>> Node.js has over 30,000 modules available<p>how many of these are over a year old? how well maintained are they? how battle proven? how well is v8 going to be maintained 10, 15 years from now? can we buy an extended support contract for v8 from Google?<p>these are also questions people in enterprise want to know. how well does it interact with our existing CLR/JVM stack that we've used for the last 10 years?<p>I have never been convinced by the "writing server side and client side code in the same language is good" argument, different jobs require different tools. Someone once said of this:<p>'you know how to use a knife, so you bring a knife to a modern war fought with guns, tanks, and missiles while shouting "at least I can use the same tools when I eat and when I fight! I save so much time!" before somehow managing to shoot yourself in the foot anyway.'
No dynamically typed language is going to be "The Dominant Language Of The Enterprise" anytime soon. When you have hundreds of mediocre developers in cubicles pounding away at a single, huge, codebase, you're going to want as much compile time checking as you can get. You're going to want the ability to refactor and immediately see everything that needs to change, etc.<p>For a new language to have a shot at it, it should be statically typed and probably run on the JVM or CLR.
Simple learning curve? The thing is its really easy to write bad Javascript and a lot harder to write good Javascript. For that reason I think it has a much higher learning curve then most of the current languages used for web development.
This article is content marketing for Appcelerator. It builds a straw man of enterprise development that is convenient for Appcelerator's business model (scaling JavaScript applications), neglecting to consider other concerns such as stability, maintainability and support.
With large software projects you want a language that is relatively easy to read. This is the biggest problem with JS, it's pretty easy to write but can become unreadable pretty easily.<p>Even best practises as described by "the good parts" are full of nested parens and functions , .call()s and IIFEs
Here's my list of why other frameworks have become the language of the enterprise: (you can draw your own conclusions as to why JS won't fit).<p>1) Large resource supply - .NET, Java, etc resources are cheap, quick to deploy and abundant.<p>2) Pay-for library support - I can pay Oracle and MS gobs of money to support me when things go wrong. (how quickly they fix things is another question for another discussion)<p>3) Supported engine - Enterprise customers pay IBM, HP, MS, etc for support of JVM's, etc in order for the code to run.<p>4) Scalability - There is a reason programs at scale are written in languages that are written for performance. "Enterprisey" languages are verbose and have to be compiled because they allow for better control of performance at scale (notice I didn't say they perform better, there is a big distinction)<p>Lastly, JS <i>is</i> already an Enterprise language, but mainly for front-end only. So the argument is whether it becomes a back-end language.
Try writing anything larger than 10.000 LoC and JavaScript becomes a pain in the ass. No matter how many frameworks will appear unless there are fundamental changes in the language I don't see it making it to the enterprise.
I can't help but attribute all the JS bashing to good old-fashioned tech nerd snobbery.<p>A scripting language IS a programming language.<p>Write code -> some method of compilation -> Computer executes == programming language.
Saying that something will have the same language on client and server is misleading: javascript (and most other languages) have very simple syntax - it's more about the libraries involved. Node.js and the browser environment are totally different (and I doubt there are many packages written for both settings).<p>Even if everyone were working in JavaScript, seems unlikely that you'd be able to be both an awesome client-side and server-side developer.
If we are talking front-end, then Javascript is already the dominant language for EVERYONE (for the web anyways.)<p>> Big brand names like GM, Yahoo, Dow Jones, Walmart and Dell have all deployed Node.js and are touting its merits.<p>It's as if the borg is chanting node while it slaves away on its corporate machine. I bet if I asked Michael Dell what he thinks about Node, he would probably tell me to F-off.<p>I googled LinkedIn and the first result talked about how they replaced their Rails app with a Node app. Right, when I see an article talking about how X huge corp replaced their Scala app with Node then I might be more convinced.<p>We don't need to be locked into any one tool though. As we learn how to build things better we find that we can route our pipes to different boxes which handed different things rather than having one huge box handling everything.
I love every time an article like this appears. Everyone is immediately on the fence, bashing JavaScript furiously. Yet momentum doesn't appear to be declining?<p>I'm a JavaScript developer mainly, with a background as a front-end oriented developer (php), but I also dabble a bit with C/Objective-C - especially since JavaScript got me interested in application development in general. JavaScript does bring a lot of freedom, a freedom that can hold you back, if you're not careful (code bloat, callback hell etc). The thing is, JavaScript is just plain fun to write in, and the responsiveness and full-stack capabilities are amazing.<p>I think we just have to accept that JavaScript is here to stay. And should its popularity fade, I should be ok with that as well. But until then, I'll keep having fun at work.
I like JavaScript and node.js but I simply can't wrap my head around callbacks. Some people simply love to nest callbacks... Anytime I see that it drives me crazy....
Enterprise software is about long-term maintainability, compatibility, and comprehensive support for all included components. Pulling packages from npm and the like unfortunately will not satisfy those prerequisites.