[HN Gopher] The State of WebAssembly 2022
___________________________________________________________________
The State of WebAssembly 2022
Author : ColinEberhardt
Score : 127 points
Date : 2022-06-20 09:42 UTC (13 hours ago)
(HTM) web link (blog.scottlogic.com)
(TXT) w3m dump (blog.scottlogic.com)
| trusktr wrote:
| > I do wonder whether some respondents are incorrectly
| identifying AssemblyScript as JavaScript?
|
| Perhaps we should include HTML and CSS in the list of languages
| to choose from next year! :P
|
| I picked JavaScript thinking of AssemblyScript as a tool (not a
| language) to use JavaScript (with types) as a language compiled
| to WebAssembly. Maybe the results are not accurate.
|
| I also use Wasm for web (the largest category of use so far) and
| would not use a JavaScript engine inside Wasm to talk to plain
| JavaScript in a browser (I don't think any web developer would
| hehe).
|
| Perhaps the survey should have an option to choose
|
| "JavaScript running in a JavaScript engine inside WebAssembly",
|
| and
|
| "JavaScript compiled to WebAssembly",
|
| to make the results clear as to which "JavaScript" people are
| using.
|
| Does a JavaScript engine inside WebAssembly even count as a
| "WebAssembly language"? Or is that C++ and Rust actually?
|
| Does running a browser in WebAssembly make HTML and CSS
| WebAssembly languages too?
|
| I think that NEAR users just use the SDK, I don't think the users
| chose JS specifically for it to be in Wasm.
| AlbertoGP wrote:
| WebAssembly is great as a developer, but it's bothering me as a
| user that some websites require it for what looks to me like
| basic functionality.
|
| The last one to bite me is Linode's login: I can't even login to
| my account to adjust a DNS setting without WebAssembly. That's a
| problem because the browser I use, Firefox on PowerPC 64 (a
| current production CPU, not an old Mac) does not support it.
|
| Yes, I can and have found workarounds, and I do have a variety of
| machines around that include AMD64 CPUs. It's still an annoyance
| for no good reason that I can see.
|
| As for the linked article, I'm not surprised to see Rust rising
| there because in some quick tests I did, everything worked as
| advertised with minimal friction.
| timw4mail wrote:
| Unfortunately that kind of (now) obscure platform is unlikely
| to get great support from web browsers in general.
| sp332 wrote:
| This is really basic functionality though. It could
| gracefully degrade to an HTML form.
| babypuncher wrote:
| It could, but it is a bit of a stretch for your average web
| developer to
|
| 1: Know that webassembly does not work on the PPC version
| of Firefox.
|
| 2: Have access to a PPC machine for testing in 2022.
|
| It is an unfortunate but exceptionally rare edge case that
| few websites will ever actually encounter.
| watersb wrote:
| I disagree. Bog-standard functionality like a login form
| _on a web based service_ should at the very least have a
| version that uses HTML.
|
| _(I wrote a web app in 1998, pushed the team to adopt
| shiny new HTML 4.0 and Java, but all the front end was
| data validation that was replicated on the back end
| anyway. In retrospect it was a lousy way to develop the
| system - I started with fancy and worked my way down, ass
| backwards that blew the dev budget - but at least the
| damn thing had a layer of fail-safe server that worked
| (handled errors and notifications) no matter what you
| threw at it.)_
|
| _I 'm writing this on an ancient iPad with JavaScript
| disabled. This is a text site. It works._
| woojoo666 wrote:
| Tons of websites don't have html fallbacks for the small
| userbase that disables javascript. You'd be hard pressed
| to convince them to support html fallbacks for what I
| assume is an even smaller userbase (PowerPC)
| babypuncher wrote:
| If you are building an app that requires Javascript in
| order to do what the customer wants, then having the
| login form also use Javascript does not seem like a
| problem to me. Building an HTML-only fallback that
| successfully logs the user in but takes them to a page
| that does nothing without Javascript seems like a waste
| of resources.
| heinrich5991 wrote:
| Huh, TIL. There's no C interpreter fallback for WebAssembly in
| Firefox that works on all platforms?
| AlbertoGP wrote:
| It seems that WebAssembly support requires the JavaScript JIT
| (Just-In-Time) compiler:
|
| > " _Unfortunately I have not had time to do much more work
| on the JIT because of the holidays, family responsibilities
| and $DAYJOB. I won 't be offended at all if someone beats me
| to the punch especially as I'm starting to see WebAssembly
| becoming a hard dependency even for some add-ons (without the
| JIT there is no support for wasm)._"
|
| > https://www.talospace.com/2019/12/firefox-71-on-power.html
|
| That's from December 2019. As of 2022-05-31, there has been
| some progress but it's still not working:
|
| > " _I can 't figure out where the bugs are in our POWER9 Ion
| JavaScript JIT implementation, though I still strongly
| suspect it's because we use sign-extended 32-bit ints. This
| is enough to pass the test suite but still breaks with the
| web. MIPS does too and we are strongly based on the MIPS
| port, but one wonders if MIPS suffers from the same issues,
| and I'm quite sure it's not tested anywhere near as well. As
| 32-bit arithmetic instructions aren't orthogonal in Power ISA
| this change would require some significant rearchitecting and
| I've just come off a really bad week at work, so I'll just
| try to pull up the current JIT to 102 so that those of you
| building the new ESR can continue to use Baseline Interpreter
| and Baseline Compiler, and then it will be time for more
| major surgery on the source code. You can help (please!)._"
|
| > https://www.talospace.com/2022/05/firefox-101-on-power.html
|
| Looks like it's not that simple.
| buu700 wrote:
| This seems really odd to me. If it's possible to convert
| wasm to C[1], then it should be possible to convert wasm to
| asm.js and just execute that. That may not be ideal, but
| surely it's a better stopgap solution than letting the
| happy path fail for years on end.
|
| 1: https://github.com/WebAssembly/wabt/tree/main/wasm2c
| flohofwoe wrote:
| Emscripten can still compile to asm.js (which is a subset of
| Javascript), and this can be used as fallback path on ancient
| browsers. But without special asm.js support the performance
| cost will be very high. Of course the actual question is: why
| does a login form need to load a WASM blob.
| Mertax wrote:
| Blazor/dotnet is the framework using WASM. C# is the language.
| ColinEberhardt wrote:
| Very good point, I'll fix that for next year's survey.
| Fortunately for people working with WebAssembly those two terms
| are synonymous, so this will not effect the results.
| azakai wrote:
| Btw, while you're here, another suggestion: Perhaps include
| Node.js as a runtime option? It's not a pure wasm VM,
| obviously, but it may be a common way to run wasm on the
| server simply because npm packages can include wasm. (OTOH,
| users of such packages might not even know they're using
| wasm...)
| jkbbwr wrote:
| Without interface types to unify passing strings around or more
| complex handles to resources. WASM is going to be rough on the
| serverside.
|
| I still have not found a consistent way to construct a sqlite
| connection, pass it to wasm (language agnostic) and then return
| and close it.
| trusktr wrote:
| You can do that with bindings currently. Interface types should
| only make it easier (for languages with utf-8 strings, as
| interface types does not support WTF-16 strings like in Java or
| JavaScript yet).
| bluejekyll wrote:
| Interface types appear to continue to be making progress:
| https://github.com/WebAssembly/interface-types
| Jasper_ wrote:
| From your link:
|
| > Note: This proposal is currently inactive, with work having
| moved on to the component-model repo.
|
| This is never getting done, is it... this is the fourth
| rewrite of such a feature.
| pyrolistical wrote:
| Don't be so dismayed. I've been following the progress and
| the move was a good one. It allows them to ship the thing
| most people care about.
|
| These things take time. If all else fails just write a
| polyfill. Component model doesn't add anything new runtime
| requirements that can't be polyfilled
| sceptically wrote:
| Where is the .NET / C# in the data? :(
| pjmlp wrote:
| Packed under Blazor.
| dustingetz wrote:
| 1. what's the functional programming story - immutable data
| structures, garbage collection?
|
| 2. WASM's best use seems to be to cross-compile C++ GUI apps in a
| browser (like Unity engine). Ok, but it's not platform native, so
| will this feel like weird Java desktop GUIs all over again? The
| best apps are native
|
| 3. Web apps are I/O bound. How does wasm help?
| pjmlp wrote:
| Thanks to WebGL, all plugins are back, that is how WASM helps.
|
| Have a look at Grain for a ML like language with GC runtime.
| dustingetz wrote:
| Javascript already has WebGL? What is wasm adding
| dgb23 wrote:
| A smaller, lower level target than JS. In a sense the
| better question is "what does it remove".
| remexre wrote:
| See this subthread:
| https://news.ycombinator.com/item?id=31810249
| int_19h wrote:
| wasm is a low-level architecture - it gives you a linear heap
| to play with however you want. If you want immutable data
| structures and GC on top of that, you can certainly do that, in
| the same exact way we do it on other platforms.
|
| The weird Java desktop GUIs were weird not because they weren't
| native code, but because the standard Java UI didn't use native
| UI APIs, nor did it even try to at least look native (as e.g.
| Qt does). But, just as there are native UI libraries for Java,
| there could be the same for wasm. It's just too early to tell,
| given how immature the whole wasm-outside-of-browser story is
| in general.
| azangru wrote:
| What is a use case for running a javascript vm in webassembly?
| Why not run javascript in the browser itself? Is it for server-
| side webassembly stuff?
| simonw wrote:
| Yeah, my interest in this is for server-side purposes. I can
| imagine wanting to build a feature that allows users of my web
| application to write and execute their own custom code - think
| triggers and hooks for custom logic.
|
| If they're creating code that will run on my servers I need to
| have an EXTREMELY reliable sandbox around it - I see
| WebAssembly as providing the best possible option for that
| these days.
|
| Letting them write their customizations in JavaScript which I
| then execute in a JavaScript interpereter inside a WebAssembly
| container sounds like a pretty good option.
| jeffparsons wrote:
| You can "pre-initialise" the JavaScript VM so that your
| JavaScript code starts much faster at the cost of some small
| ongoing performance penalty.
|
| I think the main use case is "serverless" or "edge compute"
| where start-up time is often hugely important.
| goatlover wrote:
| Why not just use a language that's better suited for
| serveless or edge computing? Why is JS the hammer to every
| programming nail? Aren't programmers supposed to be able to
| learn and use multiple languages, depending on best use case?
| lisper wrote:
| > JavaScript cannot be compiled to WebAssembly
|
| Wait, what? Why? Is WASM not Turing-complete?
| sunfish wrote:
| Wasm is Turing-complete. What people typically mean by this is
| that in a browser context, compiling JS to Wasm does not
| currently make it run faster than just running the JS as JS.
|
| Javascript _can_ be compiled to WebAssembly, and there are
| people doing it:
|
| https://bytecodealliance.org/articles/making-javascript-run-...
| AndrewDucker wrote:
| It would need a JavaScript interpreter to go with it.
| goatlover wrote:
| You need a runtime like the browser or Node in WebAssembly. I
| suppose you could write one in Rust and then compile it to
| wasm. But then what do you gain by doing this?
| syrusakbary wrote:
| Props to Colin on the survey. It's always super useful to have
| more insights on where the market is going.
|
| I'm super happy to learn that Wasmer (https://wasmer.io) is the
| most popular runtime (regarding most people having heard of it).
| But I would like to cheer all the other runtimes for their
| awesome work, it's always good for the ecosystem to have a
| healthy amount of competition on the runtime space :)
| martin_drapeau wrote:
| Can someone point out a known web page/service that uses
| WebAssembly?
| capableweb wrote:
| Figma is probably the biggest web application that uses it for
| the main feature they offer (the entire in-browser editor is
| C++ compiled to Wasm).
|
| You can read more about how they use it here:
| https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
|
| > Because our product is written in C++, which can easily be
| compiled into WebAssembly, Figma is a perfect demonstration of
| this new format's power. If you haven't used Figma before, it's
| a browser-based interface design tool with a powerful 2D WebGL
| rendering engine that supports very large documents.
| martin_drapeau wrote:
| Ok, this is a great example. I will check that out!
| Extigy wrote:
| You can run Python directly in the browser via Pyodide:
| https://pyodide.org/en/stable/
| m00dy wrote:
| well, I have just implemented webgpu support for Pyodide ;).
| Soon, we will able to train neural nets right in the browser
| :). So, right now I'm working a very minimal grad based nn
| framework
| nonima wrote:
| How do I know it's running in the browser?
| azakai wrote:
| Whenever you use Zoom or Meet in a browser you're using
| WebAssembly. Lots of other sites do too, but you just need to
| open the devtools to notice it.
|
| Other big examples: Unity games, Photoshop, Figma, Google
| Earth, etc.
| astlouis44 wrote:
| Unreal Engine games on the web soon as well :)
|
| https://venturebeat.com/2022/05/12/wonder-interactives-
| the-i...
| jphilip wrote:
| Mozilla uses WebAssembly in it's offline translation extension.
| Here's a web-page demonstrating the same stuff:
|
| - https://mozilla.github.io/translate/
|
| These are neural models that are compressed and optimized to
| run on user's CPU. I write some of the code which repurposes
| the underlying (C++) library for extension's needs, all of
| which gets compiled via emscripten to WebAssembly for use in
| the browser.
|
| Previous discussion on HN:
| https://news.ycombinator.com/item?id=31596888
| pjmlp wrote:
| Adobe Photoshop and Autodesk for example.
| meheleventyone wrote:
| Google Meet uses it for a bunch of processing.
|
| Figma uses it.
|
| We're using it right now to drive a new physics integration.
| neriymus wrote:
| Just curious what your thought are regarding this
| (https://zaplib.com/docs/blog_post_mortem.html) if you have
| seen it. Does implementing a physics engine in Rust and
| complied in wasm provide you guys with quite a big
| performance boost? Asking because I've considered doing so
| for my team, but have reservations about the performance
| increase.
| meheleventyone wrote:
| We're not implementing in Rust but taking an existing piece
| of middleware (Bullet) and using it. Performance wise it'd
| be an apples to oranges comparison but our general
| understanding from benchmarks, our own personal experiments
| and blogs like the one you posted there is not to expect
| miracles but more consistency and less footguns (e.g.
| megamorphic behaviour).
|
| This is another good summary:
| https://ianjk.com/webassembly-vs-javascript/
|
| I would say there is hope when SIMD is supported across
| major browsers if your workload will make use of it. Just
| waiting on Safari. And there might well be more performance
| to eek out of the JIT compilation.
| neriymus wrote:
| Thanks! This was useful
| m00dy wrote:
| it looks like most developers not interested in mem64 feature. I
| can't really understand this thing.
|
| Ladies, Gentlemen and all non binaries, current vm runtimes have
| 32 bit adressing and therefore you can have at most 4gb memory
| for your webasm application. I think it should be top priority to
| make it 64bit
| recursive wrote:
| Top? Not sure about that. You can do a lot of things (most, I'd
| say) with far less than 4gb.
| jcelerier wrote:
| This kills me aha, I bought a computer with 16gb of ram in
| 2011, started getting OOMs in 2014/2015. My laptop has 32
| gigs and desktop 64 and I still have the occasional OOM in
| media creation work (and no doubt I'd have the same editing a
| large 3D scene, making a detailed part in a CAD software,
| editing a detailed SVG or 8k image with 35 layers, running a
| complex electronics simulation... All the things that people
| buy computers for lol)
| recursive wrote:
| Tool for the job. I think there are probably reasons why
| editing a large 3d scene or doing detailed CAD work are
| probably best done outside of a wasm VM.
| remexre wrote:
| It would also be kind of nice if web developers knew they
| couldn't use more than 4GiB per tab, so didn't even try to
| get close :P
| abeyer wrote:
| > so didn't even try to get close
|
| That would imply they weren't _already_ trying.
| mikewarot wrote:
| As long as they don't let WebAssembly have raw access to the host
| filesystem, they'll do well. "No access" is the best access
| choice for the default.
|
| As adoption ramps up, the pressure to make filesystem access
| "easier" will increase. I just hope they hold it off, as
| isolation is the key feature of the platform.
| capableweb wrote:
| > As long as they don't let WebAssembly have raw access to the
| host filesystem, they'll do well. "No access" is the best
| access choice for the default.
|
| Not sure where this worry even comes from? Browsers have never
| let anything (not even JS) have raw access to the host FS, so
| not sure why Wasm would be different.
|
| Edit: Ah, I realize now you might be thinking about running
| Wasm outside of browsers, via some other runtime. If so, I'd
| understand the concern as most desktop technologies allow
| unfettered access to FS and more.
| mikewarot wrote:
| Browsers have never _intentionally_ let anything outside the
| filesystem, the site the page is loaded from, etc... there
| are always escapes.
|
| The design of the WASM vm seems to preclude escapes, unless
| people get sloppy and make ladders that can be climbed out
| of. That's where my concern comes from.
| russtrotter wrote:
| Technologies like WASI are coming on right now to do exactly
| this kind of access in the context of a sandbox. From what I
| can tell, they're going through a lot of the same progression
| of JVM and .NET IL back in the 90's and early 2k's but for
| whatever reason seem to be more openly embraced in all the
| places where WASM is gaining a foothold.
|
| I'm just keeping my fingers crossed that this one sticks .. oh
| and, please make WASM run in a browser without JS :)
| nindalf wrote:
| Some of the folks developing wasmtime plan to run it as a
| server environment where any users can submit code to be run.
| They are very incentivised in making sure the sandbox can't be
| broken.
| tormeh wrote:
| I wish I could somehow ship a website as a single wasm file.
| Currently there's quite a bit of HTML/JS ceremony involved in
| order to execute a wasm file, but I'd rather be able to serve up
| an "index.wasm" and be done with it. Is there any movement
| towards this?
| sitkack wrote:
| The ceremony is a one time thing, and the boilerplate is a copy
| and paste away. You _can_ pretty easily ship an entire
| application as an self contained html file.
| singularity2001 wrote:
| yes, <src module="main.wasm"/> is under consideration. Maybe
| you need a tiny wasm_dom.js but direct DOM manipulation is in
| the pipeline too.
___________________________________________________________________
(page generated 2022-06-20 23:01 UTC)