Hacker News Reader

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:

https://kangax.github.io/compat-table/es6/

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.

As I have mentioned above, I do not write ES6/ES2015/ES2016...

Its the entire web community writing code in a barely function compiler.

>I do not write ES6/ES2015/ES2016...

So maybe not the best person to comment on the state of its tools?

>Its the entire web community writing code in a barely function compiler.

"I didn't include some plugins so the compiler couldn't work" != "barely functioning compiler".

It's not just IE11, it's Safari 9 and older, iOS 9 and older, and Android 5.0 and older.

Generators are unsupported on all of them.

And if you're public facing, IE9-11 may be too big combined to not support.

- 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...

From the HN Guidelines:

  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.

sorry. I will edit it out.

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

I have the feeling Babel has a hidden lock-in.

When I look at the compat tables, everything is getting green, looks like a bright future, without the need of Babel anymore.

But I find myself using post-ES2015 features all the time, because, why not? Babel gets me the latest fix.

(static) class properties, decorators, bind... Also JSX! Even if all browsers are completely on ES2015 in the next months, I can't throw Babel out :D

But luckily it seems like the next ES releases are all much smaller, so maybe the browser-manufacturers will have caught up in 2016...

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?

Which unfortunately loses the ES7 features.

You can use the env option to change the transforms per env http://babeljs.io/docs/usage/babelrc/#env-option

you can have different configs for prod vs dev. Just compile the features your dev browsers don't support. Done.

use babel-node (babel-cli) against src/ in dev, build and run against dist/ in prod.

Whatever Babel is worth, between "hate this" and "stupid coworkers" that, this whole comment screams "unprofessional" and/or newbie.

Lucky this post has nothing to do with Babel then!