4 ms·
There is some confusion in this thread about the purpose of this tool, which is targeted at generated code—specifically, code generated by other compilers. In
by gavinpc 9y ago
There is some confusion in this thread about the purpose of this tool, which is targeted at generated code—specifically, code generated by other compilers. In order to get language features that don't exist in javascript, code has to be generated in a more or less context-agnostic way. This (as I understand it) brings more context to bear, to reduce the cost of the new abstractions for your specific usage.
- djsumdog 9y agoAh that makes sense. I was wondering why the examples all looked like Coffeescript output.
- wereHamster 9y agoWhy improve the compilers when we can have yet another tool to layer on top of our ever growing tool stack.
- abritinthebay 9y agoI take it you've never looked at a modern C++ or similar build and execution chain under the hood then? There's a LOT of parts that do different things. They may be aliased under one command (with tons of flags) but a modern system does a lot of stuff. For modern JS we appear to have: - Linters (ESLint, etc) - Transcompilation to Object Code (Babel, etc, transpile to JS) - AoT Compilation (this & Closure Compiler, etc, do optimizations on the code ahead of running it) - Recompilation (AST based compression - like Uglify) - Compiling (the actual JS VM, V8, etc) - JIT (in the actual browser) None of these steps are alien to other build chains.
- sjrd 9y agoIs that right? The Scala.js compiler emits none of that "run-time metaprogramming" boilerplate that Prepack is good at optimizing away. In general, I would expect from a compiler to JS not to emit performance killers like that. Any decent compiler to JS should be able to remove its own crap on its own ;)
- kevindqc 9y agoMaybe someone can try it on a large AOT compiled Angular2 project?