IE 11, the Modern Web, and You (Featuring StencilJS)

This article has an alternate title: How I learned that enterprise users are people too.

IE11 Is the Worst

So. IE11 is the worst. No one should support it any more and it should be shunned from existence (except for those specific apps that depend on it and are critical to your operations. Your company should have started the process of getting out of that mess 3 years ago... but we all know how that goes).

I've been really excited about my project at work because I was trying out web components with Stenciljs from the Ionic team. It works well in every browser I've tested... except IE11 (No, I am not surprised by this.... more surprised by the support requirement that I discovered after I started working on POCs and said "Let's try it... I'm sure we can write/use polyfills where needed").

Bring the Ruckus

Yesterday I found one issue where IE11 doesn't know what CSS.supports() is. I fixed that (with a little pain) and moved on. It was actually in a dependency so I could have just pulled out the dependency, written it myself and moved on, but I'm only about a week into the project, so I'm still in learning mode.

Playing around with it today I found Symbol being referenced in my ES5 build. Symbol is ES6. TypeScript hasn't fully implemented it, but every single browser HAS except IE11 which is, of course, 0% implementation. It will never be implemented because IE11 is a dead browser save for some security updates.

As an aside, the error that was thrown? It came from a polyfill. Let that sink in. IE11 is starting to break when you try to polyfill it. It hasn't received a new feature in more than 3 years. That's the situation we've created by using IE11 in 2018... it's the equivalent of using Netscape Navigator in 2011)

I'm thinking about rolling back to using a framework, because I know I'm just going to keep finding these problems as I build more and more. This is.... frustrating to say the least.

Seriously, try Stencil.

Full disclosure, Stencil is in pre-1.0 mode and has only been out for a little over a year. It's a tool, not something that will be deployed to end-users, so I'm personally OK with this. You'll need to consult your own conscience and your mileage may vary.

I looked at Polymer, Skate and Svelte... but all of them were more abstracted than I wanted and all of them are essentially frameworks of some kind. I wanted to get as close to building actual Vanilla JS web components (And I actually tried a POC of exactly that) with the smallest framework-style coupling I could get. Stencil won the day.

In Stencil, I can build a search component that has an endpoint property and is invoked in HTML like:

<search-component api="/some/url/string"></search-component>

Then I can npm run build a dist folder with NO framework code, only Vanilla JavaScript. I cannpm pack that into a tarball, publish it to npm, keep it in a local registry, or go the low-tech, bad practice, unscalable, get-it-off-the-ground route and just store those in a directory in the repo and npm install <tarball location> (Seriously, don't do that for production code... please?).

After that it's a simple import 'search-component' or appropriate syntax, and I can start using it anywhere else. I could just put a script tag on index.html and call it with no other JavaScript on the page.

The best part? These are composable components. Do you need to write 3 components to make up one feature? You can pack them all together and only have one import.

What Do We Have to Lose?

What are we losing because of support for IE11?

1. Vanilla Shadow DOM v1 and Custom Elements v1 which gives us total encapsulation of every single component
2. Access to the ionic v4 library of web-components (Also in Beta), built with Stencil (Even though I'm a long-time AngularJS/Angular guy I've never used or thought about using Ionic, but they've gotten me super excited about this one... prebuilt components and/or examples of how to build them? Yes, please.)
3. Vanilla JS implementation that can live forever in a tarball or on npm until W3C deprecates it. No more versioning of dependencies at pipeline build time, no more worrying about breaking changes in a dependency of a dependency, no more feeling like I need to proxy npm just in case a package is removed from the registry and my build breaks. None of that. I can use that same artifact for YEARS until I see a need to work on it again. Then I can update JUST that one component and NOTHING else will be impacted. This gets so granular that in Ionic, their grid system is down to the col level.... they have a component for columns in a responsive grid. That's just cool.
4. The ability to get ahead of the technology curve instead of chasing Angular/Vue/React updates every 6 months.
5. Easy PWA creation (Literally they have a PWA builder, or you can just define the Service Worker file in the config)
6. Easy-ish Native conversion with (again) Ionic, whether I initially build in Ionic or not. Routes and Layouts are components. Just spin up an ionic or insert web to native framework here instance and plug and play.(Warning: I have never done this, so this could be mindless marketing propoganda that I'm parroting.... but it looks easy...ish... but we all know what happens when someone says "It should be easy, right?")
7. Built-in polyfills for the things that don't work per browser. Most of this is supported in 80% of all browsers. Unfortunately the POLYFILL is what broke IE11. Firefox will have support for Shadow DOM and Custom Elements v1 in 63 which is the next release at the time of this writing, but I don't want to manage the polyfills for all the other browsers myself.
8. Using a COMPILER vs a FRAMEWORK. No more downloading tons of code just to use 1/10 of the functionality. No Stencil code is sent to the browser in any way. This makes me very happy. With IE11 in the picture, this is not an option.
9. The ability to get rid of Stencil two months or two years from now once Web Components are fully supported. All that it takes is for Firefox to release 63 and Edge to take it out of 'Consideration' and implement it... notice a pattern there? Take a look at the canIuse page for Custom Elements v1 and Shadow DOM v1. Once those are supported we can just directly write custom components in Vanilla JS. Now I'm going to take a second and point out that this next sentence is very important, having been through the AngularJS to Angular upgrade on a very large application. WE DON'T HAVE TO GO BACK AND CONVERT THE OLD STENCIL COMPONENTS. They will always be there and we can do lazy upgrades whenever we want, or just continue using Stencil for those components only. We give up this flexibility in order to support IE11.
10. Anywhere from 10-30% of our development time (stat is pulled from thin air and anecdotal experience) because no matter what tech we use other than (maybe) JQuery, we WILL run into 'doesn't work on IE11' problems.

What Did I Just Do?

I think I just wrote the argument convincing ME to fight for dropping IE11 support and telling anyone still using it to use a modern browser... we'll see. I started this post in despair, but I think these are the arguments that I'm bringing to the team on Monday. We're making the assumption that our employees are using browsers in a different ratio from the worldwide average... Why? Do we think our employees are less intelligent or less tech-savvy than the average and haven't downloaded Chrome or Firefox, happily chugging away using an application that probably throws more and more strange errors every day? Nope. There's at least 2.66% of people still on IE generally. I'd guess it could go as high as 15% inside a company if we account for people that don't like to download outside applications to their work computer, as well as the technically inept. I have NO problem telling those users to go download a real browser. Hell, I'll do it for them!

But hey, If it doesn't work out and I start spinning up a Vue application instead, at least I'm not being forced to use TypeScript, amirite?