To jest, businesses can be successful without sustainability. Instagram definitely was.
In the space of such foundational technologies, there’s always been a vast gap between the number of private vs open-source projects that succeed. Even all the way back to proprietary compilers 40-50 years ago.
If they had stuck to being an open-source project, the kind of adoption and mindshare they achieved would have put them among the most successful ever. And I am sure they would have been able get their team paid very well sustainably. The unicorn model cannot fit every single venture.
Some day devs will learn FOSS projects don't survive on good will alone.
But the VC path pushed them to increase costs more than they should. They didn’t need that money to deliver on the mandate of Deno, they had to inflate the vision to some grand cloud solution, which didn’t make much sense.
> then it is a failure as company
Perhaps it shouldn’t be a company at all. Private companies cannot attract the same support as open-source foundations do, since they are for-profit organizations.
Foundations are companies in disguise, with taxes benefits, and there isn't one without industry partners.
Which programming language survives with support contracts, no company sponsorship, and has mainstream adoption?
Of COURSE there are industry partners. That’s not a bad thing!
Ultimately, it was easier for the Node ecosystem to adopt those changes into Node than it was to migrate to a different JS runtime like Deno. Bun would likely not exist without Deno too.
https://esdiscuss.org/topic/a-reprieve-for-es6-comprehension...
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.)
Getting “funded” is to get a job maintaining the project. Great! This happens to incredibly few, high-profile projects. Those people wouldn’t be working on the alternative if they didn’t get paid to work on the one they care about.
In the context of Deno here, it obviously implies market share.
However that doesn’t mean it’s a good idea to use them, it is not
I wish it were otherwise but I don't think anyone running a hype-driven project of dubious utility needs to worry too much, humans are not rational creatures
Which is forever in the tech industry.
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.
It's a different mental model I'd say. Specifically: First, I add the part to the pile, then I wire it up.
I wouldn't call it redundant to explicitly spell out what actually happens. If anything, I'd call it good to remind people that they are adding something into their scope of responsibility.
Fix't it for ya.
Okay. Now I'm confused and my head hurts. You want to randomly download dependencies for a "shell script" at the time of invocation?
I think I need to lie down.
Nobody says Deno is not better overall than Node. It clearly is, across the board. And nobody cares.
If Deno would provide actual improvements people would care about then for sure it would survive. The problem is that it didn’t. It was just fun project and creators learned a lot for sure. And entire js ecosystem improved thanks to Deno’s push.
I wouldn't want a shell script to have side effects aside from its desired function.
On top of that, I wouldn't want a shell script that is being used for some task to have a runtime dependency on Internet connectivity, a registry being up, and/or the chance that a version of a dependency that is used is dependent upon when the artifact was first run.
But you replied to a comment that said "for simple standalone tooling scripts in otherwise non-JS/TS projects" where this absolutely is not a bad pattern.
There's no business here anymore.
You can't just switch over to nodejs
Deno has tons of browser APIs, e.g. Deno.serve uses the standard Request and Response objects. That's not platform lock in.
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
But then again considering there's no barrier for entry to develop runtimes now, I guess these companies are just going to develop their own.
Congratulations to the Deno employees.
It appears that they are well on thier way to supporting all possible runtimes.
I don't. What do you mean?
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.
edit: Sweet! seems to be all intact!! Thanks!!
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 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'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 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.
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?
I don't mean that in a "social proof" kind of way. Popularity brings it own advantages. Because lots of people use something, you get the advantages of lots of other people using it:
a larger ecosystem, more libraries, easier to find new team mates, easier to find people willing to learn, better and more answers on Stack Overflow (or in LLMs now, I guess), etc., etc.
And there's just no compiled languages more used and known than JavaScript/TypeScript. Java and C# come closest, but they're still far off and still require runtimes.
All compiled languages require runtimes, the only difference is how big they are, and JavaScript runtimes are not among the smallest ones.
Hmmm, no ?
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.
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?
If only those that boast online how X is greater than Y in every single thread, actually paid even a Starbucks coffee to X.
Deno/Bun see the picture better than I do, and they decided it was the right time for an acquihire.
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
Server side compiled languages were working perfectly fine, but we had to have this scripting languages, performance doesn't matter 2010's vibe.
Only for all to realise 15 years later that performance actually matters when paying the electricity bill.
JS running on a raspberrypi can support most sites on the internet.
Sure it matters at scale but what tech interviews forget is most don't every get to the scale where it matters.
A 2015 machine with duel xeons can run many many small tech companies stacks.
They should hire a few devs to develop it then.
Keybase, Astral and Oven / Bun are other examples of this, I think Zed is on a similar path.
No one who has tried ruff, uv and ty would agree with that.
Nor go back to any of the previous alternatives Astral's products replaced. (With the possible exception of ty since that's still pretty new)
this is so much bullshit I don't even.
even if they thought that could actually work : it could not unless by "great engineers" you mean "resume-pad masters".
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?
This is actually a good decision though.
built-in permission system for filesystems and etc
just forbid writing to important folders like ~/.ssh
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.
Nonsense. They paused releases to get the rewrite out, and following the rewrite it was rather obvious they lost the ability to release production-grade software.
It would have been trivial to release patch versions with little cleanup work, but evidently the project isn't even able to put that together.
You guys should stop to hear yourselves talking about these vibecoded projects. How come they can simultaneously do major rewrites but be completely useless at refactoring and maintaining their own code?
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.)
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.
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.
Earlier metric in late 2024 shows 28%
If he had some experience he'd seen dozens of technologies that were "the future" being thrown away to the dustbin, not even getting any real adoption.
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.
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.
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.)
I hate to cite xkcd 2347, but if those many companies are using a FLOSS project without contributing anything back them they need to put on their big boy pants and stop expecting others to do their work for free.
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.