WASM has a lot of potential. But in terms of shipping less code I don't think it is particularly compelling. I think it means potential of bringing some really rich performant applications to the browser. I think it opens up new ways to run code of the server(or serverless) in more performant ways.
I expect we will see serverless WASM platforms to offer optimal performance using things like AssemblyScript. This might be a competitive edge. Maybe even new WASM based server platforms.
In the browser as we see more of the barriers ironed out WASM should get more performant. Which it will make it an easier choice for offloading heavy computational work. Still unclear whether it can compete with a SPA framework for rendering, all indications so far suggest not for a while but it will definitely be a key role player.
For traditional sites and MPA which are trying to shave overhead I don't expect it to play much of a role outside of powerful widgets you lazy load.
For the foreseeable future, while I see a lot of value in WASM I don't expect it to be game changer in terms of the core experience. But rather a really nice addition to the arsenal.
I started programming in 1995 with Microsoft BASIC on MS-DOS from a book I found in my father's library, and I slowly (having no real mentors) learned other programming languages by myself.
What about if they develop a specific runtime or sandbox similar to how JavaScript runs in the browser, only made specifically for WASM?
Could that happen and would that spell doom for JavaScript?
I mean could something like Rust or AssemblyScript with full access to the browser DOM and browser APIs result in massively more powerful and more performant PWAs?
Could all the above translate to less bytes shipped to the client especially if the code can be sent already compiled for the specific binary interface of that runtime?
PS - Sorry if I'm misunderstanding how some of these technologies work or are supposed to play together. I'm new to the field of web development.
Hard to speculate when they get access to the DOM API if they'd be massively more powerful. I do think that if they could avoid the overhead of going through JavaScript bindings there are good improvements to be made. I wouldn't be surprised if it could be really good for app like experience. However, if I were guessing I wouldn't expect this reality for at least 5 years.
In the next couple years there will likely be some big improvements but to fully realize this is going to take a while. I wouldn't be surprised if we don't see this fully happen this decade. That sounds callous but like Web Components have been in the works for 10 years. WASM has been going for about 4 years now. Which is why I'm unclear if it is more likely JavaScript becomes more dominant than ever during this time and WASM ends up just a way to continue for it to take over traditional backend services. I'm basically saying I'm more likely to bet on the speed proprietary solutions(like a new backend platform) move at than that of the Browser platform which basically dictates the speed WASM can be adopted.
In terms of size I imagine WASM doesn't end up being smaller. However it's possible there is less parsing/execution overhead that makes up for that. I'd be surprised if it has any meaningful impact on this initial load scenario. So for traditional websites/MPAs I wouldn't really hold my breath. We might see exploration there but likely only after what I wrote about above.
I find this discussion interesting. I want to share my findings on the future of WASM, but I realised that they are just a tad too much for a comment here (bullet points and all). So here are my Notes on the future of WASM and JS (2 min read, most important facts, with sources). FWIW.
avoid the overhead of going through JavaScript bindings
See esp. the Web IDL bindings proposal which would allow WebAssembly to directly access the native web API’s (which allow operating on the DOM). Imagine the possibilities...
Yeah that's pretty much what I've seen. A good summary. I'm aware of these proposals but these things take years. So what I was getting at is I give it about equal chance that JavaScript to WASM compilation gets in a good place before those proposals get implemented. To be performant enough to push JavaScript further into the backend before it's practical to take WASM approaches mainstream in the browser.
👨🏫 Co-Founder of This is Learning, Organizer of AarhusJS
✍️ Writer, Speaker, FOSS Maintainer 📗 Author
🏆 Microsoft MVP 🌟 GitHub Star
🌊 Nx Champion 🦸 Angular Hero of Education
Yeah I didn't realize this had a name. This is an example of what I was referring to in using WASM not in the browser being a potentially more interesting application. It's cool that they are attempting to standardize this approach.
👨🏫 Co-Founder of This is Learning, Organizer of AarhusJS
✍️ Writer, Speaker, FOSS Maintainer 📗 Author
🏆 Microsoft MVP 🌟 GitHub Star
🌊 Nx Champion 🦸 Angular Hero of Education
👨🏫 Co-Founder of This is Learning, Organizer of AarhusJS
✍️ Writer, Speaker, FOSS Maintainer 📗 Author
🏆 Microsoft MVP 🌟 GitHub Star
🌊 Nx Champion 🦸 Angular Hero of Education
WASM has a lot of potential. But in terms of shipping less code I don't think it is particularly compelling. I think it means potential of bringing some really rich performant applications to the browser. I think it opens up new ways to run code of the server(or serverless) in more performant ways.
I expect we will see serverless WASM platforms to offer optimal performance using things like AssemblyScript. This might be a competitive edge. Maybe even new WASM based server platforms.
In the browser as we see more of the barriers ironed out WASM should get more performant. Which it will make it an easier choice for offloading heavy computational work. Still unclear whether it can compete with a SPA framework for rendering, all indications so far suggest not for a while but it will definitely be a key role player.
For traditional sites and MPA which are trying to shave overhead I don't expect it to play much of a role outside of powerful widgets you lazy load.
For the foreseeable future, while I see a lot of value in WASM I don't expect it to be game changer in terms of the core experience. But rather a really nice addition to the arsenal.
Magnificent.
What about if they develop a specific runtime or sandbox similar to how JavaScript runs in the browser, only made specifically for WASM?
Could that happen and would that spell doom for JavaScript?
I mean could something like Rust or AssemblyScript with full access to the browser DOM and browser APIs result in massively more powerful and more performant PWAs?
Could all the above translate to less bytes shipped to the client especially if the code can be sent already compiled for the specific binary interface of that runtime?
PS - Sorry if I'm misunderstanding how some of these technologies work or are supposed to play together. I'm new to the field of web development.
Hard to speculate when they get access to the DOM API if they'd be massively more powerful. I do think that if they could avoid the overhead of going through JavaScript bindings there are good improvements to be made. I wouldn't be surprised if it could be really good for app like experience. However, if I were guessing I wouldn't expect this reality for at least 5 years.
In the next couple years there will likely be some big improvements but to fully realize this is going to take a while. I wouldn't be surprised if we don't see this fully happen this decade. That sounds callous but like Web Components have been in the works for 10 years. WASM has been going for about 4 years now. Which is why I'm unclear if it is more likely JavaScript becomes more dominant than ever during this time and WASM ends up just a way to continue for it to take over traditional backend services. I'm basically saying I'm more likely to bet on the speed proprietary solutions(like a new backend platform) move at than that of the Browser platform which basically dictates the speed WASM can be adopted.
In terms of size I imagine WASM doesn't end up being smaller. However it's possible there is less parsing/execution overhead that makes up for that. I'd be surprised if it has any meaningful impact on this initial load scenario. So for traditional websites/MPAs I wouldn't really hold my breath. We might see exploration there but likely only after what I wrote about above.
I find this discussion interesting. I want to share my findings on the future of WASM, but I realised that they are just a tad too much for a comment here (bullet points and all). So here are my Notes on the future of WASM and JS (2 min read, most important facts, with sources). FWIW.
See esp. the Web IDL bindings proposal which would allow WebAssembly to directly access the native web API’s (which allow operating on the DOM). Imagine the possibilities...
Yeah that's pretty much what I've seen. A good summary. I'm aware of these proposals but these things take years. So what I was getting at is I give it about equal chance that JavaScript to WASM compilation gets in a good place before those proposals get implemented. To be performant enough to push JavaScript further into the backend before it's practical to take WASM approaches mainstream in the browser.
Are you aware of WASI? Interesting potential future for serverless services.
Yeah I didn't realize this had a name. This is an example of what I was referring to in using WASM not in the browser being a potentially more interesting application. It's cool that they are attempting to standardize this approach.
It's been an ongoing effort for a few years. I would love to see vendors support this. It seems like it could be an OCI (Docker) container killer.
A few interesting projects: