Just make sure to update your package.json to take a hard dependency on Node 6+ if you do that:
{ "engines" : { "node" : ">=6.0.0" } }
This will make it so that ES6-compat is assumed and TS won't transpile ES6 functionality, but it will use commonjs for modules, which means your TS will almost be a 1:1 mapping with the compiled JS and everything should just work.
Personal pet peeve: Please don't set the node engine field in npm packages. It potentially breaks your package whenever there's a new release candidate because `node@7.0.0-rc.1` is less than (!) `node@6.0.0` when it comes to npm's handling of this field.
Sooo that's like, an npm design flaw then? If you don't specify the engine field, someone using an older version of node will just get incorrect failures and think your package is broken. I'd rather specify the engine and give a clear error to all users on a version of Node.js older than 1 day than to make it work for users on Node RCs. Although it would be nice if npm made it possible to support both sets of users.
What does this type of condescending bile add to the discussion? Thousands of companies successfully use PHP and node to write excellent software every day. If you despise node so fervently, why are you even engaging in a thread about the latest node release?
Personally, I prefer ruby whenever its an option, but I've worked with node in the past and it's a decent platform that worked very well for the company (a commercial app servicing about 840k api and page requests per month).
So negative opinions about '*' should never be expressed?
JavaScript is a terrible language, and imho es2015 fixes a lot of broken stuff in the only backwards-compatible way it can. That said, I find the entire micropackage culture around npm and node, coupled with the hundreds of packages that typically constitute build scripts for even a smallish node project make me realize just how brittle it is compared to competing platforms.
"Negative opinions" are fine. Heaping on condescending substance-free exclamations of ridicule in the middle of a thread about a specific issue regarding a platform you don't even use is just toxic arrogance.
Your "micropackage" complaint is daft; if you don't like small modules don't use them. Why is the language to blame for free, open-source code that you don't have to use? How is this even a legitimate complaint? You don't need hundreds of packages for anything and you can find examples of this in any language.
There's a difference between being negative with specific complaints versus hyperbolic, drive-by FUD.
Regarding your own complaints with Node. You're over-generalising. Nobody says you must use small modules. Larger libraries and frameworks exist. Same goes for build scripts. Also read this to get more context on small modules: https://github.com/sindresorhus/ama/issues/10
What language/eco-system isn't horrible, honestly? In some way? What's your "ideal" stack?
Professional, I have used or am using C/C++, Python, Ruby, Javascript, some Java, some C#, Golang.
Our of all of those the only one I don't really hate is Golang. In every other language/eco-system I can point to at least a dozen things that are awful. In Golang - maybe only 9.
Node has NPM with a huge eco-system. It's fast. Javascript, if written correctly, can be a pleasure to use, IMO. And even if you can't use it idiomatically for some reason, you can use Cofeescript/Typescript or whatever that forces some sort of code structure/discipline.
Node itself is decent if you understand how to ignore callback-pyramid-of-death with Promises and reactive-type programming.
Not all suck, at least not as much as the one in the discussion...
I have used most of those you listed, and some esoteric/legacy/proprietary stuff.
To me, with all its flaws, C#, Java, Scala, Python were the best, with goodness decreasing.
I need to try F# as I feel I'd like it very much. Generally I believe in static type systems with proper generics support catching a lot of bugs up front, and are a pleasure to use, as my personal experience also shows this. You may not have enough experience with Java, or especially with C#, and I suspect that you may even find some of the greatest features there mere annoyances.
After being an experienced C programmer and having same JS experience I can say JS has the much same problems. Bad design decisions initially. Then sticking to the legacy. Lack of expressive power.
Writing correct code in JS or C is a struggle. For some reason both are overrepresented here on HN.
Lack of proper module module system makes JS inferior to most modern languages (C#, Go, Rust,...). (npm solves some of it), and it could be continued for pages, but for a believer/zealot it wouldn't matter.
Strongly recommend you get used to it. JavaScript is the universal language of the future. What can be written in JS will be written in JS. This is just a fact my man. Not because it's superior to other languages, it's simply because it is more cost effective to use. For example, at my current company, we are now using a Node Microservices architecture, Cassandra, Redis, Relay, GraphQL, and React. We're doing all our mobile using React Native. We were a Rails Angular shop before. All our engineers are now full-stack JS. We were able to get rid of 75% of our engineers using this stack...and then hire much higher quality engineers...JS experts. I can't tell you what a pleasure it is to work with this stack vs. something like Rails + Angular. And as for performance, it moves like nothing I've ever seen before. Warp speed brother. JS is the future my man. It's the only programming language I would invest my time in learning...i mean if you're concerned about job security and all. If not, I would spend my time learning Elixir and Phoenix. Also TensorFlow.
I guess the argument is that, if you're going to use ">=6.0.0" to choose a version of node.js, and your options are 6.1.0 and 7.0.0-rc1, you don't want a random release candidate. But if you're going to use it to verify an existing version of node.js, a 7.0.0-rc1 that someone else chose should be considered acceptable. Their semver rules can't distinguish these two cases.
PEP 440 seems to handle this by decoupling the prerelease rules and the version-comparison rules: https://www.python.org/dev/peps/pep-0440/#handling-of-pre-re... "Pre-releases of any kind, including developmental releases, are implicitly excluded from all version specifiers, unless they are already present on the system, explicitly requested by the user, or if the only available version that satisfies the version specifier is a pre-release."
On a more serious note this really is an awesome release. Kudos to everyone that works on Node.js!
Ever since the "reunification" of node.js/io.js there's been a whirlwind of great activity both in adding features as well as LTS releases (which are critical for long term adoption of the platform).
Sidenote - was just messing with Homebrew a few days ago, and found it a little bizarre that all of the recipes are in source control and require a pull to update, rather than being on a server somewhere.
On a related note, does anyone know if there's a way to tell Babel that your compilation target is Node.js v6.0 and only have it compile stuff that isn't natively supported yet?
Edit: Thanks for all the answers. I just went through the list of unsupported features and as I'm not using any of the remaining 7%, I might be able to get rid of Babel during development if I'm lucky.
Instead of Babel, you might want to look at Rollup.js for ES6 module support. [1]
You can have Rollup spit out CommonJS require commands for things that aren't part of your project, or you can use rollup-plugin-commonjs to wrap your entire app into one big bundle, including the CommonJS includes.
And as much faster as Node 6 has gotten with module importing, it almost can't be as fast as Rollup's module loader, which is more optimal than Browserify and WebPack, in that ES6 modules don't even get wrapped in "requires", but instead included inline. It just parses the code to ensure no variable names collide.
I don't know the answer, but this would be useful in general given that much of ES2015 is supported by Firefox, Chrome and Edge. It's enough that I can imagine having an "evergreen browsers" build and an "everybody else" build.
There's one remaining problem: V8 ES6 support is quite new and less optimized. If you're looking for optimal performance, you'll be transpiling for a long time (or possibly forever, 'cause those ES7 features are tempting, aren't they?)
The javscript version of the hedonic treadmill ensures there will always be a juicy new feature that node/browsers don't have yet but Babel/other transpilers usually will. Just because it's 93% of the way there on ES6 at this moment doesn't mean that a few months from now people, your team included, won't be clamoring to be able to write with the new sweet features from ECMAScript 2017 or whatever. The only solution is to keep Babel a part of your stack perpetually and really that's not so bad in my opinion.
Remember that performance with Babel transpiled code is still sometimes faster (in some cases, substantially so) than the native ES6 implementations, as optimizing continues on V8's end.
And be sensible about how much transpilation you want, you can use newer presets that don't need to transform the code as much, while still having the ability to layer in newer features (async/await, ES7, etc).
In fairness, the babel approach to module handling is probably better than an in-browser es6 module implementation, or what may follow... compatibility with npm packages (cjs) will be significant for a while.
My understanding is that V8 will provide hooks that parse the module imports, then delegate to the embedder to fetch the actual source code and hand it back to V8 to load. I'd expect that the Node implementation of these hooks would work the same way as the existing require() machinery, so that existing libraries will continue to work.
That's because it is a press release. There is a changelog and release notes too, it just happens that whoever submitted this chose to link to a press release instead.
I've been a front end developer for, well, quite a while, and in that time we've gone from cycles of around a decade (thank you IE6!) for new versions of JS to something closer to a couple of years.
Wow, a new extension for ES modules? That seems really unfortunate.
Why can't node parse a file to detect if it's a module? The presence of a top-level import or export means it's a module. If it's not, then the parsed file can be kept if the file is also in strict mode. If it's sloppy, it'll have to be re-parsed. Seems like a small penalty if the goal is to enable migration.
Also, why worry about ES modules importing Common JS? Just disallow that and let projects migrate to ES modules bottom-up. Then you don't have to worry about executing a Common JS module to determine what its exports are or circular dependency problems.
There is a pretty epic thread that I suggest you just read the tail end of https://github.com/nodejs/node-eps/pull/3#issuecomment-21476... . Basically we tried detection via source code as the first proposal; ambiguities at runtime that do not throw errors make it absolutely impossible to do safely, performance problems, and tooling integration problems.
There is/was a vote on this pretty soon. We are deciding how modules would work - with a new file extension? With a module.json? With a separate entry entry in package.json? Lots of decisions to be made :)
ES6 didn't define precisely how module loading worked, one of the reasons it isn't actually implemented yet. And there are actual reasons why the method babel currently uses won't precisely match the actual implementations (see hierarchal v flat dependencies)
I'm using node 5.9.1 and webstorm creates a -compiled.js and -compiled.js.map file for each transpiled file.
If I use Node 6 which I understand is now up to 95% support for ES6, do I still need to transpile to ES5.1? Is anyone else using webstorm with ES6 and are you also going through this transpiling step?
It makes me feel a little ill to think of all the new-ish devs jumping on the Node train, thinking it's the Next Big Thing in server code. It's a cool technology, and incredibly easy to get into, but then the curve gets so very steep as you try to make it behave like any of the robust and fundamentally sound language/framework app development ecosystems.
If I could offer any advice to anyone who is relatively new to all this, I would say choose anything else: Ruby/Rails, PHP/Symfony, Python/Django, Java/Spring, C#/.NET, whatever. You'll be doing yourself a favor. Learn how to do things correctly, in an tech stack that actually exists and works properly and makes sense, then see where things stand for JS on the server in a couple years. The bad habits, mistaken assumptions, and rampant misinformation being spread in the JS world these days is just amazing.
"Choose anything else" sounds like some FUD to me. I'm not an expert with all the technologies you mentioned but I feel like Meteor has just recently truly come into its own and I would pick it over Rails, Django, or anything PHP any day.
I think another factor is the level of conservatism of the programmer in question: would you rather work on stable but somewhat boring platforms at a large enterprise, or do you want to be on that new-new at a hip startup? (These options obviously exist on a spectrum.)
If you want to be in the fastest-moving, most exciting ecosystem around, it seems to me that JS is the train you want to be on.
Somewhat related there is no optimization for passing arbitrary length arrays with `...` to function having `...rest` as the last argument, which means [].splice is still a footgun:(
It is, but Clojure uses it, because it cannot really do Tail Call Optimization due to constraints on the JVM. Therefore "recur" is required to keep the Stack from overflowing.
It might be worth trying to get to 4.2.0, which was the first LTS [1] release (due to the change in versioning, that's only six months older than 4.2.0).
What sort of compatibility issues? Most packages update to work with new Node releases fairly quickly. Usually the packages that have compatibility issues are ones with native C++ bindings. If you `npm rm` the package and reinstall it, it will usually build correctly for the latest Node/V8 release.
Further, if you have a project that for whatever reason is not feasible to update to run on modern Current Node, you can use `nvm` or `n` to choose which Node release you want to use: i.e. `nvm exec 0.12 node old-project.js` and `nvm exec 6.0 node fresh-project.js`. v6 (and the versions that preceded it) has made Javascript really enjoyable to write.
Our biggest issue is to get off node 0.12, we need to get off protractor 2, and some of our protractor tests fail on protractor 3 for reasons no one has yet figured out. The only clue is a note saying selenium webdriver 2.48 changed how its control flow worked, but nowhere is what changed from 2.47 to 2.48 documented.
thanks, I will look deeper into it. I could not install certain packages even with a fresh and clean new node.js. NVM is not the issue (I know node version handlers like nvm or tj/n). I just wondered if I'm the only one who had this compatibility issues.
We've banned this account for repeatedly violating the HN guidelines. If you don't want it to be banned, you're welcome to email hn@ycombinator.com. We're happy to unban people when there's reason to believe that they'll only post civil, substantive comments in the future.
babel sucks - I never though I could hate something so strongly.
Just today I had to deal with the fact that babel wraps ALL your generators in some shit function.
Why ? just why ? generation function was supported in browsers longer then the age all the babel maintainers combined.
The worst part is I do not use babel myself - I wouldn't touch it with a ten foot pole but am forced to use it due to my stupid cowokers writing everything using babel - ( why does babel need .babelrc file ?? - is babel such a prominent part of your life that you need .rc files ?? and why does the .rc file need to be specified in every freaking folder ! )
1) babel's docs are also terrible
2) The people maintaining babel seem to actively market babel and then at the same time ignore questions and requests for better docs from the community.
3) Slowest compiler I have had the pleasure of dealing with - my babel watch process consumes a grand total of 150 MB of memory !!
You don't need a .babelrc file in every directory, your coworkers are doing something wrong. Also, in that .babelrc file you can customize the generator behaviour to your heart's content - if your coworkers have chosen bad presets then your issue is with them, not Babel.
I agree that Babel is slow. Hey, there's always Buble: http://buble.surge.sh/, but then you lose a lot of configurability. There's always a trade-off.
And yes, the generator stuff is far more verbose than it needs to be, but because Babel is trying to cover all browsers by default. It's like jQuery. Good news is you can opt out.
Generator functions do not have total browser support yet. IE11 does not support them. Node 6 is actually the first Node version with total support for them:
Even if generation functions are not supported - its a tradeoff that is worth making since very few of our users use IE11.
That is not my main concern. Babel can wrap the code in 10 functions for all I care ( performance is also not a concern since we are not sending rockets to mars - just another technology sweatshops trying to sell viagra )
The wrapped function throws errors - since apparently you need to download some babel plugins for it to work. (ノಠ益ಠ)ノ彡
>That is not my main concern. Babel can wrap the code in 10 functions for all I care ( performance is also not a concern
Babel code is actually faster than the native implementation of most of the ES2015/6 features atm.
>The wrapped function throws errors - since apparently you need to download some babel plugins for it to work. (ノಠ益ಠ)ノ彡
So you forgot to download some plugins and it's Babel's fault?
And, sorry, where does the entitlement come from? It's you who needs and uses Babel, even imperfect and buggy as it is, to get the job done, not the inverse.
- You can put the babel configuration in your package.json.
- babel by itself doesn't actually do anything. It depends on the preset you chose. There are now a bunch of presets that leave parts of ES6 alone (i. e. to use ES6 import with webpack).
- I have actually never looked at the docs :). Never had a problem with it (unlike the package manager from config file hell, i.e. webpack).
Yeah, webpack can be not fun at all... but, depending on your needs it can do what you want. Being able to configure CSS processed, with some stuff inlined, required from your components is pretty sweet...
Please resist commenting about being downvoted.
It never does any good, and it makes boring reading.
Please don't bait other users by inviting them to downvote
you or announce that you expect to get downvoted.
I agree with you in part. Babel is not something I'm fond of (I can't seem to wrap my brain around phabricator as an issue tracker).
In fairness though, you can configure babel to use native generators if you intend to only support platforms which implement them. However, generators have also not been well supported for very long: http://kangax.github.io/compat-table/es6/#test-generators
It'll probably be about 5-6 years until all of the features I use today are in supported in browsers and the last of IE has fallen off. I'm surprised SNI haven't pushed XP and Android < 3 out faster.
I like the idea of Babel, but would prefer it as a sort of compile-for-production step. The performance and debugging complexity don't seem worth it as part of the development process. Seems like it'd now be possible w/ Node v6 and a modern browser to develop "live" in (93% of) ES6 and then just Babel-compile to ES5 for backwards compat at the end?
Just make sure to update your package.json to take a hard dependency on Node 6+ if you do that:
This will make it so that ES6-compat is assumed and TS won't transpile ES6 functionality, but it will use commonjs for modules, which means your TS will almost be a 1:1 mapping with the compiled JS and everything should just work.