4 ms·

That's not a solution if you end up with Javascript in the end. (Also Dash is absolutely terrible, horrible documentation, horrible code.)

vbsteven 5y ago
Why is that not a solution? The concept of compiling/transpiling a language into the target language for the runtime is everywhere. Even native languages like C/C++/Rust compile their language into binary format that the platform can run. It just so happens that the web runtime format is JS instead of binary machine instructions.
- HideousKojima 5y ago
  Because debugging your transpiled JavaScript becomes a nightmare in a language you already hate
  - dragonwriter 5y ago
    > Because debugging your transpiled JavaScript becomes a nightmare in a language you already hate That’s what sourcemaps are for; you don’t have to debug compiled instead of source format on the web just like you don't on other platforms.
dragonwriter 5y ago
> That's not a solution if you end up with Javascript in the end. ( It is, just as using compile-to-(or interpreted-by-a-runtime-in-)-native-code languages is a solution to “I don’t like raw x86_64 machine code for desktop applications”, even if you end up running machine code in the end. > Also Dash is absolutely terrible, horrible documentation, horrible code. “X is not a choice people can make” is a different claim than “One example of X is not something I personally would recommend”.
- ad404b8a372f2b9 5y ago
  The issue is that writing code that goes through a JS-transpiler is more complicated than just writing Javascript, unless the language you choose is Javascript-adjacent, whereas writing code that compiles to machine code is infinitely less complicated than just writing machine code. As to your second point, that's why I put it in parentheses, of course it doesn't refute your claim but if you use as example a technology that has awful documentation because of this two-language paradigm, and leads to garbage code both at the Python stage and the Javascript stage, to me it doesn't paint a good picture of the whole concept.

vbsteven 5y ago

Why is that not a solution? The concept of compiling/transpiling a language into the target language for the runtime is everywhere. Even native languages like C/C++/Rust compile their language into binary format that the platform can run. It just so happens that the web runtime format is JS instead of binary machine instructions.

HideousKojima 5y ago
Because debugging your transpiled JavaScript becomes a nightmare in a language you already hate
- dragonwriter 5y ago
  > Because debugging your transpiled JavaScript becomes a nightmare in a language you already hate That’s what sourcemaps are for; you don’t have to debug compiled instead of source format on the web just like you don't on other platforms.

dragonwriter 5y ago

> That's not a solution if you end up with Javascript in the end. ( It is, just as using compile-to-(or interpreted-by-a-runtime-in-)-native-code languages is a solution to “I don’t like raw x86_64 machine code for desktop applications”, even if you end up running machine code in the end. > Also Dash is absolutely terrible, horrible documentation, horrible code. “X is not a choice people can make” is a different claim than “One example of X is not something I personally would recommend”.

ad404b8a372f2b9 5y ago
The issue is that writing code that goes through a JS-transpiler is more complicated than just writing Javascript, unless the language you choose is Javascript-adjacent, whereas writing code that compiles to machine code is infinitely less complicated than just writing machine code. As to your second point, that's why I put it in parentheses, of course it doesn't refute your claim but if you use as example a technology that has awful documentation because of this two-language paradigm, and leads to garbage code both at the Python stage and the Javascript stage, to me it doesn't paint a good picture of the whole concept.