The Enterprise JavaScript Conundrum

I’m a full stack developer in the way that McDonalds is a breakfast restaurant; yes, they serve breakfast, but only really from 5am to 10:30am. I only get into the nitty gritty of the frontend when I absolutely have to, and it’s certainly not a place that I generally spend a lot of time. Saying that, it’s important to keep up with what’s out there, at least from an awareness perspective. The frontend darlings at the moment are clearly Angular (particularly in the Melbourne market), and React. I’ve worked with Angular (1.3) previously, but thought it was time to see what React was about, as there’s a lot of talk about it around the office water cooler. It became a rather interesting adventure down the rabbit hole…

First up, the tooling around JavaScript is changing at a neck-snapping speed. If we look at Babel’s installation instructions (more on that later), there are 30 configuration options. Kudos to the Babel team for supporting such an impressive plethora of tools, but it makes selecting an “optimal” configuration challenging. Then there are the tools themselves. Tools such as Grunt which were du jour a couple of years ago have been relegated to almost a pariah status amongst some of the new libraries. If you’re not starting with Webpack (maybe with a hint of Gulp), then you’re not starting on the right foot. Webpack itself has a fairly steep learning curve, but once you’ve got it setup correctly you wonder why you ever lived without it. The automatic refresh capabilities with the inbuilt dev-server are super helpful. Saying that, it doesn’t “just work” out of the box, and you still need to tinker around with it before it comes to life.

To use the latest version of JavaScript, ES2015(ES6), you really need to use a transpiler like Babel to convert the code down into something more universally implemented across the various browsers + node. If for example you want to use the new arrow function it doesn’t work on Mobile Safari, which is not going to get you many friends on mobile.

It’s a pretty exciting time to be a JavaScript developer, but I’m concerned that the pace of innovation isn’t compatible with the approach taken by large enterprise customers when it comes to maintaining their websites/applications. Companies in Australia might be shifting their development practices to being more agile-oriented, but their approach to projects and code maintenance is still very much stuck in the waterfall. You might work for n sprints to deliver a new application, where you’ve used something like Webpack, and React, but once it’s delivered it’s then handed off to a Business As Usual (BAU) team which doesn’t necessarily have the funding to continually update and maintain the codebase. I’ve worked on applications during the last year that will be in one form or another still being used by their respective clients for the next five years. What happens if they need to add some functionality in five years time? Will they still be able to download and use the Webpack tooling with the required dependencies?

The solution is understandably to change the way codebases are developed, maintained and funded within companies, but it’s hard to encourage these practices without some kind of “crises” to facilitate the discussion. I think it’s about curtailing over excited developers to a certain set of approved tools, and then making sure new versions or approaches are rolled out across every living application. I was working with a client last year where they were trying to run multiple, older versions of Angular applications on the same page. These problems are a development nightmare and ultimately end up in sub-standard user experiences. A trickle upgrade approach needs to be mandated for all enterprise projects, especially when dealing with consumer facing JavaScript projects. It might not be as exciting now, but you’ll be thankful when you’re getting called up in five years to update your business critical Angular 1.5 app.