WTF! it's instantaneous on my system. I think that could be called "slow" if you are continuously installing different versions of node.
So? Are we all supposed to be using your machine? Performance can vary a lot depending on system, filesystem, and workflow. Something feeling “instantaneous” for you doesn’t mean it isn’t sluggish for others, especially when tasks like compiling TypeScript are done frequently, where even small delays add up over time.
What I recognise as problematic it's the support for Windows if you are using WSL, and because of this, I'm thinking of giving a try to mise. I work on a pure Linux dev box, but my team mates work on Windows 11 (some people are masochistic...) and this would help when they need to mess with the frontend code.
Write TypeScript, compile to native code via CLR's NativeAOT. We're almost there, you can see some examples here: https://github.com/tsoniclang/proof-is-in-the-pudding
You get everything; real multithreading, stack allocated types, single binary output (x64, ARM64 for Linux/MacOS) etc.
At what point do JavaScript developers need to realise that this is all convoluted, and begin to use languages better suited for the job.
You want something that can compile into a binary with multiple architectures, multithreading, types, etc? Please use a different language that's built from the ground up to achieve that.
You want something that was designed to add some sugar onto a website? Then yes JavaScript is probably best there.
Not everything needs to be written in this one language that's not designed for it. Just because you can, doesn't mean you should.
For example, JS/TS's file-path based imports are more intuitive; several languages do it via explicit namespaces when well-written code is already organized into directories. Of course, all of these design choices are subjective. In fact, disagreement with a few people in the C# user community is one of the reasons I started this project.
Another example - top level functions, being able to export them trivially etc.
> At what point do JavaScript developers need to realise that this is all convoluted, and begin to use languages better suited for the job.
I'd like to know what makes TS convoluted. Here's an example of multi-threading: https://github.com/tsoniclang/proof-is-in-the-pudding/blob/m...
Speaking of Go, Esbuild is amazing. You can write entire dev servers and build pipelines in a couple hundred lines of Go, with hot reloading etc. Full control over your build process, plugins are compiled with the builder so you don't pay the JS -> Go cost, it's really great stuff. I love Esbuild, thank you Evan :)
On top of this, a lot of JS tools have crazy plugin systems that let you hook into performance-sensitive places and run arbitrary code. This is slow and also makes parallelism tricky. For example, babel plugins can make arbitrary changes to the AST. Ordering them is already kinda tricky; many plugins just give up and run their entire logic as a callback against the root AST node. The fact that swc, esbuild, etc. come batteries-included with transforms for module syntax, Typescript, etc. actually helps with performance; you can leverage assumptions about these fixed sets of transforms to run them all at once and avoid multiple passes over the entire AST.
So rewriting in a language with better ergonomics and being able to ditch some excessive flexibility is what gets you the massive speedup, it's not just magical Rust dust
Yeah, seems NodeJS kind of made some people into JS-zealots, while us web developers have thought of separation of concerns from the beginning, hence the holy trinity of HTML, JS and CSS. Glad others are catching up with web developers for once :)
Reminds me when I was working on distributed filesystem at LiveDrive more than 10 years ago, wrote working prototype and few iterations in Ruby before rewriting it in C - somebody said "(you did it) because Ruby was slow/crap?", I said "no, because Ruby was essential (to do it quick)".
Also interop with those tools (though wasm) is relatively new.
Js/ts ecosystem is actually quite nice now with this option to use wasm for performance - while still keeping "works on the server and in the browser" intact.
- through builds (https://www.npmjs.com/package/@typescript/native-preview), or
- through the editor extension (https://marketplace.visualstudio.com/items?itemName=TypeScri...)
We have several extremely heavy projects (mostly in the functional programming/effect space where you easily get union explosion) that make working even on an M3 max with 8gb per process limit impossible and we get OOM fast (besides compilation times).
Mad props to the team, it's an amazing achievement
We're using tsgo only on the command line btw, we're not using the vscode plugin yet
I'm not sure Go can offer native performance.
The "script" is compiled all the way down to machine code by the runtime, for heavily used paths. The black/white distinction of "scripted" vs. "compiled" does not exist, has not for many years.
Too many of these discussions and arguments seem to be stuck in the 1990s technology level. It is much more mixed and complex now.
"Script" PLs tend to be interpreted, dynamic, and handwave various machine-level details. In contrast, "compiled" PLs usually provide you the constructs to manipulate native machine-level features directly.
Realistically, communities around "script" languages aren't going to talk much about memory layout or syscall. Instead, getting the job done fast (devtime-wise) is their main focus.
On the other hand, "compiled" languages tend to draw people who like squeezing every bit of computing power from their computer, even though it tends to raise the complexity.
What would be the fastest new combo? TS+Svelte+deno? Is there something that replaces vite?
For tools users use, developer experience is important, so they get whatever React and Electron slop we hurl over the fence.
Tale as old as the web.
So yah, no free lunch.
Python is a beautiful beast and its main language is C if you want.
JavaScript has a coming of age. It is not a language anymore but a universal tool to build mainly web apps.
I rarely see any JavaScript die hard fans anymore, we are talking about JAVA like variations like the predominant TypeScript.
And production critical apps need professional treatment and so it goes.
pyridines•3w ago
> Modern JavaScript applications aren't just a few scripts anymore — they're sprawling codebases with thousands of dependencies, complex module graphs, and extensive build pipelines.
This has been true for at least a decade.
The very next paragraph:
> JavaScript-based tools that were once "good enough" now struggle to keep up, leading to sluggish build times, laggy editor experiences, and frustratingly slow feedback loops.
The tools really weren't "good enough", even back then, by these metrics. JavaScript tooling has been slow and bloated on large codebases for just as long.
Blackarea•3w ago
srdjanr•3w ago
vrighter•3w ago
DecoySalamander•3w ago
FridgeSeal•3w ago
/s
Blackarea•3w ago
_heimdall•3w ago
That doesn't work for webapps that are effectively entirely based on client side reactivity like Figma, though the list of projects that need to work like that is extremely low. Even for those style of apps I do wonder how far something like Phoenix LiveView might go towards the end goal.