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?

Comments

[Scott Yeatts]

It's about half and half. Strong typing exists because the language wants to prevent you, the supposedly highly skilled and experienced developer, from doing something dumb. It restricts expressive power and speed in favor of stability. I feel the same way about Object oriented languages. Why would I restrict myself to one paradigm, when (no matter what language I use) there is a good use-case for OO, functional and even procedural techniques in almost any application.

JavaScript's strength is actually what many would call its weakness... duck typing and expressive power. You lose a lot of freedom when you restrict that.

It was facetious because of course I see the benefit of TypeScript (especially for large teams). Forcing consistency through language-level contract rather than structural convention (I'm reminded of how many times I had to remind people to use the revealing module pattern for AngularJS services... and then having to explain what that was, what design patterns are and why they are useful in that specific context, the benefits, etc... more times than I care to admit) but at the same time there's a reason Atwood's Law isn't "anything that can be written in Java will be". TypeScript is a tool like any other.

Give me a small team of highly skilled engineers in a 100% ES6 environment, I might not use it. Make me the one senior leading a team of 10 junior engineers and I'll reach for it in a second. Single developer environmemt with complete control of the stack? Maybe I'll try Elm or maybe I'll write Vanilla JavaScript so I can write dead-simple code without worrying about classes and types. I guess it's about applying the rule of least power in a way it wasn't necessarily meant for. If I NEED TypeScript, I use it. If I don't, I don't. When my tools REQUIRE TypeScript because it's the flavor du jour or because THEY needed it for their use-case, then that forces me to need it, rather than their tool doing what they do and presenting an API that I can easily consume with JavaScript or Elm or FORTRAN or whatever is best for my use-case. All these tools are an effort to compile down to vanilla Javascript anyway, so we should focus on trying get to the point that we don't NEED TypeScript, not just assuming that we will need it in every project.(Yes, FORTRAN was a joke, too :D)
EDIT: Written from my phone while waiting on my son to finish breakfast... so please excuse any grammatical errors. Any stupid things I say are probably still dumb though :P

[Matthew Costabile]

Which polyfill caused an ie11 issue? I've been building a stencil compiled component set that has to support ie11, and so far haven't had a problem with their polyfills (but occasionally have had to rewrite sections of my code to get around or)

[Scott Yeatts]

url-polyfill, 1.0.14
https://github.com/lifaon74/url-polyfill
MIT Licensed
*/
(function(e){var t=function(){try{return!!Symbol.iterator}catch(e){return false}};...

Now, this is probably from the Stencil 'app' environment, since the components individually work correctly when served on their own (After I fixed the CSS.supports() issue that came from the ion-col component).

Unfortunately I lost the good fight :( Our director wants to make Web-Components our goal over time and we're building with that end-state in mind, but I got a good enough argument (even if it's because of things I disagree with, but we don't have control over it) that now I'm looking at building Vue-Components until we can get rid of IE11. I am OK with this as development is a team sport :D

This is NOT a Stencil issue: This is one of those 'I can probably make it work if I invest enough time and energy', but the time-investment, risk of breakage with multiple errors on ng start --es5 whenever IE is open (again: Stencil app environment) and polyfill breakage is all a bit too much if we HAVE to support IE11 as a PRIMARY (IE: Daily use for all general browsing) browser. (Which is to be expected: Ionic v4 dropped IE11 support, and Stencil is what they used to build all of their components).

I'm still going to continue my journey with Stencil and Vanilla web-components, just not in my current project.... which makes me sad :(

Takeaway for anyone who wants to know if they should use Stencil in their projects: YES. Most of these issues are not with components generated by Stencil, but probably environmental. Our particular use-case just favors speed and stability over rampant innovation (which isn't always a bad thing).

Know the risks (especially if you're pulling in another teams web components) and keep moving forward. Everyone reading this is probably a better engineer than me anyway (or at least that's what the imposter syndrome keeps telling me ;)

[Scott Yeatts]

Following-up: My arguments made it, and we knocked down some roadblocks: Stencil/Web Components are a GO! Very excited. I may have some more posts in the future about the journey to try and get some more info out there and help people avoid the mistakes I am sure I'm about to make.

Fingers crossed people, let's make it happen!

[Alexey Kallaur]

Have you eventually solved those issues and made stencils app working in ie11? Seems like I encountered the same problems

[Scott Yeatts]

EDIT: 18 Feb 2016
Something changed between writing this and getting started on the frontend of our app, in the best possible way. I don't know what, but I have not seen a polyfill breakage since my POC. I've got our app up and running on Stencil and have seen very few of these issues. So I guess the ultimate answer is yes!-

I have actually been side-tracked into working on the Java backend since I built the POC, so I have not been able to work on this at all.

I WAS successful in making the argument that full support for IE11 was a very bad idea, and we are going with an alternate, extremely minimal UI specifically for IE (we're talking no-frills bare-bones UI), but the longer we put it off, the closer we get to January 2020, when extended support for Windows 7 ends and I will argue that IE support should go with it.

I actually argued that we shouldn't be supporting it now, either, but you know businesses... There's always one person on the chain that's worried the old guy above him is going to still be using IE, and sees that as a technological issue, not a training one haha!

One suggestion would be to write each component individually and not use their app starter environment, but honestly IE11 is going to give you headaches if you use any browser/tech developed before 2015 and isn't being consistently updated. The browser engine just doesn't have any of the things that have been added to the spec since then...