I remember the first Unity demos appearing on these orange pages at least 4 or 5 years ago, and promptly blowing me away. But, after an eternity in JavaScript years, I still dont know what the killer app is, technically or business wise. (Side note - I encourage people to prove me wrong, in fact I'd love to be! Thats whats so engaging about discussions here. I'd love to see examples of what WebAssembly makes possible that wouldn't exist without it.)
Obviously very serious chess players will still want to install a database and engine(s) on their own computer, but for casual players who just occasionally want to check what they should have done on move eleven to avoid losing their knight it's a game changer.
If it's not, I'd be interested to see a speed and feature comparison between the two.
Example of WASM being used in a major product:
https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
You can infer from this that it's making them 3x faster than anything a competitor can make, and probably inspired a lot of those 'Why is Figma so much more awesome than any comparable tool?' comments I remember reading on Twitter months back.
I use WebAssembly for a few cross-platform plugins. E.g. An AR 3D rendering engine in C++ and OpenGL. With very little effort it is working in browser. No bespoke code, same business logic, etc. Saved a lot of time vs creating a new renderer for our web app.
For me it allows a suite of curated plugins which work cross-platform. The web experience is nearly just as nice as the native mobile and desktop experience. This in turn increases market growth as more of my clients prefer web vs downloading an app (which is a large blocker for my users). I also enjoy the code reuse, maintainability, etc, :)
Another:
This year Max Factor (via Holition Beauty tech) won a Webby award for in-browser AI and AR. This was used to scan a users face, analyse their features, advise them on what make up, etc, would suit them, after which the user can try it on. This would have been impossible without WebAssembly.
This tech is also used by another makeup brands beauty advisors (via WebRTC) to call a customer and in real-time advise them on their make up look, etc.
Is this tech necessary? Probably not, but it is a lot nicer than having to go to a store. Especially when we are all in lockdown :)
1) https://www.holitionbeauty.com/
2) https://winners.webbyawards.com/?_ga=2.215422039.1334936414....
I moved on from that a decade ago but it was a neat project at the time.
But I deployed my first integration of WASM about a month ago for PaperlessPost.com. It is a custom h264 video decoder that renders into a canvas that manages timing relative to other graphics layers over this video. This code works around a series of bugs we've found with the built in video player. It went smoothly enough that we are looking into a few other hot spots in our code that could also be improved with WASM.
One avenue for WASM might be simply polyfilling the features that are not consistently implemented across browsers.
Ten years ago I did the same but in Java and JOGL (before Apple banned OpenGL graphics within Java Applets embedded within a webpage). Was used for AR Watch try on within https://www.watchwarehouse.com and Ebay. The pain of Flash and Applets still wake me up at night.
I'm also building something very similar but with the ability for custom codecs (https://www.v-nova.com/ is very good). Probably the same issues too! Could I know more about your solution?
I think WebAssembly is more used than it appears, just difficult to see/tell.
A few years ago I actually tried integrating AR via WebAssembly with Amazon. We couldn't get the approval due to poor performance on Amazon fire devices (which have low end hardware). It is a shame but it is what it is.
What is disappointing/annoying is - as a CTO - it is near impossible to hire someone with WebAssembly skills. It requires an extra curious Engineer with a passion for native and web. Training is always important for a team but when going down the WebAssembly route you need to extra focused and invest more than what a typical Engineer would be allocated (E.g. Increase training from 1 day a week to 2-3). I suppose this may put people off?
I've been playing with WebAssembly lately and the moment where it clicked for me how powerful it was was building an in-browser crossword filler (https://crossword.paulbutler.org/). I didn't write a JS version for comparison, but a lot of the speed I got out of it was from doing zero memory allocation during the backtracking process. No matter how good JS optimization gets, that sort of control is out of the question.
I also think being able to target the browser from something other than JS is a big win. 4-5 years is a long time for JS, but not a long time for language tooling; I feel like we're just getting started here.
One thing I haven't heard much about is the packaging of wasm runtimes. For example, instead of including all of the .net runtime as scripts that need to be downloaded, we could have canonical releases of major libraries pre-installed in our browsers, and could even have the browser have pre-warmed runtimes ready to execute, in theory. So if we wanted to have a really fast startup time for .net, my browser could transparently cache a runtime. Basically like CDN references to JS files, but for entire language runtimes.
This would obviate the need for browsers to natively support language runtimes. It's conceptually a way to get back to something like Flash or SilverLight but with a super simple fallback that doesn't require any plugin to be installed.
I'm cautiously optimistic about blazor, it definitely makes streaming data to the Dom much easier
People are already whining about JS bundle size and even the small .net runtimes are >60kb.
Yew on the other hand seems to fit right into what WebAssembly was made for.
It is the first time you can develop a full stack application (client and backend) in one language in one debugging session. For C# that was possible with Silverlight.
Small companies (like mine) that deliver applications and have full stack engineers can have some amazing productivity!
So for my needs I'm really excited with something like Blazor, and this was only the first release.
I just don't think it's a good idea in general.
I remember being really excited at the concept. Of /course/ we needed Java co-processors!
That's a pretty big difference.
Also, a lot of computer use is via mobile these days and I doubt too many people are using the web interface on mobile for gmail.
And point about conversations moving to post-email protocols, but email is certainly still up there with HTTP as a bedrock standard that everyone eventually touches.
Without pushing JavaScript and a full featured web client, it's fair to say Google wouldn't have grown as quickly and be nearly as dominant today.
As for their move to full mobile app, I think it's a bit of a different calculation when you happen to own the OS that powers ~75% of all mobile phones [2]. ;)
Suffice to say, I don't think Google has the same troubles as other developers. (Exception to security policy, for my first party app? Sure!)
[1] https://www.statista.com/chart/17570/most-popular-email-clie...
[2] https://www.statista.com/topics/3778/mobile-operating-system...
Web Assembly is one of the more misunderstood technologies in terms of it's real, practical application.
At its core, it crunches numbers, in limited memory space. So this can provide some 'performance enhancements' possibly for running some kinds of algorithms. It means you can also write those in C/C++, or port them. Autodesk does this for some online viewers. This is actually a surprisingly narrow area of application and it still comes with a lot of complexity.
WA is a black box with no access to anything and how useful really is that?
Most of an app is drawing 'stuff' on the screen, storage, networking, user event management, fonts, image, videos - that's literally what apps are. The notion of adding 'black box for calculating stuff more quickly' is a major afterthought.
At the end of the day, JS keeps improving quite a lot and does pretty well, it might make more sense to have a variation of this that can be even more optimized than building something ground up.
WASI - the standard WA interface is a neat project, but I feel it may come along with some serious security headaches. Once you 'break out of the black box' ... well ... it's no longer a 'black box'.
WA will be a perennially interesting technology and maybe the best example of something that looks obviously useful but in reality isn't really. WA actually serves as a really great Product Manager's instructional example to articulate 'what things actually create value and why'.
It will be interesting to see how far we get with WASI.
For 5 years we've been hearing about how great they are, except nobody is really using them.
So now, it's 'the next thing' that will make it great? Except that next thing isn't there, not agreed upon or implemented, we don't know so many things about it?
Like I say, this is textbook example of tech-hype for things probably not as valuable as they appear.
If (huge if) WASI were 'great, functional, widespread, smoothly integrated' - I do agree there's more potential. But that this will really happen is questionable, and that even if it does happen, it will be valuable, is questionable.
JITs may approach native performance in theory - but the battery consumption and memory consumption are not very good. ("Better than JS" is a low bar).
As hardware becomes stronger, I would like to do more with it, and when it comes to portable devices, I want more battery life. Nothing justifies compiling same code again and again, or downloading pages again and again like "web apps" shit.
I understand where developer productivity argument comes from. But we can have both efficiency and developer productivity - it is a problem with webshit-grade stacks that are used today that you can't have both.
I personally think flutter model is future. You need not strive for "build once - run anywhere". You can write once and build anywhere a cross platform HLL and that's better.
As for sandboxing, maybe it is that your OS sucks (I say this as linux user); Android / iOS have sandboxing with native code. You shouldn't need to waste energy and RAM for security. IMO enforcing W^X along with permission based sandboxing is better than webassembly bullshit that is pushed.
And webassembly itself seems to be a rudimentary project with over ambitious goals. JS bridge being so slow and not having GC support ("To be designed" state) make it unusable for many purpose. Outside HN echo chamber, not many web people want to write in rust or even C++.
Without WebAssembly I wouldn't have been able to ship 2 products pro-bono within intensive care units and operating theatres directly helping with COVID.
I understand your dislike towards WebAssembly (albeit Web stack trends / flavour of the month esque development). I am not the largest fan of modern web development. Nevertheless love for WebAssembly is not due to developer productivity. After shipping 20+ WebAssembly products (alongside native counterparts) I am yet to meet an Engineer who enjoyed the WebAssembly/Emscripten/Blazor pipeline. However what WebAssembly has achieved for me is: Do people use your app? and within certain markets it allowed me to grow, do good, and say yes. This is the only real reason why someone should go down this route.
Wasm is like the JVM or CLR in that regard. It's not the future - it's the past.
Even if it were, there is an extremely high bar to meet for actual new ISAs/cores. There is no chance for Wasm to compete with RISC-V, Arm or x86.
Imagine if the crowd didn't fall for the HODL hypers and called these things cryptolotteries or something like that -- they are a betting game after all -- how ridiculous would it look to include them in every discussion like this.
If you read about the Baseline protocol (EY, Microsoft, SAP etc building neutral interconnections between consortiums), ENS/IPFS, or digital identity systems you might find something that interests you and is more relevant than the mindless hodl ancaps. It's actually a pretty exciting field to be in as a computer scientist with almost no end of boundary pushing experiments and cryptographic primitives to play with and build on top of.
It's interesting in a bunch of ways, and I think it might end up having a wider impact than anyone has really realized yet.
It's an ISA that looks set to be adopted in a pretty wide range of applications, web browsers, sandboxed and cross platform applications, embedded (into other programs) scripting, cryptocurrencies, and so on.
It looks like it's going to enable a wider variety of languages on the web, many more performant than the current ones. That's interesting on it's own, but not the main reason why I think the technology is interesting.
Both mobile devices, and crypto currencies, are places where hardware acceleration is a thing. If this is going to be a popular ISA in both of those, might we get chips whose native ISA is web assembly? Once we have hardware acceleration, do we see wasm chips running as CPUs someday in the not too distant future (CPU with an emphasis on Central)?
A lot of people seem excited about the potential for risc-v, and arm is gaining momentum against x86 to some extent, but to me wasm actually seems best placed to takeover as the dominant ISA.
Anyways, I doubt that thinking about this is going to have much direct impact on my life... this isn't something I feel any need to help along (or a change I feel the need to try and resist). It's just a technology that I think will be interesting to watch as the future unfolds.