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."
This is how bloat begins: with an apparently clever insight that ignores actual common sense.
"Place me in the company of those who seek Truth, but deliver me from those who believe to have found it."
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.
SJW n. One who posts facts.
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
?
LOL. The 90s are calling, they want their Java applets back.
On a side note, articles containing the phrase "business logic" can be safely ignored as irrelevant trash.
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.
Pretty much all the features they need are standard features or are better addressed by a dedicated library.
Also it's more a framework than a runtime. Learn the difference, it could save your life.
When I think "business logic" I'm usually thinking "RDBMS interface".
What does Chrome's library do to deal with business data?
Nothing.
I do not fail; I succeed at finding out what does not work.
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.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Seems like a recipe for disaster.
I've calculated my velocity with such exquisite precision that I have no idea where I am.
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.
They should have chosen Java instead of C++ in the first place.
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.
This space intentionally left blank
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.
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.
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.
A successful API design takes a mixture of software design and pedagogy.
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.
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. 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.
A successful API design takes a mixture of software design and pedagogy.
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.
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
I have been a user for about 10 years. This ends Feb 2014. The site's been ruined. I'm off. Dice, FU
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.
I am TheRaven on Soylent News
Holy moley, I can't believe what I'm reading.
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 or Java code that exists in the real world.
And modern C++ is an extremely efficient language to program in. Maybe you're ignorant of C++11, but it adds many high-level language features that we don't even see in Java yet. C++ also has very mature tooling and libraries which further makes it very fast to develop with.
> "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.
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.
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
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.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
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.
Limiting damage from dumb mistakes is more important than absolutely best efficiency. That's true for all projects, not just programming. It's pretty much the definition of Murphy's Law.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Oh, another one who uses cloaca.lib -- yeah, not only warmer, but you get aimed results and splash damage.
I've fallen off your lawn, and I can't get up.