Hacker News Reader

I want to believe... I always thought WebAssembly had a lot of potential, however, in practice it doesn't seem to have turned out that way.

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

An example I can give:

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

3) https://www.maxfactor.com/vmua/

I build a slower version of something with the same idea 13-14 years ago in Flash for http://www.makeoversolutions.com which most of these makeup companies licensed back then.

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.

I feel like I am looking in a mirror!

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?

This is really great work and exactly the kind of response I was hoping for - thank you. I wonder why tech like this is not being more widely used, for example on Amazon product pages. Especially with the well known reluctance as you mentioned of people downloading apps.

Thanks, much appreciated!

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'd love to see examples of what WebAssembly makes possible that wouldn't exist without it.

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.

Great work.. This is amazing! Thanks for sharing

This is brilliant, thank you!

I can tell you about a WebAssembly killer app for a small niche. lichess uses WebAssembly to run a state-of-the-art chess engine inside your browser to help you analyze games [1]. Anyone who wants to know what a super-human chess player thinks of their game can fire it up on their desktop, laptop, or even phone (not highly recommended, it's rough on your battery life).

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.

[1] https://lichess.org/analysis

I think chess.com has something similar too, but not sure if it's powered by wasm.

If it's not, I'd be interested to see a speed and feature comparison between the two.

I think there might be killer apps that companies aren't publicizing, because it's part of their competitive advantage.

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.

Agreed - Figma is a very good example. I stand corrected.

Adobe XD uses some Wasm also.

I read that a few days ago and just realized why Figma runs better than Miro/RealTimeBoard. I wish the Miro team is also looking to port to WASM/boost performance. I don't think it's easy though; Figma's effort started in 2017.

If you’re looking for a real world example of Webassembly being used in production at a large scale for performance gains, check out Figma. Their editor is all wasm based, and is really their secret sauce.

Thank you! I just checked them out, and I stand corrected. Really an excellent design tool and very responsive. I see now that for certain applications WASM is indeed the right tool for the job.

Speedy client-side coordinate conversion in geospatial apps, thus avoiding the round-trip to the server.

I agree! WASM is very interesting. Blazor is an exciting example of an application of Web Assembly - it's starting out as .net in the browser, but you can imagine a lightweight wasm version of the .net runtime could be used in a lot of places as a sandboxed runtime. The main .net runtime is not really meant to run unprivileged. It would be more like the UWP concept that MS made to sandbox apps for the windows App Store, but applicable to all OSes.

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 look forward to in browser DLL hell /s

I'm cautiously optimistic about blazor, it definitely makes streaming data to the Dom much easier

Blazor seems like the only one application of WASM at the moment that goes in the completely wrong direction.

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.

The download size does make it hard to use for a "public" site, like a webshop. But it is a different story for an application, like an intranet solution or app like Figma. A first time download of a few MB's is not a problem, as you regularly use it. Like a desktop application.

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 understand the appeal for .net devs.

I just don't think it's a good idea in general.

For every person whining about 60k JS there are 10 creating 10MB web app.

Cautionary tale: we’ve been here before with JVM CPUs like Jazelle. They didn’t take over the world.

Absolutely, but there's been plenty of technologies where the time wasn't right the first time around, but it was the second, or third, or fourth.

Even closer to home. Palm, RIM, Microsoft, Apple and Google have all said at one point that web apps were the answer for mobile apps....

I mean, modern Google was half-built on the back of the Gmail web app...

Gmail was introduced after Google was already popular. The Google home page’s claim to fame was always its simplicity and fast load time.

To an average user, Google in 2003 was a search page. In 2004+, it was essential internet infrastructure.

That's a pretty big difference.

Gmail is popular but in the grand scheme of things it’s not that popular for email. I’m sure that most people get most of their utility from email from their corporate email. Their personal email is mostly used for distant relationship type communications. Most personal interactions these days happen via messaging and social media. AKA “Email is for old people”.

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.

It's pretty popular for email, at 25%+ market share [1]. That's a LOT of information to mine.

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

The question is not about how many people use Gmail - and that still doesn’t take into account corporate users. It’s about how many people use the web interface as opposed to using a mobile app.

Yes. And we're both clear that there wasn't always a mobile app version of Gmail, right?

To say that Gmail had much to do with Google’s growth considering that there was only a relatively small Window that email was the most popular form of personal (not corporate communication and spam) and that was over ten years ago before mobile started taking over doesn’t really have any basis in today’s reality.

See https://vintageapple.org/byte/ and search on the page for "Java chips" or download the PDF directly at https://vintageapple.org/byte/pdf/199611_Byte_Magazine_Vol_2...

I remember being really excited at the concept. Of /course/ we needed Java co-processors!

True, just like we were here before with devices like the Palm Pilot and Apple Newton, which is why the iPhone and IPad never took over the world ;)

I'd argue somewhat the opposite. Because WebAssembly is abstract but low level, it makes it really easy for a platform to optimize specifically for that platform, so instead of creating a need for specific platforms, it'll allow more diverse systems to run the same "native" blobs.

That potentiality has been there for many many years, I don't see 'the thing' that provides the critical mass necessary to make it work in reality.

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.

I think you're underestimating WASI. Projects like cloudABI, where an existing app is compiled against a libc with strong sandboxing, really cool things happen.

Thanks but the same thing was said about WASM and ASM.JS.

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.

I don't like to see wasm replacing native for stuff like development tooling, and desktop apps.

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

> I don't like to see wasm replacing native for stuff like development tooling, and desktop apps.

Wasm is like the JVM or CLR in that regard. It's not the future - it's the past.

Yes. Even if there were a number of dominant architectures, install-time compilation would be better than run-time compilation for frequently used software. The RAM and Energy overhead isn't just worth it.

When dealing with Health or Military systems installing or updating a native application could result in months of delays (e.g. quarterly OS image update cycles). However running within Chrome, Firefox, and other typical software preinstalled, this becomes <days for implementation.

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 was not designed to be a hardware accelerated ISA. It was designed as an IL/bytecode target like JVM and .NET.

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.

Aaah so we have come full circle from Java applets.

> 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,

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.

What are you adding to the discussion? This is a technical forum, the least you could do is comment on the use of Web Assembly in Ethereum or maybe anything of substance. There's a bunch of technically interesting topics to bring up but somehow I doubt you know anything about them.

I speak up against cryptocurrency because it's a cancer. It's a hype adding to climate change without any real world use case whatsoever.

Have you looked deeper than just hodl memes and Bitcoin? Ethereum is a highly technical project that doesn't really care about money and lots of people here on Hacker News find interesting topics regarding it. Web Assembly will be the base programming platform for example, which is one of the reasons he included it.

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.

Most new cryptocurrencies are moving away from PoW because a.) it's a massive waste of electricity and b.) it's not actually secure anyway, because we've seen a consolidation of mining power with major ASIC customers who have cheap power costs (notably in China). Ethereum's moving to it in 2020 or 2021, and EOS, Stellar, Tezos, Cardano, etc. are already PoS or derivatives.

Have the security issues with PoS been worked out yet?

Thank you for your input, but thus is not TechCrunch. We understand the problems with PoW, and we also know that a lot of interesting research is being done on top of Ethereum. For your reference, Ethereum is moving away from PoW.