Why I care about Firefox OS fading away
gist.github.com
gist.github.com
[1] http://www.apple.com/pr/library/2007/06/11iPhone-to-Support-...
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.
We were looking for instances of insecure WebView usage, so from a security perspective small piece vs. entire app doesn't matter too much (and is difficult to measure, especially when looking at 1.1M apps).
However, some of the other numbers from our analysis can be useful to draw a picture of WebView usage.
We statically looked for uses of WebView, and 85% of the 1.1M apps used a WebView.
Of those 998,286 apps:
- 97% enable JavaScript (which is off by default)
- 36% use the JavaScript Bridge Interface (which is a fairly good indicator of heavy WebView usage)
- 94% implement a shouldOverrideUrlLoading method of the WebView (another good indicator that the developer is using the WebView for something non-trivial)
- 27% implement an onReceivedSslError method of the WebView (indication that the developer is using the WebView for something non-trivial). (Sadly, 29% of the apps that implement onReceivedSslError intentionally IGNORE all SSL errors.)
So I guess the takeaway is that 85% is an upper bound, the real number of WebView-only apps is absolutely lower, however it's clear that WebViews are significantly used in mobile apps.
How do you account for apps that only use the WebView for showing ads with the various ad toolkits out there?
It would be interesting data, although determining WebView for ads statically might be tricky.
That is probably true but most would require 10x the development effort at least and be obsoleted much sooner.
And then users don't want generic lowest common denominator applications; users want software to make the best use of the platform.
This might as well be Java.
Chromium specific certainly isn't as good as open standards, but it isn't as bad as Java. Once chromium is ported to something it doesn't face legal uncertainty.
Only the two companies that tried to screw Sun had any issues with it.
Whether or not someone owed damages is immaterial to the problem of trying to get everyone an appropriate license who might want to run your software in contexts you haven't imagined yet.
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.
CSS has tons of problems, but almost every replacement for CSS that I've seen proposed would almost certainly have worse performance characteristics than CSS, optimally implemented, would. Most of them kill parallelism and kill opportunities for optimal GPU usage—they're proposed cures that are worse than the disease. The problem is mostly that browsers don't implement CSS as well as they could due to legacy, not that the technologies are fundamentally flawed (though this is not to say that they're not improvable, far from it).
To create a better architecture, you first need to have an in-depth understanding of what the problems in CSS actually are. Otherwise, you'll just trade one set of mistakes for another. (In particular, a CSS replacement that optimizes for Web developer productivity will not necessarily have acceptable performance characteristics—too often, people assume that "easy to develop in" implies "runs fast", which in fact these concerns are often in direct opposition.)
Except the Web had already been invented at Xerox PARC and further explored at ETHZ using native technologies, so I guess some had already a pretty good idea.
Surely there are some hiccups left in the design that come from its organic growth and could be smoothed out; but those are not as much as you would think, and most of that work has already been done in html5+ES6.
The end result is a platform that is great for zero-install distribution of web applications AND web documents. A new framework that centered only on the first goal would be severely limited, and a new one that served for both would look a lot like the current one.
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.
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.
This argument is made frequently, and I don't get it. With a typical web app, you have no idea what the backend is doing, and your data is stored on servers owned by third parties. At any time they can revoke your access, go out of business, share your data with others, or change the app in user-unfriendly ways. An open source Android app that runs and stores data locally (perhaps with an option for cloud storage) seems much more "open" than that.
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.
I agree completely about the privacy thing though. I guess it's a bit easier to see when a native app is sending data over the network with the right tools but in general, there's just as much room for abuse with either model.
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.
So like Android, except using HTML/JS/CSS which I'd consider either an irrelevant implementation detail or a negative.
No less open than the github hosted, Android app scenario you mention.
Sure, no less and no more. The real issues are whether the user is allowed to run the app without explicit permission from the OS vendor, and whether they're required to hand control of their data to a third party. Once we have the answers to those questions, whether the app is written in JS or Java or Swift or C++ doesn't really matter in terms of openness.
Web is never going to be as feature rich as native, until the browser becomes nothing more than yet another JavaScript VM.
http://blog.valbonne-consulting.com/2013/07/19/steve-jobs-is...
time to move on I guess
I don't think they appreciated just how brutal and unforgiving the smartphone market is. Apple makes money on it, but they spend billions on R&D and billions more on marketing. Samsung makes money, but a lot less than they used to and only because they own their entire component pipeline and also spend billions on marketing. Google makes money, because they own the operating system that 80% of the phones use and use it to push people to their wide array of services. Everyone else is breaking even at best, and hemorrhaging cash at worst. Think how many billions Sony and Microsoft and Nokia and Palm and Blackberry spent on their smartphone efforts only to get shoved to the sidelines. This is a market where you've gotta pay big in order to play; to be honest it was downright silly of Mozilla to expect that they could get a foot in the door.
I applaud them for trying.
It's like saying desktop apps are killing the web which is stupid. You need both. Yes you need strong standards and open technologies but a random mobile game or a contact list on my phone isn't the web.
> Firefox OS was an attempt to combat that
It wasn't going to work anyway given the poor performances of Firefox OS. That's what killed it more than anything else. They chose to go for low end devices with web techs ? we all know how web techs perform in general, badly, compared to solutions based on Java, C , C++, Swift and co ... This true on desktop and even more true on limited devices such as phones.
Firefox OS is open source and it's a good think, but aside from open source developers,most buyers don't care about that.
What has been killing Firefox OS (and nearly everything else Mozilla does outside of Firefox) is their peculiar abhorrence for anybody else writing anything in native code.
Mozilla wants to use the web as that platform exclusively, which is fine if everybody is already making everything for the web and there is nothing of importance you can do with native code that you can't do from the web. But neither of those is true so their strategy fails.
There are things you can do on iOS that you can't do on Android (e.g. Apple Pay), and vice versa (e.g. Google Now). iOS fails the "there is nothing of importance you can do on Android that you can't do on iOS" test, and Android fails the "there is nothing of importance you can do on iOS that you can't do on Android" test. Yet here we are, with two successful platforms.
I think the truth is a lot more nuanced, and in particular I think the emphasis on "native code" is a convenient red herring. (Android isn't really native code for anything but games, and iOS Objective-C is technically native code, but that Smalltalky object system is not up to C++-level performance, so the distinction doesn't mean much.)
At which point you have to ask whether the missing things are actually that important.
> I think the truth is a lot more nuanced, and in particular I think the emphasis on "native code" is a convenient red herring.
"Native code" in this context is as distinguished from aggressively sandboxed javascript received over the network in real-time. It's not only about performance. It's about the app still working where there is no wireless signal, or being able to read or write device-wide settings or files, or make a VPN work, etc.
Right. And the choice of programming language isn't.
> "Native code" in this context is as distinguished from aggressively sandboxed javascript received over the network in real-time... It's about the app still working where there is no wireless signal, or being able to read or write device-wide settings or files, or make a VPN work, etc.
Firefox OS had all of those capabilities (maybe excluding VPN depending on your definition--but if your definition of "making a VPN work" excludes Firefox OS it excludes iOS apps too). Firefox OS was based on locally installed apps.
The platform isn't just the language.
> Firefox OS was based on locally installed apps.
Then I have no idea what we're talking about.
So the point of Firefox OS was supposed to be what, you make the UI using HTML and javascript but then it runs locally and exposes system call wrappers through javascript?
That's not actually so bad of a concept, but then you have the opposite problem. Nothing that does anything you can't do in a traditional web page is portable outside of Firefox OS so you have no user base to attract developers.
It seems like they're trying to compete with Android when they should be trying to compete with Java. Make a runtime that runs the Firefox OS apps on Debian and Android and Windows. That would be interesting.
Yes, I'd agree that is/was much more of a problem than the technology stack itself.
> Make a runtime that runs the Firefox OS apps on Debian and Android and Windows. That would be interesting.
There is such a thing: https://developer.mozilla.org/en-US/Marketplace/Options/Open...
Manufacturing hardware is stupid expensive and smartphones are really refined at this point. All the players with the capacity to make high-quality phones are already committed to their OS for all kinds of monetization strategy reasons and Firefox OS wasn't offering anything to them.
Between users, devices, manufacturers and carriers, Firefox OS's only chance was to commit to a 10-20 year plan and fund continuous development until it was so good it was obvious that it needed to start ending up on real mass consumer devices.
Not only that, but the number of spare smartphones is steadily increasing. Barring impact damage, the hardware generally lasts longer than the period of time a consumer is satisfied before wanting something newer.
But older devices are also increasingly left out in the cold with software updates. Anything that can't run the latest OS release will miss out on a portion of apps. Anything that's more than one OS release old will miss out on most of the apps. Three OS releases? You'll be able to run what came with the OS and a bare handful of carefully backward compatible (or all but abandoned) apps, maybe.
So... there's an increasing amount of old devices that could really use something else to run on them.
Maybe crowdfunding? Replicate the Cyanogenmod infrastructure and provide automated releases on every CM12.x device for Fx OS and others (Replicant, LuneOS, sailfish)?
I think Ubuntu Touch is slightly different but they run a bastardised Android inside an lxc container, so could possibly benefit from auto-building each 'inner' image too.
Many said the same about Mozilla building a browser to take on Microsoft, with a desktop monopoly and enormous resources, and Internet Explorer with 95% market share. This same comment is heard by every failed tech venture, which includes most startups: "I told you it wouldn't work."
It's a good thing so many people are willing to ignore that advice, also heard by 100% of entrepreneurs starting new ventures. I'm sure others here find it equally familar.
I'm a little surprised to see it receive so many votes on HN.
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.
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.
"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.
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.
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.
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?
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.
> 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?
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.
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.
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 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.
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'?
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.
We need Linux on the Web!
I was really excited about Firefox OS when Mozilla was announcing it. I've been playing for years with free smartphones like Neo Freerunner, GTA04 and (surprisingly free) Nokia N900, and the situation on Android market was far from being good for me. I still cannot really change my phone without downgrading my user experience. Firefox OS offered me some hope.
Unfortunately, it turned out that Firefox OS was just Android-me-too, without much of added benefits when it comes to user freedom. Sure, the development model was more like baazar than cathedral, but how did it matter if most of the Firefox OS devices out there were as blocked and closed as Android ones?
Mozilla even had a certification program you needed to pass in order to use Firefox OS brand with your device - and guess what? Closed crap like ZTE Open was passing the certifications. Mozilla was basically endorsing devices you had to break into in order to be free to use them as you wish. How is that different from Android?
I had high hopes, but Firefox OS disappointed me.
I admire Mozilla for trying, but that OS would have taken a miracle to get it working in a good fashion.
What's the down-up bunny ears? Does this mean anything or just a typo?
[1] https://en.wikipedia.org/wiki/Quotation_mark#Summary_table_f...
[3] https://en.wikipedia.org/wiki/Quotation_mark#German_.28Germa...
At first they say Firefox OS isn't going away and it will support IoT, so development will continue. Panasonic even made a PR just so people don't freak out and stop buying their TV set.
Now it is moved to Tier 3 support...
I really don't know whether i should blame Mozilla or Panasonic on this one.
If there is enough demand for it, someone can do a Kickstarter, raise enough money, build it and push it into Android. Or some other company can fork Android, add the cool new feature and steal Android's market share.