skatepark

The big difference is that nobody insisted that ARM stay instruction-level compatible with x86.

When I started, there was no web. The historical context is quite a bit broader, and it helps to understand what the state of the technology was.

When the browser war was fought (and won):

- Netscape Navigator was actually a pretty terrible piece of software. I dare say they deserved to lose. Towards the end, most Mac users were running IE5 -- it was a better browser (http://en.wikipedia.org/wiki/Internet_Explorer_for_Mac).

- There was diminishing market interest in supporting alternatives to Windows because non-windows marketshare (Mac OS X, UNIX workstations) was plummeting. This allowed Microsoft embrace-and-extend to succeed.

- The web development field was nascent at best. Similar to how many web developers are moving into the mobile space today (and bringing their ideas of how to write apps with them), you had Windows-centric enterprises migrating towards writing web sites (not apps!) and bringing their ideas of how to do so with them.

I very much doubt that the web browser war would happen again in quite the same way. Between the availability of open-source browser stacks, the genuine viability of multiple platforms and vendors (iOS, Android, Mac OS X, Windows, and even Linux), and the established web development community (which would have to be co-opted), I don't think it would be quite so easy for someone like Google to 'win' a browser war and then stagnate indefinitely.

Open-source doesn't make the problem go away, but it does make the problem surmountable.

No, I'm saying that open-source solves most of the issues with a monoculture, while also being more effecient than vendor standardization when it comes to pushing forward innovation.

Open-source counters most of the issues around monoculture. Remeber that the first browser wars occurred between two closed source products.

In fact, I think that a single OSS project is far more effecient than attempts at standardization across competing products when it comes to user-beneficial innovation.

Look at the open-source UNIXes. Nearly all the value-add has come from cross-pollination of "proprietary" and not-yet-standardized enhancements, which are consumed by users and application vendors targeting those platforms.

> Do we need all the power a PC provides natively to make great games?

I think the market has declared this to be a definitive "yes". Users don't want to waste their hardware dollars so that you can spend them on inefficient solutions.

When your competition takes advantage of the hardware, and you don't, then your application (or game) falls behind in the marketplace.

There's the argument that users are willing to have lesser performance ... for lesser cost. This is true, but quite different from your code performing more poorly than your competition's on the same hardware.

As a hiring manager for over a decade, I can't recall the last time I received a resume from a qualified female applicant for a full-time software position.

Internships tend to be a bit less one-sided, but the skew is still quite high.

This sucks. I want to receive those resumes, for what I hope are obvious reasons, but I don't ever receive them.

Given that, I can't help but wonder whether:

1) You have a completely different applicant pool

or

2) You somehow changed your application process in a way that resulted in a 2:1 female:male ratio.

I don't think those are terrible questions to have. The answers could be enlightening.

> We never had access to the use of SIMD intrinsics in browsers in the first place, anyway. For that, use native.

Yes, exactly. I want it all: native performance, security, open platform.

Google is making attempts to tackle this, Mozilla keeps trying to shove app authors back into the JavaScript box.

That's why I said "entire browser". Page rendering, font rendering, <canvas>, et al, are the interesting bits.

The use of XUL and the resulting UI clunkiness (speed, responsiveness, nativeness) are pretty well known.

A world in which only the vendor gets to write low-level code sounds is a terrible division of labor.

> It is not a VM that accepts binary bytecode as input, which is what the person I am replying to wanted. Context matters. And you could have read that yourself.-

Er, so?

> One could argue quite successfully that one of the chief reasons Java (applets) in a browser is a bad design is because of its "standardised" bytecode format, which is what everyone in this discussion thread is screaming for.

Then please, reasonably argue it. I don't understand how the argument applies.

Java applets perform poorly in the browser for a number of reasons, none of which have anything to do with bytecode:

- Java's generational GC is designed around reserving a very large chunk of RAM, and performs poorly if insufficient RAM is reserved. This is a terrible idea for desktop software.

- Java's sandboxing model is broken and insecure, as it exposes an enormous amount of code as an attack surface. A bug in just about any piece of code in the trusted base libraries can result in a total sandbox compromise.

- Java is slow to start and slow to warm up, and applets more so. It historically ran single-threaded in the browser and blocked execution as it did start up.

- Swing does look native, and doesn't look like the web page, either. Applets can't actually interface with the remainder of the DOM in any integrated fashion (eg, you can't have a Java applet provide a DOM element or directly interface with JS/DOM except through bridging), so applets are odd-men-out for both the platform, and the website they're on.

> Flash was able to get by better by virtue of having a monopoly instead of a standard, and thus, has the freedom to change its swf format and bytecode format.

That doesn't even make sense. Flash was better because it didn't lock up your browser when an applet started, and didn't consume huge amounts of RAM due to a GC architecture that was poorly suited to running on user desktops.

Flash sucked because of its extremely poor implementation and runtime library design.

> ... imagine where we will be in another 15 years time.

We'll be 15 years behind the PCs of 15 years from now[1].

[1] Unless something changes drastically in the web stack.

I believe the ideal (for users) would be to target NaCL natively, with a fallback to server-side PNaCL compilation, and an absolute fallback to PNaCL compilation/execution.

I'm not sure what you're trying to prove; javascript runtimes are VMs too.

Java was designed poorly, and it performed poorly. It just so happens that its design was well-suited to long-running servers, however, so that's where it's used.

I'm not a fan of a future in which the only people that can do interesting things (including the use of SIMD intrinsics) are the platform vendors (eg, Mozilla), while the rest of us live in a JavaScript sandbox.

Maybe Mozilla should try writing their entire browser (VM included) in JavaScript/asm.js and let us know how that goes.

> You assert this, but you haven't provided evidence. Web application developers are providing great user experiences.

Are you serious, or are you really just that out of touch with how we work on desktop and mobile apps?

> What tools do you need to provide a good user experience that the web as it is now doesn't have?

- Performance, performance, performance, performance.

- Performance.

- The ability to use the right language for the job. The right language isn't the right language if the performance is pot, so no, Emscripten isn't a solution. I'm talking about everything from exposing SIMD intrinsics when writing time-critical software to languages that actually support compiler-checked type-safety.

- Performance.

- Common widget toolkits providing a common user-experience across applications, from which users can learn platform conventions and be immediately comfortable and familiar with an application. These toolkits allow us to reinventing the wheel every single time. No, bubblegum and spit collections of JavaScript and CSS are not the same thing.

- Standard library which provides the functionality necessary to conform with platform exceptions and integrate with the platform.

- Tools. Debuggers, compilers, and most especially, profilers and deep instrumentation.

- Platform integration. This isn't just "cameras". It's also the iTunes/Media query APIs, in-app purchase, airplay, spotlight plugins, quickview plugins, menu items, and the mountain of other things that platform vendors implement to provide an integrated and coherent experience. Platform vendors push forward the user experience by providing richer platforms. Web vendors don't.

- Unification of code, UI, and styling. The DOM has to go, as does CSS and JS as separate entities. It's a ridiculous model for UI development and it makes producing genuinely re-usable and interoperable component toolkits very difficult.

I could probably go on all day. I WANT a non-proprietary, open, standardized application platform, but I need a platform that lets me provide the best available experience to end-users, and the web isn't it. I'm writing my software for my customers, and choosing technology over user-experience doesn't do my customers any favors.

At the expense of battery life and performance as _compared to native applications_.

> iOS and Android are successful because they offer a great selection of powerful APIs, not because of the particular binary representation they use for applications.

They also provide great battery life and user-visible performance (iOS especially), have incredibly well integrated development tools (see Apple's Instruments and its power, CPU, syscall, et al profiling), and give software authors the escape hatches they need to maximize performance when absolutely necessary.

It's not just a question of nice APIs. Layering another level of JavaScript spit and bubblegum on top of the problem is t going to make any of the above easier.

'Very acceptable' speed isn't what consumers are looking for when comparing battery life and wall-clock performance between competing platforms.

For a desktop and/or mobile app, on which the consumer is waiting and you are burning battery (laptop/phone) or just simply CPU cycles, 2x-4x slower is 'not fast'. You're simply wasting the end-users time and resources for what amounts to ideological reasoning.

We're always making a trade-off between performance and ease of programming, but when your competition is coming in at 2x faster than your optimal case, and 4x in the standard case, you're going to lose for all but the simplest apps.

Funny you should mention that, given that I just this week had to use NEON intrinsics to eek out better user-visible wall-time performance in a native app.

Bad is the enemy of good, too. Mobile platforms have being pretty successful, too.

We'd also need a full widget toolkit, set of foundation/standard libraries, and all the other functionality we take for granted on other platforms.

With all that in place, then I'd use whatever reasonable (JS isn't) language existed as a norm on the platform to write applications to target the browser, instead of Android, iOS, and Max OS X.

My only allegiances are to user experience and the quality tooling necessary to ensure it. The web as-is provides neither.

Now I'm very curious what you think that purpose is.

Instead, it's a small bit of complexity levied against every single link in the chain, including the user (performance).

Which basically describes the entire stack of hacks that have been built on top of the web.

You're a web developer, yes? In my circles NaCL is looked at with interest because there's no way possibly for us to produce apps to the level of quality we do elsewhere -- and without a huge amount of pain -- while using the web's organically grown technology stack.

Google at least understands the flaws. Web developers seem to have their head in the sand while mobile may very well eat their lunch.

The web is the most widely used document platform in the world.

And no, it's not a robust application development platform. Working with it is an exercise in constant compromise between bad technologies and the quality of the user experience.

You're smoking something too, if you're equating the content-centric web with the breadth and depth of the market of native mobile and desktop apps.

Of course, I also get a better experience from the NYTimes mobile app; it's simply that the web can do content less badly than it can do apps.

I shudder in horror at writing one of our large apps in JavaScript, maintaining it, and desperately trying to keep frame rates up (yes, that does matter to more than just games), conform to some sane semblance of platform standards to which users are accustomed, reuse a platform widget toolkit, etc.

The myopia of the web crowd is why your platform continues to suck.

> But asm.js is usable in all browsers immediately. asm.js is just JS.

A magic JS-based bytecode that's usable in all browsers immediately isn't useful if it isn't fast. Which it isn't, because it's a JS-based bytecode executing under existing JS engines.

So now we have apps that perform incredibly poorly when run on a browser without "asm.js" support, and a rather ridiculous bytecode format that will have to be parsed natively to run reasonably quickly, with a fair bit more complexity for every layer in the development and runtime stack because they insist on keeping it as valid JS syntax.

> Because backwards compatibility is really important. x86, the Windows API, TCP, IPv4, and Unix (compared to Plan 9) are all examples of things that are full of cruft, but they persist because they have the right survival characteristics.

All of those things were also incredibly successful at what they did.

JavaScript and the DOM have not been incredibly successful at turning the browser into a first-class application development platform.

This is for many reasons; network performance, CPU performance, the difficulty of composing rich APIs, the lack of cleanly defined re-usable widgets and libraries (eg, the non-suitability of the DOM), the difficulty of interacting with the host.

Given that, why not start fresh for targeting applications? Leave JS in place, let your system target it as an output format for backwards compatibility, and -- finally -- clean up the massive cruft of the web as an app platform. Discarding decades of experience in producing effective consumer applications on the desktop (and now mobile) is foolish.

Meanwhile, you web guys are throwing away the last 30 years of progress on consumer application development, and starting from scratch.

Web apps are not documents.

> In reality, that goal was achieved ;-)

This ... has not been my experience. And I write a lot of high-performance native and Java code.

> For dynamic languages, if you want decent performance, all the known techniques require JIT techniques.

Then adopt a bytecode standard so that it can be JIT'd. I don't believe that NaCL is the end of the conversation, just that Mozilla has consistently prevented the conversation from starting, and refused to participate in it unless it involves Eich's JavaScript as the baseline implementation language.