The web historically moves in waves.
Libraries are created to push complex features in an easier way. Then the libraries themselves get complicated, often more so than the benefits they provide.
Eventually, (some of) the core features of those libraries make their way into the browser itself, but the libraries linger like water on the shore, slowly receding.
And before the sand has a chance to fully dry, a new set of libraries washes in to push the web even further.
I like this high-level view of the state of CSS today. There are two main takeaways:
- Custom properties, flexbox, and grid are game-changers.
- Pre- and post-processers are becoming less and less necessary.
This is exactly the direction we should be going in! More and more power from the native web technologies (while still remaining learnable), with less and less reliance on tooling. For CSS, the tools have been like polyfills that we can now start to remove.
They could learn a thing or two from the trajectory of CSS: treat your frameworks as cattle, not pets.
Scott re-examines the browser support for loading everything-but-the-critical-CSS asynchronously and finds that it might now be as straightforward as this one declaration:
<link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">
I love the fact the Filament Group are actively looking at how deprecate their
loadCSS polyfill—exactly the right attitude for polyfills in general.
A fascinating look at the web today with IE8. And it’s worth remembering who might be experiencing the web like this:
Whoever they are, you can bet they’re not using an old browser just to annoy you. Nobody deliberately chooses a worse browsing experience.
The article also outlines two possible coping strategies:
- Polyfilling Strive for feature parity for all by filling in the missing browser functionality.
- Progressive Enhancement Start from a core experience, then use feature detection to layer on functionality.
Take a wild guess as to which strategy I support.
There’s a bigger point made at the end of all this:
IE8 is today’s scapegoat. Tomorrow it’ll be IE9, next year it’ll be Safari, a year later it might be Chrome. You can swap IE8 out for ‘old browser of choice’. The point is, there will always be some divide between what browsers developers build for, and what browsers people are using. We should stop scoffing at that and start investing in robust, inclusive engineering solutions. The side effects of these strategies tend to pay dividends in terms of accessibility, performance and network resilience, so there’s a bigger picture at play here.
Really good advice for anyone thinking of releasing a polyfill into the world.
Behind the amusing banter there’s some really solid performance advice in here. Good stuff.
Client Side Rendering (CSR), or as I call it “setting money on fire and throwing it in a river” has its uses, but for this site would have been madness.
This is such a great perspective on what it’s like to build for the web over the long term. The web will always be a little bit broken, and that’s okay—we can plan for that.
The Web has history. If you build with web technology it will stick around. We try not to break the web even if it means the mistakes and bad decisions we have made in the past (and will make in the future) get set in stone.
Remy looks at the closing gap between native and web. Things are looking pretty damn good for the web, with certain caveats:
The web is the long game. It will always make progress. Free access to both consumers and producers is a core principle. Security is also a core principle, and sometimes at the costs of ease to the developer (but if it were easy it wouldn’t be fun, right?).
That’s why there’ll always be some other technology that’s ahead of the web in terms of features, but those features give the web something to aim for:
Flash was the plugin that was ahead of the web for a long time, it was the only way to play video for heavens sake!
Whereas before we needed polyfills like PhoneGap (whose very reason for existing is to make itself obsolete), now with progressive web apps, we’re proving the philosophy behind PhoneGap:
If the web doesn’t do something today it’s not because it can’t, or won’t, but rather it is because we haven’t gotten around to implementing that capability yet.