Live data from Hacker News

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

tbfleming.github.io

311–318 of 318 posts

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

#311

Having some random thoughts about the comments here, some of which talk about having a "browser" drive large parts of what we consider today an "operating system". I agree that certain aspects of what most modern operating systems do today can be abstracted away behind a unified, convenient (and perhaps browser-accessible) API. The entire user-experience stack comes to mind immediately, but there are counter examples…

>What is WASM's advantage over, say, Java's bytecode?

Precise control over memory layout and allocation which can translate into massive performance gains of several orders of magnitude.

LLVM IR isn't stable accross LLVM versions.

Webassembly is the solution to a problem that stayed unsolved for decades.

There is no alternative to webassembly. It is in it's own category.

Probably the closest competitor you could find is LuaJIT with it's FFI module but LuaJIT wasn't designed as a compilation target. It'd suffer from the same problems that asm.js did.

JVM bytecode is stable but high level.

LLVM IR is unstable and low level.

WebAssembly is stable and low level.

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

#312
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…

I've been using the web for over twenty years and it has never harmed my computer or invaded my system in any way. I do think I've seen adware and scumware that may have originated on the web on friends computers but I'm pretty sure they did something like allow a toolbar to be installed. Can you give an example of an exploit that did not require user permission,did not use a plugin, and that allowed arbitrary code e…

Would the recent Spectre vulnerability be an acceptable example for you?

There are a gazillion others, but this one is nice and sweet and exposes the whole web app strategy as completely bankrupt from a security perspective.

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

#313
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".

Yes, they are much better than your example, which is one of the worst things that could happen. :)

But paid software in the 90s and 2000s was fine, no network connectivity, didn't even check for updates. Heck, a lot of freeware was fine.

Then the market changed and spyware as a service became very profitable. The genius of this Spyware 2.0 was that it offered some benefits while not abusing the collected data in any obvious ways, like stealing your money. Browsers are helpless against this, in fact they are enabling the whole business model through their support of web apps and increasingly complex APIs.

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

#314
post #250

Earlier quoted context omitted.

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.

Yeah I'm actually afraid to run some of the more complex WebGL on my laptop, as I've had occurences of them hard locking my computer, which should not happen.

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

#315

Earlier quoted context omitted.

If you have an HTML5 game that you own and it doesn’t require a server (it runs entirely on the client side) then there is no technical reason it can’t be archived. You can’t run google docs offline because what would that even mean? One of the main features of google docs is the live collaborative editing. It’s a multiplayer game that requires a host server. You can architect your game to be friendly to being archiv…

> If you have an HTML5 game that you own and it doesn’t require a server (it runs entirely on the client side) then there is no technical reason it can’t be archived. If a game is fully available on the client side - it doesn't just need to run on the client side, but have everything available on the client side, data files and all - then yes you can archive it. But this is a very limited case and so far only the mos…

> is a feature but i'd say that the main feature is being able to edit documents. In terms of games, it is a game with multiplayer features that still requires a host server for its singleplayer part (which is generally something that is frowned upon).

Uh, before Google Drive, I'm not sure people were looking for a substitute to Word or other word processors. The "Killer Feature" of Drive is that multiple users can collaborate on the same document, hosted online, in real time. If anything, Google Drive has less features than Word overall. It's having "one true source" instead of emailing around mutliple drafts that is the killer feature for most people. Or having access to that document across all their devices. You could build an offline text editor in the browser, but why would you? (Then again, I use VSCode every day which runs on electron and works totally fine offline).

Edit: I just realized, you CAN run google docs offline. https://support.google.com/docs/answer/6388102?co=GENIE.Plat...

> Technically yes, but things aren't black and white - there are "natural" tendencies in each approach with the web approach leaning heavily towards network reliant applications and the native approach avoiding it.

The native approach has it's own "natural tendencies" that are anti-user, but I'll agree that yes, there are a lot of games that are unarchivable. I don't disagree with that.

> I'd rather not see (offline) games in the browser, or any other online-based method, personally.

This is the statement that you made that motivated me to respond. This is why I tended to ignore what some businesses might do and focus on the developer perspective of "what is possible with these technologies." Because we're already talking about single player offline games.

I guess I'm focusing on the developer side because you seem to be focusing on all of the anti-user things that game devs might do, to which I say "aren't they already doing those on native apps?" I just don't see how the web can make the situation worse. Everyone isn't going to want to play every game in the browser. However, there is great potential for multiplayer games, there is great potential for single player games that compete with mobile (which is by far the most anti-user platform of all!). Yes, people will use for other things, but they're already doing that without the web's help anyway.

Another Edit: > If a game is fully available on the client side - it doesn't just need to run on the client side, but have everything available on the client side, data files and all - then yes you can archive it. But this is a very limited case and so far only the most simplistic games can be distributed like that.

This is increasingly possible with WASM and WebGL.

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

#316

Earlier quoted context omitted.

> If you have an HTML5 game that you own and it doesn’t require a server (it runs entirely on the client side) then there is no technical reason it can’t be archived. If a game is fully available on the client side - it doesn't just need to run on the client side, but have everything available on the client side, data files and all - then yes you can archive it. But this is a very limited case and so far only the mos…

> is a feature but i'd say that the main feature is being able to edit documents. In terms of games, it is a game with multiplayer features that still requires a host server for its singleplayer part (which is generally something that is frowned upon). Uh, before Google Drive, I'm not sure people were looking for a substitute to Word or other word processors. The "Killer Feature" of Drive is that multiple users can c…

I think we're focusing too much on the specifics of Google Docs, replace Google Docs with any other web application that has a desktop equivalent.

> Edit: I just realized, you CAN run google docs offline. https://support.google.com/docs/answer/6388102?co=GENIE.Plat....

Yes, but i'm not talking about being able to run something offline, i'm talking about being able to take Google Docs, put it on a CD, DVD, external hard disk or whatever and have it working in 10 years or whatever independently from Google's servers, pretty much how you can do today with -say- Microsoft Office 95 (or any other desktop application available in downloadable or physical format).

> I guess I'm focusing on the developer side because you seem to be focusing on all of the anti-user things that game devs might do, to which I say "aren't they already doing those on native apps?"

> [...]

> This is increasingly possible with WASM and WebGL.

It was possible ever since the days of Netscape when could encode data as arrays in JavaScript and you could make (simple) games with all assets in a single easy to copy around HTML file since Internet Explorer 8 was released.

WASM isn't any different from JS when it comes to how data is accessed. Native/offline games (and other applications) have their data stored locally, all the files are available there and to do anything else it needs the developers to go out of their way to achieve that - which is why practically nobody does such a thing. Web-based games would have their data stored remotely so even if you download the entire code of the game on the client side, you still cannot archive it because you'll practically never have access to all the necessary data files (imagine an open world game, for example, that downloads assets as you roam the world).

> possible with WASM and WebGL

And to try and make myself clear, i am not worried about the possibility of doing something, i am worried about the impossibility of doing something: ie. having full control over the software you are using.

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

#317

Earlier quoted context omitted.

in addition, each had an separate graphics api. Which was imperative, not as stable nor backward compatible nor as battlefield-tested as html. Each keyword is a difference between all previous approaches versus html. And sometimes/often regarded as better. Every programmer knows html though not the frameworks. But these are seperate.

Yeah, because I can so write a website and only test it in one browser and be sure it will work on all of them, right?

Mostly, which is enough to attract lots and lots of amateurs and high-schoolers. Then there's also the standardization committees and special frameworks.

Also the two most popular browsers are multiplatform. You can write a website and make it work on whatever computer you need.

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

#318

Having some random thoughts about the comments here, some of which talk about having a "browser" drive large parts of what we consider today an "operating system". I agree that certain aspects of what most modern operating systems do today can be abstracted away behind a unified, convenient (and perhaps browser-accessible) API. The entire user-experience stack comes to mind immediately, but there are counter examples…

>What is WASM's advantage over, say, Java's bytecode? Precise control over memory layout and allocation which can translate into massive performance gains of several orders of magnitude. LLVM IR isn't stable accross LLVM versions. Webassembly is the solution to a problem that stayed unsolved for decades. There is no alternative to webassembly. It is in it's own category. Probably the closest competitor you could find…

  Precise control over memory layout and allocation which can translate into massive performance gains of several orders of magnitude.
"Can translate" is not "translates to". Performance gains can be achieved when executing an efficient instruction set over a performant VM. Are you arguing that the JVM falls short as opposed to a browser in that regard?

Also, with most operating systems, physical memory is abstracted from user-mode processes entirely. Kernel-mode is a different story, but I fail to see how a browser/WASM in user-mode do better than a JVM in user-mode in that regard.

  LLVM IR is unstable and low level.
Interesting. What makes an instruction set "stable"? Is this about being backwards/forward compatible? About being encoded/decoded efficiently?

What about the actual APIs exposed by the browser to WASM? Are those considered "stable"? Browsers today "break" all the time - inconsistencies between minors of the same browser, let alone different browser vendors.

Post reply on HN