Why I care about Firefox OS fading away (opens in new tab)

I don't think "web apps are the future of mobile". But I do think there is a better separation of native apps and mobile/responsive web apps.

For example iPhone Safari does not do push notifications, an essential ingredient if you want web apps, whereas Chrome on Android does. With Chrome on Android you can do Facebook's Messenger without installing anything. And while iPhone Safari led the way with some useful additions, like the possibility of specifying higher resolution icons for "Add to Homescreen", they dropped the ball on such improvements since iPhone 3G. In fact iPhone Safari is behind in implementing web standards. Apple also rejected Adobe's Flash and I concede that was for good reasons, but that left a huge void in how media, like video and games, could be delivered. You know, things like HTML5 Video and WebGL came after that. You also have to take into account that the first two models (iPhone 1 and iPhone 3G) had poor resolution, poor hardware and poor battery life by today's standards.

So you know, if Safari on iPhone 1 is the anchor by which you judge native apps, well of course native apps are better. You also make it sound like "the people" forced Apple to open their SDK. Oh come on, you can't be that gullible. An SDK was inevitable. What's the point of building your own OS if you can't lock people into its APIs? That's a lesson Microsoft taught us. The only reason for its delay was them taking the time to figure out how to control it. Do you remember when Google Voice along with other apps where rejected because they "duplicated existing functionality"?

You may not see it, but web apps have been winning for some time and there's no end in sight. When Google Voice was rejected by Apple, Google still delivered its functionality by means of a web app. When the Google Maps integration app was replaced by Apple with their own, which I might say it is inferior and unusable in my city, for a while iPhone users used Google Maps on the web, as it's very much usable.

All it takes for web apps on mobile phones to be more common is for the browser makers to implement the needed functionality. Right now the front-running in implementing web standards relevant for mobile phones is Google's Chrome and sadly not Firefox (though I hope that will change). And I must say it works well.

The lackluster performance and high resource usage associated with web apps is a direct consequence of the complex patchwork nature of each component involved. Quite simply, the web was not designed to be used the way we’re using it, and evolving standards have made browser rendering engines horrifically complex (and in some cases convoluted).

What’s needed is a fundamental reimagining of HTML, CSS, and the DOM at minimum with little to no regard for legacy. In the 90s, we didn’t know what we needed but now the picture is crystal clear. Should we use this knowledge to design a new web, I’m positive that the result would be just as open as the web is now while performing tens or hundreds of times better — it’d likely be good enough to make web apps competitive with native apps under a far wider set of circumstances.

Apps on the Marketplace are deployed to a device and run locally, offline - complete with an intricate permissions model. The only 'web' aspect is being written in HTML/JS/CSS and the extent to which they integrate with the cloud. No less open than the github hosted, Android app scenario you mention. Maybe Firefox OS does need an f-droid equivalent for a free app catalogue though, if and when Mozilla pull the Marketplace servers down.

So be aware of the distinction between mobile web 'apps' and mobile web sites.

That is, I can't just create an app and throw it up on a server like I can with a website. It needs to be "approved" first. That's a HUGE barrier to openness that the web never had, and hopefully never will have in the future.

And, even though mobile apps run natively, I don't think one can be very confident that they're any more private than a typical website...analytics & the drive for data is there regardless of medium.

OneDrive having a web client doesn't make it open. If you think about OD as just a way to access and share files then it's probably open since the web client will run in any modern browser. However if you think of OD as a platform of sorts then I wouldn't consider it open since, to my knowledge, MSFT controls everything about it and it's not standardized.

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.

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.

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.