Comment by 1337p337 | Hacker News Reader

Comment by 1337p337 | Hacker News Reader

Parent Full thread

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 make web the web worse? Force developers to target several architectures for their apps, or greet users with "Your CPU isn't supported!" pages. Lots of Webapp developers have trouble with cross-browser issues!

If you look at Firefox plugins (native) versus extensions (Javascript), you can see fairly plainly that, even though it's slower, the ease of development in Javascript (even with all its quirks) outweighs the benefits of native code, even for heavyweight extensions.

The best solution, in my opinion, is to expose a (fast) bytecode VM to web developers. Javascript is okay for a lot of purposes, but it's a messy language, and can be pretty clunky. A bytecode VM (one that at least has a Javascript front-end) could solve most of these problems. Off the top of my head, the JVM has Rhino for JS (as well as support for Ruby, Python, Clojure, and a host of others) and is easily restricted, if somewhat heavyweight. The Lua VM is faster than the JVM, is portable to a number of platforms (having a clean, portable, lightweight implementation), and I suspect that a Javascript front-end would not be hard, given the similarities between the languages (Lua could be described as a cleaner, faster Javascript). The language of choice would be up to the developer, as long as it could target the VM (and we'd not have to put together hacks like minifiers or $language-to-JS compilers like CoffeScript and Objective-J). Getting Google, Microsoft, and Mozilla to agree on a VM is trickier, although I hear MS loves Lua.

I also agree with the app store assessment (1000 suns, etc.), but have little to add.

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 implementations. Native Client is a complicated enough technology that it might be completely impractical to spec it in sufficient detail and independently reimplement.

You might think this is only a technical issue of standards process, but a standard with only one implementation ends up de facto controlled by a single entity, even if the implementation happens to be open source. In practice, you'll get support for the platforms and CPU architectures that Google cares about, in their priority order. You can see how that might not be so appealing for an entity that doesn't want Google to be setting the agenda quite that much.

In addition to this, the security architecture of the whole thing seems pretty dubious. It does have a better attempt at security design than ActiveX. But given the basic approach (binary-level validation of binary code), it has a lot of attack surface.

All that being said, it's a neat project with a lot of hack value. It just doesn't seem like a great fit for the Web. It is likely more driven by Chrome OS at this point.

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?

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.

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

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.

I'm referring to these benchmarks: http://shootout.alioth.debian.org/u32/which-programming-lang...

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

This is kind of at odds with your earlier comment...

Reply on news.ycombinator.com