
Chrome Is The New C Runtime - aagr
https://www.mobilespan.com/content/chrome-is-the-new-c-runtime
======
mwfunk
He's talking about using bits and pieces of Chromium's infrastructure in other
programs, but didn't address open source licensing at all. I haven't looked at
it myself, but according to Wikipedia, Chromium's source is licensed under:
"BSD license, MIT License, LGPL, MS-PL and MPL/GPL/LGPL tri-licensed code,
plus unlicensed files". This is all fine, but anyone using this code needs to
make sure they understand what license(s) the code they are using is under and
what the terms of those licenses are. Just because it's open source doesn't
mean you can just do whatever you want with it; even less restrictive licenses
like BSDL might have conditions like the advertising clause, and you should
always be aware of any copyrights in the code and be sure to preserve them.

That said, I'm sure the Chromium source is a great resource- just a strange
and important omission from the article.

I would also suggest that anyone looking for a platform-independent runtime
check out APR (Apache Portable Runtime):
[http://apr.apache.org](http://apr.apache.org). It's lower-level than some of
the Chromium libraries mentioned in the article (it would be equivalent to the
"base libraries" block in the "Chrome Development Platform" figure), but
sometimes that's all you need. Plus, it's already designed as a library for
other applications to use, there's no need to repurpose anything like you
might have to do with the Chromium sources.

~~~
paulgb
I don't see how it would be different from using any other MIT-licensed code
in your project. The Apache License doesn't seem any less restrictive than MIT
at first glance?

Edit: I assumed the entire codebase was multi-licensed, it looks like you're
saying that different parts have different licenses, which does sound like a
headache.

~~~
sanjeevrad
The core Chromium codebase itself uses the same license (a BSD-style license).
Chromium itself uses certain other third-party libraries that have different
licenses.

------
United857
As someone not at Google, but who's re-used multiple parts of Chromium (as
described in the article), the code (especially the stuff under base/) is
possibly the best documented large-scale, open-source C++ codebase I've seen.

~~~
haberman
I haven't worked with Chromium, but the main C++ code-base at Google is like
this for the most part too (especially the core stuff).

The C++ culture at Google is amazing, and proof that large-scale C++ can
actually be really nice if you stay within best practices. It takes a lot of
effort and experience from a lot of knowledgeable people to craft these
practices, but thankfully Google publishes its C++ style guide
([http://google-
styleguide.googlecode.com/svn/trunk/cppguide.x...](http://google-
styleguide.googlecode.com/svn/trunk/cppguide.xml)) so that everyone can reap
the benefits of this.

~~~
prodigal_erik
Avoiding exceptions is a worst practice. The guide even admits they're only
doing it because they're so far beyond a critical mass of exception-unsafe
code that they've lost hope of solving the problem.

If the profession ever wants to produce anything reliable in C++, one of the
first things that needs to happen is to start treating all unsafe legacy code
like toxic waste, marking it clearly, handling it carefully in isolation, and
disposing of it with prejudice as soon as possible. I don't ever expect to see
this, which is partly why I switched to languages that try to handle failures
and mistakes gracefully.

~~~
seabrookmx
> Avoiding exceptions is a worst practice

You say this very matter-of-factly. Many (myself included) do not believe in
exceptions, and in C++ where they are poorly implemented, think not using them
is _best_ practice.

I would summarize, but this 10 year old article I've seen on HN a dozen times
does a much better job than I:

[http://www.joelonsoftware.com/items/2003/10/13.html](http://www.joelonsoftware.com/items/2003/10/13.html)

Error handling is essential, but exceptions are far from a perfect solution.
The Linux kernel is an impressively complicated, and robust piece of software
and they get along just fine without exceptions. One just needs to be vigilant
when handling errors.

~~~
adobriyan
> The Linux kernel is an impressively complicated, and robust piece of
> software and they get along just fine without exceptions.

The amount of error-unwinding goto spaghetti, ERR_CAST/IS_ERR/PTR_ERR/... and
all the bugs coming from it is not "just fine".

~~~
throwawaykf03
But how much of that would be solved by exceptions without convertng to a
fully garbage-collected language?

~~~
adobriyan
Dunno.

Passing -ENOMEM 5 layers upwards stops being fun very quickly.

------
mbrubeck
As an example of this type of Chromium library re-use, Firefox and Firefox OS
use the Chromium ipc library for messaging between the main UI process, plugin
processes, and content processes (in Firefox OS or in Firefox with the
experimental multi-process mode enabled).

[https://hg.mozilla.org/mozilla-
central/file/tip/ipc/chromium](https://hg.mozilla.org/mozilla-
central/file/tip/ipc/chromium)

[https://wiki.mozilla.org/IPC_Protocols](https://wiki.mozilla.org/IPC_Protocols)

~~~
nilsbunger
Yes, we (OP) use the ipc library too. It's a great asynchronous IPC mechanism
which works across platforms.

------
fidotron
Contrary to many, I'm profoundly concerned about the culture around Chrome
development, and the attitude here is indicative of that. There really is a
belief by those that work on it, or have worked on it, that it's much better
than it really is, when what actually happened was it was much better than the
competition at launch, but now there isn't much between them at all. This
notion that Chrome is decent on mobile is still absolutely bizarre.

The more long term concern is the way it's creating a sort of development
priesthood. You have the chosen few that are making decisions and developing
the platform largely in secret and pushing the code out to mere mortals from
on high. This wouldn't be so bad, except the decisions are not made in the
interest of the mortals, but of the priesthood and the strategic interest of
their Googly God, and they exhibit a level of contempt for the mortals by
disallowing them direct access to things such as the components so lauded
here. In an ideal world most of what's mentioned should not be in the C++
layer, but in JS, except the hooks to provide that are simply never going to
be exposed (at least in the near term because of the JS performance it would
be technically dubious), leading to this them and us situation where they get
to develop all the low level stuff, and no one else does, especially if any
patches would conflict with the interest of their lord and master. They simply
aren't dogfooding their entire development stack. Mozilla, for all their
flaws, do actually engage the rest of the world in what they're doing, and
early Java, while slow, did have a relatively small JVM with an enormous class
library which was mostly written in Java itself. You could argue Sun's error
was to Swing too far in the other direction by insisting on being all Java
where at the time it really should not have been.

So yes, sadly I've come to view many Chrome devs as smug self serving slightly
delusional types persistently confused that the masses don't acknowledge their
brilliance, and this piece is evangelism to try and persuade us of this. The
truly scary part of this is they just might be right to have this point of
view in order to prevent what happened to Android where groups outside
succeeded in nullifying many of the expected advantages of a standard open
mobile platform, and I suspect it's this which has led to their open but
closed approach to things.

~~~
jeremyjh
I read an article about using core Chromium components as a cross-platform
library that comes complete with a build system. What did you read about?

------
oscargrouch
Im using the chromium codebase to build a sort of netxgen "browser" (not web
browser).. but more akin to a application platform with p2p in mind (and other
crazy ideas). While the idea proposed by the author may sounds cool, i think
chromium is a huge codebase to be used like the author says so trivially..

Its ok; if you need multiprocess ipc + net + actor-based thread concurrency +
gpu compositor + webkit.. (like i do)

But, dont know if it worth the trouble otherwise..

For instance, it takes a very long time to compile everything, it takes long
to debug (the final chrome binary with debug symbols end with 2G.. all loaded
in the heap) and you got a big codebase to know about.. so use it with care
and in need.. otherwise you will waste your precious time trying to kill a fly
with a canon

~~~
chetanahuja
This is the argument that resonates with me the most. Unless you're already
intimately familiar with the codebase and build system (with all their
attendant quirks), it could consume a huge amount of time and effort to tease
apart the stuff you need from the vast chromium codebase.

For the record, I'm working on a new C++ project where I ended up picking up
small (very small) pieces of chromium codebase with the rest being in
conservatively written C++ (but not as conservative as described in google
code-style guide). In general, I'd say /base and /threading libraries are
useful sources to raid at the beginning of your project. These are high
quality implementations of basic things most programs would need and somewhat
easier to disentangle from the rest of the code.

~~~
oscargrouch
i think theres a safe threshold someone can use as a rule, before things get
too much complicated..

first: know how to use gyp and ninja build tools then.. you can embed: base,
crypto, net and ipc..

Anything more than that, things start to get more complicated.. for instance:
if you want to use the 'ui'.. then you have to embed 'cc' and 'gpu'.. and to
work right.. you will need the browser process + the gpu process.. and will
have to create a custom-renderer, or adapt the renderer process to yourself..
so now you will realize you are doomed!

The other Chrome components past the ones i've pointed out, will need to use
the IPC and multiprocess logic from chrome.. so that part should only be used
in very specific scenarios..

Edit: i think the 'cc' module, the chrome compositor, also has some sort of
autonomy from the multiprocess IPC core.. so could also be used with: base,
crypto, net and ipc

------
steveklabnik
I'm posting this from a Chromebook Pixel, which I use for all of my
development. No crouton, just stock ChromeOS.

This movement is really interesting to me. If I could clone myself, I'd be
working on an exokernel in Rust that just exposes a V8 VM, and uses a DOM
implementation as the native drawing interface. Processes == tabs...

Of course, there's higher level work that needs to be done to expose more of
the machine in JavaScript. Check out
[http://extensiblewebmanifesto.org/](http://extensiblewebmanifesto.org/) ,
signed by Google, Mozilla, and W3C TAG members, as well as
#extendthewebforward on Twitter.

~~~
dded
Have you any experience with VNC clients on ChromeOS? If so, what's the
performance like?

I found the following, which mentions Chrome Web Browser, is that equivalent
for the sake of applications? [https://chrome.google.com/webstore/detail/vnc-
viewer-for-goo...](https://chrome.google.com/webstore/detail/vnc-viewer-for-
google-chr/iabmpiboiopbgfabjmgeedhcmjenhbla?hl=en)

~~~
merlish
A lot of VNC Viewer for Chrome is just the standard RealVNC stuff compiled
into NaCl, so you should find the performance to be pretty good. If you've
used any of RealVNC's mobile apps you should have a good expectation of what
you're getting (except better because you might be using a wired connection &
a desktop computer has more power than a mobile device).

------
brokenparser
XULRunner is almost 8 years old now, it was invented for the same purpose TFA
uses Chromium but it's actually documented:

[https://developer.mozilla.org/en-
US/docs/Mozilla/Projects/XU...](https://developer.mozilla.org/en-
US/docs/Mozilla/Projects/XULRunner)

~~~
sanjeevr
XULRunner is a good option to build HTML or XUL based apps. We were looking
for a great cross platform library for native (c++) apps. With support for OS
specific features.

~~~
masklinn
> We were looking for a great cross platform library for native (c++) apps.

Isn't that what Qt is for, with the added bonus that it's what Qt _is actually
for_ and thus e.g. documented and supported?

~~~
sanjeevrad
Qt is a higher-level application dev framework with UI support (like MFC but
cross-platform). We were looking for lower-level constructs - especially in
the networking and P2P areas.

~~~
icefox
I know that you are an ex-chrome dev so this is all moot as Chrome is the code
you knew when you started, but really that is exactly what QtCore + QtNetwork
is for. You don't have to use any of the GUI bits when you use Qt if you don't
want to. I have written many "Qt" applications that were console apps simply
to use the built in capabilities.

Edit: in fact just to highlight how similar it is, the way that QtWebKit works
is that it is built on top of these modules in a [hand wavy] similar way that
blink is built on top of the chrome development platform (I have hacked on Qt,
WebKit, and Chrome).

------
alexhutcheson
Just a heads up, Web of Trust has this sited rated very poorly[1], ostensibly
for spam. As a result, any users with the Web of Trust browser extension
installed are shown a Big Scary Warning that they must click through before
seeing the site's content.

The warning is based on one review, and doesn't seem accurate in this case, so
this might be something to try to get resolved.

[1]
[https://www.mywot.com/en/scorecard/mobilespan.com?utm_source...](https://www.mywot.com/en/scorecard/mobilespan.com?utm_source=addon&utm_content=rw-
viewsc)

~~~
nilsbunger
We asked them to review it a few days ago. It's from before we owned the
domain. Thanks for the heads-up.

------
randallu
Chromium is _huge_. If I just wanted to use the HTTP library (with tls and
spdy) then how would I build just that, and cleanly integrate the build into
my own project in a way that won't require constant revisiting every time I
update my chromium sources?

~~~
sanjeevrad
You would only link with the net library (and its dependent libraries - like
base and crypto)

~~~
icefox
And what about source and binary compatibility. What are the current
guaranties? (his second question)

Edit: to be clear after you get your app up and running with the current
version how much time has to be spent on ongoing maintenance down the road?

~~~
nilsbunger
You build the libraries and link them into your libraries. If you maintain a
cadence of updating your Chrome checkout every month, you will mostly be OK
(though this can vary, of course).

~~~
bd_at_rivenhill
Why not just stick with a stable version for a while? Updating every month
sounds like a huge headache.

~~~
erichocean
Because the Chrome team makes huge, breaking changes to their code APIs with
breathtaking rapidity. If you don't update that often, it'll just get harder
and harder and harder to do.

Google can do this (in general) because they have a single source tree
(although IIRC Chromium isn't actually part of that). Point is: when you only
care about your own code, as the Chrome devs do, third parties are in a really
bad place to try and stay current.

------
sanjeevr
Hi all,

I'm the author of the post. Happy to answer detailed questions on using
Chromium as a Dev platform. Any suggestions for a follow-up post?

~~~
zwieback
Simple sample app would be great for the next post.

~~~
nonane
I second this. Would love to see an actual app skeleton that links with
Chromium's sources.

------
sehugg
Judging from the number of dependencies I think it'd be more fair to say
Chromium is the new Boost.

------
ii
Chromium, Gecko and Webkit codebases are huge, they are hard to compile. They
are optimised for use in the browsers and nothing else. They are not universal
runtimes yet! I like that idea but please don't make it sound like chromium
runtime is ready for everybody to use for their projects.

~~~
sanjeevrad
I'm not sure what you mean by "optimized for use in browsers". I can't speak
to the other 2, but Chromium is basically a vast collection of C++ cross-
platform libraries that can be used in many applications.

~~~
icefox
While a class/library/etc might be used by chrome and all of its many users,
it was originally designed to solve an issue for the browser and it might have
a horrible api for anything else or much more likely be completely missing api
that other applications would not only want, but need.

------
gcp
Recommending Chrome is a bit like recommending bionic when everyone else is
enjoying (e)glibc?

The Chrome runtime has some good libraries but using that over say Qt really
only makes sense if you're a (former) Chrome developer. For everyone else it's
just needless pain.

~~~
justincormack
No, please. Bionic is not a replacement for (e)glibc, its a small subset of a
libc for Android. Now Musl, thats a real usable implementation.

------
memracom
Sounds like Chromium might be the successor to APR, the Apache Portable
Runtime. I believe that the authors of Chrome consciously tried to provide
functionality that replaced APR, presumably because of their multiprocess
model.

------
cbr
This is what mod_pagespeed/ngx_pagespeed does. We need many basic things and
we use the Chromium libraries for that.

(You could say that's because we're kind of like a browser, but we don't
actually use the most browser-like components of Chromium. We do need an
http(s) fetcher and html/css/js parsers but the Chromium ones aren't a good
fit for our usage.)

------
SaveTheRbtz
With the same reasoning you can use nginx as a C runtime.

------
moca
Chrome is more like Java or .NET runtime than C runtime. You can build full
blown apps as Chrome packaged apps. Google has not polished it very well. If
done well, developers can use it to build apps that run on Windows/Mac/Linux
without change.

~~~
josephcooney
It CAN be like Java or .NET if you build on top of it with packaged apps, or
it can be like the new C runtime if you statically compile bits of chrome in
to your application, as a 'stack' that you build on, which is what the author
is describing.

------
lstamour
While looking for cross-platform (iOS and Android) networking and security
resources, Google kept giving me references to the Chrome codebase. Having
compiled Chromium for a homebrew Chrome book (and tired of copying settings
between two separate codebases), I'm going to try this. :)

A big shout out to the author of this stack overflow post, where I first
confirmed that it might indeed make sense to develop function-based middleware
in C or C++ and share it between iOS and Android to bridge the low and high
levels of your app:
[http://stackoverflow.com/revisions/5234868/2](http://stackoverflow.com/revisions/5234868/2)

------
yeureka
This is interesting. Ideally, if the rendering and audio parts are of high
performance enough, it could be used as platform abstraction for game
development.

~~~
pit
Have you seen the Epic Citadel demo? It's pretty amazing:
[http://www.unrealengine.com/html5/](http://www.unrealengine.com/html5/)

~~~
grogenaut
Have you seen original real player it's pretty amazing tech too. Except that
it's forever ago. Just epic citadel vs when they actually coded that demo.

------
chubot
Interesting, it seems kind of like the scenario where the "web stack is the
new GUI", with desktop projects like Light Table being built on Node-Webkit.
You're reusing browser infrastructure for native apps.

What other alternatives are there? Apache Portable Runtime?

------
piyush_soni
To the author: I think you should 'Find and Replace' all (except a few)
occurrences of 'Chrome' to 'Chromium' in your article.

~~~
sanjeevrad
Yes, Chromium would be the technically correct usage, I used Chrome as it is
the more familiar term.

------
huchi
But otherwise I still see no reason to use something designed for a specific
use-case over something which is designed for general development. Though if
it is a proprietary app it might work because there people seldom care about
using latest version of libraries, sad as it may be.

Further, I really don't like the idea of adding a third-party draw API to a
language standard. Dunno if we really want to blur the line between language
and library.

------
hucha
There is a lot of code in Chromium that covers ground that Qt does not and
there are good reason to prefer permissive licensed code for your project that
you can directly modify. Qt is a fine library but hardly the be all end all of
what is out there. ISO C++ committee recently posted to the Cairo library and
C++14 might have a standard 2D based on it. There is a lot of room for
different projects

------
avighnay
Thanks for bringing this to limelight

Just started experiencing this early on this week via Node Webkit, it is just
awesome what NW with Chromium brings to the table.

The first thing that came to my mind is that this should have been there 15
years earlier through Java/Embedded browser. However the powers of the time
(read IE) were not interested/even actively blocked embedded browser usage.

------
hucha
sigh people just cant stop using something just because its "cool", rather
than what is right!!!

------
codingtheone
So you write your mobile apps in C++? and you can't take advantage of iOS or
Android STL?

~~~
sanjeevrad
Libraries like STL (which Chromium code uses extensively) and boost are lower-
level. Chromium has much higher level abstracts.

~~~
huchi
The reason to use specialized code is because your needs match them. Not
everyone wants to bother linking to a general purpose library and adding a
dependency when you can reuse some specific code and be done with it. Also,
language standards cover libraries extensively and this is hardly a new trend
and once it is standardized, it can no longer be considered third party. This
has already happened quite a bit with C++11 which standardized many commonly
used portions of the Boost library. Nevertheless, I mentioned the
standardization aspect not to debate about it but to use it as an example to
point out competing projects.

------
yason
That's how NSPR was/is used by projects other than Netscape/Mozilla, too.
Producing such a library is generally an unavoidable consequence of writing a
popular multi-platform application -- unless you reuse someone else's.

------
hucha
Idea of adding a third-party draw API to a language standard is not a good
idea

------
zobzu
it'd be fine if the libs were actually libs, with a documented api (you know,
in man, it's nice).

that's not the case tho, and that's why its a blog post and not something
everyone and their dog uses.

------
frozenport
I think Qt is a much lighter and feature rich alternative. Light because you
only need and see the Qt dlls and feature rich because the things described
are already in Qt.

------
factorizer
No, it's not.

------
jokoon
Can I use the p2p libs to make some bitmessage-like app, using the bitcoin
protocol to spread data ?

------
zerop
C/C++ web stack is really needed for performance reasons.. good project I
would say....

------
elwell
I for one welcome our new C Runtime.

------
indubitably
oh just fuck this entire idea

~~~
hucha
I really don't like the idea of adding a third-party draw API to a language
standard

------
clienthunter
"Person-hours".

