Go Evergreen

Posted 17 October 2017. 4 min read.

Happy 🎂 Day IE 11!

On the 17th of October in 2013, Internet Explorer 11 was released from Microsoft. That means that as of today, this popular* browser is now four years old and, with all respect to it, it really ought to go.

Good day sir. I said good day!

Evergreen Browsers

What makes a browser, or any software for that matter, evergreen? Well, the basic requirements for a browser, or any piece of software for that matter, are specifically the support of automatic updates, that bring in:

security fixes
bug fixes
rolling/evolving feature udpates

Some of the more popular evergreen browser right now are Chrome, Firefox, and MS Edge. Internet Explorer, for example, is not an evergreen browser.

Why Does It Matter?

To be perfectly honest, the advancements in JavaScript (EcmaScript) to make use of its annual specification update means that we need to stay on top of our games. In addition to keeping up with the standards being evolved with the spec, we have security concerns as well. Does everyone remember the stretch of SSL issues we saw with POODLE and friends that lasted a minor eternity? Does anyone think that will never happen again? We need to stay flexible in our updates and reaction to threats, that's not in question and should sell this "argument" in and of itself.

When a web browser is evergreen, it brings with it flexible adaptation to security threats, pursuit of the evolving web standards specifications, and lets us have access to the latest and greatest APIs so that we as developers aren't held back. Everyone wins from the user, through the developers, up to the vendors.

A Case In Point

In case you're wondering how this sort of thing comes up in practice, I've got a somewhat handy example that I ran into in my day job. Consider the following object literal assignment in JavaScript. For this example, we're using ES5 syntax.

	function someFunc(){ ... }
	function anotherFunc(){ ... }

	var ob = {
	someFunc: someFunc,
	another: anotherFunc
	}

view raw basic_ob_assign.js hosted with ❤ by GitHub

Now consider we add another function (yetAnotherFunc) and while adding it to the object, we get a typo.

	var ob = {
	someFunc: someFunc,
	another: anotherFunc,
	yetAnotherFunc, yetAnotherFunc
	}

view raw oops_assign.js hosted with ❤ by GitHub

Obviously, we meant to use a : in place of a , but what happens when we have this? Even though we're writing to an ES5 level, evergreen browsers have been picking up significantly more of the ES2015(ES6) and above features and syntax support. Seeing how this is the evolving spec (with annual updates), there's no reason to hold back. So, if you haven't guessed it by now, this works perfectly fine in any browser that supports the shorthand assignment in Object initializer, which is part of the ES6 spec. We've defined yetAnotherFunc twice since we used the same property name as the function name, but since both reference the same function, there's not much in the way of issues. This also means that because older browsers, such as IE11, aren't evergreen, they do not and cause us to find a functional issue in potentially only one of our tested browsers. (*any that doesn't support beyond ES5)

If you're saying, "but that's not IE11's fault", you'd be absolutely correct. IE11 doesn't support ES6, but then it never will and is holding us back; the entire point I'm trying to make here.

See It In Action

Summary

The ultimate intent of this post is to stress the importance of what we need a web browser to do. Ultimately, just as Continuous Integration (CI) has led to great advances in how we accomplish development along with its testing and release processes through sheer flexibility, consistency, and immediacy; we also should look for those qualities in our web browser(s). If a browser grows stale or sluggish in its release cycle (such as non-evergreen browsers), then we all suffer for its inability to respond to security threats, release with the known evolving specifications from W3C and TC39. It's not just about having the new and shiny, it's also about assurance of response to security threats and adapting to the direction of the web.

In the end, the question I've been asking myself is:

How do we get from needing to support IE(11) to the bright future where we don't have to care if a browser vendor allows itself to go out of date?

I'm fairly certain this will need to be grassroots in nature. We need to "bubble up" our need to move on from inflexible browsers; previously, I would include something like the browse happy include (*this is limited, as it is generally detecting IE specifically) and point those with outdated browsers to it, but it still lists IE 11; part of what I'm trying to avoid.

*Note: I don't mean to hate on IE, rather Microsoft has moved on with Edge and while they have taken a very business stance of supporting IE for a longer time than I would prefer, but it's for their business customers who have locked-in requirements of older software requiring, say, IE 7. This is rather meant to highlight the need for us as the development community to force the movement and let the "norm" be something favorable to everyone.

Until next time, 🍻!

software development, operations, tooling, and musings on technology by Eric McCormick

Mastodon GitHub Instagram