Conditional JavaScript: Only download when it is appropriate
umaar.com
umaar.com
It'd be a bit jarring to have certain features suddenly disappear on the next page load, just because your resources dropped below certain thresholds decided by the developer?
Deactivating features based on battery life? That’s absolutely still a thing on native apps. If you throw Windows into battery saver mode, for example, the acrylic material becomes opaque; if you put Android into power saver mode, native controls will shut off their gratuitous animations, things like that. Nothing major, but a bunch of small things.
The post offers something else: vague heuristics, different on each website, and no feedback or ways to override.
See the difference?
At least the iOS App Store I believe supports splitting up assets and loading them after initial install (optionally?)
Native applications lack this kind of polish because all software lacks polish, not because it's a bad idea. "Can the application be improved in any way if it were to query battery life, connection strength, metered vs unmetered bandwidth, remaining disk space?" are thoughtful questions for any developer to ask, even if the answer is ultimately "No."
I suspect the answer is typically "Yes, but putting this level of thought into any other area of development would have been more worthwhile".
Doing the deliberation, even if the answer ends up being "No" or "Not worth it", is a crucial part of UX design. Most people don't turn over those stones at all.
e.g. Anyone with spotty or slow internet has had the realization that most desktop software has never been tested on a connection slower or less reliable than localhost, and quality software where it rears its head immediately stands out.
It might seem like frivolous polish to be adaptive to the user's current connection speed, or it might give you a spot to put a smart variable knob that lets you build good software.
But I'd also point out that we're not used to writing software that cares much about the user's resources like remaining battery life. We just write our iOS app and then depend on iOS' battery-saving mode (global throttle). It's just not something we're used to thinking about, so it's easy to be dismissive.
> cares much about the user's resources like remaining battery life.
If you are in a position where you care about user resources then you would generally minimise how you use it, globally, in every case.
[I'd say that developers/product managers often do care about this, except that advertising is intentionally resource-greedy and will wreck any care given to this]
If a user runs out of battery before the end of the day, that is as much (if not more) about what happened at the start of the day as it is at the end.
I consider website design and development to _still_ be a craft that centers the end user, which suffers degradation of quality because of -- for lack of knowledge of a better name or phrase -- The Market.
After inspecting I saw over 100 .js files were being requested by require.js, but because each module required yet another set of .js files and those files required another set, and so on. The server was serving them up plenty fast (<50ms) but because they were being loaded in waves the load time ended up being between 5 and 7 seconds.
Many of these issues arise from being fancy and people tend to want to fix it with fancy stuff. But sometimes you need to stop being fancy and just fix the damn problem in an old fashioned way (concatenate, minify, allow local caching).
What we need is ways to mark content as optional or offering it in multiple levels, that the navigator can pick from. This would be similar to how videos are served.
I also want to point out the Save-Data header which is a step in the right direction.
Just because you only visit Hacker News it doesn’t mean that every website can do its job with an equivalent amount of JS.
The whole point of such APIs is to automatically provide the right content to people: Lightweight on slow connections, beautiful on the rest of them.
While I understand your frustration, I would certainly understand a web game loading more JS than, I dunno, some major text-oriented web sites where a similar page can be written with minimal or even no JS.
This I think is the point. The requirements are different, but to look at many web pages you'd not notice.
Too many resources that could be relatively simple pages with some code to aid user experience, are becoming massive full-blown applications pulling in megabytes of code and supporting assets.
Your game requires that code and those assets by its very nature. The vast majority of web pages/sites do not, and can probably be just as beautiful without (if not more so, as speed and responsiveness is part of aesthetic judgements).
You wouldn’t need such APIs if the developers didn’t shove so much baggage at the user. If the problem really is the result of competence then even the best APIs ever written won’t fix this.
I don't see this strategy being adopted by most websites, but I reckon it's a technique worth knowing about. I've worked on WebGL visualisations where the device RAM played a big role on performance for example.
And it is probably better if power consumption increases on the server side rather on the client side, because you can locate your server facilities in connection to good clean energy, compared to all client users in the world.
We recently blogged about that on the example of Matomo (Google Analytics alternative). The main part is the following code:
if (navigator.doNotTrack !== '1') { /* load script */ }
No https://www.w3.org/TR/tracking-dnt/ The problem with DNT is not its specification but that the largest chunk of the industry does not adhere to it. Instead they nag their users with annoying cookie overlays.
> Isn't DNT [...] just not supported in browsers any more?
It is supported by all common browsers except Safari: https://caniuse.com/do-not-track
navigator.deviceMemory
navigator.hardwareConcurrency
Also because of the nature of these features (depending on use case), you can use them in a progressively enhanced manner.
I had to stop viewing my favorite website recently because it’s no longer viewable with JavaScript disabled.
How about: if you don't need the JS, don't load it.
I know you don't need most of it because I use NoScript, and most sites work fine with a good chunk of JS disabled. As a generally observed pattern, the more JS they load from more sites, the more you can disable and still use them.