undefined | Better HN

0 pointsTouche12y ago0 comments

All of those things you mentioned are currently being worked on and will be added to JavaScript directly.

0 comments

8 comments · 2 top-level

coldtea12y ago· 3 in thread

"Coming in a browser near you in another 5-6 years"...

I've followed Harmony / ES6 for like 7 years now.

Don't hold your breath. (And I know that you can get lots of these features with special switches in Chrome, FF etc. Also know about Traceur. I mean don't hold your breath about having it released and available all-around for real web work, frameworks updated for it, etc).

lomnakkus12y ago

On Traceur: We're currently using a subset[1] of Traceur for out frontend coding and I can't say I've noticed any particular problems doing so. I also don't see any problem if libraries we were using would change to using Traceur, so long as they were to distribute the compiled output. Yes, we'd have to include the Traceur runtime, but we already do, so... (There could be versioning issues, but I suspect that the Traceur runtime is relatively static and so could remain "compatible enough" across versions. One could also easily imagine JS libraries built on Traceur distributing both the original ES6 source and the transpiled JS.)

[1] The caveat here is that we have to support IE8 (for now at least) which the Traceur runtime doesn't support, so there are a few features we cannot use (yet).

cpeterso12y ago

Does Traceur always polyfill ES6 features, even if the browser supports them natively?

lomnakkus12y ago

Of course pure source transformations (classes, let, const, splats and such) just yield ES5 source directly, and so you lose native browser support for those. That's no big deal since most browsers really aren't really up to scratch yet in ES6 support.

I'm not sure about the runtime, but I think I remember it doing some (very basic) feature detection while browsing through the generated code during a debugging session.

EDIT: Frankly, I think it would probably be a good idea to polyfill all browsers until they all really implement the ES6 spec.

modeless12y ago· 3 in thread

What's the solution being worked on for code size?

azakai12y ago

Code size currently is avoid equivalent to native builds, if you gzip both of them. The emitted code is basically similar to a native build except it's in text format (so the difference mostly vanishes after gzip).

You mentioned things like templates in C++ - those will be an issue in asm.js just as they are in a native build, no more and no less.

modeless12y ago

My experience has been that emscripten builds are significantly larger than native even after gzip. Templates are of course an issue in native builds too, but native builds are usually less size-constrained than web apps. Sending (minimized) Rust source code, as we do with JavaScript, would result in significantly smaller downloads (and less code to compile) vs. asm.js. Also shipping a standard library with the browser (as JS does) would be another significant reduction.

azakai12y ago

I would be curious to see your code, if that's possible - perhaps we can optimize things better or you are hitting a bug. How much larger was it, after gzip?

I'm not sure you'd want to send Rust source code - you'd need to wait for it to compile on the other side. (Rust is designed for many things, but fast compilation is not a primary goal.) Most likely you'd want to build it ahead of time on the server, just like C++, but then I'm not sure there would be a size advantage to Rust.

1 more reply

j / k navigate · click thread line to collapse

0 comments

8 comments · 2 top-level

coldtea12y ago· 3 in thread

"Coming in a browser near you in another 5-6 years"...

I've followed Harmony / ES6 for like 7 years now.

lomnakkus12y ago

[1] The caveat here is that we have to support IE8 (for now at least) which the Traceur runtime doesn't support, so there are a few features we cannot use (yet).

cpeterso12y ago

Does Traceur always polyfill ES6 features, even if the browser supports them natively?

lomnakkus12y ago

I'm not sure about the runtime, but I think I remember it doing some (very basic) feature detection while browsing through the generated code during a debugging session.

EDIT: Frankly, I think it would probably be a good idea to polyfill all browsers until they all really implement the ES6 spec.

modeless12y ago· 3 in thread

What's the solution being worked on for code size?

azakai12y ago

You mentioned things like templates in C++ - those will be an issue in asm.js just as they are in a native build, no more and no less.

modeless12y ago

azakai12y ago

I would be curious to see your code, if that's possible - perhaps we can optimize things better or you are hitting a bug. How much larger was it, after gzip?

1 more reply

j / k navigate · click thread line to collapse