Is it just the JavaScript tag or are there any serious drawbacks? I suppose ES6 solves a lot of issues and improves Node/JS. So, my question is it still unfit for corporate/enterprise development?
Out of interest, was the question really regarding JavaScript or Node? Node implies server side development, JavaScript could be either; JavaScript is the only way to really develop client-side browser code and is therefore already enterprise by lack of choice.
Java and the JVM is 20+ years old and received many millions in funding by enterprises to build something that would cater for the enterprise. Node has yet to prove itself.
What is node missing? With most dynamic languages, 3 years is considered enough time to deprecate some feature. With Java, most of the features have been carried along for over a decade, so the risk of your software stop working is much smaller with Java - Node and JavaScript are still changing and so are the libraries on NPM - maven libraries for Java have been stable for ages and are being managed by an organisation who won't just pull a library for the hell of it.
Enormous Fortune 500 companies are backing Java, Node doesn't have that level of backing.
Businesses require integrations into strange things, ISO integrations, SAP, rule engines, etc. The Java ecosystem has many solutions for these problems, Node doesn't.
A decent threading model, proper concurrency support, high-performance, strong-typing - all things enterprises look at, Node has one trick which is reactive support which Java is now getting as well.
Can you get certified as a Node developer? With Java you can, you can be certified by Oracle, something which certain enterprises look for if you don't have an engineering degree.
Fantastic database driver support - for every database there's a defacto database driver that's considered standard and mature - one that works well and everybody works on instead of massive segregation you get on NPM.
I can run Scala, Kotlin, Jruby, Jython, Java, Groovy, Clojure, Nashhorn (JavaScript on the JVM) etc etc all on the JVM - many choices all on the same infrastructure; on Node you can only run JavaScript - a language which is still seen as that thing you use to do fancy things in the browser with by many enterprises. To the enterprise, there's only C# and JVM-based languages, anything else is frowned upon.
When SUN designed Java back in the days, it was focused on exactly what the enterprise was looking for and I think they spent 4 years before releasing Oak (Java 1). JavaScript was designed in 10 days, without the needs of enterprises taken into account.
On which platforms does Node run? Java runs on just about everything, BSD, Linux, Solaris, Sparc, Windows, mainframes, mobiles, OSX and can also be cross compiled to JavaScript to run in the browser. Enterprise often has legacy infrastructure or specialized hardware which the JVM supports more often than not.
Java and the JVM works well, alternatives such as Scala and Kotlin makes it much more modern if you want to get away from the boilerplate that comes with Java, but they can all run together, you don't have to use Java whereas with Node, you have to use JavaScript.
Enterprise languages like Java or C# are often called "bondage and discipline" languages. They make it easy to use static analysers and to write APIs with very strict rules about what is or isn't acceptable use or input. An incompetent programmer can still write bad code in these environments but they are far less likely to cause considerable damage as long as they follow the rules.
Apart from making it easier to limit the damage bad programmers can cause (which is a much bigger problem the larger your company is, especially if it is not a tech product company or if the software is optimized for longevity rather than developer comfort) these languages also often enable a lot of tooling by virtue of being easy to statically analyse.
Dynamic languages like JavaScript (or even Ruby and Python, though slightly less so) are very hard to analyse statically unless you limit yourself to a subset of the language. That is why Google first created Dart as an alternative to JavaScript and then put their weight behind TypeScript (which Microsoft created as a stricter superset of JavaScript with type annotations). Facebook took a similar approach by creating Flow as a static type checker for JavaScript (with their own type annotation syntax).
There's also the matter of integration. For many enterprise corporations a lot of Java/C# code is effectively glue code to tie together software from enterprise vendors like Oracle, SAP or Microsoft. While Microsoft has been opening up and standardizing their APIs recently (e.g. moving from a proprietary undocumented single-sign-on system to OAuth 2) this is mostly part of their effort to evangelize web developers (who mostly moved away from Windows because it was too different from their production environments running Linux).
But in my opinion where Node.js really shines and has seen some acceptance in the enterprise is as a "glue language" to write micro-services in. Building small services to provide specific functionality (e.g. realtime notifications in a web app) is extremely easy in Node compared to, say, enterprise Java, and thus Node is often added to existing stacks rather than replacing them entirely. It may not be suitable as an enterprise general purpose solution but it's great for small off-hand projects that need to be released outside the regular enterprise cycle -- similar to how PHP often ends up in the enterprise.
Couple of things, actually.
Node.j lacks enterprise tools and solutions. Most of Java based systems we see, are using IBM tools one way or the other. And it is a norm in enterprise scenario. But lack of tools and support from major vendors for Nodejs mean, it is considered as a risky proposition to even pick from client side! When a team of people discuss about infrastructure and feasibility, there are lot of factors like, will this language got enough enterprise tools for us to use? Can we get enough resource in this lang? Node.js is buzzword, but there are very limited experienced resource simply because it is pretty new to the market.
Corporates want some big names that used certain language to assure themself that the choice they made is right one. Trust me, even names like LinkedIn and twitter weren't enough to convince the higher ups to go with Node.js for simple utility module. Unless Node.js get some tremendous support, tools to go with enterprise system, it will never become mainstream language in an enterprise setup like say, Java!
Olivia Lyon
abcopensource
Jacques de Hooge
Main developer of the Transcrypt Python to JavaScrip compiler (http://www.transcrypt.org)
The JavaScript world is a very dynamic world. On the upside this means that there's a constant stream of new features that touch the core of the language, innovative applications and clever libraries. On the downside this means that the JavaScript landscape has changed beyond recognition in a few years time, and will continue to do so.
Enterprise application development means investing a lot of money in specialized applications that often have an expected lifetime of 5 years +. But 20 years + isn't an exception. JavaScript itself has a reasonable track record of backward compatibility, although some older coding idioms break the performance of recent highly optimized interpreters.
For libraries this is different. Newer ones rapidly supersede existing libraries. There are many ways to get to the same functionality. It's like evolution in the highest gear: it's impossible to say which ones will be the "fittest" and will survive. So making long term bets for long lifetime applications is very hard.
On top of that JavaScript itself has it's intricacies. It SEEMS an easy language, and used for small "scripts" it is. But once developers start designing larger systems with it, many have a hard time finding their way. A concept like "prototype based inheritance" e.g. is the subject of countless explanations on the Internet, some clear and concise, but many of them half-understood and quite some of them plainly wrong.
Lastly, where performance is crucial, an interpreted, dynamically typed language has its limitations. JavaScript is not the only language suffering from this. A language like Python is in itself unsuitable for e.g. number crunching. But in the Python ecosystem C/C++ based libaries fill the gap. This is not (yet) the case for JavaScript. The fact that the accent is still on running it in the browser makes it unlikely that such high performance libraries will emerge soon.
So while, given the enormous number of developers using it, JavaScript no doubt has a bright future, and may eventually overcome most of these limitations, using it for multi-year projects in its current form in my view carries a high risk.