Chrome Is the New C Runtime

New submitter uncloud writes "Cross-platform app development is more important than ever. But what about when you need the features and performance of native code, across platforms? And you're a startup with a small team and impossible deadlines?" His answer? Take advantage of cross-platform Chrome. From the article: "Out of necessity, the Chrome team has created cross-platform abstractions for many low-level platform features. We use this source as the core API on which we build our business logic, and it's made the bulk of our app cross-platform with little effort. Most importantly -- Chrome code has been battle-tested like almost nothing else, with an installed base in the hundreds of millions. That makes all the difference when you want to spend your days working on your company's business logic instead of debugging platform issues."

Comments

Bloat.

[qubex]

This is how bloat begins: with an apparently clever insight that ignores actual common sense.

Re:Bloat.

[gbjbaanb]

someone didn't read the article....

firstly they aren't using Chrome as a platform, they're using the libraries that Chrome uses to build their apps, also that the chromium dev kit lets you specify which libraries you want to use, and thirdly they're using C++ to build their code so the bits they don't use just don't get compiled into the final program. And of course, they're using c++ instead of some crappy bloated other system that comes with every manner of crap already installed in the language or an interpreted mess that is bloated to hell anyway.

So tell me, what's so wrong with their approach - using cross platform libraries that just happen to be written by the Google boys?

Re:Bloat.

[Anonymous Coward]

Why is that "-1, Flamebait"? For crying out loud, he's one of the only posters to correctly identify the facts in this story:

- It's the general, lowest-level libraries of Chrome that are being discussed here, not the Chrome browser itself.

- C and C++ do have a superior compilation and linking model, limiting the inclusion of unused code.

- C and C++ do offer huge performance benefits over Java, Ruby, and JavaScript.

- C and C++ apps don't require huge runtimes like the JVM, a Ruby interpreter or a JavaScript interpreter.

- C and C++ do offer superior portability. Their code runs just about everywhere you can imagine.

Mod the parent up. He's one of the few who isn't spewing bullshit in this story's discussion!

Re:Bloat.

[tibit]

They had alternatives. For native C++ development, they could have used Chrome's platform abstraction, Mozilla's, Apache's, or Qt. I'd say that going with Chrome may be a bit against the grain, but hey, if it works for them, it works for them. I wonder how well the damn thing is documented, because it's hard to beat Qt's documentation.

Re:Bloat.

[Anonymous Coward]

You're making several blatantly incorrect assumptions:

1) You're incorrectly assuming that the two or more apps are using the exact same shared libraries. This is not necessarily true. Many apps have their own private copies of such libraries, preventing such sharing.

2) You're incorrectly assuming that the apps are linked against the same version of the library, even if all of the library files are publically shared. If they're using different versions of the library, then sharing won't occur.

3) You're incorrectly assuming that the app or apps haven't been statically linked, which again prevents sharing of common code between distinct applications.

4) You're assuming that Chrome or some other app has already provided these common libraries. That very likely isn't the case. The Chrome binary was nearly 100 MB last time I checked, so it's likely that this core code is already linked in to the Chrome executable and not shared.

Nice try, buddy, but please know what you're talking about before you start talking about it.

And also...

[serviscope_minor]

From TFA:

Unless you are building your app for Windows 3.1, chances are that you want to talk to a server of some kind.

Why does everyone assume that everyone else is doing stuff exactly like them? For work I don't think I've ever written code that makes any kind of network calls.

In fact the main reason for me not to use any of the "highly optimized interfaces" they provide is that professionally none of them are of the slightest bit of use to me. It's interesting but there are more programs in this world than web-2.3.1-rc4 apps for phones.

Re:And also...

[maxwell demon]

Unless you are building your app for Windows 3.1, chances are that you want to talk to a server of some kind.

That's true: Sooner or later I get hungry, so I'll go somewhere to eat and ask the server to give me some food.

Mozilla NSPR

[abies]

I have a strong feeling of deja vu - I have heard same pitch about Mozilla NSPR (https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSPR). Same thing - base library for many platforms, which is very well tested, developed for the needs of browser coding, but not really tied to hmtl rendering in any way.

So, assuming I want to be hipster should I:
- use NSPR, because it was available before reusing browser base libraries went mainstream
or
- use Chrome library, because really cool guys use Chrome rather than Firefox
?

Re:Mozilla NSPR

[maxwell demon]

Obviously you should make your product cross-platform by supporting both NSPR and Chrome ;-)

It's just the hipster ignorance yet again.

[Anonymous Coward]

The software development industry used to consist of professionals. These were people who knew enough to know that not everybody works on networked software.

Then sometime around 2006 to 2008, the whole "Web 2.0" phenomenon started. It flooded the industry with hipsters. These are people who have no technical or professional training. They just like wearing fedora hats, glasses with no lenses, and expressing "opinionated" ideas about stuff they know nothing about.

To them, "software development" does not extend beyond JavaScript and Ruby on Rails. They don't know assembly, C, C++, or even Java and C#. They don't know about embedded software. They don't know about industrial control systems. They don't know about financial, scientific and engineering modeling software. To these people, all there is is web development. They can't even conceive the idea that there might be software that isn't networked.

Hipsters are an infection upon the software industry. They bring nothing but ruin and stupidity.

Re:Plugins.

[Gavagai80]

This has nothing to do with plugins. Chromium is open source, this is about using chromium source code in other projects. Does not require the Chrome browser to be installed on the system.

Re:Plugins.

[gbjbaanb]

WTF? You didn't read the article did you.

nothing about plugins - its about leveraging the libraries than Chromium uses to build Chrome. In that, you can leverage those same libraries to build whatever you like. Its got fuck all to do with plugins, or Chrome itself for that matter.

Jesus Slashdot

[gbjbaanb]

this is worse that usual, I read the article (well, skimmed through it) and all the guy is saying is: Chrome is built on some libraries that you can pick and chose and build your own programs using. So if you need a http server or xml lib or any other of the myriad bits that Chrome needs, there's a nicely set up way of getting all those for free, and cross platform. Then he describes the library-picker tool and how it can create project files for various platforms to make your life easier.

But all the comments in /. are:

why would you build it on big old bloated Chrome (I assume the browser);

but that's what java was designed for;

but that's way bigger than libc;

So google now want us to write plugins instead of HTML5

and so on, no-one really got what the article was about, thinking its somehow building programs inside Chrome, or using Chrome as a kind of new webkit.

Pathetic. I blame the editoral summary TBH, but the kids here just got to a new low in not RTFA.

Re:Java as the cure for "bloat"? What the fuck, so

[tibit]

There is a very efficient, hardware-assisted Java runtime available from Azul, but that pretty much just proves your point. You need dedicated hardware to make Java scream.

Modern C++, if you're not dumb about how you use it, lets you avoid all of the C's unsafety, automagically, and it can enforce many safety constraints for you at compile time, too. I don't really understand why anyone writing big, scalable server applications would want to use Java when running the same stuff on C++ will cost you less in datacenter power & cooling.

Yet another cross-platform API

[TheloniousToady]

Though I found TFA interesting, it seemed like actually doing what it suggested would be equivalent to learning a large new cross-platform API. Compared to the familiar wxWidgets, QT, and GTK+, the Chrome API may have some advantages in terms of features, but I doubt it would be nearly as well documented. It would probably be a pretty big mountain to climb.

Regardless of which of these things you adopt (or even Java), you always have the basic problem of learning a large API, so it's hard to commit to more than one of them. So, although the idea of using the Chrome source as a cross-platform API is interesting, I wouldn't actually get involved unless it offered something that I actually needed which the other cross-platform toolkits didn't already provide.

Re:It makes sense

[CdBee]

the real trick is to start chrome browser, start Fabrice Bellard's javascript x86 virtual machine in Chrome, start Chrome OS on the VM, start Chrome on Chrome OS, then once you've got an infinite software defined hardware loop running, just unplug the physical hardware and put it away

Re:Java as the cure for "bloat"? What the fuck, so

[TheRaven64]

Azul stopped chip development a few years ago. They found that the speed benefits in GC with their custom hardware were offset by the fact that everything else was slower than on a commodity x86 chip. They now primarily sell x86 systems, and do some insane stuff with the page tables to make the GC fast.