JavaScript - how to balance innovation and volatility in enterprise software

JavaScript was a poor cousin of "proper languages" for many years. In some ways it still is. But its popularity and the vibrancy of the ecosystem in recent years tell a different story.

I've written a lot of JavaScript framework and application code back when runtimes were slow and libraries near non-existent. Compare that with today and today's JavaScript is impressive.

With vibrancy comes volatility - the pace of new libraries being introduced is extreme. This volatility is probably great if you're a startup trying to do few things but do them well. For those of us engaged in slightly more complex enterprise applications volatility smells like cost. It costs to keep replacing libraries with the next new hot library, and it is hard to attain efficiency of scale if different teams pick different libraries whenever they feel.

However, we must control our instinctive tendency to go for scale efficiency first. There is a new balance to be found whereby individual teams have the freedom to innovate and explore to find what is best for them, and the need to ship cohesive enterprise products with a low maintenance overhead and risk.

I suggest that this balance is best found via a lightweight evaluation based on observable facts which impact the enterprise point of view. This approach ignores the discussion of the more subjective elements of the developer experience - based on the assumption that the development team should know best since they will be stuck with the consequences of their own recommendations.

The parameters to evaluate from an enterprise level include:

• Relative learning curve compared to other libraries in use - will it be difficult for future developers to skill up to maintain and add to code?
• Does the library integrate well with existing toolchain? How and where should it be done?
• Can we begin small and incrementally increase use the new library or does its success rely on a riskier big bang introduction?
• Can we automate handling of library dependencies?
• Is the library suitable for code generation?
• How does the library support automated testing?
• Does any GUI aspects of the library use an easy-to-understand styling selector scheme - sometimes these are so clever but ideosyncratic that it makes enterprise consistency hard to achieve - if nothing else because it may be hard to motivate a developer to understand it well enough to implement a UX designer's wishes
• State handling must be compatible - no point in injecting a new library focused on local state if the rest of the JavaScript architecture was designed to avoid local state
• ... this is not an exhaustive list but only goes to show that there are a number of enterprise-level properties which can be discussed in a fairly objective fashion and still allow exploration and innovation in individual development teams

I'm writing this as I got inspired by Elm. Elm is an interesting approach where you write highly declarative code which is subsequently compiled into optimised JavaScript. It's not unique in this but it seems compelling. Elm would go through above enterprise review rather well because it encourages co-existence and incremental use, and because while it will feel alien to some it does compensate with type inference to avoid those annoying nondescript runtime exceptions which plague JavaScript.

Please share if you have experiences to share on how to balance JavaScript innovation with enterprise needs?