I may be out of the loop here, but wasn't the big benefit of JavaScript everywhere that it's the same JavaScript everywhere?
Does it matter if server-side is JavaScript Next Gen and browsers lag by a few years of features?
Too many more iterations of this and you'll be back to two programming languages again and web developers heads will explode from having to learn two things instead of one things.
It's been "the same javascript everywhere" mostly due to the ECMAScript group kinda stalling for the past 15 years. The stabilisation created through that has been useful, but the plan is to transition the spec onto a one-year update cycle.
That means that going forward we'll likely have more feature mismatch between engines, making backward compatibility compilers pretty important.
Chrome (logically) already supports features of the new JS spec that 'only now' get put into node.
With automatic updates for browser being the trend currently I also think that it is now easier to keep the server and browser support for JS in sync.
Not necessarily. I don't think the v8 team really consider the Node project so breaking changes in v8 take some time to get merged into Node/io.js. This is the reason that arrow functions are only shipping now when v8 marked them complete a while back. AFAIK Node is somewhere around 3+ months behind Chrome.
V8 has had arrow functions for a long time, but until recently they were not fully spec compliant. That is also why iojs put them behind a flag (separate from the flag that enabled stable harmony features).
Yeah, 'ship' means different things in different contexts. In the context of your original comment, node stable is getting arrow functions within a week of Chrome stable getting them.
In general, io.js has been very good at picking up stable V8 soon after it ships in Chrome. The exception was V8 4.3, which was not picked up because of API compatibility issues.
This is not a problem for Chrome because chrome doesn't expose the V8 C++ API to large body of third party module writers like Node does. It takes time to deal with some API changes.
node.js got forked into io.js. io.js made a lot of improvements and changes, while trying to reconcile the fork and the reasons why it occurred. those have been reconciled.
io.js had many contributors and changes, starting at 1.0, they are now on 3.0. 4.0 is the full reconciliation with node.js, as part of the linux foundation.
It's also useful to note that io.js moved fasted in version numbering because they switched to a more semver versioning pattern, whereas Node had been using something a lot more awkward and rather more confusing. It looks like a benefit to the 4.0 jump is that Node will be using semver moving forward.
FYI this isn't holding up release ("A .bat file is holding up the whole thing!"—hackernews), it should be completed by recent commits to core, I'm leaving this open as a reminder to confirm that it's working as expected in the 4.0 RC builds.
So excited this is finally happening. I enjoy every bit of node I get to write, really excited for the updated features. Babel has taken a lot of the edge off, but I dont want to pull babel in for every script.
I'm curious, what is your development background, and what do you enjoy most about Node.js?
I come from a Java background, but have been working exclusively with Node.js for the last eight months. Everything I write, I can't help thinking things like "this problem has already been solved in Java many times over", and "this would be safer in a statically typed language", and "this would be faster to write in anything else" (though this is more a reflection on my choice of libs).
With TypeScript [1] you can get the best of both worlds: statically checked code with tool-assisted refactoring plus the ability to drop down to JS when the type system doesn't support what you want to do. (Of course, you'll now need to be careful about it and try to isolate the dynamic code from the rest of the system and present a static facade to it)
I've thought that if you're going to go the route of compiling to JS, you might as well go to a higher level of abstraction and use something like PureScript, Haxe, or any of the 100 other languages that compile to JS. Of course, interop then becomes a problem.
Thats precisely why I suggest TypeScript or Facebook's flow, as interop is a non-issue. They're both just ES6 + optional types.
The trouble with PureScript is that its different enough to have a different cost model (in terms of performance) thanks to the pervasive closure allocations resulting from currying as well as the typeclass dictionaries. Though I'm sure that once the compiler matures and those costs are eliminated, it would be the best choice.
There is also TypeScript's tooling - while the language is less safe, the language service tools are a lot more advanced than PureScript's (I can't say if the same applies for Haxe though)
Mostly dynamic languages. I really like statically typed languages for certain tasks, but many times a dynamic language that gets out of your way can be quite liberating. It takes a lot of trust compared to a language where your compiler is what you trust - and occasionally you spend a bit of extra time tracking down why things are in a state other than what you expect, but on the whole it takes the time from this is what I need to this is what I have down considerably.
However, if you have good test coverage then you can test for that stuff and get a similar experience. For example, if a test break then you know your variable is not a number anymore when you need it to be.
Manually writing tests for things which the compiler automatically picks up is not my idea of 'a similar experience'. Background: ruby and is dev who is now learning Scala and loving having type safety
Am I doing something wrong? I find NPM very slow and buggy compared to maven which just works for me. It could be that I'm on Windows or just more familiar with Maven. Use an internal nexus for both proxying NPM and maven.
