The visualizations in this article are excellent!
WebAssembly’s post-MVP future
11–20 of 207 posts
Re: WebAssembly’s post-MVP future
#12I'm reminded a bit of Java's early days when Sun was able to create the illusion that it would take over the world. WebAssembly has had a lot of early success and its limits are hazy, but it seems like they must be out there somewhere? To speculate:
On the server side, it seems like docker format has already won. Maybe cpu architecture portability doesn't matter there and x86 is good enough? Although serverless and edge computing often use JavaScript.
On mobile this seems to depend on Apple and/or Google deciding to support WebAssembly for native apps, which seems unlikely.
Developers need laptops to run their development environment in. I'm wondering if this might just be Linux tools running in a container on your laptop. Chromebooks seem to be moving in that direction.
The revival of something like Sandstorm might be interesting, but that's pretty speculative.
Re: WebAssembly’s post-MVP future
#13It would be a shame if these improvements were restricted to WebAssembly only. For most modern high level languages, JS remains a much better compile target than WebAssembly for the foreseeable future.
Re: WebAssembly’s post-MVP future
#14I'm reminded a bit of Java's early days when Sun was able to create the illusion that it would take over the world. WebAssembly has had a lot of early success and its limits are hazy, but it seems like they must be out there somewhere? To speculate: On the server side, it seems like docker format has already won. Maybe cpu architecture portability doesn't matter there and x86 is good enough? Although serverless and e…
I’m not impressed by wasm yet. One of the reasons JS is so good is because it can manipulate data without doing a full page reload, and wasm will do that, but another important reason is how productive modern JS is.
I’m not a UXer, never was, and I moved into management long before programs even got pretty so I’ve never even had to pick up.
Yet I can make a pretty web application with vue with minimal efforts. Add stuff like graphql, and wasm looks so ridiculously old aged before it’s even born.
Of course that kind of defeatist attitude is silly, and I’m looking forward to see where wasm goes in the coming years, because if people just gave up, I wouldn’t have been able to make a pretty app in vue either.
Re: WebAssembly’s post-MVP future
#15I'm reminded a bit of Java's early days when Sun was able to create the illusion that it would take over the world. WebAssembly has had a lot of early success and its limits are hazy, but it seems like they must be out there somewhere? To speculate: On the server side, it seems like docker format has already won. Maybe cpu architecture portability doesn't matter there and x86 is good enough? Although serverless and e…
I’m not impressed by wasm yet. One of the reasons JS is so good is because it can manipulate data without doing a full page reload, and wasm will do that, but another important reason is how productive modern JS is. I’m not a UXer, never was, and I moved into management long before programs even got pretty so I’ve never even had to pick up. Yet I can make a pretty web application with vue with minimal efforts. Add st…
On the other side I see huge potential for WASM because all the things I worked with in C/C++/Rust that required a client-side install are now available to me on the browser.
Stuff like UnrealEngine running in browser, low-latency audio processing, etc. Lots of potentially cool solutions where you need strong control over allocations and memory placement.
Re: WebAssembly’s post-MVP future
#16Is there already a performance advantage with the current WASM implementations for number crunching code compared to writing plain Javascript?
My experience is that modern JS engines are already pretty good at optimizing that kind of code, so I'm wondering if there are still significant speedups to be had by using WASM, given that it's still pretty new and didn't have much time to get optimized further yet.
Re: WebAssembly’s post-MVP future
#17Okay, I've only done the over-breakfast skim of this, and I hate to be that guy who comments without having fully read TFA, but here I go anyway...
I don't see any explicit mention of what I understand to be the killer feature: the ability to directly access the browser's WebAPIs, from Accelerometer to Document to MimeType to XPathExpression. Start with modifying the DOM, and go from there. Of course fast WASM/JS interop lowers the cost of the obvious workaround. And yes, there's discussion in the article of getting WASM to play nice with JS GC, which I understand is a prerequisite. But there should be explicit discussion of what the predicted path is for making WebAPIs available in WASM, what the sub-goals are, and how to measure progress.
And the first paragraph of the article is a joke, claiming that people thought the 2017 version was the final version. No, we're waiting for a relevant version (this sentence is an exaggeration, but it's more true than what TFA said).
Re: WebAssembly’s post-MVP future
#18Here's a newly created proposals repo to keep track: https://github.com/WebAssembly/proposals . > Skill: 64-bit addressing As a WASM backend implementer in an environment w/ only 32-bit addresses, I hope people don't move to 64-bit addresses too soon. Are we really reaching the limits here already? > Skill: Portability [...] A POSIX for WebAssembly if you will. A PWSIX? A portable WebAssembly system interface. Yes pl…
Agreed on the stdlib concept. I'm sure people are working on it, the benefit would be massive. Just the amount of mobile data transfer that could be saved by 1MB of software pre-distributed to all browsers would be huge. I wonder if anyone is trying to do it based on the javascript integrity hashes. In theory, if you took the top 100 javascript libraries and established a blessed build pipeline that would produce ref…
You can probably build a poor man's version with Subresource Integrity and the DecentralEyes plugin.
Re: WebAssembly’s post-MVP future
#19I'm reminded a bit of Java's early days when Sun was able to create the illusion that it would take over the world. WebAssembly has had a lot of early success and its limits are hazy, but it seems like they must be out there somewhere? To speculate: On the server side, it seems like docker format has already won. Maybe cpu architecture portability doesn't matter there and x86 is good enough? Although serverless and e…
I’m not impressed by wasm yet. One of the reasons JS is so good is because it can manipulate data without doing a full page reload, and wasm will do that, but another important reason is how productive modern JS is. I’m not a UXer, never was, and I moved into management long before programs even got pretty so I’ve never even had to pick up. Yet I can make a pretty web application with vue with minimal efforts. Add st…
Wasm isn't really for pretty apps you can quickly make in Vue. It's more for those heavy duty apps, games or libraries that most people run natively because of performance and because they're written in languages like C++, Rust, or even Fortran (scientific computing libraries).
Also, JS isn't the best tool for all programs, and programmers would like more of a choice when it comes to things that are more than just your standard web app.
Re: WebAssembly’s post-MVP future
#20I used to think without DOM web assembly is uselsess then I saw how Figma made their UI super fast rendering to a canvas and was convinced that hopefully WS will be the reason DOM apis go out of fashion