Why I care about Firefox OS fading away(gist.github.com)
gist.github.com
Why I care about Firefox OS fading away
https://gist.github.com/SunboX/1fb5a3ebc520e4facf47
81 comments
IMO the bigger reason to lament the loss of competition here is the app model: Firefox OS was pushing for "apps" to be web apps. That seemed a lot more open to me than pushing for apps to be proprietary (Android, iOS, Windows, etc.). As great as mobile devices are, their walled gardens stifle creativity, privacy, and choice.
Apple was pushing for "apps" to be web apps when they first released the iPhone as well [1], with Steve Jobs going as far as to say that native apps would potentially "damage the phone system". It wasn't until after the iphone was jailbroken, and people kept insisting on more powerful development choices that they started on their app store. People have been saying that webapps are the future for a decade now. At this point, I have to say it's never going to happen.
[1] http://www.apple.com/pr/library/2007/06/11iPhone-to-Support-...
[1] http://www.apple.com/pr/library/2007/06/11iPhone-to-Support-...
Fair points. I think it's more nuanced. Native apps are great and necessary for many scenarios. However, there are a ton of native apps that could be just as functional as a responsive web site. Sure there were issues with discoverability which the app stores helped with in the beginning (now I think it's just as hard to get noticed in the store as it is on the open web).
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.
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.
What's more -- a significant number of apps ARE a wrapper around a UIWebView or something like it.
We've studied this and found that ~85% of the free apps on the Google Play store use a WebView (I like the term "mobile web app"):
http://adamdoupe.com/publications/large-scale-study-of-mobil...
There's a big difference between an app that 'uses a WebView' to render specific pieces of content or clicked links, and an app that is basically a thin wrapper around a WebView. Can you clarify whether your ~85% number is referring to the former or the latter?
Sure! The short version is that I don't know.
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.
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.
As far as I'm aware, mobile doubleclick ads need a WebView with Javascript and shouldOverrideUrlLoading(). I'm not sure about others.
How do you account for apps that only use the WebView for showing ads with the various ad toolkits out there?
How do you account for apps that only use the WebView for showing ads with the various ad toolkits out there?
In our study we didn't differentiate (from a security perspective, if you are vulnerable because you use a WebView when showing ads, then you are still vulnerable), so I don't have data for that.
It would be interesting data, although determining WebView for ads statically might be tricky.
It would be interesting data, although determining WebView for ads statically might be tricky.
> there are a ton of native apps that could be just as functional as a responsive web site
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.
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.
If we turn the web itself into an actual developer (and user) friendly platform, then we could probably start making better use of it as an application delivery vehicle. To enable this, I've been furiously working on this OS-in-a-browser concept for the past 3+ years: https://linuxontheweb.appspot.com
"This site relies upon cutting-edge web technologies that only Chromium-based browsers have implemented."
This might as well be Java.
This might as well be Java.
> 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.
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.
Everyone that follows the Java license never had any issues.
Only the two companies that tried to screw Sun had any issues with it.
Only the two companies that tried to screw Sun had any issues with it.
If you write a free application that runs on Java on the raspberry Pi you (probably) owe Oracle nothing. If anyone builds a console around that raspberry Pi, Oracle probably is owed money because the device is no longer a general machine. That is very different than chromium or anything else that is license compatible with your typical Linux distribution.
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.
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.
I've seen this anecdote given as rationale, but you can't say that the "web app" model on iPhones failed when Safari doesn't give you the needed functionality to make 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.
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.
I think that one day, web apps by default could work, but before that can happen the web must see sweeping change.
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.
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.
You'll have to explain why in details, not at a high level. In particular the fact that a replacement could perform "tens or hundreds of times better" is an extraordinary claim.
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.)
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.)
can't wait for servo "strict mode" css!!
If you reimagine HTML, CSS and DOM around web applications, you'll lose everything that make them great for their original purpose, which is rendering (non-fixed-layout) documents and structured content.
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.
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.
> In the 90s, we didn’t know what we needed
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.
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.
Don't forget Facebook's HTML5 focus.
Firefox OS was pushing for "apps" to be web apps. That seemed a lot more open to me than pushing for apps to be proprietary
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.
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.
'typical web app' is NOT the default deployment model for Firefox OS.
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.
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.
Apps on the Marketplace are deployed to a device and run locally, offline - complete with an intricate permissions model.
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.
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.
Yeah, but with a mobile app you have all those downsides...and you have to deal with the whims of a walled-garden gatekeeper like Google or Apple.
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.
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.
Not to nitpick, but people create native apps all the time and throw them up on servers for download and installation. In fact I have a handful on my phone right now. It's one of the main reasons I've gravitated toward Android on mobile and away from the more mixed iOS/Android devices I used to buy. My first smartphones running PalmOS and Windows Mobile allowed me to download and install apps from trusted developers and I disliked the dodgy hurdles I had to jump in order to do the same on iOS.
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.
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.
How is it that web apps are supposed to be open and apps are supposed to be proprietary, as though Microsoft OneDrive is "open" and IPFS is "proprietary"?
Is IPFS proprietary? Have they even gotten far enough along yet to really know?
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.
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.
I too think that losing the possibility for an open model to distribute apps is the biggest loss. I did a very enthusiastic article when the news broke about FirefoxOS aiming to become a more open alternative. It's both funny and sad now reading my enthusiasm from back then
http://blog.valbonne-consulting.com/2013/07/19/steve-jobs-is...
time to move on I guess
http://blog.valbonne-consulting.com/2013/07/19/steve-jobs-is...
time to move on I guess
Nokia was probably the first vendor to try out web apps with Web Widgets on Symbian.
Web is never going to be as feature rich as native, until the browser becomes nothing more than yet another JavaScript VM.
Web is never going to be as feature rich as native, until the browser becomes nothing more than yet another JavaScript VM.
I don't want to sound like the know-it-all smartass here, but from the moment Firefox OS was announced I gave it a negligible probably of amounting to anything and was really baffled that Mozilla decided to focus their efforts in that direction.
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 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.
Everything you say here is 100% true. Mozilla believes in the open web and, I'm speculating, they didn't like the direction of closed mobile ecosystems so they had a go and tried a different approach.
I applaud them for trying.
I applaud them for trying.
That's exactly it. Mobile apps are killing the web. Firefox OS was an attempt to combat that. This was no secret (e.g. https://wiki.mozilla.org/Booting_to_the_Web) but it's something that most people have overlooked. It was always going to be a huge challenge.
> Mobile apps are killing the web.
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.
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.
> from the moment Firefox OS was announced I gave it a negligible probably of amounting to anything
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.
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.
[deleted]
Isn't this basically the same argument as that Debian can't make any inroad into servers because IBM and Microsoft spend untold sums on R&D and marketing?
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.
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.
No, what is making or killing a mobile OS is whether some key apps are available or not. Many people don't really mind using an OS or the other, but they absolutely need eg. WhatsApp. The unwillingness or WhatsApp to write a mobile web app - or to let a 3rd party do it - made more damages to FirefoxOS than anything else writing in the comments so far.
But that's true of any platform ever. You need third party developers to either target your platform or a platform your platform is compatible with (like the JVM).
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.
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.
> 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.)
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.)
> 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.
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.
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.
> At which point you have to ask whether the missing things are actually that important.
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.
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.
> Right. And the choice of programming language isn't.
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.
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.
> 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 with which to attract developers.
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...
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...
[deleted]
The other problem in my mind is that there simply aren't a bunch of highly standardized smartphones for sale without an OS of some sort already installed on it. It's not like the computer market at all, where you can buy "blank" computers and or really easily wipe some crapware OS install.
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.
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.
This is something I never understood about Firefox OS. Why did they not package it up in a way that it could be easily installed on someone's existing smartphone. I was eager to give it a try also but there was nowhere to buy the hardware and I never found a way to install it on a spare smartphone.
This.
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.
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.
Well it is based on a pared-down Android build system complete with adb and fastboot access.
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.
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.
It makes me wonder why canonical is wasting effort on ubuntu mobile.
My thoughts exactly when Amazon decided to build a phone
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 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.
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.
"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.
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.
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.
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.
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?
> 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?
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?
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.
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.
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.
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.
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.
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'?
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.
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.
WinRT doesn't depend on the CLR at all, it's just an updated COM-based model.
My main problem with all these "well, it failed" alternative operating systems for phones are: I couldn't even buy them in the first place. I tried, but there was no hardware available in my region that ran on my network etc. The closest thing we've got is the nexus, but what we need is a 'standard' (de-facto or otherwise) phone like x86 PCs had to be in order for linux to take off.
yes was nearly impossible to buy one for me here in US
>in order for linux to take off
We need Linux on the Web!
https://linuxontheweb.appspot.com
We need Linux on the Web!
https://linuxontheweb.appspot.com
That isn't Linux.
I don't really care. And that makes me sad.
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 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 managed to get a developer phone with Firefox OS at a dev conference. I can say that hands down it's the worst phone I've ever tried using. I used it as my primary phone for a week and the operating system made me avoid doing anything. Making a phone call was the most pleasant, but if I had to send a text or try and use one of the apps I just found myself locking the phone. The webapp as a phone app idea was just really unpleasant especially if you had limited connectivity.
I admire Mozilla for trying, but that OS would have taken a miracle to get it working in a good fashion.
I admire Mozilla for trying, but that OS would have taken a miracle to get it working in a good fashion.
I seriously considered buying a ZTE - until I checked out user reviews online. The os is universally hated.
> „Tier 3“
What's the down-up bunny ears? Does this mean anything or just a typo?
What's the down-up bunny ears? Does this mean anything or just a typo?
Quotation marks are done differently in different languages [1]. The author of the article is André Fiedler [2], and he's from Saxony/Germany, where they apparently use, what you called down-up bunny ears [3].
[1] https://en.wikipedia.org/wiki/Quotation_mark#Summary_table_f...
[2] https://github.com/SunboX
[3] https://en.wikipedia.org/wiki/Quotation_mark#German_.28Germa...
[1] https://en.wikipedia.org/wiki/Quotation_mark#Summary_table_f...
[2] https://github.com/SunboX
[3] https://en.wikipedia.org/wiki/Quotation_mark#German_.28Germa...
I think it's the German convention for quotation-marks, like French use «guillemots» and Japanese uses 「corner brackets」.
The bigger question is What will happen to those who has Firefox OS shipped like Panasonic TV. ( Actually that is likely to be the only popular Devices using it )
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.
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.
> Let's say Android does not implement the new cool feature
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.
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.