4 ms·

> but I sometimes wonder if we’re living in a collective delusion that the current toolchain is great when it’s really just morbidly complex. Epiphany of the y

> but I sometimes wonder if we’re living in a collective delusion that the current toolchain is great when it’s really just morbidly complex. Epiphany of the year there.

TAForObvReasons 9y ago
> 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.
nine_k 9y ago
In a better world, the browser-borne language with access to DOM and other features would be small, stable, and the "transpiling" would be plain compilation. Unfortunately, both Netscape and MS wanted control, and then it was too late.
- pcwalton 9y ago
  This wouldn't be the right solution if you wanted to avoid the problem in the article. For-of has subtle semantics around exceptions. When you have to spell them out explicitly at every call site, which is what would happen with a small VM, you get the code bloat described in this article.
  - nine_k 9y ago
    I'd rather have a language which is not specific to the browser, and browsers offering a compilation target, like LLVM / CLR / JVM. A simpler compilation target would hopefully lack semantic subtleties. Now we can have this, too, of course, and e.g. run Clojure or Elm in a browser, compiled down to a safer / better supported subset of JS, or use ES7 with polyfills. But the intention of browser vendors is currently different; WebAssembly, while a small and well-defined VM, is not intended as a JS peer, let alone replacement, though.
    - wolfgke 9y ago
      > I'd rather have a language which is not specific to the browser, and browsers offering a compilation target, like LLVM / CLR / JVM. A simpler compilation target would hopefully lack semantic subtleties. I would rather claim that all common VM targets, such as LLVM, CLR, JVM etc. are so full of semantic subtleties that the subtile parts of JavaScript are quite harmless against them.
deleted 9y ago
[deleted]

> but I sometimes wonder if we’re living in a collective delusion that the current toolchain is great when it’s really just morbidly complex. Epiphany of the year there.

TAForObvReasons 9y ago

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

nine_k 9y ago

In a better world, the browser-borne language with access to DOM and other features would be small, stable, and the "transpiling" would be plain compilation. Unfortunately, both Netscape and MS wanted control, and then it was too late.

pcwalton 9y ago
This wouldn't be the right solution if you wanted to avoid the problem in the article. For-of has subtle semantics around exceptions. When you have to spell them out explicitly at every call site, which is what would happen with a small VM, you get the code bloat described in this article.
- nine_k 9y ago
  I'd rather have a language which is not specific to the browser, and browsers offering a compilation target, like LLVM / CLR / JVM. A simpler compilation target would hopefully lack semantic subtleties. Now we can have this, too, of course, and e.g. run Clojure or Elm in a browser, compiled down to a safer / better supported subset of JS, or use ES7 with polyfills. But the intention of browser vendors is currently different; WebAssembly, while a small and well-defined VM, is not intended as a JS peer, let alone replacement, though.
  - wolfgke 9y ago
    > I'd rather have a language which is not specific to the browser, and browsers offering a compilation target, like LLVM / CLR / JVM. A simpler compilation target would hopefully lack semantic subtleties. I would rather claim that all common VM targets, such as LLVM, CLR, JVM etc. are so full of semantic subtleties that the subtile parts of JavaScript are quite harmless against them.

deleted 9y ago

[deleted]