The average JS transfer size per website, in the top 1000, has grown almost 500% since late 2010. Meanwhile, the average HTML transfer size in that same period and selection, when compared to JS, has grown a "paltry" 100%.
As a whole, the Average Webpage Is Now the Size of the Original Doom! (The thought of multiple floppy disks for a game install still drives me bonkers.)
All this is incredible, but it's really not surprising to anyone involved with web development.
Of course, the "boom" has largely been associated with the development of rich, responsive websites that (hopefully!) make interaction of said websites easier on the end user.
I am no longer optimistic this will change in the next two years, and there are untold millions of slow Android devices out there, so we need to start considering alternatives for the Discourse project.
(Emphasis his, not mine)
Henrik Joreteg went on to write a blog post discussing The viability of JS frameworks on mobile in response to Atwood's post:
Whether I like it or not, not everyone using my web apps will be running iOS 9 on an iPhone 6S or a Nexus 6P and connecting via super-speedy wifi.
The reality is often anything but that. 3G connections and older hardware is often the norm.
You may be thinking: ”this is load time performance, Atwood was talking about runtime performance!”
Yes, Atwood was discussing runtime performance, I’ll get to that shortly. But, the user doesn’t care why they’re waiting, so load time is clearly an important part of performance too.
My question is simply: are all these heavier tools/frameworks even viable for mobile use?
I’m not convinced they all are.
Progressive enhancement uses web technologies in a layered fashion that allows everyone to access the basic content and functionality of a web page, using any browser or Internet connection, while also providing an enhanced version of the page to those with more advanced browser software or greater bandwidth.
In other words:
The thought process behind Progressive Enhancement is to always provide an upgraded experience if the client/browser allows for it.
Enter Controllable Enhancement
Let's pause for a moment and ask ourselves the following questions:
Or as I like to call it: Controllable Enhancement.
Contrary to the thought process behind Progressive Enhancement, Controllable Enhancement is to intentionally scale back functionality and associating performance costs if the user doesn't actually need it.
Progressive Enhancement is about the client whereas Controllable Enhancement is about the user.
Controllable Enhancement in Action
Effectively, this example is a Single Page Application (SPA) that can be run as a "Traditional" application at any point in time. More importantly, a "Traditional" application with a reduction of enhancement costs.
Indeed I am, my friend.