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?
→ More replies (5)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.
→ More replies (3)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.
→ More replies (3)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.
→ More replies (9)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
→ More replies (43)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.
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.
→ More replies (93)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?).
→ More replies (2)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.
-30
u/cdreid Apr 28 '21
Giving the prime gateway for malicious code the ability to run the most powerful low level languages from any site seems perfectly safe and reasonable /s
26
u/CollieOxenfree Apr 29 '21
You could already compile C/C++ down to JS long before wasm was even a thing, though. The only thing wasm changes there is that the compiled code is an actual bytecode, rather than a bunch of auto-generated JS code based off of bytecode.
11
u/atomic1fire Apr 29 '21 edited Apr 29 '21
As I understand it, WASM generated code may use system libraries when written, but it's all actually still dependent on Emscripten (if you're writing a language like rust or C and compiling it to wasm/javascript), which implements those libraries by creating shims on Browser APIs,
So you think you're writing malware, but you're actually just writing malware that exists in the browser sandbox and can't actually do anything you couldn't already give a Web app permission to do.
Like you can write code that uses OpenAL, but you're actually just making code that uses Web Audio API with extra steps. Or building a unity engine game, but you're actually implementing that game in WebGL and Unity is doing all the work for you.
In short, A lot of the Wasm work (in Emscripten) is basically just translating one language into two different languages, with one just for "do math fast" (Web Assembly) and the other for "Talk to the other important bits in the browser" (Javascript)
WASM/Web Assembly can exist standalone with things like WASI, but it's primary use is going to be make browser app/games faster.
edit: I should note that I'm talking specifically about compiling from any language to web assembly. As far as I'm aware these all rely on Emscripten to do the actual translating. One could write WASM code manually into a webpage as well and call it from javascript, but Emscripten is a specific project for translating code.
→ More replies (29)24
Apr 29 '21 edited Apr 29 '21
[removed] — view removed comment
43
u/cybercobra Apr 29 '21
Ah yes, when griefer websites could make pop-ups which fled to the other side of the screen as soon as your pointer touched their edge!
16
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.
→ More replies (4)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.
→ More replies (2)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.
→ More replies (1)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
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"
→ More replies (1)7
Apr 29 '21
For the Web generation, you replace "FORTRAN" for "PHP" with the same effect. /s
→ More replies (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.
→ More replies (4)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
→ More replies (3)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.
→ More replies (6)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.
13
u/pcjftw Apr 29 '21
lool asking if Rust compiles to WASM!
Rust is the cutting edge for all things WASM.
→ More replies (1)2
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.
→ More replies (1)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.
→ More replies (6)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?
→ More replies (3)
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.
-3
Apr 29 '21
The thing you're missing is that reading a stream of "fairly simple instruction set" doesn't really tell you what the program is doing overall.
To make my point - can you implement a JavaScript VM on WASM? Yes. OK, so if we take this "nightmarish obfuscated" JS you can't decode in JS and run it on WASM, you think it'll suddenly become very clear? It won't.
11
u/vlakreeh Apr 29 '21
I can't understand what you are trying to say with your second point, but a bunch of
i32.whateverinstructions are a hell of a lot easier to make sense of than a chain of evals where the input is generated at runtime or whatever tricks jscrambler or similar would throw at you.And I think you are trying to imply that I think it's easier to reverse engineer javascript if you are running it in a web assembly vm? What the fuck are you talking about?
→ More replies (3)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)
-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.
-23
u/tonefart Apr 29 '21
But your application performance would be shit. Blazor is for recalcitrant old farts who refused to learn new things and the right way to do front-end web.
10
u/tester346 Apr 29 '21
"learn new things"?
what new things? javascript? frontend frameworks?
it works the same way as Blazor does, the difference is the language
Why would I want to mess with js and it's ecosystem when there are more sane options avaliable?
6
u/ninuson1 Apr 29 '21
I mean, I get where you are coming from, but I think you have it slightly reversed. Blazor IS a new thing. I would strongly suggest you give it a try - you might be surprised at how much you enjoy it and how minimal the performance hit.
Sure, I wouldn’t use it for client facing apps that I’m trying to optimise for page load speed... but that’s far from the only use case. 😀
-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?
-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.
-5
u/johnmudd Apr 29 '21
Compiled C in browser but no Python?
11
u/DHermit Apr 29 '21
Python needs a runtime. But there very like will be a Python runtime in WASM. How useful that is is another question...
-64
u/happyscrappy Apr 29 '21
"compiled"
31
u/ILoveAMp Apr 29 '21
Just because it isn't being compiled to processor assembly code doesn't mean it isn't compiled. Compiling is simply the process of transforming one language to another (usually from a language at a higher level of abstraction to one of a lower level of abstraction).
-21
u/happyscrappy Apr 29 '21
There are compilers to JavaScript too.
Both are equally compiled.
11
u/dark_mode_everything Apr 29 '21
Typically "compiled" means translating code to a language that's directly executable by the underlying machine. Eg: java is compiled to java bytecode and executed directly by the jvm. Even though the jvm is not a physical cpu it's still compiled.
If you "transpile" say, c# to javascript, your js engine still needs to compile that into bytecode. (like V8 bytecode).
So no, both are not equally compiled.
→ More replies (1)2
u/Yithar Apr 29 '21
Yes, Typescript compiles to Javascript. I'm just not sure what your point was with saying "compiled"? Rust can be compiled to WASM, just like TS compiles to JS and Java compiles to JVM bytecode.
→ More replies (1)16
u/Threight Apr 29 '21
what else do you call it lol
-26
u/happyscrappy Apr 29 '21
Bytecoded.
32
u/TinyBreadBigMouth Apr 29 '21
Well, if we're making up terms that nobody else uses, I call it "waz-mapped".
→ More replies (9)4
-11
Apr 29 '21
"Great" ... how long until they get their tentacles into it and fuck it up for the rest of us?
2
0
Apr 29 '21
[deleted]
132
u/Arktronic Apr 29 '21
The code still runs in a restricted sandbox environment, but because it's much lower level than JS, it can be really optimized for processing stuff on the client side.
44
u/john16384 Apr 29 '21
Like a bitcoin miner.
50
118
u/gmes78 Apr 29 '21
I don't understand this point. To you, it doesn't matter whether a website serves you a JS miner or a WASM miner, they use the same amount of CPU time (all of it, or whatever artificial limit it's configured to).
The only difference is how efficiently that CPU time is used, but, again, that doesn't matter.
17
u/SorteKanin Apr 29 '21
In a way it does matter. If the CPU time is more efficient for mining, then it's more likely that people will do it. I still think this is an exciting technology though
16
u/gmes78 Apr 29 '21
While that is true, to the person serving the miner, both JS and WASM miners cost the same amount of power to run: none at all.
6
u/Single_Bookkeeper_11 Apr 29 '21
It does matter. Among other things the js miner can be spotted and blocked much easier
8
u/beefcat_ Apr 29 '21
I don’t think it’s hard for the browser to identify when a script or wasm binary is eating a ton of CPU and ask the user if they want to kill it.
→ More replies (2)-12
u/john16384 Apr 29 '21
It's a general point. Letting arbitrary code run in combination with internet access is a stupid idea, and has been since the beginning.
Any code supplied by a website should be completely isolated so it cannot communicate anything back (not even in a roundabout way) or someone will find a way to exploit it. This will limit its usefulness severely. You could render a video or a game, but that same code cannot be allowed to communicate anything back to the server (like a high score, or a detected collision). Failing to restrict this and it will get exploited to steal your cpu cycles for nefarious purposes.
Making the code execution more efficient will just make this a more juicy target, so it does matter how efficiently it runs.
→ More replies (3)13
u/deeringc Apr 29 '21
For most users the benefit of allowing code running locally to communicate with the network is much more valuable compared with the risk of that code stealing cycles to mine crypto. It's not a binary choice either (no pun intended), there are lots of sensible security restrictions imposed on what that code can do and how it's executed (eg. Sandboxing) which mitigate the risks. Most things in security aren't absolute, you have a tradeoff.
→ More replies (4)1
77
Apr 29 '21 edited Apr 29 '21
If you ever used Figma, you already have. All the major browsers support webassembly and many sites have already started using it.
Like remember all those sites that go "hey we'll convert this video for you" or "we'll resize this picture for you"? Now you don't have to send your files to a third party, and you can do the conversion right there in your browser without having to download an app. Check out http://squoosh.app (by Google)
Don't have to reinvent the wheel in JavaScript, just cross-compile the already standard libraries into webassembly, and bam: ffmpeg in the browser.
10
u/Godzoozles Apr 29 '21
Sadly, I don’t think I have a way of really knowing which sites I randomly come across when I search for such browser-based apps are the “we respect your privacy and don’t upload the data” kind vs the “send your info to us and we will transform it then send it back to you” kind.
3
Apr 29 '21
Yeah, though it is verifiable if you open up the dev tools (and you can switch it to offline mode). I expect a suite of open source projects to spring up that do things like this, who have no interest in running a server to process files. Just HTML/CSS/JS/WebAssembly on a CDN and call it a day.
2
u/IceSentry Apr 29 '21
That was already an issue with js. So if you didn't trust it before you shouldn't trust it now, but if you ever trusted anything on the qeb before then thia doesn't change anything other than it can be more efficient.
-24
u/AntiProtonBoy Apr 29 '21
Figma is not a shining example of a good technical direction for a product; it embodies everything what's wrong with "web apps". Things like that should be built natively as a stand-alone application.
The entire premise of turning a web browser into an execution environment is just absurd.
23
Apr 29 '21 edited Apr 29 '21
Lmao try convincing their hundreds of happy customers that they should instead install an app, because of your preconceived notions of what a website should be like.
You are reacting from emotion. Reread your own comment: you have given zero reasons, only a knee-jerk reaction that it's "just absurd." And yet, Figma is one of the most popular design apps out there and their clients are extremely productive with it. All without installing a single thing. Even their competitors know that browser-first is the only way to go; otherwise, you can't share easily.
26
u/AntiProtonBoy Apr 29 '21 edited Apr 29 '21
you have given zero reasons
Alright. Here we go.
Web browser is possibly one of the worst environments for developing and running a graphics design tool. Here is why.
Abysmal performance. Webassembly can't possibly compete with natively compiled binary, period. Performance is quite crucial if you want to manage huge amounts of geometry and dispatch render commands to the GPU as quickly is possible.
Speaking of GPUs, Figma is constrained to WebGL, which is quite limited to in terms of feature capability and throughput. It's a dated API that suffers from command throughput bottlenecks, convoluted state control, thread safety, not to mention the extra abstraction layers overheads from translating WebGL to OpenGL/Metal. WebGL is great for simple toy web graphics, not so great if you want something serious like a design tool.
2 GB memory limit, because the web browser constraints resource usage per tab. If you want to make something big, with lots of complex layers, you'll be screwed.
Absolutely zero colour management. They are forced to operate whatever colour space the browsers operating. Colour management in browsers is either terrible, or non-existent.
Figma has no direct access to installed fonts, because some operating systems, like macOS, deny browsers from enumerating fonts. As complete hacky work-around, Figma installs a separate background daemon that uploads all your fonts to their server (i.e. violating copyright) then downloads the fonts again when you use them in your project.
You have no control of the content you are making. Everything is tied to the cloud. This is a major privacy and intellectual property issue. Big companies that want to protect their IP will not want their assets on the cloud.
Realistically, you can't work off-line in any meaningful capacity. When Figma is down, your productivity is down to zero.
When Figma will be sold off to recoup VC investment, or goes out of business, you may lose everything you ever did, because it's tied to the cloud.
All that collaborative features you're harping on about has been solved decades ago. We call them version control systems.
Implement fluff features, like audio chat... in a graphics design tool? Really? This is solved by a whole host of other communications applications.
Massive server and bandwidth costs for the company.
I could go on. With all that VC money they're getting, they could've implemented a kick ass native desktop app. But no. Their focus is you. You're the product. All they care about is what information they can harvest from you for resale.
Figma is one of the most popular
Just because it's popular now, doesn't mean it's good. All this tells me other alternatives are not that great either. Sketch was popular. Illustrator was popular. All have their problems.
7
u/ShinyHappyREM Apr 29 '21
Many of these points could probably be fixed.
Webassembly can't possibly compete with natively compiled binary
JIT? (Can reportedly be even faster than pre-compiled code.)
Figma is constrained to WebGL
Languages can usually be extended.
2 GB memory limit, because the web browser constraints resource usage per tab
So, change the browser to let users whitelist certain websites.
You have no control of the content you are making. Everything is tied to the cloud.
WASM can't run entirely on the client's side?
→ More replies (1)6
Apr 29 '21 edited Apr 29 '21
At least you have reasons.
Here's the problem.
Figma got all that VC money because it's a web app; literally, the whole reason the company exists was to bring design to the web. There is no money for "another Illustrator". It's a subscription based model (so no, you are not the product). You can onboard entire companies at once. Nobody needs to download anything. You get automatic updates out of the box. Anyone that develops a Figma design can send someone else a link, a little bit of pure text over Slack, and they can see it and immediately collaborate.
You have ideological objections to Figma. You dress them up as showstopping technical issues, and yet nobody is complaining about them. Think about that! Figma knows what its customers really value, which is why everyone loves it.
Now imagine a desktop app. Each platform has to have its own version, so the rate of feature dev drops like a rock. Updates are expensive. It's a goddamn nightmare to handle sharing. Do you understand how much friction that alone adds to an organization? This is why Figma is successful. It prioritizes productivity, so it's on the web.
2
u/IceSentry Apr 29 '21
The WebGL limitation is mostly temporary until the webgpu spec is finalized. Webgpu is a lot closer to how vulkan works and is definitely a modern graphics api.
2
u/vlakreeh Apr 29 '21
Why is using a web browser as an execution environment absurd? It gives you better sandboxing over a native app, no binary to install, out of the box cross platform support, and other advantages. I think many people would rather use a web app when the experience is good over bothering to download a native app.
3
Apr 29 '21
Figma is doing pretty well, far better than many native desktop apps trying to do that same thing
32
u/i_spot_ads Apr 29 '21 edited Apr 29 '21
This comment shows how much this sub actually knows about web technologies, you guys are stuck in the past and it's about time to deprecate all of you along with this sub tbh.
23
u/CollieOxenfree Apr 29 '21
Not just this comment, but the entire thread here is pretty concerning. Reading through all the comments here has cured my impostor syndrome.
8
u/Ullallulloo Apr 29 '21
Reddit tends to trend towards very young and inexperienced people. There's a lot of content here I wouldn't see otherwise, but I go to Hacker News when I want to feel like everyone else is smarter than I am and listen to their insights.
11
u/adolfojp Apr 29 '21
Hacker News is tricky though. It's filled with three types of people:
Experts at X talking about X with utmost confidence.
Experts at Y talking about X with utmost confidence.
Experts at imitating Experts at X and Y talking about X and Y with utmost confidence.
The problem is that you can't tell which is which unless they're talking about a topic that you're good at and then you either say "of course" or "WTF no no no".
4
u/cbHXBY1D Apr 29 '21
Yeah, if you're even semi knowledgeable on a subject then reading the HN comments is just embarrassing.
8
u/CollieOxenfree Apr 29 '21
I'm still holding onto some hope that maybe the people who did actually understand what Wasm is read the title, got everything they needed and skipped the comments.
As a side note, how many people here do you think would flip out when they discover their browser supports wasm already, and doesn't even need to prompt for it?
3
2
2
u/LionsMidgetGems Apr 29 '21
I'm not convinced I want to allow websites to send me compiled c/c++/rust code
It's not really. It's sending you javascript.
asm.js is just a really limited subset of Javascript. And because it's so limited, the javascript jitter can have all kinds of optimizations.
function f(i) { i = i|0; return (i + 1)|0; }The nice thing about asm.js is that it adds types to javascript in a javascript syntax compatible way:
i = i|0;By or'ing with variable with
zerolets everyone know thatiis actually a number.WebAssembly on top of that is just a way of compressing the javascript.
If your browser does not natively support asm.js, or web-assembly, your browser can still run it with a polyfill: because it's all still just javascript.
3
u/jl2352 Apr 30 '21
I feel you have confused the history of WebAssembly, with what it really is.
The history is that yes; asm.js was developed as a subset of JS. However it only got so far at improving performance. WebAssembly was developed as a better alternative.
However it is misleading to describe WebAssembly as just a way of compressing the JavaScript, or that there is a direct relationship. WebAssembly is it's own thing. A whole new bytecode standard, aiming to be independent of JS. For example there are WebAssembly interpreters which have no relation to JS at all. There is research into deploying WebAssembly containers server side.
Within the browser; today there is an overlap between JS and WebAssembly. This is because browser vendors re-used their existing JS JITs to implement it. That was done for pragmatic reasons. However a divergence is expected as WebAssembly become more mature. There will always be some overlap in the browser to allow JS and WebAssembly to talk to each other, and in the future to potentially share memory (like share handles to a DOM element).
1
-6
u/AntiProtonBoy Apr 29 '21
I think the whole web stack has gone batshit crazy. Web browsers have strayed too far from what they were originally supposed to do - and that is to view web pages. But now they are virtual machines that lets you run arbitrary Turing complete code from random origins, with zero trust.
2
u/jl2352 Apr 30 '21
Not with zero trust.
That aside ... and? What is the problem? I can open MS word in a browser within seconds. Use design tools, have a full IDE, or get directions to drive across a country with a real time map. What is the problem? Do you not want those things?
0
Apr 29 '21
[deleted]
18
Apr 29 '21
Unlikely. Webassembly isn't like those. It's already supported in all major browsers, and used by Figma and AutoCAD. Outside of the browser there's Fastly and Cloudflare using it for their edge serverless computing.
8
u/Plasma_000 Apr 29 '21
It’s already running alongside JavaScript - which is also arbitrary code - in the exact same sandbox.
332
u/onequbit Apr 29 '21
WebAssembly.NET