The main thing I remember from an usability book by Jakob Nielsen is that web pages should fit in 50kb, including all elements. Managing to do this in only 2x that size today, considering that his book was from 1999, may be considered a merit.
To put this into another context, today there was a post about Slack's 404 page weighting 50Mb.
I don't do web stuff at all, but I really enjoyed this article. I am convinced that software engineers (not to mention others) have thrown the baby out with the bathwater in our brave new world of 32GB memories and fibre-optics. By all means the generous hardware capabilities let us do amazing things, like have a video library, or run massive climate computations, but mostly those resources are piddled away in giant libraries that provide little or no actual functional value.
I don't really pine for the days of the PDP-8, when programmers had to make sure that almost every routine took fewer than 128 words, or the days of System/360, when you had to decide whether the fastest way to clear a register was to subtract it from itself or exclusive-or it with itself. We wasted a lot of time trying to get around stringent limitations of the technology just to do anything at all.
I just looked at the Activity Monitor on my Macbook. Emacs is using 115MB, Thunderbird is at 900MB, Chrome is at something like 2GB (I lost track of all the Renderer processes), and a Freecell game is using 164MB. Freecell, which ran just fine on Windows 95 in 8MB!
I'm quite happy with a video game taking a few gigabytes of memory, with all the art and sound assets it wants to keep loaded. But I really wonder whether we've lost something by not making more of an effort to use resources more frugally.
> As I often point out to teams I’m working with, the original 1993 release of DOOM weighed in at under 3MB, while today we routinely ship tens of megabytes of JavaScript just to render a login form. Perhaps we can rediscover the power of constraints, not because we have to, but because the results are better when we do.
Emphasis mine, and tying with how it opened with the story about the designer who believed accessibility and "good design" are at odds (I'm screaming inside).
I really enjoyed the article. I have to say, though: sorry, not sorry, but application size is a poor measure of performance. A 128KB size limit doesn't account for pictures, videos, tracking, ads, fonts, and interactivity. Just avoid them, is not a real world strategy.
Suggesting that an application should stay within a 128KB limit is akin to saying I enjoy playing games in polygon mode. Battlezone was impressive in the 90s, but today, it wouldn't meet user expectations.
In my opinion, initial load time is a better measure of performance. It combines both the initial application size and the time to interactivity.
Achieving this is much more complex. There are many strategies to reduce initial load size and improve time to interactivity, such as lazy loading, using a second browser process to run code, or minimizing requests altogether. However, due to this complexity, it's also much easier to make mistakes.
Another reason this is often not done well is that it requires cross-team collaboration and cross-domain knowledge. It necessitates both frontend and backend adjustments, as well as optimisation at the request and response levels. And it is often a non-functional requirement like accessibility that is hard to track for a lot of teams.
Maybe i'm dumb, but I really don't understand the point of this post.
Why even make it "reactive"? Just make your site static server-rendered pages? Or just static pages. Is it because additional-content-loading is something users expect?
"Write your site in plain javascript and html. Don't use a framework. Write some minimal css. Bamo. Well under 128kb." ???
Making a website is what made me interested in programming as a 10 year old during the dot com bubble. Even back then I realized very quickly that webdev is a cargo cult and I switched to C and assembly to learn how to program “real” programs. Even now, almost 30 years later, I can make high quality software based on technology from back then (compared to the constant dependency drift nowadays in webdev). It’s just a constant assault by young programmers who don’t know better in webdev.
Some years ago I made a website again. Screw best practices, I used my systems engineering skills and the browser’s debugger. I had written game engines with soft realtime physics simulations and global illumination over the network. I knew what computers could do. This website would render within 1 frame at 60 FPS without any layout recalculation, garbage collection events, web requests that can’t be parallelized without dependencies etc.
I showed it to friends. They complained it doesn’t work. They didn’t realize that once they clicked, the site displayed the next content instantly (without any weird js tricks). This was a site with a fully responsive and complex looking design. The fact that users are SO used to terrible UX made me realize that I was right about this industry all along as a child.
I'm about halfway through the read so far, but wanted to vome back and say that these were/are some of most interesting challenges to overcome and constraints to work within, when I was coming up as a web person. Inspired by agencies like Clear Left, I'd seek out old af devices with comically bad browsers, tiny screens, and obtuse input methods. Unfortunately I never really found a financially rewarding enough path to continue pursuing that; the constraint on most projects that don't have these super tight requirements baked in, is money, time, and looking good, which meant that I could either accept that as a survival mechanism and throw JS at CSS problems, or I could lose my job. Although it's neat that over the years of my incredibly shaky career, I've moved from web designer/developer to f̵a̵k̵e̵ software engineer, I've never found UI programming to be quite as rewarding as making an incredibly fast and responsive and pretty and robust website.
13 comments
[ 4.1 ms ] story [ 35.1 ms ] threadTo put this into another context, today there was a post about Slack's 404 page weighting 50Mb.
I don't really pine for the days of the PDP-8, when programmers had to make sure that almost every routine took fewer than 128 words, or the days of System/360, when you had to decide whether the fastest way to clear a register was to subtract it from itself or exclusive-or it with itself. We wasted a lot of time trying to get around stringent limitations of the technology just to do anything at all.
I just looked at the Activity Monitor on my Macbook. Emacs is using 115MB, Thunderbird is at 900MB, Chrome is at something like 2GB (I lost track of all the Renderer processes), and a Freecell game is using 164MB. Freecell, which ran just fine on Windows 95 in 8MB!
I'm quite happy with a video game taking a few gigabytes of memory, with all the art and sound assets it wants to keep loaded. But I really wonder whether we've lost something by not making more of an effort to use resources more frugally.
Emphasis mine, and tying with how it opened with the story about the designer who believed accessibility and "good design" are at odds (I'm screaming inside).
But, damn, that was some fun stuff. Really challenging to get the graphical results we wanted and keep it under budget (15 KB in the early days).
It's really satisfying.
Suggesting that an application should stay within a 128KB limit is akin to saying I enjoy playing games in polygon mode. Battlezone was impressive in the 90s, but today, it wouldn't meet user expectations.
In my opinion, initial load time is a better measure of performance. It combines both the initial application size and the time to interactivity.
Achieving this is much more complex. There are many strategies to reduce initial load size and improve time to interactivity, such as lazy loading, using a second browser process to run code, or minimizing requests altogether. However, due to this complexity, it's also much easier to make mistakes.
Another reason this is often not done well is that it requires cross-team collaboration and cross-domain knowledge. It necessitates both frontend and backend adjustments, as well as optimisation at the request and response levels. And it is often a non-functional requirement like accessibility that is hard to track for a lot of teams.
Why even make it "reactive"? Just make your site static server-rendered pages? Or just static pages. Is it because additional-content-loading is something users expect?
"Write your site in plain javascript and html. Don't use a framework. Write some minimal css. Bamo. Well under 128kb." ???
Some years ago I made a website again. Screw best practices, I used my systems engineering skills and the browser’s debugger. I had written game engines with soft realtime physics simulations and global illumination over the network. I knew what computers could do. This website would render within 1 frame at 60 FPS without any layout recalculation, garbage collection events, web requests that can’t be parallelized without dependencies etc.
I showed it to friends. They complained it doesn’t work. They didn’t realize that once they clicked, the site displayed the next content instantly (without any weird js tricks). This was a site with a fully responsive and complex looking design. The fact that users are SO used to terrible UX made me realize that I was right about this industry all along as a child.