Oh come now, there are good reasons to compile to JS if you are doing things in a browser.
The only indirect technical justification is in maintaining compatibility with existing browsers, but that falls over pretty fast when you're a browser maker (Mozilla) and refusing to work with another browser maker (Google) on jumping over that compatibility hurdle.
Indirect: Market constraints that drive technical limitations.
When it comes to browsers, Mozilla both creates and exists within market constraints that drive indirect technical reasoning.
Lashing your industry to JS for another 10 years as a bytecode target is clearly not an optimal long-term solution as compared to the current state of the art, but it might make sense as a legacy support mechanism given the indirect technical constraints.
What do you consider the current state of the art?
A future in which we wind up with architectural support for NaCL-style sandboxing intrinsics, in the same way we saw them be developed for VT-(x|d).
Sticking us with JS for another decade and expecting us to compete against better application runtimes? No.
That depends on the target. I selected them because they represent different aspects of the state of the art.
> ... and I would argue that modern JS VMs are competitive with them in many respects
But not all, and in many places, not even close. JS VMs make trade-offs that we don't need if we abandon JS, and on top of it all, you have Mozilla insisting against shared-state multi-threading supported and exposed by the VM, which discards enormously important optimization opportunities) -- and that's just the tip of the iceberg.
Get rid of JS, get rid of Mozilla's self-enforced constraints on the browser, and look very seriously at something like NaCL which blends native execution performance (including being able to drop to SIMD instructions) with security sandboxing.
Let language authors target the low-level machine, and target your high-level general purpose bytecode.
Once you've built a runtime in which I could implement a JS runtime that's as performant as yours, we will no longer be operating in a two-tier universe in which browser makers think that JS is good enough for everyone but themselves.
1. Shared-state multithreading. This has been proposed by various people in the past, and is still being debated. There are people for it and against it in various places. It might happen, if there is consensus to standardize it.
2. SIMD: PNaCl (which I mention since you mention NaCl in that context) does not have SIMD. But of course it can add SIMD, just like Mono and Dart have, and there is a proposal for JS as well, hopefully that will get standardized.
So even those limitations are in principle resolvable. They do depend on standardization, of course, but so would any VM you want to run on the web.
> Let language authors target the low-level machine, and target your high-level general purpose bytecode.
asm.js is meant to get performance similar to a low-level machine. It's already very close to native on many benchmarks.
> Once you've built a runtime in which I could implement a JS runtime that's as performant as yours
I don't follow that. You can't make a fast JS runtime in your previous examples (the JVM, PNaCl, .NET, etc.).
I included ones you could, such a NaCL. And I should probably have also included the native platforms (Apple, MS, Google), because they're the competition, even if their sandboxing or runtime environment isn't what one might call 'state of the art'.
At the end of the day, it's the two-tier universe that bothers me the most. You're content to foist the JS runtime on everyone but yourselves. Once you implement Firefox entirely as an application running in a JS VM, the argument that JS is good enough might carry some weight.
Nonportable native platforms are there, you can write apps for them. They are even the dominant platforms on mobile.
But the web's entire purpose for existing is to be portable. So you do need something like JS or PNaCl or the JVM. And all of those, due to being portable and secure, impose limitations, such as limiting the native operations that you perform. That's unavoidable. But again, if you don't like that, develop directly for a native platform.
So provide fat binaries. Maximize performance on ARM and i386, with fallback to PNaCL for future platforms that are neither.
> They are even the dominant platforms on mobile.
For a good reason. Adopting their strengths while eschewing their weaknesses (proprietary and single-vendor) would benefit the entire industry greatly.
That's fine for most things, but web content is something that we do want to always be accessible.
It is hard to adopt the strengths of native execution using all the lowest-level tweaks specific to one platform, because that inherently limit portability by definition (and often also security).
I share your goals, but don't think there is an obvious better compromise than the one we are all already making on the web.
If W3C and WHATWG were competent and delivered a viable web application platform, we wouldn't be hiring Android and iOS developers now. Mozilla needs to be more open to new technologies like PNaCl that enable the web to be competitive.
> JS was never meant to be a bytecode and likely will never be able to achieve the performance possible with PNaCl.
LLVM IR was also never meant to be a bytecode. But in both the case of JS and LLVM IR, the question is the final result, not the original intention, even if the two are often connected.
> Mozilla needs to be more open to new technologies like PNaCl that enable the web to be competitive.
PNaCl is not even shipped, so it is too early to evaluate it. But the last benchmarks I saw for compilation speed and performance were mixed.
(NaCl is much more proven, but NaCl is not portable.)
Neither was LLVM IR, if you mean "portable bytecode".
Both asm.js and PNaCl are using the technologies in ways they were not originally designed for.
You cannot do it in NaCl, as being able to map pages rwx would break the security model.
You can either do this through a high-level "JIT API" that generates safe machine code from a validated IR (aka PNaCL), or through a fancier version of mprotect() that validates the actual machine code (aka NaCL).
In a wondrous hypothetical future where processors support a NaCL restricted operating mode, you wouldn't even need to validate; just set the processor state to thumb^Wnacl mode, and define a syscall instruction that switches to direct execution (without actually requiring a context switch to the kernel, just flip an execution flag).
This is why NaCL is so damn interesting, and JS/asm.js is not. NaCL has the possibility of turning our design of restricted execution environments on its head, in a very good (for performance) way.
Edit to respond to your edit: although it would be cool to be able to have a "sandboxed mode" that can somehow be switched out of more cheaply than an interrupt, the whole thing seems like a massive hack to me. After all, NaCl does not take advantage of its pseudo-ability to do so: NaCl code runs in its own process and already incurs a context switch whenever it communicates with the browser, so there is no inherent hardware reason NaCl couldn't just run directly under the kernel and have the kernel provide the same level of sandboxing as the NaCl runtime currently does. It's just an issue of getting such an approach to work portably with existing kernels... hardware support might be able to make it easier to get that to work, but it's probably unnecessary.
If we speculate wildly, why not an "asm.js restricted operating mode"? Not saying that's a good idea, but I'm not sure why a NaCl one would be either. Both PNaCl and asm.js should reach pretty much native speed anyhow.
Btw, the L is not capitalized in NaCl.
Because we already had Jazelle, and it sucked, and we learned our lesson. A Jazelle that operates on ASCII-encoded bytecode with traps for unsupported JS constructs? No thanks. :)
> Not saying that's a good idea, but I'm not sure why a NaCl one would be either. Both PNaCl and asm.js should reach pretty much native speed anyhow.
Pretty much native and actually native are very different things.
I've had to sit down and hand-optimize critical paths that would not have been viable otherwise, and would have meant discarding a feature, or introducing a significant impact on usability -- and that's on platforms where similar investments in runtime library optimization were already made by the platform vendor, too.
If we're going to throw away performance, it has to be for a good reason. As someone who doesn't spend all day on platform development (as interesting as it might be), my focus is in providing the best possible user experience.
I'd love to do that on the web, but the web needs to punting throwing away solid technology decisions because of the bad technology decisions made in the early 90s when none of us knew what the hell we were doing.
> Btw, the L is not capitalized in NaCl.
Whoops. Thanks. Now I will look less stupid in front of software engineers AND my chemistry buddies. :)
I agree.
We are losing performance in return for: portability, security and standardization. The web runs everywhere, has a good outlook for continuing to do so (no fat binaries of current archs), and anyone can build a new web browser based on standards.
None of the other options proposed give us portability, secutiy and standardization right now. Perhaps with more work they might, and perhaps JS VMs will get closer to their speed as well. It's good to try to from both sides to improve things, and people are doing so.
I don't think anyone is overlooking some obvious better solution - that fits the requirements - that is before us. PNaCl (NaCl is not portable, so not relevant here) is interesting, just like the JVM and CLR, but they have major hurdles to pass if they want to be standardized, and that effort has not even begun in the case of PNaCl.
The one quasi-counterexample I can think of in that subset of languages is Objective-C which essentially just adds sugar on top of C and can be transformed relatively simply to C (there are library functions you can use to build classes and objects and call methods from scratch, using no actual Objective-C syntax). My understanding is that Objective-C compilers don't go through C as an intermediate, but this is merely to reduce compiling time, not to improve efficiency at runtime. If Objective-C did target C instead, the end result would be identical.
That makes it totally uninteresting to try to meet your constraint.
We pretty much never try to implement a maximally efficient runtime architecture, cost or resources be damned.
By this argument, there's no direct technical reason why we should not spend 20 years hand writing machine code and proving the code sequence optimal for each target architecture.
It's a policy decision, not a technical decision.
Native is faster. A lot faster. And that's what browser apps are competing against.
That's ridiculous. Mozilla is willing to stick their neck out there implementing a mobile phone operating system, but trying to deploy a sane runtime environment to replace JavaScript is just too risky?
Meanwhile, native mobile and desktop keep growing, and growing, and the web as an application platform loses out, because none of the native platform vendors are quibbling about whether they can convince themselves to ever do something different than what they were doing before.
No, the situation makes it a reality; Mozilla doesn't control Apple or Microsoft.
If they're willing to accept that risk, by comparison, how large of a risk is trying to push through a better standardized browser execution environment, with Google's cooperation?
God forbid they succeed, and we finally have a competitive application platform.
You mean, like Google, who continually pushes to do exactly what I've described here, only to be stymied by:
- Apple, who has no reason to support the web as competitive to their native platform.
- Microsoft, same.
- Mozilla, who refuses to consider that there might be a world beyond HTML/CSS/JS because they believe those specific technologies are intrinsic qualities of the web, and thus central to their mission of supporting the web.
Looks like the only people I disagree with are the Mozilla camp. Microsoft and Apple have different priorities, and Google is continually frustrated by exactly what I've described here.
Reality. Imagine that.
Imagine that.
Mobile is growing hand-over-fist and web apps developers are still arguing about whether they're fast enough to compete, and whether we could possibly maybe actually move past HTML/CSS/JS sometime in this decade.
It's ridiculous, and you claim it's "reality". Fine, your reality sucks, and there's no inherent reason why it has to win ... and it might not.
Mobile has gone from a side-show farmed out to consulting organizations to a mainstream in-house development effort, and the organizations themselves have shifted management and priorities accordingly.
It used to be that almost everyone had a web engineering organization in-house, even non-technology companies. That is changing. Companies like the NYTimes have gone from being grossly unable to manage mobile efforts and farming their work out to subpar contractors, to straight-up building a top-quality team of mobile developers.
Here's the tricky thing about that, too. Those developers, by the nature of where they work in the technology stack, are already quite versatile, and can choose technology solutions outside of the web stack. The problem that most organizations faced originally was that their web departments were a mono-culture and couldn't adapt.
So now you have companies that can and are building technology outside the web, and that means that the network effects that existed before are being torn down. The web tried to leap onto the application bandwagon, and the web failed. Now other technologies are taking over that space.
Who are these development organizations who truly enjoy maintaining five different apps for all the major desktop and mobile platforms and who are aren't going to make the jump as soon as HTML5 delivers everything they need?
Obviously there will always be applications (antivirus, encryption, etc.) for which a browser is poorly suited. But this percentage will never be bigger than it is today.
When will that be, exactly? The promise has been a long time coming, and in the meantime, the constitution of the industry is shifting away from a web myopia.
Next Thursday, 7:39 PM PDT time. Go outside and look at the sky.
> The promise has been a long time coming,
Indeed.
> and in the meantime, the constitution of the industry is shifting away from a web myopia.
I'm sure there are individual companies that fit that description, but I don't see it from where I sit. Here's an example of one of the classic big native platform apps doing stuff on the web. http://office.microsoft.com/en-us/
> the reality is that proprietary application platforms are taking over the application market
That doesn't even make sense as proprietary application platforms have always owned the application market.
You're asserting that there hasn't been a significant management and hiring shift in engineering departments over the past 5 years, moving away from what became a web monoculture in the post-90s environment, from roughly 2000-2005?
> That doesn't even make sense as proprietary application platforms have always owned the application market.
So you admit the web is ill-suited to serve as an application platform, and is failing to acquire traction in that space despite considerable but ill-focused efforts to the contrary?
> You're asserting that there hasn't been a significant management and hiring shift in engineering departments over the past 5 years, moving away from what became a web monoculture in the post-90s environment, from roughly 2000-2005?
I asserted no such thing, learn to read.
> So you admit the web is ill-suited to serve as an application platform, and is failing to acquire traction in that space despite considerable but ill-focused efforts to the contrary?
I admit? What kind of stupid opening is that? Show me where I said anything about the web serving as a great application platform over native apps.
You know what, never mind; you're an argumentative ill tempered child who doesn't know how to have a discussion properly. Have a nice day.
One of us has stuck to discussing the topic, the other, discussing the person. Good day.
There are far far worse systems for evolving widely used platforms.
That's fine, but perhaps it would behoove Mozilla to not participate in dooming the web as a competitive application platform simply due to a misguided belief that the web is defined by HTML/CSS/JS?
The problem with HTML5 is it was designed by committee for displaying documents not dynamic apps. While JS has come a long way to closing the gap with native performance, it's the other HLML5 tech that's holding the web back. CSS is ill-suited to be hardware acceleration and DOM is a performance sucking hack that kills the UX on mobile platforms.
Yes, really.
It's time to move on.
Neither NaCL, PNaCL, nor asm.js are 3rd-party browser plugins.
I agree that it's time to move on. It's time to treat the web as a real application platform, instead of as document model with a JavaScript scripting interface.
I think asm.js is brilliant and I hope it does turn out to be the way forward. But it's also a poster child for maintaining compatibility with existing browsers through standard Javascript.