Following our discussion of the need to support IE6 for a significant group in China, let’s consider the general issue of old browsers and code. Thanks to polyfills, browsers at IE6 levels of sophistication can be “pumped up” to modern HTML5 rendering. But should we? One result of polyfilling our way to modernity is that old browsers become slow browsers. I submit that this is unnecessary, and results more from “code culture” than the code needed to run old browsers.
Today’s JavaScript engines are many-fold faster than older engines, due to competition in the late oughts between V8, SpiderMonkey, Chakra, and others.
http://www.zdnet.com/the-big-browser-benchmark-january-2013-edition-7000009776/
While modern JavaScript engines can give near-native performance, this is not true of older browsers. Now, imagine that we are polyfilling in an old browser (which slows things down relative to native code), and the polyfill itself is run more slowly than a more recent browser, possibly by a factor or 10 0r 20? The result is that the old browser is soooo slow that it was probably not worth the effort. Since these browsers don’t support CSS3, there’s no ability to push the JS into CSS. In fact, to make CSS work correctly, you will probably be loading some JS polyfills.
The solution is to simplify pages and reduce page footprints, but on the current web this isn’t happening. In fact, things are running in the opposite direction. For the past several years, page sizes have been going up, and JavaScript is the culprit, according to the HTTP Archive. While some of the new code increases functionality, some does not, and in fact is more cultural than development.
As the web has expanded as a platform, JavaScript has attracted developers trained in classic languages like Java or C#. These languages have a formal class structure that can only be mimicked with difficulty in JavaScript. In the interests of transporting the “coding culture” found in application development, class structured-coding is increasingly implemented by programming groups. Rather than use the unique “design patterns” available in prototyping languages, the design team follows class-based development. The result – lotsa of JS code for poor old browsers to chug through.
Along with this work, and in part due to the rise of the mobile web, emphasis has moved to putting program “state” and process control on the client. In the classic web, servers did most of the Model-type work in an MVC pattern, while HTML and CSS were pretty much a lightweight View. This approach of a light client was standardize in the Progressive Enhancement strategy, which dictated that client-side functionality couldn’t prevent user access – the server had to be able to deliver all content in basic markup.
However, in the current environment, the “walled gardens” of iOS and to a lesser extent Android have made it possible to design “heavy” clients. Large client-side JavaScript libraries try to move functionality formerly on the server out to the client. Since that kind of code was typically written in class-based languages, we (surprise) get a heavy client with lots of slow-parsing code. Mobile web apps are increasingly written by refugees from other environments, allowed to migrate by virtue of bloated JavaScript stacks, themselves comprised of big “frameworks.” The result? Old browsers crawl through big code.
Probably the case where these problems really come to a head is in Content Management Systems (CMS). On the face of it, one would expect a CMS to be lightweight – after all, lots of the page templating and program control are happening on the server. But the “plugin” architecture of CMS systems like WordPress result in the basic CMS pages being “decorated” by dozens of code-heavy and HTTP request heavy “plugins.” The result is the worst of both worlds – lots of heavy work on the server, plus a big load of client-side plugins.
Based on trends in “framework” interest, I wonder if many of our current tools are more faddish, and a consequence of “JavaScript is a real language, so let’s make it like C#” crowd.
http://techblurt.com/2014/08/12/choose-your-javascript-framework-wisely/
What’s the Solution?
Consider the unique features of the web.
- There’s not need to shoehorn browsers into the kind of “heavy clients” favored in traditional client-server programming.
- Frameworks can be used, but not all of them at once
- We don’t really need to re-invent a class architecture when prototype-specific design patterns can accomplish the same thing more efficiently
- “Coding culture” imported from other non-web areas won’t necessarily “fix” the web – it will just slow it down.
- Designs often don’t need a heavy back end to work well for the tasks users need to complete
A great discussion of alternative strategies at:
http://www.sitepoint.com/complete-guide-reducing-page-weight/
Wonderful quote:
Are you using a library because it’s familiar and comforting?
Many people are…
http://www.creativebloq.com/netmag/5-tips-creating-simpler-and-speedier-websites-81412746
In short, supporting old browsers via JavaScript leads us to question the wisdom of cranking out so much cloud-castle coding designed to preserve code culture imported from outside the web. JavaScript may be a “real” programming language now, but that doesn’t mean it has to re-invent those languages in itself.
Sustainable Virtual Design 