3 ms·

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 w

by 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 muglug 4y ago

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."