Imagine how much easier it will be in the future when ever very intensive programs can be written, and run, on the web.
There is some work to try to make it portable, but it is unclear how it will end up (how portable, how fast, how secure, etc.).
Partly because of this, NaCl is not standardized or even a proposed standard, which is another problem for the web.
I do admire the NaCl technology though - it's very neat. Although it's bad for the web, it is good for lots of other things.
In your original comment, were you referring to the fact that Opera also runs on money from deals with search providers, yet doesn't support proposals from them if they disagree?
In any case, Opera has always been one of the biggest supporters of the open web, through working on standards, opposing things that are bad for the web, etc.
Not true: http://www.chromium.org/nativeclient/reference/arm-overview
Yes, you can build for more than one arch. But if you have x86 and x86_64, you are missing ARM. If you add ARM, you are missing PowerPC (consoles) and MIPS (some phones). If you add those, you are still missing new archs that will be invented later.
For this reason Google is working on PNaCl - but it has other issues.
What _isn't_ fixed client behavior on the web? Browsers don't just interpret HTML any which way that they want to.
So it is in fact one of the worst things that could happen to the web.
NaCl run on x86-32, ARM and x86-64.
More importantly, content using NaCl would not run on any new hardware platforms that might appear.
So if the web were to use NaCl to an appreciable extent, new platforms would be unable to get any traction in any context that relied on the web. We'd be stuck with ARM or X86 forever for any mobile devices we might have.
Maybe you think that's ok; I think that's a terrible idea; an attitude like that toward the web in the late 1990s would have meant that ARM phones that appeared in the late 2000s would not have been able to browse the web!
(Also, note that I said "hardware _platforms_", not what you asked above.)
The important word is currently. As the GP said, 10 years ago "archs where its currently at" would not include ARM, and the ARM success on phones and tablets would have been impossible, because they wouldn't have been able to run the web, if the web used Native Client!
10 years from now, we could have entirely new architectures, and if we lock the web into the currently popular ones, we might miss out on those.
You say that because you're not the one actually using hardware built on those chips. And presumably you don't care whether people who _are_ can use the web. But some other people do care.
> X86 and ARM is where its currently at
Key word being "currently". That's fine, but we don't want to make the web _require_ this.
> So it does make sense to target these platforms first.
Sure, but with NaCl you _can't_ target other ones later. You'd have to recompile the code server-side to add any other platforms. This isn't the case with JavaScript, say, where all a new platform would have to do is write a jit for itself and existing content would just work.
PNaCl, if they ever get it working, might not have this particular problem, by the way. If that ever gets off the ground, I'd be happy to revisit this discussion.
> So we can run other languages in the browsers, at full > speed
And forever lock all computing in the world into the ARM and x86 architectures. No thanks.
Or are you talking about software that you only want to run this month and will never want to run again?
Moving from a hardware independent web to one where a full experience would be limited to a few "where its currently at" hardware platforms isn't a step backwards? Heck, while you're at it, why don't we just specify an iOS, Android, and Windows web only?
You're also, by the way, talking about the decline if not the death of a view-source web, a semantic web, and a hypermedia focused web, and probably some other things I'm missing.
By all means, feel free to write native client-server apps for any reason that pleases you, whether it's that you don't like JavaScript as a language or are working on something that truly demands native speed. Just don't advocate destroying the features that have made the web successful.