The death of FirefoxOS was inevitable, because of two words that the supporters dread. Native Apps. If your problem did not match the things that Javascript was good at, you were completely out of luck. Every other platform has a way of writing your app in different languages. The iphone has native swift and cocoa, plus javascript, plus lua, plus a whole host of other choices. Android has java, javascript, and anything else that can be run via jni. Windows has WinRT, which doesn't offer native code, but does offer anything that can be run under the CLR -- C++, C#, Javascript, etc. Firefox OS's sticking with just javascript meant that it was hamstrung from the start, with much less ability to create apps that really stood out, leaving it to wallow in mediocrity.
There aren't any substantive differences between the CLR and the minified JS+asm.js model (or, even more so, the minified JS+Web Assembly model).
There are differences, but they're details. CLR IL is quite high level.
In general, I feel people oversimplify the "Web vs. native" performance debate to differences in programming languages, because programming languages are easy to tell apart (unlike for example rendering stacks) and it's easy to benchmark them. But I probably wouldn't even put the JS vs. Obj-C or JS vs. Java dichotomy in the top 5 reasons for any performance difference.
There are rather substantive differences. For starters, the CLR doesn't have to be the IL anymore; since Roslyn and the WinRT framework, you can compile down to native code. However, the most important things are what the CLR gives to the developer that Javascript doesn't.
Syntax-wise, the CLR's threading is much more flexible -- you can have your workers talk to each other directly when that's the most convenient way of doing things, instead of the Web Workers model where everything has to pass through the main thread. The CLR also supports more than two number types, which is useful in a number of situations, such as art programs, where most if not all of your actions are going to be against smaller types. Web Assembly fixes some of these problems, like providing reasonable number types, but at the same time, ignores other flaws that still exist, like a lack of vector types, which is something nearly every modern processor has and uses for improved performance.
The problem with Javascript, and its various extensions and adjuncts is that it still suffers from the same walled-off mindset that it has for the past fifteen years. Numbers are numbers and you're crazy if you want anything other than these beautiful 64 bit floats, a compact, easy to parse bytecode format is an affront to the open web, even if the alternative is a hack that is just as unreadable, and threading will just lead to programs crashing. Javascript may be fine if you're delivering a web page, but the tools it gives make it woefully unusable for near anything else.
Nope. asm.js as implemented in Firefox supports native integers and SIMD. SharedArrayBuffer gives you threads--but honestly this is a red herring, with apps barely making any use of multicore and iPhones being limited to 2 cores anyway. Web Assembly gives you 64 bit ints.
"Compact, easy to parse bytecode" is also irrelevant. JS is easy to parse. And the parser is such a tiny part of a JS engine it doesn't matter at all in practice for complexity. It's an aesthetic concern.
The actual performance problems Web apps hit have nothing at all to do with any of the areas you describe anyway. You think the Facebook app is making heavy use of custom SIMD or multicore? The SIMD support in Firefox gets barely any use because apps can't find a use for it. Apple isn't adding cores to their phones because apps aren't using them. And so on.
Apps barely making use of multicore? Maybe in your web world.
We would not have been able to ship the apps we've shipped were it not for being able to exploit shared state concurrency.
... and yes, I think the Facebook app is making heavy use of multicore and SIMD; multicore directly, and SIMD by way of the heavily optimized native frameworks shipped with the device.
I've previously made of NEON to get ideal performance out of critical path file decoding on lower end devices, where having those additional CPU cycles available made the difference between stuttering and smooth UI.
Stop trying to fit native apps into a box you've defined to match your web-centric experience, where low expectations are simply the norm.
If apps were using multicore all over the place, the hardware vendors would have responded by increasing the number of cores on the CPU as they planned to. Instead, they didn't, because people aren't using it.
I don't see any particular use the Facebook app would possibly have for multicore. Image and video decoding perhaps, but browsers already multithread those.
The point about native frameworks making use of SIMD applies equally to the SIMD that the browser engine components internally use.
Finally, I've been writing native code almost exclusively for the past five years.
In this context threading is less about making maximum use of multiple cores and more about "never blocking the main/UI thread". Even on a single core device you usually need to start offloading heavy computation to a background thread to keep the UI responsive.
Even today I'll run into websites that lock up a browser tab because they're running a whole mess of Javascript soup (typically jQuery). I know we were promised WebWorkers like 5 years ago but does anyone actually use them?
Yes, I fully agree that this is one of the biggest problems. Web developers don't treat Web Workers like they treat Blocks in Objective-C, and this is causing performance problems. On the engine side, we have to figure out how to make workers and off-main-thread work just as easy to use as in Objective-C and Java--I believe this is doable with effort.
Multicore isn't free in a battery constrained device, and yet devices are multicore. The fact that you don't have an 8 core phone doesn't mean multicore concurrency isn't used.
There are all sorts of things that benefit from multicore concurrency; a simple example is keeping data handling (including SQLite query execution, which has a non-zero cost) off of the UI thread that's responsible for keeping table scrolling glossy smooth.
You may have been writing native code, but you clearly haven't been shipping high gloss end-user applications on mobile devices.
Concurrency is not parallelism, and you're conflating the two. Multicore is for parallelism: literally doing multiple tasks at the same time. Apps are not making good use of parallelism. Apps certainly do make good use of concurrency--your example of moving background work off the UI thread is an example of that--and the Web needs to support that better. But that's not a parallelism problem, and it's not related to multicore: note that what you describe is a good idea even with only one CPU.
> but you clearly haven't been shipping high gloss end-user applications on mobile devices.
Yes, I have. Can I suggest you stop inserting these random jabs into your posts?
This is profoundly false and I would have hoped you'd know better than to make an argument like this. There's an enormous gap between the CLR and (even bleeding-edge) asm.js, not only in standard library feature set but in language feature set. MSIL is dramatically more expressive and the runtime offers a bunch of capabilities that still aren't available in the browser.
At present if you want to actually run a typical .NET application in the browser, you will have to boot and run an entire CLR implementation in asm.js, specifically because asm.js is not expressive enough to map typical CLR code to it. This includes things like reimplementing garbage collection because the browser still doesn't offer basic primitives like weak references. Even once you do that, there are specific things you won't be able to do - for example, weakly hold references to the DOM, or handle cross-language reference cycles.
For the record: I am the author of a .NET -> JS translator with near-complete CLR feature support, including unsafe code (pointers) and p/invoke. This stuff is not trivial, and much of the difficulty is a direct result of how anemic asm.js is as a compilation target, not to mention how pathetic the ES5 stdlib is. I'm also a participant in the WebAssembly spec process and I think you've misrepresented what it currently offers.
The web has a bright future but pretending it doesn't have problems does no good. It's honestly quite insulting for someone to claim that everything is OK here when I've been fighting hard for years to get the ecmascript and HTML5 feature sets moved forward so that the web can actually compete with .NET.
I'm not claiming everything is fine. There are lots of problems with JavaScript as it stands.
I don't think the differences between the CLR and JS are "substantive" in that they make it impossible to build working, performant apps. So far the main things you have cited are (a) the lack of WeakRef and (b) a bad standard library. I truly don't mean any "insult" here, but weak references do not strike me as something that makes the difference between an app working (and working fast) versus being incredibly slow. WeakMap covers lots of the use cases for WeakRef already. On the native side, Objective-C didn't even have weak references until iOS 5. As for the standard library, developers just add lodash or whatever they need; it's not ideal, sure, but it's just a question of whether the functionality comes bundled or whether developers add it themselves.
If you add all the things you want to JS in order to get it up to parity with .NET by your definition, but do nothing to the DOM and rendering stack, you'll still have the performance problems people cite with mobile Web apps. On the other hand, if you do nothing to JS and fix the DOM and rendering stack, then I believe the Web will be able to compete with native. This is not to say we shouldn't improve JS, but it's not on the top list of things holding the Web back.
It's not so much Javascript itself that is the issue so much as the reliance on HTML/CSS for the UI. iOS (and recent versions of Android) are designed around the performance limitations of their devices (especially on early hardware), and there are a lot of optimizations in their respective UI frameworks to ensure the UI stays responsive, and scrolling stays smooth, even when working with large amounts of data.
Throwing the kitchen sink at developers in the form of HTML/CSS does not encourage performant design, and indeed when you read stories of developers trying to write complex mobile apps using web technologies it often eventually devolves into a performance optimization game (that doesn't always succeed).
That said, I'm sure someone could put together a UI framework based on JS that rivals the perormance of iOS or Android. But no one has bothered to do so because they view HTML/CSS as "good enough". Which is critically flawed thinking.
This is closer to the mark: implementations of CSS cause a lot of problems. CSS isn't obviously worse than mobile frameworks though. In fact, I'm getting fairly confident that CSS can potentially achieve better performance than UIKit and the Android stack (because it's parallelizable and declarative as opposed to procedural, neither of which apply to mobile app frameworks), though of course browsers of today don't take advantage of this well.
Another large issue is that browser implementations of CSS are a black box: very few Web developers understand how it works and browsers present a hidden maze of slow paths. (Which CSS animations will run in the compositor? Which run a separate thread? What events cause off main thread scrolling to be disabled? What order will the browser fire events in?) This is, again, an issue that's more about implementation more than anything: I believe a better from-scratch implementation of the CSS specs would fix a lot of this.
> If your problem did not match the things that Javascript was good at, you were completely out of luck. Every other platform has a way of writing your app in different languages.
Why didn't FirefoxOS also include a mechanism for native apps in some other language? It still could have been an open platform. I understand they like to promote Web technology, and they still could have the HTML5 apps, but that's not inherently more open than some other options.
That raises an issue I hadn't considered: Is Mozilla's mission the 'Open Web' or 'Open Internet'?
> Windows has WinRT, which doesn't offer native code,
WinRT is pure native code.
It is just the second coming of COM+ 2.0, the competing project to CLR, back when Microsoft was researching between improving COM or extending something like Java into a COM like framework.
