Having been building websites since the mid 90's, I laugh at terms like "HTML-first website"
It's like chai tea.
Building an HTML-first site doubled our users overnight
91–100 of 605 posts
Re: Building an HTML-first site doubled our users overnight
#92Empathy 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.
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
Re: Building an HTML-first site doubled our users overnight
#93Earlier quoted context omitted.
They don't know what a megabyte is
They feel the slowness of the page load
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.
Re: Building an HTML-first site doubled our users overnight
#94I 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.
Re: Building an HTML-first site doubled our users overnight
#95Good 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.
Remix has been nonetheless influential in the space, in the same way preact and signals have been.
Re: Building an HTML-first site doubled our users overnight
#96Re: Building an HTML-first site doubled our users overnight
#97Hmm 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?
Re: Building an HTML-first site doubled our users overnight
#98Re: Building an HTML-first site doubled our users overnight
#99I 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 acce…
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.
Re: Building an HTML-first site doubled our users overnight
#100People 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
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.