The strength—and also the weakness—lies in how WASM is consumed in the browser. During instantiation, JavaScript engines validate the module and reject it if it uses unsupported instructions or features. In practice, due to browser compatibility differences, WASM modules often need to be built in multiple variants, such as a baseline version, a SIMD version, a SIMD+threads version, and so on. This is a significant pain compared to native binaries, which can rely on runtime feature detection and dynamic dispatch.
Making WebAssembly a first-class language on the Web
131–140 of 287 posts
Re: Making WebAssembly a first-class language on the Web
#132If you’d like to get acquainted with modern WebAssembly, check out the component model book:
https://component-model.bytecodealliance.org/
It includes high level concepts, practical code samples and more that introduce the really powerful parts of WebAssembly.
With regards to the JS ecosystem specifically there are 3 projects to know:
https://github.com/bytecodealliance/StarlingMonkey
https://github.com/bytecodealliance/ComponentizeJS
https://github.com/bytecodealliance/jco
The most mature tool chain right now is Rust, but there is good support for most things with LLVM underneath (C/C++ via clang). Golang, python and support for other languages is getting better and better (tinygo and big go) and there’s even more to come.
One of the goals of WebAssembly is to melt right into your local $TOOLCHAIN as a compilation target, and we are getting closer every week.
Re: Making WebAssembly a first-class language on the Web
#133Earlier quoted context omitted.
I'd rather deal with an obfuscated WASM blob than obfuscated JS.
Why is that? With obfuscated JS you can instantly create ASTs, easily patch and preview the results. We have codemodding tools for mass patching and analysis. With WASM, you can theoretically have a future anti-tamper corporation with a solution to actively obfuscate binaries and antagonize reverse engineers, like we have today with desktop binaries.
Many of the anti-debugging techniques for desktop binaries do not work on WebAssembly: it can't jump to an address, it can't read the instruction pointer, it can't read/access it's own machine code, ...
Re: Making WebAssembly a first-class language on the Web
#134This maybe an unpopular opinion, but I feel WebAssembly in the browser is the wrong direction - this vision to turn the browser into an OS so that we are then forced to rent every software through the "cloud" will screw all of us eventually. It is going to make the web less open. With HTML and Javascript (or even VBscript in the old IE), you could always look at the source. Good luck doing the same with WebAssembly. Soon websites will start bundling WebAssembly malwares and browsers will then also bundle an anti-virus (probably coded with WebAssembly) to counter it. Ofcourse, the anti-virus will need a "cloud service" so everything you do on the browser will be collected and sent "anonymously" ... good bye privacy.
Re: Making WebAssembly a first-class language on the Web
#135Earlier quoted context omitted.
> WebAssembly has a sandbox and was designed for untrusted code. So does JavaScript. > It's almost impossible to statically reason about JS code, and so browsers need a ton of error prone dynamic security infrastructure to protect themselves from guest JS code. They have that infrastructure because JS has access to the browser's API. If you tried to redesign all of the web APIs in a way that exposes them to WebAssemb…
> If you compile them to GC wasm instead of running directly in JS then you're just adding unnecessary overheads for no upside Language portability is a big feature. There's a lot of code that's not JS out there. And JS isn't a great compilation target for a lot of languages. Google switched to compiling Java to Wasm-GC instead of JS and got a lot of memory/speed improvements. > Because for example if a browser chang…
> Language portability is a big feature. There's a lot of code that's not JS out there. And JS isn't a great compilation target for a lot of languages. Google switched to compiling Java to Wasm-GC instead of JS and got a lot of memory/speed improvements.
It's also worth noting that Wasm wasn't born into a vacuum like JS was (and Java for that matter), so it is competing[1] in a crowded space. Wasm is making inroads into languages that already have well-developed toolchains and ecosystems like Java, Kotlin, Rust, Scala, and Go. I think the Wasm network effect is happening, it is just very slow because it's primarily been a deployment platform and not a development platform.
It's also worth noting that Wasm advancement is pretty decentralized and there are a lot of competing interests, particularly outside the web. Basically every other language had at least one massive investment in both language development and tooling from the get-go. Java=sun, C#=Microsoft, Go=Google, JavaScript=browsers, Scala=foundation, etc.
[1] "competing" only in the sense of adding value over the mainstream or mainline implementations of these languages.
> Wasm is way too complicated to use today. So users of wasm today are experts who either (a) really need the performance or (b) really need cross platform code. So much that they're willing to put up with the rough edges.
I believe we can do better; we've been counting on languages that come to Wasm as a secondary deployment strategy and have their primary devex focused on another platform where then can debug better and offer better tooling.
Re: Making WebAssembly a first-class language on the Web
#136Earlier quoted context omitted.
>20 years of serious browser security bugs caused chiefly by JavaScript I think you may be confusing Javascript the language, with browser APIs. Javascript itself is not insecure and hasn't been for a very long time, it's typically the things it interfaces with that cause the security holes. Quite a lot of people still seem to confuse Javascript with the rest of the stuff around it, like DOM, browser APIs, etc.
That’s not entirely true. Security issues in the JIT of V8 are found every now and then. See https://v8.dev/blog/sandbox
Javascript isn't more insecure than any other language. Any language can have the same or other security issues.
Re: Making WebAssembly a first-class language on the Web
#137This (appears as though it) all could have happened half a decade ago had the interface-types people not abandoned[1,2] their initial problem statement of WebIDL support in WebAssembly in favour of building Yet Another IDL while declaring[3] the lack of DOM access a non-issue. (I understand the market realities that led to this, I think. This wasn’t a whim or pure NIH. Yet I still cannot help but lament the lost time…
I worked on the original interface-types proposal a little bit before it became the component model. Two goals that were added were: 1. Support non-Web API's 2. Support limited cross language interop WebIDL is the union of JS and Web API's, and while expressive, has many concepts that conflict with those goals. Component interfaces take more of an intersection approach that isn't as expressive, but is much more porta…
[dead]
Re: Making WebAssembly a first-class language on the Web
#138The web is fascinating: we started with a seemingly insane proposition that we could let anyone run complex programs on your machine without causing profound security issues. And it turned out that this was insane: we endured 20 years of serious browser security bugs caused chiefly by JavaScript. I'm not saying it wasn't worth it, but it was also crazy. And now that we're getting close to have the right design princi…
Nothing is being ripped out or replaced.
Re: Making WebAssembly a first-class language on the Web
#139The web is fascinating: we started with a seemingly insane proposition that we could let anyone run complex programs on your machine without causing profound security issues. And it turned out that this was insane: we endured 20 years of serious browser security bugs caused chiefly by JavaScript. I'm not saying it wasn't worth it, but it was also crazy. And now that we're getting close to have the right design princi…
> The web is fascinating: we started with a seemingly insane proposition that we could let anyone run complex programs on your machine without causing profound security issues.
Isnt this what an OS is supposed to do? Mobile operating systems have done a pretty good job of this compared to the desktop OS.
Re: Making WebAssembly a first-class language on the Web
#140I don't understand the push to make the browser a tool for securely running general purpose applications. This is the job of the OS. We keep building layers on top of layers of abstraction instead of fixing or improving what we have.
I think web apps are dead anyway and the browser is heading towards being a legacy software. The future is small ephemeral UIs generated on the fly by LLMs that have access to datasources. WASM is too late.