Unfortunately Node still can't do something like this out of the box (AFAIK at least):
import { Bla } from "npm:bla@^5";
Deno also has a builtin TS type checker, linter, formatter, test runner with coverage support, package manager, language server etc etc... In node these are all separate (and often 3rd-party) tools.
There's no business here anymore.
I wouldn't be surprised if Bun is abandoned at some point as well.
(Which is why I am happy to see new runtimes but never care enough to seriously use or adopt them.)
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
For my projects, I am used to maintaining package manager configuration, bundlers, linters etc.
So I never had much interest in looking into benefits of Deno or bun.
However I now work with software that requires PQC resistance and node's native ML-KEM and ML-DSA abilities made me switch back. Also I'm not particularly an Anthropic fan so that was also a separate nail in its coffin for me.
Finding the right balance of "being responsive to bugfixes, some of which may patch disclosed zero-days" and "not allowing a compromised package to be installed" is tough, these days.
But PKG is not supported by anyone any more (?) and it has an upper limit on the version of Node.js base-image it will support.
If Bun supports compiling executables nicely I hope that feature somehow stays alive and is migrated to other runtimes. Or maybe it can become a standalone tool for exe-compiling?
Node at least picked up --run, TS stripping support, .env loading, watch mode, and sqlite (plus some other things I'm probably forgetting) since Deno started so at least theres that.
Random example: I've worked with many frontend developers who seemed to believe listing dependencies in package.json in devDependencies instead of 'dependencies' controls what ends up in the production bundle.
I'm under the impression few understand that this is only a cosmetic distinction unless you use the package manager's --omit=dev or --production flags during install.
What is included in the production bundle is of course determined by the bundler's dependency-graph reachability from the entry point.
For people who never configured these tools themselves, it's probably difficult to understand how the modern web stack works.
However, nowadays you can probably have AI explain it to you well enough while it fixes the issues.
> I've worked with many frontend developers who seemed to believe listing dependencies in package.json in devDependencies instead of 'dependencies' controls what ends up in the production bundle.
If so many believe that it’s how it should work, maybe it just should work that way. Principle of least surprise and all that.
It also gets messy if you're building 2 or 3 services simultaneously out of the same node_modules dir. E.g frontend, backend, shared, scripts...
Like say you installed only the production dependencies, then you'd be missing the build tools, bundler, etc.
One idea would be to use hooks of your bundler to enforce that each module resolved during the production build is declared in the regular dependencies.
It would be far from a standard solution though.
It's not built in to ESLint, but it's fairly widely used in my experience and helps ensure that you've got a sensible split between production and non-production.
It helps keep all your related packages on the same dependencies. It’s hell for react native sometimes though.
With nx you define the dependencies between your tasks, so that the packages build in the right order and with caching.
I do not think it changes anything about how packages are installed by the package manager or bundled by the bundler.
You can declare build tools in either the root package.json or packages/a/package.json, and I don't think anything prevents you from bundling something declared in devDependencies.
On second thought, I see now that you probably mean it helps keep shared dependencies at the same version when you declare them in the root package.json.
That's a feature of npm/pnpm/yarn workspaces though, not nx itself. And it only works with bundled dependencies, since they would be undeclared in the package itself and thus couldn't be installed externally. If you need that, I think pnpm catalogs would be the right tool.
It works the same way you use a bundler instead of assembling your own and so on and so forth down the tree. The farther down the tree, the less focus you should give your understanding to, but that's not an excuse for giving no understanding below the first layer.
* Or, in the absence of well-written documentation, the source code, the decompiled object code, or at the very least inspect the end result.
I don't. What do you mean?
It reminds me of game engines. If you want to make a game engine, there's nothing wrong with that, but you should acknowledge that you're building a game engine, not a game--or rather, if your goal is to make a game, starting by making a game engine probably isn't optimal.
It's the same for Bun. It's clear that they wanted to build a JavaScript runtime, and also they wanted to use Zig. They are doing both of these things, but when push comes to shove, their desire to use Zig was more important than their desire to make a JavaScript runtime, I believe.
The one silver lining here is that Deno had already increased their node/npm compatibility. Migrating off of the jsr ecosystem and back to npm is going to be less painful than one might imagine. I expect present LLMs to be sufficiently good at the task, for example.
- They originally bet on being a TypeScript dialect that didn't quite match the expectations of node in a few small places that ended up mattering hugely.
- One of the original value propositions was "deno compile" and "deno bundle", and those never actually worked well enough to be robust for our real-world use cases (early on they didn't support TLA, then dynamic imports didn't work, then they had issues with ARM compilation)
- Then they simultaneously tried to support node syntax out of the box with npm import specifiers _and_ create a new javascript registry (jsr.io)
- At the point where we expected them to actually make their base-level ecosystem robust, they pivoted to edge compute, and then the writing was on the wall
Deno/Bun see the picture better than I do, and they decided it was the right time for an acquihire.
Then I read that paragraph, and it made more sense that they're acquihiring + killing.
It's an acquihire. They hired the people behind Deno
Companies went all-in in a barely established niche player with 1/100 the traction, instead of sticking with Node, and even better an LTS Node, and are now surprised?
Do they also do their front-end in Dart?
https://nodejs.org/api/permissions.html - since v20 - Apr 17, 2023
https://nodejs.org/learn/typescript/run-natively - stable and without a flag since v22.18.0 - which sometime after Apr 24, 2024 which was the v22.0.0 release
https://nodejs.org/api/single-executable-applications.html - Added in: v19.7.0, v18.16.0 but still in Active Development (not stable yet) - 2022
For reference, Deno was released in 2020 with all of these features from the start.
Feels like it always take some healthy competition for Node to make big strides like this. Like the whole io.js fork thing a long while ago.
For context: I begrudgingly adopted Vue a while ago after finding React to be too unwieldy, and part of that opinion is definitely related to a poorly written Redux implementation.
It sounds like you're coming at this from a perspective of popularity and thus access to engineering candidates with expertise in it which is fair, but speaking as someone who also went with Angular 2 over React during those times, I'm still using Angular and I'm very happy with it from a technical perspective. Yes, it does mean there are less options for hiring, but it has been a positive experience for my team and for me in my own projects to stick with it.
How well designed the initial versions of TypeScript were can be seen by how smoothly later versions were able to build on them, and even after so many major improvements the language has barely a wart (enums probably being the only one).
Something of its own sign of Microsoft out-engineering some of the hiccups of the ecosystem as a whole. (I started using Typescript < 1 simply because it was the safest and easiest way to write AMD modules also with an eye to UMD or SystemJS output with just a compiler flag change if you needed to ship something compatible outside the house.)
1/3rd of apps on the iOS and Android app store use flutter and that percentage is growing over time. Whereas people are moving away from JS/TS frameworks like React Native.
built-in permission system for filesystems and etc
just forbid writing to important folders like ~/.ssh
Hey, you jest, but Flutter has a lot of traction!
(I conceptually like Flutter, but I can't get over the Dart thing, so I'm not part of that traction.)
This is actually a good decision though.
Wait till you hear about this thing called Bun.
Though with a tiny core team and almost carte blanche AI credits, they are a lot leaner.
Bun's release cadence dropped like a rock after the rewrite, in spite of the radical AI militancy and virtually infinite AI budget.
I understand why the venture-backed entity couldn't do this, but given the reactions here, could a new maintainer not take over and simply charge for support and future enterprise features like the Sidekiq guy?
They should hire a few devs to develop it then.