> The opposite is true.

Kind of.

A lot of the apps I work with have front-ends developed by one team, and those rely on back-ends developed by one or more teams. Serving server-rendered HTML is not a great option in this case (as much as I loved the "3270 way" of 1990's web). As client-side complexity increases, it starts to pay off to build on foundations that add more functionality, such as React, Vue or Angular, the same way some teams will prefer TypeScript over vanilla JavaScript. Adopting a well known framework makes easier to onboard new team members, as nomenclature and organization are already known to them. And, while we are at it, the team in charge of the visual representation will appreciate ways to better organize their CSS files, and, if possible, just serve a single CSS assembled from a set of files with definitions organized by subject or function. A build step allows an application to be served with files that define only the functionality needed, leaving most of the framework behind.

Not all web applications require it, of course, but I wouldn't say the expectation is to build a web application with bare HTLM/CSS/JS.

Also a web developer of 20 years. Used to use PHP to write old-school server-side webapps a bunch. When I first started things were just transitioning to PHP 5 as I recall. Exciting times.

Honestly, what confuses me the most is that looking at the codebase FTA it just looks like a modern webapp codebase (albeit a small one) except without TypeScript. I don't really see the point in this case. It was one thing when tooling really sucked, but we're past the Webpack days: you can setup Vite in a minute and have a really nice and very fast bundled workflow out of the box. Nowadays the performance critical bits of bundlers are written typically in Go or Rust and decently optimized, so it's not like it takes a ton of memory or CPU time to bundle a modern app, especially one that is fairly small.

There's really nothing wrong with rawdogging HTML/CSS/JS like the old days, I've certainly done it from time to time, but in this case it doesn't really look like the outcome is much different. If you're going to write a client-heavy app in a style that works perfectly well with modern tools, why not use the tools? If you don't like them, you can always get rid of them later. You can always strip out the TypeScript types and remove any reliance on bundler features and ship it as normal ES modules. It's really not hard at all, the reason why people don't do it is lack of obvious benefit.

There's some middle ground between "only dev tool is Notepad" and "hello welcome to my Vite + TypeScript + ESLint + Prettier + Svelte + SvelteKit + tRPC + Y.js + leftpad starter pack", you could always just choose the high-impact tools that help improve the code and the resulting application experience and be very deliberate about what you depend on.

I read the article but I still don't entirely understand the point. (There's a focus on "not using JS the browser doesn't understand" but also, you don't have to? Browsers now understand ES Modules and async and most other modern features even going back a few years. Even Ladybird Browser has little trouble with any of the modern features I care about!)

> "Experimenting" with no-build web apps makes it sound like web apps require build steps by default. The opposite is true.

It's not that it's required per se, just that when it seems like most people use applications with a build step, experimenting is the right word to use when going the other way, even if it is the default. It might even be the case that the author hasn't made apps without a build step so again in their case, they indeed are experimenting with it, even if to others it doesn't seem like an experiment. In any case, as with any experiment, they are learning something new.

This. Add in some PHP and MySQL, and I still don't have to 'build' anything.

Well, I have to build it of course. As in, me as the developer has to make it.

> The idea of building/compiling in web development is (and has always been) totally alien. HTML, CSS, JavaScript.

Then you may be serving your users broken implementations or you may be spending way too much time handling progressive enhancement. If not, congratulations on mastering every edge case.

The rest of us use polyfills, linting, transpilation, treeshaking, and other alien tool chains to help us out.

The last 12 years of browser development (and the people who make said tools, so things get adopted quicker) are to thank for letting you do more things with less tools today.

I've interviewed "Front end Devs" who don't know the difference between a class and an id. We're becoming dinosaurs

Well the stack has deepened.

10 years ago I would have expected you to know the HTTP protocol well.

But now I don’t ask about HTTP anymore and ask more about raw HTML/JS, because I also need to ask you about frontend things like accessibility.

I feel like this is needless nitpicking. Some of us may have grown up with PHP, DHTML, actual XML HTTP requests, and so forth. I guarantee that there is a major crowd, even on HN, who have not had this experience and who think that webpack etc. are required.

You are not the audience for this post.

A way I think of this is to categorize skills by whether they'll last a decade.

Python, SQL, Linux, those are core skills I've used for over a decade and are just as useful as they were a decade ago.

Javascript is obviously more than a decade old but a reason I've avoided that ecosystem is that you're often operating in the domain of year to year tools and skills on top of it.

Decade long skills come as easily to you as English. (Or whatever your native language.) It's easy for people to overlook this because it's so easy to "learn" a skill right away and feel fluent.

I've optimized for keeping as much of my work as possible/practical in decade long skills because it's pure productivity. If I'm turning over frameworks and tools regularly I'll still be productive, but not productive. I see it as a qualitative difference, not quantitative.

I basically have the same approach. Still need a micro-build to fingerprint assets, though.