[flimsypremise]

I don't think the author of this article actually understands the pressures that increasingly drive all frontend development into javascript frameworks, but those pressures are actually very straightforward:

• A large portion of the cost of maintaining a code repository goes toward maintaining the build.

• Multiple builds per repo create significant costs.

• Any web application with a UI _requires_ a frontend build for CSS/JS. Anyone around from the JQuery/pre-SASS days will recall the mess that lack of things like dependency management and ability to control import order caused.

• If the frontend build is already baked into the process, you can save costs by _only_ using a frontend build.

• SPA patterns are the easiest to use with a frontend build, have the most examples/comprehensive documentation.

[deergomoo]

I think the author understands that just fine (I follow him on Mastodon and this is something he is very passionate about). To me his argument is that this shouldn't—and doesn't need to—be the case.

The vast majority of sites out there would be just fine, and in many cases much better, as traditional server-rendered pages with a thin layer of JS on top for enhancements and for islands of interactivity. That massively reduces the complexity and cost of creating and maintaining a build.

Most of us aren't working on anything that requires the entirety of every page and the entire navigation model to be implemented on the client.

[lucsky]

So he's basically publishing a 20 pages philosophical logorrhea to make the simple point that developers should pay more attention to the difference between a web SITE and a web APP and choose their stack accordingly, which is a totally fair point to which I 100% agree with.

What I fail to see is how React is responsible for any of this because this sort of reads like his wife left him for one of the React engineer or some shit.

[flimsypremise]

Building a web application with a UI in a professional context without a frontend build is borderline malpractice. Even a "thin" layer of JS on top requires some degree of dependency management, and I personally have no desire to go back to the days of vanilla CSS, so you need a SASS/SCSS transpiler. Then there's a lot of handy things that frontend builds do, like normalizing SVG icon formats, automatic organization of static assets etc. The fact is the "islands of interactivity" model still requires two builds.

[coddle-hark]

> Any web application with a UI _requires_ a frontend build for CSS/JS.

Except it really doesn't. Core web technologies have gotten so much better since the jQuery/pre-SASS days that you can absolutely get by without a build step.

- http/2 makes bundling a questionable choice

- polyfills are pretty much no longer a thing

- CSS now has most (all?) of the features that people used SASS for (variables, nesting, etc.)

- es6 modules work

This has been a big talking point in the Rails community lately — one of the big selling points of Rails 8 was the fact that you can, by default, ship a whole webapp without a build step, and that this is considered the "happy path".

[flimsypremise]

In web application terms, the "build" is everything that needs to happen to get your application running into production. That means a runtime and dependencies. Speaking of dependencies, does your perfect frontend simply not have any of them? Is every tool you will need to use perfectly packaged with vanilla CSS and ES6 modules? Browser support for import maps is around, but its nothing I would build a production application on. And god help if you if you work in a context that requires support for older browsers.

Maybe in 5 years this will be a practical approach, but there's a reason that old ways of doing thing hang around: they're well-documented and reliable.

[baggy_trough]

I write web apps with UI using ES6 native modules and https://stimulus.hotwired.dev. It's very simple, and life is good. No-build is the way.

[yurishimo]

He works (worked?) for Google. I think he knows what it takes to build a site on a large team and the trade-offs.

[youngtaff]

Works for MS now