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.

Third, and most critical in my view, involves the type system, but it also involves other aspects of JavaScript’s syntax and semantics. All programming languages have issues that, if ignored or forgotten, lead to problems. My beloved Smalltalk evaluates “1+2*3” as 9. But whether you call them flaws or quirks, JavaScript’s type coercion and concatenating “+”; semicolon insertion; and error-prone semantics relating to “falsy/truthy,” “undefined/null,” and “with” are very consequential in the real world.

JavaScript’s prototype-based inheritance has merits, but those familiar only with Java or C# models will suffer from an “impedance mismatch” similar (but perhaps even more insidious) to that between objects and relational data. These are exactly the kinds of issues that professional developers are paid to master, but JavaScript’s dynamic type system makes static tool-based discovery of these problems significantly harder.

Finally, there’s legacy integration. I was talking with a colleague recently about a 100,000-line library dedicated to controlling the numeric errors in oil-drilling operations. When you propagate a tiny error down two miles of drill-line, it can turn into a big and really expensive error at the head. Just touching a line of code in this library is, apparently, subject to executive review. A rewrite would be an enormous undertaking, a rewrite into JavaScript’s type system would be especially worrisome, and “Just do it with Web Services” is not an answer for oil-field operations. Legacy code and legacy data drive enterprise codebases, and just because that’s often frustrating doesn’t make it less true.

Since the world is complex, there are counter-arguments to each of my points: The number of JavaScript libraries is growing, the market resistance to dynamic type systems might change, JavaScript’s quirks can be avoided, and legacy code can be improved by a careful rewrite. There are great applications written in JavaScript, a lot of startups are betting on JavaScript on the server (reminiscent, to me, of those 1998 startups that bet on Perl on the server), and there are languages that layer different semantics on and “compile down” to JavaScript.

There are some who say that if you persevere building your castle in the swamp, eventually you can have the strongest castle in the isles. I don’t believe it. Foundations are important.

Larry O’Brien, former Editor of Software Development and Computer Language magazines, is a software developer living in Hawaii.