The browser is slow, it is bloated. Stop adding new features!
How about taking some away?
That is an interesting question. There is an implicit assumption that once a feature is specified a) it should be implemented in all browsers and b) it should never be removed. Both of which are flawed in my eyes. Pruning of features natively supported in the platform should be a viable option.
I have a lot of memories of building for the Win32 platform and Microsoft's insistence at the time that apps will not break between operating systems upgrades because windows will always be backwards compatible — As a developer this felt great, my stuff will work and keep working. Each new OS revision adding many new and rich platform features that developers wanted, all whilst retaining the features back from days prior to Windows 3.11.
Bloat, increase size and reduces cadence. All of this was a massive cost, and the web is in a similar position.
The question needs to be raised. When should a piece of the platform be put out to pasture and what do we as web developers do we do when features on the web die?
Browser vendors are actively deprecating features on the web already, some because of poor standardization, others because they are large monolithic codebases with web developers hardly using them and in some cases the cost of maintaining support for these features is too high. A set of recent changes spring to mind where this is happening.
- showModalDialog (Chrome, Microsoft)
- XSLT (Maybe)
- SMIL
The case for doing this is strong: Less code, less maintenance, fewer bugs, smaller binaries, reduced attack surfaces, faster browsers.
The case for not doing it is strong too: Messing with Developers and breaking working stuff.
There is also an argument to stop adding new features and instead keep what we have. I will briefly say on this that this is not feasible, not if we want the web to thrive and evolve in the world of mobile (I will do a separate post about this).
Interesting questions arise out of this: How do we (as browser vendors) tell developers about this so that they can migrate their sites and apps to new equivalent API's and keep their users happy; How does a developer who can't migrate keep their sites and businesses functioning?
Traditionally we web developers smooth over the lumpy bits bits of the web by creating a polyfill that will implement the feature in another technology. For example, when getUserMedia was introduced many sites that used this new API would use a Flash plugin to provide the functionality using a functionally similar API. As mobile started to eat the world polyfilling in this manner becomes less and less viable.
Polyfills and Shims have three major problems: Everyone knows they are not "the actual" API — Modernizer calls them Fallbacks — and only use them when they have to or not at all; they don't integrate well with the progressive enhancement story; they frequently rely on plugins which are non existent on mobile.
With plugins deprecated, it has been up to browser vendors and spec authors to ensure that when new features are defined and implemented, they are done so in a way that can be explained by the core primitives and foundations that can be implemented upon.
To quote the Extensible Web Manifesto
To enable libraries to do more, browser vendors should provide new low-level capabilities that expose the possibilities of the underlying platform as closely as possible.
They should also seed the discussion of high-level APIs through JavaScript implementations of new features (such as Mozilla’s X-Tags and Google’s Polymer).
Maybe every "fundamental" new feature won't be able to implemented today in this way, but as more of the platform is exposed by primitives across the browser landscape, in my head at least, polyfills will become more prevalent, easier to implement and provide unified access to new capabilities that differentiate the web from native platforms.
Service Worker and it's Network API's are a prime example of the Extensible Web in action. It can be managed in a way that enables the same declarative API that AppCache defines yet it provides all the raw primitives for building any number of more appropriate solutions for your web site: partial caching, intelligent caching, progressive offlining. You name it, Service Worker can enable it for the network (and other platform features).
We have a huge chunk of the web platform that wasn't built with the extensible web in mind.
So can we remove AppCache? Yes. If someone has built a "reverse polyfill" for it.
Are people building "reverse polyfills"?
Yes and No.
Microsoft in Edge have implented XPath Level 3 in JavaScript via Wicked Good XPath. You wont see the polyfill polluting the pages as they have a separate runtime engine for it.
Chrome replaced the <marquee> element in
the Blink rendering engine.
Neither of these two are visible to the developer, they just work and it appears they are working well enough in terms of performance that no one notices they are not directly integrated natively into the browser.
- Extensible web => core primitives, higher level constructs built by developers.
- We need more platform pieces ported from other languages => Web Assembly.
- It's a shame that the w3c don't build out these API's in pure JS.
If large portions of DOM APIs are removed from browsers and there is no direct replacement then JS only spec compliant solutions are going to be needed.
Reverse Polyfills are the future. They are the same as polyfills but for features that are pulled from the platform, and those added to the platform. Developers will need to accept that Polyfills are a good thing and are now part of the progressive enhancement story.
- Need to be API compatible
- [TODO]
I believe the long term viability of the web depends on the Extensible Web: build the primitives of the web in a way that can be expanded on without the need for new core features. To get to this new future we are going to have to push forwards faster on the Extensible Web.
We are going to need technologies such as ASM.js and WebAssembly to reverse polyfill.
Funny thought: A bare bones browser that exposes has all API's open that you as a developer need to choose to polyfill.
https://github.com/domenic/html-as-custom-elements Blink-in-JS https://code.google.com/p/chromium/issues/detail?id=341031
I lead the Chrome Developer Relations team at Google.
We want people to have the best experience possible on the web without having to install a native app or produce content in a walled garden.
Our team tries to make it easier for developers to build on the web by supporting every Chrome release, creating great content to support developers on web.dev, contributing to MDN, helping to improve browser compatibility, and some of the best developer tools like Lighthouse, Workbox, Squoosh to name just a few.
I love to learn about what you are building, and how I can help with Chrome or Web development in general, so if you want to chat with me directly, please feel free to book a consultation.
I'm trialing a newsletter, you can subscribe below (thank you!)
