5 ms·

> I’m not sure this is an issue with Babel per-se, but maybe a more meta topic of the cost of polyfilling. The overarching problem is that the web platform its

> I’m not sure this is an issue with Babel per-se, but maybe a more meta topic of the cost of polyfilling. The overarching problem is that the web platform itself is so fragmented, with different levels of support for various features, that polyfilling and transpilation are important. Strictly speaking, if every relevant browser supported for..of natively, there should be no need to transpile. You could avoid the whole for..of problem by writing ES5 JS code, but for many people that's apparently a worse option than dealing with Babel.

rhapsodic 9y ago
> You could avoid the whole for..of problem by writing ES5 JS code, but for many people that's apparently a worse option than dealing with Babel. Yes, and I don't understand that at all. I don't have any problems writing plain old ES5 code.
- noir_lord 9y ago
  You don't, I do. TypeScript has been a revolution in the way that I write client side code, been able to write in a superset of a language I already know against existing code in a way that I and my tools can reason about and with faith (backed up by experience) that I can write it once and know it will work basically everywhere is huge. Is it a perfect tool? by no means, it's output messages can be a bit opaque. That I can also use features now that won't make it into browsers everywhere for a while and that they'll gradually replace those features as browser support for them increases, ES6 was a good step in the right direction (and you can target it from TS and in many cases there aren't that many differences between clean ES6 and TypeScript's output but I can also set the target to ES5 and use it). FWIW: https://github.com/Microsoft/TypeScript/pull/12346 https://github.com/Microsoft/TypeScript/pull/12346 https://basarat.gitbooks.io/typescript/content/docs/types/lib.d.ts.html#lib-option https://basarat.gitbooks.io/typescript/content/docs/types/li...
inferiorhuman 9y ago
> You could avoid the whole for..of problem by writing ES5 JS code, but for many people that's apparently a worse option than dealing with Babel. The big reason I'm so excited about web assembly is that now we can escape the albatross of JS/ES. I've started playing with rust targeted to emscripten and it's such a breath of fresh air (both the language and toolchain).
- kbenson 9y ago
  I was just thinking the same thing while reading this article but, upon thinking about it, you'll likely have to ship the stdlib of whatever language you're targeting as well as your code (although I'm sure some interesting omissions of the stdlib can be automated determined based on the actual use). That's traditionally why Rust binaries are large (they statically compile in their standard library). Statically compiling a simple hello world C program results in a 700+ KB executable. By researching And adding various options to gcc to reduce size, I was able to get the binary down to just under 650 KB (277 KB gzipped), so progress! :/ There are undoubtedly smaller libc implementations[1], but I think I've illustrated the problem adequately. Having an entire runtime in the browser gives JS a fairly large advantage as I see it, at least currently. 1: https://en.wikipedia.org/wiki/Dietlibc https://en.wikipedia.org/wiki/Dietlibc
  - cwzwarich 9y ago
    Rust binaries are also large because they copy some of C++'s bad decisions: 1) Generics are instantiated and compiled separately with types for which the generics have identical behavior. 2) Functional abstraction is encouraged (not a bad thing!) and inlining heuristics are overly aggressive to compensate. 3) By default, almost every function call has to deal with the possibility that the callee might throw an exception. This is smaller than 1) and 2), but it still matters.
    - inferiorhuman 9y ago
      Except that rust doesn't have exceptions.
      - cwzwarich 9y ago
        Rust actually does have exceptions. Rust unwinding is implemented using LLVM/Dwarf exceptions, and can be caught using std::panic::catch_unwind: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/fn.catch_unwind.html Idiomatic Rust doesn't use them for error handling, and they can be disabled entirely with a command-line option, but the implementation still has to deal with all of the issues that come with having exceptions.

rhapsodic 9y ago

> You could avoid the whole for..of problem by writing ES5 JS code, but for many people that's apparently a worse option than dealing with Babel. Yes, and I don't understand that at all. I don't have any problems writing plain old ES5 code.

noir_lord 9y ago
You don't, I do. TypeScript has been a revolution in the way that I write client side code, been able to write in a superset of a language I already know against existing code in a way that I and my tools can reason about and with faith (backed up by experience) that I can write it once and know it will work basically everywhere is huge. Is it a perfect tool? by no means, it's output messages can be a bit opaque. That I can also use features now that won't make it into browsers everywhere for a while and that they'll gradually replace those features as browser support for them increases, ES6 was a good step in the right direction (and you can target it from TS and in many cases there aren't that many differences between clean ES6 and TypeScript's output but I can also set the target to ES5 and use it). FWIW: https://github.com/Microsoft/TypeScript/pull/12346 https://github.com/Microsoft/TypeScript/pull/12346 https://basarat.gitbooks.io/typescript/content/docs/types/lib.d.ts.html#lib-option https://basarat.gitbooks.io/typescript/content/docs/types/li...

inferiorhuman 9y ago

> You could avoid the whole for..of problem by writing ES5 JS code, but for many people that's apparently a worse option than dealing with Babel. The big reason I'm so excited about web assembly is that now we can escape the albatross of JS/ES. I've started playing with rust targeted to emscripten and it's such a breath of fresh air (both the language and toolchain).

kbenson 9y ago
I was just thinking the same thing while reading this article but, upon thinking about it, you'll likely have to ship the stdlib of whatever language you're targeting as well as your code (although I'm sure some interesting omissions of the stdlib can be automated determined based on the actual use). That's traditionally why Rust binaries are large (they statically compile in their standard library). Statically compiling a simple hello world C program results in a 700+ KB executable. By researching And adding various options to gcc to reduce size, I was able to get the binary down to just under 650 KB (277 KB gzipped), so progress! :/ There are undoubtedly smaller libc implementations[1], but I think I've illustrated the problem adequately. Having an entire runtime in the browser gives JS a fairly large advantage as I see it, at least currently. 1: https://en.wikipedia.org/wiki/Dietlibc https://en.wikipedia.org/wiki/Dietlibc
- cwzwarich 9y ago
  Rust binaries are also large because they copy some of C++'s bad decisions: 1) Generics are instantiated and compiled separately with types for which the generics have identical behavior. 2) Functional abstraction is encouraged (not a bad thing!) and inlining heuristics are overly aggressive to compensate. 3) By default, almost every function call has to deal with the possibility that the callee might throw an exception. This is smaller than 1) and 2), but it still matters.
  - inferiorhuman 9y ago
    Except that rust doesn't have exceptions.
    - cwzwarich 9y ago
      Rust actually does have exceptions. Rust unwinding is implemented using LLVM/Dwarf exceptions, and can be caught using std::panic::catch_unwind: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/fn.catch_unwind.html Idiomatic Rust doesn't use them for error handling, and they can be disabled entirely with a command-line option, but the implementation still has to deal with all of the issues that come with having exceptions.