4 ms·

I really hope Bun at least becomes a big player. Node.js has been very sluggish implementing new features, to the point where most people just don't trust them

I really hope Bun at least becomes a big player. Node.js has been very sluggish implementing new features, to the point where most people just don't trust them much anymore with this. Deno's direction is interesting but doesn't align well IMHO with dev's interests. Bun in exchange: > Out-of-the-box .env, .toml, and CSS support (no extra loaders required). This makes a lot of sense. Node.js should be "sherlocking" (integrating into the core) the most popular/common features devs use. It's crazy to me that, after 10+ years of `.env` being a common abstraction to manage environment variables, you still need to install a separated library because Node.js doesn't know to read the file itself. Same with yaml or toml. Same with features like fetch(), which took 5 years from the Issue to be implemented in Node.js (and not for lack of collaborators, but for lack of wanting to merge it). I'm happy though that Node.js is finally approving web features, and that the move to ESM has been finished, but they are moving so slow that I can def see a focused small team (might be too much for one person) overtaking Node.js.

andrew_ 4y ago
There's value to a system where everything is bolt-on as well.
- t0astbread 4y ago
  I have zero experience designing systems like that but I think the sweet spot would be a standard library that's modular and detached from the core. You could pull it in after setting up the core, replace it or upgrade it in parts but it's still maintained by one entity with a consistent level of quality.
  - andrew_ 4y ago
    That's the general approach Deno has gone with. it's finding success.
- franciscop 4y ago
  Sure, but I'd argue that value is marginal, for 90%+ of people building websites you want a straightforward HTTP server that you can build and customize with plain JS, and for some deeper cases yes then that bolt-on system is useful as well.
inglor 4y ago
Node is a small team too but what features in particular are we missing?
- franciscop 4y ago
  I explained some right in my comment, currently missing are things like native support for .env, for .toml and .yaml. Support for ESM and fetch() was missing for way too long until recently. Currently I don't see big gaps between web and node anymore, but I still find the APIs a bit messy and to e.g. do work with files I have to import all of the three `node:fs`, `node:fs/promises`, `node:path`. It'd be nice if at least `node:fs/promises` ALSO included non-promises from `node:fs`, like "createReadStream()" to avoid having to import another core module for that. Also WebCrypto should define the variable `crypto` as a global, like `fetch()` and `URL` do, for compat with the browser. Just some ideas/examples from the top of my head, no much search/research was put into this so def take with a pinch of salt.
  - cztomsik 4y ago
    not actually disagreeing, just my opinion: .env would be nice but I personally do not miss .yaml/.toml at all so there's likely some subjectivity in these feature-requests and keeping it in user-space has a value too (simple, rock-solid core) being able to run typescript code (without type checks) is in my opinion the biggest improvement in deno, I don't care about their own formatting or linting and I especially don't care about their LSP and opinionated way of file urls (requiring .ts suffix everywhere). Also, webgpu is nice but it shouldn't be in the core, etc. BTW: Speaking of complexity, Deno takes 140M of memory, bun and node are both around 10M. I think bun has huge potential to replace node, especially because it's not written in C++ nor in rust, both of these languages are extremely hard to master and that limits contributions (and FUN) to some extent. Safety is important but it seems to harm productivity a lot.
    - franciscop 4y ago
      Those are the kind of things that you don't think about everyday until you actually need to think about it and go like, why isn't there a `YAML.parse()` like `JSON.parse` or similar? I need not only to import a separated library, but install it first? These things should def be in the core IMHO.
davnicwil 4y ago
The problem with stuff like introducing .env support out the box is breaking backwards compatibility in a silent way, ie without any code changes and in a way that'd still run the same in dev, and pass tests on CI etc, and then just affect prod. I know this shouldn't ever happen, but you can well imagine plenty of legacy/badly configured setups where it would. More pertinently, where it would no matter how loudly you warn about it in release notes etc. When you're as mature and used a platform as node, you just can't risk things like this, unfortunately, no matter how more convenient it would be for the vast majority of users.
- atwood22 4y ago
  Apple breaks stuff all the time when updating their APIs. If you hold yourself to decisions made long in the past, then your platform will undoubtably become crusty and stale. Maybe Node maintainers are ok with that, but it shouldn’t be surprising when people go to greener pastures.
  - davnicwil 4y ago
    I do agree to an extent but the specific point I'm making here is about breaking things in a potentially silent, not obvious way. Not sure what things you are referencing here in terms of Apple's breaking API changes but if it's the sort of breaking change where previous code just doesn't compile or run on the new version it's a different matter in my view - as in, it's something far easier to catch in dev or testing and not only affect prod.
- franciscop 4y ago
  That would be very easily solved by adding a Node.js version or range in your package.json that specifies where the program is supposed to run, and treat major versions as breaking. There's a balance to be had here, and avoiding breaking anything at all costs is surely not really balanced and it's starting to add a lot of cruft that will be needed to be maintained long-term. The solution is not to "warn loudly" here; specify a Node.js version in your package.json, and your code will continue working on that version. Upgrade the Node.js engine version, and then it's on the person upgrading making sure that nothing breaks. That's how virtually all platforms work (except the web itself, but that's not "versioned" so it's fair). It's a bit more troublesome when changing core packages and considering dependencies, but the same could apply there.

andrew_ 4y ago

There's value to a system where everything is bolt-on as well.

t0astbread 4y ago
I have zero experience designing systems like that but I think the sweet spot would be a standard library that's modular and detached from the core. You could pull it in after setting up the core, replace it or upgrade it in parts but it's still maintained by one entity with a consistent level of quality.
- andrew_ 4y ago
  That's the general approach Deno has gone with. it's finding success.
franciscop 4y ago
Sure, but I'd argue that value is marginal, for 90%+ of people building websites you want a straightforward HTTP server that you can build and customize with plain JS, and for some deeper cases yes then that bolt-on system is useful as well.

inglor 4y ago

Node is a small team too but what features in particular are we missing?

franciscop 4y ago
I explained some right in my comment, currently missing are things like native support for .env, for .toml and .yaml. Support for ESM and fetch() was missing for way too long until recently. Currently I don't see big gaps between web and node anymore, but I still find the APIs a bit messy and to e.g. do work with files I have to import all of the three `node:fs`, `node:fs/promises`, `node:path`. It'd be nice if at least `node:fs/promises` ALSO included non-promises from `node:fs`, like "createReadStream()" to avoid having to import another core module for that. Also WebCrypto should define the variable `crypto` as a global, like `fetch()` and `URL` do, for compat with the browser. Just some ideas/examples from the top of my head, no much search/research was put into this so def take with a pinch of salt.
- cztomsik 4y ago
  not actually disagreeing, just my opinion: .env would be nice but I personally do not miss .yaml/.toml at all so there's likely some subjectivity in these feature-requests and keeping it in user-space has a value too (simple, rock-solid core) being able to run typescript code (without type checks) is in my opinion the biggest improvement in deno, I don't care about their own formatting or linting and I especially don't care about their LSP and opinionated way of file urls (requiring .ts suffix everywhere). Also, webgpu is nice but it shouldn't be in the core, etc. BTW: Speaking of complexity, Deno takes 140M of memory, bun and node are both around 10M. I think bun has huge potential to replace node, especially because it's not written in C++ nor in rust, both of these languages are extremely hard to master and that limits contributions (and FUN) to some extent. Safety is important but it seems to harm productivity a lot.
  - franciscop 4y ago
    Those are the kind of things that you don't think about everyday until you actually need to think about it and go like, why isn't there a `YAML.parse()` like `JSON.parse` or similar? I need not only to import a separated library, but install it first? These things should def be in the core IMHO.

davnicwil 4y ago

The problem with stuff like introducing .env support out the box is breaking backwards compatibility in a silent way, ie without any code changes and in a way that'd still run the same in dev, and pass tests on CI etc, and then just affect prod. I know this shouldn't ever happen, but you can well imagine plenty of legacy/badly configured setups where it would. More pertinently, where it would no matter how loudly you warn about it in release notes etc. When you're as mature and used a platform as node, you just can't risk things like this, unfortunately, no matter how more convenient it would be for the vast majority of users.

atwood22 4y ago
Apple breaks stuff all the time when updating their APIs. If you hold yourself to decisions made long in the past, then your platform will undoubtably become crusty and stale. Maybe Node maintainers are ok with that, but it shouldn’t be surprising when people go to greener pastures.
- davnicwil 4y ago
  I do agree to an extent but the specific point I'm making here is about breaking things in a potentially silent, not obvious way. Not sure what things you are referencing here in terms of Apple's breaking API changes but if it's the sort of breaking change where previous code just doesn't compile or run on the new version it's a different matter in my view - as in, it's something far easier to catch in dev or testing and not only affect prod.
franciscop 4y ago
That would be very easily solved by adding a Node.js version or range in your package.json that specifies where the program is supposed to run, and treat major versions as breaking. There's a balance to be had here, and avoiding breaking anything at all costs is surely not really balanced and it's starting to add a lot of cruft that will be needed to be maintained long-term. The solution is not to "warn loudly" here; specify a Node.js version in your package.json, and your code will continue working on that version. Upgrade the Node.js engine version, and then it's on the person upgrading making sure that nothing breaks. That's how virtually all platforms work (except the web itself, but that's not "versioned" so it's fair). It's a bit more troublesome when changing core packages and considering dependencies, but the same could apply there.