Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mozilla’s Rejection of NativeClient Hurts the Open Web

chadaustin.me

Post reply on HN
Print view View original

101–106 of 106 posts

Re: Mozilla’s Rejection of NativeClient Hurts the Open Web

#101

Post by rizzzer »

stcredzero wrote: post #97
rizzzer wrote: post #96

Earlier quoted context omitted.

The point is that if you have only x86 and ARM binaries, you can't run them directly on a new architecture. It isn't a matter of changing an implementation. It's like trying to run a C64 binary today. The only practical way is emulation, which is slow - but thankfully fast enough in this case. In general though, it means new architectures will run more slowly than existing ones. That's not a good thing.

By then just recompile it for the next wave of tech/standards.

Do you think we still have the source code to all C64 binaries out there? We don't. And in 5 years, we won't have the source to all the stuff we are running now.

Re: Mozilla’s Rejection of NativeClient Hurts the Open Web

#102

Post by joelgwebber »

papertiger wrote: post #83
ant57 wrote: post #55

Earlier quoted context omitted.

I don't want to dismiss these out-of-hand, but they're really not a replacement for a modern application development framework. Beyond functionality (of which these can and do provide considerably less), part of what makes a platform like Cocoa/UIKit so valuable -- it is used by every application on the device . The applications will interoperate both with each other and with the OS (background services/tasks, quickl…

I have seen many apps (on all platforms -- iPhone, Android, OS X, Windows, etc.) that deviate from user expectations. Ultimately, meeting user expectations is the responsibility of the developer not the framework. HTML has its own set of visual cues that you and millions of others easily interact with every single day. I would argue that the interaction model of HTML/JS apps may be as familiar or more familiar to use…

I'd like to point out a couple of things about these choices for examples of rich UI libraries: All three of them throw most of the DOM, and reimplement almost everything from scratch: structure, layout, and most behavior (outside of that provided by input elements that can't realistically be implemented by hand). I don't think you can ask for a stronger indictment of the DOM and related APIs with respect to implementing applications.

And that's the problem. It's not [p]NaCl vs. Javascript. It's whether the core APIs are designed for the task, which in the case of web applications they clearly aren't. The most egregious failings of web applications stem directly from bad APIs, and if you look at their counterparts (for example) in iOS and Android, there's absolutely no comparison. A better script engine (and yes, almost anything would be better than Javascript) would be nice, but would do very little to solve the API problem (don't forget that NaCl can't call anything not provided by the browser, so it can't serve as an "escape hatch").

There are those who suggest that the browser APIs are close to "good enough" and just need to be tweaked a bit to make it possible to create good, efficient web apps on par with modern native apps. I'd like that to be the case (my day job is working on browser application tooling and infrastructure), but so far it's not happening where it matters most -- on mobile devices. On the desktop you can usually get away with murder because the machines are so fast (and have so much memory), but on more limited mobile platforms (and by limited I mean ~1GHz ARM with ~0.5G of memory) web apps aren't even close to their native counterparts. There are some laudable attempts out there (e.g. Gmail mobile, the Sencha Touch demos), but if you poke on them a bit you start to notice obvious performance and memory issues (e.g., when Safari Mobile crashes on the iPad it's usually out of memory).

Does this mean native apps in app stores will "win", and the web will "lose"? The web "won" on the desktop (for most kinds of apps, anyway), in spite of its severe limitations, because it provided a reasonably stable platform and super-simple deployment. App stores solve the deployment part of this problem reasonably well, but fail badly at the cross-platform part. Can the web be made "good enough" in time to win again? I don't think anyone can accurately predict the outcome at this point.

Re: Mozilla’s Rejection of NativeClient Hurts the Open Web

#103

Post by pohl »

rbanffy wrote: post #84
chc wrote: post #82

Earlier quoted context omitted.

How much would you trust the JavaScript-based sandbox? I don't see why you'd be more afraid of the blob because it's binary rather than obfuscated plaintext. I mean, heck, they could compile the LLVM bytecode to the exact same JavaScript bytecode they're currently using . If you're not afraid of JavaScript, I don't understand the objection you're raising here. That's what I'm getting at here. Executing remotely downl…

> And the problem with Java was that it had terrible performance. It had, indeed, terrible performance in 1996. > The idea of NaCL is that it will actually perform better than what we have now. Again, I see no reason why an improved JavaScript language/runtime would not perform as well as this LLVM-based solution, with the added benefit of building upon 15 years of knowledge on how to secure (and not to secure) a Jav…

Again, I see no reason why an improved JavaScript language/runtime would not perform as well as this LLVM-based solution...

The original article here does an excellent job of explaining why. Did you read it? In particular, his reference to Tom Forsyth's article on Moore's Law versus Duck Typing is very informative. And his reference to the game Supreme Commander makes it pretty clear what level of performance he would like to see web-deployable pieces of code achieve.

with the added benefit of building upon 15 years of knowledge on how to secure (and not to secure) a JavaScript-based sandbox

Those years of experience can be brought to either solution, can't they?

I watched the video that junkbit posted a link to here, and they appear to not trust the llvm-bc. Once the bitcode is translated to a native executable, they run a verifier on the resulting binary, and if the verifier is unable to prove that the only instructions that can execute are those in thi binary, then they have a strict policy of not letting it run. In addition to that, the translator itself runs as a NaCl module so that if a bug is found, it cannot be maliciously used to escalate privileges.

Their approach seems pretty reasonable to me.

Re: Mozilla’s Rejection of NativeClient Hurts the Open Web

#104

Post by joelgwebber »

BonsaiDen wrote: post #40
pedrocr wrote: post #29

The only way I can see PNaCl catching on is if Google deploys it in Chrome and the Android Browser and creates an automatic fallback to a javascript PNaCl interpreter for the browsers that don't have it. Then it becomes about "why is Firefox/IE/iOS slower at running this webapp?" But even then you'd need Google or someone else to deploy some interesting PNaCl apps to make having it worthwhile. It's a pity that this i…

Well JS is very dynamic, people have for a long time focused on the optimization of static typed compiled languages. The JVM did awesome things in the area of JITs, V8 Crankshaft is already pushing the limits once again, up to 3x gains over the current version in the Browser. There's still a lot of potential in optimizing a language like JavaScript, but Rome wasn't built over night, give JS some more time.

Don't hold your breath. Everyone seems to be predicting huge gains in Javascript performance based on two data points (it used to be really, really slow, and now it's only 5-10x slower than native). But an incredible amount of effort has been poured into Javascript optimization, and it's crawled way up the asymptote, so to speak.

The reason Javascript performance is likely to max out well below that of native code (and even below less "dynamic" dynamic languages like Lua) is that it's freakishly dynamic. JITing dynamic VMs resolving dispatches (this.that) efficiently by making assumptions based on the state when a function (or trace) was compiled. When those assumptions change, they have to fall back and either interpret or recompile. In Javascript, there are a lot of things that can change to break these assumptions (e.g., anything, anywhere, in the prototype chain). Much more so than in more straightforward dynamic languages.

It's also not really true to suggest that optimizing dynamic languages is somehow "uncharted territory" and that we should expect huge gains as people explore the space of solutions. Most of the techniques used in VMs like V8 trace their history all the way back to Smalltalk (and Self, sometimes via HotSpot).

Re: Mozilla’s Rejection of NativeClient Hurts the Open Web

#105

Post by joelgwebber »

chc wrote: post #72
EGreg wrote: post #63

Earlier quoted context omitted.

Because ECMAScript turned out to be pretty awesome, and is now the de facto standard on the web. If you don't like Javascript, your best alternative right now is to make a language that compiles into it. Take whatever "nice" features you want. Here was my crack at it: http://news.ycombinator.com/item?id=2044752

Creating a language that compiles to JavaScript without essentially being an alternative syntax for JavaScript or being agonizingly slow is surprisingly difficult. I'm not aware of a single one. Do you know of any? Your "language that compiles into it" falls into the former category.

Languages like CoffeeScript do fall into the "alternative syntax" category. And things like emscripten (and some others I've seen) probably fall into the latter. If you try to abstract out a traditional VM on top of Javascript, you're likely to get poor results.

As another commenter suggests, though, we have a language like Haxe, which is much more than just an alternative syntax. And GWT does a very good job with Java -- with the exception of some corner cases, it's usually as fast as hand-written Javascript, and often faster because of a great deal of static optimization. The Google Closure compiler arguably defines a different language (if you turn on "advanced optimizations", it only accepts an effectively-statically-typed Javascript variant).

Re: Mozilla’s Rejection of NativeClient Hurts the Open Web

#106

Post by stcredzero »

rizzzer wrote: post #101
stcredzero wrote: post #97

Earlier quoted context omitted.

By then just recompile it for the next wave of tech/standards.

Do you think we still have the source code to all C64 binaries out there? We don't. And in 5 years, we won't have the source to all the stuff we are running now.

Fine, those things can just die or limp along.
Post reply on HN