Mozilla’s Rejection of NativeClient Hurts the Open Web

Update: To avoid potential confusion, I will plainly state my overall thesis. The primary benefit of the internet is its openness, connectedness, standardness. By not adopting a technology capable of competing with native apps on iOS, Android, Windows, and Mac, web vendors are preventing important classes of applications such as high-end games and simulations from moving to the open web.

Tom Forsyth writes that clock speeds have grown disproportionately relative to memory access, implying that dynamic languages such as Python or JavaScript, which perform more dependent memory reads, don’t reap the full benefits of Moore’s law. Tom then digs into Data-Oriented Design, whose proponents think primarily about how data is laid out in memory (physical structure) and secondarily about code’s syntax (logical structure). I would have loved to have seen Tom dig into empirical data about the performance of Python and JavaScript across a variety of architectures, especially now that memory subsystems are better and tracing JITs have caught on, but his point stands: memory analysis is critical for low-latency code on today’s architectures. Dynamic languages and virtual tables are at odds with predictable memory access patterns.

How does this apply to the web? Google has developed an x86 sandboxing technology called NativeClient which allows web pages to securely embed x86 code. NativeClient enables Data-Oriented Design on the web, bringing web applications to the same playing field as native applications, especially in domains such as 2D and 3D graphics, video encoding/decoding, audio processing, and simulation.

Mozilla publicly rejects NativeClient and its portable LLVM equivalent, PNaCl. Instead, Mozilla is choosing to invest in JavaScript improvements, predicting that JavaScript performance will come “close enough” to native code performance.

I argue that native code’s primary benefit lies in memory layout and access patterns, not instruction set benefits such as SIMD. With typed arrays, WebGL has brought some degree of explicit memory layout to JavaScript, but it’s still restrictive: typed arrays don’t provide pointers, structures, structure-of-arrays vs. array-of-structures, or variable-width records. These aren’t always easy to specify in C either, but at least NativeClient gives us the possibility to innovate on systems-level design, while preserving the convenience, security, and portability of web-based code.

Predictability is a further advantage of native code. In today’s browser climate, the JavaScript engines have sometimes wildly different performance characteristics. Even if each browser vendor implements its own x86 or LLVM sandbox, it’s unlikely that an application would run differently across browsers.

Beyond performance, NativeClient gives us the ability to target existing code written in C, C++, or even languages like Haskell, to the web. Emscripten and similar “translation taxes” are no longer necessary.

Finally, notice that web-based installation of native code is becoming more prevalent: iOS App Store, upcoming Mac App Store, Games for Windows Live, and Steam have shown it’s possible to make a seamless and compelling native code installation experience. However, these are all restrictive walled gardens! For the open web to compete, it needs a realistic answer to native code.

I believe that Mozilla’s insistence on pushing JavaScript over NativeClient hurts the open web by giving native applications an indefinite leg up. I want the web to support applications as rich as Supreme Commander, a game with thousands of units where each weapon trajectory is physically simulated. NativeClient would give us that capability.

Preemptive response: But NativeClient is x86! Basing the open web on a peculiar, old instruction set is a terrible idea! That’s why I point to LLVM and Portable NativeClient (PNaCl). It’s not a burden to target PNaCl by default, and cross-compile to x86 and ARM if they matter to you.

14 thoughts on “Mozilla’s Rejection of NativeClient Hurts the Open Web”

  1. Why does everyone insist on converting Browsers into a network based OS?

    I don’t need, **nor** do I want to run my future video games or applications that use half my ram in a Browser, if my Browser crashes I don’t want to loose the state of all my applications. I don’t want to have another OS inside my current OS, if people really want this to be the future, then go ahead and write a new OS from scratch. Then, any only then, can you make sure that the security system that’s in place actually works.

    We’ve got more than enough security problems on the Web, I don’t need people to port there bug ridden C++ code into my Browser and then have an implementation bug by Vendor X wipe out my home directory…

    Speaking of ~/, in the end everyone and their mom will write platform dependent code yet again. It’s the same as with plugins like Unity. I can’t see how this serves the OpenWeb in any way. If you don’t like that people can look at your source code, well, then I’m sorry for you.

  2. I call bullshit. To me, the open web was about enabling technologies like Google. HTML 2.0 was simple. It was easily machine-parsable. Search engines were possible because you could reasonably parse the web. Anyone could write it. I could teach my mom to write it in half a day. Then, web designers came along, and decided they needed pixel-by-pixel control. Then, web developers came along and decided they wanted AJAX. Have you tried parsing anything out of web sites today? Damn hard. Browser features also don’t work — half the web can’t even handle the back button. Implementing a rendering engine is damned near impossible. We’ve gone from hundreds in the early days of the web to four (Mozilla, IE, Opera, and WebKit).

    Standards that are near-impossible to implement are not open standards. Now you’re asking for sandboxed x86 code, with cross-compilation on ARM. Yes, it is possible. No, it is not a good idea. At that point, the idea of someone reimplementing a web browser goes from difficult to ludicrously difficult.

    The cost of having the web stuck at the 200MHz era is well worth the lack of complexity.

    I won’t even mention security issues.

  3. Wow.

    Can’t we just use browsers to browse? There’s an entire, incredibly rich ecosystem outside of the browser that you guys are neglecting. Reimplementing everything inside browsers and HTML rendering engines means nothing good for openness or usability. The barrier to entry for writing a new HTML engine is growing all the time and that’s a bad thing for everyone, as it discourages new development, and variety and competition help all users in the end.
    Also, ffs, distribute source code.

    Seriously, turing-complete code in web pages is a bad thing. Javascript should be trimmed down into a simplistic way to get drop-down menus. The increasing complexity that the Web’s trending towards benefits two groups: browser vendors and hardware manufacturers. Let’s bring back a Web for the users and the data.

  4. I understand the nervousness of those who have responded negatively to NaCl, but I think that it is addressing a need that stems not from the whims of google developers but from users.

    Users are addicted to rich media and increased interactivity and we can expect this trend to continue. The days of web 1.0 static pages are long gone. Given this trend, the question is, which technologies are appropriate for addressing this (undoubted greater) complexity?

    I may be mistaken but IMHO some of the posts don’t seem to understand the security model of NaCl. Any such model can be compromised but this one is well thought out, open sourced and there is no reason it can’t be made as secure as say secure bsd.

    NaCl has real strengths. Performance, access to legacy code and protection of IP come to mind.

  5. I agree that “standardness” is an important aspect of the web, but with only a single implementation of NaCl as far as I can tell, and Google would tell you that it’s not ready for standardization. Google’s messaging around NaCl has moved from “needed for performance” to “can reuse existing libraries and code-generators”, for what it’s worth. The performance issues with NaCl integration are still non-trivial, since on x86 you have to cross processes all the time. Doing physics computation for each frame in a separate process and thunking back and forth all the time would be pretty brutal, and forget your memory efficiencies! If you put *everything* in NaCl and just draw to the screen from there, then you’re really not connected to the web at all — no accessibility, no user control over how it executes, etc. Might as well use Silverlight at that point, IMO.

    Why do you think JavaScript can’t have efficient structure layout? We at Mozilla think it can, and are working to get there in addition to the traditional interpreter-JIT techniques that everyone is now happily employing.

    Betting against JS performance increases, given the trends in the last few years, is a pretty bold position! :-)

  6. petegrif: I generally understand the NaCl security model (I say generally, since I’ve read over documents like, but I have not looked over code or details). Understanding is different from trust. Security issues primarily come from complex interactions of complex systems. They are incredibly difficult to predict. Simplicity is the key to security. This adds an incredibly large, complex layer to the web browser. I’ve never seen a system this complex without issues. They might be something ass-backwards complex, but they will be there.

    In terms of strengths, the question is strengths to whom. Protection of IP is not a feature users want or care about. Access to legacy code is not a feature users care about (and it’s not even something NaCl delivers). Performance is an issue that users care about only to a very limited extent. My Pentium 100MHz did everything I care to do on a computer, except for video and audio. Those are handled in native code libraries anyway, so they work fine. I’m not sure the performance hit of JavaScript matters for anything other than videogames.

    Personally, I’d much rather see Google make a new version of JavaScript that is cleaner supports better JIT, and fixes many of the bugs/issues in JS, and let the developer specify which version to use. JS is in desperate need of a revamp. Google could then make a new JS->old JS compiler for legacy browsers.

  7. “By not adopting a technology capable of competing with native apps on iOS, Android, Windows, and Mac, web vendors are preventing important classes of applications such as high-end games and simulations from moving to the open web.” I picked up some subtext in that sentence and that article as a whole. It reads “I personally want it, so this technology is a good thing for the whole web”. And also, “It doesn’t matter if Mozilla’s developers believe otherwise, they are harming the web because I say so”. Seriously, how do you get to the notion that anyone is “preventing” anything? Mozilla isn’t implementing a function that virtually no one is developing for and somehow they own both sides of the chicken and egg problem? By your argument Mozilla should be integrating every notion anyone comes up with regardless of whether they think it makes sense because, well, it might catch on.

    “For the open web to compete, it needs a realistic answer to native code.” Now that’s very true, if and only if we need the web to compete with native applications. I don’t see a need or demand for that. I would never willingly use what you are saying we need because of the security implications of such complexity (see history of Flash for example). It would be one more thing I would have to actively disable in all our desktop browser configurations and I’m already unhappy about having to do that with other bloatware “features”. If we want your high-end games and simulations, we will happily acquire them and install them if and only if they really are native applications.

    In my own engineering development background, we labelled a proposed product as a “flying submarine tank” when it tried to be too many things at once. That is precisely what you are pushing for.

  8. “Dynamic languages and virtual tables are at odds with predictable memory access patterns.”

    I think what you meant to say was opaque and/or unpredictable data and code layout makes predictable memory access hard. Virtual table layout that is predictable doesn’t cause a problem for example, you just have to know what is coming out the other end of your compiler or JIT.

    One argument could be Javascript makes it easy to not think about memory layout issues, too easy to forget your objects are hashtables. However, what is getting laid down in memory by V8 for example is a lot closer to a predictable object layout in your static language of choice than it is a hashtable. So even here you have to understand your runtime.

    So you say it gets easier if it is just x86, right? Well, not entirely. Look into the cache line filling and layout differences between all the x86 processors. Oh yes, and NaCL also does rewriting of your code such that it throws another wrench into figuring out what exactly will come out the end of the compiler, you end up with about 10% perf hit on your code due to the safety measures imposed by NaCL.

  9. > Dynamic languages and virtual tables are at odds with predictable memory access patterns.

    This isn’t relevant to all JS code, as not all JS code uses dynamic features and virtual tables and so forth. For exactly that reason, there doesn’t need to be a “translation tax” with Emscripten – it doesn’t generate very dynamic code. It generates implicitly statically typed JS. That JS can be compiled into something that runs as fast as native code.

    For example, see how PyPy statically compiles RPython into C. RPython is a parallel to the code generated by Emscripten – an implicitly statically typed subset of the full language.

  10. I agree too, NaCl open up possibilities.

    First, it’s as safe as Javascript and WebGL, while having an huge performance boost (it is using HTML5 as the gatekeeper, so i’ll be roughly as safe as HTML5).

    Second, it’s an open-source model, so it does avoid lock-in, as opposed to silverlight, flash, or activeX.

    Third, it does allow use of lots and lots of existing languages, C, C++, C#, .NET, fortran, etc. That is, bringing them to the web.

  11. The browser is a terrible design. The whole thing should be built inside something like pnacl, then we can say goodbye to code execution exploits FOREVER. Can’t people understand this? The current design of the browser is terrible. How much damage has Mozilla caused through browser bugs. How many decades is it going to take for people to realise that all of the security problems can be designed out. I’m not saying pnacl is the final answer in that regard, but it’d be a lot more tractable than the squillions of lines of C/C++ code that is trusted in a traditional browser. Anyone who is against pnacl, is FOR plugins and the attendant security issues.

  12. To those who say that the web doesn’t need fast computations I would suggest that you consider the case of Virtual Reality.

    Virtual reality could become the must preferred way to surf the net in my opinion.

    It needs a fast and platform/cpu independent medium.

    If PNaCl is faster than JavaScript then it may be the only acceptable option.

Leave a Reply

Your email address will not be published. Required fields are marked *