Posted
by
timothy
on Saturday January 18, 2014 @08:03AM
from the ok-but-does-it-have-a-browser dept.

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

Yeah, that's the theory. With business apps this has turned out to be almost a joke. Any friggen' client (Oracle, SAS, SAP you name it) brings their own private Java run-time (typically outdated) because that's the one that's tested and supported.

Well, that's a good point. When I last upgraded my OS, certain applications insisted that I have a JRE that is a version or two behind the one that was bundled with OS X. Maybe it was planned obsolescence on their part, but if so, it backfired: I'll be damned if I'm going to go out and buy new copies just because I upgraded my OS. I'll find something else.

In a somewhat related bit of news, Google recently emailed me to let me know that they were no longer going to support the desktop notifier, that tool I use each and every day to let me know I have mail. However, Google went on to tell me, I could get that functionality back if I switched to Chrome.

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?

Your claimed "2x performance gain" is usually actually 10 to 15 times, for real-world software written in C++ versus Java, and 25 to 50 times for software written in C++ versus JavaScript or Ruby.

Don't bother trotting out your totally unrealistic Fibonacci sequence micro benchmarks where some Rubyists or Javaists have spent months highly tuning some Ruby or Java code so it's only 5 times slower than the equivalent unoptimized C++ code. That's not the kind of Ruby

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

The fact that it's been done before many times? Or perhaps the fact that there are lot of platforms out there that have never seen a browser and which have never had Google testing the library stack on them? There's a lot of diversity once you're outside the consumer market, even now.

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.

Qt has many advantages. I, however, don't like 16-bit characters. (Possibly this is because of experiences with Java.) Either they should use utf-8 or utf-32. Or both. And the heavy emphasis on latin1 in the documentation of Qt is a real turnoff. (Yes, you can avoid it, but yeesh...the only useful thing to do with latin1 is to convert it into utf...either 8 or 32, depending on your purpose.)

OTOH, I've no reason to believe that Chrome libraries are any better. If the *have* a documented API, he didn't

Use of a variable-length encoding for internal storage in a string type is really introducing a lot of runtime inefficiency, so it's best avoided. IMHO it was a valid tradeoff between flexibility and performance to use UCS-2 - a fixed-width encoding, as opposed to say UTF-16. It also reduces storage by 50% compared to using the fixed-width UTF-32, but makes some less-used code points non-representable.

There's nothing "emphasized" about latin1 in Qt, not even in Qt 4. These days you're supposed to encode you

What's wrong with the approach is that there isn't a link to API documentation, so you can't quickly judge how well it would fit your project. Source code takes a LOT longer to review.

If I were convinced enough, I could download the source and run it through DOxygen, but that's not much good unless the code has been properly documented. Is it? Not a clue. Yes, if I get convinced I can do it myself, but I take a lot more convincing if I can't see the API ahead of time.

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.

Obviously you've never written code for a Windows system. Shared memory pages for libraries is so incredibly rare it isn't funny. Also, because the Windows DLL interface isn't intelligent enough, most people end up having to distribute their own copy of any libraries they use anyway so they can't be shared with other applications.

You seem to be missing a dose of reality. A quality product at a discount price typically cannot compete with established manufacturing, distribution and advertising channels. It requires deep pockets and order of magnitude value improvements to succeed against an entrenched player. That's why we don't have flying cards and a Mars colony. Competition is so inefficient as an economic organizing principle that it is literally killing millions every day. Perhaps the only worse principle is central plannin

There is a very efficient, hardware-assisted Java runtime available from Azul [azulsystems.com], 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.

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.

It isn't that insane. Instead of remapping one page at a time the queue up a number of changes and commit them all at once. This is because on stock Linux every page table re-map creates a lot of cache coherency traffic to make sure all the processors know of the new mapping. By committing them all at once they only need one round of that.

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.

Because as the size and age of the codebase grow towards infinity, the chances of at least one dumb person touching it grow towards one.

That's pretty much irrelevant. He's talking about using the Chrome libraries, so the linker will strip out any unused functions.

What this means is that it's likely providing a bunch of useful functions above and beyond the standard library. The problem is, he only talks about those routines in such general terms that you can't figure out whether they're useful, and he doesn't give any links to documentation, so you don't even know if they're documented.

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.

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.

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 mainstreamor- use Chrome library, because really cool guys use Chrome rather than Firefox?

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

As hipster and nerd, you should DYOFF (Develop Your Own Fucking Framework)!

Also note that the Apache Portable Runtime is highly lacking in introcuctory documentation. What it has is DOxygen generated comments for poorly documented routines. They're probably quite adequate if you already know what they do, and just need reminding, but otherwise....sheesh!

No, NSPR is really low level. You can think about it as less readable libc+libsocket+libthread, which gives you platform-independent API.So, it isPRUint32 PL_strlen(const char *str);instead ofsize_t strlen ( const char * str );(saves you from worry about what size_t is on given platform). And every other function you know from above libraries will be converted into some with strange prefixes, but well defined data types.Well, there are few other goodies like hashtables, but generally it is about being reall

What's a better term than "business logic" for that which should be kept separate from presentation? There's "game logic", but that too is domain-specific. "Application logic" perhaps?

Yes, I think "application logic" would be good. The problem with "business logic" is that it's domain-specific too; an awful lot of interesting algorithm development and implementation is taking place outside the realm of what would normally be considered business applications. Games are one example; scientific programming is another. In both cases, many of the principles that are useful in business programming can be usefully applied, but the purpose of the final application is very different.

Lets talk about this again in 12 months. Given the NSA bullshit, Chrome, Apple and Microsoft all being involved, I'm not sure people are going to be keen on yet another layer of abstraction for surveillance to be hidden in.

...why would any sane person build their whole business on Google, with its reputation for pulling the plug on projects for no obvious reason, little or no warning, and absolutely no interest in granting stays of execution?

Seems more like an understanding fail to me. Their business is not built on Google. It's built on a platform abstraction library that currently works for their intended uses. It's a closed book, they don't need any further involvement from Google. If they want to, they can fork it and maintain it themselves. They've already got a big trampoline so it'd still be less work to maintain that code than to come you with a yet another in-house, buggy, under-tested "framework".

Google, with its reputation for pulling the plug on projects for no obvious reason

That reputation is a product of/. groupthink, not reality. The reality is that Google has a history of pulling the plug on projects that aren't successful, niche products used only by a tiny percentage of the user base.

Chrome, however, is wildly successful. Plus, the code is all open source and has an active developer community outside of Google. Google isn't going to drop Chrome, and even if Google did, Chromium wouldn't be going away any time soon.

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.

Maybe they are kids, maybe they are old dogs who got burned by environments who were devise to be weaponized, increasing some corporations' hold on the market. It is irrelevant to scream "but it is open source!", google itself has shown how raw engineering power can be used to control a project with android.

In 2014, why do we need non-native libraries to handle DNS lookups, crash reporting, logging? Surely these are part of what a proper platform should offer, yet none of them do. It is pretty sad when at least one GUI toolkit (QT) feels the need to include a networking API.

Because you don't want to use differents API for DNS lookups on different platforms, you want to "write once, run everywhere". Considering the above-mentioned Qt already exists, I thought this was a solved problem, but apparently Chrome-fans have to reinvent the wheel.

There is no decent DNS-lookup and connection establishment C API in standard Unix. You are left to implement e.g. Happy Eyeballs (RFC 6555) on your own. You can of course use the low-level API's to send AAAA and A requests on your own, but there is no way to just say "give me a socket to google.com on port 80" and have it do the right thing.

Cross platform is something else entirely, that would be wonderful, but something platform specific would be OK too.

This guy talks like this is some new idea, but there are excellent libraries that already provide this stuff. A quick look at the list tells me that boost and openssl cover most of the functionality, and unlike chromium they are made to be libraries, so you can be pretty confident they work under all conditions and the developers won't screw around with the api between versions.

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.

> "Out of necessity, the Chrome team has created cross-platform abstractions for many low-level platform features.like java> 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.like java> Most importantly -- Chrome code has been battle-tested like almost nothing else,> with an installed base in the hundreds of millions.like java

so I kind of dont see a difference to just using what would be considered a higher-level language.

10 years ago, you just whipped out your Visual Studio when you needed a client application, but not anymore.

No. I whipped out Visual Studio and created a header called plat.h and a source called plat.c. There were no more than 2000 lines devoted to platform issues, vs. something like 40k for the whole thing at its largest point. They allowed my application to run on Windows, Linux and FreeBSD. And yes, it did threads and networking! It used pthreads on Windows, and it worked very well. Eventually, the kernel module component (yes, kernel module) ran on all 3 systems in kernel mode. The plat.h/plat.c business never got out of hand. It was pretty manageable. At some point, we interviewed a manager who wanted us to switch to Eclipse, and couldn't understand how I could do what I did without using Java. Fortunately he was not hired.

At work we use Skia, the 2d drawing library for Chrome/Android, in a server application, to render charts and graphs based from seismic data into png images.

The library is a fairly light weight dependency, lightning fast and designed to take advantage of the power of C++, rather than sticking to a C api. However, dealing with Google's custom build system and the relatively sparse documentation made getting started a bit harder.

Depending on the kind of application being built, I would definitely consider tak

Probably. Emacs runs lisp, for which a large variety of javascript implementations exist. x86 simulators for javascript do also exist. On these, some kind of operating system can be booted (be it windows or linux or whatever), on which the related version of chrome should be able to run.

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.

Those "proper" APIs are usually chock full of bugs ("features"), intricacies, and generally can be a pain to work with. All this has been handled by people who develop the platform abstraction. You really need to go out more and look at how convoluted real-life cross-platform code is [woboq.org]. All this crap took long time and lot of effort to get done. You can use it and get ahead, or you can reinvent the wheel, usually in a buggy way. Your choice.

Mozilla was being used as a platform more than 10 years ago; not the browser but the framework underlying it which powered the browser, email client, irc chat, etc. I remember seeing a few books on it before Chrome even existed.

Apache has been running on everything forever; one could say similar things about using Apache for writing server software... in fact long before Chrome they made the common elements into a library called the Apache Runtime Library.

Sorry, but which version of Gtk? Gtk3 is pretty much incompatible with Gtk2. so I've stopped paying either version much attention. (The last time I checked, Gtk3 had mad many of the things I was doing with Gtk2 not work, so I stopped active development on the Gtk projects...or switched to other libraries. Admittedly that was several years ago, but I haven't heard many people singing the praises of Gtk since then. Qt, yes, and it has many nice features, along with some I rather dislike, but not Gtk...of