Since last week’s .NET Meetup in Louisville, KY, where Jared Faris spoke about ECMAScript 6, I’ve been troubled by the problems ECMAScript 6/2015 is going to cause. In fact, I think ECMAScript updates will cause more problems than it solves for the Enterprise. Below, I’ll share some of my thoughts on what ECMAScript updates will do to the Enterprise and what you can do today.
Background
A little background – I’ve been a .NET developer since day 1. I grew up with .NET and unfortunately WebForms. Aside from some Java Applets I wrote 10+ years ago for a Software Engineering course at Xavier, I hadn’t done a significant amount of web programming until WebForms (…my WebForms history and love/hate relationship over the years is a topic for another day…). Back when I was doing WebForms on a regular basis, IE 5.5 and IE 6 were “it” – you HAD to support these browsers. Web development both sucked (hello? IE 5.5./6) and felt cool because of emerging technologies (remember AJAX anyone?).
The rise of new browsers and need for cross-browser compatibility
Cross browser compatibility was becoming important, but not for the reasons you may think – it was mostly because you never know which version of IE was running on someone’s desktop. My point, anyway, is web development was frustrating because everybody was making their own standards and support the “official” standards all willy-nilly.
The Enterprise Problem
Today, we have made some great progress – newer browsers like Chrome and Firefox have made a huge dent in browser market share, pushing out IE – but large enterprises are still stuck on IE (or Enterprise developers are still stuck supporting IE in addition to Chrome/Firefox/Safari/etc.). It’s not bad that Enterprises are still using IE – the real catch is having to support a non-Evergreen browser, like IE.
So, what will ECMAScript 6/2015/etc. do for the Enterprise? I think ECMAScript 6/2015/etc. will take the Enterprise back another step – we will run into similar cross-browser compatibility issues as we are still seeing today as Enterprises are upgrading operating systems.
Two Options for the Enterprise
First, the adoption of Evergreen browsers will help to alleviate compatibility problems (but that assumes browsers will keep up with the standards). I have confidence we’re moving closer to Evergreens browsers that are updated in accordance with the standards, but a large barrier exists for legacy applications. Right now, Enterprises are shying away from application refactoring because it’s costly, and the risk of refactoring is extremely high due to a lack of regression tests and application subject matter expert availability. Instead, Enterprises are relying upon internet Explorer “Enterprise Mode“, which can be deployed via Group Policy. Small/Medium Sized businesses are in a similar situation; however, they tend to lack the resources and funding to refactor their applications. As a result, I see a HUGE opportunity for recent college grads to jump into these types of businesses and upgrade a ton of apps – the price point is right, and the “just get it done” mentality exists.
Second, developers can rely on JavaScript compilers to recompile their new ECMAScript code to pre-ECMAScript 6/2015/etc. compliant standards. Javascript (and CSS) compilers aren’t foreign to web developers today; however, there’s an old curmudgeon in me screaming, “Get off my lawn – I don’t want your stinking compiler!” Alas, I’ll get over it. Don’t worry. I predict we’ll see better IDE support for compilers, with compilation being the “norm” in 1-2 years. There already exists a good community of JavaScript compilers, with Babel as an arising leader.
What Can I Do Today?
To get prepared for impending chaos of ECMAScript updates, you can do these things:
- start integrating a JavaScript compiler into your build workflow, check out Babel, or TypeScript
- start using the new ECMAScript 6/2105/etc. features
