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

71–80 of 106 posts

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

#71

Post by chc »

mahmud wrote: post #19
BonsaiDen wrote: post #7

Earlier quoted context omitted.

> like the ones I listed (games, simulations, video, DSP). Those should not run in a Browser, they should on a real OS (or Emacs). What's next VMWare inside your Browser? Then it's OS -> Browser -> VM -> OS -> Browser... Sorry but just because things are possible, doesn't mean that they should be done...

but you can't just right-click on a binary executable and "view soure", bro! ~ Seriously, people managed to write successful, cross-platform software without expecting everyone with any kind of gadget or device to run it with one click.

When was this? Atlantis? I don't remember any point in history where this was simple and commonplace.

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

#72

Post by chc »

EGreg wrote: post #63
tzs wrote: post #25

Earlier quoted context omitted.

According to Brendan Eich, the designer of Javascript: JS had to "look like Java" only less so, be Java's dumb kid brother or boy-hostage sidekick. Plus, I had to be done in ten days or something worse than JS would have happened. (See comments from http://www.jwz.org/blog/2010/10/every-day-i-learn-something-... for that and more from him) Given that constraint, JS is an amazing hack. But it's 2011 now. Why should we…

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.

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

#73

Post by chc »

JoachimSchipper wrote: post #18

Considering NaCl in the context of papers like http://eprint.iacr.org/2010/594 (timing the CPU cache to break AES) is... interesting. You'd hope that Google would have considered such issues, but a quick search doesn't yield anything.

Are you saying that AES in JavaScript is more secure?

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

#74

Post by stcredzero »

mahmud wrote: post #16

Completely disagree. I don't even think Google "adopted" NaCl, it's still more a private project of a few, compared to Chrome(OS) and Android. NaCl is one of those technologies that I secretly hope fails. Pull the plug on x86 already, FFS. Saying that the Open Web needs an app-store to compete with the walled gardens is also a fallacy. Quite the contrary, the web competes with the walled gardens because it doesn't ha…

NaCl is one of those technologies that I secretly hope fails. Pull the plug on x86 already, FFS.

There's no reason why NaCl should be inherently limited to x86. x86 is currently the biggest platform, but there's no reason why NaCL couldn't switch to a "Universal" payload like OS X has, combining the 2 largest ISA. (x86 and arm?)

EDIT: I've since read that NaCl is working on LLVM, which would be even better.

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

#75

Post by stcredzero »

1337p337 wrote: post #23
mahmud wrote: post #16

Completely disagree. I don't even think Google "adopted" NaCl, it's still more a private project of a few, compared to Chrome(OS) and Android. NaCl is one of those technologies that I secretly hope fails. Pull the plug on x86 already, FFS. Saying that the Open Web needs an app-store to compete with the walled gardens is also a fallacy. Quite the contrary, the web competes with the walled gardens because it doesn't ha…

I couldn't agree more if I were suddenly granted the magical ability to concur with the power of a thousand suns. As far as NaCl goes, the absolute last thing the web needs is portability/endianness issues. I'm writing this comment on a phone (ARM), and I also browse on my desktop machine (x86-64) and my netbook (Atom, x86). (Not to even mention PS3/XBox 360/Wii/older Macs, all of which come with browsers.) Wanna mak…

The best solution, in my opinion, is to expose a (fast) bytecode VM to web developers.

The base Squeak/Pharo VM runs bit identically on over 50 platforms. The performance of the Lua VM and its suitability for ECMAScript is very attractive, though.

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

#76

Post by chc »

megaman821 wrote: post #37

People are going to want to target their C, Java, Python, etc. code to the browser. The only question is what is the better target, Javascript as a VM or a sandboxed LLVM? Honestly the inclusion of NaCl wouldn't change that much. JavaScript would still be the easiest path for most developers to choose. It will be only language that the browser hosts the interpreter and has no compilation step.

The ability to use a better language could very well make that the easier route even though it requires compilation. I mean, languages other than PHP and Perl are stupendously popular on servers these days despite the fact that they're superficially less easy to get up and running.

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

#77

Post by dchest »

1337p337 wrote: post #23
mahmud wrote: post #16

Completely disagree. I don't even think Google "adopted" NaCl, it's still more a private project of a few, compared to Chrome(OS) and Android. NaCl is one of those technologies that I secretly hope fails. Pull the plug on x86 already, FFS. Saying that the Open Web needs an app-store to compete with the walled gardens is also a fallacy. Quite the contrary, the web competes with the walled gardens because it doesn't ha…

I couldn't agree more if I were suddenly granted the magical ability to concur with the power of a thousand suns. As far as NaCl goes, the absolute last thing the web needs is portability/endianness issues. I'm writing this comment on a phone (ARM), and I also browse on my desktop machine (x86-64) and my netbook (Atom, x86). (Not to even mention PS3/XBox 360/Wii/older Macs, all of which come with browsers.) Wanna mak…

Lua VM is not faster than JVM or V8; you might be thinking about LuaJIT, which is not as portable as the standard Lua implementation and uses different bytecode format.

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

#78

Post by vilya »

BonsaiDen wrote: post #7
chadaustin wrote: post #6

Earlier quoted context omitted.

Hi, original author here, Responding to your bytecode argument, modern JavaScript JITs are already compiling JavaScript to machine code. That means JavaScript is becoming the de facto bytecode of the web. Then the argument becomes "what's the most appealing bytecode for the web?" I'd argue that SWF isn't (closed), Java isn't (for the same memory layout and language translation issues I discussed), and JavaScript isn'…

> like the ones I listed (games, simulations, video, DSP). Those should not run in a Browser, they should on a real OS (or Emacs). What's next VMWare inside your Browser? Then it's OS -> Browser -> VM -> OS -> Browser... Sorry but just because things are possible, doesn't mean that they should be done...

"Those should not run in a Browser, they should on a real OS (or Emacs)."

Why? It was not so long ago that people would have said the same thing about an email client.

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

#79

Post by 1337p337 »

dchest wrote: post #77
1337p337 wrote: post #23

Earlier quoted context omitted.

I couldn't agree more if I were suddenly granted the magical ability to concur with the power of a thousand suns. As far as NaCl goes, the absolute last thing the web needs is portability/endianness issues. I'm writing this comment on a phone (ARM), and I also browse on my desktop machine (x86-64) and my netbook (Atom, x86). (Not to even mention PS3/XBox 360/Wii/older Macs, all of which come with browsers.) Wanna mak…

Lua VM is not faster than JVM or V8; you might be thinking about LuaJIT, which is not as portable as the standard Lua implementation and uses different bytecode format.

I don't know which Lua you're used to, but as of 5.1, it's incredibly fast; I may be benchmarking the wrong things (the big one I tried was finding the first 2,000,000 primes by trial division, which should lend itself well to hotspot optimizations). Either way, though, I'd still argue that a VM (JVM and Lua were just a couple of examples of VMs that are fast, used in real applications, and are readily jailable) is the ideal solution.

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

#80

Post by rbanffy »

chc wrote: post #70
rbanffy wrote: post #65

Earlier quoted context omitted.

Well... This solves one problem.

It solves the only problem you brought up in the comment he was responding to, AFAIK. If you meant to point to others, I think you need to be more explicit or people will miss them.

So, you would be happy if a banner served through Facebook could push a obfuscated (good guys may well play by the rules, but bad guys will figure out in no time how to circumvent anything LLVM-BC brings to the table) binary blob to be executed in your browser? How much would you trust the LLVM-based sandbox?

Well... I wouldn't.

In fact, I can't understand why taking more or less the same shortcut to a dead-end Java took a decade-and-half ago is suddenly a good idea and why disagreeing with it means dooming the web to failure.

Post reply on HN