Live data from Hacker News

Clang runs in the browser and compiles C++ to WebAssembly

tbfleming.github.io

241–250 of 318 posts

Re: Clang runs in the browser and compiles C++ to WebAssembly

#241

Cool! Now I just need the JVM as a clang target, and then I'll never have to use anything other than C++ ever again!! :D Webassembly has a tad more promise than ActiveX.

Perhaps you could use node.js to compile your C++ code into a native WASM module?

lol. Gross! Perhaps if Node.js... omg. Nevermind. You can call pthreads from Node.js. :)

Re: Clang runs in the browser and compiles C++ to WebAssembly

#242
post #50

Earlier quoted context omitted.

Currently quite a lot, more than 10 with the current stable Firefox release, here's a test page: http://pmav.eu/stuff/javascript-webworkers/ (Web workers are around since ca. 2010 so this is not very new)

Do they require you to serialise data to strings or is it possible to transmit typed arrays?

There is support for efficiently passing data around. You can directly get binary typed arrays from XmlHttpRequest without intermediate processing, and you can pass them around without memory copies to WebWorkers using Transferables.

More recently you have shared typed arrays that work like shared memory between threads (as of Safari 10.1 / Chrome 60, Firefox too)

Re: Clang runs in the browser and compiles C++ to WebAssembly

#243
post #139

Earlier quoted context omitted.

The answer is that browsers provide something that users desperately need and no operating system has ever provided: a sandbox strong enough to run completely untrusted code. The success of browsers is an indictment of the entire field of operating systems research. They have either failed to recognize the need or simply failed to deliver that kind of security. For one example take WebGL. For decades OpenGL had been…

> a sandbox strong enough to run completely untrusted code No browser has provided that either. In fact, browsers are by definition a security anti-feature because they are always connected to the network and the customer/user data lives on the network. Even if they manage to solve the problem of computers getting hacked when visiting websites they are very unlikely to solve the problems of tracking and private data…

Browsers do a whole lot better than the status quo for apps in the '90s and early 2000s, which was "offer a Windows .EXE to download, and monetize with spyware".

Re: Clang runs in the browser and compiles C++ to WebAssembly

#244
post #222

Earlier quoted context omitted.

Guns aren't dangerous! It's the bullets that will get you!

This is not an appropriate analogy. Guns and bullets are designed to kill, but browsers and the download capability are not designed to infect your computer. Rather, they are designed with an opposite goal.

An "infection" in this case would be the execution of some other person's code on my computer. Browsers have been designed specifically to do this since Javascript was invented.

The only difference between malware and "regular-ware" is whether the code meets certain user expectations about what it will and will not do.

Re: Clang runs in the browser and compiles C++ to WebAssembly

#245
post #139

Earlier quoted context omitted.

> a sandbox strong enough to run completely untrusted code No browser has provided that either. In fact, browsers are by definition a security anti-feature because they are always connected to the network and the customer/user data lives on the network. Even if they manage to solve the problem of computers getting hacked when visiting websites they are very unlikely to solve the problems of tracking and private data…

Browsers do a whole lot better than the status quo for apps in the '90s and early 2000s, which was "offer a Windows .EXE to download, and monetize with spyware".

Web apps are already spyware by default, as everything gets done on a computer I don't have access to.

Just plain pretty TTYs.

Re: Clang runs in the browser and compiles C++ to WebAssembly

#246
post #178

Earlier quoted context omitted.

> The answer is that browsers provide something that users desperately need and no operating system has ever provided: a sandbox strong enough to run completely untrusted code. The success of browsers is an indictment of the entire field of operating systems research. They have either failed to recognize the need or simply failed to deliver that kind of security. The JVM more-or-less managed it. Modern hypervisors do…

The JVM took too long to achieve that ideal in a way that actually worked for end-user applications. Early java-based client applications had a horrible user experience. Version conflicts were very annoying, especially on windows where you didn't have a command-line culture comfortable with simply switching between versions by modifying PATH and JAVA_HOME. And even when you didn't have version conflicts, Java applica…

Browsers have worse history with compatibility, they are more memory hungry than Java, performance is worse, their UI isn't even trying to mimic system UI (Java could have system L&F for 10 years at least, likely more).

Re: Clang runs in the browser and compiles C++ to WebAssembly

#247

So the web browser is pretty much a mini operating system. Firefox and Chromium seriously feel like they have the longest compile time out of any package in Gentoo, except maybe Libreoffice. It has tons of embedded packages that it doesn't pull from the system/native (jpeg and png decoders and such). So with a lot of these neat things where we compile stuff or run a Linux kernel in the browser, we've pretty much come…

> So the web browser is pretty much a mini operating system.

Was this not the tacit reason for Microsoft's burying of Netscape? A browser that is a portable platform for applications was a threat to its de-facto near-monopoly in operating systems for personal / end-user computing.

Re: Clang runs in the browser and compiles C++ to WebAssembly

#248
post #210
post #165

Earlier quoted context omitted.

Native apps had a head start: they don't load every asset from a potentially untrusted source. I would say that the browser most certainly has the biggest attack surface of any software in regular use. Your average browser is insanely complex. In fact, it is the only piece of software on my computer that scares me. Multiple JITs, font rendering, parsing, layouts, compression, image handling, sound and of course about…

> Native apps had a head start: they don't load every asset from a potentially untrusted source The whole native app is "untrusted" at the point of install. Even an app store offers a fairly thin guarantee about what apps are actually doing. It's far easier and less risky to open a web page and start doing something than install a native app.

I only think this applies to certain ecosystems (ones where the motivation or incentive to provide the software doesn't align with ensuring user's safety or security).

The native apps I run on my Linux laptop, for example, I trust quite a bit. There may be a way for someone to sneak in some obfuscated code that does some harm, but I think the risks are much lower than many of the alternatives.

Re: Clang runs in the browser and compiles C++ to WebAssembly

#249

Earlier quoted context omitted.

It is that simple. And a bummer because I think HTML is a pain for things that aren't documents. And JS UI frameworks feel like hacks too. Unity already supports the web, but I don't think that'll matter for AAA games. People who buy computers specifically to play them will care about the slight performance hit and not want to keep the games they bought and spend a lot of time with as bookmarks to web pages. Non-perf…

> HTML is a pain for things that aren't documents. Indeed it is but there seem to be no relevant alternative. The only thing that is better [for apps] is XAML (WPF) but it is Windows-only.

No, there are other XAML variants, like Avalon and Xamarin.Forms.

JavaFX also follows the same design ideas.

And there is QML as well.

Re: Clang runs in the browser and compiles C++ to WebAssembly

#250

Earlier quoted context omitted.

Most users spend >80% of their time in the browser. It's probably that simple. If you have a thing and you need users, are you really going to deliver it as a Qt app? Unless you're bitcoin, it's hard to think of a case. I'd say "or a game," but many are webapps. And at this point some of the hollywood-grade games might figure out a way to be coming to browsers soon. Unreal did it.

If you need performance, and portability, and something that can be more easily maintained, for example QT is the only way. Power tools that are graphics heavy, or music applications, or anything that requires heavy multimedia lifting, you're not gonna do that currently in the browser. Maybe this will change in the upcoming years though also, I have a feeling the client/server bridge will be getting closer and closer…

Most of the time someone puts an WebGL demo here, it fails to work consistently across all my mobile devices.

Some of which don't have any issue running OpenGL ES 3.x games.

Post reply on HN