I’ve been doing it professionally for 20 years, and I agree. Modern front end development with TypeScript, Vite, Preact, and even the much maligned npm are so much better than anything that preceded them for building complex front end applications.
I like having a build step for code that I write. I build C, I build Go, I build C#. I don’t ship debug builds of those things.
I don’t know why I’d want to forego all of the niceties that a modern TS build brings and also ship what is essentially a debug build of JS to the browser.
Sure, for a really simple web page, I’ll just slap a script together. But for anything real, hell yes, give me a good build mechanism.
I think the difference lies is how pleasant the tooling/build process are. In the case of C, Go, C#, and other non-web languages, there are comparatively few gripes — the most common being “building takes a long time” with Rust and Swift for example, which is a fairly mild problem. The negative parts of the experience for these languages more often than not get fixed.
With JS, it seems like many of the negatives are much more sticky and refuse to go away. Not sure why. Perhaps it’s related to how that ecosystem has a tendency towards cyclical reinvention of the upper layers while foundational/structural issues get considerably less attention, and so they get swept under the rug more often than they’re fixed, leading them to rear their heads every so often to remind everybody of their existence.
> I think the difference lies is how pleasant the tooling/build process are.
> With JS, it seems like many of the negatives are much more sticky and refuse to go away. Not sure why.
Spot on. I think there is a quality/cultural problem around the javascript ecosystem, but I'm also not sure why it persists. If I had to hazard a guess, I suspect that it has to do with what javascript programmers are usually trying to build. Those things are mostly visual, and the audience cannot see the quality or lack thereof easily, and outputs do not often live long. These incentives steer people to create fast and not worry so much about the soundness, sustainability, or longevity of their solutions.
I made a comment to a colleague recently that javascript tooling is a 'labyrinth of complexity'. That is my main gripe with all of the 'stuff' that comes with the front end. It all feels overcomplicated and thrown together.
While you may like having a build step, it is not necessary and some people don't like it. I've been building commercial data warehouse apps for >30 years and am very happy that our apps don't have a build step. Current app is a multi-million dollar Fortune 500 client app. No build step.
> $ echo '{}' > package.json && npm i --save-dev typescript vite preact
> added 17 packages, and audited 18 packages in 1s
You're off by two orders of magnitude. I get not wanting a lot of transitive dependencies, but you can get a modern toolchain without having a lot of transitive dependencies.
And you can go even smaller if you're fine with a slightly less user friendly (but still modern, and also very fast) build tool that's used at the core of Vite:
Webpack is the real offender and while vite is cool it isn't really a replacement for the decade or so standard, and looks like it requires a semi modern browser.
I'll probably try it out some time for a home project, but for anything serious it's a no go.
Perhaps, but JS tooling is waaaay better than it used to be.
Vite and Turbopack are way easier to use than Webpack, and faster than the next best thing, Parcel.
npm supports lockfiles. Yarn goes further in that you no longer need a million files in node_modules; or pnpm uses hard links to prevent duplication.
That said, typechecking Typescript is unfortunately slow. esbuild (as used by Vite) can strip out type signatures quickly, but can't check them. Rescript is very fast, but is a very different language than TypeScript or JavaScript, namely ML with braces.
The person I was responding to wrote "Modern front end development with TypeScript, Vite, Preact, and even the much maligned npm are so much better than anything that preceded them for building complex front end applications." which implies that modern front end is an improvement over what previously existed.
That person then wrote "But for anything real, hell yes, give me a good build mechanism." which implies that he creates real, high quality applications.
But my experience is that all front end web applications are all sub-par, so it doesn't really matter if a SPA uses a bundler or not, it doesn't affect quality when it is all shit anyway. So more power to the guy who decides to not use the bundler.
In the end, I agree with Alan Kay, the web was created by a bunch of amateurs
Figma and Discord come to mind as being exceptionally well implemented front end applications. They're even more HN-friendly because they both use Rust for performance-critical code.
I like having a build step for code that I write. I build C, I build Go, I build C#. I don’t ship debug builds of those things.
I don’t know why I’d want to forego all of the niceties that a modern TS build brings and also ship what is essentially a debug build of JS to the browser.
Sure, for a really simple web page, I’ll just slap a script together. But for anything real, hell yes, give me a good build mechanism.