18 ms·

Node v4.0.0

• Cshelton 11y ago
  When I first saw the post about the two combining, never did I imagine it happening this fast. Congrats!
• andrewpe 11y ago
  Exciting to see node moving so quickly
• Killswitch 11y ago
  So excited!
• dcwca 11y ago
  The io.js fork and subsequent merge back into Node.js, including the birth of the Node Foundation, has been one of the best examples of the power of open source I have ever seen in action. The situation went from bad, to worse, to the best possible outcome, and that's remarkable to say the least. Congratulations to everyone involved and thank you for the hard work.
  • vezzy-fnord 11y ago
    The same episode happened with GCC and EGCS in the 90s. It's the power of free software.
    • acveilleux 11y ago
      Oh, I remember having to use kgcc on red hat to build a kernel because egcs couldn't... Recently worked on bits of ancient C++ that still require gcc 2.7 for that very reason. I am so glad that gcc got its house in order. As a bonus the compiler got significantly better in pretty much all the ways it could (at least for users, no idea about internals.)
    • hyperpallium 11y ago
      Wasn't there also one with Rails and Merb?
  • blowski 11y ago
    As somebody who uses Node only at the periphery of my role (for things like the Zombie browser, and SASS parsing) the massive instability has put me off from relying on it for anything core. Documentation is quickly out of date, libraries seem to have incompatibilities which only become obvious when they don't work, there's no 'recommended' approach for even basic tasks. I won't pretend I'm speaking for everyone, as clearly there are lots of people doing great things with Node. However, it doesn't seem to be a language like Ruby or Python where I would feel comfortable using it for a small but important project. I'm always grateful to everyone who works on open source projects, but I wouldn't hold Node up as a great example of the open source community.
    • dcwca 11y ago
      Instability is the very thing this merge and the foundation seek to address. Where there was once an uncertain future, there is now a Board of Directors and a Technical Steering Committee bound by a Open Governance Model. The future has never looked more stable for Node, just take a peek at the names of the companies sitting on the board: https://nodejs.org/en/blog/announcements/foundation-elects-board/ https://nodejs.org/en/blog/announcements/foundation-elects-b...
      • blowski 11y ago
        It promises a stable future, so let's say I'm being cautiously optimistic.
        • grandalf 11y ago
          > It promises a stable future, so let's say I'm being cautiously optimistic. This doesn't make sense in light of your initial comment. One of the big goals of IO was to move to semver and address unpredictability/instability that you describe. If anything, the merging of Node and IO should give you confidence that project governance will be on the right track moving forward. Also, when you consider the advancements in transpiled js, the js/node community is looking very wise compared with other language maintainers.
  • deleted 11y ago
    [deleted]
  • odonnellryan 11y ago
    The more examples I see if open source in action -- that are similar to this one -- the more I start to realize what makes the `free market` special isn't the `market` part at all. These interactions strongly mimic the interactions of the market. What's the true driving force?
  • denzil_holles 11y ago
    Unlike Bitcoin Core / Bitcoin XT / BIP 120392?
• atburrow 11y ago
  This is great news. I'm especially excited about the new ECMA6 features (arrows, etc.)
  • andrewpe 11y ago
    Can't wait to start using ECMA6 natively
  • cosmosgenius 11y ago
    Right before the release they upgraded to the new V8 version 4.5. Having native support for arrow function. So exciting so start using them.
    • jonny_eh 11y ago
      The new class syntax and arrow functions are huge, I'm in love.
  • pfooti 11y ago
    Yeah, this is rad, as I imagine there's some overhead to running the transpiled babel ES6 code compared to running the native ES6 features. At least some things may be faster - I remember lexical block scoping (let and fat arrow) causing perf issues in traceur. Now I just need to be able to rely on these features being present in the browser so I can just write native ES6 everywhere and skip that build step entirely.
    • azernik 11y ago
      Not just performance overhead, but also the overhead of maintaining and configuring the extra bits of toolchain.
    • balupton 11y ago
      We've been using a concept of a "esnextguardian" to be what our package.json main points to, it then tries and loads the es6+ version and if that fails, fallbacks to the compiled es5 version. It's been working quite well for all our different Bevry projects. More info: https://github.com/bevry/base#esnextguardian https://github.com/bevry/base#esnextguardian
• ihsw 11y ago
  Node on Docker Hub needs a new tag. https://hub.docker.com/_/node/ https://hub.docker.com/_/node/
  • cdbattags 11y ago
    Same with Homebrew, por favor.
  • antouank 11y ago
    Get an alpine based one, it has 10x smaller size. I made one with npm v3 and node v4.0.0 https://hub.docker.com/r/antouank/alp-node/ https://hub.docker.com/r/antouank/alp-node/
    • pluma 11y ago
      Thanks to docker's image layering, using a non-Ubuntu image may actually be "bigger" if you already use other Ubuntu images.
• georgerobinson 11y ago
  What happened with the version numbers? I could have sworn Node was on v0.10 just a couple of months back?
  • M2Ys4U 11y ago
    Joyent were incompetent stewards of the node project, so it was forked into "iojs". The iojs project adopted the semantic versioning system, where a new major version number indicates backwards-compatible changes (which mainly happen when they update the version of V8). Eventually Joyent recognised they were on the losing side, and so they agreed to merge back together, under a new foundation which was set up with the help of the Linux Foundation. Node.js v4 is the first release from the newly merged projects and they used v4 as iojs had already made it to v3.
    • lucio 11y ago
      *incompatible
      • dickeytk 11y ago
        that's not what he meant
        • DCoder 11y ago
          > where a new major version number indicates backwards-compatible changes lucio was probably referring to this part, where "incompatible" is indeed correct.
          • progx 11y ago
            lol
      • M2Ys4U 11y ago
        Whoops! That's a bit of a glaring error, sorry about that.
• yulaow 11y ago
  Hoping all the main distros include this release as soon as possible in their main repos.
  • therealmarv 11y ago
    I hope not. Many libs are still not compatible with that.
• jyunderwood 11y ago
  Excited to see this happen so soon. I was expecting it to take a bit longer. I see it's still shipping npm v2. Any news on when npm v3 will be "production-ready" and the default version?
  • M2Ys4U 11y ago
    npm@3 "will be leaving beta very soon!" according to the release notes for 3.3.2.
• bhanu423 11y ago
  Finally a stable release. Thank You Node Foundation.
  • Florin_Andrei 11y ago
    Just curious - what makes it "stable"? We've tried 0.12, then went back to 0.10 for stability reasons.
    • james33 11y ago
      What wasn't stable about 0.12? We've been running it in production since around April or May without any issues.
    • saghul 11y ago
      No software is bug free, but AFAIK Node v4 was very thoroughly tested in a vast array of platforms and configurations, which provides certain degree of certainty, when talking about stability. At any rate, if you ran into issues with 0.12, the best you can do is give 4.0 a go and report issues!
      • actualprogram 11y ago
        If you're concerned with stability, the best thing you can do is wait for the LTS release to come off the 4 branch. A quick glance at outstanding issues will show a number of integration bugs are still outstanding, and the new v8 was landed only a few days previously - incompatibilities with new versions of v8 can take a while to surface in node. It's important to remember that semver makes no promises about stability. While we're used to "N.0" meaning "stable and ready for upgrade," that's a non-semver idea that is explicitly disregarded in the semver release model. Node moving from 3.* to 4.0.0 only indicates that there are breaking changes(1). If you have concerns about stability, you should take signals on that from the node LTS group, and pick LTS releases. 1 - whether or not this is good, bad, or merely a different permutation of the things that are turning your hair grey, I leave as an exercise to the reader.
        • 11y ago
• hamhamed 11y ago
  This is crazy fast shipment..almost scary that you have to start keeping up with all the changes.. For anyone who wants to upgrade either from node 0.12 or iojs 3.30..all you have to do is re-install it with the GUI installer and you're good to go..for your personal computer at least!
  • Aldo_MX 11y ago
    Servers don't use a GUI installer :P
    • andrewpe 11y ago
      Use your package manager to update then...
      • csense 11y ago
        $ cat /etc/issue Ubuntu 14.04.3 LTS \n \l $ apt-cache showpkg nodejs | head Package: nodejs Versions: 0.10.25~dfsg2-2ubuntu1 (/var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_trusty_universe_binary-amd64_Packages) (/var/lib/dpkg/status) My package manager knows nothing of this mythical "bleeding edge" of which you speak...
        • mscdex 11y ago
          Probably your best bet at this point is to use the NodeSource repos to keep up to date with the latest (stable) versions: https://github.com/nodesource/distributions https://github.com/nodesource/distributions
          • michaelsbradley 11y ago
            Or use nvm: https://github.com/creationix/nvm https://github.com/creationix/nvm
    • andresmanz 11y ago
      Some do[0], even if they shouldn't. [0] https://en.m.wikipedia.org/wiki/File:Desktop_on_Windows_Server_2016.png https://en.m.wikipedia.org/wiki/File:Desktop_on_Windows_Serv...
• ErikRogneby 11y ago
  I wonder how fast AWS will adopt it on Lambda?
• maga 11y ago
  Guys, does V8 still deoptimize on ES6 features? For example, would using say const/lets in a function prevent V8 from optimizing it as a whole? That was the case some time ago when these features were still under a flag.
  • deleted 11y ago
    [deleted]
  • deleted 11y ago
    [deleted]
  • BinaryIdiot 11y ago
    I was wondering this myself and I couldn't find a clear answer. If you find out let me know! :)
  • gear54rus 11y ago
    Can I ask for a link on that? Thanks!
    • maga 11y ago
      The one readily available on search: https://github.com/petkaantonov/bluebird/wiki/Optimization-killers#2-unsupported-syntax https://github.com/petkaantonov/bluebird/wiki/Optimization-k... Otherwise the fact that engines bailout on optimizing ES6 features was kind of common knowledge when engines started to implement them.
  • natorion 11y ago
    const/let in particular does not prevent optimization. You just need to use "use strict" in order to use them.
• deleted 11y ago
  [deleted]
• AndyKelley 11y ago
  Alright, now everybody stare at ffmpeg and libav!
  • stingraycharles 11y ago
    Don't forget about bitcoin core and bitcoin-xt! People are screaming bloody murder about that, it will be very, very interesting to see how it plays out.
    • sam_goody 11y ago
      There are many ways a large fork can go in an open source project. A great description of the io.js/node split is: https://news.ycombinator.com/item?id=8884874 https://news.ycombinator.com/item?id=8884874 "Lets hope the spork gets spooned so that no projects get knifed. If not then I guess we have to hope for a knork so we don't get stuck with a couple of chopsticks."
• msoad 11y ago
  When node supports `import` how you'll import node modules? I hope it works like this import {readFile} from 'fs'; import {clone} from 'lodash'; rather than explicitly providing "correct" URL to the modules. EDIT: edited the syntax.
  • codecurve 11y ago
    You'll be able to achieve that behaviour when node also supports destructuring. import { readFile, writeFile } from 'fs'; import { clone } from 'lodash';
    • msoad 11y ago
      oops I forgot the braces! ok then, it's cool. I'm happy it does resolving to node_modules and all that automatically.
      • pluma 11y ago
        It's just syntactic sugar for `require`, mostly. The import mechanism should behave the same.
    • loganfsmyth 11y ago
      Just a nit, but that isn't destructuring. Named import syntax has several differences, since name aliasing uses a different format and you cannot nest or provide default values.
    • WalterSear 11y ago
      As I understand it, that still involves importing the whole file, rather than just the part you need. If that is an issue, lodash is parted out by method, so you can do this instead: import clone from 'lodash/lang/clone'
    • awalGarg 11y ago
      Not really. The destructuring syntax used in the imports is not the same as the standard array and object destructuring. Section 15.2.1.16 of the current stable ES6 specification specifies how the import syntax is resolved, and it doesn't use destructuring. P.S. Sorry too lazy to get a clickable link from the spec :P see http://awal.js.org/especser/#15.2.1.16 http://awal.js.org/especser/#15.2.1.16 if you really wanna read it
• techman9 11y ago
  Does anyone have a good source of information about the major changes between Node and IO? I haven't kept up with the community recently and I'm curious as to what the delta really is and what merging IO back into Node will mean practically.
  • steveklabnik 11y ago
    The largest is a pretty big update to V8, it was one of the biggest features of iojs.
  • speg 11y ago
    https://github.com/nodejs/node/blob/master/CHANGELOG.md https://github.com/nodejs/node/blob/master/CHANGELOG.md
• snickmy 11y ago
  0.12.7 -> 4.0.0 Best versioning convention ever :)
  • Aldo_MX 11y ago
    just follow the timeline of io.js
  • abritinthebay 11y ago
    Actually it went: 0.12.7 -> 1.0.0 -> 1.0.1 -> 1.0.2 -> 1.0.3 -> 1.0.4 -> 1.1.0 -> 1.2.0 -> 1.3.0 -> 1.4.1 -> 1.4.2 -> 1.4.3 -> 1.5.0 -> 1.5.1 -> 1.6.0 -> 1.6.1 -> 1.6.2 -> 1.6.3 -> 1.6.4 -> 1.7.1 -> 1.8.1 -> 1.8.2 -> 1.8.3 -> 1.8.4 -> 2.0.0 -> 2.0.1 -> 2.0.2 -> 2.1.0 -> 2.2.0 -> 2.2.1 -> 2.3.0 -> 2.3.1 -> 2.3.2 -> 2.3.3 -> 2.3.4 -> 2.4.0 -> 2.5.0 -> 3.0.0 -> 3.1.0 -> 3.2.0 -> 3.3.0 -> 4.0.0 You just weren't paying attention.
    • ultrafez 11y ago
      If you include io.js, sure. Node did technically jump considerably.
  • pluma 11y ago
    Technically Node 4 is io.js 4 after Node 0.12 was merged into io.js 3. So it's really 0.11.x -> 1.x -> 2.x -> 3.x -> 4.0.0. Except that 1.x, 2.x and 3.x weren't called "Node" at the time because Joyent owns the trademark and went on to release their own 0.x release(s) until the merge happened.
• jjcm 11y ago
  "In parallel, we will be branching a new Stable line of releases every 6 months, one in October and one in April each year." Nice, they're syncing up with the ubuntu release cycle. Should make updating servers a bit easier.
  • daredevildave 11y ago
    Presumably, this means Ubuntu will always be one release behind...
• jtwebman 11y ago
  I might stay on 0.12.7 for a few months to let everyone work out the issues first.
  • Twirrim 11y ago
    That's probably the smart approach, in general, other people make awesome guinea pigs.
• aarestad 11y ago
  So, why is the link 404ing right now?...
• ausjke 11y ago
  the iojs site mentioned nothing about the merge as I checked yesterday, neither does nodejs site, which is a bit odd. the new version number is using iojs instead of nodejs's existing version scheme, which is interesting too. I just began a php device-configuration-management project and was strongly persuaded by a senior php developer that I should use nodejs instead, as he thinks nodejs _is_ the future and many big guns are using it for real deployment(netflix, linkedin,paypal...), just in time to try the fresh nodejs release for the new project.
  • dragonwriter 11y ago
    > the new version number is using iojs instead of nodejs's existing version scheme, which is interesting too. Well, its a follow-on to both pre-merge iojs and pre-merge nodejs, and has breaking changes to both, so the most SEMVER consistent version number is the first major version greater than the greater of pre-merge iojs's last version number and pre-merge node's last version number -- which is exactly what they chose.
• platz 11y ago
  so now which apt repository to I use for node going forward?
  • mattkrea 11y ago
    Don't. I don't think Chris Lea is updating his anymore. Wget the tarball and tar -C /usr/local --strip-components 1 -xvf <tarball>
    • STRML 11y ago
      Not so, Chris Lea's PPAs are now part of Nodesource: https://github.com/nodesource/distributions/#installation-instructions https://github.com/nodesource/distributions/#installation-in...
      • mattkrea 11y ago
        Oh wow! Didn't know about this. Awesome.
• cpeterso 11y ago
  Here is a timeline diagram showing how the LTS and Stable branches will work: https://nodesource.com/assets/blog/essential-steps-lts/nodejs_lts_schedule.png https://nodesource.com/assets/blog/essential-steps-lts/nodej... From this NodeSource post: https://nodesource.com/blog/essential-steps-long-term-support-for-nodejs https://nodesource.com/blog/essential-steps-long-term-suppor...
• smaili 11y ago
  This marks a big day for Node - one which I and many others have been patiently waiting for, and one which still hasn't quite hit me yet :) Big thanks to all those who made this possible!!
• mark_l_watson 11y ago
  ES6 support is nice, especially if there is no performance hits for using ES6 features. I slightly prefer Typescript, but the extra language features in ES6 really make JavaScript development more fun for me. Thanks to the newly re-combined Node team!
  • tomphoolery 11y ago
    Good news for you: ES2016 will support optional type annotations, clearly inspired by TypeScript. The idea is we shouldn't need a damn transpiler just to get the features most people want out of a language...
    • Ciantic 11y ago
      Interesting, can you give a link? I tried to find it, it's not here https://github.com/tc39/ecma262 https://github.com/tc39/ecma262 Only mention is "Typed objects" but that is not TS-like annotation.
    • pluma 11y ago
      SoundScript is on track then? I thought it was just proposed (i.e. highly experimental).
• atomi 11y ago
  > ARMv6 32-bit Binary: Coming soon Is there more information on what's holding back this build?
  • nathankunicki 11y ago
    The fact that the little Raspberry Pi building it is still...well, building it! :) https://ci.nodejs.org/job/iojs+release/168/nodes=pi1-raspbian-wheezy/console https://ci.nodejs.org/job/iojs+release/168/nodes=pi1-raspbia... It does look like it's very nearly done though, given that it's tar'ing stuff up at the moment. The decision was made not to wait for it here - https://github.com/nodejs/node/issues/2522 https://github.com/nodejs/node/issues/2522
    • orik 11y ago
      just finished building :)
    • rylee 11y ago
      Should have used a high-powered Scaleway server as advertised on HN a few days ago :-P
• netcraft 11y ago
  The arm support is great too. Great work from everyone involved, io.js was short lived but will have a lasting impact for the better.
• haberman 11y ago
  Anyone know when Node will get IndexedDB?
  • redidas 11y ago
    That's likely out of scope for node.js. I'd recommend checking out leveldb: https://www.npmjs.com/package/level https://www.npmjs.com/package/level
    • haberman 11y ago
      Why out of scope? It's a DB api that has no browser/ui dependencies. I see that the levelDB implementation you pointed to can use a backend that uses IndexedDB. So theoretically this levelDB Api could provide an Api that work across both browser and server. But argh. IndexedDB is a standardized api. It has a usable open source implementation in WebKit. Why not just go with that?? Why create a different API that does the same thing? I've been building an entire app around IndexedDB, but now I have to port it to a different Api to run on a server? Why?
      • secoif 11y ago
        If you'd used leveldb from the beginning you wouldn't have this problem as it will happily work on the server and in the browser https://www.npmjs.com/package/level-js https://www.npmjs.com/package/level-js
        • haberman 11y ago
          Yes I see that. But if IndexedDB were supported on Node I also would not have this problem. So the question is, why can't node just support IndexedDB (which is formally specified in a standards document) instead of inventing an extremely similar but incompatible api?
          • pluma 11y ago
            Because IndexedDB is a W3C spec[0] intended for web browsers and LevelDB is a third-party npm module[1]. Node is just a JS environment. Implementing IndexedDB is as much out of scope as implementing XHR[2] or the File API[3]. In fact it provides the building blocks developers to implement any of these on top of Node should they need to (like node-fetch[4] implementing the Fetch API[5] for isomorphic apps). [0]: http://www.w3.org/TR/IndexedDB/ http://www.w3.org/TR/IndexedDB/ [1]: http://leveldb.org/ http://leveldb.org/ [2]: https://xhr.spec.whatwg.org/ https://xhr.spec.whatwg.org/ [3]: http://www.w3.org/TR/FileAPI/ http://www.w3.org/TR/FileAPI/ [4]: https://www.npmjs.com/package/node-fetch https://www.npmjs.com/package/node-fetch [5]: https://fetch.spec.whatwg.org/ https://fetch.spec.whatwg.org/
• deleted 11y ago
  [deleted]
• kylehotchkiss 11y ago
  yay
• mark_sz 11y ago
  I remember when many people were complaining about PHP - lack of progress, inconsistency etc. Now look what's happened to Node just in 6 years. And this is just the beginning.
  • pluma 11y ago
    I have no idea what you're trying to say. PHP stalled in pre-6.0 land and then jumped straight to 7.0 because the release was just not going to happen. The closest thing in Node I can think of is ES4 (which failed, resulting in a jump to 5 and ActionScript diverging further). Node stalled in pre-1.0 land with what was effectively a feature freeze before io.js split off and jumped to 1.0. Io then went on a regular release schedule strictly following semver leading to 2.0 and then 3.0. These aren't backwards incompatible in the sense that PHP 5 is to 4 or Python 3 is to 2 -- most code will likely still work; they mostly propagated breaking changes caused by updates to the underlying V8 engine, breaking some native extensions. The "jump" from 0.12 to 4.0 for Node is because instead of merging io.js back into Node, Node 0.12 was merged into io.js and io.js became the new Node 4.
• intrasight 11y ago
  All I can say is that after reading this thread, I'm glad that I'm not a Node developer.
  • _fizz_buzz_ 11y ago
    You are missing out. Node is dope!