Hacker News new | past | comments | ask | show | jobs | submit login

[deleted]



I'm all in on ES6 when it's practical or allowed. Arrow functions are wonderful, I love destructuring assignment, const and let, and considering that some projects I work on involve a lot of async stuff, I'm close to just giving in and using ES7's async/await functionality.

But most of the time this is in the context of Node.js development, and in every case I use Babel.js to turn the end result into ES5 code.

I'm perfectly comfortable with using ES5, because as a freelancer/contractor I often have to do so. But I really miss the ES6 stuff and the more I use it, the more time it takes me to 'switch' to a mindset where I'm only allowed to use ES5 functionality.

Nonetheless, it strikes me as really odd to actively prefer ES5. Having worked with Ruby and Python (among others), ES5 feels limiting for no good reason. The only rationale I can think of for prefering ES5 is nostalgia.

Could you elaborate why you don't like the 'perl/python' style changes? Because I truly do not understand why one would choose to limit oneself to things like .bind(this) instead of the different forms of arrow functions that make functional-like programming so much easier. And I've found that the best part of JS is that it's decently functional.

Edit: I would agree when it comes to the new 'class' keyword though. I'm not a fan of that.


> Could you elaborate why you don't like the 'perl/python' style changes?

It's really just a style preference. I enjoy the "look" of C-family code.

>why one would choose to limit oneself to things like .bind(this)

I know 'this' is a source of pain for a lot of people. For me, I see it a source of flexibility. I've found the ability to control the context at will to be a huge benefit. It's a feature I miss when I'm writing in other languages.


> For me, I see it a source of flexibility. I've found the ability to control the context at will to be a huge benefit. It's a feature I miss when I'm writing in other languages.

But that's why you can still use the regular functions... I don't quite understand how having the added option of a more concise syntax with automatic binding to the surrounding context is less flexible. I often find myself using the regular function declarations to differentiate between different sorts of functions. The arrow notation is opt-in.

Or is your issue that when you work with other people's codebases, you have no option to opt-out?


Having used ES7 async/await through Babel extensively for some highly asynchronous code, I can say that it feels much better than using Promises alone, even better than using ES6 generators + a runner (especially since async/await meshes so well with ES6 classes).


The only fear I have is that the spec might still change, which is not the case for ES6 features. Do you think my fears are unfounded? Because I'd love to use ES7 for my back-end projects where all database interaction, and by extension a large part of my codebase, relies on promises...


> But most of the time this is in the context of Node.js development, and in every case I use Babel.js to turn the end result into ES5 code.

If it's helpful: the current stable node (4.x) already supports ES6 out of the box.


I'm currently doing that for a project, but I'm about to change things up and use Babel anyways, for the following reasons:

- my project contains jsx files, which currently are compiled into .js files which feels a bit messy.

- I'm seriously considering using ES7's async/await functionality, which is not supported by node yet.

- and most importantly: node's ES6 support is incomplete. In particular, I miss default function parameters and destructuring assigment.

Using Babel would solve all these issues, and I could simply remove Babel once support is sufficient.


Webpack/browserify remove/polyfill most of the ES6 syntax so it is backwards compatible for browsers. Server side you just need to be aware of your engine's support of ES6.

The extra syntax around arguments (defaults and rest) is useful. ES5 does support function overload, but often ends up some hard to read hacks. Libraries commonly have only a few functions, but the functions have flexible signatures. So the first thing you see when trying to read their source is a jumble of argument parsing.

That said, ES6 can end up with some poor performance. For example, template literals are almost 10x slower than just plain string concatenation. But if you are concerned with performance, writing JS may not the be the best choice.


Not at work, but I use either ES6 or Typescript personally.

"All of the syntactic sugar stuff changes the look and feel of the language too much for my tastes."

I think it brings it into line with how the language is being used in production these days. Modules, generators etc make the language more beautiful, powerful and easier to maintain.


>>> Not at work, but I use either ES6 or Typescript personally.

Not a JS developer, but most of my friends who are have been transitioning to Typescript. The road is bumpy, but they say once you get some syntax stuff down, you're good.


TypeScript is very nice. The one main problem it has is lack of type definitions for third-party modules, some developers find having to "waste time" writing those defs themselves to be quite bothersome.


Typescript gives you an "out" to type checking using the any type. Additionally, most libraries really worth using have .d.ts files floating around the internet somewhere, in DefinitelyTyped or otherwise.


That's all true. It's a chicken-and-egg problem there, though. I've seen several arguments that the language is not worth looking into until more typings become available, and of course those naysayers are not going to write the missing typings.


Writing ES6 at work, turned into ES5 by Babel. I don't want to write "var self = this" ever again. Also, quite a few Node modules are ES6, and we use NPM for managing our frontend JS packages.


I'm also all-in on ES6. We use it extensively on Metabase (https://github.com/metabase/metabase)


Using ES6 here most of the time as well, there's very few reasons not to these days. Some of the changes may only be syntactic sugar but you very quickly find yourself not wanting to go back.


I prefer ES6/ES2015 (currently via Babel, and considering TypeScript). The let keyword and arrow functions in particular make it a much more pleasant language to work with than plain JS. It's now competitive with CoffeeScript, but with more coherent and predictable parsing rules.


Template strings, arrow functions and object shorthand ({ foo: foo } === { foo }) are very nice.


To be clear, that statement doesn't actually evaluate to true, but those two object literals are equivalent (not referentially equal)


Why did someone downvote this? It's correct: https://babeljs.io/repl/#?experimental=true&evaluate=true&lo...


I'm fully using es6 for most of projects now. Started about 2 months ago and will make all new projects I have with it. Import/export, destructuring, templates, string interpolation.. it just cuts down on alot of the cruft (imo).


I'm still writing ES5 at work, but I've fully embraced ES6 (and bits of ES7) for personal projects. I love it and it's a major improvement to the language IMO.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: