Live data from Hacker News

Building an HTML-first site doubled our users overnight

mohkohn.co.uk

571–580 of 605 posts

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

#571

Earlier quoted context omitted.

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

every action including scrolling roundtrips to the server As soon as you include a network roundtrip in anything you're opening up a Pandora's box of slow connections, slow DNS queries, network outages, what-if-the-user-is-on-a-train problems, what-if-their-IP-changes-mid-flow problems, etc. Reducing the network calls in any app has upsides and downsides. It isn't really true that SPAs are faster to render (as your e…

It baffles me people can write software like this.... Surely it's the most basic tenet of webpages is that it's all sent over the network and the network lags and drops packets.

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

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

> Why is it more work?

People expect the entire screen not to redraw whenever they interact with an app and expect behaviour asides from the HTML defaults.

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

#573

Earlier quoted context omitted.

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…

The push to have everything be served over HTTPS is absolutely insane. Very few things actually need to be served securely. But sadly, browser makers don't give a damn about actual benefits for the users, but rather shove their out of touch ideas about what the Web should be down everyone's throats.

Imagine if you found someone making full fledged applications from word documents. Like, they'd managed to create a "framework" in VBA so they can do all the things word docs can't do out the box. The word documents were running servers, production code etc

You'd think the person was creative but maybe insane.

This is the exact same feeling I get when I see web "apps".

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

#574

Earlier quoted context omitted.

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.

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

It's redundant in the same way Earl Grey tea is redundant, though.

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

#575

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?

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.

A decade-old phone was released in 2016 (yes, we're old).

React already existed in 2016, so did Vue and Typescript. Never mind good old JS.

I frankly can't imagine a device capable of supporting modern TLS stacks but incapable of supporting JS. Much less a phone, which in many countries basically requires LTE (and sometimes even VO LTE) support to function at all, due to the 2G and 3G shutdowns.

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

#576
post #355
post #217

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…

> Ironically Facebook was super popular in the 2014s because they didnt have much React based BS going on. facebook was super popular in 2014s because they were just starting the transition from mostly being about people to mostly being algorithmic rage bait, and they tapped a new market of fox news/conservative talk radio listeners

To be fair, Facebook invented React slightly before 2014 so the original point seems very very strange to me.

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

#578

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?

Remember, "don't support JS" is just a shorthand for a broader variety of situations:

- Old browsers without the modern JS features you're trying to use

- Different browsers, with different features

- JS didn't load due to network errors

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

#580

Earlier quoted context omitted.

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

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.

I don't know about you, but my team uses React and we also have to handle validation on front end and back end, in different ways.
Post reply on HN