This is an exhaustive analysis of just how bloated some web tech is, and how poorly it performs on low-end hardware that might seem cheap to rich techies in the US but is still hideously expensive to somebody in poorer countries.
I don’t know how to solve existing web bloat, but I know how to avoid it on my own website.
- If it doesn’t work in lynx, it doesn’t work at all.
- If it doesn’t work with connection speed throttled to 14.4Kbps, it doesn’t work.
I think too many people working in web tech have either forgotten what it was like to access the internet on dialup, or never knew what it was like in the first place.
These same people have forgotten what it was like to have a monocore CPU running at 33MHz or less, no more than 8MB of RAM, and 512MB of storage maximum — and to be limited to DOS with no GUI and no dev tools but QuickBASIC. Either that, or they never knew in the first place, except from stories they don’t hear because the graybeards have all been laid off for not being a culture fit.
It’s not the HTML that’s the problem. It’s not the CSS, either. HTML and CSS are declarative programming languages, and even old browsers on old hardware render them quickly.
It isn’t even the back-end code, though some might argue that Ruby on Rails is slower than PHP. (Be grateful it’s not ASP.NET or ColdFusion!)
It’s fucking JavaScript, as usual. These low-end devices Dan Luu has been testing can’t handle all of the JavaScript with which so many web developers are so blithely profligate.
I’d like to make some of these JavaScript jockeys build web apps on punch cards. Maybe that might teach them, though I doubt there’s really any cure for having more money than sense. Nevertheless, let’s see them run their npm-based build processes with over 9,000 dependencies on a GE 645 mainframe running Multics.