You may have noticed that this website is small, very small. In fact, the part that generates this website is around two thousand times larger than the site it generates. But why? Don't I lose out on all the latest features of the web?
Indeed, in their current form, browsers give us access to a ton of very useful APIs. Here are a few you probably didn't know about:
These APIs allow us to create very beautiful and complex experiences. From dimming the screen based on ambient light, to loading images only if they are going to be on screen. But more importantly, they allow us to craft experiences based on how much of the device's capabilities we need. And it's this last word I use which most people change to abuse.
Website bloat is a real problem, and with each passing year, on average, we ship more JavaScript and more code to the users, with very little benefit to the end-user. Most people don't even notice, or use much of the code that is shipped.
I opened the homepage of the New York Times and, according to Chrome, I only use 2.2Mb of the 4.4Mb I downloaded.
This might not seem like much, but stop and consider, 4.4Mb of JS and CSS (it doesn't take images into account when calculating this information) was sent to me to show, what is, arguably, a very simple layout and some lazy loading. And we both know, that the JS and CSS has passed through, at least, one form of optimization.
Is 4.4Mb a lot in 2019?
I'm probably not going to revisit NYTimes in the near future, so most of that is wasted for me. But, if I did then maybe I'd get to use more of their bundles and then my experience would be better. That is a fair point. But you can't argue with the fact that there is some waste.
What most people don't take into account is the amount of energy required to parse, render and use those packets. And yes, this process is really fast thanks to modern electronics. But I used a very specific word: energy, not time.
There's a lot more that goes on than just the 4.4Mb. That's just the tip of the iceberg. Those 4.4Mb have probably been created from a laundry list of packages which have been sewn together with care by Webpack. So with every whirl of a CI pipeline, all packages get downloaded (hopefully they use a cache), all JS/CSS assets are bundled neatly, and then await their arrival to a fresh browser. All this energy to display something that is simple, and this is where I tell you: they did the correct thing.
The right thing
This way, they get to keep a quick UI, possibly allow for various layouts and layout switching for specific articles, and still get away with relatively fast loading times for people on good connections - which I'm assuming makes up much of their audience.
Can they improve their metrics? Yes, definitely, but they have thousands upon thousands of articles and their needs aren't mine or yours. I'm not here to bash on NYTimes, that would be highly rude. But they could make improvements, and remove the console logs from their Raven code.
This works for them, and for most web applications. It has clear benefits like:
- fast development times
- reasonably fast UI
- apart from the initial load, most of the content can load very quickly
- spread the cost of rendering to the client (although with SSR this is debatable)
This does not seem to me to be the correct approach when dealing with blogs, presentation websites and around 80%+ of the websites that exist.
The small-scale approach
I've taken a completely different route for my small site. A static site which can be served very quickly by any http server. Yes, I'm losing out on all of that pizzazz that other websites have. But I don't really need all that much since I'm using two browser APIs that most people have forgotten about: the DOM and CSSOM. I'm not using JavaScript, but that is merely because I don't see the point in adding it, at the time of writing.
But why? Why subject myself to all the simplicity and difficult nature of writing HTML and CSS without the aid of things like React, or Angular or jQuery or whatever else?
Because I don't need it. And come to think of it, most likely you don't need a lot of what you're serving to your own users. I'm not talking about removing the entirety of JavaScript, but rather being more careful with what you're sending to the user and making the most out of all that the browser has.
The elephant in the room
Ads and user information gathering are a topic that I won't delve too deeply in this article.
There is much to say and I probably will write a different article on my thoughts on the pervasiveness of ads and user data gathering, but I will say that I think that we are loading far too many ads and "metrics" into most websites with not that much gain for end users, but let's be honest end-users were never the beneficiaries of such things.
The point?
Use the browser as much as possible. Don't overengineer solutions unless you really want to create problems for yourself. The simplest solutions is probably the best. And, let's face it, you probably won't want my Service Worker downloading parts of my website in the middle of the night when you probably will visit my website ... wait, I don't know if I get any repeat visits because I don't track anything!
I am in favor of using as much JavaScript is necessary and to use the browser's capabilities to their fullest extent.
I am in favor of larger bundles for an experience that demands such a price.
I am not in favor of having to download yet another jQuery version, just so you can move two divs into a different place.
I am not in favor of wasting everyone's time on a bundle which isn't used because they cannot be bothered to chunk their application.
Can we do better as a community? Yes, we can, we can show to everyone that the Web isn't just a black hole of node_modules, but rather something that is crafted with care and consideration to others.