3 ms·

On this bit: > Perhaps if ES4 landed, fewer people would need complex build tools like Babel, Webpack and Typescript. I'd pose it the other way: if stuff like

On this bit: > Perhaps if ES4 landed, fewer people would need complex build tools like Babel, Webpack and Typescript. I'd pose it the other way: if stuff like Babel existed at the time, folks might have actually written es4 because they could do so without breaking backwards compatibility. And most of the value in a static type system is the ability to flag errors before running the program, so I don't think there's anything you can add to the browser that would have obviated an offline tool for that. Frankly, I think we'd be better off if we started getting a lot more selective about what gets added to browsers. Adding more and more features to browser's js implementations is silly when most folks are using ahead of time build steps to get access to those features without the browser's help. And continuing to add things is a great way to ensure that they'll keep right on using those tools, so they don't have to worry (as much) about who supports what. And it just makes the barrier of entry for building browsers higher and higher. There's more utility when native browser support can do something a compiler can't. Things like reducing code size for really widely used functionality, enabling technologies that can't be bootsraped through developer tools (e.g. WebRTC). I'd like to see additional growth of the web platform be focused on areas that can't adequately be addressed by separate tools.

masswerk 6y ago
Mind that features like type hinting in ES4 / AS3 were more about execution speed than about IDE-like error checking. There were times when AS3 was faster than any native browser JS, exactly because of this (and due to faster object lookup, as well).
- zenhack 6y ago
  Ultimately though this end probably would have been better served by bytecode.
  - masswerk 6y ago
    Mind that byte code is generally much larger than source code. (This is also, why scripting languages were prevalent server-side with slow hard disks: loading and compiling a Perl script was faster than loading a massive binary. See also the 2MB Java Hello-World.)
    - JoeAltmaier 6y ago
      Which highlights why bytecode is such a bad idea. It isn't a sort of assembly language, its much dumber, more like a pocket calculator language. It actually loses semantic information. It has to be re-compiled like the source code but with most of the useful source clues lost. A far, far better choice would have been some orderly structuring of the semantics of parsed and interpreted code. What the compiler has internally after digesting the source, but before generating code. Choose some schema and emit json or something. That would have been a game-changing choice some decades ago. But no we got saddled with byte-code and a billion dollars has been spent mitigating that disaster.
      - teddyh 6y ago
        > What the compiler has internally after digesting the source, but before generating code. Choose some schema and emit json or something. You mean the parsed Abstract Syntax Tree; AST. The next step would obviously be that people choose to start programming directly in the AST form. And now you have created Lisp.
        JoeAltmaier 6y ago
        Denied. The next step is not pretending everybody wants to be a compiler internals expert. Programming languages are two or three orders closer to human understanding.
    - zenhack 6y ago
      This needn't be the case; it depends on the details and what the particular format is designed for. Wasm is a good example of a bytecode format designed for small code size. Though I expect wasm may often still be larger than equivalent js just because it's so much lower level. But there's no reason you couldn't design a compact bytecode format with high level semantics, and I would expect it to beat any human readable format.
  - nojvek 6y ago
    AS3 did compile to bytecode. Flash used a JIT and achieved phenomenal performance compared to JS engines of the times.
    - masswerk 6y ago
      But this was more a 1:1 representation of the source with generic markers for any arguments and local variables (in functions), as far as I remember. However, there was also an optimization option in the compiler. (But, of course, type hinting instructed the byte code emitted by the compiler.)
      - nojvek 6y ago
        Absolutely. AS3 bytecode was heavily inspired from java bytecode. There were a number of asks to get a server version of AS3 but Adobe was too invested in coldfusion to make it happen. Adobe is a classic example of having too many products that they’d let internal innovation stifle. Can’t blame them but that’s why we needed Flash to be open source. Adobe did a poor job letting it realize it’s true potential.

masswerk 6y ago

Mind that features like type hinting in ES4 / AS3 were more about execution speed than about IDE-like error checking. There were times when AS3 was faster than any native browser JS, exactly because of this (and due to faster object lookup, as well).

zenhack 6y ago
Ultimately though this end probably would have been better served by bytecode.
- masswerk 6y ago
  Mind that byte code is generally much larger than source code. (This is also, why scripting languages were prevalent server-side with slow hard disks: loading and compiling a Perl script was faster than loading a massive binary. See also the 2MB Java Hello-World.)
  - JoeAltmaier 6y ago
    Which highlights why bytecode is such a bad idea. It isn't a sort of assembly language, its much dumber, more like a pocket calculator language. It actually loses semantic information. It has to be re-compiled like the source code but with most of the useful source clues lost. A far, far better choice would have been some orderly structuring of the semantics of parsed and interpreted code. What the compiler has internally after digesting the source, but before generating code. Choose some schema and emit json or something. That would have been a game-changing choice some decades ago. But no we got saddled with byte-code and a billion dollars has been spent mitigating that disaster.
    - teddyh 6y ago
      > What the compiler has internally after digesting the source, but before generating code. Choose some schema and emit json or something. You mean the parsed Abstract Syntax Tree; AST. The next step would obviously be that people choose to start programming directly in the AST form. And now you have created Lisp.
      - JoeAltmaier 6y ago
        Denied. The next step is not pretending everybody wants to be a compiler internals expert. Programming languages are two or three orders closer to human understanding.
  - zenhack 6y ago
    This needn't be the case; it depends on the details and what the particular format is designed for. Wasm is a good example of a bytecode format designed for small code size. Though I expect wasm may often still be larger than equivalent js just because it's so much lower level. But there's no reason you couldn't design a compact bytecode format with high level semantics, and I would expect it to beat any human readable format.
- nojvek 6y ago
  AS3 did compile to bytecode. Flash used a JIT and achieved phenomenal performance compared to JS engines of the times.
  - masswerk 6y ago
    But this was more a 1:1 representation of the source with generic markers for any arguments and local variables (in functions), as far as I remember. However, there was also an optimization option in the compiler. (But, of course, type hinting instructed the byte code emitted by the compiler.)
    - nojvek 6y ago
      Absolutely. AS3 bytecode was heavily inspired from java bytecode. There were a number of asks to get a server version of AS3 but Adobe was too invested in coldfusion to make it happen. Adobe is a classic example of having too many products that they’d let internal innovation stifle. Can’t blame them but that’s why we needed Flash to be open source. Adobe did a poor job letting it realize it’s true potential.