kbrecordzz
Home - About - Contact - Overview
In my previous post I wrote about the limitations web browsers put on your web program's or game's Javascript code. You want to use a device's full CPU and memory - especially if you make something advanced like a game - but you can't. But if you learn how web browsers work, you can make the best out of it.
The main point was that different web browsers behave pretty differently from each other, and there are only a few select things you can assume about how a web browser handles Javascript. Using some trick to make your program run faster in Chrome, may make it slower in Firefox. That's why I explained the subset of functionality you _can_ assume and therefore use to your advantage.
We can use this same idea for browser features too! Features go in and out of browsers all the time, but some are so classic that they worked in 2010, work now and will continue to work (like the HTML tag "font", which is the most supported feature for its cause even though it's "deprecated"). That's the subset we want to use. Everything becomes so much easier when you don't have to test your program across browsers because you use too many experimental features. And after all, you want to be better than the developers who say "Your browser isn't supported anymore, please upgrade" to their users when they've made their program too complex to handle, right?
For me, who makes 3D web games, there's no need or possibility to support web browsers before WebGL. WebGL came around 2011, and it went hand in hand with the development of 3D graphics on the web and GPUs in phones. There’s no coincidence that both devices and browsers from around 2011 started being able to support 3D, this was simply the time when technology became powerful enough for both PCs and phones to support 3D.
There's also another harder limit, not only for 3D graphics, but for all websites: The mass-adoption of HTTPS (with an "S" at the end). Or more specifically, the specific versions of HTTPS that use the security protocols TLS 1.2 and 1.3. TLS 1.2 started being supported by web browsers around 2012-2014, and it seems like the webmasters always want the most secure for their websites, so when a new standard comes they tend to upgrade their sites to use the new one and leave the old one behind. This means that while new browsers support old sites, new sites don't support old browsers. You _can_ make your site work with classic HTTP to serve the users of Internet Explorer 5 and the first version of Firefox, but if Google, Facebook, Youtube and 95% of all other sites won't work on that browser (because they don't support old SSL and TLS <1.2 anymore), who wants to use it? So the time around 2012-2014 is a good starting point for finding out what browsers to support, and then from that figuring out what features these browsers have in common.
So, if I want to target all web browsers from around 2012-2014 and onwards, I could use a site like caniuse.com to see if the HTML and Javascript features I use will work on all these browsers. But I can also get a decent picture by testing my program on a real browser from 2014. I won't catch all the differences between Safari and Chrome (which are annoyingly many), but I'll catch which features are timeless and not. If something works on a 2014 browser AND a 2024 browser, I'm pretty safe. I'll for example catch that Flash is too old (not surprising), and that WebGPU is too new (may be obvious, but no one says it in 2024). Solving backwards-compatibility solves forwards-compatibility as well, because we skip the old features that have disappeared, _and_ the new ones that risk meeting the same fate in a couple of years. The ones that are left are a stable and timeless subset to focus on.
And if I have this old browser on an equally old computer, I can test my program for hardware capability at the same time! If it works on an old weak device, it will probably work on most devices today and in the future, at least if we're talking hardware power and not specific features.
I know this may seem extreme. Who uses a web browser from 2014 today anyway? But it's a different thing to go head over heals and write complicated "polyfills" to make your program work everywhere, compared to cutting away features that aren't universally accepted and focusing on the ones that are. The latter is to me the most reasonable way to achieve great results _and_ making it easier for yourself. It's not only about supporting old browsers to be nice, it's also about leaving your program to function in the future without stressing about "maintaining" and updating it.
Subscribe to Golden emails