7 ms·
The ECMAScript stage 3 proposals related to decorators and class private and static fields need a lot more time to bake - maybe a few years. The whole # or -> t
by dflat 8y ago
The ECMAScript stage 3 proposals related to decorators and class private and static fields need a lot more time to bake - maybe a few years. The whole # or -> thing seems fundamentally wrong. The standards process needs to slow down until better ideas emerge from the JS community and the Babel ecosystem.
I do like the idea presented of having a transpiler track and a JS engine track. Keep the ES spec for the JS engines simpler and hoist all the syntactical sugar onto the transpilers.
- dested 8y agoDoes this help the JS engines? Instead of _knowing_ the developers intent and optimizing for it, it has to infer what the transpiler outputted and optimize for that. One seems harder than the other.
- dflat 8y agoThe yearly ES release cadence seems to be adding sugar for its own sake. This stuff hasn't been battle tested in the field long enough. Look at how many times class field and decorator proposals have changed over the years. JSX by comparison seems much more stable than the class and decorator proposals, although arguably its features are much better optimized by a transpiler rather than a native JS engine.
- scottmf 8y agoReasonML has JSX. It just translates to function calls which do whatever you want. It’ll probably never happen but it’d be cool to see native JSX in JS.
- cpeterso 8y ago> This stuff hasn't been battle tested in the field long enough. There is a circular dependency: TC39 wants new language changes to be prototyped and proven in compiled-to-JS languages but the transpiler developers don't want to implement language changes that are not already on the standards track.
- BinaryIdiot 8y ago> I do like the idea presented of having a transpiler track and a JS engine track. Keep the ES spec for the JS engines simpler and hoist all the syntactical sugar onto the transpilers. Alternatively, if you focus on getting web assembly up to speed, you can compile any flavor of JavaScript you want directly to web assembly. You wouldn't need transpilers at all except for backward compatibility (which would eventually fade). At least that's the future I'd like to see.
- crooked-v 8y agoThat would be my preference too. It feels like there are so many possibilities for performance gains and better tooling stuck behind WASM's lack of DOM integration and other native browser libs.
- RussianCow 8y agoEveryone keeps saying this, but it doesn't make sense to compile JavaScript to WebAssembly. Even if WASM had enough built-in APIs to allow you to implement JS without also implementing its runtime, you would lose all of the JIT performance optimizations. There is literally no benefit, aside from being able to implement non-backwards-compatible features (which doesn't feel like a strong reason to me, given the cost).
- BinaryIdiot 8y ago> you would lose all of the JIT performance optimizations I don't follow. Why would losing optimizations from one language prevent optimizations from being done in an IL? Are you saying that Web Assembly can't be as fast as JavaScript? If so, why? > There is literally no benefit, aside from being able to implement non-backwards-compatible features You ignored the benefit I outlined above. Why would you want a single scripting language to be the only one to ever be used in a web browser? Heck, web assembly can even make the ECMAScript iteration loop tighter if you really wanted to. I'm having trouble seeing the downsides to this approach.
- MikeHolman 8y ago