'Running Clang in the Browser Using WebAssembly' (wasmer.io) 30
This week (MIT-licensed) WebAssembly runtime Wasmer announced "a major milestone in making any software run with WebAssembly."
The announcement's headline? Running Clang in the browser using WebAssembly... Thanks to the newest release of Wasmer (4.4) and the Wasmer JS SDK (0.8.0) you can now run [compiler front-end] clang anywhere Wasmer runs! This allows compiling C programs from virtually anywhere. Including Javascript and your preferred browser! (we tested Chrome, Safari and Firefox and everything is working like a charm)...
- You can compile C code to WebAssembly easily just using the Wasmer CLI: no toolchains or complex installations needed, install Wasmer and you are ready to go...!
- You can compile C projects directly from JavaScript...!
- We expect online IDEs to start adopting the SDK to allow their users compile and run C programs in the browser....
Do you want to use clang in your Javascript project? Thanks to our newly released Wasmer JS SDK you can do it easily, in both the browser and Node.js/Bun etc... Wasmer's clang can even optimize the file for you automatically using wasm-opt under the hood (Clang automatically detects if wasm-opt is used, and it will be automatically called when optimizing the file). Imagine using Emscripten without needing its toolchain installed — or even better, imagine running Emscripten in the browser.
The announcement looks to a future of compiling native Python libraries, when "any project depending on LLVM can now be easily compiled to WebAssembly..."
"This is the beginning of an awesome journey, we can't wait to see what you create next with this."
The announcement's headline? Running Clang in the browser using WebAssembly... Thanks to the newest release of Wasmer (4.4) and the Wasmer JS SDK (0.8.0) you can now run [compiler front-end] clang anywhere Wasmer runs! This allows compiling C programs from virtually anywhere. Including Javascript and your preferred browser! (we tested Chrome, Safari and Firefox and everything is working like a charm)...
- You can compile C code to WebAssembly easily just using the Wasmer CLI: no toolchains or complex installations needed, install Wasmer and you are ready to go...!
- You can compile C projects directly from JavaScript...!
- We expect online IDEs to start adopting the SDK to allow their users compile and run C programs in the browser....
Do you want to use clang in your Javascript project? Thanks to our newly released Wasmer JS SDK you can do it easily, in both the browser and Node.js/Bun etc... Wasmer's clang can even optimize the file for you automatically using wasm-opt under the hood (Clang automatically detects if wasm-opt is used, and it will be automatically called when optimizing the file). Imagine using Emscripten without needing its toolchain installed — or even better, imagine running Emscripten in the browser.
The announcement looks to a future of compiling native Python libraries, when "any project depending on LLVM can now be easily compiled to WebAssembly..."
"This is the beginning of an awesome journey, we can't wait to see what you create next with this."
ActiveX returns (Score:5, Insightful)
Re:ActiveX returns (Score:5, Insightful)
The tech nerds faith in solving everything with MORE tech features will eventually repeat the mistakes of history again and again... giving us more employment as we repeat the same pointless cycles.
ActiveX, Java Applets, WASM eventually... they'll add the "missing" features like direct browser or OS access. Like how they've optimized javascript to dynamically recompile for speed opened up some vectors. Funny how size and speed go up but we will waste effort and lower security in pursuit of optimizations whose benefit is lost before implementation on new hardware... usually so advertising related software can get more bloated...
We can't have a microkernel OS because of "speed" yet we've lost more speed with tons of less important features. I'll gladly lose some IO performance when I got such a huge boost migrating to SSD. Remember when Windows 98 transitioned to a much better NT based OS and the gamers were holding onto their unstable machines for a higher frame rate?
Re: (Score:2)
direct browser or OS access
They already have more memory available to them than entire older machines had permanent storage space. In addition to opening arbitrary connections, running native code, directly accessing peripherals, and permanent storage of their own. At this point the browser *is* an OS. Most "developers" don't code for native, they code for the browser using native where required.
usually so advertising related software can get more bloated
Well of course. The industry realized a long time ago that micropayments were the only means of sustaining themselves. You can't sell a go
Re: (Score:2)
> We can't have a microkernel OS because of "speed"
Sure you can. You can have any kind of kernel you want.
Just write one and convince people to use it.
Re: (Score:2)
Re: (Score:2)
"Any WASM code that runs in a web browser doesn't have access to anything it isn't supposed to. Y'all are just terrified of browsers and javascript without even really knowing why."
Are you that ignorant of history? Browsers are some of the LEAST secure pieces of software in existence.
Re: (Score:2)
How many browsers / security programs are searching for common exploits in source code form?
Even if they are, how many are going to be successful in guarding against easily randomized variants?
Re: (Score:2)
> Previously if you wanted to compile your own customized payload you needed to either do it on the server or write a custom assembler in WASM.
I'm sorry, that is not relevant. If you compile C code offline using Emscripten or the like, you can just put the output on a web site and any browser that visits will execute it without complaint.
Being able to compile it within the browser doesn't add any capabilities that aren't already there.
Re: (Score:2)
As I understand it, there are two major differences between Wasm and ActiveX.
1. Wasm runs on any major browser. ActiveX never ran on anything but Microsoft browsers.
2. Wasm doesn't provide the executing code with full access to the underlying machine, as ActiveX did. In other words, it doesn't suffer from the same security vulnerabilities.
It's true that Wasm has some serious shortcomings, such as being forced to load large binary frameworks (libraries) in order to provide compatibility with traditional fram
Re: (Score:2)
Wasm is more like java applets than ActiveX.
Back in 2000, we built a fat client web application which used a java applet running in the background which used javascript to display pages, cache things and do database connections etc. This saved a lot bandwidth on the restrained slow satellite link that app used. The satellite link was a phone link using conventional modems for ppp TCP-IP.
First time it loaded it took a while to download all the applet java code but then after that it was much quicker than a r
Sounds like a great platform for viruses (Score:2)
Re: (Score:2)
How would this be so? Wasm doesn't provide higher permission levels than traditional javascript. it's not like anybody actually looks at minified javascript libraries to inspect them for viruses already.
Re: (Score:2)
Exactly. It's hard to see how this will create any security issues that WASM and JS don't already have. I mean, you can *already* compile arbitrary C code to WASM (using the Emscripten tool chain, for instance), slap it on a web site, and have it executed in any modern browser that visits the page.
Re: (Score:2)
WASM isn't native.
Ooh! Ooh! (Score:3)
Neat! I plan to cross-compile Firefox into WASM so I can run the browser in the browser!
Damn. (Score:2)
You beat me to it.
Re: (Score:3)
Re: (Score:1)
Dawg
Tech is like an onion (Score:2)
So, we can run a virtual machine in the browser which compiles a browser in which any code compiles to run programs like bots and adware and worms.
Yeah, like an onion, it stinks.
I never understood... (Score:3)
...the fascination with running more and more software in a browser.
A browser is a poor OS. There are better choices.
You can hammer in a screw with a wrench if you try hard enough, but it's better to use the proper tool for the job
Re: (Score:2)
One reason. The browser is the one "OS" that literally everyone has. If you're on Windows, Mac, iOS, Android, ChromeOS, it doesn't matter, everyone with a browser can run WebAssembly. Further, every major browser supports it. So why *wouldn't* developers be drawn to a platform that literally everyone has, instead of having to rewrite their code for each major OS?
Re: (Score:2)
The primary reason is that you don't have to fool around with distribution, installers, and similar folderol.
You may not like it, but it's an extremely serious advantage nonetheless.
It's funny (Score:2)
Makes one wonder how it would have gone if they'd acknowledge that that was the plan originally and follo
I hope this never catches on (Score:1)
Re: I hope this never catches on (Score:1)
Never catches on.....Like jit? It was supposed to be a preprossor firmware abstraction.
blast from the past (Score:2)
WASM is a low-level runtime, we get it. (Score:3)
It's become a bit of a sport and hacker pastime to compile everything under the sun to WASM and launch it in the browser. The most impressive stunt in that regard IMHO being Automattic (the commercial WordPress entity) compiling the entire LAMP stack with a ready-to-run WordPress installation to WASM and providing it as an URL for anyone who want's to toy with and try out WordPress without installing anything. True thing, no joke. It's pretty crazy and the results are quite impressive [wordpress.net]. Although I did spend an afternoon pissing myself with laughter so much that eventually my belly hurt when I read the announcement.
However, given the attention WASM and the compliation to WASM has gotten, it is no surprise that you can do this sort of thing with single programs. It's impressive that entire stacks and systems apparently can now do this too. I'm pretty sure there are entire Linux distros out there built for running on WASM. It's a neat hack and demonstrates the power of todays laptops and browsers and for sophisticated rich client webapps it's a god-send, but this is still very niche and it will likely remain that way.
Inferiority complex (Score:1)
These guys must be compensating for some inferiority complex, 'I do JS then I'm not a real developer' style.
Nothing good could come out of this excepting some claim that "see we can serve you JS tracking code without affecting your battery" which can never the as efficient as _not_ running crappy 3rd party code in the first place