[HN Gopher] Deno.js in production
___________________________________________________________________
Deno.js in production
Author : sdesalas
Score : 81 points
Date : 2022-05-10 12:12 UTC (10 hours ago)
(HTM) web link (medium.com)
(TXT) w3m dump (medium.com)
| gorjusborg wrote:
| I'm surprised the included library wasn't front of mind. Perhaps
| it is implied by comparing to golang.
| unwind wrote:
| > 'Deno' (like 'Node' but backwards)
|
| Yeah, no.
|
| I wonder if more people just assume that to be true, heh. I kind
| of was expecting it, weirdly enough.
|
| Hint: "node" is "edon" backwards. Not sure if that name is taken
| for something Javascripty ... * goes to check * yeah, I found [1]
| which seems to be 4 years old, tagline "Run browser JS in the
| terminal".
|
| [1] https://github.com/dbkaplun/edon
| film42 wrote:
| "node".split("").sort.join("")
| msoad wrote:
| wat
| chrisco255 wrote:
| Sorting the letters by alphabetical order in "node" by
| converting each letter to its own string in an array. Slick
| JavaScript, basically.
| hbn wrote:
| This is the correct official answer except you didn't invoke
| sort
|
| "node".split("").sort().join("")
| bitwize wrote:
| Deno is Node on a middle-endian architecture (see: the NUXI
| problem).
| krautsourced wrote:
| Deno is No|de swapped. So no, not backwards. But... how would
| one call it?
| throwawaymaths wrote:
| Backwards (in Japanese)
| rootlocus wrote:
| little-endian
| oliwary wrote:
| French has a word for this:
| https://en.wikipedia.org/wiki/Verlan
|
| Verlan is itself verlan of l'envers (backwards). It's super
| common to make slang words this way.
| smrtinsert wrote:
| Shifted
| vlunkr wrote:
| Deno, an anagram of node
| benatkin wrote:
| It's also backwards, but by two character groups, or if you
| prefer, consonant-vowel groups.
| barnabask wrote:
| Maybe "scrambled".
| [deleted]
| [deleted]
| robinsonrc wrote:
| Rotated
| llanowarelves wrote:
| Transposed
| fswd wrote:
| node.js nowadays is a total disaster. I've been able to hold down
| the fort with turbo repo, but even then it's been a touchy
| strategy. I want to switch to Deno, and I'm interested in
| articles like this. Either that, or, because of the state of
| nodejs/NPM modules, and it's ever-increasing surface area of doom
| and resume driven development node modules, either somehow switch
| to deno or go back to just HTML and vanilla js. I just can't get
| any work done. I'm saying this as a developer with 27 years
| experience and who has written my own server side spidermonkey
| solution pre-nodejs.
| HatchedLake721 wrote:
| Care to elaborate why you can't get any work done, and how Deno
| will solve that?
|
| I've been using Node.js pretty much daily in production for
| almost a decade now, and it's never been a total disaster, not
| even close.
| thr0wawayf00 wrote:
| > I just can't get any work done.
|
| Yep, I'm feeling this right now. I was recently tasked with
| updating an internal node app that hadn't been touched in about
| 4 years and it's seriously one of the least fun things I've had
| to do in my nearly 10 year career. After hacking away at for it
| a couple weeks, I told my boss that it needs a ground-up
| rewrite.
|
| The bazaar approach of Node and NPM has created an absolute
| hellscape to develop in.
| 3np wrote:
| > Node.js is too easy to get started. This means that the pool of
| available programmers is not the highest quality. Runtimes like
| Go or Deno are still havens for the 'connoisseur' programmer.
|
| wat
|
| (Deno seems worth checking out though!)
| golergka wrote:
| Same is true about Lisp and was true about Python in early 00s.
| Rare tech brings out enthusiasts.
| qayxc wrote:
| Really? I never noticed any particularly high barrier of
| entry with either.
|
| Pygame for example was very popular with hobbyist game
| programmers in the early 2000s as it provided a much easier
| way to get started with game programming than C, which was
| the most popular alternative back then (Unity 3d only
| released in 2005 and Unreal Engine only became free in 2015).
|
| What I do remember from the early 2000s, though, was legions
| of aspiring game programmers struggling with C and C++.
| steve_adams_86 wrote:
| I've been playing with Deno lately and I can assure the author,
| I'm no connoisseur
| threatofrain wrote:
| This means at the level of their ability to draw in candidates,
| Deno interest is signal to their hiring pipeline of more
| quality. The consequence is their hiring pool is also that much
| smaller. One might say the same thing about Java v Go.
| RussianCow wrote:
| > The consequence is their hiring pool is also that much
| smaller.
|
| In the current market, unless you're a big company that gets
| flooded with applications on a daily basis, why would you
| ever reduce your hiring pool arbitrarily? If you're a
| 13-person startup with good funding, you want all the
| candidates you can possibly get. Excluding potentially great
| engineers because they've never worked with Deno doesn't make
| any sense.
| cercatrova wrote:
| It does make sense, because you filter out the non
| enthusiasts, a proxy for great programmers. When Rust was
| still nascent, the people interested in it were likely to
| be of a higher quality bar than any regular old Javascript
| dev. That's not to say that JS is bad necessarily, just
| that enthusiasts correlate to great programming skills.
| chrisco255 wrote:
| My goodness, if you're excluding any hire because they've
| never worked with (insert new hotness here) you are simply
| making a big mistake in hiring, in general.
|
| Deno is still JS based at the end of the day and attempts
| to conform to web standards in its design. I don't know why
| in this particular case it would limit your pool.
|
| I could see how Golang vs Deno (JS) would impact your
| hiring pool dramatically though.
| mattwad wrote:
| Especially if you're a product-focused startup, the last
| thing you may actually need is an enthusiast for a
| language. 90% of the time you want people that just want to
| use the right tool for the job.
| threatofrain wrote:
| As chrisco255 pointed out downthread, I made a mistake in
| saying that Deno would reduce your hiring pool. That Deno
| is a signal in hiring does not mean you've lost out on Node
| talent, it just means that you've found a net gain in
| hiring by weighing Deno more strongly (assuming the blog
| post is correct).
|
| However, Java vs Go would probably make a big difference in
| terms of hiring pool size.
| 14u2c wrote:
| Yea, this is one of the most garbage takes I've ever heard.
| Requiring the use of something esoteric is not suddenly going
| to allow you access to a pool of higher quality candidates.
| Instead you will still see the same pool, but now the average
| candidate will be even less knowledgeable about the technology.
|
| I do like Deno personally, but this reason is not a great one
| to do so.
| jonny_eh wrote:
| "Too easy to get started" is just gate keeping.
| DrFell wrote:
| Reverse gate keeping, yeah. You built a fence around your
| safe zone, and locked yourself in.
| my69thaccount wrote:
| On one hand, JavaScript being easy makes programming
| accessible. On the other hand, the state of programming is
| terrible and getting worse. So you can't say if it's bad or
| not.
| kupopuffs wrote:
| it's not getting worse. you're just getting older
| jonny_eh wrote:
| 100%. If people want to still use Wordperfect 5.1, they
| still can.
| RussianCow wrote:
| > On the other hand, the state of programming is terrible
| and getting worse.
|
| What does this mean? It's an order of magnitude easier to
| build an app/service/whatever today than it was a decade
| ago. Having to maintain separate code paths for IE because
| it doesn't support many of the APIs and CSS features you
| need was "terrible"; by comparison, engineering today is
| heavenly.
| my69thaccount wrote:
| Engineering might be easier, the user experience is
| magnitudes worse than a decade ago, pretty much
| universally.
| duxup wrote:
| I've tried Deno. The author might rethink that line after
| interviewing me.
|
| Really though this seems almost like resume keyword checking
| level of a candidate quality check. Actually it sounds exactly
| like that...
| BeefWellington wrote:
| It is disappointing to see this message as the basics of what the
| software is on their site (https://deno.land/):
| Deno is a simple, modern and secure runtime for JavaScript,
| TypeScript, and WebAssembly that uses V8 and is built in Rust.
|
| Only to have that immediately followed by really poor practice of
| suggesting this as the installation method:
| curl -fsSL https://deno.land/install.sh | sh
|
| This is not strictly related to Deno -- lots of software does
| this -- but if you're going to suggest your thing is more secure
| than the other guys' thing (which is implied by calling your
| thing secure), you shouldn't then be immediately throwing that
| credibility away.
|
| Yes, the page offers a link to the "Releases" page at their
| github repository. However, anyone familiar with any kind of UX
| will understand immediately that this is effectively burying the
| link and subtly makes the statement that you don't really want to
| bother with that other way of doing things. They also don't
| provide a gzipped/bzipped tarball for the linux install but a zip
| file instead, adding an additional barrier/dependency.
|
| I understand this is an area where security is losing the tug of
| war to ease of distribution/access but it pains me to see it on
| any project, let alone the potentially good ones.
| winrid wrote:
| It's using SSL, what's the real world concern here? Other than
| someone might get copy-paste happy and someday install
| something they don't want.
| BeefWellington wrote:
| There's quite a bit wrong with this idea that "It's using SSL
| [therefore it's safe]", assuming your meaning there.
|
| The most obvious case: someone compromises the installation
| script on the actual real deno server. Right now the
| webserver there is returning an HTTP/307 to an HTTP/302 to
| the "current" installation script file. Any compromise of the
| webserver makes this very dangerous.
|
| Contrast that with proper signed packages, code signed
| sources, etc. There it requires compromise of the developer's
| systems and signing keys, which at least _can_ be a far
| harder thing to attack if they 're doing things securely.
| __ryan__ wrote:
| This makes sense. But how do I as a basic user make sure
| the signature is correct and definitely from Deno? Couldn't
| a hacker sign it with their own signature?
| systemvoltage wrote:
| I think this is a fair criticism and deserves attention.
| Whenever anything shiny comes around, we are too enamored
| by it to not allow any criticism.
|
| Is there a reason Deno is not packaged as a repo in
| official apt, deb, yum, etc repositories?
| dimitrios1 wrote:
| And in this hypothetical scenario, how does that protect
| against the aforementioned attack? If one of deno's
| hosting sites can be attacked to upload a malicious
| script, one of the package registries can also be
| attacked and upload a malicious package.
| gorjusborg wrote:
| https://www.idontplaydarts.com/2016/04/detecting-curl-
| pipe-b...
| my69thaccount wrote:
| 1. the file is replaced with a malicious version on their
| server and not checksummed
|
| 2. copy/pasting includes invisible characters that aren't
| seen until executed
|
| both of these things happen regularly
|
| orthogonally, curl|sh (usually) circumvents the package
| manager and makes uninstallation difficult
| crowlKats wrote:
| https://deno.land/install.sh is a redirect to
| https://deno.land/x/install.sh, which is treated as any /x/
| (community) module. These modules are immutable clones of
| github tags (in this case,
| https://github.com/denoland/deno_install/). If someone would
| manage to breach the AWS S3 buckets that we use for module
| storage, it wouldn't be just a problem for installation of the
| deno CLI, but a problem for any module on the registry.
| __ryan__ wrote:
| You're about to run their software on your computer-- what's
| the difference with that and running their install script?
| BeefWellington wrote:
| How do you guarantee that their install script is non-
| malicous and was actually provided by them?
|
| There's a reason why code signing exists as a security
| measure.
| danenania wrote:
| While signing does improve security, it's still something
| of a turtles-all-the-way-down problem because how do you
| verify the public key is valid? An additional factor is
| added, which helps, but it's not a silver bullet. And the
| complexity tradeoffs of requiring cross-platform
| installation of a signing lib like gpg/minisign (which
| plenty won't already have installed) and a _much_ larger
| install snippet are significant.
| skybrian wrote:
| For the Mac at least, signed dmg files and apps are
| normal, so they should have done it that way.
| benatkin wrote:
| In the security model section it doesn't mention workers. In
| Deno, workers can be given different permissions. The article
| suggests having different permissions per file. I think it might
| be nice to have both but if I could only have one I would want
| separate permissions per worker. Files aren't always split along
| the same lines that permissions should be split. I would like to
| be able to control permissions by url prefix though - so some
| library doesn't do more than I want it to. It might mean setting
| up a worker if I want to make sure it doesn't indirectly use more
| dependencies.
| [deleted]
| dimgl wrote:
| I haven't had the same success with Deno that I expected. At
| first, I was shocked by how good the tooling is, and I was super
| happy with its dependency management. All of the problems started
| once I started getting into actual business logic.
|
| `redis` and `ioredis` `npm` packages don't work with Deno, even
| with the Node compat layer (I tried). So you have to use the Deno
| driver for Redis. But you look up the library for this, and it's
| experimental: https://deno.land/x/redis@v0.25.5
|
| Same deal with Postgres. `pg` would not compile at all. Knex also
| didn't work (this was an older project). I'm assuming this is
| because these two packages use native Node.js plugins.
|
| I like Deno a lot, and the out of the box TypeScript support is a
| gamechanger, but I had a really tough time working with it and
| actually being productive.
| ricardobeat wrote:
| On the other hand, not being able to bring all of the node.js
| package ecosystem along can be considered a feature.
| SkyPuncher wrote:
| I don't really understand this take.
|
| Yes, there are a lot of packages available - but that gives
| you choice.
| LAC-Tech wrote:
| I don't think it can.
|
| There's a lot of crap in the node.js ecosystem, no denying
| it.
|
| But there's just a lot of packages in general. Many of which
| are really, really well designed and good.
| Osiris wrote:
| It's not a feature if you can't build the project you are
| trying to build.
| MuffinFlavored wrote:
| > `redis` and `ioredis` `npm` packages don't work with Deno,
| even with the Node compat layer (I tried).
|
| I'd love to hear specifically what didn't work and how close
| the Deno team is to maybe fixing those sorts of issues. Not
| that they owe that to us open-source wise, just curious as
| like... otherwise you are right. We're starting the ecosystem
| again over from scratch.
| ecmascript wrote:
| I hoped this article would provide more info than it actually
| did.
|
| For me, a javascript developer that mainly use Node.js for work,
| Deno is interesting and I want to use it but the hosting part is
| what prohibits me from using it. In node it's easy to run
| production code with pm2, you can cluster it and it's super easy
| to configure it so that it will run one node process per
| available core.
|
| With Deno, you can't do this because there is no clustering
| available so you kind of have to run it on single core machines
| to get maximum performance out of your hardware. In other words,
| on cloud solutions like Deno deploy or a Kubernetes cluster
| configured to run it on single cpu docker containers.
|
| I am not interested in that and as long as it is that way,
| running Deno is unfortunately a waste of my hardware. Sure there
| are web workers and they are great for stuff but if my process
| dies for some reason I don't want that to halt the application.
| Sephr wrote:
| The title is very misleading. Deno is not written in JavaScript
| and is never referred to as Deno.js in any official sources. Deno
| is written in Rust.
| benatkin wrote:
| Much of Node.js is written in C, yet it's still called Node.js.
|
| Deno has some JavaScript/TypeScript in it. On GitHub
| https://github.com/denoland/deno is 22.8% JavaScript and 13.2%
| TypeScript, and https://github.com/denoland/deno_std is 68.2%
| JavaScript and 31.6% TypeScript.
|
| So to me the title is misleading about the name (Deno is
| certainly not named Deno.js), but not about what Deno is
| written in.
| danenania wrote:
| The security model is a big one for me. If they could extend the
| permissions system to work for individual dependencies, they
| could solve one of the biggest security issues facing developers
| right now. _Especially_ if policies could also be applied to node
| packages.
|
| Are there any plans to move in this direction? It seems like if
| you can do it for the full app, you should hypothetically have
| the capability to make it library-specific. Or perhaps there are
| non-obvious blockers that make it too hard?
|
| If there _are_ plans to do this, isn 't it better to do it sooner
| rather than later? Better to get library authors in the habit of
| specifying permissions/policies now while the ecosystem is still
| small. If you wait too long, it will be a ton of work to retrofit
| all the existing libs.
| mostlylurks wrote:
| I, too, would like to have per-dependency security policies.
| But I can't really see where you would realistically draw the
| line between dependencies, other dependencies, and your own
| code. Is a callback, created in your own code, that potentially
| accesses dangerous APIs allowed? Presumably yes, but what about
| when it is passed to a dependency that proceeds to call it?
| What if the dependency returns the callback back to your own
| code, can you call it then? What if the dependency wrapped the
| callback in another callback that calls the original callback
| with altered arguments, and returns that to your code? Do you
| enforce any potential restrictions statically, necessitating
| much stricter restrictions on what you can do than typescript
| on its own does, or at runtime, necessitating some sort of non-
| trivial bookkeeping tracking all the parts of the codebase that
| any piece of behavior has touched?
| danenania wrote:
| While I don't have the answers to all these questions, I
| imagine we could come up with some sane defaults.
|
| Even if you have to 'eject' and provide overly broad
| permissions to certain libraries, I'd imagine these would be
| quite a small percentage and you'd still get the huge win
| that the 90% (or whatever) of your dependencies that don't
| need any system or network access at all and don't have the
| kind of issues you describe can effectively be removed as
| viable targets for attack.
|
| For callbacks, Deno could provide a wrapper function that is
| only available to the top-level app (not dependencies) and
| causes the permissions in the callback to be evaluated at the
| app level, not the dependency level. There may be a better
| way, but that's one idea.
|
| Static checking would be great too. I think a combination of
| static and runtime enforcement would be ideal.
| heynk wrote:
| You should check out Lavamoat:
| https://github.com/LavaMoat/LavaMoat
|
| It attempts to do what you're essentially describing. It was
| built by the MetaMask team, where supply chain attacks are an
| obviously huge risk.
|
| I've spent some time trying to get it working in an app, but
| haven't been able to get it all the way working. It's still
| pretty beta and not well documented.
| danenania wrote:
| Thanks, I'm super interested in anything that tackles this
| problem.
|
| Deno's approach seems most promising so far since it's really
| ideal to have this built in to the core runtime, but it's not
| really very useful yet as implemented and I don't know
| whether taking it further is a priority for them.
| simlevesque wrote:
| > Or perhaps there are non-obvious blockers that make it too
| hard?
|
| To me, it seems like you'd need a new language.
| danenania wrote:
| Why is that? I may be missing something, but they're already
| enforcing permissions at runtime, which seems like the hard
| part to me. It would 'just' need to be integrated with the
| call stack so you know which dependency(ies) want
| system/network access.
| zdragnar wrote:
| IIRC there are all sorts of issues around monkey-patching
| prototypes, shared objects between modules, etc. which
| would readily allow escaping any sort of module /
| dependency level permissions system. You'd probably be
| better off pitching a typescript subset language with its
| own compiler / interpreter rather than trying to shoehorn
| it into V8.
| danenania wrote:
| These seem like solvable problems. Prototype
| modifications are rare these days and should probably be
| restricted in the same way that system/network access is.
| Shared objects between modules also seem like an edge
| case apart from callbacks? I posted an idea on how to
| handle callbacks upthread a bit:
| https://news.ycombinator.com/item?id=31326123#31332061
| zdragnar wrote:
| System and network access are all done via the runtime
| library functions, which are easy to control.
|
| Changing prototype access almost certainly involves
| modifying V8 in unpleasant ways, and I'm not sure how you
| would get around the overhead of deno needing to the call
| stack on every function call- statically analyzing when a
| function is operating in one context or another is
| certainly not a trivial problem.
| gernb wrote:
| you will not solve the dependency problem with permissions. You
| will only solve it by reducing dependencies and reviewing code
| before you updated dependencies
|
| adding permissions will do nothing except add ridiculous
| overhead and complexity such that to get anything done devs
| will just give all permissions
___________________________________________________________________
(page generated 2022-05-10 23:01 UTC)