10 ms·
Node.js v7.0.0
- emilong 10y agoAnyone have a good summary of the language feature changes & APIs (either standards or standards track) that are in the version of V8 that ships with Node 7 vs Node 6?
- jefozabuss 10y agoFrom what I read in slack: Do not use async/await yet (with --harmony-async-await flag) because it has memory leaks (V8 5.5 will fix it when it gets added)
- ilkkao 10y agoIs it known how easy it is to trigger the memory leak?
- PacoLoco 10y agoVictor & Marlen
- subie 10y agoI came across this just the other day.. https://github.com/MatAtBread/fast-async https://github.com/MatAtBread/fast-async
- TheRealPomax 10y agoAs a not-elligible-for-LTS version, it's probably fine - you're not going to be using Node 7 in production anyway, as it's only ever a cutting-edge release, unless you don't care about stability in which case memleaks are part and parcel.
- jbergstroem 10y agoExpect a blog post shortly, but from v8 we get these language changes: - await/async behind flag (already covered in thread) - Exponentiation operator: > console.log(60**2*24); 86400 - Object.{values,entries}: > o = { a: 1, b: 2} > Object.values(o); [ 1, 2 ] - Object.getOwnPropertyDescriptor(s): > o = { a: 1 } > Object.getOwnPropertyDescriptors(o); { a: { value: 1, writable: true, enumerable: true, configurable: true } } Additionally, there's a lot of pretty impressive optimization work done by the v8 team. You can read more about that on their blog: http://v8project.blogspot.com http://v8project.blogspot.com Finally, one of my favorite things about Node.js 7.0 is the WhatWG http parser: https://github.com/nodejs/node/pull/7448 https://github.com/nodejs/node/pull/7448. edit: elaborated on exponentiation operator
- paulirish 10y agohttp://node.green http://node.green tackles this pretty well.
- Macha 10y agograceful-fs v3.0 is dead. This can bite you if you haven't updated gulp, less, npm, bower or similar in a while
- gedy 10y agoI realize this follows semver, but bumping major releases without major changes is... not as fun? as the 'old days' where major versions of software meant something less incremental :-) Kind of wish there was yet another number prefix to semver to signify this.
- jasnell 10y agoThere are a number of semver-major changes included in v7. That said, the goal for this release has been improved stability and performance over new features so the jump from v6 to v7 is fairly small.
- andrewstuart2 10y agoI think gedy meant that it used to be that "v7.0 released!" meant that one could expect exciting, fun features to be present, and that the new version is worth taking a look at, and playing with. With semver, it seems like a lot of "new features" are typically released in minor versions, since quite often they don't need to break compatibility in order to introduce features. So major versions are, to me, almost more of a cause for concern these days. My first thought is typically "Oh no, what part of my stack is going to break now? How much time will I spend tracking down the fix?"
- nothrabannosir 10y agoSo major versions are, to me, almost more of a cause for concern these days. My first thought is typically "Oh no, what part of my stack is going to break now? How much time will I spend tracking down the fix?" Isn't that exactly the point of semver? And, assuming things will break at some point,* isn't that great? Now you know when to expect it. Semver doesn't influence design decisions of a project's lifetime. It describes them. * fair assumption, unless you're dealing with software which literally never breaks backwards compatibility.
- andrewstuart2 10y agoYeah, that's definitely the point of SemVer. The only point I'm (and presumably gedy is) making is that a major version no longer feels like Christmas morning, but rather akin to "see me in my office tomorrow morning." Okay, not quite that bad, but in the same vein. SemVer is great and helpful and I wouldn't choose anything else currently, but it also lacks the builtin PR that old-school major versions seemed to have, where major version bumps usually meant you could get excited about exploring new major features. There's nothing special about a minor SemVer bump that says "new major features have been introduced." The spec only asserts that minor means new features. That is, there's no obvious way to know that 1.1 introduced only one new method for checking status, while 1.2 introduced a new magic() method that finishes your work for you and makes all your dreams come true. :-P
- PacoLoco 10y agoVictor <3 Marlen
- XaspR8d 10y agoThis just makes me realize that it's gonna be really confusing when Node.js V8 is released! Joking aside, I wonder if there are any internal plans on keeping terminology clear for the next version?
- BurningFrog 10y agoMight as well "do a Windows" and skip to V9.
- terink 10y agonode releases should ship with yarn instead of npm. Yarn is better all around - faster, deterministic, local caching, offline mode, better licensing terms.
- mattnewton 10y agoNot everyone is down to switch such a core piece of the infrastructure at the first sign of new and shiny. I think yarn will succeed, but so did lots of people about bower, ied, duo, etc. Give it a moment to settle. The path forward might even be a merger instead of replacement.
- terink 10y agonode developers have overwhelmingly indicated that they want to switch to yarn and are willing to work through the short term problems until it becomes stable. npm wouldn't be a suitable caretaker for yarn.
- franciscop 10y agoI am sorry, but what? What is your source? From a new account[1] with only 3 comments overwhelmingly favoring yarn over npm it's difficult to trust this as it just seems like SPAM. I have been developing in Node over 3 years and trying new things constantly and no, I'm not really excited about yarn. Nor many Node developers I know. [1] https://news.ycombinator.com/threads?id=terink https://news.ycombinator.com/threads?id=terink
- terink 10y agoMost devs on Github disagree with you: https://github.com/yarnpkg/yarn https://github.com/yarnpkg/yarn - 17,271 stars https://github.com/npm/npm https://github.com/npm/npm - 10,807 stars
- franciscop 10y agoAh I see, Github stars. I am not sure they are a good indication though; many people (HN effect?) star something new and fancy when it comes out, while I think NPM can be considered to have "grown" organically with Node.js; which in my experience doesn't attract as many stars at all. When NPM came out the Node community was still in its infancy, with not so many people in the ecosystem. I haven't even starred NPM while I almost starred Yarn the other day.
- bit_logic 10y agoThe JavaScript language has improved a lot since node.js was released (Promises and soon async/await). However, at this point NPM has a lot of libraries written in the old callback style and it seems even new libraries are still doing this. There are libraries like bluebird and Q which can "promisify" a callback style library, but I think using these is a bad practice. It's something that works most of the time, but sometimes breaks when the callback code isn't what the promisify function expected. Also, the library writers are not writing the code with any guarantees that promisify will always work. So even if it works now, it could break in the future. The whole promisify is a good example of general node.js culture. It's considered "good enough" and everyone just uses it. However, anyone who has done software development in more solid languages would feel very uneasy using something like this. It's not really the fault of the JS developers, the dynamic nature of the language offers no other choice. For example, when Java added lambdas, since it has static typing it could consider a certain type of class (a single method class) as automatically a lambda. This allowed full backwards compatibility with any old library that conformed to this (and many libraries such as Guava did use single method class as a kind of "ugly" lambda). node.js has a convention for callbacks (function(err, result)), but unfortunately it's only a convention and there's no compiler to enforce it. So automatic promisification is not possible. That leads to the current situation. There's all these new language features in JS, but everyone is still sticking to the "lowest common denominator" of callbacks. There's no path forward for existing libraries. The only way is a complete rewrite of libraries using the new Promise/async/await style.
- mpfundstein 10y agoWhile - in general - you are quite right, most of the bigger libraries that I use in production offer interfaces for both styles. Mongoose for instance. You can easily use it with Promises or with the old-school callback style. Same for unit test libraries. And this trend will only continue. There is a lot of cool research being done in combining JS with hardcore FP (fantasy-land, ramda) and this will of course influence future developments. Not to forget the FRP community around React/Bacon etc... I predict that in a year or two, the majority of devs will use Promises as if they always have been there.... And hey. Promises are Monads [1], so maybe we will also soon see a lot of Eithers and Maybes in Production code. I taught today a lecture about this at my company, and people with no prior exposure to FP immediately loved it. Thats also one cool thing of the js/node community. We just adopt stuff and try it out. With microservices, this also poses no problem. If it doesn't work, do it differently in the next service. [1] I know, I know. A+ Promises are violating some laws BUT the general idea holds. And there are full monadic promise libraries like Data.Task or Fluture available.
- EugeneOZ 10y agoDedicated blog post: https://nodejs.org/en/blog/release/v7.0.0/ https://nodejs.org/en/blog/release/v7.0.0/