56 ms·

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

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?

hn_throwaway_99 6y ago
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.
- Ciantic 6y ago
  > 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.
  - hn_throwaway_99 6y ago
    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.
- littlestymaar 6y ago
  > 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).
harikb 6y ago
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.
- granshaw 6y ago
  The cycle of [software tooling] life
- vipshek 6y ago
  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-attractive-profits/ https://stratechery.com/2015/netflix-and-the-conservation-of...
satvikpendem 6y ago
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 https://github.com/denoland/deno/issues/986
- ashkankiani 6y ago
  It's not going to be static compilation or give any sort of speedup. That's just a bundling command basically.
  - satvikpendem 6y ago
    Ah that's disappointing. i wonder if there is any work to create a JS compiler.
jariel 6y ago
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.
- eloff 6y ago
  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.
  - jariel 6y ago
    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.
draw_down 6y ago
Perhaps this is a start of a way out of the tiny-package madness in the Node ecosystem.
Snelius 6y ago
And why it can't be added to the node? Why we need the brand new incompatible engine for that

hn_throwaway_99 6y ago

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.

Ciantic 6y ago
> 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.
- hn_throwaway_99 6y ago
  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.
littlestymaar 6y ago
> 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).

harikb 6y ago

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.

granshaw 6y ago
The cycle of [software tooling] life
vipshek 6y ago
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-attractive-profits/ https://stratechery.com/2015/netflix-and-the-conservation-of...

satvikpendem 6y ago

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 https://github.com/denoland/deno/issues/986

ashkankiani 6y ago
It's not going to be static compilation or give any sort of speedup. That's just a bundling command basically.
- satvikpendem 6y ago
  Ah that's disappointing. i wonder if there is any work to create a JS compiler.

jariel 6y ago

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.

eloff 6y ago
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.
- jariel 6y ago
  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.

draw_down 6y ago

Perhaps this is a start of a way out of the tiny-package madness in the Node ecosystem.

Snelius 6y ago

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