Building an HTML-first site doubled our users overnight

Posted by edent 4 hours ago

Comments

Comment by OskarS 1 hour ago

As a non-web dev, I have a question about this part:

> There was a sad coda; as is the way of contract work, I moved on. I explained what I had built to my replacement, that it always worked even without javascript. He was appalled and said, “but that’s a lot more work for us.”

Why is it more work? The approach described in the article seems honestly reasonably simple: just write the standard <input> components for the form, have a submit button at the bottom. When I was making my own websites many years ago now, that's how it worked, and it wasn't that hard. Maybe it's reflecting my ignorance in this field, but doing fancy front-ends seems much harder to me.

Comment by chao- 56 minutes ago

Starting a few years ago, I realized some junior and medior engineers never once considered the possibility of building a website (app, experience, etc.) in anything other than a heavy SPA framework. But they're not stupid people! If you directly asked "Can you build a website without React?" they know the answer is obviously "Yes." However, if you asked them to build a new website, they would unthinkingly start a new React project, mostly out of familiarity and a desire to get the job done.

A few of them would outright not know how to do anything else. No knowledge of how to stand up a boring HTTP server to send pure HTML. No experience building a form that validates or submits without JavaScript. These are not the people who post here on HN. They are not engaged in online discussions of new tools and skills (or old tools and skills!). These are people who learned just enough from a bootcamp, or their uni's single "web apps" course, to get a job. Since then, they have just-in-time learned whatever their employer required, or whatever particular tools someone else on their team chose for a project.

As an old, it took me a while to recognize/realize it, but I understand them now. Depending on their career path, someone will encounter the simplest aspects of HTML, CSS and vanilla JavaScript after they learn the complex, framework-specific aspects of each. It feels (to them) like more esoteric, advanced, or tertiary knowledge.

Tying it back to to the quote "that’s a lot more work for us", that's not necessarily an intentionally false claim. It probably does feel like a lot more work to perform a task using unfamiliar tools, even if they are less-complex tools.

Comment by concinds 45 minutes ago

You are far too empathetic to them. They should not hold the jobs they have.

These are the people writing React monstrosities for government benefit websites, and testing them on fast iPhones and fast 4G, without realizing that every page load for actual users will take 30 seconds on their old $200 Android on 3G, and users won’t complete the form.

It’s a culture of not giving a shit, that’s the deeper issue.

Comment by 6510 25 minutes ago

I use to have an old pentium 2 computer for testing websites. Sometimes you cant make things fast enough for the old box. A fun trick is/was to have <script>elm.textContent="loading images"</script> between each "heavy" section, all targeting the same elm. If the computer, network or server is truly extremely slow you will get a nice message at the top describing what they are waiting for. On a normal slow computer you won't see the messages unless something went wrong.

Comment by yesco 22 minutes ago

I see no reason not to be empathetic. The frustration is fair, but it's aimed at the wrong layer. These people were guided into this spot by bootcamps and curricula that start at React and never go down the stack.

My experience was the reverse. I learned HTML and CSS first, then Rails in college to serve templated pages. I understood the client/server boundary fine as a concept, what I couldn't see was where it actually sat in a web context. I sort of knew JavaScript ran in the browser, but then I'd see ERB templates stamping values directly into script tags, so the server was writing the JavaScript that ran on the client, and my mental model fell apart. Where does my code actually execute? Why does this variable exist here but not there? Why does the page have data the network tab never fetched? Nobody ever sat me down and explained the request/response lifecycle as its own thing. I had to assemble it from fragments over years. This was around 2017 for context.

How you learn something shapes how you keep learning. If your mental model is misaligned, everything downstream is friction. The thing that finally made it click for me was reading the actual HTTP RFCs, which is apparently a weird thing to do, because HTTP itself is absent from nearly every guide and curriculum. Tutorials teach you the framework, maybe the language, and just assume the protocol underneath. These days I make newbies read the MDN docs like a book and skim the HTTP wiki page, learn the history of the protocol. It's short! It's not even a book! That gives you a firm foundation. But if your foundation starts at React, drilling down is like digging past bedrock. People don't know where to start, and Googling only shows them wrong answers because they don't yet know how to ask the question.

Comment by luckylion 4 minutes ago

Are you sympathetic to a doctor who specialized in surgery and now always recommends surgery, even for a common cold? Or would you say they are in the wrong job, if they are anywhere but surgery?

Comment by opem 36 minutes ago

Don't you think they have a legit skill issue here and should they be better off upskilling themselves?

This is a direct effect of being a low barrier industry to enter. Most of the ppl among us are mostly here because of a good paycheck. And it SUCKS!

Comment by chao- 28 minutes ago

>Don't you think they have a legit skill issue here and should they be better off upskilling themselves?

Absolutely agree! Just because I understand how they got there doesn't mean I think it's a good state of affairs ;)

My post was already quite long, and I didn't want to append a treatise on what one should do when encountering those engineers. It depends on many details. Avoid hiring them, if that's a power you have. If you are stuck working with them, depending on your authority, encourage them to learn or force them to learn. If you're coming in to clean up after them... well, hopefully your comp is worth the annoyance.

We are all simultaneously in the position of encountering "the world as it is", understanding it, and doing what we can to improve it.

Comment by egeozcan 34 minutes ago

I think the problem is hearing just one side.

Someone is saying that they delivered a very reasonable solution that's simpler than most would come up. Person taking over was not happy.

Do we know if the code being handed over was high quality? Were they reacting to the fact that it was "not React"? Maybe they have a template they enforce in the company about how apps are built?

We don't know.

Comment by theflyinghorse 1 hour ago

It probably has to do with what technology people are used to. There has been a couple of generations of web developers who have only known javascript and its ecosystem for building webapps, and so anything other than pure javascript solution looks foreign.

Comment by 39 minutes ago

Comment by seangrogg 56 minutes ago

As a web dev a lot of this is simply ongoing maintenance of a largely unknown quantity. Most web devs know React and use it extensively; Astro is something they'll have to learn on the job or hire for specifically.

It's akin to writing a backend in Haskell. Chances are you could write something performant that leverages FP in a way that serves as a magic bullet for your domain. But now everyone after you needs to learn Haskell and how to model all future problems in a way that conforms with it - or rewrite things again.

Comment by freehorse 29 minutes ago

Not a web-dev myself and I was wondering if, apart from unfamiliarity with astro or HTML being treated as unknown technology, it also has to do with having to handle fallback cases, eg the 3 point validation (web component, browser default, server), esp when one is used to have react (libraries) just handling it all without any more considerations.

Comment by oldandboring 42 minutes ago

> Astro is something they'll have to learn on the job or hire for specifically.

Before LLMs I would have agreed.

Comment by hungryhobbit 38 minutes ago

LLM + framework you don't understand goes in ... unmaintainable garbage comes out.

Comment by CSSer 32 minutes ago

Before LLMs, learning on the job looked like reading documentation. Now it’s a guided tour with verification. When I produce things in this way, I’m not just blindly accepting it. The goal is that by the end of it I have learned more about the codebase and architecture, not less. I feel that’s important.

Comment by 55 minutes ago

Comment by simpaticoder 1 hour ago

Simpler doesn't mean easier. Consider a chef who at their previous job started using a wood-burning stove. This is an objectively simpler tool than a gas or electric stove, yet it would be very difficult (even impossible, depending on local architecture and regulations) for a new kitchen to add one.

Comment by squidbeak 50 minutes ago

I'm interested to hear what architecture and regulations prevent the use of something that is foundational to web develpment and backwards compatible by design? Which also, by the way, comes with the advantage of not incinerating other parts of the restaurant (accessibility, user experience...), forcing expensive countermeasures or total rebuilds of the things destroyed every time you turn it on.

Comment by LNSY 1 hour ago

I don't understand how having to pay 20 different vendors so hackers can run commands on your server barely impeded is somehow simpler.

Comment by simpaticoder 52 minutes ago

The message you just wrote involved how many complex systems, from your keyboard switches and firmware to your BIOS and OS interrupts, to your browser, the internet and middle boxes, just to say one sentence to someone. It would be much simpler (and more secure!) if you just told me with your mouth, but you didn't do that.

Comment by LNSY 21 minutes ago

Of course, and if you use all these services you can be a pedantic ass who never has to actually ship a product.

Comment by atoav 1 hour ago

By this point people don't appear to have any real clue how to write HTML anymore. Writing semantic HTML isn't significantly harder than say writing Markdown. You copy some HTMl skeleton and you literally just stack your elements into the body. I managed to do that as a 13 year old on MySpace without any deep instruction. Sure you have to close elements as well so the syntax is slightly harder than markdown, but that allows you to differenciate between for example <article>, <section> and <aside>.

I am convinced the one single thing that made HTML unusable over the time was that people wanted or needed a way to re-use parts of the page across multiple pages, like headers, navigational elements and footers.

This meant people used frames, PHP, templating engines or any other new technology mainly for the purpose of creating shared elements, simply because HTML failed (and to this day: fails) to offer a way to include one HTML file in another without having it suck (like frames definitely did, since the browser treated each subpart of the page like its own entity including caching).

Comment by autoexec 37 minutes ago

Large websites resorted to PHP and server side includes to get headers and footers. Smaller websites resorted to frames and copy/paste. It wasn't perfect, but it also wasn't horrible or unusable either.

Comment by p-t 6 minutes ago

yeah editing all the footers and navigation parts in html is too annoying to me so i've resorted for my websites to just a back button to a page that has links to everything else lmao

Comment by jmye 16 minutes ago

I think it was... SHTML? that allowed for server includes. My recollection from... 25ish years ago was that it was generally quite well supported and worked quite well (and was dead simple to implement). Not sure why, if that was the issue, the fix didn't quite catch on (but it's totally possible I'm mis-remembering the state of browser support).

Comment by EvanAnderson 10 minutes ago

Server-side includes worked fine but weren't enabled by default in any of the mainstream web servers. I used the heck out of them in the late 90s.

It would have been very cool if HTML had been created with the ability to do client-side includes without having to resort to using a Turing-complete VM in the client to do it.

Comment by atoav 6 minutes ago

[delayed]

Comment by rhelmer 59 minutes ago

[dead]

Comment by 54 minutes ago

Comment by LNSY 1 hour ago

Because before there was AI Slop, there was React.

Comment by EGreg 55 minutes ago

I think Facebook with their money and Vercel with their VC funding tried hard to push the React and then the Next.js everywhere. So it arrived in time for AIs to all train on it. And now it’s the one true way :)

But do we really need all that stuff? Build steps, bundling, tree shaking, all for what? And is it really simpler… hmm

Comment by motoboi 1 hour ago

Old people. They exist.

Not even that old. 60 year people can't user your fancy site because then don't have an internal model of how a computer works.

You know that when pressing a button a hidden engine runs in the backend (or something runs in the backend). You expect an answer and if the expectation do not match the result, the model in your mind creates an hypothesis about what maybe happened and iterate from there. Maybe you should have clicked something before? Maybe you should mark some form checkbox?

Old people don't have that because they didn't grow up with computers.

What is on the screen is what they see. I clicked next and nothing happens. Well... the site is broken.

You known when you plug your refrigerator and nothing happens and instead of reflecting on the possible blown out resistor that you can bypass with a small wire you understand that your only relationship with the refrigerator is plug and unplug or call for help? That is an old person using your site. They won't fight against it. They'll give up immediately.

Comment by StableAlkyne 1 hour ago

I would argue it's not even old people. Most people do not have any understanding of what's going on when you click a button. Website either acts as expected, or it doesn't "work"

If the button doesn't work, the average user is going to say "this most be broken" and then use a competitor (or contact your support). That's why it's really important to error-proof one's design (eg https://en.wikipedia.org/wiki/Poka-yoke).

So instead of the button failing because you didn't check a box, pop up with a message telling them "Please click $box before continuing". Or if you want to be fancy, feed them whatever form you're giving them piecemeal, so that they can't continue until they finish this small part (e.g., have them input a name, then the next page only has a spot for an address, then the next page only has a spot for card information, then the next only has a spot to select shipping). Simple bite sized chunks anyone (well, anyone you would ethically want to sell to) can understand.

Comment by black_puppydog 43 minutes ago

Yep, I changed town a few years ago and my new social circles are mostly like that.

Either it works right away without any further questions, or they'll not do it.

Sadly, also if they can't do it on their phone, they will not do it. It's actually very hard to get people motivated to do anything that has to do with sitting down at an actual computer anymore. Which is a bit hard if you're in a very technical political advocacy group, kinda makes me the guy to do everything remotely complex... XD

Comment by andrewflnr 31 minutes ago

Yeah, it's really, really not an age issue. If there's an age distinction, it's the range of people who were brought up on computers before the UI was really polished, but even then it's not consistent, and they may not have deep understanding. Kids brought up on iPads, and who aren't forced to learn by their interests or educators, have no clue.

Comment by breakwaterlabs 1 hour ago

> Old people don't have that because they

Aren't insane.

When did the industry put the onus on the user to understand how the computer works? What happened to the old days of Xerox PARC's HCI studies putting the user first? The computer is in service of the user, not the other way around!

If I need to build a mental turing machine to understand your application, it is a bad application. It is rather the engineer's job to build a mental model of the user and their needs, and if you can't do that you should not call yourself a software engineer.

Comment by ryukoposting 45 minutes ago

As a firmware engineer, my philosophy is this: if I'm doing my job properly, the user should never even know I exist.

Maybe this isn't applicable to all software devs. If you make web apps, users actually see your UI, they click an icon or type in a URL and hit enter with the intent of using the thing you made. With firmware, that's not how it works.

When you hit the "mute" button on your laptop keyboard, it should just do it. The audio should turn off and the little LED should light up. If that fails, even once, the mirage is broken. The user is forced to think about the fallibility of firmware, which is a word they might not even know, and still struggle to conceptualize if they do. I think it also has a lasting effect on the way someone thinks about the pruduct: Is this going to work today? Why did that happen? Was that a virus? So on.

OTA firmware updates have the same problem. Most users don't know what the hell firmware is. All they know is their computer is showing a loading screen they've never seen before. It's unfamiliar and weird.

Like I said, I don't know if this mindset translates perfectly to other fields, but the priorities that fall out of my philosophy certainly apply. Reliability over everything, and get it right the first time.

Comment by cosmic_cheese 16 minutes ago

Usability was thrown to the wolves in favor of more readily available designers from non-UI backgrounds, brand identity (“UI as branding”), and pretty screenshots for slideshows and marketing.

The pendulum is overdue for swinging back the other way, but I don’t know who or what has both the capability and will to give it the push needed to send it on its way back.

Comment by isityettime 53 minutes ago

Automation generally goes along with a transition to more "self-service" approaches that require the user to model internal states and workflows of whatever they're dealing with.

This is even true for things as seemingly non-technological as getting to your flight once you arrive at the airport. People who are used to dealing with a service desk might just show up with their printed ticket without even having looked at it, take it to the counter, and expect instructions on what to do next without having read or considered all the fields present on the ticket.

It's not just about understanding the technology, but sometimes about understanding the business, policies, whatever. When a human agent or customer service worker is handling that stuff for you (typical in the pre-computer age), you barely have to think about that stuff and even if you're told, it can be "in one ear, out the other". Automation very often means pushing a requirement of more understanding onto customers/users.

Comment by Hard_Space 1 hour ago

> 60 year people can't user your fancy site because then don't have an internal model of how a computer works.

I think this is a bit outdated. I'll be 60 in a month, and have been practicing and writing about machine learning, for money, for a straight 10 years now; and I was a young man (and a full stack developer) during the digital revolution.

If anything, GenX had to work harder to get into these brittle emerging technologies and paradigms. There's no-one of my age group, at least that I know of, who is remotely as tech-illiterate as your comment depicts.

Truth is that it took so long for smartphones to dumb down everyone's tech acumen that those of my generation had already learned to do it the hard way.

Comment by rewgs 1 hour ago

GP clearly isn’t talking about 60 year olds who were full stack devs and get on Hacker News.

Comment by tomgp 1 hour ago

60 year olds have been using computers most of their working life. Word processors and spreadsheets having been ubiquitous for office workers from at least the early 90s.

Comment by lproven 51 minutes ago

> 60 year olds have been using computers most of their working life.

Absolutely. I am in full-time work, and expect to be for another decade. I have worked my entire career in IT, doing tech support, training, systems design and implementation, tech journalism, and tech writing (i.e. documentation).

I will be 60 in less than 18 months.

> Word processors and spreadsheets having been ubiquitous for office workers from at least the early 90s.

You did say "at least", but still... longer than that.

I started work in 1988 and they were already ubiquitous in my world. Richer companies had the fairly newfangled IBM compatibles, which were still big and expensive. The cheap Amstrad PCs were just starting to appear.

Older hands had multiuser boxes with SCO Xenix or DR Concurrent CP/M or Concurrent DOS and a bunch of dumb terminals. My company had switched to these from Alpha Micro systems running AMOS -- and again, dumb terminals. One of my clients had a DEC PDP-11.

The real old hands had 8-bit kit: some CP/M, and a few BBC Micros.

The first big migrations I saw were from standalone (or multiuser) PCs to LANs, and from pre-PC systems to PCs and Macs.

Comment by jimbokun 53 minutes ago

Most people under 60 aren’t full stack devs either.

Comment by Hard_Space 1 hour ago

Well, neither am I - I am talking about my own peer group, non-tech types just fine with computers.

Comment by wang_li 59 minutes ago

I'm 55 and likely have been using computers longer than that poster has been alive. Regardless of the fact that I started young, by the time I was in college the PC revolution was in full swing and everyone had and worked with computers.

My mother, born in 1934, had no problem using computers. She didn't internalize how they work, but she learned the workflows she needed. How to launch applications and so on.

The situation described in that comment is just a broken app, it has nothing to do with the age or the understanding of the user.

Comment by dijksterhuis 1 hour ago

> practicing and writing about machine learning ... full stack developer ... digital revolution.

my mum, a boomer now in her 70s, would have no bloody clue what you're talking about. she used to work helping out a guy who was doing punchcard programming back when she was young. she ain't dumb. if i broke it down into normal human english words, she'd probably get a sort of idea (or at least nod along to humour me).

i've lost count of the number of conversations i've had with my dad, late 70s boomer, where he complains that they've changed the UI. "It's all different and i don't understand, why did they have to change it? I don't know where anything is now." he's been moaning about things like this for over a decade now (so since his late 60s).

there are definitely technically not-very-literate 60 year olds and the general point about older folks, whether that's >60 or >70, is very real:

older people exist who don't have a clue about SPAs/PWAs, and chances are they're either asking their offspring for help (my mum does this), trying to phone someone instead (my mum does this) or just walking away from it (my mum does this).

Comment by Maken 9 minutes ago

To be fair, the UI randomly changing in every update is a pain point for people of any age.

Comment by asdfasvea 34 minutes ago

Dude, you know what he meant. Don't be the internet pedant. No need to be the protector of your class, especially one so inconsequential as "literal 60 year olds".

Instead of "old person" he put a number on it. (Cue the people who need to cut me down because I used a male pronoun for an unknown poster)

Comment by bearjaws 33 minutes ago

You are just describing a broken site?

I've seen static sites with these same problems, 404 was invented decades before React...

Comment by initramfs 1 hour ago

There's a great book that explains how abstract computer systems have become from the machinery: https://dabacon.org/caelifera/2017/02/05/book-overcomplicate...

Comment by dotBen 55 minutes ago

"Old people don't have that because they didn't grow up with computers."

You know, it's time to stop this trope.

People who are 60 today were born in 1966, they probably entered the workforce in the mid 80's. They probably are not even retired yet. They know how to use computers, they own a smartphone (or if they don't, it's probably for economic reasons unrelated to their age).

As a founder and product manager, this kind of thinking is unhelpful as we design the future. In many ways it's actually ageist to imply that old people are unable to utilize everyday technology.

I was building public service websites (BBC News website) back in the early 2000's where accessibility was a real and important consideration. Technology progresses, and the bar for accessibility has moved up.

My father is about to turn 80 - he checks his heart with his Apple watch, video calls his grandson from his iPad, and asks ChatGPT questions from his iPhone and MacBook Pro. Maybe he's more unusual for 80yo's but it's time to stop this lazy trope that old people are technically illiterate.

(also, shit, I'm only 15 years away from being 60 myself :/ )

Comment by pmontra 1 hour ago

Giving up is a wise choice: there are so many other sites to interact with. On the other side they have only one refrigerator.

Comment by Telaneo 1 minute ago

I wish I could convince my grandmother of this.

"Why did the bank change the layout? I want the old one back!" - Don't like it? Change bank then. That's what I did.

I get that changing to another bank is a big unknown, but it's probably still worth it to show your displeasure. Plus her bank are morons when it comes to several other things.

Comment by dghlsakjg 1 hour ago

Next time I have trouble checking in on an airline site I’ll remember that there are so many other sites to interact with that whatever I was trying to do probably doesn’t matter.

I wouldn’t sweat the broken fridge either though, there’s so many other electrical appliances in the house to use.

Comment by natbobc 1 hour ago

Is entirely context dependent. I can agree in some scenarios but when it’s a utility or gov site that I can’t really avoid it’s less straightforward.

Comment by celsoazevedo 57 minutes ago

And now also a lot of young people. They grew up with iPhones and many think that "Wi-Fi" = "internet".

Keep it simple and light. HTML+CSS first, JS to expand functionality. Don't re-invent the wheel.

Comment by pugworthy 10 minutes ago

> Old people don't have that because they didn't grow up with computers.

You realize that someone who was 18 when the Mac was first released would be 60 now?

Comment by aidanbeck 1 hour ago

I was going to comment on the Terence Eden excerpt quoted by the author about the woman researching housing benefits on an old PSP browser, when I noticed that you (the OP) are Terence himself. It's strikingly powerful, and a reminder of the duty we have in building our infrastructure.

> Of course, your javascript-based analytics package doesn’t see the users you are bouncing because of javascript failures.

It is frightening to think of how many people are alienated from critical systems every day because of this bias reinforcing the idea that they do not exist.

Comment by genewitch 1 hour ago

just use firefox with an adblocker like adnauseam and a fairly decent chunk of the internet stops working, including chase.com and several other massive corp sites.

I can't imagine trying to use links/lynx or a browser with less market share than FF that isn't based on chromium.

Comment by nunez 1 hour ago

Chase works with ad blockers, though.

It doesn't work if you disable JavaScript...but it wasn't always this way!

They had a mobile version of their online banking service at https://m.chase.com that was EXTREMELY FAST and did 85% of what you need to do in an online banking portal (check balances, transfer funds). They scrapped it when they moved to their current bloated monstrosity of the portal that they have today.

It was a big reason why I moved to a credit union (who outsources their online banking services to Alkami, which maintains a very tight portal and supports 2FA AND passkeys!).

Comment by genewitch 1 hour ago

i am unclear on if it's because of the adblocker (specifically i use ad nauseam which does block some JS. some.) or because of firefox. I can load it on edge every time it fails on firefox. last week, chase.com worked fine on firefox. the previous 15 months where i needed to log in, it did not.

Someone at chase isn't checking their work on firefox.

Comment by enlightens 1 hour ago

FWIW I use Firefox with uBlock Origin and Enhanced Tracking Protection, and use Chase's website almost weekly. No issues that I've noticed on MacOS or Windows

Comment by nunez 1 hour ago

When I have to log into Chase on my computer, I do via Firefox, and it works fine. Maybe you flipped something on in about:config that's breaking it?

Comment by genewitch 58 minutes ago

i love that i'm holding it wrong. thanks, HN.

Comment by natbobc 54 minutes ago

And that is what pixel tracking is for. :)

Comment by Telaneo 7 minutes ago

I'm curious how many web issues can be solved by having the people responsible for the relevant sites only be allowed to use them on a Windows 11 machine with only 4 GB of RAM using Firefox with the network throttled to 3G speeds.

Assuming the processor isn't horrible, I can still browse plenty of sites with those specs without much issue, and on the sites that do require more, it's very rarely because the sites actually needs it (i.e. I'm not running Windows XP in a VM in the browser or something). It could just be normal HTML and CSS and normal forms, sprinkled with some light JS to help out a bit. But the amount of sites made with that level of care and attention are sadly rare, since the people responsible rarely feel the pain or have the empathy to fix the problem.

Comment by ungreased0675 2 hours ago

Empathy and respect for users is what product managers should be doing.

Shipping tens of megabytes per web page is impolite, if not outright disrespectful to users.

Comment by pier25 6 minutes ago

> Shipping tens of megabytes per web page is impolite, if not outright disrespectful to users.

You're being generous with what I would consider negligence.

Comment by HumblyTossed 2 hours ago

"If our users can't afford the bits, we don't need them!"

Comment by epolanski 2 hours ago

You're not a good and modern engineer who knows his craft if you aren't defaulting to react and tailwind.

And don't dare to contradict me, the fact that MIT-bred leetcode ninjas paid half a million per year can't produce a simple (mostly static) website on that stack it's only because of management that wants to ship the next product. /s

Comment by ai_slop_hater 2 hours ago

They don't know what a megabyte is

Comment by pier25 10 minutes ago

The consequences of MBs of JavaScript can be perceived by anyone in terms of performance and mobile data consumption.

Comment by jorisw 2 hours ago

They feel the slowness of the page load

Comment by alex_suzuki 2 hours ago

Not on their iPhones operating over 5G or the corporate WiFi.

Comment by afavour 2 hours ago

It's still present. JSON/JS parsing still has a delay. And in either case (as the author states) not everyone is using an iPhone over 5G. Heavy React apps are a miserable experience on low end Android phones, even when the connection is fast. I've seen JS/JSON parsing times in the multiple seconds.

Comment by jorisw 2 hours ago

There's 5 bars 5G and there's one bar 5G anyway... Citing connection types really is completely beside the point.

Comment by aziaziazi 1 hour ago

My old iPhone handles well react apps, but frequently freeze/crash on heavy advertised pages and pages with huge images/auto loading videos.

Comment by pier25 8 minutes ago

The vast majority of global users are not using iPhones.

Comment by jorisw 2 hours ago

You don't think there's any palpable difference as long as the connection is any good?

Comment by hamburglar 2 hours ago

I think there’s a palpable difference but many young developers have no concept of why.

Comment by shakna 1 hour ago

Salesforce and SAP are not fast, even on that. But ubiquitous for building corporate platforms for their customers.

Comment by kitd 2 hours ago

Read the article. Typical users had old browsers often with poor reception. One user was using a PlayStation Portable which had very limited WWW capability.

Comment by sarchertech 2 hours ago

The person you are replying to is saying the PMs are using new phones on WiFi, not that the customers are.

Comment by msla 1 hour ago

"What, support Safari? Isn't that, like, less than 20%? And its standards support is abysmal! No, not worth my time, they can upgrade to a normal browser like everyone else."

Comment by nonethewiser 2 hours ago

But if they dont, where is the disrespect? They dont know what a megabyte is, they dont feel a slow page load. Where is the disrespect?

React is too heavy weight for a lot of things. But it's ridiculous to call it disrespectful.

Comment by Ruarl 1 hour ago

If Rick Rubin could take a tape to his car to listen to his mixes, your product people can try their websites on £20 phones from Tesco. They can ask to sit in on user tests with minority groups. Extending your knowledge like this is trivial, but rarely done.

Comment by genewitch 1 hour ago

May i ask why, specifically, Rick Rubin? I don't know who that is, but whenever we finished mastering a new song, we had a series of "systems" we listened to it on. We went out to my dad's work van and listened there. We called up our friend with a street-comp sound system in his car, and listened in there (neighbors must have loved us!), and then a "cheap" boombox with large-ish speakers but cheap.

if it sounded "clean" on all 3, without the bass muffling everything, and the highs not hurting the eardrums, we called it "good" and released.

Comment by bgarbiak 55 minutes ago

Working in the music industry and not being aware who Rick Rubin is… is a bit weird.

Comment by nonethewiser 1 hour ago

Yeah but for those not using £20 phones from Tesco, where is the disrespect?

Comment by alok-g 22 minutes ago

+1.

I have been asked by someone in late 40s why uploading a video takes a lot longer than uploading a photo.

They are not dumb people. They just do not know.

The onus is on the engineers to design for them.

Comment by graypegg 2 hours ago

I haven't heard much about in a while, but the HTML Triptych proposal [0] is still something I hope to eventually land in browsers. HTML forms speaking to REST endpoints are a good pattern. (meaning user-aiding validation is handled via the input attributes, real validation is handled on the far side of the request, and the flow is GET /form => POST /thing => GET /thing/1) It would be a great pattern with the triptych features implemented!

[0] https://triptychproject.org/

Comment by t1234s 2 hours ago

Having been building websites since the mid 90's, I laugh at terms like "HTML-first website"

Comment by kkkqkqkqkqlqlql 2 hours ago

It's like chai tea.

Comment by jppope 21 minutes ago

  - shrimp scampi
  - Old Adage
  - chai tea
  - Naan Bread
  - Rio Grande River
  - Lake Tahoe
  - PIN/ VIN number
  - ATM machine
  - GPS system
  - Panini sandwich

Comment by wpollock 1 hour ago

The Sahara desert. It's not only repetitive but it repeats itself too as well.

These gems are brought to you by the department of redundancy department.

Comment by brandrick 41 minutes ago

Naan bread

Comment by calvinmorrison 1 hour ago

ATM Machine

Comment by mixmastamyk 1 hour ago

The La Brea Tar Pits => The the tar tar pits

My favorite from Southern California.

Comment by lproven 46 minutes ago

OK, I have to admit, that one I didn't know.

It's only a matter of time until someone posts "Torpenhow Hill" -- which does not exist.

https://en.wikipedia.org/wiki/Torpenhow_Hill

Comment by nonethewiser 1 hour ago

explain?

Comment by jp_sc 1 hour ago

"Chai" means "tea", so "Chai Tea" is "Tea Tea".

"ATM" means "Automatic Teller Machine", so "ATM Machine" is "Automatic Teller Machine Machine".

Both are mentioned in the animated movie "Spider-Man: Across the Spider-Verse".

Comment by thesuitonym 1 hour ago

Actually, in English, Chai does not mean tea, it means a specific flavor of tea. If you don't believe me, try ordering some Earl Grey Chai, see what happens.

Comment by adi_kurian 17 minutes ago

https://www.google.com/maps/search/england+chai+london/

Comment by 37 minutes ago

Comment by zhengyi13 1 hour ago

If your server is Indian, they'll likely react positively, and get you what you want.

Comment by pphysch 1 hour ago

Sure, but "chai tea" is still redundant. I have never used that term and ordered chai in many places without confusion.

Comment by genewitch 1 hour ago

it's redundant at a place that serves chai, but it isn't redundant at a place that does not serve chai, because you're skipping the "what is chai" question from whoever you're querying.

Comment by iamacyborg 1 hour ago

PIN number

Comment by pmontra 1 hour ago

Town names too: https://en.wikipedia.org/wiki/Montebello_della_Battaglia

Not in the Wikipedia page (but check the Italian version): it started as "Mons Belli" (Mount of the Battle) because of a battle fought by the Romans a few years before the Hannibal campaign. Then the original meaning was lost and it gained another "of battle" in the 1800s. Mount of the Battle of the Battle. Hopefully there won't be another one to add.

Comment by 1-more 59 minutes ago

Lake Tahoe (Lake Big Lake). River Avon (River River). https://en.wikipedia.org/wiki/List_of_tautological_place_nam...

Comment by dylan604 1 hour ago

Except places are now offering Chai Latte Coffee so if you don't specifically order Chai Tea Latte, you could get some thing totally different than expected. I learned this the hard way.

Comment by Zambyte 1 hour ago

> Chai, a word for tea in numerous languages

https://en.wikipedia.org/wiki/Chai

Comment by hamburglar 2 hours ago

Reminds me of “pre-jit”

Comment by re-thc 1 hour ago

ie "aot"?

Comment by addandsubtract 1 hour ago

I thought this article was missing a (1999) in the title.

Comment by naravara 2 hours ago

I’m sorry I can’t hear you over the Flash animation splash pages I was forced to sit through before being able to look up hours of operation.

Comment by danudey 1 hour ago

As a teenager I remember going to a website for... a city, I think? And their 'sidebar' was a Java applet that did nothing but provide links for you to click with on-hover effects. The page used frames; the applet was in the left-side frame and the content was in the main frame on the right.

The applet took 30 seconds to load. Once it loaded, it showed five buttons to click to get to different sections of the site. When you clicked on one, instead of changing the content frame, it sent you to an entirely new frameset. This, of course, caused the sidebar to take another 30 seconds to load. Hitting the back button did the same thing.

Meanwhile, I knew someone whose friend made a little applet that he showed me; it was a Java applet that you could provide an image URL for and it would load the image and then, below the image, show a rippling effect as though you were looking at something on the shore of a rippling lake. This applet took less than a second to load and ran incredibly smoothly.

Java was a curse, not because Java was bad but because Java applets were written badly and used badly simply because they were neat.

Comment by dylan604 1 hour ago

Every language can say that bad developers write bad code with it while good developers write good code with it.

I would like to say the early interweb was just a learning experience, but today's interweb hasn't learned any of the lessons. It's just changed which language the lesson is being relearned

Comment by LNSY 58 minutes ago

A lot of these tools, like React, are designed to embrace, extend extinguish the web. Why Microslop and Zuckerberg spend millions of dollars of dark PR claiming anyone who doesn't like React doesn't know what's going on is because it makes the web worse and less useful, which means you spend more time talking to Co-Pilot or bots on Facebook.

Comment by ErroneousBosh 1 hour ago

I did some work for a company that spent nearly a grand on a Flash animation for their title page of a red bouncing ball that would bounce from right to left along the letters of the word "Yipee" (yeah totally not ripping off Yahoo! were they?) until it landed in the crook of the Y, where it would spread down the middle - the finished logo had the Y made out of blue, yellow, and red stripes.

Every single person I showed it to including my then-70-something mother said "that just looks like menstrual bleeding".

Every single person said that.

They still went with it. Conversion rate? Dunno, never got numbers high enough to test the script.

Comment by thewebguyd 2 hours ago

Same, and it has certainly made me realize that I am now officially entering my "old man yelling at cloud" phase of my life, and I'm "only" 38!

Comment by faangguyindia 2 hours ago

Most of my apps are now simply HTMX + Go + SQLite.

I've found it's enough for most projects.

One of my sites is image heavy and serves 10 TB of traffic per month. For this, I use the following setup:

1. S3 (I wanted reliable data storage) 2. In front of it, I have Cloudflare (with Tiered Cache enabled, which makes POPs prefer pulling from Cloudflare rather than the origin). I've set rules to cache everything on both the browser and Cloudflare for 1 year, ignore origin cache policies, ignore query strings, etc., and I simply use immutable objects that require revisioning. 3. BunnyCDN in front

Cloudflare will not let you run an image heavy site on its own, so I use this approach to massively cut the bills. Their policy says you cannot use it primarily for images; it must be used for HTML, CSS, JavaScript, and other site content.

And if you run only S3, the bills will be huge.

But yes, lately I’ve been building mobile apps. PWAs are limited; the OS can evict IndexedDB storage, so I cannot offer people reliable data storage in the app without sign up or involving a backend.

What can I do? So I was forced to switch to Flutter on Android, but I ran into another pain point: app updates sometimes spend a lot of time "under review," which is frustrating. For the same app, I maintain a web app that is very quick to update by comparison.

I wonder why there isn't a mobile OS that simply lets you build apps with JavaScript, HTML, and CSS and gives you reliable storage without all this effort.

I like how quickly you can update PWA app.

Comment by wild_egg 3 minutes ago

On the mobile point, there is https://github.com/instawork/hyperview

Your Go server can have endpoints that render XML instead of HTML and basically get the same server-driven experience of your HTMX site. Fully skips the need for the app review process since you're not updating the actual client app code to make UI changes.

Comment by creesch 2 hours ago

> I wonder why there isn't a mobile OS that simply lets you build apps with JavaScript, HTML, and CSS and gives you reliable storage without all this effort.

There is! You just have to time travel all the way back to 2009 when webOS was launched by Palm. Time travel is the easy part, you then also need to somehow prevent Palms demise and webOS fading into obscurity as a smartphone OS.

If 2009 is too far back you can try your luck in 2012 with Firefox OS.

Joking aside, people and companies have given it a go. But a combination of bad timing and various other events never made that reality happen in our timeline.

Comment by paytonjjones 2 hours ago

Maybe I'm missing something but aren't PWAs pretty dead-simple on both iOS and Android? Maybe it's the "reliable storage" part that's the gap?

Comment by shakna 1 hour ago

The amount of effort that goes into keeping Termux barely functional, has a lot to do with Android and the platform making it harder and harder, to access a dev environment on a phone.

Running `npm install` on Android isn't so easy.

(Caveat: The new Android Terminal that only works on a handful of models.)

Comment by inigyou 1 hour ago

I thought I read that one or both of them removed or heavily restricted PWA support to funnel more apps to their 30%-taking app store.

Comment by inigyou 2 hours ago

Go is so awesome for server apps. I should have discovered it much sooner. It somehow sits in the exact optimal point having no bullshit overhead like C, yet also getting out of your way so you can focus on the business logic like Java (not Rust).

It's not great for every task - in particular the lack of abstraction-building capabilities - but it's great for business-logic-heavy server apps. It feels like it's specialized for that and not trying to be a jack of all trades.

Comment by shit_game 2 hours ago

>One of my sites is image heavy and serves 10 TB of traffic per month

I can't imagine this kind of traffic without acting as a CDN, advertising broker, pornographer, or part of a massive ecommerce site. I have to wonder, what are you doing that generates 10TB of traffic per month?

Comment by jimbokun 22 minutes ago

Where do you store the SQLite database files? What is your strategy for partitioning your data into SQLite files? One per user or…?

Comment by jimbokun 18 minutes ago

Developing webapps only for iPhone was Jobs original strategy. Only changed when developers complained.

Comment by bearjaws 31 minutes ago

> I wonder why there isn't a mobile OS that simply lets you build apps with JavaScript, HTML, and CSS and gives you reliable storage without all this effort.

Because there isn't a 30% walled garden you can create with that.

Comment by shakna 1 hour ago

> Cloudflare will not let you run an image heavy site on its own, so I use this approach to massively cut the bills. Their policy says you cannot use it primarily for images; it must be used for HTML, CSS, JavaScript, and other site content.

Pages has a 20k-100k limit on static files, but if they just guide you to R2 to offload it, which is still Cloudflare.

Did you mean the CDN? In which case, I'm not seeing that in the terms. [0] Though, I would have expected they'd have a similar thing. R2 resources don't generally count towards your cache limits.

[0] https://www.cloudflare.com/service-specific-terms-applicatio...

Comment by inigyou 1 hour ago

10TB is nothing these days. All Hetzner virtual servers in Europe have 20TB/month traffic included (excess less than $2/TB) and all their dedicated servers have unlimited fair use (which is probably about 200TB/month averaged over many months).

Comment by pragma_x 1 hour ago

Since you're using HTMX, I have to ask: do you have any tips or idioms for composing complex forms and UI without things getting out of hand? I love the approach, but I'm having a bad time figuring out where the ideal balance is between too few or too many HTMX-replaced areas in a page. Thanks.

Comment by pphysch 1 hour ago

My #1 advice is not creating separate server endpoints for every HTMX fragment, unless you are 1000% sure that endpoint will be used in multiple different pages.

Working on a "simple html page" that is actually 5 different independent "subpages" (routes, views, templates) in the backend is awful. The UX was improved, but the DX was sacrificed.

I recommend having a single view function for each page/SPA and do sub-routing within that function to handle page fragments. In other words, use a GET/path/Header parameter that indicates which fragment is currently needed, defaulting to the full document as normal. Just make sure you are considering request logging and client-side caching in your solution.

This makes it very easy to add/remove async content from the page, since you are just editing the one view function/template and you can easily reason about the entire page as one logical unit.

It also means you don't need to duplicate security logic or other middlewares for the page, since it can be implemented once at the start of your multi-faceted view function.

Comment by wild_egg 1 minute ago

Generally you don't even need to do the sub-routing in the handler. You can just render the entire page and have `hx-select` attributes pluck out the part that you want.

Comment by miroljub 2 hours ago

> Most of my apps are now simply HTMX + Go + SQLite.

Would like to hear about your Go stack for building htmx apps.

Comment by arnorhs 49 minutes ago

This post is good, and it's a great example of taking a problem and solving it with the appropriate tech with the right amount of depth. It really helps to have full domain knowledge of your customers as well.

However, I do not like how it is framed as "simple html is better than react" - because you could just as well have told the same story as a react developer.

(Nb. I could go on forever about the complexities and intricacies of storing things session based on a server vs browser based and etc - and lots of other things that were skimmed over in this article, but that would be too long)

All of those things that are simple in html are also simple in react.

It's literally the same code - there's nothing preventing you from using browser based html validation in react - all the same code that gets complicated in react (overly complicated validation logic) also ends up being complicated in astro - they have their own thing around schema validation etc and integrating it within an astro site means you have to integrate their client router etc etc.. so it's very easy to go overly-complicated there as well.

The comparison is also with an off-shore team doing development for you with probably incomplete knowledge and the way projects are structured they have an incentive to create the solution as fast as possible, in as little time as possible, with the biggest amount of complexity as possible.

The last point is devious - it's not necessarily that the contractor does this by design, but the incentive structure makes it so something that's overly complicated actually benefits them, so they don't have a direct incentive to go with something simple.

Anyways, a simple solution, directly addressing the problem at hand is always better - no matter what stack you pick.

(I'd like to say that I don't have anything against Astro's form validation, I was just trying to highlight how there's more to it than "native html browser validation")

Comment by wmanley 2 hours ago

The counterargument: In Defence of the Single Page Application:

https://williamkennedy.ninja/javascript/2022/05/03/in-defenc...

Comment by __natty__ 2 hours ago

Funny enough. I’m opening this on mobile internet connection and it stuck at loading spinner. I don’t know if the problem is with my internet (probably not) or support for mobile so I can’t even read the content.

Comment by frisia 2 hours ago

I think that's the joke :) all other articles load fine instantly, just this one that has a spinner

Comment by __natty__ 2 hours ago

Heh it got me then :)

Comment by alsetmusic 1 hour ago

Whoosh! Right over my head. I feel a little silly, but also, got me!

Comment by ErroneousBosh 1 hour ago

Got me too :-)

Comment by elmigranto 2 hours ago

My guess it’s a joke.

Comment by TSiege 2 hours ago

it's a sarcasm loader

Comment by sorenjan 2 hours ago

Sufficiently advanced parody is indistinguishable from reality.

Comment by Izkata 34 minutes ago

Ages ago when writing.com was first modernizing its site, they started by hiding story content to display a spinner, waiting a second or two, then re-displaying the content. It was on the page the whole time, they just made it look like it was loading in the background.

Comment by bryanrasmussen 1 hour ago

https://medium.com/luminasticity/on-the-triumph-of-satire-fa...

"Satire isn’t dead.

Satire won.

This is what it looks like from inside, looking out. "

Comment by pegasus 2 hours ago

All I got is a "loading" animation. Gave up after 10 seconds. So, not a counterargument, but a confirmation of the article's thesis.

Comment by tele_ski 2 hours ago

It's a joke/sarcasm

Comment by sodapopcan 1 hour ago

I wish I hadn't read the replies. I love being made the fool (though not to worry, I'll have plenty of other opportunities, likely today!)

Comment by 650REDHAIR 2 hours ago

I got wooshed.

Nice work!

Comment by bryanrasmussen 1 hour ago

Like most defenses of Single Page Applications it managed to make me angry, at least at first.

Comment by pkphilip 1 hour ago

I have to say that I hate SPAs. It is often a far worse user experience than the vanilla multi-page websites.

Comment by TSiege 2 hours ago

lol this got me

Comment by 1 hour ago

Comment by onion2k 1 hour ago

This isn't "We replaced a React app with an HTML form and performance improved." It's "We replaced a bad web page with a good web page and performance improved."

Attributing this to the technology driving the browser experience is silly. You can make a brilliant user experience with React. You can make a terrible website with plain HTML.

The improvement comes from the change design, not tech.

Comment by Aurornis 49 minutes ago

> The improvement comes from the change design, not tech.

You could argue that the constraints of using HTML-first (as they call it) helped them stay away from the bad patterns they were using before.

But you’re right: The user change came from fixing the design, not the technology used.

This is a lot like those bad resume bullet points where someone tries to claim an increase in business was due to their code change. “Increased visitor count 100% by rewriting website to be HTML-first”. Then when you ask them about that point they concede that the entire site was redesigned to fix some design problems or add a feature and that’s what drove the visitor increase.

Comment by lucumo 54 minutes ago

The standard answer to that is that some technologies make one harder than the other. That's kind of true from first principles, but it requires making the case that e.g. React is actually harder to make good than a plain HTML page.

Fun thing, TFA describes a kind of multi-page wizard style form that I haven't seen a lot anymore in the last decade or so. But when I did see it, it's always some dogshit enterprise system. Some Oracle product for expensing expenses last time.

The problem with those things always seems to be that they are slow in the middle of doing your task. Every button is seconds of waiting. Doubly annoying if you have to go back a step or two. The badly coded SPAs seem to be slow at the start. It takes a while to load, but once it's loaded its performance is usually okay.

Comment by iammrpayments 1 hour ago

Of course, is just what with React is 100x harder, and when you fail the fans will blame you instead of the technology.

Comment by entropichorse 3 hours ago

People who built a crappy website using React are just as likely to build a crappy website using Astro, HTML-first approach or any other technology

Comment by wmanley 2 hours ago

I disagree. An HTML website which uses links, forms, buttons and inputs will by default:

* Have working back/forward buttons * Have working progress indicator as provided by the browser * Show errors to the user - even if they are ugly * Be accessible to keyboard navigation

With SPAs these are all things the developer has to get right.

So often when using a SPA I'll click a button, you get a spinner and then nothing will happen. Is it still in progress? Don't know. Eventually I'll open developer console and trace the network requests to find the JSON HTTP request that returned "ERR_BAD_EMAIL" and fix what I've entered. With a normal form submission at least the user will see the error message and can press back and then fix it.

Comment by adjejmxbdjdn 2 hours ago

True. Crappy developers will build crappy websites irrespective of the tech.

The article is clearly aimed at non crappy developers or developers who want to do better for their users.

And it provides an anecdotal experience where an HTML first option developed by a good developer was far superior to what a JS necessary option would have been, given the user base of this application.

Comment by someonebaggy 3 hours ago

At least it'll be a fast and crappy website.

Comment by nicoburns 2 hours ago

It's definitely possible to make slow server-rendered website. Most of the slow client-side apps are slow because they're waiting on slow network requests.

(I still very much support fast, simple HTML websites. The good ones are a fantastic user experience)

Comment by trashb 2 hours ago

but the host (the company) will need to pay the price in the form of server equipment. Not the user as is the case with client side rendering. If server side rendering becomes slow it will affect all users regardless of their hardware or connection, prompting earlier response from management and devteams.

Comment by nicoburns 2 hours ago

The cost difference between client-side and server-side rendering is pretty non-existent these days.

Comment by cyanydeez 3 hours ago

yeah, I love when shit loads immediately, so I'm not wasting seconds of my life just to see shit.

Comment by hyperhello 3 hours ago

You can do a bad job with any tool but you cannot do a good job with any tool.

Comment by swiftcoder 2 hours ago

This is patently untrue, give a craftsman terrible tools, and they'll still produce a decent end result. That said, defaults matter, and astro is going to be significantly more friendly out-of-the-box to low-end clients

Comment by whstl 1 hour ago

> give a craftsman terrible tools, and they'll still produce a decent end result

This is an absurd statement. Just because something is a proverb, doesn't mean it's automatically true for all cases.

Comment by elxr 1 hour ago

I agree. Server-rendered React can also send down 100% HTML apps.

But I 100% see where the author's coming from, considering the massive fragmentation of react codebases/patterns and decision paralysis of React development in general. I really doubt most React apps, even the more accessible ones, are testing their multi-page form wizards with JS completely turned off.

HTML-first does seem highly underutilized in the commercial web, and I learnt a lot from reading this (as a solidJS/react dev).

Comment by manuhabitela 1 hour ago

I find it's way easier to build crappy React apps than an HTML-first approach.

An "old school" Ruby on Rails/Symfony/Django app, with templates, usual get/post forms etc, frames you and pushes you in using the standards and relying on browser default behaviors.

In JS-heavy apps, it's as easy to code normal `button` elements as it is to code clickable `div` elements. But with the divs you just forget to handle keyboard nav, proper element roles, etc. It's easy to create fake links, not relying on `a` tags, using an internal JS router that doesn't expose URLs, doesn't handle middle click mouse, for no particular reasons.

In less JS-heavy contexts, the easiest way to do is to use proper HTML so you are less inclined to mess up.

Even on codebases that use a decent framework like Next.js that handles those for you on paper, it's often we see people not very aware of the benefits of using proper semantics and standard behaviors, and you easily end up with web apps with poor UX in the end.

Comment by malteg 2 hours ago

true, but where can I find the smallest functional react website where react is needed...?

Comment by TSiege 2 hours ago

with this logic, why discuss any technology?

Comment by afavour 3 hours ago

Not really, no. Astro requires you to opt a component in to client-side rendering, React (with its server components etc) require you to opt out. Defaults matter in scenarios like this and I'd bet the average developer of crappy websites would have a much faster site with Astro than React for that reason alone.

Comment by whstl 1 hour ago

Small correction: it's other frameworks that require you to opt-out, most notably Next.js. Although I've been seeing so many people confusing Next.js with React lately...

Astro itself works just fine with React, and it can still be HTML-only.

But you can also render React on the server yourself using renderToString, if you don't want a framework.

Comment by bschmidt300 2 hours ago

[dead]

Comment by callumprentice 1 hour ago

Excellent article but I am always torn when I read inspirational articles like this - it makes perfect sense to me and I love the idea of simple, non-nonsense sites that work well, load quickly and don't rely on the latest browsers to function.

Then I start to wonder if that's just because I'm not smart enough to understand React or whatever the fancy technology of the day is.

Feels like I have a hard understanding threshold that cannot be breached - give me a simple editor like Sublime and ask me to make a web page - even with JavaScript - and it's my happy place. Give me VSCode or Zed, Claude/Copilot/ChatGPT plugins everywhere, React tutorials and my brain goes to mush.

Comment by thesuitonym 1 hour ago

If it makes you feel any better, the people using the fancy frameworks and whatnot usually aren't smart enough to understand them either.

Comment by LNSY 1 hour ago

I love the web. I hate what the React cretins have done to it.

Embrace Extend Extinguish is real, and the people going along with it deserve to be replaced by a LLM that lies and spits out garbage code just like they do but faster.

Comment by elxr 24 minutes ago

React has helped folks like vercel/convex/cloudflare to build fantastic dashboards. There's just as many examples of well done React as there are the opposite.

I generally prefer solidJS nowadays, but the react ecosystem has enabled lots of amazing user experiences (and developer experiences too if you don't fall into the trap of overcomplexity).

Comment by bastawhiz 1 hour ago

I'm not convinced from the article that HTML-first was the thing that fixed the problem. What fixed the problem was 1) the person building it knew what they were doing and 2) it had design constraints from the get-go to be user-friendly. You can do that with React. It's arguable whether it's easier or better, but you can get there regardless of the approach you use.

Comment by yawaramin 16 minutes ago

1. Presumably the team that made the previous app also thought they knew what they were doing. Presumably they were not hired on the assumption that they couldn't make a good app.

2. The design constraints had always existed, the previous app just failed to meet them.

Comment by neya 45 minutes ago

Sadly, this is the story of nearly every React project I've reluctantly inherited. In my experience, it's because React is not opinionated like its peers Vue and Svelte. So, a bunch of devs will use something for state management and and another team will use something else completely. Eventually both teams leave after making a mess. But, if you look at the graphs and numbers that MBAs chase, they will all look like everyone was productive until the very last minute. The ultimate casualty is unfortunately the user. Even Facebook hasn't figured out React across their properties. Just use Instagram / Facebook on the web. Bunch of spinners to load a static list of items in a drop down menu. Not even joking, click on the bhamburger menu on Instagram web. It makes a dozen requests, shows you a loading skeleton and takes 5 seconds before you can see a finite list of menu items. Ironically Facebook was super popular in the 2014s because they didnt have much React based BS going on. Everything was just good old hyperlinks.

If the creators of React haven't figured it out, what makes you think you can?

Comment by sjtgraham 2 hours ago

I built apps like these on GOV.UK over 10 years ago for the Ministry of Justice. We built our own form wizard library that let us validate long forms in steps and break them out into multiple pages because Ruby on Rails didn't support doing that out of the box. It was a very important principle back then that everyone should be able to make use of these digital services regardless of whatever users were using to access them.

Comment by initramfs 1 hour ago

I've always liked basic HTML pages where one can upload a document without having to restart the entire application. That's a great practice you have there with general forms. With each session ID, it can cross reference a page in a multi page application with that session ID, so that the user can maybe type it in if necessary, but it should be able to determine that with enough information, like IP address, upload date, browser, OS and so on. But the most accurate session would be within the browser so that the cookies for a single application aren't mixed up with another applicant, like a relative, who might be using the Playstation Portable.

Comment by miki123211 24 minutes ago

How many people are using browsers which don't support Javascript in 2026, and doing so out of necessity rather than out of choice? I can't imagine this number to be >1%.

How many such devices can still support modern TLS certificates anyway? By this logic, shouldn't we also use plain HTTP instead of TLS?

Comment by munificent 21 minutes ago

It may only be 1%, but that small fraction of users are also probably the people who sure as hell don't need even one more tiny thing going wrong in their life.

If you're using a decade old phone to sign up for a utility, you've got bigger problems in your life and no self-respecting person should be adding to them.

Comment by Dwedit 1 hour ago

There is one hard wall that stops very old clients from connecting: Not supporting a new enough version of TLS. TLS 1.2 is from 2008, and TLS 1.3 is from 2018. Web browsers older than 2008 can't connect to modern websites since TLS 1.0 and 1.1 were deprecated from web servers in 2021.

Comment by 0xpgm 2 hours ago

Don't tell me were going to rediscover progressive enhancement all over again after more than a decade. Back when we used to actually care about the end user whether you were programming frontend or backend.

Too much VC money and big tech influence in the JS ecosystem made the web worse in some ways.

Comment by ecshafer 1 hour ago

I am not familiar with this astro framework they used. But having built some sites using Pure HTML/JS back in the day, React, Angular, Vue, Rails ERB, Rails Hotwire, and HTMX. I think HTML first websites are absolutely the way to go. Rails Hotwire with View Components makes rails sites super fast, faster to develop and easy to re-use components. HTMX more generally, but Ive used it with Spring boot and Thymeleaf. I really don't want to go back to SPAs. Development time is less and the website performance is better, and I haven't really seen any regressions in capability. With HTMX and some url parameters, I can make a pure HTML site that seems like a Single Page Application but without the excessive loading times.

Comment by xavortm 1 hour ago

I first tested Astro on my site and never went back. Now every new project defaults to Astro and I have to have a reason not to use it. So far no reasons. It's simple, fast and it kinda fits my desire to keep things minimal. For example, yes, page content matters, but all but one page on my site is under 10kb, most hovering in the 3-4kb range (100% of the downloadable content)

Comment by Shellban 1 hour ago

I like JavaScript-light websites just as much as anyone (my own website works on the same principle). However, I do wonder how much of the increased traffic has to do with AI agents that now have an easier time working with the more standard web forms. My own contact form had a bunch of bots quoting Scorpion lyrics before I added a rate limiter.

Comment by yawaramin 13 minutes ago

None of the increased traffic was from AI agents. FTA: 'The results? When we launched, the number of people completing the form doubled.'

All completions were real people. It's a government website.

Comment by initramfs 1 hour ago

This is such a great story. I am glad more people are sharing stories like this. I hope my article the other day inspired more to develop lightweight websites:

https://inavoyage.blogspot.com/2026/06/im-building-parallel-... https://inavoyage.blogspot.com/2026/06/how-about-new-java-ba...

Comment by ninalanyon 1 hour ago

The quote from Terence Eden almost made me cry. Actually the whole article did.

Comment by gcity123 33 minutes ago

same that quote got me emotional ngl

Comment by sethammons 1 hour ago

> When we launched, the number of people completing the form doubled. The analytics people didn’t even know where these users were coming from. Of course, your javascript-based analytics package doesn’t see the users you are bouncing because of javascript failures.

Yeah, reminds me of the b52 story re holes in wings on the planes that made it back from missions, leading them down the wrong path of strengthening wings. They weren't looking at the planes that never came back with holes in the fuel silages.

Comment by Havoc 44 minutes ago

Yeah the uk gov website is indeed petty damn good. For once all the money dumped into studies and what not produced an outcome.

Comment by jrochkind1 2 hours ago

> this was a regulated monopoly, and if their customer satisfaction dropped below 96% (if I remember correctly) it could result in millions of pounds in fines.

OK, I'm still at the beginning and irrelevant to the article, but as a USA-ian, I am so jealous about that. Unheard of here.

Comment by Uncle_Brumpus 1 hour ago

That hit me, too, specifically thinking about my current gas/electricity provider. I have not heard one single piece of positive feedback from the public, and there's only ever problems. I feel like that's a pretty universal experience here. Even outside the scope of websites, it holds so very true.

Personal anecdote: Recently they were updating everyone to "smart meters" on the gas lines. They needed me to be home so they could enter my apartment and bleed the gas out of the line by turning on the stove prior to replacing the meter. I played phone tag with them for 6 months, setting up countless appointments, and nobody ever showed up, the meter remains un-upgraded. At the same time, I have received weekly phone calls and monthly physical letters stating that if I don't upgrade the meter, my gas will be shut off. I just moved, so the new tenant will have to deal with it now.

Comment by Quarrel 2 hours ago

I moved to the UK in 2016.

The public sector, simple, no frills, accessible, no flashy graphics, websites were a massive eye-opener.

They just worked. They had a job. They did it. I wasn't going to buy more from them because of it, and they didn't care. It was great.

I've heard that recently they've dismantled the centralised team that wrote all the rules, enforced it, and started moving to decentralised hosting, but so far the whole still seems to hold to together really well. I think, I hope, they have embedded the expectation that the local council, the tax office, your visa status, etc, should just be utilitarian in nature, and work for everyone.

I worry how long it will last...

Comment by freedomben 3 hours ago

Good post, but:

> A venerable web application pattern that has had a small modern renaissance thanks to Remix

Remix is not that popular. I don't think attributing this to remix is accurate. Next.js quite possibly.

Comment by simonw 3 hours ago

The full context of that quote makes it clear that it's meant more as a wry joke:

> A venerable web application pattern that has had a small modern renaissance thanks to Remix, form submissions and redirects took a while to explain to my colleagues, on account of everyone being used to heavily client-side web applications.

(Although it's not really a joke, it's pretty amazing how many professional web developers these days don't know how to use forms without JavaScript.)

Comment by someonebaggy 3 hours ago

The opposite is why I'd never be a good web developer. I grew up messing around with PHP and if I spent the time to learn the modern stack, I'd constantly be thinking it's stupid.

Comment by dormento 2 hours ago

I can relate to that.

I recently had to intervene during the latest office holy war to explain that you don't need JS for file uploads.

It was eye opening.

Comment by afavour 3 hours ago

I think the author is suggesting that Remix was the inspiration for the renaissance, not that it's necessarily the most popular method for doing so.

I'd be curious to see the stats on how often Next.js users lean into the server component model that makes the frontend fast. My anecdotal experience is that it's an afterthought for many. By comparison, Astro (as mentioned by the author) makes you think about this stuff upfront via opt-in rather than opt-out. It's a wonderful framework.

Comment by arowthway 3 hours ago

Opt-in = action is required to opt in = off by default.

Comment by pspeter3 3 hours ago

I think Remix brought back interest in Form Actions and other meta frameworks took inspiration from that.

Comment by epolanski 1 hour ago

Remix has been nonetheless influential in the space, in the same way preact and signals have been.

Comment by skybrian 1 hour ago

What do people like for form validation?

In this article he recommends the “validation-enhancer” library:

https://www.npmjs.com/package/validation-enhancer

I’ve also seen one called “formisch” that the author of valibot is working on:

https://github.com/open-circle/formisch

They’re both pretty new. Has anyone tried them?

Comment by kccqzy 1 hour ago

My biggest tip to reduce complexity of data validation if you are using React is to stop using React controlled components and switch to React uncontrolled components. They are an underused part of React. You usually don’t need React to handle every single keypress and every single character being entered by the user. In fact before React popularized it, it was unusual for form components to update on each key press; traditional desktop apps tend to validate when a field loses focus only, not on each key press. This has at least three benefits: (a) good for performance, (b) reduces unnecessary error UI when the user is in the middle of entering data, and (c) simplifies your own code by not having to deal with prefixes of valid input that’s not itself valid.

Comment by yawaramin 9 minutes ago

Also allows user scripts to interact with the forms, eg I can run a bookmarklet to fill out certain forms. With React controlled components all these changes are wiped out and reset with the state that React has in its app memory.

Comment by simonmysun 1 hour ago

Hmm I cannot load the font on Firefox 151.0.3 Arch Linux. All I see is only a title and empty paragraphs. So I end up reading the article in the source code mode and felt pretty on-brand.

Back to HN comments it looks like this wasn't actually intentional?

Comment by ErroneousBosh 1 hour ago

> Arch Linux

You've only got yourself to blame, there.

Comment by danielrhodes 1 hour ago

I've tried this before and I think this constraint is something that has to be kept top of mind for a designer not just the engineer. Most designs these days assume a single page app and there are interaction patterns that make plain HTML not suitable. But if you incorporate this in from the start and stick with it, there's no reason you can't do this.

Comment by hiccuphippo 1 hour ago

Can anyone confirm if Web Components work in the old psp web browser?

Comment by Shitty-kitty 58 minutes ago

I'm not a web dev and my needs are pretty simple but I've had a lot of success with jekyll. It's a open source static-site generator.

Comment by IFC_LLC 2 hours ago

I've started getting traffic on my website only after I re-build it with a locally-brewed MD parsing engine that uses Astro to spit out the final version of the site.

I guess the main argument is how easy it is for an LLM to ingest the content, since I can bet all of the crawlers are llm-enabled one way or another.

Comment by NopIdoN 2 hours ago

> […] it always worked even without javascript. He was appalled and said, “but that’s a lot more work for us.”

Is it more work?

Comment by dirkc 2 hours ago

My go-to for spinning up a site has been Jekyll + Bootstrap with the occasional bit of React for well over 10 years now.

While it still does the job, I'm a little curious to explore more modern options, if for nothing else to understand the choices a more junior dev would face/make today.

I'm seriously considering giving Atro a go. Is it worth it?

Comment by kcrwfrd_ 2 hours ago

Yes

Comment by dirkc 1 hour ago

Guess I should have stated the questions as "what makes Astro worth while to try out?" :)

Comment by theandrewbailey 2 hours ago

> Javascript and modern CSS should be used to enhance the experience

When messing around with my blog's Javascript, this mantra is so thoroughly embedded into writing it, that I try to include "enhance" in function names where it makes sense. I might have to do likewise with my CSS.

Comment by tootie 3 hours ago

I was a little confused by "doubled our users" since that's more about inbound traffic than site experience. I guess it's really shorthand for "halved form abandonment" which is still pretty great.

Comment by yawaramin 7 minutes ago

Doubling conversions, in digital marketing-speak. Marketing firms probably give out fat bonuses for this kind of result.

Comment by yCombLinks 2 hours ago

Users visited the site and couldn't even begin the form, nor get seen as a visitor, due to javascript metrics and rendering failing.

Comment by myself248 2 hours ago

I think that's even more significant, since it's measuring people who cared enough to click the form in the first place, which is juicier than just page loads.

Comment by robofanatic 2 hours ago

may be he meant, doubled our users who actually submitted the form

Comment by Zak 2 hours ago

All the text is invisible for me in Firefox on Linux when the `--font-body` is set to `"Atkinson", sans-serif`. Setting it to `"Atkinson Hyperlegible", sans-serif` fixed it.

Comment by simonmysun 1 hour ago

I read the article in the source code mode and thought it was intentional until I came back to the comments

P.S. your solution seems to have disabled the custom font instead of fixing it

Comment by Zak 10 minutes ago

You're right. Seems like it fails when the font is correctly selected. Another machine running Firefox on Linux didn't have a problem.

Comment by fd-codier 1 hour ago

Nice clickbait title.

Comment by James_K 19 minutes ago

I will never stop singing the praises of plain HTML. It's accessible, it's portable, it's simple, but for some reason we need horrid JavaScript nonsense to operate.

Comment by masa-kozu 2 hours ago

Designing for failure modes (bad network, old devices, no JS) often leads to better systems even in the happy path. This is a good case study of that.

Comment by fisherwithac 2 hours ago

[dead]

Comment by nobleach 2 hours ago

Recently I had to migrate an old SpringBoot app that had a React front-end to a new cluster. Not wanting to mess with super-old dependencies, I opted to rewrite it on a new version of Java/SpringBoot. When it came to the frontend, I paused. I couldn't come up with a single good reason why this app needed React. I rewrote the frontend in straight HTML with a little bit of JavaScript for DOM manipulation. I literally used `var` instead of `let/const` just to drive the point home... (yes, that was overkill). But you know what I didn't need? A BUILD PROCESS! No npm deps. No vite/rsbuild/etc. It was like I had forgotten we could even DO that.

Don't get me wrong, I actually have enjoyed React over these past 10 years. But, including it blindly is just silly.

Comment by Natfan 2 hours ago

esm.ah let's you include "complicated" JS that isn't usually found in CDNs.

it doesn't work for everything and imo is worse for (p)react due to the lack of native JSX, but it does allow for bringing in stuff that usually takes an `npm install && npm build`

Comment by melon_tsui 2 hours ago

Interesting they went with Astro.Makes sense for a form-heavy site. No JS until you need it,and it handles page transitions cleanly.

Comment by nilirl 1 hour ago

I understand people need to make arguments for things they like but provide more please.

What were some of the downsides? Illuminating the tradeoffs would elevate this post from good to great.

Comment by aidanbeck 1 hour ago

The downside mentioned by the author's replacement in the article is the unfortunate explanation for why this is rare in practice.

> "but that’s a lot more work for us."

And it's not that any individual or team is lazy. Most teams have a constant barrage of priorities to balance and are paid by companies valuing efficiency over everything. That said, I think the article makes a great case for adjusting our prioritization. Going a bit slower won't kill anyone, in fact doing so will probably save some.

Comment by drchaim 2 hours ago

I wish more people take this approach, specially public services.

Comment by joelanman 1 hour ago

UK government services guidance is to use progressive enhancement

https://www.gov.uk/service-manual/technology/using-progressi...

Comment by 6510 36 minutes ago

It will still work 30 years from now! 300 years! 3000 years. There will be no strange error messages in the log, no browser updates breaking stuff.

Personally, rather than this luxurious approach, I just do one giant form and store all values in local storage. If something is wrong have one message at the top listing which fields failed validation and why. Generate some css to put a red border around the fields.

Local storage might not be a good idea for such sensitive data but if you can get away with the simplicity it's lovely.

Comment by regnull 1 hour ago

> When we launched, the number of people completing the form doubled.

I don't want to be that guy, but the title is misleading. The number of users completing the form doubled.

Comment by yawaramin 3 minutes ago

No, it's actually people. FTA: 'My client was a utility company, and they had a big problem. To apply for their services, customers could either use an old ASP form on the website...'

Ie customers of the utility company were completing the form, not random users from the internet.

Comment by qsort 2 hours ago

If you're a "React person", as the article puts it, friendly reminder that you can render components to HTML and serve that to the user.

I have done exactly that on a project that was under similar constraints. The UI models live in .tsx files and the browser gets pure HTML with zero JS by default.

Comment by malteg 2 hours ago

in the bio ... "has over twenty years of experience building highly accessible and usable web applications"

why not take the html5 standard (see https://html.spec.whatwg.org/ ) and if needed (dont think so for these use cases... "for clients ranging from energy companies to political parties") htmx or alpinejs ...

Comment by ernsheong 1 hour ago

Everyone reinventing what Rails has been saying all along...

Comment by ElijahLynn 1 hour ago

Beautiful story!

Comment by brianwmunz 2 hours ago

Maybe this is heretical in today's AI hype climate but...weirdly due to the rise of AI, then AI-slop polluting everything, a lot of old fundamentals are coming back. Clear, well-structured, descriptive content on a well-built page has a better shot of being picked up for SEO/AEO/whatever which are the same best practices from 2005. A lot of these tips and tricks and hacks just aren't going to move the needle as much anymore imo.

Comment by kijin 2 hours ago

SEO and accessibility laws have always been the most effective way to convince someone to build clean, well-structured webpages. Guess what, both are measures of how easy it is for a machine to extract content from your pages. AI is just the latest machine that wants to slurp up your soup of tags.

Comment by etaioinshrdlu 1 hour ago

It's true. Also, if you despise bloat, you may like my JS-free LLM site: https://ch.at/

Comment by skylovescoffee 2 hours ago

"I took a very bold decision and built a new version of the site using Astro"

Comment by oybng 2 hours ago

It shows just how far gone webshit is when the obvious must be stated time and time again

Comment by oulipo2 2 hours ago

Totally agree, gov pages should be widely accessible. Also gov services should NEVER mandate internet access. There should always be a way for tech-illiterate people to ask someone, and fill their forms

Comment by yawaramin 2 minutes ago

FTA: 'To apply for their services, customers could either use an old ASP form on the website, or follow a manual process.'

Comment by TZubiri 31 minutes ago

>She’s connected to the complementary WiFi and is browsing the GOV.UK pages on Housing Benefit. She’s not slicing fruit; she’s arming herself with knowledge.

>The PSP’s web browser is - charitably - pathetic. It is slow, frequently runs out of memory, and can only open 3 tabs at a time.

Alluring, an annoying property of private software development is that making websites and software in general inaccessible to lower end hardware is actually a positive effect, as it filters out 'undesirable' lower-income prospects.

That, along with pressure to produce fast, without much concern for quality (with notable privileged exceptions of luxury software like Apple or 1B+ user software like Google), as well as a disregard for sourcing "I don't care if you do it yourself, or npm install software from effectively unpaid volunteers", ends up in a state of software lacking craftmanship, software that one is not proud of to work in.

Comment by hit8run 36 minutes ago

So funny to me that the kids nowadays are rediscovering HTML lol.

Comment by tgtweak 2 hours ago

It'll be replaced by a new react app within a few hires lol

Comment by bschmidt500 2 hours ago

[dead]

Comment by romanovcode 3 hours ago

[flagged]

Comment by rafram 2 hours ago

No we don't. There are lots of countries with software outsourcing industries, and contractors in any country can be good or bad. Would you rather have a top IIT graduate, or someone who took a year of programming classes at a community college in Fresno?

Comment by black6 2 hours ago

Considering the rampant fraud in a certain country's university system, give me local CC graduates.

Comment by rafram 2 hours ago

As opposed to the US, where nobody ever cheats in school?

Comment by conductr 2 hours ago

Idk, the general javascript spinner situation is beyond normalized at this point. I think mainly driven by React and other large/overkill JS frameworks. I avoid JS/TS heavy stuff so I don't really know but that's largely the impression I get. The whole thing reminds me of dialup era internet were we all were watching progressive JPGs load on a slow connection despite the fact I have fiber. I can't believe anyone is Ok with that UX, I don't see how any framework choice justifies introducing that type of behavior.

Comment by yakshaving_jgt 2 hours ago

> The problem was clearly this excerpt because we all know which country it was.

Oh yeah? Which?