6 ms·

This starts to open a lot of very interesting new doors for web development in general. JavaScript is suddenly no longer the only real game in town it seems.

by mdhb 3y ago

This starts to open a lot of very interesting new doors for web development in general. JavaScript is suddenly no longer the only real game in town it seems. I mean sure WASM has allowed C, C++ and Rust to run on the web for awhile now but they aren’t typically languages that web developers tend to have a lot of knowledge of or interest in learning. But Dart, Kotlin and Java for example, they very much are viable replacements for many TypeScript or JavaScript use cases and the mental jump from TypeScript to any one of those three isn’t particularly onerous. We still don’t yet have direct DOM access from within WASM but I know both Kotlin and Dart at least are building a glue layer to fix that. (Example of Dart’s here: https://github.com/dart-lang/web/blob/main/test/smoke_test.dart https://github.com/dart-lang/web/blob/main/test/smoke_test.d...) It also opens up the door for a UI framework that skips the DOM and goes directly down the canvas and WebGPU path which is what Flutter are aiming towards. The web platform needs to decouple accessibility from the DOM in order to make that not just an opaque blob of pixels that a canvas element is currently but work is already underway on that via the Accessibility Object Model API. I think this gets us to a pretty exciting place just over the horizon. I’m excited to see the next few years but I think it’s at least start thinking about if JavaScript or a compile to JavaScript language is really the best option in the near future now that it’s no longer the only choice available.

pjmlp 3y ago
The revenge of plugins is almost complete.
menaerus 3y ago
> I mean sure WASM has allowed C, C++ and Rust to run on the web for awhile now but they aren’t typically languages that web developers tend to have a lot of knowledge of or interest in learning. I think that main use case is not for the web developers who already know the tech needed for web development but actually vice-versa. E.g. you're a C/C++/Rust developer and you want to expose your product as a browser service - you transpile it to wasm and with a bit of JavaScript you integrate it into the end service. And that landscape is now expanding to other languages too, namely the ones with the GC.
- pjmlp 3y ago
  Already possible with PNaCL and CrossBridge in 2010, but yeah we needed to have it as a standard and delay everything for a decade.
  - menaerus 3y ago
    I don't really know about PNaCL or CrossBridge, web is not particularly my domain but I was just trying to state the obvious advantage about WASM.
  - solarkraft 3y ago
    You're entirely correct. Non-standard ("proprietary") things tend to not catch on.
    - pjmlp 3y ago
      The irony is that with ChromeOS taking over the Web it hardly matters.
      - deleted 3y ago
        [deleted]
  - comex 3y ago
    Emscripten has been around since 2012, originally targeting JavaScript. But if you’re comparing to proprietary examples, you could go all the way back to ActiveX in 1996. Or, since today’s news is about Java, you could go back to Java applets in 1995. (At least those were somewhat secure, unlike ActiveX.)
    - pjmlp 3y ago
      Yeah, I left those out on purpose, because Java Applets did not support C and C++, although there were later compilers for the JVM, and ActiveX were straight COM x86 binaries.
- 3y ago
linuxontheweb 3y ago
I don't see the "binaryification" of the web platform happening any time soon (if ever). The web is (and should remain) fundamentally about the transmission of documents. Javascript+DOM allows for the dynamic updating of said documents, and this is what the main thread (asynchronous event loop) is all about. For all "heavy lifting," the logic should go into worker threads, where there isn't any DOM access anyway. I think a decent rule of thumb is that WASM modules should generally only be used in these kinds of off-the-event-loop types of worker threads. (See https://linuxontheweb.github.io/ https://linuxontheweb.github.io/ for my implementation of a new kind of web application platform where these kinds of ideas can start becoming a reality.)
- awongh 3y ago
  I like the idea of the web / js / DOM being for documents, but if you look at all the new browser javascript APIs it’s clear we’re constantly moving further and further away from documents. Once developers have all these tools available they build things and the cycle continues towards what seems like a pretty complete application runtime environment within the browser.
  - linuxontheweb 3y ago
    As long as web applications are necessarily embedded inside of SCRIPT elements, which are themselves necessarily embedded inside of HTML elements, then documents will always have priority over applications.
- davexunit 3y ago
  There are basically two variants of the web: The document web and the application web. I think there's space for both.
davexunit 3y ago
You can get DOM access with WASM right now by importing host functions. I have managed to write a simple virtual DOM rendering algorithm using WASM GC and imported DOM functions. Only a small bit of JavaScript is needed to instantiate the module and pass in the host functions.
winternewt 3y ago
Kotiin already compiles to JavaScript, but to my understanding it has seen limited use in browsers. So why would people use it to target wasm if they don't already use it to target JS?
- sdeleuze 3y ago
  Kotlin now also targets WASI for server-side Wasm applications. Combined to Kotlin/Wasm browser support, that’s a powerful combo. Notice the footprint is very small (3k for an hello world).
fulafel 3y ago
JS hasn't been the only "real game". People have been happily shipping apps with ClojureScript, TypeScript, Scale.js, PureScript etc compile-to-js languages for years (12+ for CLJS[1]) with much easier JS interop and integration with buid systems etc. WASM even with this is a pretty poor fit for managed languages that don't have heritage in the native compilation platforms. [1] https://www.clojure.org/news/2011/07/22/introducing-clojurescript https://www.clojure.org/news/2011/07/22/introducing-clojures...

by mdhb 3y ago

pjmlp 3y ago

The revenge of plugins is almost complete.

menaerus 3y ago

> I mean sure WASM has allowed C, C++ and Rust to run on the web for awhile now but they aren’t typically languages that web developers tend to have a lot of knowledge of or interest in learning. I think that main use case is not for the web developers who already know the tech needed for web development but actually vice-versa. E.g. you're a C/C++/Rust developer and you want to expose your product as a browser service - you transpile it to wasm and with a bit of JavaScript you integrate it into the end service. And that landscape is now expanding to other languages too, namely the ones with the GC.

pjmlp 3y ago
Already possible with PNaCL and CrossBridge in 2010, but yeah we needed to have it as a standard and delay everything for a decade.
- menaerus 3y ago
  I don't really know about PNaCL or CrossBridge, web is not particularly my domain but I was just trying to state the obvious advantage about WASM.
- solarkraft 3y ago
  You're entirely correct. Non-standard ("proprietary") things tend to not catch on.
  - pjmlp 3y ago
    The irony is that with ChromeOS taking over the Web it hardly matters.
    - deleted 3y ago
      [deleted]
- comex 3y ago
  Emscripten has been around since 2012, originally targeting JavaScript. But if you’re comparing to proprietary examples, you could go all the way back to ActiveX in 1996. Or, since today’s news is about Java, you could go back to Java applets in 1995. (At least those were somewhat secure, unlike ActiveX.)
  - pjmlp 3y ago
    Yeah, I left those out on purpose, because Java Applets did not support C and C++, although there were later compilers for the JVM, and ActiveX were straight COM x86 binaries.
3y ago

linuxontheweb 3y ago

I don't see the "binaryification" of the web platform happening any time soon (if ever). The web is (and should remain) fundamentally about the transmission of documents. Javascript+DOM allows for the dynamic updating of said documents, and this is what the main thread (asynchronous event loop) is all about. For all "heavy lifting," the logic should go into worker threads, where there isn't any DOM access anyway. I think a decent rule of thumb is that WASM modules should generally only be used in these kinds of off-the-event-loop types of worker threads. (See https://linuxontheweb.github.io/ https://linuxontheweb.github.io/ for my implementation of a new kind of web application platform where these kinds of ideas can start becoming a reality.)

awongh 3y ago
I like the idea of the web / js / DOM being for documents, but if you look at all the new browser javascript APIs it’s clear we’re constantly moving further and further away from documents. Once developers have all these tools available they build things and the cycle continues towards what seems like a pretty complete application runtime environment within the browser.
- linuxontheweb 3y ago
  As long as web applications are necessarily embedded inside of SCRIPT elements, which are themselves necessarily embedded inside of HTML elements, then documents will always have priority over applications.
davexunit 3y ago
There are basically two variants of the web: The document web and the application web. I think there's space for both.

davexunit 3y ago

You can get DOM access with WASM right now by importing host functions. I have managed to write a simple virtual DOM rendering algorithm using WASM GC and imported DOM functions. Only a small bit of JavaScript is needed to instantiate the module and pass in the host functions.

winternewt 3y ago

Kotiin already compiles to JavaScript, but to my understanding it has seen limited use in browsers. So why would people use it to target wasm if they don't already use it to target JS?

sdeleuze 3y ago
Kotlin now also targets WASI for server-side Wasm applications. Combined to Kotlin/Wasm browser support, that’s a powerful combo. Notice the footprint is very small (3k for an hello world).

fulafel 3y ago

JS hasn't been the only "real game". People have been happily shipping apps with ClojureScript, TypeScript, Scale.js, PureScript etc compile-to-js languages for years (12+ for CLJS[1]) with much easier JS interop and integration with buid systems etc. WASM even with this is a pretty poor fit for managed languages that don't have heritage in the native compilation platforms. [1] https://www.clojure.org/news/2011/07/22/introducing-clojurescript https://www.clojure.org/news/2011/07/22/introducing-clojures...