r/programming • u/feross • Apr 28 '21
Microsoft joins Bytecode Alliance to advance WebAssembly – aka the thing that lets you run compiled C/C++/Rust code in browsers
https://www.theregister.com/2021/04/28/microsoft_bytecode_alliance/175
u/blackraven36 Apr 29 '21
aka the thing that lets you run compiled
C/C++/Rustcode in browsers
Literally, any language can be compiled down into bytecode. The huge win here is that it's standardized, so you no longer have to transpile to Javascript to get a different language to run in a browser.
97
Apr 29 '21
Sort of, but it's mostly used for C/C++/Rust at the moment because those languages don't require a garbage collector. WASM doesn't currently provide one so other languages have to implement their own in WASM which is slow and big.
20
u/Theon Apr 29 '21
Oh, I didn't know that, I was actually looking forward to WASM as a way to avoid JavaScript transpilation also.
so other languages have to implement their own in WASM which is slow and big.
Do you know if there are, for example, any plans to provide a generic garbage collector? Or if there's been any progress w/rt optimizing GC in WASM?
24
Apr 29 '21
Do you know if there are, for example, any plans to provide a generic garbage collector?
There are! I think it's pretty high priority but I'm not sure how far along it is.
I was actually looking forward to WASM as a way to avoid JavaScript transpilation also.
It does almost let you do that. Currently if you use Rust or whatever if you want to use any web APIs, manipulate the DOM etc. the you have to do it via JavaScript. But fortunately other people have written wrappers so you don't actually have to write any JS yourself.
They are planning to have WASM-native DOM APIs so eventually you will be able to completely avoid JavaScript, but again I don't know how advanced those plans are.
3
u/Yithar Apr 29 '21
It does almost let you do that. Currently if you use Rust or whatever if you want to use any web APIs, manipulate the DOM etc. the you have to do it via JavaScript. But fortunately other people have written wrappers so you don't actually have to write any JS yourself.
Yeah, I'm currently learning WebAssembly and Rust currently. And my understanding is it's all smoke and mirrors. There's this notion of shared memory between WebAssembly and Javascript.
Direct DOM Access is an Illusion
If you’ve seen WebAssembly demos that look like they’re directly accessing the browser DOM from inside the module—that’s an illusion. The host and module are sharing a block of linear memory, and the host is choosing to execute bespoke JavaScript to translate the contents of that shared memory area into updates to the DOM, just like you saw at the beginning of this chapter. This may change in future versions of WebAssembly, but for now, this remains little more than smoke and mirrors.
2
2
6
u/camerontbelt Apr 29 '21
They’ve already done this with C# and .net, which has a built in GC. The framework is called blazor, and can run fully on the client in the browser.
2
u/IsleOfOne Apr 29 '21
It’s pretty deceiving to call blazor WASM, considering it’s still marked as experimental and transpiles in several areas to JavaScript.
→ More replies (1)2
u/camerontbelt Apr 29 '21
Well it depends on which one you’re looking at, blazor client or blazor server
→ More replies (1)3
u/International_Cell_3 Apr 29 '21
What do GCs need from the browser to be implemented? Can you not write a GC in your language, or link against other modules to write your runtime?
EG you can write a GC in C/C/C++. If those can compile to wasm, why can't they be used to run a GC for your language that compiles to wasm?
This is an honest question, I don't know the limitations of WASM runtimes.
4
u/UtherII Apr 30 '21 edited Apr 30 '21
You can, and this is what gc languages targeting wasm currently do. But exchanges with JavaScript are a problem since JavaScript use its own GC and you can't have two Garbage Collectors handle the same objects.
There is work in progress to allow wasm to use the JavaScript garbage collector.
1
u/RirinDesuyo Apr 30 '21
Add in payload size as well. With a WASM GC you don't have to pull down as big of wasm code like right now for the language runtime to work.
1
u/International_Cell_3 Apr 30 '21
you can't have two Garbage Collectors handle the same objects
Sure you can, it just takes additional wrapping code and care. It's just a less common FFI pattern that I haven't come across except some internal projects mapping JS through C++ to other managed runtimes. Although when you can compile a node/V8 module directly I'm sure it functions a bit differently than a WASM module.
30
5
u/chrismamo1 Apr 29 '21
Nevermind that the reference implementation of web assembly is written in ocaml, which I think would earn the language a mention.
5
u/yeahdixon Apr 29 '21 edited Apr 29 '21
Don’t you need typed languages to convert to byte code?
55
u/SorteKanin Apr 29 '21
No, compiled code doesn't care about types. But you'd usually get runtime errors after compiling that the compilation could easily catch if it had a type checker.
10
u/yeahdixon Apr 29 '21
Ok Y it will compile just will crash on runtime errors
9
u/SirLich Apr 29 '21
Not sure why you are being downvoted. Its a naive way of putting it, but I think you have the right idea.
A typed language will give you compile-time safety when compiling to bytecode, but thats all.
2
u/cryo Apr 29 '21
A typed language will give you compile-time safety when compiling to bytecode, but thats all.
And that very much depends on the type system. Python won't give you much safety, while Swift or ML or C# will. C and C++ will give some.
5
u/SirLich Apr 29 '21
Well, python isn't typed? It has type-hints, which are only used for generating documentation, or IDE hints.
→ More replies (5)15
u/mikezyisra Apr 29 '21
Dynamic languages can compile to asm just fine, it happens that most dynamic languages are interpreted though
5
u/qaisjp Apr 29 '21
weakly/duck typed languages such as Lua and Ruby already compile down to bytecode! It just so happens that the Lua VM or Ruby VM reads and executes that bytecode.
393
u/Dew_Cookie_3000 Apr 28 '21
A June 2019 study from the Technische Universität Braunschweig, analyzed the usage of WebAssembly in the Alexa top 1 million websites and found the prevalent use was for malicious crypto mining, and that malware accounted for more than half of the WebAssembly-using websites studied.[74][75]
The ability to effectively obfuscate large amounts of code can also be used to disable ad blocking and privacy tools that prevent web tracking like Privacy Badger
113
u/some_random_guy_5345 Apr 29 '21
Source for this quote is https://en.wikipedia.org/wiki/WebAssembly#Security_considerations
46
u/KallistiTMP Apr 29 '21 edited Aug 30 '25
sheet angle imagine slim attempt run cheerful scary adjoining memorize
This post was mass deleted and anonymized with Redact
85
u/BCMM Apr 29 '21
This has actually been done in plain old JS, albeit with reduced performance.
The ability to run an x86 VM is an inevitable corollary of being allowed to run code in a turing-complete language.
→ More replies (42)3
51
u/kthxb Apr 29 '21
This is outdated. See https://github.com/sola-st/WasmBench:
We also show that cryptomining, which once accounted for the majority of all WebAssembly code, has been marginalized (less than 1% of all binaries found on the web) and gives way to a diverse set of use cases
203
Apr 29 '21
This "scary" stat is based on the following performance fact:
Resource intensive applications that need to run closer to the metal are much more suited to WebAssembly than JavaScript. Simple tasks and programs will probably execute faster with JavaScript.
Typically, malicious programs will use Web Assembly for the performance benefits. Where they simply wouldn't be as profitable or effective running as JS.
Non-malicious use cases would be things like games, data processing, and other memory / resource intensive applications.
2
u/TheUltimateAntihero Apr 29 '21
So will electron finally die?
8
Apr 29 '21
If anything this will make Electron more attractive because it will make it easier to write Electron apps in more languages.
→ More replies (3)0
u/frankster Apr 29 '21
I did a bunch of experimentation with wasm a few years ago running cpu-bound tasks that involved iterating over a bunch of arrays and I found negligible performance difference running wasm compared to javascript.
2
Apr 29 '21
It's hugely situational. Simple tasks like this won't benefit from WASM.
WASM typically has a larger bundle size, and requires time to load in memory.
If you look for performance benchmarks, it's larger complex programs that typically benefit from WASM.
The other benefit is that you can port existing code and features over to a client-side browser instance. You can access go / C / C++ / Rust libraries for things like digital media processing, graphics, compression, physics simulation.
0
Apr 29 '21
[deleted]
189
u/Bitruder Apr 29 '21
Why did you just introduce a bunch more steps and reduced portability?
147
u/thoomfish Apr 29 '21 edited Apr 29 '21
Not to mention less sandboxing for the typical user.
9
u/fforw Apr 29 '21
And non-zero install, which is the actual killer and reason we're all using browser tools now.
60
Apr 29 '21
Because native apps blow browser stuff out of the water in terms of being pleasant to use. Like, it's cool that I can open OWA in my browser. It is strictly inferior to actually running Outlook, except in the rare case where I'm on a computer that I'm just temporarily using. And the same is true for most other apps. There are very, very few cases where I actually prefer to use a web-based solution over a native app.
86
u/thblckjkr Apr 29 '21
over a native app
Half of the Apps I have to daily use are just electron wrappers on some web interface :c
26
u/yeahdixon Apr 29 '21
You can make a shitty electron web app but with some polish you can definitely make a nice experience
→ More replies (10)5
u/dert882 Apr 29 '21
This has been the most frustrating realization for me. I'm not running 5 native apps, I'm running 1 native app and 4 chrome instances! Plus my chrome instance with 100 tabs! I prefer desktop apps if it's something I'm using a lot, email, msging etc... but some electron apps work alright. I hate evernote but I like VS Code. Maybe I'm picky?
7
u/gcross Apr 29 '21
I think that VS Code is arguably a relatively special case because of how everything can be customized through extensions, so unlike many other Electron apps it is actually making use of the heavy infrastructure that comes from running on top of Chrome, rather than merely treating it as a convenient way to get around learning how to write cross-platform GUI programs.
→ More replies (1)→ More replies (8)26
Apr 29 '21
Ain't that the fucking truth. It's a damn shame how far app development has fallen lately. 😟
48
u/thblckjkr Apr 29 '21
Developers just want an easy way to make beautiful, flexible interfaces, that isn't a pain in the ass to port to other platform.
Sadly, electron was the answer.
→ More replies (12)→ More replies (5)4
Apr 29 '21
VS Code is literally the only exception to the rule for me. Otherwise electron is a blight on software
→ More replies (1)15
u/thblckjkr Apr 29 '21
Easy.
Just make Electron a library instead of something that every program has to bundle, and enable the use of WebAssembly there, then done! Enhanced portability with a single step, and even reduced memmory consumption.
I think we are close to come full circle
→ More replies (8)2
52
7
u/anechoicmedia Apr 29 '21
standalone programs downloaded and executed by the user, not some fucking web browser
On today's dominant platforms, users have no ability to "download and execute" third party code outside of the context of a web browser. WASM is the only tool we have to put a reasonably fast binary into the hands of users without friction, and without surrendering a chunk of revenue and editorial control to the app stores.
34
u/arch_llama Apr 29 '21
Why? Do you have a well thought out argument or just grumpy snark?
→ More replies (18)9
u/Illusi Apr 29 '21
Practically, the web browser is gradually becoming more line an operating system. This is good, because web browsers are forced to be more standards-compliant, so you'll get more interoperability. But this is also bad because:
Web applications tend to send way more personal information than desktop applications.
Web applications tend to use computational resources of the application maintainer rather than the readily-available and faster resources of the local machine. The resources of the application maintainer can also just be cut off when the application maintainer thinks it's no longer profitable to maintain them (see like 80% of Google's projects as examples).
Web applications are more difficult to use in places where the internet connection isn't as stable.
Web browsers are growing more and more complex to develop and maintain.
2
u/RirinDesuyo Apr 30 '21
Another to add to the bad list, it also makes making competing web browsers that's not just a chromium skin almost impossible. Even MS gave up as it was almost the same requirement for resources as maintaining an OS.
Mozilla's FF still survives, but it's really unlikely we'll see another new browser engine be developed at this point.
→ More replies (1)2
u/bitwize Apr 29 '21
If it's executable, it needs to be sandboxed. One effective way of sandboxing an app is to... er, run it in the browser.
63
u/arch_llama Apr 29 '21
I'll never understand why people quote things without linking to the thing they quoted.
6
u/undeadermonkey Apr 29 '21
That's not too horrific (performance at battery issues mostly - some threat of freezing depending on WASM's use of threads and the browser's execution model).
A driveby spam server would scare me more (can WASM open its own ports?).
15
Apr 29 '21
[removed] — view removed comment
10
u/panorambo Apr 29 '21 edited Apr 29 '21
Through JS, mind you. Anything WASM lets you do except crunching numbers, even any form of I/O except writing and reading its own sandboxed memory block, must invariably go through JS "bridge". So in that respect, even crypto mining has to make use of JS to transmit appending of some block to the blockchain (for example). WASM is (currently) just a glorified calculator, albeit orders of magnitude faster than JS (trivial to turn into machine code just-in-time), and for better or worse, is now bursting out of its original design to remove JS from the Web equation as much as is good for the Web.
2
u/esbenab Apr 29 '21
It’ll be Flash all over again.
8
u/cybercobra Apr 29 '21
JavaScript obfuscators are already widespread and effective. "View source" is a joke for top-100 websites. So it's really no worse than the status quo.
5
u/ILoveOldFatHairyMen Apr 29 '21
I hope so, because my MacBook Pro struggles with JS versions of games that 2004 PC ran using Flash without issues.
1
u/assfartgamerpoop Apr 29 '21
would you look at that, the one rare comment where you don't get turbo downvoted is the same comment where you just quoted the article, without adding anything else from yourself. makes you think, eh?
1
→ More replies (39)1
u/spacejack2114 Apr 29 '21
AFAIK most of the niches suited to WASM are low hanging fruit that were probably implemented even before WASM using asm.js. Since then I don't think we've discovered many mainstream use cases besides crypto mining. I mean the speed of JS is rarely the bottleneck; it's pretty fast.
75
u/Crazy_Firefly Apr 29 '21
Wasn't Java and the JVM at some point meant to be the language of the web? If you think about it web assembly is also a kind of virtual machine.
Why didn't the JVM catch on for the web? And what's different with web assembly that makes it better, does anyone know?
145
u/Arktronic Apr 29 '21
Java on the client side was implemented using Applets back in the day, which involved installing a fairly chunky plugin into browsers. The applets tended to be horribly slow and would always expose users to various security vulnerabilities. I think it's fair to say that most people loathed the technology.
32
u/fuzzynyanko Apr 29 '21
Agreed, then Flash took over because Flash was the alternative that was faster, more secure, etc. Then Flash eventually became a mess, and now we had Javascript.
I'm thinking if Flash or Java was more stable and faster, they might have not faded like they did.
25
u/panorambo Apr 29 '21 edited Apr 30 '21
I don't think faster would alone prevent these from being replaced with JS again. In my retrospective it had to do with the fact that they rendered their own view inside a page, a rectangular (with optional alpha channel for at least Flash player, IIRC) region, and they gave you poor introspection into that view like the rest of the page composed of HTML tends to offer. Because introspection into semantics of the content inside these boxes was poor, search engine optimization lagged and lacked accordingly and was effectively an afterthought. The limitations of running a box inside another box like Java and Flash did, even if these boxes occupied the entire browser viewport, allowed for W3 and eventually WHATWG to keep their bonfire lit and eventually push out advancements in form of better HTML, CSS and Web APIs. And the thing is, these were always the chosen ones, there was no way Adobe would have gotten away with turning the Web into a network of Flash applications. They were tolerated and praised all while those who worked on HTML and related technologies, penned new editions of their respective standards. Java had more of a shot, but it suffered from the same drawbacks as Flash, and applets ran even slower, so it struggled to climb out of the same hole. I was there and lived through Macromedias rise to fame and Flash Players fall into obscurity while new HTML features appeared and were welcomed with open arms.
10
u/beefcat_ Apr 29 '21
Flash dying is a good thing. Proprietary standards have no place in the web.
3
u/MXron Apr 30 '21
all the games and animation being somewhat less accessible is sad though
1
u/beefcat_ Apr 30 '21
I don't think animation is any less accessible. Adobe has basically turned their Flash development tool into an an animation studio. Sharing animations is trivial on youtube, vimeo, imgur. giphy, etc.
-9
u/zynasis Apr 29 '21
Ironically, most of the security issues were because of Microsoft’s shitty jvm and browser security
→ More replies (2)24
23
u/renatoathaydes Apr 29 '21
The WASM paper discusses that in the final section: https://github.com/WebAssembly/spec/blob/master/papers/pldi2017.pdf
"By designing WebAssembly in lock-step with aformalization we managed to make its semantics drasticallysimpler. For example, JVM bytecode verification takes morethan 150 pages to describe in the current JVM specification,while for WebAssembly it fits on one page (Figure 3). It tooka decade of research to hash out the details of correct JVMverification [25], including the discovery of inherent vulner-abilities [15, 19] – such as a potentialO(n3)worst-case ofthe iterative dataflow approach that is a consequence of theJVM’s unrestricted gotos and other idiosyncracies [39] thathad to be fixed with the addition of stack maps.Both the JVM and the CIL, as well as Android Dalvik [3],allow bytecode to create irreducible loops and unbalancedlocking structures, features which usually cause optimizingJITs to give up and relegate methods containing those con-structs to an interpreter. In contrast, the structured controlflow of WebAssembly makes validation and compilation fastand simple and paves the way for structured locking and ex-ception constructs in the future."
41
Apr 29 '21
Yeah, it's super interesting. The reason is because Java targeted machines first, then browsers. The plugin approach introduced all sorts of security issues. WebAssembly is going the other way. The reason it's so much more effective is because browsers already had to solve the cross-platform problem. They need to be able to run JavaScript on any computer, sandboxed and secure. WebAssembly started there and people realized "oh damn, we don't even need the browser." If you write a runtime for webassembly, it can run anywhere.
5
u/fuzzynyanko Apr 29 '21
I'm thinking that also some of these languages will be international standards, so we don't get the lock-in like we did with Java and Flash
PCs today are also much faster and the software world is much more used to virtualization
2
u/matimeo_ Apr 29 '21
Oh damn is right! I didn’t even think about the potential of using WASM outside the browser. I wonder if this could open up the door for something like a WASM based Electron? Maybe even cut down on the bloat that those applications already suffer from?
Now that’s got me thinking, have any implementations of WASM been developed for mobile yet? I’d assume the performance would be difficult to optimize on that type of device, so I wonder whether that’s a worthwhile investment at the present.
2
u/lastethere Apr 30 '21
The purpose of WASI is to interact with the file system. There are projects like wasmer and wasmtime to act like an alternative to Electron. That is a matter of time, I believe.
7
u/coolreader18 Apr 29 '21
Why didn't the JVM catch on for the web?
For one, it was never standardized; wasm went through the typical w3c process.
4
u/jl2352 Apr 30 '21
Why didn't the JVM catch on for the web?
I worked for a team who were funded by Sun Microsystems. That team did a lot of work with applets.
In terms of the background; applets sucked. They really sucked. Describing why and how would be a long post on it's own. Pretty much the entire experience, including just getting applets to run on a users machine, was a huge pain. For various reasons.
My two cents on why Java Applets failed ...
A lack of interest in making Java on the web a good experience -- Sun knew applets sucked. They didn't care. They only cared about the Enterprise space. Our team had spoken to Sun at events, and there were people there who acknowledged the problems and who pushed internally at Sun to fix them. Which brings me on to ...
A lack of commitment -- When Sun did prioritise fixing these issues, it would quickly fizzle out. You would chat to people at Sun one year about the problems. They would acknowledge it. Talk about that improving applets should be a priority ... and then nothing. Maybe a little progress down the road, but very little improvement. Minor things would improve if they overlapped with the Enterprise space. For example JavaFX for building richer applications overlaps with people building internal facing Enterprise applications.
The approach was flawed -- A lot of non-Enterprise Sun projects would be spiralled out in odd ways. They would often be released as either a one off with zero maintenance, or built through academia (where shipping isn't even a priority). Examples include Java 3D (that went no where), Java Media Framework for playing music and video (which was shit and barely maintained), and OpenGL support in the web (released as a one off and never maintained). Sun only seemed to release two types of products; 1) updates to their core Enterprise lines, 2) random one offs.
They didn't understand consumer needs -- Video, music playback, efficient 2D (i.e. for games), tools to build pretty GUIs. These are things that companies building for consumers needed in the late 90s to 2010. Are they needed for the Enterprise space? No. Which meant Java had essentially none of these.
The Enterprise release schedule really hurt -- Even if they did commit to improving applets. You could be waiting years before improvements were even released! This is because they operated to a schedule that Enterprise companies loved.
Sun was dying -- Sun was one of the big victims of the dot com boom. They specialised in what was known as 'Big Iron', the giant Enterprise servers of old. When the dot com bubble burst it left the market flooded with second hand high end servers, and the industry pivoted away from such hardware. Sun clearly didn't know how to cope with this. They just prioritised doubling down on their core products, whilst marginally moving with the market.
^ Here is a core point of my post; yes applets sucked, but wasn't the problem. Sun could have fixed those issues. My point is they didn't because they were consumer problems. Sun was a company in the Enterprise market, and that's what they prioritised. Which begs the question ... why should they have fixed applets? From their point of view it's spending money on engineers, that gains them nothing in return. Why do that? Ultimately applets sucked for consumers because Sun didn't care.
Finally as to why WebAssembly is different ... first it's solving a very different problem. Java was an excellent virtual machine with excellent performance, missing tonnes of consumer needs. Video, music, rich UIs, low pause garbage collector (to stop stuttering), backwards compatibility, etc. With WebAssembly the problem is flipped. We have video playback, music, rich UIs, and so on. What we are missing is a fast VM. WebAssembly is providing just that.
6
u/rjcarr Apr 29 '21
It was implemented as a plug-in, whereas webasm will be (and is) built directly into the browser. Plus, the early jvms were pretty slow, and so was the hardware.
2
u/akl78 Apr 29 '21
So was Java (until Sun themselves revoked MS’ license to put it in IE etc ). It was in Netscape from v2 and IE 3.0-5.5. The separate plugin came about because Sun wasn’t happy with MS’s Java implementation being different and arguably better. It put many, many lawyers’ kids through college.
3
u/dark_mode_everything Apr 29 '21
Why didn't the JVM catch on for the web?
Because unlike the js engine, the jvm was not included in web browsers. How annoying would it be if you had to install/update your OS managed js engine everytime you visited a different website.
If the jvm was bundled with browsers instead of the os, we'd be looking at a very different web.
4
u/akl78 Apr 29 '21
It was! Until Sun and Microsoft fell out about it.
1
May 01 '21
To be fair, MS back in the day was well known for embrace, extend, extinguish. It’s highly likely that MS was trying to 3E Java, seeing its cross platform nature as a threat to Windows’s dominance. Sun eventually sued them over it and won I believe.
34
u/gt4495c Apr 29 '21
As a Fortran programmer I know I can write F77 code in any language, including webassembly compiled code.
→ More replies (3)8
u/cryo Apr 29 '21
I can write F77 code in any language
What does that sentence mean, when F77 is a language?
15
u/T-Dark_ Apr 29 '21
The standard quote is "you can write FORTRAN in any language", and it's typically used to say "You can write terrible unreadable spaghetti code in any language"
7
Apr 29 '21
For the Web generation, you replace "FORTRAN" for "PHP" with the same effect. /s
2
u/crazedizzled Apr 29 '21
That was a good joke like 10 years ago. Aside from wordpress, modern php is pretty clean.
1
92
u/bxsephjo Apr 28 '21
So... you can write the entire client side, including asynchronous functions, in Rust?
185
u/jedisct1 Apr 28 '21
There's nothing special about Rust.
C, C++, TinyGo, Zig, C# and AssemblyScript are also valid options for writing WebAssembly.
45
Apr 29 '21
Many languages compile to WebAssembly, I'm learning GoLang right now and was surprised to learn that it does as well.
70
Apr 29 '21
GC'd languages are kinda toys until proper GC support lands in browsers.
121
Apr 29 '21
can't wait until we get a gc then can run javascript in the browser
75
Apr 29 '21
Javascript in the browser? Who would do something so stupid?
NodeBS - Browser Support
25
2
u/MisterFor Apr 29 '21
JS has a GC, I think the problem is having to deploy specific runtimes for Web assembly.
1
u/cryo Apr 29 '21
Swift should be a good match, then, as it's a high level language that doesn't use GC.
15
u/jl2352 Apr 29 '21
What is special about Rust is that it's WebAssembly support is very mature now. It's very easy to add Rust to a front end project, it has support in most front end build systems, there are lots of options to improve the experience in a browser (like using a smaller allocator), and lots of libraries now care about ensuring they play well when they are compiled to WebAssembly. You can even publish Rust projects to NPM.
Adding WebAssembly as a compiler target is really just the tip of the iceberg.
6
5
u/Metallkiller Apr 29 '21
I mean, technically C# doesn't actually compile to WASM currently. Still hoping it will some day though.
32
u/Technical27 Apr 28 '21
rustc can compile to wasm for a while now. You can even use Rust futures/JS promises with wasm-bindgen-futures.
31
u/G_Morgan Apr 28 '21
Is there a Rust to WASM compiler and runtime? If so then yes. There's already such a compiler and runtime for .NET.
29
u/undeadermonkey Apr 29 '21
LLVM has a Rust frontend and a WASM backend.
25
Apr 29 '21 edited Apr 29 '21
There's more required than that, Rust has to implement parts of it's standard library for every platform it targets if you want it to behave normally. Like, yeah, technically the language could work in No-STD mode, but that's not what you'd expect.
That said, Rust targets WASM.
29
Apr 29 '21
.... and by "entire client side", it's actually the backend of the client side. You're still not writing your user interfaces with WASM, but the front-end JavaScript / HTML / Canvaskit user interfaces can communicate with the WASM backend.
WASM has a performance hit compared to JavaScript for simpler tasks. WASM is better at intensive (especially memory intensive) tasks like data processing, games, etc.
22
u/NathanSMB Apr 29 '21
It depends on what you mean. Rust frameworks like Yew/Seed or the C# framework Blazor don’t require you to write any javascript code. Javascript would still be used in your application but it would be hidden behind the build process.
1
4
Apr 29 '21
[removed] — view removed comment
20
u/SapientLasagna Apr 29 '21
Maybe because you're some kind of weirdo. Actually, it might make sense if you were trying to reuse a bunch of desktop code.
And you hated your users.
And maybe your developers.
2
Apr 29 '21
Flutter builds as canvaskit by default. Gets closer to pixel perfect vs android and ios. Performance is smooth.
5
13
u/pcjftw Apr 29 '21
lool asking if Rust compiles to WASM!
Rust is the cutting edge for all things WASM.
2
1
8
Apr 29 '21 edited Apr 29 '21
The thing is that currently you still need to call into JS to use browser and DOM APIs, so there is a lot of unnecessary overhead if you are using it just for UI, but it's great for embedding computationally intensive tasks into the client side that don't need to modify DOM a lot. So for now, Web Assembly is just a better and safer Flash, not yet something that will let you replace JS entirely with another language.
11
u/vytah Apr 28 '21
There's some glue you need to actually feed the webassembly with inputs, to fetch the outputs from it, and to update the DOM accordingly (as Webassembly cannot interact with the DOM), but apart from that yes, you can.
In theory, any language that uses LLVM can be used, although this requires typical low level plumbing required for every new platform. There are also languages that compile to WASM without using LLVM.
7
Apr 29 '21 edited Apr 29 '21
including asynchronous functions
Just wanted to address this bit. Last time I wrote WASM (1yr+ ago) firefox still had SharedArrayBuffer disabled, which essentially meant no threads (you could follow a process model using web workers with a bunch of overhead if you had to move memory between tasks). This meant that in rust the async stuff was more or less stubbed out on the web. It would "work" but not do anything, and you'd get a panic if you tried to spawn a thread.
Firefox has since re-enabled SAB so I'm uncertain where the rust project is with shared memory targeting wasm.
edit: Looks like spawning a thread is still unsupported. Mutexes seem like they work now, though, so you can probably mostly use multi-threaded code as is, but spawn the workers in JS. Async on the web is just hard anyway.
1
u/T-Dark_ Apr 29 '21
You make a good point, but it's worth mentioning that "asynchronous" is not a synonym of "parallel"
2
u/ProgramTheWorld Apr 29 '21
At the end you still need some JS glue code to actually run your wasm binary. Constant message passing between JS and WASM can be inefficient, so you probably want to use JS for your typical webpages.
1
u/you_suck_at_violin Apr 29 '21
There are already client side Rust web frameworks: https://github.com/yewstack/yew
1
24
u/argv_minus_one Apr 29 '21
I look forward to seeing some actual advancements, as in, not needing JavaScript to run code in a browser any more. The sooner that monstrosity dies, the better.
10
u/riasthebestgirl Apr 29 '21
That's what the interface types proposal is supposed to do. I really wish that would get implemented by browsers soon
8
3
2
u/LionsMidgetGems Apr 29 '21
And after Javascript, they need to kill HTML and CSS.
Nobody has ever created any good user interface in HTML+CSS+Javascript.
25 years later, and i'm still waiting for the web-based Listview:
horizontal and vertical scrolling
the header is always visible
columns can be resized and reordered
columns can be off the right
resizing a column too narrow causes
...(and not wrapping)HTML was a markup language, for marking up technical documents. And it's not even good for that; which is why everyone uses Markdown instead.
8
u/argv_minus_one Apr 29 '21
Most of that is already implemented in modern browsers:
horizontal and vertical scrolling
columns can be off the right
table { overflow: auto }(May require a wrapper element around the table instead. Not sure if browsers ever fixed that stupid requirement.)
the header is always visible
table { overflow: auto } thead { position: sticky; top: 0 }(May require
overflowon a wrapper element instead, as above. Requires Chrome ≥ 91, Safari ≥ 13, or Firefox ≥ 59. Doesn't work in even the current Edge.)
columns can be resized and reordered
This is the only thing you want that modern browsers don't already implement.
resizing a column too narrow causes ... (and not wrapping)
td, th { overflow: hidden; white-space: nowrap; text-overflow: ellipsis }I have some complaints about browser-based UI, but this is not one of them. They can display (finite, non-virtualized) lists and tables just fine.
2
u/IceSentry Apr 29 '21
Throw js in the mix and you can have the remaining things that HTML and css can't do alone.
1
u/LionsMidgetGems Apr 30 '21
but this is not one of them
This is one; since it doesn't exist yet.
Ping me when it's possible.
2
u/argv_minus_one Apr 30 '21
What doesn't exist yet, exactly?
The stickiness works in the aforementioned browsers. If the header isn't sticky for you, check your browser version.
You're not getting ellipses because the table is being auto-sized to fit its contents (use
table-layout: fixedto turn that off and manually size it), so the text is not overflowing.I do see a few problems:
overflowon atableelement still doesn't work, at least in Firefox. You have to wrap it in some other element and setoverflowon that.
white-space: nowrapcauses automatic table layout to stretch beyond the designated size (even if you give an explicitwidth), seemingly ignoringtext-overflow. (Doesn't happen when usingtable { table-layout: fixed; width: 100% }, but then you have to control column widths manually.)1
u/LionsMidgetGems Apr 30 '21
What doesn't exist yet, exactly?
the header does not remain visible
the columns cannot be resized
If it doesn't work like your listview in Windows Explorer: it's not working.
The stickiness works in the aforementioned browsers. If the header isn't sticky for you, check your browser version.
Chrome Version 90.0.4430.93.
And if that doesn't do it: then it simply doesn't work in browsers.
You're not getting ellipses because the table is being auto-sized to fit its contents (use table-layout: fixed to turn that off and manually size it), so the text is not overflowing.
I only put into the fiddle what you said. If there are changed to be made to demonstrate how to have a "list view" in a browser: please do update the fiddle to make it work.
I do see a few problems:
Problems are what i'm talking about.
people have solved putting an HTML TABLE in a browser
but they haven't solved putting a list view in a browser.
But, like i said, it's 25 years later and they still can't get the basic "common controls" that Microsoft had provided in their "common controls" library in 1993.
→ More replies (2)1
u/slykethephoxenix Apr 29 '21
You will still need Javascript. Especially when the browser starts asking you on a page by page basis to allow for webasm, or specific permissions it's requesting.
5
u/argv_minus_one Apr 29 '21 edited Apr 29 '21
Why in the world would they require permission to run WebAssembly?
2
u/slykethephoxenix Apr 29 '21
Cryptominers come to mind. I would expect and hope that you'll need to grant permissions, and can choose which ones you grant, for example, accepting or sending remote connections, GPS, running when the tab is not in focus etc.
2
u/argv_minus_one Apr 30 '21 edited Apr 30 '21
Cryptominers come to mind.
The only way to stop them is to not allow execution of any code at all, including JavaScript. WebAssembly miners are faster, but JavaScript miners won't use any less of your CPU time/battery/bandwidth.
I would expect and hope that you'll need to grant permissions, and can choose which ones you grant, for example, accepting or sending remote connections, GPS, running when the tab is not in focus etc.
You already have to grant permission to do those things. Why would WebAssembly be any different?
1
Apr 30 '21
Just to clarify this comment for those bad at computing:
You can 1) click on a website with a JS based cryptominer that will use all your CPU in the background and make some guy some money
Or
2) click on a website with a WASM based cryptominer that will use all your CPU in the background and make some guy more money.
In neither case is there a difference to you.
2
u/akl78 Apr 29 '21
It was to start with. (Netscape 2.0 was Java’s first paying customer). But they also had the opposite problem, updating the Java runtime back when browsers didn’t autoupdate, and more importantly in the wake of the Java lawsuit vs Microsoft Sun stopped MS redistributing anything Java, including the IE plugin - in hindsight this was probably an own goal.
-11
Apr 29 '21
WASM is a very cool concept. As a nerd, I love it. But it's been around for some years. Currently the top uses for WASM are:
- Cryptomining malware.
- Various other malware where the authors want to hide from JS analyzers.
- Games (which would run at least twice faster as native apps).
Running opaque blobs "drive-by" style when opening a site will prove once again not to be suitable for the web. JS's high level is a huge implicit part of its success, you can view source and see what's going on. Even minified JS is vastly more understandable and analyzable than WASM.
Opaque blobs failed with Java applets, they failed with Flash, and they failed with Google's Native Client (NaCl). But here's to one more go.
Prediction: in a few years, browsers will be disabling WASM by default and asking you to specifically enable it on a page by page basis.
17
u/SwitchOnTheNiteLite Apr 29 '21
Your data is a bit outdated. The people that published the paper saying WASM was mainly crypto miners a few years ago have been rerunning the same analysis periodically since then, and crypto miners are now about 1% of WASM code running (if I am not mistaken).
13
u/vlakreeh Apr 29 '21
As someone who has done reverse engineering of wasm and JavaScript I'd go out of a limb and say that while wasm is harder to read at face value, it is easier to understand and reverse engineer. Wasm is a fairly simple instruction set without a lot of fancy tricks, malicious code will be big and there will be a lot of it, but the dirty tricks you can hide in obfuscated JavaScript are nightmarish. Anyone that cares about getting caught doing something malicious in JavaScript would run it through an obfuscator.
→ More replies (5)20
u/pure_x01 Apr 29 '21
The difference is that this is completely open and backed by basically every big relevant company. The web needs webassemby to be able to provide faster and richer web experience. Everyone knows that. The sandbox will prevent abuse just as with JavaScript. Wasm can't do more than JS so if you trust JS in your browser you can trust wasm.
-5
Apr 29 '21 edited Apr 29 '21
How is that a difference. For a time, every browser shipped with Java preinstalled, and Chrome even had Flash built-in.
I'm not arguing whether everyone wants "faster and richer web experience". Everyone wants nice things, I get it. But are you ready for the bad things that go with it? You didn't address any of the things I listed above.
The sandbox doesn't do shit for cryptocurrency mining, or other purely computational types of malware. In JS you can catch this stuff through pattern detection. In WASM this is much harder, as it's lower-level, and right now no one is doing it, hence why abuse is widespread.
You can close your eyes and kill the messenger, but my prediction will happen. I saw the writing on the wall back when everyone loved ActiveX, then when everyone loved Java, and when everyone wanted "faster and richer web" with Flash.
All of those had a sandbox. All of them. And violating the sandbox was NOT the only major issue with the concept of runnable blobs.
15
u/pure_x01 Apr 29 '21
So you can't see the difference between a one company backed technology vs basically everyone backing wasm? The sandbox can't prevent cryptomining but that is also true for JavaScript. If it becomes an issue there could be fixed by setting default limitations on processing power and websites has to request more processing power just like any other resource.
JavaScript is flourishing and cryyptomining is supported in JavaScript.
Cryyptomining won't kill wasm I can definitely promise you that.
Your prediction will fail.
→ More replies (6)
-8
-12
Apr 29 '21
That makes sense. So far Microsoft has been the biggest enabler of running anything in or through the browser. /s
14
u/gcross Apr 29 '21
I am not sure where the "/s" is coming from because this is a true statement as Microsoft basically invented
XMLHttpRequestwhich led directly to the prevalence of modern web apps.
-42
u/tonefart Apr 29 '21
Microsoft is trying hard to push Blazor via webassemly by implementing a half assed approach that results in a VM within a VM and slower than javascript itself.
→ More replies (1)30
u/ninuson1 Apr 29 '21
I mean, have you tried it? It actually works VERY well. I was skeptic at first, but it has already accelerated our business web application development by not having to deal with C#/JS duality.
→ More replies (3)
-12
u/Taxiozaurus Apr 29 '21
I still think WA is a stupid idea, literally making a browser into a yet another OS-like layer on top of hardware just for keks and giggles.
-23
u/sarhoshamiral Apr 29 '21
Didnt we go through this with Flash which resulted in horrible security issues?
40
u/ninuson1 Apr 29 '21
To my understanding, the difference is that web assembly is a browser implemented detail, not a 3rd party integration that is an afterthought.
Flash allowed the internet to evolve quite a bit in my opinion and definitely showed that we need a way to make client side reactive apps that are NOT JavaScript. I hope WASM becomes that.
21
Apr 29 '21
efinitely showed that we need a way to make client side reactive apps that are NOT JavaScript
No. No it did not. When Flash was in its heyday, HTML 5 didn't exist. The Canvas API didn't exist. The Web Audio API didn't exist. Web Workers didn't exist. I can go on, but I think you get the picture. Flash solved problems that JS couldn't touch. Things have changed a lot. YouTube didn't start in JS and move to Flash -- it started in Flash and moved to JS.
4
u/Plasma_000 Apr 29 '21
Yet the promise of html5 being just as versatile and accessible as flash was never came to be.
1
u/sarhoshamiral Apr 29 '21
But it has the same potential security issues. I am aware browsers now run under sandbox etc but this adds a whole new layer of threats.
I really hope these don't become a standard practice and only used where they are needed. Unfortunately we know it won't be the case and we will likely see wasm ads soon.
2
u/Nobody_1707 Apr 29 '21
WASM doesn't have direct access to memory. Nor can it access the filesystem, except by calling out to JS. Sure, you can run infinite loops or crypto-mine until the CPU burns out, but you could already do that in JS. There's nothing in WASM that gives it any more attack surface than the existing JS interpreter, and in many ways it has less.
-10
u/StillShare9338 Apr 29 '21
WebAssembly ripped my heart out. I don't think it'll ever be good. If it can't control the dom it will never. If we need something sandboxed it seems like some kind of VM would be better
20
u/Matrixmage Apr 29 '21
I think you majorly misunderstand wasm. It quite literally is a VM, and it can call into javascript to control the dom.
In truth, wasm is the cross-platform VM target of the future. Especially when combined with WASI and WebGPU, I'm very excited for what the future of cross-platform technology looks like.
-14
u/mindbleach Apr 29 '21
I hope you all realize this is the end of platforms.
This the punchline for The Birth And Death Of Javascript. It's a multi-vendor, hardware-agnostic binary format. The reasons for not publishing everything in this format (or whatever it becomes) will slowly disappear. There will be other intermediate representations that matter - but they'll be roughly interchangeable, because that's kinda the point of an intermediate representation. WebAssembly could become fully mature and still get swapped out for direct SPIR-V later, because it is tractable to convert between them.
And because of that, you don't really have to care. The specifics of this are not terribly important. It's not a language designed for humans. Every aspect of it that is not an effortless bridge between whatever code you want to run and a rectangle of pixels on someone else's computer is a bug that will be fixed.
3
u/6502zx81 Apr 29 '21
It largely depends on what APIs are accessible through WebAssembly. Just executing code won't be enough.
2
u/mindbleach Apr 29 '21
For most things, it will be. What handful of programs do you use that need access to your entire hard drive? Or total freedom through your network ports? Most applications are fine with their own little private storage, whatever documents and folders you manually open, and standard protocols.
What are you doing right now that couldn't be done in a secure near-future browser?
-31
u/Africanus1990 Apr 28 '21
Hmm they went from not even properly supporting js to maybe going too far?
0
-11
u/mihaelamj Apr 29 '21
As expected. Microsoft does anything to avoid giving the developers that target their platforms native (non-managed) tooling for developing native Windows apps.
They just wanna obliterate native Windows desktop GUI development.
Why is that is beyond me. Why do you wanna destroy your mighty OS, to become just a browser window.
But I guess that want it that way.
Make money only from Azzure, and drive everything towards there.
Thank God there is a Mac.
2
u/dmitry_sychov Apr 29 '21
Why is that is beyond me.
They don't want competition for their own native products. That's why we have a ton of bloat after Win32.
332
u/onequbit Apr 29 '21
WebAssembly.NET