Opera shrugs off Google Native Client Mozilla has no intention of mimicking Google's efforts to run native code inside the browser. And Opera feels much the same the way. In a recent conversation with The Register, Opera chief standards officer Charles McCathieNevile argued that Google's Native Client plug-in — a means of running native code inside the company's …
i think they're going to start worrying too much about 'purist' ideals rather than making usefuly stuff.
as for javascript matching native client, i just can't see it, cherry picked example runs at half the speed, javascript might get faster but so will native client.
The java fanbois have been claiming the same for years: "Java is within 50 % of C/C++ performance".This is true if you confuse a certain benchmark with *real* applications.
But everything non-trivial like a 3D action game, a CAD package or an image editing program simply needs C or C++ to deliver complex features with acceptable response time. And that is exactly because the memory structures and allocation/deallocation patterns must be customized to the problem at hand. There are lots of applications where memory is still at a premium, so compact storage is critical. Think of an engineer "flying" through the mechanical design of an Airbus A380. This is still a huge computer science challenge if every part can be manipulated/inspected/filtered individually. Or a multi-billion transistor chip design flow.
Also, the argument of architecture-neutrality does not stick. All platforms which have gcc and NPAPI can run Native Applets, as long as only c or c++ is used. Developers don't even need to cross-compile themselves; this could be done by entities like Google, the Mozilla foundation or GNU.
In case the compiler is supposed to implement security assurances (not the case with the current native client implementation), the object code could be digitally signed by a Trusted Compilation Provider (similar to a Certificate Authority)
Native Client, Google Chrome, Linux Security Modules and BSD Jails are innovative concepts which deserve more investment. The current state of application delivery and installation is very 1980ish, so to speak.
Although I don't disagree with the key points of this, bear in mind that all of the examples you've given where JS doesn't cut it are graphically intensive and other than certain genres of games, most common apps are not that demanding.
I doubt anyone is planning on replacing their video editing software with a web-based application any time soon (although I believe they *do* exist) but that doesn't mean it isn't good enough to make serious inroads into the most commonly used software.
Javascript!=Java
Memory structures in C++ nowadays are probably going to mimic those in Java simply because Java's memory structures and handling were designed to be as efficient as possible (don't snigger there at the back) by people who design programming languages -- oh, and the Sun website seems to suggest that Java was written in C anyhow.
Nowadays things like 64bit chips probably mean that you need to manipulate data in large discrete chunks anyhow -- gone are the bit-twiddling days for most coding.
Cross-compiling and cross-platform are not the same thing -- though, I suppose, the current trend into having a compiler as part of the browser to JIT compile ECMAScript is pretty close to your allowing Google to compile for each platform, isn't it?
Digitally signed as secure? By whom? You'd need to pay an awful lot to get someone to sign off any old shit coding, compiled by any of a myriad of different companies proprietary compilers, as safe.
I seem to recall that applications worked just fine in the '80s, without the need to happen in a browser window. Having to open a Google plugin inside Internet Explorer on Windows 7 just to write a short letter doesn't look like progress to me, for example.
Isn't this a step backwards? Native for ARM or x86? Are we using 32 bit or 64 bit tech? With or without GPU support? Which? And using what API for OSy things?
I thought the basic premise of Java (not JavaSCRIPT) was to make an abstraction layer so that more or less the same code will run on pretty much anything with a Java runtime. Witness Opera (Mini/Mobile) to see that in action. But... downloaded native code? This isn't the '90s!
Is this 'native code' a bit like ActiveX, but not quite so MS-specific?
You know, non-portable code with a whole load of OS-level hooks to "do stuff efficiently" that ends up a security nightmare and alienates users of certain OS/CPU/etc?
I had hoped to see the end of that sort of thing on the web.
Google's pNaCl code is designed to be delivered in LLVM format and run anywhere that has the pNaCl plugin regardless of CPU or OS. That's Intel or ARM , Windows or Mac, and potentially Android, Symbian, or anything else. The pNaCl plugin will include an LLVM compiler and a security checker.
I think Google will be quite happy if nobody else uses Native Client, because that will give Google's own Native Client web pages an edge over the competition.
Google have said they will use Native Client a lot in Chrome OS. Mind you, it remains to be seen if Chrome OS will sink or swim.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
