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?
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?
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:
'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.'
Well of course we can expect that a scripting language designed for manipulating text-document markup into pretending to be a full GUI application in a nonstandard browser-specific way will be an excellent language for general-purpose backend computing.
Yeah right , so your app doesnt have business objects ? validation ? complex business rules that need to be enforced server side ? server-side queued processes and middlewares ? what kind of app are you talking about ?
The number of modules don't matter, but what does matter is that NVM and NPM are incredible tools. I've never used any package or version manager that comes close to their polish, ease of use, and simplicity. They make a huge difference. I think the true success story of node.js lies in those tools. The deployment and project building process is not just easy, it's actually enjoyable, and exciting. I cannot say that about any other build tool.
I do think having the templating portion of the web stack being in a client side language is important, as there's typically lots of overlap and interoperability that can happen at that layer between the client and server. As for the rest, I don't buy into the whole having a single language is better for understanding and hiring. Picking the right language that has the right metaphors for the problem will make things easier than having the same language everywhere.
The top used module in npm was written for the browser (underscore)
A huge amount of code can / is be shared between the server and client, I wrote a database designed to work in browsers, a pull request away and it works in node.js using a different storage engine, 90% of the code is shared[1], the only people that arent convinced that sharing code between the server / client isnt useful just arent paying attention.
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.
Even best practises as described by "the good parts" are full of nested parens and functions , .call()s and IIFEs
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).
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.
I'm not a node guy, but I thought one of the big advantages was just that... that you could use a lot of the same code. ORM/object modelling should be fine on server or browser, also template rendering, data/form validation, etc.
One thing that is a pain in conventional web development is for a lot of these things having to implement them twice (or write clever automatic converters or whatever to generate the backbone.js (or whatever) boilerplate models from the original django/rails/whatever/schema.
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.
Obfuscation to name one. I don't see any enterprise moving to a platform where you can't protect your code from prying eyes. Although it's not inherently a language problem per se, (it could be solved by browser technology) it would help a lot if the language could be compiled.
We are talking about backend javascript, arguably javascript is already the top front-end enterprise language.
So browser technology has nothing to do with it. Furthermore, Java can be decompiled in a format that is eaiser to read than explicitly obfusciated javascript.
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....
Callbacks are possibly not the best way to solve concurrency issues. Node.js does it that way, but there's no inherent reason JavaScript should only solve concurrency problems with callbacks. It would be possible to implement a wide variety of concurrency models in JavaScript, and I'm sure people have and will. Node.js happens to be the early winner in that space.
We are still pretty early in the JavaScript story on the server side.
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.
Exactly, any language that lets you program at the same time in an imperative, functional and OO fashion is anything but easy to pick up, let alone master. Personally I still have to get around and learn it, it just seems an extremely daunting undertaking.
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.
For a new language to have a shot at it, it should be statically typed and probably run on the JVM or CLR.
If the enterprise wanted as much compile time checking as possible, why haven't they adopted something like Haskell years ago? The checks done by the type systems of the JVM and CLR are laughable in comparison. There must be some different reasons at play here, too.
Of course there are reasons beyond compile-time checking, that is just one of the many requirements of an "enterprise" language. Haskell has strong type checking but fails in many other areas. Namely, being easy to understand by mediocre to average developers (and even some good developers).
They're getting there. The leading edge of enterprise is already using scala or F#, which have a lot of the power of Haskell (in fact I'd argue scala's is more powerful in some ways, e.g. typeclasses cease to be a special case).
In terms of using Haskell in the enterprise, it isn't standardized enough (most libraries rely on GHC extensions), the library ecosystem isn't mature enough, cabal is still a mess (it's too easy to get your dependency tree into a broken state), there's not enough commercial support, there's not enough deployment/monitoring infrastructure around. Fundamentally, it was produced by academics who didn't care about selling it to the enterprise, and the effort to address these concerns hasn't entirely happened yet. It's getting there, and I think we'll see more of it as time goes on.
I believe the evidence indicates you're wrong. The incredible growth of JavaScript usage makes it virtually inevitable...it is, simply, the fastest growing language in the history of programming languages. There are more machines with JavaScript available and more programmers with JavaScript experience, than any other single language. That will result in more rapid library and tool support development in the near future (right now, there are languages with better tool support and bigger libraries of existing functionality...but, in a couple years that lead will evaporate).
Other dynamic languages have had a large impact on enterprise systems: Perl, Python, Ruby. JavaScript just happens to have the killer feature of being everywhere...including on the most important platform (the web).
Your premise about the incompetence of programmers is a false dichotomy. You've provided no evidence that statically typed languages make inexperienced programmers more productive. There's some evidence in favor of some esoteric languages, like Haskell and Erlang, being more productive for some classes of problem. But, dynamic languages tend to do well in the studies I've seen.
You're also assuming that even if statically typed languages were more effective for inexperienced programmers that that would be the only factor in enterprises selecting a language. There are many factors, and popularity is a huge one.
The trend in languages has been toward less boilerplate code. Even Haskell (arguably among the most strongly and insistently typed and "safe" languages) is vastly more concise than, for example, Java. One could possibly argue that Haskell (or similar functional languages, like Scala) would be "better" for the enterprise...I think it would be hard to argue that it's realistic to expect any of them to become as prevalent in the enterprise as JavaScript already is.
I think it's pretty obvious that Java (and C++) will continue to lose enterprise market share, and, to me, it's obvious that the language that will pick up most of that share will be JavaScript. Other languages will also be in the picture; Scala, for example. But, it won't put a dent in JavaScript's massive growth.
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.
A recent nodeup episode discussed how many enterprises aren't using npm packages unless they wrote them in house, because they don't want/trust any code they haven't written themselves.
I've also seen other companies who do use third party modules through npm make sure they have local copies documenting the version, source, source url, etc. Just in case a particular project disappears.
One thing I wonder about, so far it seems to be mostly doing ok, but will NodeJS suffer the library versioning problems that plagued Java when I last used it...frameworks importing 2-3 different versions of Apache Commons for instance.
Seems like 'in general' this is a good practice. you need to know 'what's inside' if your writing bank, finance, health-care, etc ... apps on top of other peoples code. besides as a developer you want to make sure running 'npm update' does'nt change a foundation library in a negative way. the best practice in enabling this is still up for dispute.
A recent nodeup episode discussed how many enterprises aren't using npm packages unless they wrote them in house, because they don't want/trust any code they haven't written themselves.
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.
That is true, historically compliance and governance has ruled enterprise IT and corporate workflow software. However its future may have priorities such as: time to market, access and cost of developer resources, flexibility and accessibility ( ubiquitous, open source, easy to learn ). javascript leads in these characteristics.
Client side javascript has ruled the web, mobile implementations such as phone gap and Appcelerator's Titanium are attacking mobile. Node.js gave developers with js skills access to the server. The race is won by shipping code and a developer's skilled in javasacript are shipping products to 'market' faster with more features and less cost than other language based projects.
Compatibility, maintainability, and enterprise level support will be solved by platform vendors who provide services and software 'on top of' javascript ( and its server side cousin node). Platform companies that makes it easier for js developers to introduce javascript projects into their corporate environments should look to these vendors to help them solve these problems. The future may be the best of both worlds.
In full disclosure I worked with Nolan at Appcelerator and I now work for the Node javascript company StrongLoop.com, clearly I'm betting on javascript. There are lots of problems to solve and it will make for some exciting times in the years ahead.
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.
If we are talking front-end, then Javascript is already the dominant language for EVERYONE (for the web anyways.)
> Big brand names like GM, Yahoo, Dow Jones, Walmart and Dell have all deployed Node.js and are touting its merits.
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.
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.
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.
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).
1) Large resource supply - .NET, Java, etc resources are cheap, quick to deploy and abundant.
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)
3) Supported engine - Enterprise customers pay IBM, HP, MS, etc for support of JVM's, etc in order for the code to run.
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)
Lastly, JS is already an Enterprise language, but mainly for front-end only. So the argument is whether it becomes a back-end language.
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?
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.
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'm not saying the article is right either, since it is a rather bold claim. But it is just as one sided to write it off as stupidity, because JavaScript is dynamically typed - or whatever. I can't force anyone to like JavaScript, nor would I like to, but my personal experience does lend some credence to OP from where I'm sitting.
I think the biggest problem with OP's claim is the lack of true enterprise software written in JavaScript. I can't think of anyone, besides a few lightweight SaaS applications.
We're currently building a large-scale application for public schools here in Scandinavia, but it is augmented by a .NET service backend. I hope we'll get a swing at a full-stack solution soon.
> 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?
All it will take a different scripting runtime (with equivalent performance, which isn't a hard problem) in a major browser and javascript will literally disappear in a half-decade.
56 comments
[ 3.2 ms ] story [ 133 ms ] threadhow 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?
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?
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:
'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.'
It comes off as pretty funny that way, and helps make the point.
"He could shoot himself in the foot with a knife."
(Although JavaScript in particular is not an excellent language for anything.)
I do think having the templating portion of the web stack being in a client side language is important, as there's typically lots of overlap and interoperability that can happen at that layer between the client and server. As for the rest, I don't buy into the whole having a single language is better for understanding and hiring. Picking the right language that has the right metaphors for the problem will make things easier than having the same language everywhere.
A huge amount of code can / is be shared between the server and client, I wrote a database designed to work in browsers, a pull request away and it works in node.js using a different storage engine, 90% of the code is shared[1], the only people that arent convinced that sharing code between the server / client isnt useful just arent paying attention.
[1] https://github.com/daleharvey/pouchdb
Even best practises as described by "the good parts" are full of nested parens and functions , .call()s and IIFEs
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.
One thing that is a pain in conventional web development is for a lot of these things having to implement them twice (or write clever automatic converters or whatever to generate the backbone.js (or whatever) boilerplate models from the original django/rails/whatever/schema.
Why does that seem unlikely? Sure, they're largely non-overlapping skill sets, but plenty of people are very good at more than one thing.
Seems like it scratches that particular itch.
https://github.com/gmarty/grunt-closure-compiler
So browser technology has nothing to do with it. Furthermore, Java can be decompiled in a format that is eaiser to read than explicitly obfusciated javascript.
We are still pretty early in the JavaScript story on the server side.
This is the correct reaction to heavily nested callbacks.
https://github.com/caolan/async provides several excellent functions to make readable code instead of callback soup.
For a new language to have a shot at it, it should be statically typed and probably run on the JVM or CLR.
In terms of using Haskell in the enterprise, it isn't standardized enough (most libraries rely on GHC extensions), the library ecosystem isn't mature enough, cabal is still a mess (it's too easy to get your dependency tree into a broken state), there's not enough commercial support, there's not enough deployment/monitoring infrastructure around. Fundamentally, it was produced by academics who didn't care about selling it to the enterprise, and the effort to address these concerns hasn't entirely happened yet. It's getting there, and I think we'll see more of it as time goes on.
Other dynamic languages have had a large impact on enterprise systems: Perl, Python, Ruby. JavaScript just happens to have the killer feature of being everywhere...including on the most important platform (the web).
Your premise about the incompetence of programmers is a false dichotomy. You've provided no evidence that statically typed languages make inexperienced programmers more productive. There's some evidence in favor of some esoteric languages, like Haskell and Erlang, being more productive for some classes of problem. But, dynamic languages tend to do well in the studies I've seen.
You're also assuming that even if statically typed languages were more effective for inexperienced programmers that that would be the only factor in enterprises selecting a language. There are many factors, and popularity is a huge one.
The trend in languages has been toward less boilerplate code. Even Haskell (arguably among the most strongly and insistently typed and "safe" languages) is vastly more concise than, for example, Java. One could possibly argue that Haskell (or similar functional languages, like Scala) would be "better" for the enterprise...I think it would be hard to argue that it's realistic to expect any of them to become as prevalent in the enterprise as JavaScript already is.
I think it's pretty obvious that Java (and C++) will continue to lose enterprise market share, and, to me, it's obvious that the language that will pick up most of that share will be JavaScript. Other languages will also be in the picture; Scala, for example. But, it won't put a dent in JavaScript's massive growth.
One thing I wonder about, so far it seems to be mostly doing ok, but will NodeJS suffer the library versioning problems that plagued Java when I last used it...frameworks importing 2-3 different versions of Apache Commons for instance.
That is true, historically compliance and governance has ruled enterprise IT and corporate workflow software. However its future may have priorities such as: time to market, access and cost of developer resources, flexibility and accessibility ( ubiquitous, open source, easy to learn ). javascript leads in these characteristics.
Client side javascript has ruled the web, mobile implementations such as phone gap and Appcelerator's Titanium are attacking mobile. Node.js gave developers with js skills access to the server. The race is won by shipping code and a developer's skilled in javasacript are shipping products to 'market' faster with more features and less cost than other language based projects.
Compatibility, maintainability, and enterprise level support will be solved by platform vendors who provide services and software 'on top of' javascript ( and its server side cousin node). Platform companies that makes it easier for js developers to introduce javascript projects into their corporate environments should look to these vendors to help them solve these problems. The future may be the best of both worlds.
In full disclosure I worked with Nolan at Appcelerator and I now work for the Node javascript company StrongLoop.com, clearly I'm betting on javascript. There are lots of problems to solve and it will make for some exciting times in the years ahead.
> Big brand names like GM, Yahoo, Dow Jones, Walmart and Dell have all deployed Node.js and are touting its merits.
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.
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.
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.
1) Large resource supply - .NET, Java, etc resources are cheap, quick to deploy and abundant.
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)
3) Supported engine - Enterprise customers pay IBM, HP, MS, etc for support of JVM's, etc in order for the code to run.
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)
Lastly, JS is already an Enterprise language, but mainly for front-end only. So the argument is whether it becomes a back-end language.
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.
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 think the biggest problem with OP's claim is the lack of true enterprise software written in JavaScript. I can't think of anyone, besides a few lightweight SaaS applications.
We're currently building a large-scale application for public schools here in Scandinavia, but it is augmented by a .NET service backend. I hope we'll get a swing at a full-stack solution soon.
All it will take a different scripting runtime (with equivalent performance, which isn't a hard problem) in a major browser and javascript will literally disappear in a half-decade.
A scripting language IS a programming language.
Write code -> some method of compilation -> Computer executes == programming language.