I tried to use kmscon before, and it does work nice and is much faster. But, I can only have one app that is using DRM, i.e., I cannot start console/DRM image viewer from such terminal, or mpv, etc. That is a deal breaker and issue for me.
I have no idea anymore what is happening, and none of the blogposts seem to explain that either. So, if I am to start a new JS or TypeScript project or whatever, what should I choose and why? One runtime used a lot of tokens to rewrite Zig project, one was already Rust, one bought, one rewritten in Go, what is going on?
You should choose Node.js unless you have a good reason to use something else. This is what everyone uses, and it is used widely enough that it's in the same position as Java, i.e. it will be supported forever.
Also the other runtimes only offer incremental improvements.
Regarding the blogposts, you don't read a lot about Node.js because it is mature software and there isn't a lot of drama or new things to talk about.
One was not rewritten in Go. Typescript rewrote its compiler in Go, but that doesn't affect which runtime you use for the resulting Javascript code. Moreover this isn't producing a fork in Typescript as it is a replacement for the previous compiler, at least once they're done with it. The JS runtime forks and churn are not related to Typescript per se.
Yeah, after I posted I realized that Go remark was not correct, but again, I am confused how do you combine all that. JS I can read and understand (well, understand), I have seen it already, TS, I compile TS to JS right, and then I can choose any of the current available runtimes to run that code, correct? And final fat binary that is deployed has what, whatever runtime I choose to be?
Huh, I think I guessed that right, I do use such apps, but never bothered to understand how they are actually packed.
> Typescript rewrote its compiler in Go, but that doesn't affect which runtime you use for the resulting Javascript code.
It unfortunately has other implications, ts-loader (used by webpack) for example is not compatible with the new Go crap so you need to do weird pinning down to v6 to get your builds working again [1].
Yes, everything I have is pinned that way too. That's why I said "when it is done", even in my limited experience and contact with TS it is not currently a suitable replacement, and I'm not a particularly hard user of the tool chain. (I am having a hard time phrasing this in a way that I'm completely sure can't be potentially read as snarky or short-tempered, so I guess I'll just go with the clumsy direct statement that I'm agreeing with you and continuing the thought from my own experience, not trying to disagree.)
As near as I can see, it isn't anything fundamental to the rewrite, it's just a transitional phase, though.
Well, that "Go crap" needs some explanation. The reason I am not involved in JS is because I mostly use Go for backend, and I am happy I have no relation with frontend at all. And even that is just small part of my job and what I do daily (Radius, Diameter, etc.).
But, I never heard about Go crap (in that context maybe), or experienced any crap there, it is just nice and simple. What are the issues?
Many of the "rewrite it in Rust/Go/whatever fad" projects that have cropped up have been done with the assistance of AI, especially because both languages are a pretty heavy divergence if you're used to C, C++, Java or JavaScript.
And when you can't manage to coordinate with an ecosystem dependency as large as webpack before the migration to make sure nothing breaks... my suspicion is utter incompetence and gross misuse of AI.
"which runtime" is a separate discussion from "which package manager"; there's nothing in Node requiring you to use npm (or to rely on external dependencies at all)
> So, if I am to start a new JS or TypeScript project or whatever, what should I choose and why?
NodeJS for the runtime if it's not in a browser, webpack for bundling. For the frontend stack, either React if you're in for a full application or, fuck it, good old jQuery if you don't want to do type document.queryXXX all the time. You'll find a ton of developers and coding bootcamp graduates to deal with all of that, and the AI agents should all be trained well enough on them.
Everything else is just a recipe for getting rug-pulled or being the bananaware customer responsible for the ripening.
I'd throw out webpack and start with unbundled ESM today. Vendor bundle and spot bundle with esbuild or rollup or something else designed for native ESM bundling and just ESM bundling, and only where you see actual performance bottlenecks (visible request waterfalls). Use any friction you see as an excuse to replace/drop old CommonJS dependencies entirely.
Webpack had its day, but today its kitchen sink and incredibly baroque configurations are as much a liability as a helpful place to start on a project. Start fresh with ESM and without a bundler and things are surprisingly nice in development experience.
I don't choose TS/JS for new projects anymore unless they're browser based. If you need to be in JS land for whatever reason, deploy with Node but do local package management/testing with Bun, because it's way faster for those and you can migrate off without too much pain if it ever becomes problematic.
While it may as well be the same thing, the Anthropic acquisition isn't what turned me off of Bun, it was the vibe-coded Rust refactor. As soon as that happened I dropped Bun. Deno was what I ended up more interested in (Deno Fresh seemed really cool too), but I guess it's just back to Node/PNPM for me now as well. What is going on anymore...
Yeah same for me actually, I mentioned the acquisition more as a temporal cue than an actual reason, even though they are strictly related in the end: Anthropic acquires Bun to prove their argument, that they have the most awesome LLM technology that can rewrite such a complex product from Zig to Rust for $reasons.
I also believe, like others here, that Bun future is also not safe, Anthropic might decide to kill it as soon as they believe it doesn't bring in any more value.
Bun's being a part of Anthropic is just as concerning, if not more so. At least Cloudflare is being honest here that they have no idea continuing Deno support long term. Anthropic's first role in Bun was treating it as a playground to migrate from Zig to Rust using as many LLM tokens as they wished in the process. That's not exactly the sign of a steward with long term maintenance in mind.
Bun's rewrite has been a massive success, unprecedented even.
The amount of new features they are coming up with, the speed of development has been even faster than before.
We have not seen any indications so far Anthropic messing with Bun's direction. It was always Jarred deciding what to do and it is still the same. So far Anthropic has left Bun alone and they are just reaping benefits of bun getting faster and faster.
I see that as a long term benefit. Not a negative.
Bun is dead. It's a skin-walker wearing the appearance of its former self. They screwed the community when they got acquired.
Deno has been successful, technically better and a respectably run project. I expect it may survive in the form of modular runtime and associated features.
Every company that is using Bun is getting so much more perf benefits — faster and less memory used; also less crashes/bugs. New features are dropping rapidly. All those naysayers about rust port will be littered with bugs and unmaintainable crap are already proven wrong. So now you just call it dead. nice.
If Deno and Bun were not kicking NodeJS's behind, we'd not see any of the improvements in the ecosystem in last few years. Node has been stagnant for a long time.
If you want to use TS stripping for your own project the typescript ecosystem makes it very easy to avoid using the wrong features. Just set erasableSyntaxOnly and verbatimModuleSyntax to true in your tsconfig.json and you will be warned when you're doing something node would not be able to handle. These days I find more code is being written to be stripping friendly than not, the incompatible stuff is of little importance besides enum for which you could resort to an as const object or a string union. I consider the presence of such things a smell, the TS dev team considers things like enums to have been a mistake, the goal of TS is to remain minimally divergent with JS outside of the type annotations.
Well, it does technically in that to "run TypeScript" all you have to do is strip the types, and execute the remaining JavaScript. This is what Node does, but it doesn't do any typechecking. You can always include TypeScript as a dependency to do the actual type checking for you.
Deno from my understanding included a version of the TypeScript compiler as part of its build. Node doesn't do this. I'm not sure what Bun does, but I wouldn't trust it for anything more than a hobby project.
>I thought the latest versions ran actual typescript.
That's by design. Deno smoothly hides the fact that TS needs to be converted to JS for V8 to run it. Similar to how it smoothly hides everything about npm.
Well, not really DOS, but company where I did migration (15+ years ago) from 4GL and AIX to Linux and Aubit 4GL did exactly that. They all used HyperTerminal (after me, putty) to connect and start all sorts of apps, think, SQL AND UI at the same time, terminal apps, with keyboard shortcuts that MUST be exactly the same, otherwise you would have mutiny.
They are sold a few years ago, new owner just needs a good (and huge) location in the city, if they continued, nothing would change for people working there. They saw Windows as something just for minesweeper and solitaire, nothing else.
My travel agent wife was unhappy when they GUIfied Sabre. Luckily there was enough complaints they brought back some terminal access/shortcuts for the ‘advanced’ users…
My perfect mail client would be something that does not use a browser to show the HTML emails at all. And would need to have text-only option I can enable. And for HTML emails, I would prefer something like html to markdown, that markdown can be mapped to native UI toolkits, they all have some "rich" text support.
I did that in my IUP fork, bold, italic, headings, link, image, table, that can all be mapped to native text widget, can load and save markdown from that.Will it look as intended, no, but, do not create websites when you send emails and everything will be fine.
Well, it is what was always considered to be a default toolkit. Sure, I like Qt and prefer such apps but you got a have the GTK installed anyway. It was always difficult to have general toolkit with it when you depend on dozens of dependencies, collection of libraries, not big fat libraries like in Qt, that you can deploy.
GTK4 changed a lot though, like they do not even try anymore, deprecated font dialog because that is better done with XDG portals, but such thing does not even exist. How will that work on macOS and Windows, it cannot? Or what they did with the menus. Toolkits should be user oriented and should not have vision, it just needs to work and provide controls, events, etc., you cannot even position windows in macOS and Windows with GTK4, that is not toolkit that works for users.
I am working on the IUP fork here https://github.com/gen2brain/iup-go , one toolkit to handle them all, and I did my best for GTK4 backend, but from 14 drivers/backends I worked on, it was the worst experience and I had to fight battles with it.
GTK2 tried to be more general-purpose, while GTK4 is more about serving the vision of Gnome the platform.
I hope that, if desktop / laptop as a platform remains, there will appear an interpreted, platform-independent toolkit / language for GUI specifically, along the lines of Tk, or QML, but much lighter weight than HTML+CSS.
I work on the IUP fork, where I have and support the Qt driver, which works with both Qt5 and Qt6, and I only need a couple of checks to make it work on both. I often check if I broke the Qt5 build; nope, all good there, hard to break. For GTK3 and GTK4, those must be separate drivers; there's no way you can handle that with a couple of checks. Everything is different. That was possible to some extent and works with GTK2/GTK3 (single driver), but there are so many checks and workarounds there. Qt is so nice to work with.
reply