hckrnws

Not trying to sound like an asshole but articles like this always confuse me. "Experimenting" with no-build web apps makes it sound like web apps require build steps by default. The opposite is true.

The idea of building/compiling in web development is (and has always been) totally alien. HTML, CSS, JavaScript. None of these require a build step.

It also further confuses me when authors talk about simplifying their web tooling but instead of using the actual web languages mentioned above, they resort to using some weird framework which just introduces another learning curve and more cognitive load.

As a web developer of 20 years, you know what I build web apps with? HTML, CSS, and JavaScript.

> 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.

> 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

I hope that one effect of AI assistance will be that we can go back to full stack teams again. It should be easier to know enough about both sides to be productive in them with AI help.

Then things like backend templates + HTMX would maybe work great for 90% of apps and be vastly simpler than the huge pile of technology we've been using in the frontend.

> we can go back to full stack teams again.

Not sure it'd be good. We'd only be hiding complexity, not actually removing it. The ideal scenario would be that both front and back ends could be described in simple enough terms a single team (and less than two lifetimes of training) could handle it.

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 website in your profile isn't even loading for me

Okay. For me it is. Never had complains like this, even with thousands of HN visitors an hour.

It's loading now

Cool, thanks for letting me know! ;) I see some traffic from HN now.

For some of my websites I block traffic from certain timezones and/or browser languages, I just double-checked but Hey Homepage doesn't block anything. May I ask from what country you're visiting? I myself experience long loading times for websites from Japan for example (I am visiting from western Europe).

> 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.

Also minifying code seems like a no brainer for someone developing a web app.

Is it?

Bootstrap CSS: 147KB

Bootstrap CSS Minified: 122KB

Bootstrap CSS GZipped: 22KB

Bootstrap CSS GZipped and Minified: 20KB

I'm not convinved 10% is worth adding a minifier. And I ask this question for every build tool in my projects.

source: https://css-tricks.com/the-difference-between-minification-a...

CSS minifies quite poorly compared to JavaScript. JavaScript generally minifies quite well (I've seen savings as high as 85%). The minifier can mangle variable and function names as much as it wants with no effect on behavior as well as do automatic dead code elimination and constant expression evaluation. CSS does not compress nearly as easily because the minifier is much more limited in what it can compress (mostly formatting).

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

Recently I showed somebody https://search.feep.dev and they opened the browser network tools and went “Where’s the XHR? Where’s the JavaScript?? How did you change the URL?”

They had no idea that <form><input></form> is all built in to the browser and you can make GET and POST requests without any frontend code. (Not that this is a new problem, <a onclick="document.location='...'"> has been a thing for decades at this point...)

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.

There are a plethora of different ways people are using all of the tools that you mentioned.

There are so many SQL implementations and flavors, no one could possibly have a thumb on all of them.

Acting if it is somehow easier to master than the many web development tools (frameworks, build tools, etc) that you can learn how to use in a few hours seems like a confusing take.

Now I find this fascinating. Working with JavaScript, I've just come to assume continual training is part of the job -- but what if it didn't have to be?

Of course I still learn new skills in the Python/db ecosystem, but I stick to the fundamental Python/Postgres/Flask/Django/Redis/Nginx stack where possible and it not only helps productivity but it reduces surprises. We understand the exact risk profiles of these systems. You can "learn" a new tool very quickly but you won't know how to assess or reason about what will be the operational experience of it in production. We do not factor surprise tolerance into our decisions often enough.

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

I think targeting no JS at all is much more impactful to the overall experience of web development. Reaching for it only when HTML+CSS have failed you is the original intent. Server-side rendering can take you really far if you are patient and creative.

NPM/Node is at the heart of my displeasure with JS. I don't mind JS in the browser when done tastefully. But I don't think it makes much sense outside of the DOM. As another comment noted, you often have to go dig through CDNs and hack at URLs to get the actual JS files for non-insane hosting models (i.e., statically from the same machine that hosts everything else). The notion that I need a CDN to serve a few kilobytes of source for anything short of netflix.com is absolutely insane.

I would advocate starting your next web project using 0 lines of JS, even if you intend to use the full USS Enterprise to build it out for prod. See how far you can get with just HTML & CSS. Consider that anything proximal to layout/style/art/etc. is entirely within this box. Javascript is not going to save you from an art problem. It can only make it worse.

What do you use for the back end?

.NET

Technically it has a build step, but for most projects it's not long or complex enough to matter. I rarely need to pull in dependencies beyond SQLite and Dapper.

Whenever I have the chance, no-build is how I have been architecturing web applications for the last decade or more.

That plus no-compile/near-instant-compile tooling (PHP, Bun, Go) enables instant feedback during development.

It's liberating and force multiplier.

I also implement custom unit testing libraries that are simpler than industry standard but MUCH faster. It hits different when unit tests finish running 1s after saving a file versus 10s.

I also make unit test runner play sound for success and failures. So you don't even have to look at tests to know if they passed or failed. It's dopaminergic. And reduces cognitive load because you can offload unit tests feedback to auditive system, aliviating the already heavily overloaded developer visual system.

To this day I receive e-mails and direct messages of developers thanking me for their joy working in these projects. On average once every 2 months or so. Makes my day.

Everything in the name of reducing cognitive load. This is our bottleneck.

> I also make unit test runner play sound for success and failures.

This is brilliant! Such simple change but a massive qol improvement.

> Test runner

Node has one built-in these days. Haven't tried it yet but would be nice to get rid of the vitest dependency. Mostly because it makes my dependabot noisy for no apparent benefit.

Time to open source your solutions?

I'd love to. Just need to take the time to clean up, commit and push.

That and my blog. Oh well, tomorrow perhaps.

This is the way.

Everything of consequence I’ve built with JS and still maintain today has at _most_ a bundler/minifier. If I see I need to npm install a web library, I instantly skip it and look for something I can get as a plain js file (even if I need to pick it off a CDN).

> So instead of writing the book I want to write, I decided to rewrite Little Webby Press in a stack that is more suitable to my own enjoyment.

This guy stole my patented side-project management technique.

To post a more serious comment, I’d forgotten about Mithril. It is indeed nice.

I think I’d miss Typescript and JSX too much, though. I may have to play with this stack soon, and see if it can change my mind.

This is why many developers are upset with AI. A lot of us love the craft of writing code. The last version worked. There was no need to rewrite other than enjoyment.

“Delivering value” without the craft of coding a project grates against many.

I too enjoy that process, but I’m also learning when and how the ultra boost of AI assistance can fit into a quality first / crafting mentality.

I suspect the author would shudder at the thought though

> Both the ebook and the website generation functions are massive waterfalls

async/await syntax works in all current browsers [1], you can clean up your massive waterfalls without a build process today.

[1] https://caniuse.com/mdn-javascript_operators_await

Even back then there were polyfills, which most of the time all that was involved was an extra <script src="..."> tag.

Modern web development (tooling) is trash, lmao.

Nice to see Pico CSS in use here. I'm using it for internal tools and private side projects for some time, too. I like it.

A word of caution on import maps. My app, Easel, previously relied on import maps for running user and AI-authored code in an iframe and it caused many many issues for us.

Import maps combined with ESM CDNs (like jsDelivr, jspm, or ESM.sh) can work in ideal conditions. But in practice, a lot can go wrong. Many packages don’t compile cleanly to ESM, ad blockers can interfere with individual scripts (the innocuous Lucide "fingerprint" icon [1] is a common casualty), and a package might work on one CDN but not another (intercompatibility is shaky at best). Worse, any failures happen at runtime, and a single missing or broken script can snowball into a full app breakdown.

If it’s working for you, great. Just make sure your versions are pinned. But if you’re building anything dynamic, it’s worth knowing that the ecosystem is still quite brittle.

I'll probably author a blog post about this one day.

[1]: https://lucide.dev/icons/fingerprint

Recently instead of writing the book I want to write, I decided to search a good tool to create eBooks, I found Writebook https://books.37signals.com/2/the-writebook-manual But considering that LWP doesn't require an account I will go for it

It would be great if you created this as a single executable desktop or cross platform app.

If done with Electron, that will be 100 MB.

Or with Tauri, 5 MB. Which, amazingly, seems tiny.

Redbean would probably be similarly small

If you are looking for web app stack, that does not require build step:

TLDR: I was looking for a web app stack that I can work easily in year 2030, it is for side project, small tools I am developing and that is what I came up with.

I've been spending some time thinking about (and getting frustrated by!) the complexity and churn in modern frontend development. It often feels like we need a heavy build pipeline and a Node.js server just for relatively simple interactive applications.

So, I put together some thoughts and examples on an approach I'm calling "No-Build Client Islands". The goal is to build SPAs that are:

Framework-Free (in the heavy sense): Using tiny, stable libraries. No Build Tools Required: Leveraging native ES modules. Long-Lasting: Reducing reliance on rapidly changing ecosystems. Backend Agnostic: Connect to any backend you prefer. https://mozanunal.com/2025/05/client-islands/

The only reason I work on apps with build steps is because I’m paid to.

When I play with stuff on my own, I keep my toolchains real simple. Whenever possible, my rule is “I drag the html file into the browser and it just works.” As it was in the old days

Also, FTA - is ‘nerdsnipped’ distinct from ‘nerdsniped’?