Live data from Hacker News

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

tbfleming.github.io

121–130 of 318 posts

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

#121

Earlier quoted context omitted.

SVG + JS is really quite good. You will need a few abstractions to work comfortably with the SVG DOM, but you can easily write these as you need them.

Sounds reasonable. Why don't people use it then? Are there any frameworks already available so one won't have to invent a GUI toolkit from scratch?

One of the “few abstractions to work comfortably with the SVG DOM” that “you can easily write […] as you need them” would be a layout engine. You need one to adjust your UI to the user’s screen size.

Another, I think, is that, to add scroll bars to a view, you have to write SVG scroll bars, make them respond to the mouse scroll wheel, be accessible, etc.

Even if we will get them, eventually, it won’t be “easily”.

I think it is easier to use HTML for layout, and SVG (or canvas) for those views that need it. You can do that now.

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

#122
post #111

Every time I see such news, I tell myself maybe it is the time we port a browser into the Linux kernel and build METAL, like Gary Bernhardt foretold. https://www.destroyallsoftware.com/talks/the-birth-and-death...

Or directly into the cpu. Since there already is a web server in the cpu [1], adding a browser might enable us to run and use web applications without even installing an operating system.

[1] https://www.networkworld.com/article/3236064

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

#123
post #7

People might not like it but i really think native apps are going to die once everyone figures out how to optimize this crazy web stack.

Isn't WebAssembly a VM inside browser ? If so, I am skeptical especially with end of moore's law. Edit: I was a bit mis-informed, the design document is an interesting read.. https://github.com/WebAssembly/design/blob/master/Rationale....

It is a VM, stack-based like the JVM. It is called a "WebAssembly VM" in the document.

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

#124

Next we'll get to a webassembly-only VM that will replace the OS. All 'apps' will run on this VM instead of being native, and most will be cross platform. They'll talk to each other via messaging (using Javascript semantics) instead of bytes-over-pipes as they do today. An integrated globally available, namespaced data store API might replace the filesystem. Each app+version will be accessible by a distinct URL. 'My…

Replace “WebAssembly VM” with “JVM” and you will see how it’s already available, and why it won’t catch on.

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

#125
post #35

People might not like it but i really think native apps are going to die once everyone figures out how to optimize this crazy web stack.

It's definitely possible but we went through all of this a decade ago with Adobe Air, Microsoft Silverlight, and JavaFX. Nearly a decade before that, in the early 2000s, we went through this with Macromedia Flash, Java Applets, and Microsoft ActiveX. Trying to replace native applications with runs-in-the-browser RIAs is nothing new, but we're at least finally agreeing on the language/implementation, so maybe this tim…

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.

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

#126

Earlier quoted context omitted.

Yes. Please, someone, make gamedev in the browser a reality. There are a thousand hitches: Why can't I install a 9GB game on the browser? We need all that space for textures. "But what if –" Oh come on, we can figure it out. There must be some way. Also UDP. Yeah, we have WebRTC, but look up Beej's guide to network programming. That's the threshold of intelligence required. Currently to get WebRTC working with UDP fo…

It's been proposed a few times[1], the WebRTC crowd just shows up and says that WebRTC is "good enough" and the cycle continues. Never mind that the dependency graph for WebRTC is way too large and that WebRTC is just too complicated for GameDev needs. [1] https://github.com/networkprotocol/netcode.io

I’ve done webrtc “servers” (in C, not some nodejs bindings for the chromium implementation) and webrtc P2P. It really is “good enough” for a lot of things.

But not game developers, who are used to dealing with a very forgiving environment that will let them do stupid things quickly.

I have watched game developers in earnest busy wait a network thread “for speed reasons” but also derive approximate linear solutions to nonlinear problems using overflow, wraparound, and so on.

Some of the dumbest guys I’ve ever met doing some of the cleverest things, or the smartest guys showing off just how dumb sleep deprivation makes you. I’ve never been quite sure.

Games are beautiful. Game developers are beautiful. Game code almost never is.[1]

Joining a new game dev team you think this is going to be it, finally some clean code the way the masters do it, but then it isn’t.

That is to say: Games aren’t how to do software development, but proof of how far you can get by doing software development wrong.

I have thought about packaging my webrtc “server” as a library and selling it to game dev shops, but I don’t think the professional browser market is there yet.

[1]: I’m aware of a small number of examples to the contrary, but there are many more counter examples.

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

#127
post #111

Every time I see such news, I tell myself maybe it is the time we port a browser into the Linux kernel and build METAL, like Gary Bernhardt foretold. https://www.destroyallsoftware.com/talks/the-birth-and-death...

Or directly into the cpu. Since there already is a web server in the cpu [1], adding a browser might enable us to run and use web applications without even installing an operating system. [1] https://www.networkworld.com/article/3236064

The METAL (proposed by Gary Bernhardt) is not about running in CPU, but running all software in byte code and render native code obsolete, by implementing software process isolation and save the overhead of syscalls, memory mapping and protection rings.

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

#128

Next we'll get to a webassembly-only VM that will replace the OS. All 'apps' will run on this VM instead of being native, and most will be cross platform. They'll talk to each other via messaging (using Javascript semantics) instead of bytes-over-pipes as they do today. An integrated globally available, namespaced data store API might replace the filesystem. Each app+version will be accessible by a distinct URL. 'My…

Replace “WebAssembly VM” with “JVM” and you will see how it’s already available, and why it won’t catch on.

The big difference is that the "Browser VM" has well defined permissions to access resources on the host machine. Just like phone OSes do today. Bluetooth API, Files API, Location API, etc.

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

#129
post #41

Earlier quoted context omitted.

I have been thinking about why we have ended up here, and why not just native apps. The obvious answer is that it makes applications portable, which is great. The other key component I think is delivery. You don't ever install anything, it just exists when you ask for it. That is something native applications have never done, and not even something like JVM has done even though it addresses portability too. It is als…

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…

I agree a lot with your comment. But it should also be noted that users have very little choice on what code they run when surfing the web. So in one way, browsers cause the problem they then have to solve.
Post reply on HN