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

51–60 of 106 posts

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

#51

Post by CodeMage »

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...

Games should not run in a browser? That's a funny claim. Try telling that to:

1. Millions of users, who play them happily each day.

2. Sites like Kongregate, Armor Games and Newgrounds, whose business is to publish them.

3. Sites like FlashGameLicense, whose business is to help the business of developing and publishing games that run in browsers.

If something can be done, someone will probably try to make a business out of it. If it catches on, then people who say "just because something is possible, doesn't mean it should be done" are wasting their breath.

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

#52

Post by pedrocr »

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.

I just find all that engineering effort such a waste when it is optimizing Javascript of all things. I've seen a lot of arguments of why Javascript isn't "that bad" but few about why it is actually good when compared to comparable languages.

I see a lot of good coming out of building VMs for more dynamic languages than Java, but there seems to be movement in the direction of running away from writing pure Javascript (CoffeeScript/GWT/etc) that if you're going to build a JS VM you might as well define a strict subset of the language that will be optimized and let everyone target that when building VMs and languages.

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

#53

Post by papertiger »

ant57 wrote: post #47
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…

Comments like this demonstrate why web _applications_ will lose The inertia and individual investment in HTML and JavaScript is so incredibly high that web players (from the browser makers such as Mozilla to the individual web developers) absolutely steadfastly refuse to evolve with changing requirements. The belief that JS+HTML is "just fine" and no significant evolution is required to support application developmen…

HTML+JS libraries -- such as jquery -- are just fine for interactive document publishing, but are no replacement for Cocoa, Android, or Qt. The lack of common re-usable and extensible UI components is a travesty.

Cappuccino http://cappuccino.org/

SproutCore http://www.sproutcore.com/

Ext JS http://www.sencha.com/products/js/

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

#54

Post by pohl »

megaman821 wrote: post #48
pohl wrote: post #44

Earlier quoted context omitted.

JavaScript does have a just-in-time compilation step in most implementations these days. A quick scan of llvm-bc by a back end would be equally invisible to the user.

I just meant the user has to compile their language of choice to the llvm byte code, as I don't see browsers hosting a bunch of interpreters for different languages.

Only the developer would need to do the step of compiling to llvm-bc, not each user. The browser need only host the back end JIT compilation step.

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

#55

Post by ant57 »

papertiger wrote: post #53
ant57 wrote: post #47

Earlier quoted context omitted.

Comments like this demonstrate why web _applications_ will lose The inertia and individual investment in HTML and JavaScript is so incredibly high that web players (from the browser makers such as Mozilla to the individual web developers) absolutely steadfastly refuse to evolve with changing requirements. The belief that JS+HTML is "just fine" and no significant evolution is required to support application developmen…

HTML+JS libraries -- such as jquery -- are just fine for interactive document publishing, but are no replacement for Cocoa, Android, or Qt. The lack of common re-usable and extensible UI components is a travesty. Cappuccino http://cappuccino.org/ SproutCore http://www.sproutcore.com/ Ext JS http://www.sencha.com/products/js/

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, quicklook, spotlight, etc, etc, etc). The interaction model will already be familiar to the user, visual cues will be understood, the speed and inertia of animations (such as scrolling) will be expected. There is an enormous value to being able to leverage user expectation, and this is where too many choices falls down.

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

#56

Post by 1337p337 »

mfukar wrote: post #36
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…

While you make fair points that I mostly agree with, I have a tiny nitpick: Lua isn't really a simpler Javascript; although I understand the point you were trying to make so I won't argue over it. :-)

It's true; it's a bit of an over-simpification. I was trying not to get any more long-winded than I already was. :)

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

#57

Post by 1337p337 »

sid0 wrote: post #31
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…

FYI, Firefox extensions can contain native code. Of course, you need to include a binary for every OS/arch/Mozilla version triple you wish to support.

I mentioned extensions; the first half of my previous job was spent on FF plugin development. Once in a while, one of us would get frustrated enough to try looking at how extensions are built for FF; never worth it. (Our IE guy was enviable in the sense that he only had to produce two DLLs, and got to work in his language of choice.)

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

#58

Post by [deleted] »

papertiger wrote: post #53
ant57 wrote: post #47

Earlier quoted context omitted.

Comments like this demonstrate why web _applications_ will lose The inertia and individual investment in HTML and JavaScript is so incredibly high that web players (from the browser makers such as Mozilla to the individual web developers) absolutely steadfastly refuse to evolve with changing requirements. The belief that JS+HTML is "just fine" and no significant evolution is required to support application developmen…

HTML+JS libraries -- such as jquery -- are just fine for interactive document publishing, but are no replacement for Cocoa, Android, or Qt. The lack of common re-usable and extensible UI components is a travesty. Cappuccino http://cappuccino.org/ SproutCore http://www.sproutcore.com/ Ext JS http://www.sencha.com/products/js/

[deleted]

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

#59

Post by trotsky »

Let's ignore the philosophical or design issues surrounding native client and look at a practical one.

Why does the article take issue with Mozilla alone? Surely they aren't the only browser vendor that won't be implementing native client. Mozilla is being singled out here precisely because other major platforms are considered to be lost causes.

Safari and Internet Explorer are unlikely to support NaCl for obvious competitive issues. Heavily curated platforms like the iPhone prevent even third parties from supporting such a feature.

Once you realize that even with Mozilla support you'd still only be looking at a ~60% penetration, you're going to be working around it anyway. Once you're dictating platforms, plugins or providing a fall back implementation I'm not sure if support in one specific browser is going to make or break anything. If you're willing to target only half the web you're simply not that concerned about ubiquity to start with.

Post reply on HN