Hacker News Reader

Comment by hn_throwaway_99 | Hacker News Reader

I'm really curious about whether people think Deno will succeed. Node certainly has its warts, but I feel like with recent improvements in the JS language and Typescript that Deno doesn't really solve problems people have nowadays. I don't think the decoupling from NPM and the dependency management approach (or lack thereof) is really a thing that most developers want. NPM certainly had a bunch of "dumpster fires" for years IMO (lock files mess, signed code mess, etc.) but I feel most of those pain points have largely been addressed.

I downloaded Deno and tried it out, but at this point I'm just left thinking it doesn't really add anything for me that I need.

View on HN

This is puzzling to me because I had the opposite reaction: among other things, Deno solves an incredibly important problem with Node, which is the complicated configuration used with most projects. Deno can perform, out of the box, many of the things you'd need to configure Webpack + Typescript to do:

    SUBCOMMANDS:                                                      
        bundle         Bundle module and dependencies into single file                         
        cache          Cache the dependencies                                                  
        completions    Generate shell completions     
        doc            Show documentation for a module                                         
        eval           Eval script                       
        fmt            Format source files                                       
        help           Prints this message or the help of the given subcommand(s)
        info           Show info about cache or info related to source file
        install        Install script as an executable
        repl           Read Eval Print Loop
        run            Run a program given a filename or url to the module
        test           Run tests
        types          Print runtime TypeScript declarations
        upgrade        Upgrade deno executable to given version

What would it take to get Node to do all of that? Which documentation tool would you choose, and how would you configure it? Testing? Bundling? Formatting?

If anyone remembers, this is similar to the “Turbo Gears” vs “Django” of Python world. Turbo Gears allowed me to choose the best of each component - but pretty soon one ends up having to upgrade or migrate to the new-best-sub-component on a weeekly/monthly basis. django helped avoided a lot of headache by defaulting a decent, but not necessarily the best tool, and sort of “won” in the end.

For some reason, we continue to replay this fight in each and every language and environment.

This strikes me a similar to a dynamic at the level of entire corporations and industries—commodification/modularization on one end, wholeness/integration on the other: https://stratechery.com/2015/netflix-and-the-conservation-of...

The cycle of [software tooling] life

Totally agree with all that, but I also think it's one of those things that most devs hit the pain point for once, and then have a standard template project they use for everything going forward. I.e. I have all my webpack/tsc/eslint/prettier/jest boilerplate set up once, so now it's not really an issue for me.

I also think this is a problem area where the Romejs project is taking a better approach: simplify and fix the toolchain, instead of replacing the entire runtime.

> I have all my webpack/tsc/eslint/prettier/jest boilerplate set up once, so now it's not really an issue for me.

For any given nut in that stack, there is hundreds of different iterations. Even if you can manage that, it changes between projects and people. It is horrible mess if you think about it from company point of view. Everyone who comes to new team, has some own quirks and ideas about that stack, which just makes it even worse.

The whole create-react-app was done precisely because that stack keeps changing like sheep's wool. It tries to do same thing. Having a standard way is better for developers and companies, and Deno having many of these builtin removes friction because of that.

Again, I totally agree with everything you've said, but if that's the primary problem (which, when it comes to Node/JS dev, I think it probably is), then the solution should focus on that, i.e. fix the toolchain a la RomeJS, rather than create an entirely new runtime.

> Totally agree with all that, but I also think it's one of those things that most devs hit the pain point for once, and then have a standard template project they use for everything going forward. I.e. I have all my webpack/tsc/eslint/prettier/jest boilerplate set up once, so now it's not really an issue for me.

Stop using JS for a year, and come back only to discover that half of the tools you were using back then is at best obsolete or even deprecated and unmaintained, or that their API changed so much in a major version that you can't recognize it (see the Babel6 — AKA Babel Vista— update).

And since you're not only using these tools but also their integration to your favorite editor, you cannot stick on the old version for long, unless you stop upgrading your editor altogether).

Static compilation of JS into a binary is also being worked on (albeit slowly) with `deno compile`[0]. This is the feature I'm most looking forward to personally, goodbye JS slowness.

[0] https://github.com/denoland/deno/issues/986

It's not going to be static compilation or give any sort of speedup. That's just a bundling command basically.

Ah that's disappointing. i wonder if there is any work to create a JS compiler.

None of those are very important.

When node appeared, it was a 'huge thing' because you could run JS consistently on the server-side, with some kind of packaging scheme.

Most of the things you listed aren't going to be useful to most, even when they are, they are small things that can be managed otherwise. Though admittedly, everyone will runt into at least one of those issues.

For a large, complex deployment, there's no obvious reason at all to shift to Deno.

We'll have to wait and see how it works out for those who want to try it for fun.

There are at least three big obvious reasons.

1) You need a secure sandbox for running JavaScript (e.g. You run a SaaS and you want your users to be able to customize something). NodeJS has to be sandboxed at VM level like Python, even although JavaScript was designed for this very purpose.

2) You want a TypeScript first nodejs.

3) You want isomorphic JavaScript between the browser and the server, because node does its own thing (for historical reasons) and deno strives for compatibility where possible.

What it lacks is npm compatibility. That is the JavaScript community for better or worse and without being able to use those libraries it doesn't seem compelling to me.

None of those are 'big reasons'.

Or rather, they might be 'big' for a few teams in specific areas, but they are not 'big market opportunities' not even close.

The ability to go from Java+Spring OR Perl/PHP - and then have the choice to actually do JS on the server is a big deal - and that's why Node.js was a success.

The sandbox is nice but I don't see it being a big opportunity just yet. 'Running your own SaaS with untrusted code' is a developing area, and I'm not sure of Deno actually is a solution (how does one integrate with it). Also - Node.js does have some options there in the form of VM2. The real security hasn't been validated just yet either.

'TS first' - I think is just a toolchain and packaging optimization. We're all going to be running some kind of process for bundling and packing, it requires no effort to transpile in to JS at that point.

The isomorphism again, is a neat feature.

In other words, Deno has some cool new features in the context of 'the market/users space' for server side JS, whereas Node.js actually founded and created that entire market category.

Under normal circumstances, I wouldn't bet on any movement towards Deno, just because there are too many legacy Node.js already there, but since there seems to be a strong fanboy following, I don't doubt a lot of young devs push for it to be used because it's cool and shiny. All 'shiny new toys' have some benefits here and there, it's just a matter of contextualizing them into the incumbent landscape.

I would use it if it was npm compatible, and that does seem to be coming. Remember it's not a new language, more like Python vs IronPython. Although hopefully it will have more success.

And why it can't be added to the node? Why we need the brand new incompatible engine for that

I am actually really interested to see if something like Deno can take over in programming education.[1]

Deno's extremely simple import semantics and built-in tooling could make it a great environment for a learner. They won't have to be exposed to package management, they can just click a URL in their source code and see the exact source code they just imported.

All the stuff that professional developers can do and might want to do for themselves (setting up testing frameworks, pinning transitive dependency versions) is kind of out of scope for educational use. Unless that education is specifically targeted at "how to do modern JS development within this specific ecosystem".

The ease of bringing TypeScript into your Deno programs may make it easier to start "graduating" to static typing as part of the curriculum, without being like "okay, that was Python! Next up: Java!"

[1]: Say what you want about JavaScript, I don't see that modern JS is significantly worse than Python for learning to program (having watched a couple of students go through Python courses). All languages have their warts.

I'm not seeing enough in Deno that would tempt me to drop compatibility with the Node ecosystem. What I really want is actual Node.js with native TypeScript support.

I think the best is a TS to binary right away :)

I can say that the word “sandbox” immediately raises the interest level among security folk.

The big deal here is security by default as enforced by the runtime (deno) itself - there is afaik none other doing anything remotely as cool anywhere. It in effect makes it super safe to run code since you have to explicitly allow the various levels of system access.

Also makes the system fundamentally unattractive to malware authors whereas installing modules via node.js is like leaving your front door open and taking a chartered holiday while hoping for the best.

> there is afaik none other doing anything remotely as cool anywhere

Any operating system with "capabilities", "namespaces", "privileges", etc.

That includes Linux, Windows and many others.

How many developers are really using Linux capabilities for their deployments? I highly doubt that many...

Sure. I guess that means deno is sort of providing a lot of the capabilities sysadmin have had for a while in a language.

If deno let's you design a program that acts like Qmail with all its separation of concerns and permissions but with one binary, that's a plus.

Most folks running Node.js instances have control over all of the software they are running and 'security' in this sense just isn't a huge concern. Obviously, more security is alwasy better all things being equal, but it's not the big issue with Node.js.

It seems that Deno is probably a nicer, overall version of Node, and if we were 10 years ago, undoubtedly, we would chose Deno. But we're not, we have massive installed bases and operating capabilities, so the choice is less obvious.

The developments in WASI's security model are very interesting - see this post: https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas...

It will succeed if it handily wins side by side benchmarks, its that simple.

I doubt it. For a lot of use cases node is fast enough.

No, performance is not the issue most of the time.

For most systems, the raw performance of the JS just is not a bottleneck.

Reply on news.ycombinator.com