4 ms·

"Rust with WASM & web macros." It's not really that; it's really just WASM. There's going to be a flood of this sort of thing from all sorts of languages, even

by jerf 4y ago

"Rust with WASM & web macros." It's not really that; it's really just WASM. There's going to be a flood of this sort of thing from all sorts of languages, even multiple per language. It's early days yet and the ground is still being felt out, but eventually the Javascript qua Javascript foundation in the browser is going to be breached and a day will come when it is a minority language (still many years from now), for exactly the same reason that never in the whole history of computing has one general purpose programming language "won". Per https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... , Javascript is going to "win", but it's going to be Javascript in its incarnation as WASM, not the Javascript we know today. "random bits of Rust in 2024." And that's "the ground being felt out", not a fundamental problem. I expect to see WASM frameworks develop that are shipped out to the world as WASM and bind to any language. Decent odds they'll be developed in Rust for several reasons (performance not least of all), but you won't need to know that to use it in your Python WASM front-end app or some new WASM-primary language that is nothing more than a gleam in its creator's eye right now. If you don't want the chaos, hey, great. Even people who live on the cutting edge can't be cutting edge in every dimension. By all means sit back and watch from a distance. But these problems will certainly be fixed.

muglug 4y ago
The enemy of this entire thesis is the layers of additional complexity required by such “innovation”. Each layer has its own API and update mechanisms, all of which slow down developer productivity (especially when inheriting a project you did not build). In some cases that complexity is worth it — Figma, for example, squeezes a lot of value from WASM. I myself have used WASM to create a browser-based testing environment for a Rust-based static analysis tool I’ve built, so my colleagues can quickly repro issues. But for most web development, it’s not worth it.
- jerf 4y ago
  In the long term, I expect WASM to start blowing away layers of the browser, precisely because of this problem. It may be another 20 years, but it's going to happen. To put it another way, no, you're not wrong, and yes, the resistance to large-scale changes to the web stack is huge, arguably the largest resistance of all time. Nevertheless, the amount of metaphorical amperage flowing through is even larger and is large enough that it is already "short circuiting" and blasting a new circuit through. It's going to take a while, and the backwards compatibility will be with us for a while, but we're already seeing flashes of websites where you don't need to know the old CSS and HTML and such because they're actually WebGL and WASM. As more capabilities are exposed to WASM and they become more efficient, more and more stuff will be moved into it. That will cause its own explosion problem, but it'll be handled. It's not like every website is going to write its own bespoke text renderer every single time. And in the end there are some technologies that will fade out and become legacy, then irrelevant. I may yet outlive the HTML/CSS/JS stack.
  - mrighele 4y ago
    but once you blow away the layers you are left with a virtual machine with a number of low level APIs. Most people won't want to use them. Yes, I can see the advantage of rewriting those layers in terms of the lower level APIs, for example if the DOM API were to implemented in WASM, you could keep it out of the browser, and download only when/where needed (with a number of caveats, of course)... The main issue is that even if you do that, I don't expect an API designed with JS in mind to be a good fit for Rust, and vice versa. The risk is that you end up programming not against the "Web Platform", but "WebJS platform", "WebRust Platform" etc."

by jerf 4y ago

muglug 4y ago

The enemy of this entire thesis is the layers of additional complexity required by such “innovation”. Each layer has its own API and update mechanisms, all of which slow down developer productivity (especially when inheriting a project you did not build). In some cases that complexity is worth it — Figma, for example, squeezes a lot of value from WASM. I myself have used WASM to create a browser-based testing environment for a Rust-based static analysis tool I’ve built, so my colleagues can quickly repro issues. But for most web development, it’s not worth it.

jerf 4y ago
In the long term, I expect WASM to start blowing away layers of the browser, precisely because of this problem. It may be another 20 years, but it's going to happen. To put it another way, no, you're not wrong, and yes, the resistance to large-scale changes to the web stack is huge, arguably the largest resistance of all time. Nevertheless, the amount of metaphorical amperage flowing through is even larger and is large enough that it is already "short circuiting" and blasting a new circuit through. It's going to take a while, and the backwards compatibility will be with us for a while, but we're already seeing flashes of websites where you don't need to know the old CSS and HTML and such because they're actually WebGL and WASM. As more capabilities are exposed to WASM and they become more efficient, more and more stuff will be moved into it. That will cause its own explosion problem, but it'll be handled. It's not like every website is going to write its own bespoke text renderer every single time. And in the end there are some technologies that will fade out and become legacy, then irrelevant. I may yet outlive the HTML/CSS/JS stack.
- mrighele 4y ago
  but once you blow away the layers you are left with a virtual machine with a number of low level APIs. Most people won't want to use them. Yes, I can see the advantage of rewriting those layers in terms of the lower level APIs, for example if the DOM API were to implemented in WASM, you could keep it out of the browser, and download only when/where needed (with a number of caveats, of course)... The main issue is that even if you do that, I don't expect an API designed with JS in mind to be a good fit for Rust, and vice versa. The risk is that you end up programming not against the "Web Platform", but "WebJS platform", "WebRust Platform" etc."