The unreasonable effectiveness of simple HTML (2021)
shkspr.mobiThinking back to my community college days in 2020 (right before the pandemic!), I used to rock a crappy old dual core laptop with 4GB of RAM running Fedora. Browsing the web was less than ideal and YouTube barely worked. For certain classes (the big hassle was a DB class after I transferred) running the course software was very taxing and I had a harder time with that compared to other students as a result. I remember Zoom barely working on it, but only if I didn't use the camera. I look back at this experience a bit fondly as it made me rely more on the terminal and I shifted away from slow laggy GUIs to TUIs/NeoVim. That said, for most other individuals in that position it really is a big limiting factor for their education.
Recently I was tutoring (for college essays and math) at a local high/middle school and most students browsed the web on their smart phones, but those that didn't were limited to school issued Chromebooks which were ungodly slow. Some of these students served as translators for their parents and I was under the impression that they used these devices to pay bills and for other household tasks as well. This experience is why to this day I try to keep the websites I make light on dependancies (I don't like react) and fast to load (sub 300kb ideally).
It really is a sad reflection of our craft as a profession that 16GB is the bare minimum to do basic office tasks like email/browse a news website.
It was already sad when 1GB became the minimum. Having 256MB was an amazing luxury for a long time .
I used to do email/browsing/games on 8MB of RAM. Upgraded to 24MB and was able to print a poster sized photo that I scanned with a handheld scanner.
I have 2000x as much RAM now, about 3000x more CPU, but hard to say what really changed for so much increase.
Yeah, full motion video is now more trivial. Gaming graphics certainly improved but not 1000x more fun.
I probably have more computing power today in my room than medium sized universities had back in the day.
I can only remember having 256MB as the minimum in my formative years, with a 1GHz Celeron. It ran XP fine and some very basic games(Ultima Online, strategy games like C&C).
Not much has really changed, I’d argue what young ones do these days is even less basic with more bloat.
That’s just it! It used to take a cluster of 10-20 high end PCs to approach what’s in a cheap PC today.
You've a point. HTML is plain and simple, works and gets the job done. Presenting on the web (may be a little bit of light css).
Heavy CSS animations, Javascript bloat is what slows down the websites and literally ruins the web experience.
I personally think CSS animations are wonderful. I’ve recently returned to dabble in frontend stuff and was delighted with what you could achieve with purely declarative HTML and CSS. I’m finding that you can often match the feel of an SPA with just HTMX and some CSS and I’ve found that simultaneously very satisfying and productive.
I would say that what ruins the experience is things not working. If it was an animation or some add on that threw an exception to console and did nothing, it would be fine, but designers and their tool makers want everything to be a giant conversation between microservices, which breaks for odd, undefinable, nonlinear reasons, and requires expensive help.
You can also get really small file sizes by ignoring frameworks and porting unsupported codecs to wasm.
I ported jbig2 (17kb uncompressed) and codec2 (60kb uncompressed) to wasm which enables me to use really small image and audio files in my web app. I also made a custom read only database and search engine with built-in zstd decompressor (39kb uncompressed). It probably wouldn't run on a psp though.
I like optimizing and making things small. I want to use neural audio codecs for even better compression but the model sizes and compute complexity are major hurdles and muddy the vision.
I hope the image and audio bandwidth savings are more than the cost of having to send down the codec JS payload - might be worth it for a web app with a lot of image/audio loading
With a 17kb jbig2 decoder all you need is a few one-bit images (a page of a book scan) for it to save bandwidth.
With a 60kb codec2 decoder you need about 2 minutes of audio to start saving.
But the target is dictionary apps with thousands of seconds of audio and thousands of images.
I get all my news by reading: NYT, WSJ, BBC, AP, and a few Substacks.
NYT has gotten so bloated both in actual content (long meandering interviews) as well as the encapsulating junk. I started to put it into Gemini to summarize. During this process I found, the two hour interview transcript was 50% actual words and 50% junk (probably formatting, tracking, adware, surveillance?).
The junk made me feel dirty.
I build my apps the same way: mostly server-rendered HTML with a little JavaScript on top (Hotwire on Rails). They're mostly forms and CRUD, and it's worked for years with almost no client-side state to debug. I avoid React when I can. The frustrating part is there isn't much Hotwire or Rails work around these days. Most of the jobs want React.
Which was quoted in a recent post on the HN front page: https://mohkohn.co.uk/writing/html-first/ , https://news.ycombinator.com/item?id=48475483
(2021)
Some discussion at the time: https://news.ycombinator.com/item?id=25915313
And a more recent incarnation or variation:
Using Claude Code: The unreasonable effectiveness of HTML
It feels like every week someone discovers that code closer to the metal is faster, and ignores the fact that it’s easier to write higher-level code, and that this is the specific tradeoff everyone is making. Why do these articles keep getting posted? Who is this a revelation to?
I don't think of HTML as low level, and I don't think that writing "high-level" web (whatever that is? React?) would be any faster to develop or produce better results for his example.
If you looked at the gov.uk page [1] that he linked, it is clean and readable. It doesn't look hard to me to make, and I don't think it is lacking functionality.
I'll grant that writing web-apps without a framework is going to be harder for many people (especially with all the fancy features that are expected now days), but that is not the point of this writing. This is an argument that the web (especially government services) should be usable on limited devices too.
The article and commenters are both complaining about JS in favor of HTML - I'm really just talking about it in this context.
Anyways, I disagree with the idea that we should make something simple enough for PSPs and car browsers. Just go to a library.
What a depressingly elitist and exclusionary view. The modern web browser contains all the technology right there to make fast, maximally-accessible websites and even some “app”-like things, but nah you can’t be bothered, screw the less-fortunate. Would you want to “just go to a library” instead of use the device you already have? I strongly doubt it.
“Go to a public library” is elitist? I am on my hands and knees begging you to reconsider this position. I cannot imagine a worse take.
Public libraries are great and there should be a lot more of them and everyone should enjoy them, but they should absolutely not be a substitute for respectful, accessible web design and engineering. The elitism is that only people with the shiniest new devices should get to use your website on their terms.
I guarantee libraries do not have the shiniest new devices. So trying so hard to be offended.
You are either refusing to address the central point or your reading comprehension needs a lot of work. A premise of your original post was that libraries have newer devices than some users. I maintain that libraries should not have to be a fallback for your crappy website.
Right, and I’m positing that you don’t need to support 20 year old devices that receive zero updates because everyone has access to libraries in an absolute last resort.
There are limited resources when developing software. This is a pretty bad resource sink.
There are types of software for which I’d largely agree with you. Websites are not one of them: it takes effort or incompetence to make them slow and inaccessible.
Like 99.998% of software problems are due to incompetence. What’s your point? That government software is somehow immune to this problem or something?
You seem to agree with me, but refuse to admit it because you wish the world was different. I do too, but it’s pretty irrelevant.
My point is that websites are particularly amenable to being cheaply built in a fast and accessible way. I would say classes of, say, macOS apps are similar. Government certainly should be insulated from at least the market pressures that push websites into being slow and inaccessible. Competence is more a roll of the dice, I’ll grant you, but I’m not as pessimistic as you on that.
If we were talking about JS or Python or something, I’d agree with you. Most people just don’t have expert-tier knowledge of pure HTML, and even if they do, they’re slower to develop. I could get a feature out today to 99.9% of my desperate users, or I could get it out to 99.99% by waiting another two weeks. It just makes no sense. It has nothing to do with pessimism and everything to do with economics.
Sorry, I don’t buy it. There’s nothing “expert-tier” about plain accessible HTML, and with LLMs, there’s even less excuse. I’m not primarily a frontend web engineer and I can manage it.
Yes, I’m certain you can “manage it” despite not considering things like screen readers, page layout reversals, mobile responsiveness, working with legacy codebases that are 30 years old (when was the last time YOU had to update a site that simply must shut down every night for processing?), etc.
Everything looks easier from the outside. Maybe we should focus on getting private corps to provide a small amount of accessibility before forcing onerous requirements on our already-underpaid civil servants?
We're talking about governmental document-like websites with relatively simple forms here, not your particular legacy web app, there is no excuse for not getting them right. Gov.UK did. Plain HTML, used in a straight-forward way that is very clear from the approachable documentation on, say, MDN, is already responsive, readily consumable by screen readers, and works with any backend that already exists. If you have to fix a mess left by someone else you have my sympathy - I've been there too. But the original post is appealing to people who have a choice between plain, standard-use HTML, and any alternatives. And yes, I'm all for much harsher penalties for private companies that produce inaccessible web sites/apps too.
You clearly took the lesson on board didn’t you.
http://Bellard.org is peak web design. Change my mind.
(2021)
(2021)
Now do the unreasonable effectiveness of an overly ambitious junior dev convincing management to rewrite the who site in client side react.