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

61–70 of 106 posts

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

#61

Post by Daishiman »

ant57 wrote: post #55
papertiger wrote: post #53

Earlier quoted context omitted.

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, quickl…

Yeah, well, web is not native, it's not meant to be, and it will never be, and I for one am glad that it's so different from native development.

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

#62

Post by viraptor »

drdaeman wrote: post #50
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…

Mozilla would be happy to replace Qt/Cocoa/... with HTML+CSS+JS (or XUL). So it's obvious they'll be highly reluctant to have the exact opposite. Microsoft once tried this in Windows 98 (thanks tightly-integrated IE) - and fairly succeeded. Since then, the attempts to "bring the Web to the desktop" are fairly constant.

Yet another new one is QT Web runtime: http://qt.nokia.com/developer/qt-roadmap (for lack of better link really)

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

#63

Post by EGreg »

tzs wrote: post #25
EGreg wrote: post #13

I disagree with the article's sentiment. I'm glad the web is focusing on Javascript. Here's why: the web is a nice, text-based environment that is safe to execute on your computer. Each web resource may contain active scripts but they are pretty innocuous. Native applications are binary and can do all sorts of nasty things. Sure, this sandbox is supposed to be safe, but what if it's not? When an application is delive…

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

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

#64

Post by EGreg »

tiles wrote: post #30
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…

We can. http://mozakai.blogspot.com/2010/08/emscripten-llvm-to-javas... or its kin will definitely see a place in the future of web development. x86 is a sucky architecture to target but we target it cause that's what's worked on. Path of least resistance. Same will happen to JavaScript as a bytecode target, inevitably, and when it's abstracted away and browsers speed up even faster, we won't be bothered by the pain…

Can you tell me how this is different from, say, Java? The fact that you are happy to run arbitrary binary code that was compiled for a specific platform? So now we are supposed to "write once compile everywhere" like C++, and then ship that to platforms? That is not in the spirit of the web AT ALL. If you want Java, at least THAT is write once, RUN anywhere. And why isn't running Java more seamless? I think answering THAT will be helpful to the original discussion.

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

#65

Post by rbanffy »

pohl wrote: post #43
rbanffy wrote: post #41

Earlier quoted context omitted.

> JavaScript JITs are already compiling JavaScript to machine code The details of how the interpreter works and of what it interprets are irrelevant to this discussion. It's JavaScript code that's being transported , not the compiled binary. While I agree tools like Closure somewhat obscure the resulting JavaScript, it's still source code that's being downloaded to my environment and it's my browser's job to decide h…

You can't easily do static analysis on binaries. The binary format in question here is LLVM-BC, which is just a compact representation of LLVM-IR, which is a single-static-assignment representation specifically designed for static analysis. SPARC, POWER and MIPS backends already exist, FWIW.

Well... This solves one problem.

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

#66

Post by chc »

othermaciej wrote: post #33
junkbit wrote: post #28

Earlier quoted context omitted.

NaCl works on both ARM and x86 using the same downloadable bytecode. The long term goal seems to be to translate the bytecode in the client using a sandboxed LLVM to target the local architecture See the following video from the recent LLVM Developers' Meeting Portable Native Client, David Sehr, Google [mp4,269mb] http://www.llvm.org/devmtg/2010-11/videos/Sehr_NativeClient-...

As I understand it, if you use Native Client now, you get an architecture-specific binary. The LLVM bitcode based portable version is still a work in progress. So it's more accurate to say "long term goal" than "works". The problems with Native Client go beyond its currently x86-specific nature though. The Web is based on open standards, and a requirement for most standards is having multiple independent implementati…

So are you arguing against Native Client or pointing out a couple of niggles with the current implementation of Native Client? I don't think anyone was suggesting that the current experimental builds are perfect and infallible.

And if a single implementor is a bad thing, shouldn't you want Mozilla in on it?

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

#67

Post by chc »

trotsky wrote: post #59

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 co…

Once Mozilla and Google support it, that puts a lot of pressure on the others. It might still not have happened, but Mozilla was the swing vote.

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

#68

Post by EGreg »

Think of it this way:

Flash, Java, Javacript, et al are great for the web because they are "write once, run anywhere". The same source code runs everywhere. That is what the web is all about. HTML and CSS are not scripting languages and they are also "write once, run anywhere". That is how the web delivers your programs.

Now, what will your Native Client do?

It will have COMPILED code for ONE platform. Like in C++ where you "write once, compile everywhere". Except you probably won't be able to compile everywhere. The point of the web is that any platform should be able to run your app.

On the other hand, I can see Native Client as being useful for extension libraries. You know, like PhoneGap plugins. The Javascript can test if the object is there, and if it is, use some standard interface. You could build up a standard library of these. As long as it is available on a wide enough range of platforms. Certain APIs are already exposed by the browser, through HTML5, that were originally in Google Gears.

Look, I agree that it's more of a philosophical thing, and indeed you are welcome to make an extension for Mozilla and all the other browsers. But the security risks alone will make this a tough sell to INCLUDE in a browser -- harming the spirit of the web. Not only that, but the web is totally against "favoring one platform over another" ... it is BECAUSE of the web that the platforms are able to work better together.

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

#69

Post by chc »

Dn_Ab wrote: post #45

And so the pendulum has swung back. I believe Mozilla's action is rational assuming my logic is not flawed. See if you can unravel it. Premise: The more indistinguishable a browser gets from its underlying operating system the more of the properties of said system it must share. Thus stretching the nature of the abstraction, making it shallower (till the machine) hence also increasing the probability of leaks in said…

It's not clear from your comment that you have a good understanding of what Native Client is. You're making vague, barely technical objections to the browser getting "more indistinguishable … from its underlying operating system" and losing the minuscule amount of cross-platform capability it has now without explaining how a more open and potentially efficient platform for code execution than "Whatever text-based JavaScript interpreter the browser vendor decided to include" would necessarily do that.

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

#70

Post by chc »

rbanffy wrote: post #65
pohl wrote: post #43

Earlier quoted context omitted.

You can't easily do static analysis on binaries. The binary format in question here is LLVM-BC, which is just a compact representation of LLVM-IR, which is a single-static-assignment representation specifically designed for static analysis. SPARC, POWER and MIPS backends already exist, FWIW.

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.
Post reply on HN