I've been a Javascript and Node skeptic for years now but I think the tide is finally turning. So much time and energy has been poured into making JS better that it's finally starting to pay off. Javascript with all the ES6 enhancements is really not a bad language. The runtime performance is already very good and continually getting better. Tools like Typescript and Flow make dealing with larger code bases much easier.
I don't think the other "scripting" languages like Ruby, Python, and PHP stand much of a chance against it in the longer term. They just don't have the resources to compete.
> The runtime performance is already very good and continually getting better
Have you checked out the Computer Benchmarks Game? Here are some benchmarks they provide, comparing the JavaScript V8 to Python [1], Ruby [2], and PHP [3].
Looking at statistics such as these, I'm left thinking, "1. This is awesome! 2. Is there something about these other languages that prevents V8-like performance, or is this more a matter of browser performance being highly invested in by Google, Mozilla, etc.?"
V8 does precompilation to native code and JIT optimization, which can typically turn numerical computations into efficient, and often highly optimized, machine code. These benchmarks seem to primarily be testing algorithms which require a lot of numerical computation and can take advantage of Javascript's typed arrays, which V8 is designed specifically to optimize.
A somewhat more fair comparison would be V8 vs. PyPy, Rubinius/RuJIT, HHVM, and LuaJIT. LuaJIT and V8 would likely still come out on top due to the amount of work and sheer excellent engineering put into the compilers (and in LuaJIT's case, also the interpreter), but PyPy's performance should be a lot better than CPython's for these benchmarks.
I also imagine (though am mostly speculating) that a benchmark involving a full-stack frontend framework like Angular or Ember, with hundreds or thousands of JS objects and lots of DOM manipulation, should put V8's performance a bit closer to CPython's.
I don't think more code will be a big problem for javascript. It seems to mostly affect start up time. Look at the asm.js tests with Massive. Also think about all js projects that use anywhere from 10 000 lince of code (LOC) to 100 000 LOC. I haven't heard anyone saying that the runtime got into any problem. There is always some problems with organizing that amount of code but that is true in almost any language. And javascript is actually quite effective to write in meaning a js program is probably much shorter than the same program in Java (at least before Java 8).
Well, it would be a different comparison; and I dare say a website showing such a comparison would attract a lot of traffic, if only someone would "please take the program source code and the measurement scripts and publish those measurements."
> I also imagine (though am mostly speculating) that a benchmark involving a full-stack frontend framework like Angular or Ember, with hundreds or thousands of JS objects and lots of DOM manipulation, should put V8's performance a bit closer to CPython
Interesting idea! How would we make a version of the benchmark for CPython though?
You couldn't do the DOM parts, but you could compare Python dicts with Javascript objects, and compare performance when there are a lot of heap allocations and GC calls.
benchmarksgame is not a serious comparison site, it's in the name.
The comparisons they do is not of idiomatic code... for example in python they do a lot of array programming and don't use numpy (http://www.numpy.org/). So for most languages the results in there are completely meaningless.
The name "benchmarks game" signifies nothing more than the fact that programmers contribute programs that compete (but try to remain comparable) for fun not money.
The performance of those programs with CPython explains the existence of numpy, and if you look you'll find that numpy programs are shown.
That's not an objective comparison, since Javascript has been optimized to deal with arrays and numbers, as that's one main use-case that people have in the browser. Take a look at the source code and tell me if that's the kind of code that you write.
No, it's not an objective comparison because that's not the kind of code that we deal with in 90% of the cases, except when doing games, but then again plain Javascript is shitty for doing games, unless you develop in a strict subset that isn't meant for humans.
I disagree. Every time I try to get into node, I am stonewalled by poor debugging support. I end up wading through obtuse stack traces only to find poor quality libraries are the culprit. Tracing dynamic languages is so hard already. The only thing I can tolerate is Python with Werkzeug.
I'm a 70%-90% back-end guy with 10-30% front-end work (when necessary).
As the companies I work(ed) for evolve from JS => jQuery => Backbone.JS => Backbone.JS + Marionette => EmberJS, so does my skill have to evolve. I also have to write some JS code on top of PhantomJS + CasperJS (not for automation testing but instead for performance monitoring) to support enterprise product at the moment.
I used to hate JS with passion but now after seeing Chromebook, Chrome Apps, NodeJS, and my current favorite: MeteorJS. I just have to suck it up and learn JS to be honest...
Would I bet an enterprise app to use NodeJS if it was using my own money? Probably No. Would I bet my weekend projects and ideas on NodeJS/EmberJS/JS? Yes.
I think the JS ecosystem is still unstable and a big mess but let's hope it moves to a better direction.
I will not take the # of NPM vs Java Maven as is. Keep in mind that Java SE (API) is way more complete than NodeJS basic APIs.
Also keep in mind that in Java, most people have 1-2 choices at most and those choices tend to be way more mature and stable so we tend to feel comfortable with those (at most) choices.
You can slice and dice my analysis anyway you want. You can say lack of choices is bad and millions of Java devs will disagree with you. You can say that NodeJS is evolving like mad and thousands of other more experienced Devs that myself would argue that NodeJS ecosystems is playing "see which one sticks". Your values are different than of mine.
StackOverlow stats you posted doesn't mean anything. Literally. We know JS has been around for ages. The fact that JS claim of fame to be smaller/leaner than Java yet rank #2 behind Java humongous ecosystem is a question mark in my mind: "What The Heck?"
It can go either way.
Gulp vs Grunt, NPM and Bower. Java has Maven. One tool. Yes, there are Ant and Gradle but let's be honest, Maven is king whether you like it or not. With Java, I declare the archetype (web-app or simple app) and dependencies and away I go (unit-test is part of the build, integration-test requires a few additional lines).
With JS, I have to .. ? Let me know if it's simpler than Maven. Let's not waste time to argue about XML vs JSON or whatnot, that's a matter of taste, let's focus on the required steps to build, run tests, and package it up whether as a deployable or a dependency of others.
'Most modern' ecosystem? That's likely, though it's honestly got the same things as every other programming ecosystem. I think the Perl ecosystem might be the most 'complete' programming ecosystem that exists today, in terms of implementing modern aspects of a programming ecosystem.
'Most stable' ecosystem? How do you figure that? It's only been around a short while in its current form. Other languages have had their current ecosystems hanging around for decades.
'Most evolved' ecosystem? Technically a single server-side javascript have existed since 1994, but other than JScript on ASP and Lotus Notes xPages (lol), nobody really used it again for non-frontend work until Node came around in 2009. AFAIK, jQuery was really the beginning of the 'modern' Javascript age back in 2006, and has slowly been adopting the practices of other programming ecosystems since. I would wager V8 was the biggest boost to JS development in the past 10 years, as it finally stopped being the slowest interpreted/scripting language in the world. Is there even a CPAN equivalent for JavaScript yet? It seems they've only implemented an equivalent of PAUSE or PPM.
Anyway, it's obviously getting better, but it's still pretty young.
I'm not as familiar with CPAN, but how is NPM significantly different?
As someone who used JS server-side from Netscape Livewire, to ASP JScript and even via Synchronet, and other JS runtimes... I've always appreciated the core language. Long before "The Good Parts" because Crockford only got a lot of coverage for what I already knew. Same goes for some recent adjustments regarding Object.create (and even inheritance chains in general).
JS at it's core is a decent language. ES5/ES6 enhancements make it very usable. Currently developing against Node 0.11.x --harmony, with a an es6ify for browser support. Given Node's very good async i/o interfaces, I've written a lot of bridges the past few years between systems that have trouble communicating directly.
Namely SOAP providers are a pain to consume in general a lot of the time. Not a problem to create a JSON endpoint in node that runs it fine. Need to process a huge XML or CSV file... Node is actually pretty nice... and can generally ship the final data where you need it.
Node is imho the ultimate service middle-ware... And to me, this extends to being the servers/services that web applications talk to... relaying to other backend systems/databases.
'Most stable' in the sense that both NPM and Bower are quite reliable.
'That's likely, though it's honestly got the same things as every other programming ecosystem'
I disagree on this point because dependency systems like Gems (for Ruby) and PIP (for Python) are miles behind NPM and Bower.
I'm also not aware of popular task runners on other programming languages in the same way Grunt or Gulp are.
Perl isn't a language I know well so I can't argue on that.
By 'Most evolved' I didn't mean Node.js but really the NPM / Bower module ecosystem. You rarely if ever have to write something from scratch due tu a lack of plugins.
I agree with you thought that thanks to V8, JavaScript has a performance level that is close to compiled, lower level code.
> I'm not sure why you consider the JavaScript ecosystem unstable ?
Well I'd say his opening might be the reason:
"As the companies I work(ed) for evolve from JS => jQuery => Backbone.JS => Backbone.JS + Marionette => EmberJS, so does my skill have to evolve."
It's evolving fast, and this makes it unstable in terms of knowledge and what's being used. Depending on outlook (or age?) this can make it exciting. It's also a pain in the proverbials to keep up with, and everyone's at different places (while the HN crowd appears to have moved onto Gulp, many people I know are just discovering & starting to use Grunt).
Thousands of plugin says nothing about whether it's a stable ecosystem either: the majority could all be high quality, or they could be scratch-an-itch-and-move-on projects.
Even though the frameworks evolve quickly in JavaScript, nobody is stopping you with sticking to an "older" one if it works for your project.
It's true though that your value as a developer shifts quite fast depending on the trends. But I feel that a fast moving world is merely a consequence of super large communities like the JavaScript one.
By "stability" I meant that NPM and Bower are quite reliable.
Also, if you look at the usage stats for the top plugins, the still show in my opinion stability since you have a lot of devs contributing through pull requests.
I asked myself the same question and although I'm not sure what the answer is, my guess would be that the situation you describe would be valid for any (relatively) new programming language.
It shouldn't be particular to JavaScript or Node.js.
What annoys me in the Javascript world in those "and", there is always an "and" with many commas before, to many options, when you suffer from big choice paralysis like me you lose a lot of time setting your stack and being productive.
I switched from WPF, C# dev to Angular JS with Typescript and Web API with relative ease and I'm digging it. Typescript definitely helped though. I know I have plenty more to learn, but it's not as shitty as people make it out to be.
If you're using Web API (built on ASP.NET) then you're not using Node, which is a Web server written in Javascript.
But I do think it's cool that someone can transition from WPF to Web development with Angular without feeling too lost. Dynamic Web development used to be a very, very different ballgame from client application development.
I don't see why Ruby, Python or PHP can't compete, if Dart, TypeScript, Coffeescript, JSX, Elm, purescript, ClojureScript, etc. can all still be things.
"Javascript with all the ES6 enhancements is really not a bad language."
File under "damning with faint praise", methinks. Not sure what it means if the "not all that bad" version is one that doesn't run natively anywhere yet...
I think in this instance JavaScript has to compete with Java, C#, go, erlang, etc. rather than the other "scripting" languages. I don't think many would argue JavaScript isn't comfortably #1 within that domain.
I'm genuinely curious why you think JavaScript is comfortably #1 within the domain of Python, Ruby and PHP. I've been writing (client side) JavaScript for a very long time, and I generally enjoy it, but I don't see myself abandoning Python on the server side for JavaScript anytime soon.
But is that because you like Python, have a large code base that takes time to convert, is missing some tools, don't think javascript is mature enough or something else?
I use C# myself and would not like to convert our whole app to js but I could be ok with Dart or TypeScript instead (or Go but that is not a scripting language).
I didn't argue JavaScript is #1 on the server side, simply that it's the language with the most traction when it comes to that group of languages (of which Python is no part by the way, PHP and Ruby are though). I wouldn't touch JavaScript on the server side with a 10 feet pole.
I don't think the other "scripting" languages like Ruby, Python, and PHP stand much of a chance against it in the longer term. They just don't have the resources to compete.