I know Bun is kinda not the fan favorite right now with the Anthropic acquisition and the Rust re-write drama and such, but on every one of the dimensions listed in this article, I like Bun better than either Node or Deno.
Bun is awesome. It feels great these days to start with bun or convert a nodejs app over and reduce deps down, sometimes to 0.
Ive just gone all in, no more mega bash scripts that constantly bug out on the silliest problems whenever you try to do anything complex involving a list data type.
It just feels like its something you can pretty much always bend towards what you need without needing to breakout into another language and I'm keen to see some of the new performance stuff their continuing to work on.
Consider it my rpi. I have orange pi rv2 (8GB + 2TB NVME), it's the agentic nest where the harness runs and nfs+dlna archive is hosted. One of the agentic personas has the root. The thing is plugged into the router over Ethernet. It's not the fastest raspberry pi shaped thing on the network, but everything I needed worked without fiddling with FDT and using off-mainline builds. Somehow getting arch port to riscv64 and flashing it to microsd was enough to get things running. It probably even has functioning HDMI, but I'm not sure of that.
Is there any kind of geeky service that lists the range of political views held by the founders of all popular software products? Otherwise, maybe half the software on my computer was made by fascists, and I don't even know it.
For example, Linux — how fascist, communist, or monarchist is it? I'd also be interested to know which NVIDIA drivers are more supportive of the LGBT community—the open-source ones or the proprietary ones?
I had never even thought about this until your comment.
It's useful to know where your software comes from. If something is largely funded by one company, we know it will move in the directions favorable to that company - you can be ready for it to move in a direction that you aren't happy with. If your stance on privacy is "my software should preserve it", perhaps primary developers of that software's association with anti-privacy advocates is worth consideration. This is particularly important in OSS with it's "no guarantees, no warantees, no accountable party" disclaimers - otherwise you might get fucked over when the next release starts doing something you really don't want it to (to extend the example above: e.g. sending all the logs to google or whoever).
> My interest in the Bun JavaScript runtime evaporated when I was informed of Jarred Sumner’s connection to Peter Thiel.
Ok, he doesn't really explain it in your link, but there's another link in that text ... surely that explains it:
>Anyway, I was recently made aware of Sumner’s connection to/fandom of Peter Thiel.
WHAT CONNECTION!?!?!? Did Peter Thiel help him murder someone? Invest $100k in his project? Is he friends with his uncle?
Look I think Thiel is a toxic human being too, but he's a major Siliocn Valley figure: you can't ostracize any project with any association with him, so if you're going to avoid using an entire technology, at least have the decency to say what this giant terrible connection is!
I like Bun too, I think its ergonomics are much better. If you are writing a front end you can produce the final output without an external bundled. Similarly if you are working on a backend TS project (less of a problem these days but transpiling TS used to be full of gotchas depending on your dependencies) . You can even just build a single binary to deploy in your container. Useful for command line tools to (they come out a bit big, but for personal use is not an issue)
Oh look, we’re consolidating again. My only gripe with it was that it wouldn’t directly run Typescript. Other than that it just felt a little ... antiquated.
Bun seems popular too, what would be reasons to choose it?
Bun is much much more lighter than node or deno. If you don't mind the controversy around the rust rewrite, it's objectively the better option in most cases.
A month before the rewrite I was hitting soundness bugs on fairly trivial JS code. I remember right, under HMR re-exports of module variables caused a snapshot and importers of the reexport saw stale values.
I reported it, watched robobun write an unhinged unhinged +300 -0 patch which quickly got LGTM'd and merged.
I hope now that we've moved past AGI and into the ASI era things are better.
I made a fairly straight forward webapp with Bun and let Claude check whether it was actually better than Node. Nope, Node consumed less memory and used about the same CPU as Bun. I didn't switch, because it costs tokens, but Node's reputation seem to be based on its legacy more than on today's use.
You know exactly what it means. You're just being a pedantic ass to someone for whom English is not their first language
Ps to the original poster. I screw things like this up in my 2nd language all the time.
"more" and "-er" are sort of redundant. You could say
More light (but this is just awkward - you'd just say lighter).
Much lighter gives an extra degree of lightness than lighter.
Much much lighter even moreso. There's nothing wrong with saying it like this in an informal context like this, but it would generally be better to use words like significantly, vastly, enormously, slightly, a bit, considerably etc to modify the degree of "lighter"
Any LLM could explain the nuances of all of this in much much more detail (this actually makes sense, because detail is not -er).
English is difficult, but dont let that stop you - it is easy to communicate effectively with even a low degree of proficiency, when the other person is acting in good faith.
im not the person who you initially replied to... But surely it is self-evident what they meant by lighter (even if we dont know precisely what they were referring to) - CPU, ram etc... This is something that is always discussed when it comes to node vs bun vs deno
Well, no. It's not self-evident even in your description of why you think it would be. CPU vs RAM is exactly the kind of distinction that I was trying to delineate. I've been benchmarking heavily lately as I'm working on a library, and anything that heavily depends on Crypto slightly favors Node. Bun admittedly does win on most things like JSON serialization & pure request/second throughput. However, it's just not clear cut enough to say that it is "much, much lighter" categorically.
Node directly runs Typescript now, just not inside libraries (for political reasons not technical ones). It's type stripping approach is the strictest compared to Deno/Bun in that you must turn on a bunch of Typescript linting like Isolated Modules to get it to work and not use enums or namespaces. (Which is in line with the strictness suggested by the Type Annotations TC-39 proposal, for what it is worth.)
haha! Speak for yourself, but software never judges you or cancels on you at the last minute when you're supposed to meet up at the bar. "Friends," sheesh! :)
I wanted Deno to succeed to have a single standardised toolchain, but with Deno having its own APIs you'd effectively have to architect your application to be a "Deno app" and it created two different ecosystems. The best way to make your app portable would be to use the provided Node APIs, cutting a lot of the value from Deno.
I helped Deno bring the Standard Library to v1 [as a contractor] and have always loved the team and philosophy. But these days I’m saddened by what seems to be their slow decline into obscurity. After the layoffs, there seems to be no roadmap, no comms, etc. I’m just so curious as to where they’re heading and still hope the best for it. I’ve always liked Deno more than Node and Bun.
The saddest part is that there have surely been acquisition offers from bigger players that they declined, but given how strongly the market favors the hyperscalers and super-capitalized AI companies an acquisition might’ve been their only sensible play. You either sell or get squeezed out.
JavaScript and TypeScript ecosystem is the stage of celebrities and superstars, and Deno goes the way of a boring technology, it had done many things right (ESM, battery included, all in one development tool) but it lost the spotlight. It leads me think about another technology: Unison, which is a head of the time but... not so many people understand it.
celld is very interesting and I've been following Dahl's posts on X about it. But it is not related directly to deno. The celld repo [1] for example suggests that it is 78.5% Rust.
It is much more of a side-quest and it doesn't answer the question: where is deno going?
There may be use-cases (and the RFC allows ignoring the SHOULD clause with enough reasoning), but GET does not have a request body as per specification, and a LOT of things drop it because of that (most notably - nginx! Also applies to HAProxy and Apache HTTP server afaik, but also a bunch of load balancers)
A body is technically allowed on any http request but it doesn’t mean anything on a get, a server is free to ignore it, anything in the middle is free to strip it, etc.
Enabling the GET implementation to "accept the request body" would literally be the opposite of fixing it. The broken thing here is your expectation. You are looking for POST (or possibly PUT).
You would be surprised how many softwares expect GET with the body.
Perhaps the broken thing might be how you expect existing softwares to break so that your expectation can be satisfied. You should look at GET more closely.
There is a reason curl allows to send GET requests with a body. There is a reason node allows to receive GET requesta with a body.
Technically every http method can have a body? But the specification says the semantics are undefined on get and any compliant implementation is free to ignore it.
Nope. The spec is broken. Hence they were forced to patch the spec with the addition of the QUERY method this year.
Spec is not Bible/Quran requiring religious adherence. If the spec is idiotic, developers have and will circumvent it until either the spec adapts or developers move on abandoning the spec leaving it to rot in the dust.
Why because a bunch of guys in a committee said so? Sorry your committee is broken if they put idiotic ideas out there in the open asking everybody to conform.
But at this point I don't think you would get it. All hail the almighty spec.
I can't speak for any of these other technologies, but no part of the GraphQL spec requires GET requests to have bodies. The spec is clear about how to use query strings instead.
As I have noted elsewhere here in this thread, spec saying one thing has nothing to do with how many libraries implement something. If the libraries are critical and provide value, then no matter how much you scream for your adherence to the spec, people will use it and depend on it.
The QUERY method is a step in the right direction but it came too late.
> This restriction is philosophical rather than technical. I get it though. TypeScript is a Microsoft product. Opening that floodgate would pollute the entire ecosystem.
GH still has its own login system thankfully, and I can't even sign in with Microsoft or link my Linkedin profile in any way (at least from Github.com; I'm sure there's a public Linkedin-developed Github App). I'll take what I can get.
They've been a great steward of GitHub. You people have no perspective. They've kept an insanely generous free tier - free private repos, free CI runners including windows and Mac! And no ads.
I too would have kept it "free" for the LLM learning corpus and the way to nudge developers towards own cloud services and infrastructure. Github Actions is the first obvious deviation from vendor agnosticism here. If it's about "they didn't make profit maximization at all costs a priority" then I agree.
What are you saying? It's not ok for it to be free because they're using that to encourage people to use their paid services? Uhm no shit.
And your comment about LLMs is even sillier. Not only did they buy it 5 years before LLMs became relevant, but there's nothing stopping anyone other than Microsoft from downloading all of GitHub. Look at grep.app for example.
Keep the "shit" to yourself, because I didn't say nor imply that.
> buy it 5 years before LLMs became relevant
GPT-3 is mid 2020, but I doubt the inter-departmental communication would've been strong enough to seriously consider a Github acquisition since 2017?/2018. These decisions take time.
> but there's nothing stopping anyone other than Microsoft from downloading all of GitHub.
Licensing. Not that they care about such details today.
My interpretation of events is as follows: Microsoft pivots to cloud, while strengthening their focus on developers and the ecosystem (like they have once successfully done with Win32 and later tooling & frameworks). VSCode fits this idea. The immediate goal of Github ownership was developer relations and to bring all this mass to orbit the Azure ecosystem. The machine learning trend happened to chronologically come right after. Github Copilot was the first experiment. Today it ought to be one of the major reasons to keep and expand the user base.
> The new deal shows Microsoft doubling down on the strategy of helping individuals and corporate developers adopt open-source software, despite its heritage of distributing products that cost money
That is.....not the way anyone I know would describe Microsoft's history with the open source movement historically.....
With LLMs becoming prevalent, it seems people are “quitting” their projects more quickly. Not necessarily a bad thing, but just shows that the opportunity cost is too high right now if you’re building the wrong thing. Deno isn’t the wrong thing, but LLMs don’t reach for it and that’s a huge blow right now.
"Deno isn’t the wrong thing, but LLMs don’t reach for it and that’s a huge blow right now"
Well, in my case I suddenly had deno installed, while letting run fable in auto mode, even node was already there and I had to look up what deno was. "Ah, that node replacement."
> Deno isn’t the wrong thing, but LLMs don’t reach for it and that’s a huge blow right now.
This only matters if you don't know what you are doing. LLMs can work with any tool. I'm working with a very unconventional stack and the LLM seems right at home.
They were talking from a product/company perspective where if Deno isn’t the default runtime that the LLM chooses for you, you tend to fall into obscurity.
That’s also probably why bun, supabase and netlify have been seeing so many new users, because (at least in my case and unless instructed otherwise), vibe coded projects had a tendency to push me in that direction.
I have a tech stack that I use and yes I tell AI to use it. But if I’m starting a new project and AI is doing the scaffolding, I’ll just let it decide what to use. It uses Bun a lot of the times. Many people will just go with what AI chooses, right or not.
I added a wrapper script around Deno to my agent’s allowlist to take advantage of its permissions system, and instructed it to use Deno instead of Python or bash commands. It’s worked pretty well.
LLMs don't reach for it because the frontier companies don't have it as the default. I've instructed Claude to NOT use React (use SvelteKit), NOT use Node (use Deno or Bun), among other things.
The industry defaults are trash but it is what it is.
Oh man they all reach for the nextjs dumpster fire. Every single vibe coded app is that stack. At least many are backed with supabase (Postgres is a same choice).
I wanted to make a Bukkit plugin for the first time in forever and was mainly using Claude cause I didn't want to figure out how the library jar linking works again. It kept reaching for Maven, I told it no just give me a build.sh that uses the JDK only, it pushed back, I said NO, then it did it. The resulting script was pretty simple too.
Same. The Gradle setup it was making was insanely complicated, then the Gradle-free script I forced it to make was very simple. There's no way I would've used Gradle without the LLM either.
Maven does not properly do the job for kotlin projects. The Kotlin ecosystem and all of its plugins are very much gradle focused. You have to do bizarre things in maven to get them to behave properly.
This is part of how LLMs are hurting progress. People are moved away from things like StackOverflow or new projects where they pose and answer questions with real people, or create novel things, and pushed more and more to whatever answers or solutions the LLMs will spit out for them.
Please excuse my language, but that's only the case if you're a complete imbecile and can't write a for loop to save your life.
An LLM doesn't "reach" for anything, because you tell it what to do. You go "use this tool, to do that thing, in this way, here's a bunch of written guidance on how exactly to do that, and if you run into issues ask me". Any other use is glorified copy-paste slop code and will end up with a worse codebase than if you let an egomaniac run amok on a single codebase for 20 years.
You are ignoring that prompting is fractal all the way down to the scale where the human writes everything by hand.
If I say, "start a C++ package skeleton" I'm getting CMake, not waf, make, bjam, or whatever. If I state the build system, then I'm still getting some package layout drawn from the training distribution. If I specify that, I'm still getting snake_case or CamelCase or whatever naming convention, drawn from the training distribution. If I specify that, etc etc.
I just throw Deno into my agents file and it gets installed in whatever environment I'm working in.
However, the truth is that writing isomorphic javascript programs in the age of agentic coding is much less important to me than it was a few years ago.
I wonder what the future of all three is mode bun and deno, their original goal has always been to be able to code in one language across frontend and backend, and typescript itself is a hell of a good language too.
But now that people seldom even look at the code, does it even matter? Our shared language now is English - across tests, frontend, backend, product briefs and design systems.
I have written a crap ton of node code before, because I liked it, but now I do everything in specialized stacks where each tech is chosen to best fit its environment. Backend - use Go, frontend - react/svelte/custom ,game simulation code - C#.
I just debate what would be best fit with an agent, do a few pilots to prove it and just go. Languages I’ve never coded in are super fast to execute - just insist on following best practice, modern conventions and do some spot checks against o(n) problems, architecture and parallelism - and it works, and vibe coded codebase with strict linting rules vastly outperforms fine tuned code in a shared language (node).
I honestly don’t see a bright future for them, and tbh I was surprised at Claude’s migration _to_ bun - why not just make the jump to something like ocamel that would let their agents have even more performance, context and linting tools, but I guess if they did it once the will do it again when they feel like it.
> Why? Just strip the types bro, I know you can! Let me sign a deal with the devil!
> This restriction is philosophical rather than technical. I get it though. TypeScript is a Microsoft product. Opening that floodgate would pollute the entire ecosystem. Nobody wants more Microsoft.
The reason Node disallows this has nothing to do with TypeScript being owned by Microsoft, it's because there's no guarantee the TSConfig settings used in the library you're pulling in match the ones in your project. A mismatch would mean you would get type errors inside the library code (assuming you're doing some form of type-checking in your application, otherwise what's the point of even using TypeScript).
> No TypeScript packages mean I need to find the latest churnware slop to bundle my stuff.
There are other advantages to bundling, but it's not strictly necessary if all you care about is publishing TS on NPM. Declaration files solve the problem by supplying the resolved types of the publicly exposed identifiers. Also has the added advantage of not locking out plain JS consumers.
Yes, but your TypeScript code has to be checked against the libraries in node_modules, and it is significantly costlier to check against implementation files (the .ts/.mts files) than the produced declaration files (the .d.ts files).
Type stripping can and does ignore tsconfig.json files, from the provided link:
> Node.js ignores tsconfig.json files and therefore features that depend on settings within tsconfig.json, such as paths or converting newer JavaScript syntax to older standards, are intentionally unsupported.
Of course import alias and such features would break.
Turns out the 'boring enterprise runtime' spent its time actually shipping stability while everyone else was chasing the next shiny runtime hype cycle.
It's great that they developed alternatives to Node, I was just getting annoyed with all the users trying to bait in more users like "why don't you use [Deno/Bun], it's completely compatible" when it's not. Same with all the Python interpreters besides CPython.
The ones that actually care about JIT in the box are attractive because of that, thankfully CPython is finally taking having a JIT in the box seriously.
That and other advantages. Some of them had freethreading earlier. Some were just faster. But they aren't 100% compatible with CPython, even if you don't use any libraries with C bindings.
Deno is still an easy pick for me because of its built-in test-runner (deno test), linter (deno lint), and type checker (deno check). I've used many different npm packages for these things in previous projects and I have no idea what the new hotness and proper configuration is for all of these things in a new node project, so I really value the simplicity of Deno for it all. Also JSR and Deno for publishing Typescript libraries is still so much easier than setting up a Typescript node project.
Honestly I forget now, as I first played around with it months? years? ago when it was pretty new.
But one thing that stood out was .only(). In every major testing framework IT'S ASSUMED the dev is going to want to run one test at a time (sometimes). They make it super simple: you throw a ".only()" on the test, and the test runner only runs it.
In Node, you instead need to pass some special command line flag or add .only to every describe above the test ... which just makes a basic operation (run one test) much harder than it needs to be ... for zero benefit whatsoever (again, just do it the way every other test runner does it).
The new hot lint (for me) is Oxlint. Literally a 300x speed improvement on our monorepo compared to eslint for the same ruleset. It’s amazing, especially in combination with Oxfmt instead of prettier.
While I'm at it, I forgot to mention the built-in formatter (deno fmt) is great too. I use Prettier in other projects and it's also great in those projects, but it's tiring that it's yet another dependency to remember to add and configure in a new node project.
I am not sure about deno not being innovative - I've recently started using deno for it's new desktop app support only (https://docs.deno.com/runtime/desktop/)
The thing with being around for a while is the ability to seat on the porch, watching the adventurers' caravans pass by, once upon a traveller in one of those, now only the ones that actually make the way back into town matter to actually have a second look and talk to the strangers.
It's great that we now have 3 major JS server environments: Node.js, Deno and Bun. The competition keeps them all in check.
Although I was keen to get involved in Deno in the beginning and I'm a fan of Ryan Dahl, I just couldn't shake my preference for vanilla JavaScript; it was already the case before LLMs took over, but now even more so after LLMs.
That said, Deno deserves the credit for making TypeScript as painless as possible. Juggling different Node.js and tsc versions and tsconfig versions was a major pain in the neck. I like how Deno forces a specific TypeScript version.
TypeScript is, objectively, the superior option—especially in the presence of LLMs, because the type safety is incredibly useful as a first-line eval to ensure that what the LLM spits out is sound in terms of data inputs and outputs. Strong static typing is an absolute must for building anything bigger than trivial systems.
In casual convo, I often hear strong typing conflated with static typing. Its generally fine unless im being pedantic for sport. Typescript has a stronger typing system than javascript, but depending on your audience, some might not consider typescript a strongly typed language because of things like `any`, type assertions, and lack of runtime guarantees to name a few
Structural typing versus nominal typing is another one that often upsets "strong type" fans, because structural typing looks weak (but is still stronger than "no typing").
I don't know what kind of LLMs you're using but mine have never once in 6 months got the type incorrect; neither with JavaScript nor TypeScript. So what's the point of type safety if it never gets the type wrong?
All the LLM issues I face are related to incorrect priorities, choosing the wrong tradeoffs, UX and UI flaws or incorrect assumption about requirements.
Why would I want to fill up my context window with useless type annotations and waste tokens generating them?
Also, I don't want my LLM to generate over-engineered enterprise code. My priority is to get stuff done, not achieve job security.
As a casual both Bun and Deno user, I have generally preferred Bun to Deno unless sandboxing is a concern.
I'm not quite sure I've seen a runtime, JavaScript or otherwise, that has the same network-level gating that deno enforces. Making an allowlist of addresses the default seems like it needs to be table stakes in the agentic era.
> There is no reason to use the Deno runtime today.
LMAO okay bro.
With Deno I get TypeScript by default, security, a package manager that isn't riddled with nonsense and a dated UI, and I can compile my APIs to a single executable. No way am I going back to Node but then again, this ain't my blog post.
252 comments
[ 1.8 ms ] story [ 91.2 ms ] threadIve just gone all in, no more mega bash scripts that constantly bug out on the silliest problems whenever you try to do anything complex involving a list data type.
It just feels like its something you can pretty much always bend towards what you need without needing to breakout into another language and I'm keen to see some of the new performance stuff their continuing to work on.
i'm very interested in RISC-V and would love to read anything you can provide.
Thanks!
https://dbushell.com/notes/2025-09-10T12:08Z/
For example, Linux — how fascist, communist, or monarchist is it? I'd also be interested to know which NVIDIA drivers are more supportive of the LGBT community—the open-source ones or the proprietary ones?
I had never even thought about this until your comment.
> My interest in the Bun JavaScript runtime evaporated when I was informed of Jarred Sumner’s connection to Peter Thiel.
Ok, he doesn't really explain it in your link, but there's another link in that text ... surely that explains it:
>Anyway, I was recently made aware of Sumner’s connection to/fandom of Peter Thiel.
WHAT CONNECTION!?!?!? Did Peter Thiel help him murder someone? Invest $100k in his project? Is he friends with his uncle?
Look I think Thiel is a toxic human being too, but he's a major Siliocn Valley figure: you can't ostracize any project with any association with him, so if you're going to avoid using an entire technology, at least have the decency to say what this giant terrible connection is!
Bun seems popular too, what would be reasons to choose it?
I reported it, watched robobun write an unhinged unhinged +300 -0 patch which quickly got LGTM'd and merged.
I hope now that we've moved past AGI and into the ASI era things are better.
Ps to the original poster. I screw things like this up in my 2nd language all the time.
"more" and "-er" are sort of redundant. You could say
More light (but this is just awkward - you'd just say lighter).
Much lighter gives an extra degree of lightness than lighter.
Much much lighter even moreso. There's nothing wrong with saying it like this in an informal context like this, but it would generally be better to use words like significantly, vastly, enormously, slightly, a bit, considerably etc to modify the degree of "lighter"
Any LLM could explain the nuances of all of this in much much more detail (this actually makes sense, because detail is not -er).
English is difficult, but dont let that stop you - it is easy to communicate effectively with even a low degree of proficiency, when the other person is acting in good faith.
1. people choosing the ai companion for the frictionless relationship
2. people losing the skills needed for real life human relatioships
https://x.com/rough__sea/status/2105853283617440032
https://youtu.be/G-v1hkQ8Sf8
https://github.com/stars/patcon/lists/awesome-celld
I get the sense that they'd just been brewing things around durable objects, and I'm excited for it coming to fruition
It is much more of a side-quest and it doesn't answer the question: where is deno going?
1. https://github.com/denoland/celld
Bun was promising, but as long as they don't fix their http GET implementation to accept the request body, its broken for me.
Hint: Elasticsearch, GraphQL, Axios, etc..
Spec is not the same as compatibility.
You should use bun :)
Perhaps the broken thing might be how you expect existing softwares to break so that your expectation can be satisfied. You should look at GET more closely.
There is a reason curl allows to send GET requests with a body. There is a reason node allows to receive GET requesta with a body.
I understand why you'd want it, and that's why RFC10008 introduces QUERY as a GET-with-body alternative.
What is the use of spec adherence if it leads to unusable/broken applications.
Spec is not Bible/Quran requiring religious adherence. If the spec is idiotic, developers have and will circumvent it until either the spec adapts or developers move on abandoning the spec leaving it to rot in the dust.
Why because a bunch of guys in a committee said so? Sorry your committee is broken if they put idiotic ideas out there in the open asking everybody to conform.
But at this point I don't think you would get it. All hail the almighty spec.
Sticking to RFC is one thing. Advertising as node compatible is completely different altogether. Many people cannot see the difference.
Atleast a flag would suffice as that would ensure existing infrastructure tooling doesn't break while keeping the RFC spec folks happy.
https://github.com/graphql/graphql-over-http/blob/main/spec/...
The QUERY method is a step in the right direction but it came too late.
Bad news (well not news, this happened a while ago): https://www.cnbc.com/amp/2020/03/16/microsoft-github-agrees-...
Name one other company that would do that.
And your comment about LLMs is even sillier. Not only did they buy it 5 years before LLMs became relevant, but there's nothing stopping anyone other than Microsoft from downloading all of GitHub. Look at grep.app for example.
Keep the "shit" to yourself, because I didn't say nor imply that.
> buy it 5 years before LLMs became relevant
GPT-3 is mid 2020, but I doubt the inter-departmental communication would've been strong enough to seriously consider a Github acquisition since 2017?/2018. These decisions take time.
> but there's nothing stopping anyone other than Microsoft from downloading all of GitHub.
Licensing. Not that they care about such details today.
My interpretation of events is as follows: Microsoft pivots to cloud, while strengthening their focus on developers and the ecosystem (like they have once successfully done with Win32 and later tooling & frameworks). VSCode fits this idea. The immediate goal of Github ownership was developer relations and to bring all this mass to orbit the Azure ecosystem. The machine learning trend happened to chronologically come right after. Github Copilot was the first experiment. Today it ought to be one of the major reasons to keep and expand the user base.
https://forums.theregister.com/forum/all/2019/05/24/github_i...
That is.....not the way anyone I know would describe Microsoft's history with the open source movement historically.....
Well, in my case I suddenly had deno installed, while letting run fable in auto mode, even node was already there and I had to look up what deno was. "Ah, that node replacement."
This only matters if you don't know what you are doing. LLMs can work with any tool. I'm working with a very unconventional stack and the LLM seems right at home.
That’s also probably why bun, supabase and netlify have been seeing so many new users, because (at least in my case and unless instructed otherwise), vibe coded projects had a tendency to push me in that direction.
The industry defaults are trash but it is what it is.
Please excuse my language, but that's only the case if you're a complete imbecile and can't write a for loop to save your life.
An LLM doesn't "reach" for anything, because you tell it what to do. You go "use this tool, to do that thing, in this way, here's a bunch of written guidance on how exactly to do that, and if you run into issues ask me". Any other use is glorified copy-paste slop code and will end up with a worse codebase than if you let an egomaniac run amok on a single codebase for 20 years.
If I say, "start a C++ package skeleton" I'm getting CMake, not waf, make, bjam, or whatever. If I state the build system, then I'm still getting some package layout drawn from the training distribution. If I specify that, I'm still getting snake_case or CamelCase or whatever naming convention, drawn from the training distribution. If I specify that, etc etc.
It is distribution sampling all the way down.
So, yes, literally LLMs ARE reaching for "it".
However, the truth is that writing isomorphic javascript programs in the age of agentic coding is much less important to me than it was a few years ago.
But now that people seldom even look at the code, does it even matter? Our shared language now is English - across tests, frontend, backend, product briefs and design systems.
I have written a crap ton of node code before, because I liked it, but now I do everything in specialized stacks where each tech is chosen to best fit its environment. Backend - use Go, frontend - react/svelte/custom ,game simulation code - C#.
I just debate what would be best fit with an agent, do a few pilots to prove it and just go. Languages I’ve never coded in are super fast to execute - just insist on following best practice, modern conventions and do some spot checks against o(n) problems, architecture and parallelism - and it works, and vibe coded codebase with strict linting rules vastly outperforms fine tuned code in a shared language (node).
I honestly don’t see a bright future for them, and tbh I was surprised at Claude’s migration _to_ bun - why not just make the jump to something like ocamel that would let their agents have even more performance, context and linting tools, but I guess if they did it once the will do it again when they feel like it.
> This restriction is philosophical rather than technical. I get it though. TypeScript is a Microsoft product. Opening that floodgate would pollute the entire ecosystem. Nobody wants more Microsoft.
The reason Node disallows this has nothing to do with TypeScript being owned by Microsoft, it's because there's no guarantee the TSConfig settings used in the library you're pulling in match the ones in your project. A mismatch would mean you would get type errors inside the library code (assuming you're doing some form of type-checking in your application, otherwise what's the point of even using TypeScript).
> No TypeScript packages mean I need to find the latest churnware slop to bundle my stuff.
The TypeScript compiler itself comes with everything you need for this. See: https://www.typescriptlang.org/tsconfig/#declaration
There are other advantages to bundling, but it's not strictly necessary if all you care about is publishing TS on NPM. Declaration files solve the problem by supplying the resolved types of the publicly exposed identifiers. Also has the added advantage of not locking out plain JS consumers.
OP doesn't want the types to be checked, they want the types to be stripped. Type stripping ignores tsconfig.json files and any of its features, see: https://nodejs.org/api/typescript.html#type-stripping
OP is talking about type stripping nonetheless, and I'd put type stripping into the same ballpark as reading ambient declarations, performance wise.
TypeScript has different semantics depending on settings in tsconfig e.g. useDefineForClassFields
> Node.js ignores tsconfig.json files and therefore features that depend on settings within tsconfig.json, such as paths or converting newer JavaScript syntax to older standards, are intentionally unsupported.
Of course import alias and such features would break.
You'd think unit testing would be the most already-solved problem in the world: just copy what Jest, Mocha, Vitest, etc. do ... and you're done.
Instead they left out major features and implemented other features in really strange "why are you reinventing the wheel" ways :(
But one thing that stood out was .only(). In every major testing framework IT'S ASSUMED the dev is going to want to run one test at a time (sometimes). They make it super simple: you throw a ".only()" on the test, and the test runner only runs it.
In Node, you instead need to pass some special command line flag or add .only to every describe above the test ... which just makes a basic operation (run one test) much harder than it needs to be ... for zero benefit whatsoever (again, just do it the way every other test runner does it).
Not sure if the runtime should be responsible for linting of type checking.
but some AI projects have been using deno desktop to run python via pyodide locally, I couldn't complain since it's like a sandbox to them
The thing with being around for a while is the ability to seat on the porch, watching the adventurers' caravans pass by, once upon a traveller in one of those, now only the ones that actually make the way back into town matter to actually have a second look and talk to the strangers.
Although I was keen to get involved in Deno in the beginning and I'm a fan of Ryan Dahl, I just couldn't shake my preference for vanilla JavaScript; it was already the case before LLMs took over, but now even more so after LLMs.
That said, Deno deserves the credit for making TypeScript as painless as possible. Juggling different Node.js and tsc versions and tsconfig versions was a major pain in the neck. I like how Deno forces a specific TypeScript version.
I was under the impression that TypeScript is only statically typed, not strongly typed, too. Am I mistaken?
All the LLM issues I face are related to incorrect priorities, choosing the wrong tradeoffs, UX and UI flaws or incorrect assumption about requirements.
Why would I want to fill up my context window with useless type annotations and waste tokens generating them?
Also, I don't want my LLM to generate over-engineered enterprise code. My priority is to get stuff done, not achieve job security.
I'm not quite sure I've seen a runtime, JavaScript or otherwise, that has the same network-level gating that deno enforces. Making an allowlist of addresses the default seems like it needs to be table stakes in the agentic era.
LMAO okay bro.
With Deno I get TypeScript by default, security, a package manager that isn't riddled with nonsense and a dated UI, and I can compile my APIs to a single executable. No way am I going back to Node but then again, this ain't my blog post.
"deny access to ~/.ssh and other important folders" --> that alone would likely have 99.99999% sterilized most "hacks"
... but then again, I haven't even really used the term "leet" much (let alone spelling it with numbers) since high school.