Comment by xkapastel | Hacker News Reader

Comment by xkapastel | Hacker News Reader

Parent Full thread

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

Reply on news.ycombinator.com