Chrome Is The New C Runtime | Hacker News Reader

Chrome Is The New C Runtime

mobilespan.com

294 pointsaagr142 comments

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

It's not too complicated. Everything with a different license is in src/third_party. Everything outside of that is under a BSD-style license. Need to watch your dependencies, but they aren't too hard to spot (and part of checking into third_party is a license check, so they're all well documented).

You can see them all if you go to about:credits in Chrome/Chromium.

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.

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.

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.

Yes. Not to mention incredibly well-tested and battle-worn. The unit test coverage for some of these libraries (like net) is incredible.

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...) so that everyone can reap the benefits of this.

> The C++ culture at Google is amazing

Yet the C++ code powering downloads was pretty bad and poorly maintained, written, replaced with Go.

http://talks.golang.org/2013/oscon-dl.slide#10

For sure there are great C++ programmers at Google, but across the company as a whole?

You're extrapolating the rewrite of a poorly maintained C++ server to mean something about the overall C++ quality at Google?

I fully concur with haberman about the state of C++ at Google.

If a simple C++ server is left in such a poor state, it stands to reason, how can there be a culture of C++ excellence? Why wasn't someone assigned to maintain the server? A culture is everybody, not just a few brilliant individuals or teams.

Because that server was not that important?

It was the server which allowed customers to download Google software onto their computers.

If your download server was slow and randomly disconnecting transfers for no good reason, resulting in potential customers giving up, wouldn't it be important?

You're blowing things way out of proportion because you don't have any idea what you're talking about.

It was a server involved in a fraction of Google's downloads comprising an even smaller fraction of Google's total egress. It took URLs of one form and redirected them to URLs of another form, where other C++ servers written by a staffed team (mine) actually redirected them to the actual C++ servers (again, deployed and maintained by my team) which deliver the downloads.

haberman wasn't talking about the state of Google's C++ codebase in 2005; he was talking about the state of Google's C++ codebase in 2014. This server was written years ago, using libraries that were years old at the time it was written. It wasn't maintained, and no team was responsible for it. The core libraries on which it was based were replaced by the libraries haberman lauded.

The only reason you can even try to use this server as an example is because you have no clue what you're talking about.

I'll just go ahead and call a spade a spade and say that this is a stupid line of conversation, and it's pretty clear that you know it.

Not only did the person you originally responded to even qualify with a "for the most part" -- thus allowing for the existence of bad code in said C++ culture -- every significant codebase in the verse has a neglected corner or three. Moreover, one man's "globally crappy" code is another man's halfway-decent code. We have no way of identifying how bad the code was, just that it was stalling a whole CPU without doing anything while I/O bound.

Finally, your whole point is ridiculous, because the slide deck you link is about finding a part of the codebase that has accumulated extreme cruft and replacing it with a new, clean implementation, which is exactly how you maintain a healthy codebase.

Go troll a new thread or find an actual point.

This is why I don't "get" go. If it was supposed to replace C++, why does it not compete with C++ directly? Why were they even using C++ for those projects in the first place?

Initial work on Go started in 2007.

Go was announced to the public on November 10, 2009.

So Go did not exist when the decision was made in the first place.

Why use C++? Performance, universal familiarity, ability to access low level APIs (libraries, x86, syscalls), abundance of good tooling, manual memory management (+debug tooling), legacy.

Why not directly compete with C++? The performance and compatibility/"close to the metal" requirements are separate. Much of C++'s complexity comes from the latter. It makes sense to create a solution for applications that require one but not the other.

I think in the beginning they did think of it as a C++ replacement, but it has been a long time since anyone from the core team has used those terms (system language) to describe it. It is more of an alternative to Java or Python. Possibly the server described should have been written in Java in the first place.

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.

Avoiding exceptions isn't the worst practice. You still get automatic resource cleanup with RAII when you return from a function with an error code, which is a big win over completely unmanaged C.

I generally agree though, error paths are the last area I want to expose myself to flaky manual propagation and the 'well, I think I handled/freed everything' discipline. The regimental 'goto cleanup' type code you see in the kernel is not something I want in my projects.

> 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

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.

I found this one compelling:

http://nedbatchelder.com/text/exceptions-in-the-rainforest.h...

I didn't really. IMHO as many in the comments stated, non-trivial "B" layer code makes the author's approach a mess.

Also I don't personally agree with the idea that exceptions communicate errors better. In his examples, he's taking an error code and converting it to an exception. Obviously all the information needed about that error is conveyed by the code, otherwise this approach wouldn't work.

Wrangling of this information shouldn't be happening in the middle of application logic. The return code should be acknowledged by the recipient so the necessary cleanup can be performed, then it should be piped to a central class in charge of printing/logging errors. Sprinkling these error code conversions all over the place makes things messy and hard to maintain.

In fact at the kernel level there are plenty of mechanisms that are comparable to exceptions, e.g. longjmps, software interruptions, signals ...

Edit: clarity.

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

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

Dunno.

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

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

Though I somewhat agree with you, in that C++ exceptions definitely are not the error handling method, such examples don't really mean nor prove much for this subject. Especially since the kernel isn't even written in C++ and is a pretty special beast compared to, say, a typical desktop or app. So now browse to https://en.wikipedia.org/wiki/List_of_fallacies and figure out which one you just used :P

I would never describe Linux as "robust". It seems everyone I know has seen it panic more than once, and shrugged it off not by fixing anything but by power-cycling the machine and hoping it doesn't happen too often. This means on top of a database of tens of thousands of bugs, there have been countless catastrophic failures which have never even been diagnosed. We only use it because everything else is at least that embarrassingly terrible and probably even worse.

Taking software seriously involves ensuring every failure is handled. Dropping them on the floor is almost never the right thing, which makes it crazy to have that quietly happen by default. Joel points out code without exceptions becomes very verbose and littered with local handling, but overlooks that it's so painful that most developers can't be relied on to actually do it.

I run quite a few linux boxes, and make them do lots of real work. Compared to other pieces of software, I find it quite reliable. This is especially true if you take into consideration the breadth of tasks and the performance requirements needed out of a monolithic kernel.

I'm in no way saying its perfect though.

> Taking software seriously involves ensuring every failure is handled

> it's so painful that most developers can't be relied on to actually do it

I agree with both of those points (as any decent developer would), but I don't believe exceptions remedy either of those issues.

The architects behind Go, truely some of the best minds in computer science, did not include exceptions because of this.

Cindy Rubio-Gonzalez has some fascinating empirical analyses of error handling in the Linux kernel: http://www.eecs.berkeley.edu/~rubio/

The tl;dr is that errors get dropped a lot with return codes. It's so easy to do, even in battle-tested, critical code like the Linux kernel.

>If the profession ever wants to produce anything reliable in C++

This has already been done, so you are obviously wrong.

Exceptions are cute for small amounts of code. But as soon as you get a sizeable codebase, you have zillions of functions just waiting to explode your call stack in ways you could never expect.

Documentation doesn't fix it either. Even if you could somehow guarantee that every single function has detailed descriptions of its possible throws, you won't get devs to read all the documentation for every function in some piece of code that needs a small fix.

> Exceptions are cute for small amounts of code. But as soon as you get a sizeable codebase, you have zillions of functions just waiting to explode your call stack in ways you could never expect.

Exceptions do not "explode your call stack", and any function can fail in ways both documented and undocumented. Consistent use of exceptions that derive from a small and well-chosen set of base classes means that callers can choose where and how to respond to categories of errors, instead of being forced to litter all code with error handling conditionals. I have worked on large applications that made the transition to using exceptions, and when combined with strict RAII and other best practices, the effect is absolutely to make code easier to understand and much more robust.

The key is "small and well chosen set of base classes" for your exceptions. This is where you got the most benefit, and you probably know it. Without exceptions, you can have a class that represents well defined state such as either success or an error code, with the error code being well defined, returning an object of this class for all methods that need to return success/failure codes, and requiring that it be handled, so compilation fails if callers ignore the return value.

What's great about this is I might call a method that simply concatenates two strings, that is all it does, and I know this won't fail(OOM can always happen, but good luck recovering from that), so I don't return a status. I can call this method assuming no failure and no boiler plate is needed. With exceptions, there's always that possibility that an exception can be thrown. What if I call this method from code that needs to close resources? Great, now I absolutely must have RAII for cleanup, which is more complicated than just doing close(x). Also, what are you going to do when using 3rd party code with its own base exception class? Now, at the upper layers of your code, you have to have a handler for each base class. Without exceptions, someone might have their own status object they return, and I'll need to translate that, else my code won't compile. Your code will compile even though you might not handle that 3 party base exception class.

Of course, most times code just propagates the error up so that adds to boiler plate without exceptions.

I think the talk of using exceptions vs returning a status is a red herring. They have their positives and negatives, and we can argue this until the cows come home. The most important thing is to use a set of well defined success/error codes, whether this comes from exceptions or a returned status isn't really important. I've seen codebase with C++ exceptions working just fine, and I've seen c++ code with no exceptions, and it worked well. The commonality between these two cases is .... well defined error codes.

Exceptions are cute for small amounts of code. But as soon as you get a sizeable codebase, you start to understand the huge advantage they give: your code shrinks by an order of magnitude vs the same code with manual error propagation.

I remember that last-gen game console SDK's explicitly recommended to avoid exceptions and disable them completely for performance reasons, and all C++ game-dev middleware I'm aware of don't use them or at least have support for disabling them. Don't know what the recommendation in the current console SDK's is. I never got into a situation where I thought "gosh, exceptions would be really nice to have in here".

> 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's real-world C++, not 'Modern' or Boost- or 0x-C++ (not even C++98). There is a huge gap between C++ development in the trenches and what is published on the internet about C++.

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://wiki.mozilla.org/IPC_Protocols

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

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.

stop reading 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

Do you even know what you are talking about? the only thing that is reasonable to be written in javascript is webkit, specially the DOM.. and as far as i know, the chromium folks are already doing it.. (its called oilpan, i think)

There's no way the other parts could be working in javascript.. javascript is not that sort of language.. first you need a non-GC language: C, C++, Rust or ObjC (if you can stand it)

Than you need access to the native threads, and process, net, etc.. of each platform and provide native bindings for each platform.. and you need to do it fast(this probably means AOT compilation).. and again javascript is not that sort of language..

People need to stop being lazy and learn to use different tools for different needs..

I wont even comment on the cultist non-sense part.. but the source of chromium is there.. you can use it.. its open.. what could be bad about it?

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?

Do you have an example, or just paragraphs of mad ramblings?

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

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.

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

Any more information about your project? Sounds interesting

Can i contact you in the email you are giving in your profile?

I dont think exposing it directly here wont be very succint.. (i wish this was more simple to explain about) since there are some details about how the technology works (or should work) and since i dont wrote any docs about it besides my personal notes.. i was expecting to jump here at HN with a working prototype for us to play with in some months from now.. as it would be easier for people to wrap their heads around it

Im glad to talk about it to anyone interested, and if anybody else is curious, just drop me some mail at fabiokaminski at gmail dot com

With more people interested and involved, of course i can just stop coding and write a doc or paper about it in more detail.. i know theres a lot of pressure out there for something like this.. as the journey for me to get into this formula was driven by my own needs, and the lack of something already real that i could use... (couldnt do it for web browsers and app platforms wasnt really there)

It wasnt easy to get into this formula.. and i can say that this engine is REALLY cool, once its a reality i have no doubts, it will be a much more heavy-weight sucessor of what the browser could have been if it was reimaginated and designed to be more powerful than it is.. (and with the things we do know now :))

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/ , signed by Google, Mozilla, and W3C TAG members, as well as #extendthewebforward on Twitter.

This is off topic but, what happened to your Lenovo ThinkPad X1 Carbon [0]?

0 - http://words.steveklabnik.com/returning-to-free-software-a-g...

I use it primarily for PGP. I've been thinking about trying out Linux from Scratch with it, but haven't had the time.

I made a decision to start using the Chromebook to dogfood this particular vision of computers: I'm not happy that it involves Google, but they're the only one with an implementation that's this far along, unfortunately.

I've been meaning to write on this whole thing, haven't had the time...

Does it not freak you out that your laptop was created by a company that makes billions a year learning everything there is to know about you?

Yes, it absolutely does, and I am very much not happy about it. I am the most anti-Google person I know.

Unfortunately, it is impossible to live in a world of ideals, and so, I must compromise from time to time. As I mentioned elsewhere, I have another machine with 100% free software that I use for PGP when I need to keep secrets.

Where does "must" come from in this case? You could choose to practice browser fetish on anything.

Which other OS is like ChromeOS but without Google?

Linux? FreeBSD? Haiku? There's plenty of choices, and all of them have modern web browsers available (and frankly, better browsers than Chrome. People should really stop drinking google kool aid and take a look at the chrome codebase first before using it).

Not the same thing.

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

I don't use VNC, so I can't give you any advice, sorry :/

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

Can you give us some insight into how you develop on ChromeOS? What editor do you use? How do you run things like GIT? What surprised you that was so easy? What did you find more difficult that you wish was easier?

I'm the kind of guy who lives in the terminal. The only GUI program I use is a web browser.

I've been trying out Nitrous.io, and it's pretty great. I also SSH into a Digital Ocean droplet too. I just use Vim and git and everything else as normal.

> What surprised you that was so easy?

Mostly that it works.

> What did you find more difficult that you wish was easier?

I still haven't done any international travel with it yet, I bet I'll spend a lot more time using my X1 Carbon then.

I've tried out a little development on a Nitrous box using Vim myself. It seems like it would be possible to be pretty productive in it, if you were really good with Vim and all of the command-line tools. I managed to get some things done, but working with Vim just seemed to put so much friction into things. I try to keep working with Vim enough to get more comfortable/productive in just that, but it seems like a pretty long road.

I tried it out on a VM chromeOS when I was thinking about getting a Chromebook Pixel, but I ended up going with a Macbook instead - seems like more features for the same amount of money.

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

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.

> 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?

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.

Qt is reasonably separated into modules; I've deployed stuff that only depends on QtNetwork, QtSql and QtCore and all the other stuff doesn't get linked in (it's not even in the #include search paths).

(I haven't used Chromium libs and have no opinion about them)

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

Hell, Emacs meets those requirements. I'm half-serious too: org-mode and Gnus are nice pieces of software that don't have anything to do with text editing per se.

There are a lot of cross-platform base libraries out there, many of them (like Qt, GTK/GLib, and Mozilla's stack) well-documented and well-supported. These systems are meant to be reused; Chrome? Not so much. Besides the buzz factor, why would you want to base a product on Chrome instead of one of the codebases designed to be used that way?

> Qt is a higher-level application dev framework with UI support

Qt is a C++ application framework, it has both low- and high-level components, much like e.g. Cocoa.

> We were looking for lower-level constructs - especially in the networking and P2P areas.

Which Qt provides. Qt is modular and Qt has plenty of low- or intermediate-level modules, including extensive networking, storage and concurrency systems. Using Qt does not mandate using Qt's UI components.

Finally, somebody with some sense.

If you want a fairly high level, cross platform C++ library, there is no reason NOT to use Qt.

How about JUCE, a cross platform c++ lib that is really nice coded and accessible.

The UI component of it is ugly as hell, and the API style is a little antiquated. It also isn't as comprehensive as Qt, and there isn't as many resources out there for it.

I worked for a high end audio company and used it in one of their acoustic simulation softwares.

One of my main jobs was porting this project to Qt.

XULRunner is probably on its way out:

https://groups.google.com/forum/#!topic/mozilla.dev.platform...

It'll still be possible to use Firefox to run XUL apps, though.

These are at very different levels. For example, XULRunner itself is partly built on top of (a small portion of) Chromium library code, as noted elsewhere in this discussion.

Correct. Chrome is breaking no new group here. XULRunner aside, you can also use Mozilla's NSPR library for cross-platform basic services and NSS for TLS.

you can also use Mozilla's NSPR library for cross-platform basic services and NSS for TLS.

Which coincidentally, Chrome & Chromium are based on, making the cross-library usage full circle.

Huh. When i read that article, i immediately thought of NSPR - as in, this is the Chrome alternative to NSPR. But it's built on top of NSPR? I suppose Chrome-as-a-platform provides more abstraction and richer services than NSPR.

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

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

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?

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

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?

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

So every month if I update I will be required to fix my application to work with the new versions of the library. Perhaps say 25% of my time will be _only_ on maintenance? And from what I recall things are not deprecated for a while, but very rapidly changed with little to no warning. This was a major headache.

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

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.

I wouldn't go there. If I needed high level HTTP access I'd go with libcurl [0]. If I wanted a HTTP parser I'd consider Joyents http-parser library from nodejs (no dependencies at all) [1]. If I wanted a SPDY library, I'd consider spdylay (used by aria2 I think) [2].

All of these libraries are MIT licensed, well documented, and designed to be very focused libraries with very little feature-creep.

For TLS: PolarSSL has worked for me, but its GPL and tends to break ABI quite a bit [3]

[0] http://curl.haxx.se/

[1] https://github.com/joyent/http-parser

[2] http://tatsuhiro-t.github.io/spdylay/

[3] https://polarssl.org/

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?

Are you making bets on Dart or (P)NaCl staying with the platform in the long run?

We aren't relying on Dart. (P)Nacl is a very interesting option which I'm willing to bet will remain with the platform.

Now that you're not a Google employee, can you give an opinion on Dart's chances of making it into Chrome. Thanks.

Simple sample app would be great for the next post.

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

Will keep that in mind for my next post, thanks.

So, you're not using any of the rendering parts?

No, we don't use rendering components for our application. But that doesn't mean you (or anyone else) can’t.

Do you have a link to the documentation? And if there is no documentation for this many year old project why is that? Is using it in this manor different than the explicit goals of that code (which from what I understand is to only support chrome)

"Web apps are a good solution some of the time (except for that little detail called IE!)."

This statement makes very little sense. You say that you can't use web apps because you would require client have a specific app (chrome) on their machine, but then you say the solution is that they must have a different specific app on their machine. I would re-write that or remove it.

While interesting, I think the headline is a bit hyperbolic.

The Chromium project doesn't build on many platforms, and the build system they use for it is minimally documented.

While individual bits of code might be reusable on other platforms, I'd be hesitant to base any project I create on Google's codebase given the lack of portability and their reliance on arcane buildsystems.

Hi, maybe it's a stupid question, but could you write a C application that makes use of these libraries? I mean, when you talk about integrating with the Chromium source code you mean cherry-picking some code and dropping it into your C++ code or you're talking about linking it at compile time?

Awesome post, though.

I've also used Chromium libraries for cross-platform development in the manner you have suggested. What you might want to address is how you handle deficiencies in the base libraries --- how much do you have to rewrite when you see that the base implementations, which are fine for Chromium, don't offer the features that you need in your app? An example: it includes a fs-events system, to monitor for changes in files, but it is crippled to work around a bug in one version of Mac OS X, and so in the end, one probably has to write their own file-monitoring logic for each platform (or copy the Chromium code, and then modify it). Additionally, once you start modifying the base libraries to add the features that you require, how do you merge with the changes that the Chromium team inexorably publishes?

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

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.

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.

"optimized for use in browsers" means that collection of C++ cross-platform libraries can segfault a production server simply because it was not enough tested in other environments.

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.

Actually if I'm not mistaken, the /base /net /threading (lower level components) etc. are common with the google server side codebase. At the very least, they share a common heritage. Whether they're kept in-sync on a regular basis... I couldn't say.

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.

agreed. It sounds good but I can't imagine using it over some other x-platform lib which probably has fewer headaches. It's just way too big for what the author of the original post had in mind.

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.

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.

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

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

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.

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.

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

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.

Have you seen the Epic Citadel demo? It's pretty amazing: http://www.unrealengine.com/html5/

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.

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?

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

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

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.

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

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.

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

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

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

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.

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.

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

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.

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.

No, it's not.

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

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

I for one welcome our new C Runtime.

oh just fuck this entire idea

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

"Person-hours".

Reply on news.ycombinator.com