3 ms·

I may be wrong, but I feel the anti-transpile crowd hasn't done their research. Comments in this vein have been popping up for years and have been resolved for

by cnp 11y ago

I may be wrong, but I feel the anti-transpile crowd hasn't done their research. Comments in this vein have been popping up for years and have been resolved for years. Check out the transpiled Babel code -- it's what you would expect, and sourcemaps take you the rest of the way.

BinaryIdiot 11y ago
I've used source maps before but they're not nearly as good or intuitive as simply debugging ES5. Too much of a pain in the ass in my opinion. I just don't see the value of adding an additional layer of possible bugs / issues just so I can use a little bit better syntax; I'd rather wait until more things get updated with the native implementation. I still think a better solution is some sort of byte code so people can use whatever language they want instead of trying to force JavaScript to be the "byte code of the web".
- tracker1 11y ago
  It's already been tried several times... and unless the big 3 browser makers (google, mozilla and ms) all support a given approach it just won't happen. JS is for better or worse what we get in the browser, and the subset optimizations for asmjs is probably as good as what we will get broader support for. Transpilation is really the only option... And even using a common bytecode, there will still be a compile step which is separate from the source, and requires mapping to be able to associate the bytecode to the source with the same potential for bugs you are complaining about.
  - BinaryIdiot 11y ago
    > It's already been tried several times... and unless the big 3 browser makers (google, mozilla and ms) all support a given approach it just won't happen. Has it really been tried though? I've never seen more than a few half assed attempts without all parties involved. I've love to see them come together to work something like this out; the web as it exists today isn't nearly as snappy or nice as native apps so I feel like something will eventually change here. Whether that's the help of a bytecode implementation or something else I'm not sure. > And even using a common bytecode, there will still be a compile step which is separate from the source, and requires mapping to be able to associate the bytecode to the source with the same potential for bugs you are complaining about. Yes there is always potential for compilation to introduce bugs but compiling into a bytecode is vasty different from compiling into JavaScript. JavaScript is a functional language with a lot of quirks; Java bytecode and .Net's MSIL, for comparison, are very raw and fast with as few features as possible. It's significantly better to compile into some form of bytecode for later execution than compiling into another human-readable language.

by cnp 11y ago

BinaryIdiot 11y ago

I've used source maps before but they're not nearly as good or intuitive as simply debugging ES5. Too much of a pain in the ass in my opinion. I just don't see the value of adding an additional layer of possible bugs / issues just so I can use a little bit better syntax; I'd rather wait until more things get updated with the native implementation. I still think a better solution is some sort of byte code so people can use whatever language they want instead of trying to force JavaScript to be the "byte code of the web".

tracker1 11y ago
It's already been tried several times... and unless the big 3 browser makers (google, mozilla and ms) all support a given approach it just won't happen. JS is for better or worse what we get in the browser, and the subset optimizations for asmjs is probably as good as what we will get broader support for. Transpilation is really the only option... And even using a common bytecode, there will still be a compile step which is separate from the source, and requires mapping to be able to associate the bytecode to the source with the same potential for bugs you are complaining about.
- BinaryIdiot 11y ago
  > It's already been tried several times... and unless the big 3 browser makers (google, mozilla and ms) all support a given approach it just won't happen. Has it really been tried though? I've never seen more than a few half assed attempts without all parties involved. I've love to see them come together to work something like this out; the web as it exists today isn't nearly as snappy or nice as native apps so I feel like something will eventually change here. Whether that's the help of a bytecode implementation or something else I'm not sure. > And even using a common bytecode, there will still be a compile step which is separate from the source, and requires mapping to be able to associate the bytecode to the source with the same potential for bugs you are complaining about. Yes there is always potential for compilation to introduce bugs but compiling into a bytecode is vasty different from compiling into JavaScript. JavaScript is a functional language with a lot of quirks; Java bytecode and .Net's MSIL, for comparison, are very raw and fast with as few features as possible. It's significantly better to compile into some form of bytecode for later execution than compiling into another human-readable language.