http://en.wikipedia.org/wiki/ActiveX - 1996 is knocking… yes, I know - it's very, very different this time, but still can't help remembering the horrors of ActiveX :)
PS. From Wikipedia article: In principle it [ActiveX] is not dependent on Microsoft Windows, but in practice, most ActiveX controls require either Microsoft Windows or a Windows emulator
PPS. I'm not really trying to compare them, just pointing out that obsessive idea to run Photoshop in browser is almost as old as browser and photoshop themselves. And so is the idea for a grand platform that will let us "write once, run everywhere". Uncountable attempts were made, yet somehow they all fall short of expectations. Is the idea itself flawed? Perhaps we have different operating systems for a reason?..
Sounds more like Java to me. Let's replace a few words in the article:
"Under the hood, Java Applets work by compiling Java source code to an intermediate representation, rather than architecture-specific representations as in Native Client. The Java bytecode is wrapped into a portable jar file, which can be hosted on a web server like any other website asset. When the site is accessed, Chrome fetches and translates the portable executable into an architecture-specific machine code optimized directly for the underlying device. This translation approach means developers don’t need to recompile their applications multiple times to run across x86, ARM or MIPS devices."
> Sounds more like Java to me. Let's replace a few words in the article:
Winner, winner, chicken dinner.
After seeing all the web developers of the 90s dump on Java applets all the time, it's fascinating to see the same functionality being reimplemented piecemeal in Javascript.
We dumped on Java applets because they ran isolated in rectangles on the window and took ages to start and then proceeded to slow our machines to a crawl, and most of what it was used for was mundane stuff that could be done without Java, or that we didn't want.
The ultimate indictment of just how bad a fit java applets was is exactly that people shunned it despite the horrible alternatives.
It's open source, but all committers are Googlers and/or have to sign a copyright assignment. It's controlled by Google (which isn't a bad thing necessarily).
And Java is controlled by whom?
Oracle. They own the Java trademark, so any fork cannot be called Java unless they certify it.
> It's open source, but all committers are Googlers and/or have to sign a copyright assignment. It's controlled by Google (which isn't a bad thing necessarily).
Very importantly it's a copyright (and patent) license, not assignment. And it's the same thing required for any contribution to Chromium[1], and just about every competently run open source project out there, so it's not really an interesting distinction. The important aspect is more that the only "spec" for PNaCl is the documentation, which means that it can be changed by them...but then you break everyone's already compiled apps, so there are some incentives against that. Regardless, it's still open source, and you can still fork it, etc.
I agree 100% that proper handling of copyright is important (and yes, I was wrong about the license/assignment thing), and I think Google is doing the right thing here.
My point was that Google controls the project (so far as it is possible to control an open source project). I don't see that as a bad thing.
It seems like every time someone tries to replace javascript with a better solution someone has to bring up vendor lock-in. Are we supposed to just live with javascript for eternity? When javascript was introduced it only worked on netscape browsers than other browsers adopted it later. It wasn't made a spec until later.
Indeed. Every trial to replace "standards" is called "evil". From this perspective, the web platform is far from open. The result is we all are in a local optimum trap. I already gave up expecting cool future and decided to stick to the native development for a while (for a decade or more).
BTW, as a game developer, it would be nice if this rendering latency issue will be fixed soon.
Well, asm.js gets around this by piggybacking on JavaScript's syntax. So that's one approach.
Adoption really is a big issue, and I think it kind of misses the point to handwave it by saying, "Oh, adoption is such a big issue that it's insurmountable, so let's ignore it." Google hasn't really done a lot to work with anyone else on PNaCl, or even really to address any issues anyone's brought up with PNaCl. They're just sort of creating an island so far. If PNaCl is going to be a thing, they're going to need to get past that.
I agree, that's the thought I've had ever since learning of native client. These native, proprietary solutions have come and gone, such will be the fate of NaCl. As far as I'm concerned the future of high-performance webbrowser computing will be javascript-based through projects like asm.js or remote cloud architectures (eg https://brendaneich.com/2013/05/today-i-saw-the-future/)
Consider this as a much safer Multi-OS native application development platform that happens to work in a browser and all (ok, most of) your fears will disappear.
This seems like more of a ChromeOS move to me, so that you can run native code on Atom and X86 machines. The knock on ChromeOS is always that it's "just a browser". I seriously doubt anyone is going to write their Etsy storefront in NaCl. The benefit here, of course, is that if someone does write the next Photoshop for ChromeOS machines, it should also run fine in OS X, Windows and Linux. Seems like a win for portability to me.
PNaCL and asm.js are roughly the same in terms of "exposing" the code in this sense. Both can be easily disassembled/prettified using readily tools readily available today.
I doubt Google wants to keep this Chrome-only. Just like SPDY, there isn't initially support on all platforms/browsers so you have to have a fallback. But if it catches on then you will see broader support over time.
Having taken a good hard look at adding this to a non-chrome browser I can tell you it would not be a trivial task. You can't just take the code and re-use it elsewhere and re-inventing it would require constant catch up.
You can't adopt the implementation of PNaCL either. It depends on PPAPI, which itself depends on vast amounts of implementation details of Chromium. There's no real attempt to decouple them.
People have in fact looked at what it would take to adopt PPAPI. The answer so far seems to be "you have to use Chromium, not another rendering engine".
The big difference, of course, is that you can be on any operating system with Chrome/Chromium. It's not ideal but that is huge. The "lockin" is no longer at the operating system.
PNaCl has been in development for a while, I'm having trouble understanding just what is being announced here. Is PNaCl now enabled by default in Chrome?
The news is that PNaCl has been enabled on the web in the latest release of chrome. Previously it shipped but ran only on the chrome web store and whitelisted sites like plus.google.com.
I think so. I just updated to Chrome 31 and it brought up a UAC in windows, which probably means that it was installing the PNaCl runtime since it usually doesn't require a UAC.
It was NaCL which was previously available. This one is Portable NaCL which presumably can run the code built from the same intermediate machine code on various platforms (ARM, x86/64, etc). The immediate winner here is which runs on ARM and x64.
What would be really great to see is someone putting a HTML client/DOM implementation/etc. inside a PNaCL application. This is after all how things ought to be: ideally you implement your DSL/document viewer inside your general-purpose runtime, instead of kludging your document-format specification up into an application runtime. None of the big browser vendors (including Mozilla and Google itself) is going to welcome such an idea though, as it threatens their de facto control over Web standards.
instead of kludging your document-format specification up into an application runtime
So glad to see somebody else saying this. I think you are absolutely correct. The current state of web applications / web browsers is an absolute kludge. Whatever happened to "separation of concerns" or the idea of building tools that do one thing and do it well?
But what "one thing" does a web browser do these days? One might think "browsing hypermedia content" but what does that have to do with becoming the universal application runtime?!?!??
Actually, the more I think about it, the more I think "clusterfuck" would be an even more apt term than "kludge" for what we have now. But I largely blame Sun: IF they had bothered to ship something like the Consumer JRE about 7 or 8 years sooner, and IF they hadn't screwed the pooch so badly on security, we could have something like Java / JNLP for hosting "applications" while the actual browser could stick to, well, browsing.
I'm actually waiting for something to come along and become "the next Java / Flash" but done right. :-(
I'm curious to see to what extent PNaCL can fulfill some of that.
Looks like it. It's also similar to ideas which were (iirc) prevalent in the mid-to-late '90s about a modularised/componentised browser as the future of the Web.
I really really hope that this+pepper.js will allow you to deploy Ruby/Python/Go as client-side languages for the Web. Does anyone know how (P)NaCl interfaces with the DOM?
Very good news! A lot of developers don't like JavaScript and HTML. Google started to listen. I really hope the rest of big players will follow the suite.
Sadly I don't have a lot of time, so progress is quite slow. The PNaCl support isn't working at all at the moment, as I'm going through a fairly major refactoring to make things a bit more solid.
Be careful what you wish for because it might come true. A lot of people don't like the Open Web and are clamoring for something obfuscated. Longer term is lose-lose for everyone.
I don't understand how Web can be "Open" if your choice of language is limited to JS, HTML and CSS that are changing as quickly as standards committee is managing to react. And transpilers are just a second-class-citizen hack trying to make the best of situation.
The demos are cool, but are there any among them that can't be done in JS? I know I've seen Voronoi polys in JS that were way less janky than the one in the PNaCL demo.
Why is that evidently not possible? :) Serious question, I would guess anything that can be done in C - and bignums can - could be done well in JS, because typically C code compiled to JS runs at about half the speed of native.
If you have results showing otherwise for bignums, I would be very interested. Anything special about that particular problem?
Because Mozilla assured us that it was not. Central to Mozilla's case against Dart was the assertion that parts of it - including bignums - could not be implemented efficiently by compiling to JS, leaving native Dart runtimes at a strong advantage.
Thanks, reading that it says that native bignum support can speed things up. That's probably true - the only question is how much. If it's 25% vs 2,500% then that's what matters. I don't see an actual debate about numbers in that thread there, just generalities?
As I said above, I would expect JS to reach about half of the speed of C. It's possible that having native bignums would have removed some of that difference.
More importantly, the context here is PNaCl. Do you see a reason bignums could be emulated better in PNaCl vs JS? I assumed that's what you were implying, but perhaps I misunderstood you? Sorry if so.
They can all be done in JS (modified to remove threading, of course). In fact, many of them already run in emscripten/pepper.js (see http://trypepperjs.appspot.com).
Which is a pretty big deal imo considering Voroni goes from 3.3 fps with 1 thread to 12 fps with 8 threads on my laptop with an intel quad core with hyperthreading.
It says 'LLVM style intermediate code'; why not actual LLVM intermediate code? What would be the reason for an alternative? If it would be actual LLVM code it would be easier to compile from programming languages and to different backends, right?
It's quite obvious if you look at the spec. It retains very large amounts of information that is simply not needed merely for executing programs, but is quite useful for compiler backends and tools.
It's quite smart to write a LLVM backend and frontend for a custom (compact) bytecode.
"Finalized" and gzipped PNaCl code is about the same size as gzipped x86 or gzipped emscripten-generated JS code. PNaCl code seems to have a static overhead of about 400kByte, probably statically linked code which is either handled through Web APIs in emscripten, or dynamically linked CRT in native executables.
For anyone who works on Chrome: does this mean that Chrome won't move to support asm.js? I tried searching the bug tracker and discussion group and couldn't find anything.
In general I'm really happy that we're getting faster (no-gc) runtimes, but I think I favor asm.js's approach due to its backwards compatibility (though I admit I am not aware of the nuances of each implementation).
Chrome has taken the approach of working on improving their V8 engine to (hopefully) achieve similar performance to Firefox's specialized asm.js AOT codepath but without any special handling of the "use asm" directive (which gives Firefox guarantees about variable types & stuff like that). See https://news.ycombinator.com/item?id=6553794 for a discussion on the subject.
In a way NaCl offers better backwards compatibility as the code can be compiled to both NaCl and Javascript simultaneously. asm.js javascript offers subpar performance on non asm.js platforms as it is optimised to a specific subset that would have no benefit on those. Also long run asm.js sounds like a terrible format when you consider the extra overhead of massive javascript files that could be concisely encoded like NaCl.
> asm.js javascript offers subpar performance on non asm.js platforms
What kind of browser do you consider a "non-asm.js platform"? Chrome for example is not detecting asm.js specifically, but still optimizes for the types of patterns in asm.js code. As a consequence it can run asm.js code very well, on par with Firefox in many cases, for example
IMO NaCl is much more backwards compatible, letting you recompile old code-bases for the web with minimal changes. The javascript approach (even with the speed gains of asm.js) does not have threads/native instructions/etc.
I want chrome to support asm.js, and firefox to support NaCl. Winning all around.
> though I admit I am not aware of the nuances of each implementation
Perhaps a neutral discussion page is needed... I'll see about making one.
The PNaCl translator takes time to optimize the bitcode to highly-efficient machine code (which is almost on par with native performance). This only happens the first time you load the demo - afterwards the output is cached and the load should be instantaneous.
Translation time is one of the highest priorities of the PNaCl team and it should become significantly better in the future.
Sadly even after it loads and hitting refresh I still see a progress bar.
As google knows loading time really really matters and for such small demos it does not look good that it takes 10(?) seconds to load. Makes me wonder about larger applications.
Does it take the same amount of time to load on subsequent runs as on the initial run? This should not happen. Are you running in incognito mode, perhaps? (in that case, caching doesn't happen for obvious reasons). Feel free to submit a report on the native-client-discuss mailing list or through the bug tracker.
It is faster, say less than a half second and not the 10 seconds it was the first time, but still very noticeable. Normal latest chrome on a Windows 2008 box.
One thing I am concerned about is, since PNaCl is essentially yet another platform, how Google (or anyone) is going to manage the host of supporting tools required. Tools like dependency management, libraries, process control etc.
By the way, Google has already proven their "platform-creation" skills with Android.
It also adds the ability to have, for example, multi-threaded code. That's especially nice when it lets you avoid having to port old code from threads to an event-driven model.
PNaCl bitcode is (mostly) statically-typed and has a C-like memory model, as opposed to dynamically-typed JavaScript. Dynamic typing has a run-time performance cost, and so does garbage collection.
It's kind-of typed. They kept the basic integer and floating-point types from LLVM (i8, i32, i64, double) and pointers, but removed structures and arrays. It's "more typed" than JavaScript, but less than C++. This still means that numeric code (working with integers and floats) is going to be at least an order of magnitude faster than on JS.
I am actually looking at saying good bye to browser (html / css / js and all the madness) and hello to apps that connect to dropbox or s3 or some such cheep server.
Bytecode (whether x86, Java class files or this) is a far more compact and (arguably) more complete representation of the program's logic than the input source code.
Also, you haven't experienced pain until you've tried to compile C or C++ on a machine other than the author's.
Apple's developer guidelines prohibit compiling and running anything that came over the wire, for security reasons as well as competitive ones. They could add this ability to Safari themselves, but why would they?
What do you think will be the evolution here? Surely mobile won't stay behind native-webapps forever, at some point asm.js/pnacl/something else will come in. But what?
I'm sure there is some space left for fancy named design patterns and a template library with lambda support.
You know you can't write a website without lambdas, don't you ?
PS. From Wikipedia article: In principle it [ActiveX] is not dependent on Microsoft Windows, but in practice, most ActiveX controls require either Microsoft Windows or a Windows emulator
PPS. I'm not really trying to compare them, just pointing out that obsessive idea to run Photoshop in browser is almost as old as browser and photoshop themselves. And so is the idea for a grand platform that will let us "write once, run everywhere". Uncountable attempts were made, yet somehow they all fall short of expectations. Is the idea itself flawed? Perhaps we have different operating systems for a reason?..