4 ms·

That approach only makes any sense if you have broadly compatible semantics; otherwise execution will pay a heavy penalty (CPU usage, memory usage, bundle size)

That approach only makes any sense if you have broadly compatible semantics; otherwise execution will pay a heavy penalty (CPU usage, memory usage, bundle size). And let me tell you, your “Rust, Kotlin, Python, probably many more” don’t transpile to JS well. If you genuinely mean transpiling as distinct from compiling, I think you could even reasonably say that it’s simply not possible for many languages due to fundamental and incompatible differences. I’d count Rust as that due to things like resolution and aliasing. If you’re interested in targeting JavaScript, languages like this are your only reasonable alternative to JavaScript itself. (If you’re interested in targeting the web more generally, WebAssembly is a better target.)

smt88 2y ago
I should have referenced compiling to Wasm as well, which is what languages with very different semantics to JS (like Rust, the CLR family, and the JVM family) all do.
- chrismorgan 2y ago
  If you do mean more generically targeting the web, then I recommend avoiding the word “transpile”, which will be understood to be something far more restricted in scope.
- akdev1l 2y ago
  Working with WASM isn’t really that good for interactive pages with dynamic DOM. If you don’t mind I guess you could just render to a canvas but then you lose a ton of functionality provided by the browser. (Eg: making a responsive page in WASM seems hard) It seems to me for most web applications JS is the only real alternative as of now
  - chrismorgan 2y ago
    > Working with WASM isn’t really that good for interactive pages with dynamic DOM. It’s completely fine. At present you’ll need to trampoline via JS to make the actual DOM calls, but that’s not typically a performance bottleneck; and such bindings can give you exactly the same API, if you choose. Yes, work is just about done in browsers for giving you direct access to these things without the JS trampolining, and lots of people are hanging out for that to be dependable, but in practical terms it changes nothing. Nothing. No change in expressiveness; it only gets you probably slightly better performance, and a simpler technique for binding (which is typically immaterial for end users, as libraries were handling that for them).

smt88 2y ago

I should have referenced compiling to Wasm as well, which is what languages with very different semantics to JS (like Rust, the CLR family, and the JVM family) all do.

chrismorgan 2y ago
If you do mean more generically targeting the web, then I recommend avoiding the word “transpile”, which will be understood to be something far more restricted in scope.
akdev1l 2y ago
Working with WASM isn’t really that good for interactive pages with dynamic DOM. If you don’t mind I guess you could just render to a canvas but then you lose a ton of functionality provided by the browser. (Eg: making a responsive page in WASM seems hard) It seems to me for most web applications JS is the only real alternative as of now
- chrismorgan 2y ago
  > Working with WASM isn’t really that good for interactive pages with dynamic DOM. It’s completely fine. At present you’ll need to trampoline via JS to make the actual DOM calls, but that’s not typically a performance bottleneck; and such bindings can give you exactly the same API, if you choose. Yes, work is just about done in browsers for giving you direct access to these things without the JS trampolining, and lots of people are hanging out for that to be dependable, but in practical terms it changes nothing. Nothing. No change in expressiveness; it only gets you probably slightly better performance, and a simpler technique for binding (which is typically immaterial for end users, as libraries were handling that for them).