
Clang runs in the browser and compiles C++ to WebAssembly - lifthrasiir
https://tbfleming.github.io/cib/
======
djsumdog
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 full circle? It's like running
cygwin in wine or an NES emulator inside of Windows 95 VM.

~~~
ehnto
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 also nice that it is seamless with the browsing experience, but I have
to wonder if it hasn't just turned out that the typical browser interface is a
better interface for computing than most popular OS have been? As the OS and
browsers start to see parity, are there lessons from browsers that we can
integrate into the OS?

~~~
modeless
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 native API
prioritizing performance first and security last. It wasn't until browsers
decided to expose OpenGL that the necessary work was done to make a graphics
API safe for untrusted code. And who did that work? The browsers had to do
most of it themselves.

~~~
bjoli
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 a billion edge cases because somewhere along the
road we decided that faulty code is OK. Everything with tonnes of state that
interact in ways that can't ever be fully tested or verified (because of an
almost infinite variety). Let's also not forget that a large part of that is
done at the very bleeding edge of CS research. I wouldn't trust anyone to do
that in a safe way.

To me, a kernel seems simple in comparison.

~~~
pjc50
> 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.

~~~
bjoli
Yes and no. Trust on first use is a thing. A web page is trust every time.

Sandboxing of native apps are getting easier by the minute , at least for
Linux. Flatpack and snappy aren't there yet,though...

------
sehugg
Clang is pretty big -- as a comparison, my Z80 IDE which uses SDCC (Simple
Device C Compiler, i.e. no C++) loads about 2 MB of WASM + 2 MB of data and
executes a compile/assemble/link cycle in about 0.5 sec for a small program:

[http://8bitworkshop.com/v2.1.0/?platform=mw8080bw&file=gfxte...](http://8bitworkshop.com/v2.1.0/?platform=mw8080bw&file=gfxtest.c)

Most of the execution time is spent in SDCC's register allocator, which was
recently rewritten to generate better code but unfortunately is a lot slower
than the old allocator.

~~~
seibelj
What a cool website (and book), I love what you have accomplished.

------
z1mm32m4n
I guess this just means we’re one step closer to Gary Bernhardt’s vision:

[https://www.destroyallsoftware.com/talks/the-birth-and-
death...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript)

~~~
nitemice
Every time something like this is posted, I always think of that video.

As ridiculous and played-for-laughs as it is, it's looking more and more
accurate (in one form or another) every day.

~~~
AnIdiotOnTheNet
If we have learned anything in the past 2 years, it is that the difference
between parody and reality is vanishingly small.

~~~
z1mm32m4n
What happens when the stuff like the “exclusion zone” and the war from
2020–2025 come true...? ¯\\_(ツ)_/¯

------
shalabhc
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 computer' will finally be fully virtual -
a well defined collection of 'apps/data' URLs that materializes wherever I can
open one of these webassembly VMs.

With this webassembly VM, early bound (precompiled) lower level languages may
not have a strong advantage over late bound, dynamic ones, because the
compiler is part of the OS layer (as it should be).

The world seems to be slowly moving, in a roundabout way, towards the OS-
browser idea from Alan Kay.

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

~~~
mailslot
Webassembly doesn't require you to install Oracle software, or lag your
computer for 30 seconds while it starts up... And it doesn't require Swing or
AWT. So, there are those _minor_ improvements.

~~~
pjmlp
Swing is a very good improvement over HTML UI hacks.

------
ttflee
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...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript)

~~~
no_gravity
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](https://www.networkworld.com/article/3236064)

~~~
ttflee
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.

~~~
beagle3
IBM’s AS/400=eServer is basically implemented this way since 1988 years (some
of it going back to 1979). Everything old is new again.

(It has 128 but pointers, btw - so it’s future proof for at least 20 more
years)

~~~
fasquoika
The original bytecode OS is AFAIK the UCSD p-System (from 1978)
[https://en.wikipedia.org/wiki/UCSD_Pascal](https://en.wikipedia.org/wiki/UCSD_Pascal)

------
xtrapolate
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 as-well. The answer to non-unified
execution environments (as in different operating systems and architectures)
was the rise of high-level, interpreted languages (in addition to
corresponding VMs), and runtime environments which exposed a platform-
independent set of APIs. We've been exploring the possibilities of
implementing bytecode VMs in hardware
([https://en.wikipedia.org/wiki/Java_processor](https://en.wikipedia.org/wiki/Java_processor)),
or running a managed code operating system (Microsoft's Midori) for a while
now, so the concept itself isn't particularly new. What is WASM's advantage
over, say, Java's bytecode? Did we really have to go through so many hoops
(reinvent another instruction set and a VM that can execute it across multiple
platforms)? Why wasn't an existing technology re-used here to achieve the
same/similar goals?

~~~
chuckdries
Well, what would you have replace it?

Like most things that become very popular, the web is becoming an os-like
platform because it solves a problem. Putting your application at a URL is
hugely more accessible than asking someone to download something. Maybe not to
us HN readers, but to my mom, who's skeptical to a fault of anything that says
download, it's huge.

HTML+CSS+JS is everywhere and complete in a way that literally nothing else
is. Yeah C is everywhere but (before nowish) you couldn't write a C
application once and have it run the same pretty much everywhere.

But chuck, you say, HTML has notoriously bad compatibility and working with it
is frustrating. I propose to you that HTML and CSS have so many compatibility
problems because of how pervasive it is and has been for so long, and how many
different implementations of it exist. Anything is bound to develop
compatibility issues when it gets as large as the web.

But you're right, it's suboptimal and other tech has tried to be everywhere.
Java and Flash did try, but have you ever used a java applet? They're fine I
guess, but they're stuck in a square on the page. You can make a java or flash
object take up the whole page and completely control the website but then you
run into accessibility issues and complexity on your part.

Javascript has grown organically over the past decades for a reason, and it's
being used in this fucked up way because, all things considered, it's the best
platform for the job right now

~~~
xtrapolate
Appreciate your insights. I don't really have an answer to your question. I
respect the popularity factor, I just can't help but think that we've had (and
still currently have) competing technologies which are far more mature and
capable. Not saying WASM won't end up on top in the future. There are plenty
of applications today that build on parallelisation, synchronisation
primitives, IO, IPC... all of which are already perfectly possible today over
the JRE/JVM (as an example), but the same can't be said about browsers today
(no doubt that with enough work, it can all change sometime in the future).
Just feels like reinventing the wheel.

------
stevemk14ebr
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.

~~~
frozenport
I disagree. When people start using native languages like C++ for the Web,
they will quickly realize they could have just used C++ to begin with.

~~~
adventured
Getting people to download and install traditional software is a substantial
point of friction. Average users _hate_ managing software installations,
updating, fixing broken installations, dealing with malware, et al. The
problem spans from the enterprise down to normal consumers.

Browsers as a better software platform, will significantly accelerate the rate
at which software eats everything.

Most software should ideally just work, no installs, period. The browser can
act as that platform and it can go a lot further than it has so far. More to
the point, there is no other future outcome than the browser becoming that
vehicle, nothing can stop it from moving that direction at this point.

You don't need something equivalent to maximum native performance to do what
99% of users want to do. The rare edge cases that need extreme performance
will remain native.

~~~
repsilat
Really this just points to a lack of vision on the part of operating systems
people. There is no reason downloading, possibly "installing" (mostly
caching?) and running "traditional software" couldn't be as frictionless as
clicking on a link, but that's just not how the software and security model of
Windows, OSX or Ubuntu (to name just the household names) are set up.

Browsers probably will win, but mostly by accident and as a result of network
effects rather than any inherent qualities. As a platform it's positively
awful, though it is getting better in fits and starts.

Ideally we'd have proper sandboxing, proper compilation, proper libraries,
proper access to hardware. Alas, all of that good stuff is basically a
historical footnote at this point.

~~~
colordrops
It's not either/or. The browsers will probably eventually be integrated into
the OS until they are almost invisible. All apps will be web apps.

~~~
arbie
Chrome must clearly see this as the end of the road on Windows and MacOS. What
incentive do the OS vendors have to champion full-access APIs having feature
parity for OS-level JS engines?

------
mark-r
So Clang itself was compiled to WebAssembly? That's slick, even if it does
take forever to load.

~~~
sitkack
What about packing up web assembly into a single file container like runtime
designed to run server side web applications? This .war (Webassembly ARchive)
file could include the application and all dependencies in a single
installable that is JITd on load. Might be useful for the next generation of
"serverless" cloud runtimes.

~~~
dpratt
I see what you did there.

I’d be all for this, honestly, except that the existing containers (yes, even
Jetty) are too heavyweight for this use case.

What you really want is a stripped down server runtime that loads and starts
your application’s archive, fires it up on a (possibly random) local port and
opens a stripped down Chromium instance that loads the app from that port.

Of course, that sounds a bit like Electron.

~~~
imtringued
Node.js supports webassembly.

------
jokoon
Finally, wasm short-circuited the will of os manufacturers to make their
platform exclusive and incompatible with others.

Now let's see if wasm performs well enough on Android phones, and I guess we
are finally arriving into the software deployment heaven.

~~~
Micoloth
So the mobile part is very interesting to me, as i'm no expert on this: as
cool as it is, isn't this whole webassembly thing a desktop-only thing? There
is no way smartphones will be able to download compile and run this type of
code at accettable speed will they?

Or am i wrong?

------
flavio81
This is just fantastic. The "happy 2018!" news i was waiting for.

As i've said before, little by little we're witnessing the end of Javascript
dominance.

~~~
solarkraft
Webassembly is still loaded through javascript, webassembly "apps" will be
like libraries. You could compile other languages to js before, but the
performance gain is really awesome.

~~~
flavio81
>You could compile other languages to js before

In the mid-term, there will be no more reasons to do that. Just compile those
languages straight to Webassembly.

------
Sreyanth
This is awesome. I was planning to write one myself after I couldn't find any
such Clang runner for browsers. I guess I could just strip off a few overheads
so I can run some pretty small programs to teach algorithms.

------
seibelj
Idea - make a website that lets you compile and test any open source program.
For example, I should be able to clone, compile, and run gedit (a stagnating
text editor included with many linux distros). This would let me quickly
experiment with and edit a variety of programs and tools within the web
browser without needing to get a development system up and running. I bet open
source projects can get a ton of new hackers to continue development on their
programs if everything could be worked on quickly within a web browser.

~~~
exikyut
Main issue is memory usage. Running KDE+Kate -
[http://vps2.etotheipiplusone.com:30176/redmine/emscripten-
qt...](http://vps2.etotheipiplusone.com:30176/redmine/emscripten-qt-
examples/kate/kate.html) \- uses 1793MB (htop VIRT), 416MB (Chrome task
manager). (Oh, and the renderer process wasn't hosting any other tabs.)

Second main issue is speed. qsterix isn't as memory-heavy but runs all Tetris
game code inside KDE JavascriptCore, which as part of the KDE/Emscripten build
is transpiled to JS. In other words,
[http://vps2.etotheipiplusone.com:30176/redmine/emscripten-
qt...](http://vps2.etotheipiplusone.com:30176/redmine/emscripten-qt-
examples/qstetrix.html) is JavaScript inside JavaScript, and on my reasonable-
but-not-last-week-new i3 box, I experience a small pause that I can't explain
when I hit the spacebar to drop a block.

Half of me wants to warn everyone from opening these on their phones or
tablets, the other half wants to know how badly everything crashes. :P

Note: I tried opening the Kate demo a week or so ago on a marginally older
version of Chrome, and the download phase hung. It worked this time though.

~~~
solarkraft
I can't wait to package this up into a beautiful Electron app.

~~~
jcelerier
the whole of qt and kde compiled to javascript and ran as an electron app... i
can't even

------
mailslot
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.

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

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

------
deepGem
This is really slick. Clang took about 20 secs to load on my quad core MBPro.
How does this change web development ? Do we need an Ecmascript equivalent for
C++ ?

~~~
tzahola
>Ecmascript equivalent for C++

W-what?

~~~
deepGem
Sorry, for sounding this stupid. Does this imply you can now do web
programming with C++ instead of Javascript.

~~~
tzahola
Yes. You can build WebAssembly bytecode from C++ and it will run in the
browser like JavaScript.

~~~
deepGem
Thank you. In that case is it possible to access DOM elements within a C++
program the way we do in Javascript.

~~~
tzahola
Not yet, but AFAIK it will eventually.

------
bawana
so does the concept of the 'browser is the OS' , improve security? Is it
analogous to a hypervisor running on a server somewhere, then when you log
into the server, it spins up a vm os _just for you_. Now any hacking done on
that os is isolated and disappears when that instance is closed. in the same
way, when the browser is the os, none of the files,apps or stuff on your
machine is available to it?

------
paulhilbert
So we could finally port windows93(.net) to C++?

------
netheril96
There is actually an immediate real world use for this (not just being a toy):
online judge (like leetcode). Of course, the final evaluation has to be done
on the server to avoid cheating on the test set, but the user can do his/her
own test in the browser without the roundtrip to and from the server then.

------
kgraves
This is neat and shows great potential, I hope in future that Adobe products
would be integrated with WebAssembly or even old products converted to
WebAssembly and running in the browser. We shouldn't be that far off.

~~~
sp332
Are you thinking like Photoshop, or a sandbox for Flash?

------
muthdra

      enlarged memory arrays from 536870912 to 1073741824, took 28094 ms

~~~
exikyut
That's a bit excessive. I got the same with "57 ms", and quite a lot of my 8GB
RAM (and several GB of swap) are used.

~~~
danellis
17ms and 533MiB. Seems like quite a lot of variability. This was Chrome on Mac
OS.

------
MobiusHorizons
Now we just need to compile a browser to webassembly so we can run a browser
in a browser :) then the browser will officially be a complete operating
system.

On a serious note though, this is an awesome example!!

------
AndrewGaspar
This is very cool.

It seems like there's some sort of memory leak, though. If you press the Run
button over and over, you'll get a little message every 2*N runs about
expanding memory arrays by double.

------
nodja
So, until when can we build firefox and run it, in chrome?

------
singularity2001
sorry for negative comment: _) it crashes Firefox_ ) very slow *) "1"s c_str?
srsly??

~~~
gamesbrainiac
Just tried it on Firefox, working fine. Changed the code as well, and still
compiles.

------
MaxBarraclough
And it only uses 400MB of RAM.

Neat though.

------
feelin_googley
It does not run in the browser I am using.

That is one reason I chose it. Choice is good.

------
Kip9000
Impressive as it is, depressing that it enables C++ survival. C++ is a badly
designed mess that gets ever more complicated and most probably the language
itself is order(s) of magnitude complex than the problem you're trying to
solve. Please enable other better designed comparable languages (like,
D,Rust,Nim,etc..)

