No, you don’t need to support Internet Explorer.

I was recently slaughtered on Hacker News for stating that supporting IE was a waste for many businesses. The core of my argument was simple: in the US and Europe, the effort warranted to support Internet Explorer is rarely worth the revenue supporting them brings in.

I can understand why you’d want to support IE, and for a very long time I supported making things work on old browsers. Rewind back to say, 2010 and you’d have found:

• Enterprises where IE is not only the default but the only browser
• Most browsers updating statically, so ‘current -2’ seem reasonable
• Polyfills possible to bring old browsers largely up to scratch with some minor effort
• Basic stuff, like grid layouts and async workflow management, required tutorials, libraries and frameworks.

Current browsers were ahead of old tech, but not by much. It wasn’t a huge amount of work to drag them along for the ride.

Fast forward to 2017:

• Chrome, Edge, Firefox and Safari are evergreen
• Major changes to CSS, JS/ES, and the DOM have occurred that should — if you value your time — fundamentally change the way you build web apps.
• Even slow moving corporates have AD-managed Chrome or Edge since half the internal products they purchase don’t work properly in IE. Yes really. Ask your lawyer and banking friends.

Say you want to, lay out a web page. Your options fall into two broad categories:

• Use a combination of floats, clearfixes, overflow side effects, zoom side effects, wrappers and various other hacks
• Lay it out using grid and flex

If you’re doing the former, why are you optimising your workflow for something required by a tiny portion of browsers?

If you’re doing the latter, supporting IE9 requires a Polyfill, IE10 and 11 require workarounds to fix a bunch of annoying bugs.

Supporting each of those has their own issues in turn — asides from the polyfills, your CSS will have IE9-isms and IE10 and 11 workarounds. And every time you modify your layouts you’ll need to keep them updated. Maybe you could find or implement a system to do both of them and spend some time doing that.

OK but that’s just flexbox.

Cool, now repeat the entire process above for grid.

What about managing your JS/ES async workflow?

• Use endless `.then()` chains, `async.waterfall()`, or pyramid of doom callbacks.
• Use `await`, getting return values from async functions just like they were sync ones

If you’re doing the former, why are you optimising your workflow for something required by a tiny portion of browsers?

If you’re doing the latter, you can transpile your ES2017 `await` to .then(). You can set this up and it adds a little more time to your build process. But wait — the plugin isn’t complete according to it’s authors and there are edge cases there too.

So your build process is sometimes a bit slower, a bit more complex, and your code now has some extra stuff to handle the bit the polyfill couldn’t quite do, and comments explaining why they exist, and you spent some time researching what those workarounds were and occasionally you need a new workaround. Just like your grid polyfill. Just like your flex polyfill.

What about other stuff? At CertSimple, verifying companies for EV HTTPS, we use webcrypto and clipboard. The former is shimmable, but you lose real randomness so there’s no point. The latter is also shimmable, using, er, Flash. I don’t want to be starting, building for, or troubleshooting an unmaintained browser plugin.

The polyfills and effort and edge cases to support old browsers with current web dev practices is larger than it has ever been.

How far away will the station be before you don’t care anymore?

Chrome, Firefox, Edge and Safari users are on the train and continuously moving forward. Internet Explorer, and your 3 year old cell phone are left at the station. You may like this, or not like this, but it is indisputably the case.

The technical gap between the evergreen browsers and their occasionally-updated cousins is wider than it ever has been.

More importantly, that distance grows wider every moment.

There is no amount of effort that will give old browsers a good experience. Meanwhile, the time and effort you’re spending on this impossible task drains away from features for everybody who’s on the train.

Maybe you live outside the US and Europe, and you need to practice old-style CSS, ES and DOM development until IE becomes irrelevant in your country. OK, but it will be soon.

If you don’t stop supporting unmaintained browsers now, when will you? 2018? 2024? How far away does the train get before you stop wasting your time?

If you know me personally you’ve probably heard me rant about how much I love Health and how discovering them was one of the musical highlights of this year. There’s an old Josh Homme quote: “music should be heavy enough for the boys and sweet enough for the girls” — Health combines whipping hard instrumentals with Jake Duzsik’s gentle vocals reminiscent of Neil Tennant from the Pet Shop Boys.

Health has a HUGE diversity of styles, and the names of the songs never match the lyrics, here’s a few of my favourites:

Obvious walk-on song for when I give up entrepreneuring and become a stripper

…also good on the way to the gym:
Stonefist (love’s not in our hearts)
Thrashing, hard and sexy.

OK but I just like gentle pop music and you said these guys sound the Pet Shop Boys

Life (I don’t know what I want)
L.A. Looks (It’s not love)

Contemporary dance is in Studio 7

Pain
Soft atmospheric and sad.

Soundtrack to the next Gaspar Noe film

Salvia
Hard.

Break up sex

…just kidding, this is my other stripper song.
Tears (give up on us)

A short, practical guide.

Want to run your own servers? Here’s how to deploy your node app on a modern Linux setup.

Here’s what we get:

• A stable (LTS) version of node, installed properly
• A proper .service for your node app, with automated restarts, proper logging, and other good things.
• Your app accessible on port 443 and/or port 80, but running as a regular user.
• The ability to log in automatically using your SSH key, without needing a password.
• The ability to deploy from git automatically using deploy keys, without needing a password

How I deploy node apps on Linux has been updated for 2016 and moved to my current blog at CertSimple!