WebAssembly 2023 Survey Finds Enthusiasm - and Some Challenges (infoworld.com) 34
An anonymous reader shared this report from InfoWorld:
The uses of WebAssembly, aka Wasm, have grown far beyond its initial target of web applications, according to The State of WebAssembly 2023 report. But some developers remain skeptical.
Released September 6 by the Cloud Native Computing Foundation (CNCF) and SlashData, in collaboration with the Linux Foundation, the report finds mostly optimism among software developers about future adoption of Wasm for web and non-web environments... However, about 22% of participants in the report indicated pessimism about Wasm adoption for either the web or non-web environments. Further, 83% of the respondents reported challenges with Wasm including difficulties with debugging and troubleshooting, different performance between runtimes, lack of consistent developer experiences between runtimes, lack of learning materials, and compatibility issues with certain browsers.
The report finds that respondents are using WebAssembly across a wide range of software projects including data visualization (35%), internet of things (32%, artificial intelligence (30%), games (28%), back-end services (27%), edge computing (25%), and more. While Wasm is still primarily used to develop web applications (58%), this is changing thanks to WASI (WebAssembly System Interface), which provides a modular interface for Wasm...
Other findings of the State of WebAssembly 2023 report:
- When migrating existing applications to Wasm, 30% of respondents experience performance benefits of more than 50%.
- JavaScript is the most popular language used with Wasm applications. But Rust stands out in popularity in Wasm projects compared to other use cases...
The article says WebAssembly developers were attracted by "faster loading times, the ability to explore new use cases and technologies, and the ability to share code between projects. Improved performance over JavaScript and efficient execution of computationally intensive tasks also were cited."
The report finds that respondents are using WebAssembly across a wide range of software projects including data visualization (35%), internet of things (32%, artificial intelligence (30%), games (28%), back-end services (27%), edge computing (25%), and more. While Wasm is still primarily used to develop web applications (58%), this is changing thanks to WASI (WebAssembly System Interface), which provides a modular interface for Wasm...
Other findings of the State of WebAssembly 2023 report:
- When migrating existing applications to Wasm, 30% of respondents experience performance benefits of more than 50%.
- JavaScript is the most popular language used with Wasm applications. But Rust stands out in popularity in Wasm projects compared to other use cases...
The article says WebAssembly developers were attracted by "faster loading times, the ability to explore new use cases and technologies, and the ability to share code between projects. Improved performance over JavaScript and efficient execution of computationally intensive tasks also were cited."
I have questions (Score:1)
When migrating existing applications to Wasm, 30% of respondents experience performance benefits of more than 50%
What did the other 70% report?
JavaScript is the most popular language used with Wasm applications. But Rust stands out in popularity in Wasm projects compared to other use cases...
What kind of godforsaken garbage were they using if using Javascript, of all languages, results in a 50% performance gain?
Re: (Score:3, Informative)
JavaScript is the most popular language used with Wasm applications. But Rust stands out in popularity in Wasm projects compared to other use cases...
What kind of godforsaken garbage were they using if using Javascript, of all languages, results in a 50% performance gain?
This is most likely incompetent journalism.
JavaScript is the glue language used to communicate between the Wasm binary and the browser. So most likely that's what TFA means when they say "using JavaScript".
But using JavaScript as the language for the binary makes little sense. The main benefit of WebAssembly is avoiding JavaScript and using "real" languages like C++ or Rust for web programming.
Re: (Score:1)
Yes, it's incompetent journalism.
Competent journalism would have reeled off the long list of previous attempts to have a "write once, run anywhere" abstraction layer for the web -- and where they all ended up.
Re: (Score:3)
The main benefit of WebAssembly is avoiding JavaScript and using "real" languages like C++ or Rust for web programming.
The main benefit seems to be performance, I browsed around a bit and it seems like even naive reimplementations of existing functionality achieve 10x improvement over using javascript. You could use Assemblyscript, which is modeled on Typescript, etc., to avoid having to know a more different language to gain some performance benefit from WASM.
Re: (Score:3)
Javascript can be compiled to WebAssembly. The advantage is that the browser doesn't have to compile the code itself. It also makes reverse engineering the Javascript source more difficult, as pure Javascript can only be obfuscated.
Re: (Score:1)
Don't try to gain any security by obscurity. If a computer can read it, I can read it. And I'm not that special that this is only me, so if a computer can read it, it can be read by sufficiently enough humans that you do not gain any security by trying to obscure it that way.
A binary is by no means any better at hiding a security flaw than obfuscated Javascript. As far as I'm concerned, it's worse. Mostly because i hate taking Javascript apart, at least compared to digging through a disassembly.
Re: (Score:2)
Don't try to gain any security by obscurity.
Reverse engineering and security are two different things.
Obfusticating your program doesn't make it more secure, but does make it harder to reverse engineer.
Re: (Score:2)
Not really.
In security, I'm not interested in making the program work without copy protection. I have no interest in "ripping" it. All I'm interested in is digging out the nugget of information that I need. That's usually as easy as hitting the brakes at the right moment and reading the right address in ram. No matter how you try to obfuscate some secret, at some point in the code, your program needs access to it, usually right before a telltale API call.
All obfuscation does in such a case is to make the pr
Re: (Score:2)
All obfuscation does in such a case is to make the program run slower.
In the case of WebAssembly, obfuscation means compiling source code to a binary.
That doesn't make it run slower, it makes it run faster.
If you really believe you can understand code just as easily by looking at a binary as the source code, then I don't know what to say.
Re: (Score:2)
If you really believe you can understand code just as easily by looking at a binary as the source code...
Actually, no, I don't believe that. I know that. That's my job. A binary is, in the end, a list of assembly instructions and data. At least in an x86 environment (it's slightly different in others). That can be read. It has to be, because that's what a computer does with it. If it cannot be read, it cannot be executed.
I found it slightly curious that to a lot of people this seems incomprehensible. A binary is by no means more difficult to read than the source code used to create (ok, not necessarily when de
Re: (Score:2)
Jop. Basically nice for malware where analysis time is critical, does not help at all for other uses. So why is this a good thing?
Re: (Score:3)
Web apps load faster, use less battery.
Re: (Score:2)
As a result of reverse-engineering being made harder? I doubt that very much. Or was your claim that compiled languages are significantly harder to reverse-engineer without additional measures? Because that is not so much the case anymore. Modern decompilers can make stuff easier to read than the original source. Not that that makes it "easy". Code analysis is always hard, but a regular compile-step does not do much.
Yeah I'm sure it's all swell... (Score:1)
JIT isn't always good enough (Score:2)
No, JIT recompilation of a language with full dynamic semantics like that of JavaScript turned out not to be good enough for things like CPU-intensive signal processing. That's the whole reason why WebAssembly was invented.
They eschewed support for code signing (Score:2)
Re: They eschewed support for code signing (Score:2)
Wasm is not as risky as JavaScript. Wasm can only act, by itself, in an offline capacity. JavaScript is allowed to talk to the network, wasm is not.
Re: (Score:2)
What it comes down to is code-signing would enable author cherry-picking which would in turn make it very hard for advertisers to run code in browsers
In practice, author cherry-picking has tended to discriminate against hobbyist and startup developers more than against providers of ad tech. Look at video game consoles, for instance: console makers aren't willing to sell you a devkit unless your company already has a profitable commercial game for Microsoft Windows.
The main benefit of wasm (Score:1)
Re: (Score:1)
What UI platform do you use? Bootstrap? React?
Re: (Score:2)
> What UI platform do you use? Bootstrap? React?
React is a JS framework. Blazor is a C# based framework for the same thing.
With React you code in JavaScript or TypeScript. The templating "language" is JSX or TSX. With Blazor you code in C# (or another .NET language) and the templating "language" is Razor.
You don't need to use JavaScript with Blazor. You use C# which compiled to WebAssembly instead.
With Blazor (like React) you produce HTML and CSS. It is not tied to any specific design system. You can use
Re: (Score:1)
> You don't need to use JavaScript with Blazor. You use C# which compiled to WebAssembly instead.
To get desktop-like behavior, one generally has to use JavaScript somewhere. HTML and CSS are too limited. Maybe I'm not understanding something.
I disabled WebAssembly in Firefox (Score:2)
Following these instructions [github.com]. I figure it's likely the majority of WASM usage is going to be for purposes I don't want - advertising to me, tracking me, etc. etc. - it's basically the new Flash, from an end-user point of view.
All these developers may be excited about it, but I can't say disabling it has had any deleterious impact that I'm aware of.
It's possible it might still be showing up in phone apps, but at least there the developer has to make some sort of declaration regarding what data they claim to
The new Java Applets? (Score:3)
WASM shouldn't be available to every site by default. Have the browser ask, and not in the annoying way the locator does. Borrow IE's idea of a thin yellow permission bar at the top that doesn't block content. (Yes, IE got something right, who knew.)
Re: (Score:2)
IE got something right, who knew
If Microsoft were going to get something right, it would be UI. Of course, they would still be more likely to get it wrong if you were placing a bet.
Re: (Score:2)
You can't really disable WASM without also disabling Javascript. WASM actually grew out of asm.js, i.e. the initial implementation was in Javascript. Today if your browser doesn't support WASM the site will try to load a Javascript VM to run it in.
I suppose they could detect the Javascript as well, but that's a bit of a janky solution. The real fix is to make the WASM execution more secure. For example, Chrome aggressively throttles it if the user is not interacting with the website, so things like crypto m
Re: (Score:1)
> Today if your browser doesn't support WASM the site will try to load a Javascript VM to run it in.
If the user doesn't approve that, the browser shouldn't try that.
> The real fix is to make the WASM execution more secure.
So, we're fucked.
Re: (Score:2)
You should see faster page load times now that you've disbled WASM. Most toolchains produce really bloated binaries, and behave of how Wasm works there is a significant amount of javascript necessary to instantiate a wasm module. It's like you have to write your own linker every time. If you use a library supported by your toolchain then someone already wrote these stubs, they tend to be very complete rather than small.
The argument in favor of Wasm is if you visit the same site frequently and need a web-bas
Re: (Score:2)
I expect there's a way with uBlock Origin, NoScript, or something similar to allow WASM on a site by site basis; but to this point I haven't needed to do that - so I haven't bothered to check (yet).
Re: (Score:2)
WebAssembly is just a fancy form of Javascript. It's binary yes, but it's just tokenizing the key blocks. It was originally built on Javascript as a low overhead interpreter - using only the fastest parts of Javascript to run code fast.
If you don't want to run Wasm, you can block it by disabling Javascript on the
Re: (Score:2)
blocking JavaScript fixes several ills. Although it breaks slashdot's mobile site. so you have to use the desktop site on your phone, and the layout sucks on a phone. Still better than letting JS shenanigans onto your devices.
Enthusiasm and ... (Score:3)
I enthusiastically disabled WebAssembly and didn't find that challenging.