Live data from Hacker News

Building an HTML-first site doubled our users overnight

mohkohn.co.uk

281–290 of 605 posts

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

#281

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

+1 to the idea. Developers should have a powerful machine to develop, but a minimal machine to run and test.

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

#282
post #64

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

You can still buy KaiOS phones, I have one.

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

#283
HTML doesnt have hundreds evangelists writing blogs about how cool it is. So it doesn’t really matter what the benefits are if juniors are going to keep showing up writing client-side react components. And the product managers letting them because of their sparkling (but naive) personality.

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

#285

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

> Windows 11 machine with only 4 GB of RAM using Firefox with the network throttled to 3G speeds

And their mobile device should be the cheapest Android phone from a monthly cell provider you've never heard of. This is what the real world is for a lot of people, and a huge number of developers simply don't know or care.

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

#286
> My client was a utility company

> Adding a lot of pressure, this was a regulated monopoly

> Some requirements I derived: > ... > We had to meet WCAG accessibility (the team settled on AA rather than AAA)

The author doesn't doxx their employer by giving any dates, but if we take the story at face value and assume it took place in last few years, it is pretty shocking.

How does it take a single hero to be fighting for AA compliance as an afterthought for a project with this scope in the 2020s?

I've worked on much more niche projects that treated this with the respect it deserves as a quasi-legal requirement.

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

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

A lot of developers have made or just perceive very strong silos between frontend and backend today. Any coordination that needs to happen between frontend and backend is potentially a communication challenge.

It seems like a lot more work because you have to keep the backend and frontend in closer sync. The backend has to be aware of and able to store every sub-form in the full process (which sounds like a "wizard form" with a multiple sub-forms to get through the full "form" process), not just accept a "finished" or "complete" submission. If a sub-form needs a change the backend, the backend's storage, and the frontend all need to change. The backend and frontend have to agree on validation logic for each small piece of the form. The backend and the frontend need to both validate every small piece of the form, and maybe can't share that validation logic (depending on what language the backend is written in), especially if one of the goals is to do as much of the frontend validation as possible with Browser native validation tools (`The original ways of making websites were "full stack" and from a full stack perspective it shouldn't seem that hard to have a coordinated frontend and backend, especially when a progressive enhancement approach likely means a smaller more agile frontend, but current siloed world where frontend and backend are different teams with different goals and alignment makes that seem like way too much work.

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

#289

Earlier quoted context omitted.

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

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.

The problem with changing banks to search for a ux you like is that it's not easy to see the ux before you've invested in signing up.

My main bank changed their UX not too long ago, and I liked the old one better, but the banks I've signed up for since are even worse. I signed up with them for other reasons though, so I put up with them because it's worth the pain. It does make my main bank look better though --- mobile style on desktop is annoying, but at least I can easily find everything I need... And it's not really their fault there are seven different options on the transfers page (including my favorite: same day transfer vs next day transfers... at one point same day transfers had a fee but they don't anymore so from a user perspective, it's the same thing but you can have it slower if you want...)

Also, signing up for a new bank these days is an exercise in KYC frustration. And then you can't actually transfer your money and use it, because banks responded to the dumbass check fraud that was being promoted on social media by limiting new accounts.

Post reply on HN