6 ms·

This is why the JS ecosystem frustrates me. We're talking about an ES7 -> ES6 transpilation, which I will then have to transpile again to ES5. And that's before

This is why the JS ecosystem frustrates me. We're talking about an ES7 -> ES6 transpilation, which I will then have to transpile again to ES5. And that's before we even hit the VM/JIT.

deleted 11y ago
[deleted]
marten-de-vries 11y ago
Luckily, you can downcompile to ES5 using the exact same tool: Babel. See for an example: https://github.com/marten-de-vries/kneden/tree/master/test/fixtures/pouchdb-auth https://github.com/marten-de-vries/kneden/tree/master/test/f... Anyway, I agree, the sooner Kneden becomes obsolete, the better!
_pmf_ 11y ago
Don't forget to sprinkle in JSX and TypeScript, so that transpilers have to support the cross product [ES5, ES6, ES7] X [JS, JSX] X [JS, TypeScript].
skrebbel 11y ago
Meh, the ES6 features this needs don't need transpilation, just Promises. They're perfectly well stubbable with a library (such as Core-js or Bluebird) so you don't actually need to transpile stuff "again" to ES5. But note that it's shipped as a babel plugin, so you shouldn't even need to care. What this really is is "use the currently-most-popular JS transformation toolchain to transform cool-JS to works-in-browser-JS". Whether part X is in the ES6 standard and part Y might end up in ES7 is really mostly besides the point.
aikah 11y ago
Or you can stick to ES5 like I do, and just use typescript definitions to help you with code validation and type checking. The problem is frameworks pushing a lot of non standard features, like Angular does, on the premise that it might be part of the spec one day. That's a dangerous bet.
joshmanders 11y ago
The beauty and goal of Babel and it's plugins is you can use future JavaScript today, and when that future JavaScript is now considered today's JavaScript, you can remove Babel and your code just works. This isn't like TypeScript or CoffeeScript where you're always transpiling.
krisdol 11y ago
Or don't use undeveloped language features until they're available. I'm very happy with the subset of ES6 available on node, but I never shared the complaints many people have of "callback hell". It's really not difficult to deal with and adding promises doesn't magically make it better, I've seen my share of promise hell.
- jey 11y ago
  Yes, except that the asynchronous hells finally go away when you start using async/await. Makes code easy to read, write, and reason about.
dimal 11y ago
Or just don't use this. Wait until these language features are natively supported. It's your choice. There's no need to be frustrated by something that you don't use.
jacobr 11y ago
Promises have decent support (http://caniuse.com/#feat=promises http://caniuse.com/#feat=promises) so there are certainly circumstances where you don't even need to use a polyfill.

This is why the JS ecosystem frustrates me. We're talking about an ES7 -> ES6 transpilation, which I will then have to transpile again to ES5. And that's before we even hit the VM/JIT.

deleted 11y ago

[deleted]

marten-de-vries 11y ago

Luckily, you can downcompile to ES5 using the exact same tool: Babel. See for an example: https://github.com/marten-de-vries/kneden/tree/master/test/fixtures/pouchdb-auth https://github.com/marten-de-vries/kneden/tree/master/test/f... Anyway, I agree, the sooner Kneden becomes obsolete, the better!

_pmf_ 11y ago

Don't forget to sprinkle in JSX and TypeScript, so that transpilers have to support the cross product [ES5, ES6, ES7] X [JS, JSX] X [JS, TypeScript].

skrebbel 11y ago

Meh, the ES6 features this needs don't need transpilation, just Promises. They're perfectly well stubbable with a library (such as Core-js or Bluebird) so you don't actually need to transpile stuff "again" to ES5. But note that it's shipped as a babel plugin, so you shouldn't even need to care. What this really is is "use the currently-most-popular JS transformation toolchain to transform cool-JS to works-in-browser-JS". Whether part X is in the ES6 standard and part Y might end up in ES7 is really mostly besides the point.

aikah 11y ago

Or you can stick to ES5 like I do, and just use typescript definitions to help you with code validation and type checking. The problem is frameworks pushing a lot of non standard features, like Angular does, on the premise that it might be part of the spec one day. That's a dangerous bet.

joshmanders 11y ago

The beauty and goal of Babel and it's plugins is you can use future JavaScript today, and when that future JavaScript is now considered today's JavaScript, you can remove Babel and your code just works. This isn't like TypeScript or CoffeeScript where you're always transpiling.

krisdol 11y ago

Or don't use undeveloped language features until they're available. I'm very happy with the subset of ES6 available on node, but I never shared the complaints many people have of "callback hell". It's really not difficult to deal with and adding promises doesn't magically make it better, I've seen my share of promise hell.

jey 11y ago
Yes, except that the asynchronous hells finally go away when you start using async/await. Makes code easy to read, write, and reason about.

dimal 11y ago

Or just don't use this. Wait until these language features are natively supported. It's your choice. There's no need to be frustrated by something that you don't use.

jacobr 11y ago

Promises have decent support (http://caniuse.com/#feat=promises http://caniuse.com/#feat=promises) so there are certainly circumstances where you don't even need to use a polyfill.