Building an HTML-first site doubled our users overnight • Hacker News Board

Re: Building an HTML-first site doubled our users overnight

#401

Post by aturek » Wed, Jun 10, 2026, 7:40 PM UTC

faangguyindia wrote: post #50

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…

I've learned about several frameworks that are system language + web frontend. The general approach is, ship a small binary compiled for the specific platform, and use the platform's native browser (and whatever html frontend tech you like) for frontend. The whole binary can be 1mb or less.

There's a couple of Rust libraries like this; right now I'm building an app in Tauri+Svelte.

It looks like Wails might be a similar framework in Golang.

Re: Building an HTML-first site doubled our users overnight

#402

Post by casey2 » Wed, Jun 10, 2026, 7:45 PM UTC

We are still in the early days of software and web development. This is the food service equivalent of a restaurant operator discovering that if they serve dog poo vs edible food they get more return customers.

Re: Building an HTML-first site doubled our users overnight

#403

Post by flufluflufluffy » Wed, Jun 10, 2026, 7:47 PM UTC

> form submissions and redirects took a while to explain to my colleagues, on account of everyone being used to heavily client-side web applications.

Ah yes, when you have to explain to your esteemed web developer colleagues how the web works xD

Re: Building an HTML-first site doubled our users overnight

#404

Post by rescbr » Wed, Jun 10, 2026, 7:54 PM UTC

6510 wrote: post #240

concinds wrote: post #215

Earlier quoted context omitted.

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.

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 elm.textContent="loading images" 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…

Oooh! Like a status bar!

shit, I'm too old to remember those...

Re: Building an HTML-first site doubled our users overnight

#405

Post by Lio » Wed, Jun 10, 2026, 7:58 PM UTC

ecshafer wrote: post #116

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 r…

Yep Hotwire and Hotwire Native are amazingly useful tech.

Re: Building an HTML-first site doubled our users overnight

#406

Post by youngtaff » Wed, Jun 10, 2026, 7:59 PM UTC

autoexec wrote: post #224

atoav wrote: post #180

Earlier quoted context omitted.

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…

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.

Ikea relies heavily on Edge Side Includes, assembling static pages from parts at the CDN level and then having small islands of JS interactivity

Re: Building an HTML-first site doubled our users overnight

#407

Post by arkmm » Wed, Jun 10, 2026, 8:08 PM UTC

arnorhs wrote: post #212

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 an…

Seems like LLMs embrace that last point as well.

Re: Building an HTML-first site doubled our users overnight

#408

Post by kristianp » Wed, Jun 10, 2026, 8:14 PM UTC

Related recent threads about react performance:

JavaScript-heavy approaches are not compatible with long-term performance goals 178 points by luu 3 months ago | 237 comments https://news.ycombinator.com/item?id=47029339 (should be called "Why React is not compatible with long-term performance goals")

Does anybody like React? (jsx.lol) 242 points by brazukadev 15 days ago https://news.ycombinator.com/item?id=48274077

Re: Building an HTML-first site doubled our users overnight

#409

Post by acdha » Wed, Jun 10, 2026, 8:14 PM UTC

victorbjorklund wrote: post #390

OskarS wrote: post #165

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 components for the form,…

It is harder to do more with less. There is a reason React and other is used so much. Makes it easier to make interactive websites. It’s like asking why backend engineers think it’s harder to code an api using C instead of using Django.

I used to think that was true but I now think it’s only true for very interaction-heavy apps: if you have hundreds of interactions on a page over many minutes, using an SPA is amortized across a lot of time, but if it’s something you could do with e.g. a simple Django app you’ll not only be done faster but will spend an order of magnitude less time on maintenance and accessibility work.

Re: Building an HTML-first site doubled our users overnight

#410

Post by eestrada » Wed, Jun 10, 2026, 8:17 PM UTC

mplewis wrote: post #380

eestrada wrote: post #371

Earlier quoted context omitted.

Can't vouch for it's effectiveness, but Hotwire Native might meet the needs for mobile paired with plain HTML. Despite the name, it doesn't seem that using Hotwire for the web UI is necessary to use Hotwire Native. I could be wrong about that though. https://native.hotwired.dev/

Hotwire doesn't work anywhere you can't guarantee a high-quality low-latency connection. Every UI interaction in Hotwire includes that round trip.

That's pretty much true of HTMX too (which is what GP mentions using). I mention Hotwire Native (different from plain Hotwire) because it makes it easy to wrap a web app as a mobile app. Then you can replace performance critical parts with native views, but keep everything else working through the web app portion. This is easier to maintain, albeit with the downside that everything requires network round trips. Depending on you use case, that may be an acceptable tradeoff.