It’s daft to build a castle in the swamp. It’ll burn down, fall over, and then sink into the swamp. JavaScript is a swamp. It’s the most important swamp in all of professional programming right now, and if you’re a developer, you should have a professional mastery of it. But it’s a terrible foundation for an enterprise codebase.

Right now, enterprises are facing a confusing future: Microsoft’s technical guidance has lost its AAA rating (although it’s certain that sooner rather than later we’ll get a new road map from Microsoft) and the JVM world lacks a clear directional focus due in no small part to the complexities of Google, Android and the slowness with which Java has been evolving. Meanwhile, Apple has gone from virtual irrelevance in the enterprise market to owning the mobile devices in the C-suite, and it is making fantastic desktop-replacement laptops but locks you into an effectively proprietary language.

Facing all this complexity, too many people are offering a simplistic solution: JavaScript and HTML5 as platforms for enterprise and mobile development. “Everyone can program JavaScript! It’s universally available! There’s a canvas tag! You don’t have to make a hard call!” For the large majority of enterprises, not only do I think this is a mistake, I think it’s a recipe for disaster.

Now, I do have a dog in this fight: I work for Xamarin, which allows C# developers to write native cross-platform apps for both mobile and desktop operating systems. But I didn’t develop my analysis because I joined Xamarin; I joined Xamarin because of my analysis.

It’s true that the set of JavaScript programmers is larger than the set of enterprise software developers, and that anyone with the skills to develop software professionally can learn and master the JavaScript language. That doesn’t mean that every Web developer is suddenly going to be competent at building applications or infrastructure, nor does it mean that your software development team will be as productive in JavaScript as they have been in their preferred language. There are four major issues when it comes to JavaScript productivity:

First, there’s the platform SDK issue—as in, there isn’t one. For instance, a Web search for “JavaScript security library” points me toward a project written by three people, with 38 commits, the last of which was a year ago. The authors have excellent credentials and I’m sure the code is exemplary, but I wouldn’t have confidence in using that to protect my enterprise’s crown jewels. Despite the obligatory snarky comments about the NSA, backdoors and corporate cooperation, platform companies have the resources, discipline and motivation to maintain all the critical (but perhaps boring) parts of the vast surface area of a platform SDK.

Second, there’s the type-system philosophy. I like dynamic type systems. I dream of an alternate world where Smalltalk (or at least Ruby) plays a major role in every enterprise’s codebase. But the industry has rejected that vision time and time again, at least for the very large majority of its internal code. There are good reasons to have compile-time type checking, and I think it’s foolish to think that the market has had some sudden unheralded change of heart.

About Larry O Brien