Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building an HTML-first site doubled our users overnight

mohkohn.co.uk

Post reply on HN
Print view View original

371–380 of 605 posts

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

#371

Post by eestrada »

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…

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/

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

#372

Post by zzo38computer »

I think it is a good idea. JavaScripts and CSS can enhance it but should not be required.

Accessibility functions are also helpful; if designed well then it would be helpful for everyone (not only if you are blind or other disabilities), in many possible circumstances.

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

#373

Post by gosub100 »

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

I'm risking being wrong here, but I think the difficulty is getting conforming behavior across all device and browser combos.

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

#374

Post by lucumo »

andersmurphy wrote: post #308
lucumo wrote: post #204

Earlier quoted context omitted.

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

Is it slow though? Like in practice? This demo [1] using Datastar (a streaming HTML framework) every action including scrolling roundtrips to the server. Even the checkboxes changing colour is a roundtrip. https://checkboxes.andersmurphy.com

The advantage of SPAs, like the checkboxes page, is that they can do the round-trip less visibly. The user can still continue the next thing. So even if it is slow, it's less of a deal than loading and rendering a page anew.

> Is it slow though? Like in practice?

The multi-page wizards? The ones I've seen were. Enterprise crap systems.

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

#375

Post by simpaticoder »

kstrauser wrote: post #358
simpaticoder wrote: post #174

Earlier quoted context omitted.

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.

90% of the SPAs I use could be Django/Rails/Flask apps with no noticeable difference, other than that they'd be many times more responsive on slower devices. "Old" SSR apps are mature, not obsolete. It's ridiculous when they're not considered even when they'd be the right tool for the job. I wouldn't try to clone Google Docs in Django, but something like Linear could 100% be modeled as a CRUD app with new page loads…

I agree but you and I aren't the audience and I think experts in general should be a little more holistic when critiquing other people's choices. For any given problem there always exists a perspective from which your solution is over-engineered. People who (like us, I presume) understand processes, files, the command line, compilers, a computer language or two, a bit about computation theory (e.g. Turing, big-O, Knuth..) can get to a very broad swath of places along many different (often shorter!) paths. This is not where most people are starting from.

Speaking of Knuth, imagine being asked to "write a program to add two numbers" and using something like Python instead of assembler, or because really that's complex too, machine code. Do you think that the amount of housekeeping and computer activity is justified for adding two numbers? Objectively, it is not, its just that steady-state dominates the transient over time.

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

#376

Post by yawaramin »

replwoacause wrote: post #370
yawaramin wrote: post #270

Earlier quoted context omitted.

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.

FTA? Free Trade Agreement?

From The Article

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

#377

Post by zzo38computer »

Telaneo wrote: post #303
Dwedit wrote: post #125

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.

I still think it's worth it to provide connections over plain HTTP for this reason. It probably doesn't apply to many people, and you shouldn't allow anything really important to happen over plain HTTP (logins, payment), but normal viewing should still be possible. Sadly, the internet as a whole seems to disagree. Even the most useful resource on the web one could use over plain HTTP, Wikipedia, only allows connectio…

I agree; you should allow non-TLS connections as well as TLS. (At least, access that does not require authentication should not require TLS, but should still allow it if that is what the client wants.)

If you are concerned about accidental login or API keys without TLS, then you can consider supporting mutual TLS, which improves security (and flexibility) in other ways as well. (You do not necessarily, have to require mutual TLS, in case someone prefers to use a username/password login, or 2FA or something else like that instead.) (In the case of login forms, you can have the links to the login forms to always use HTTPS, in order to avoid the problem.)

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

#378

Post by dapperdrake »

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

Computers are very good at repeating a known "recipe". They can add numbers billions of time per second. Yes, billions with a bee.

The hard part is coming up with a recipe that solves your problem and that the machine can run without breaking things when it runs around with a few billion steps per second. You have to think ahead for it and handle edge cases in the recipe.

That is the really hard part.

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

#379

Post by zzo38computer »

miki123211 wrote: post #241

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?

> By this logic, shouldn't we also use plain HTTP instead of TLS?

Better would be to use plain HTTP in addition to TLS, rather than instead of TLS. TLS does have benefits, but if it is optional then it can also be used on computers without TLS (as well as potentially other situations where you do not want TLS or where it is not useful).

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

#380

Post by mplewis »

eestrada wrote: post #371
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…

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.
Post reply on HN