For people who are interested in being able to develop on the device and flash new builds, I would suggest waiting a little longer for the reference device
Hope it's noticeably faster than the ZTE Open which I couldn't realistically use for day to day applications due to the lag and that it never updated to the latest Firefox OS and I had trouble doing it manually because I didn't know which build to flash my device with (lingo?)
Going to give this one a try.
So far, 2 Firefox phones and I haven't paid as much as I did for my 1 Android. So technically, I can still justify trying 1 more version of the ZTE phone if it comes out for around $99 in the next year or so :)
I keep trying though because I just love the idea that I can use my current web development skill set to create native apps for this so easily. My first attempts on the ZTE Open went really well.
>I keep trying though because I just love the idea that I can use my current web development skill set to create native apps for this so easily. My first attempts on the ZTE Open went really well.
I'd say those apps are hardly native, now, are they? There are several layers between the code you write, and the actual ARM(in most cases) machine code.
Native depends on the platform. Firefox OS is all in HTML, CSS and JavaScript so an application containing those languages would in fact be native for Firefox OS.
"Native apps" are ones that have been compiled down to machine code that's directly executable on whatever CPU or CPUs might be provided by the device in question. Ahead-of-time compilation is thus required.
As such, "native apps" cannot be represented solely in a higher-level code that is interpreted, regardless of how its interpreter may be implemented (this includes direct interpretation, JIT compilation, and so on).
Apps built using interpreted JavaScript clearly are not "native" apps, unless we're dealing with hardware that directly executes JavaScript code. The ARM CPUs typically found in smartphones today don't do that.
What you're describing is independent from the concept of "native apps". It's more about platform restrictions than it is about their capabilities. If an operating system like Firefox OS goes out of its way to not support real native apps, that doesn't mean that what it does support are "native" in any way.
I don't know if there's a good term to use instead, but it surely does not involve the word "native" in any way, given that that term already has very specific and existing meaning.
In the case of mobile, the term is used differently, at least as far as I have seen.
Native apps are often used to describe apps using the platforms own UI toolkit, widgets and API libraries (that is, they look and feel like platform apps and they integrate into the platforms services/notifications/...)
So for FirefoxOS, HTML apps could be considered "native" by this definition.
Speed definitely still matters for everyday apps on mobile devices, because their processors are so much slower than actively-cooled desktops and laptops, and because touchscreens demand a more responsive UI. JIT runtimes have gotten faster, but statically compiling to machine code (especially when link-time optimization is used) cannot be beat for things like application launch performance. And the machine code that Objective-C compiles down to is definitely more native than bytecode for a JIT VM.
Could we start to come to an agreement that maybe "Native" might be a bit of a marketing term? For example a browser rendering HTML and CSS is probably native under the current term. It is not until you get to JavaScript that things need the JIT VM.
There's still objective meaning to the term, even if opinions may differ on what threshold to use for "native". HTML and CSS aren't used to do computation, bytecode and machine code are. So it doesn't make sense to talk about whether HTML and CSS are native or not, only whether the rendering engine is. JITs produce native code, but a lower quality in almost all cases when compared with ahead-of-time optimization, so there's still good reason to make a distinction.
"Native" is not a marketing term, and we shouldn't pretend that it is.
It has a very specific definition in this context, and this definition requires that the application be represented in a form that's directly executable on whatever CPU is being used by the computer executing the application.
Anything that doesn't match that very simple criteria is obviously not a "native" app.
Maybe a new term is needed for describing this type of situation involving Firefox OS. I don't know what that would be, but I do know that we shouldn't go ruining an existing technical term.
Right. If there's bytecode of any sort that needs to be converted to machine code on the fly, then we aren't dealing with a native app.
We wouldn't consider a Java app running on HotSpot on a desktop or server Linux system to be considered a "native app". Thus we shouldn't consider a Java app running on Dalvik on a mobile Linux system to be considered a "native app" either.
Maybe that will change in the Android case if ART and its AOT compilation approach is more widely adopted. But that'll still be some time in the future, if ever at all.
You can actual write in assembler on iOS and use that (sparingly) in your programs, which means there are optionally no layers between you and the CPU.
For almost all apps, that's unnecessary, but it's there as an option if you really need it.
You see a bit of this in game development. At my old job, our engine was written in C++, however we had two copies of our matrix library: one written in C for desktop etc. and one written in ARM NEON asm, for building on iOS or with the Android NDK.
That argument would have more weight if you iPhone apps were distributed as Objective C source code.
They're distributed as ARM binaries. I think the standard definition of "native" is "binary". I would argue that Firefox OS apps are not native, and neither are Android's Java based apps.
That said, I don't think the distinction necessarily matters in practice. I'm excited by Firefox OS--Mozilla tends to do cool stuff.
The previous generation (ZTE Open) started at $79 and is now $69. This price point was so impressive for the html5 capabilities that it had. I even did a presentation on it's SVG performance vs. a similar Android device[1].
I'm concerned about the increased $99 price point. I thought the target market for Firefox OS was the developing world, where they could release extremely low cost phones ($50-$80) that can run the full gamut of html5 (vs. Android that is stuck in 2.3 for phones this cheap). Why release new phones that won't see as much adoption (because of the higher price)?
Woo! Great news! One of benefits of having cheap devices is that it significantly lowers the barrier to entry for the developer community. It becomes super encouraging to pick up a phone just to fiddle.
However, one of the biggest problems the community ran into for the ZTE Open was that hardly any Mozilla devs had one. So even though it was the most easily obtainable phone for the dev community, it received very little Mozilla support.
As these low-end devices push the limits the most for Firefox OS, will the Mozilla team start to work with them more?
Some Mozilla devs have them, mostly in the Taipei team where a lot of the work on this phone is occurring. Hopefully they'll become more common as time goes on.
> This price point was so impressive for the html5 capabilities that it had.
No, it isn't. The price is standard, or even high, for the hardware it has. And the hardware is pretty crap (hence why the performance was also crap).
All phones have equal HTML5 capabilities, the difference is what you can do while getting good performance. And the answer to that on the ZTE Open was "not a damn thing", because it never had good performance.
Agreed that the hardware was on par or slightly lower than other $80 smartphones. However, phones with that hardware can only run Android 2.3, which severely limits your html5 capabilities. The presentation I linked above was comparing the svg performance between Firefox OS and Android.
Are you talking about the Sony Xperia E1? Comparing to the two[1], it has twice the RAM and more+faster cores than the ZTE Open. Also, isn't it like $169 or something?
Almost identical specs as a Lumia 520, too. 4 GB storage instead of 8 GB (both extensible via sd). Even for a low budget phone, I don't get why they don't go with at least 16 GB. 4 GB is pathetic.
It's even closer to the Nokia X. Once you've installed Google Play that's not bad, and abroad you can pick up the dual SIM version.
The Nokia Store is missing pretty basic apps so provides a selection of third party stores for you to install. Alternatively you can sideload Google Play services.
Here in Czech Republic (which is semi-eastern europe), Lumia 520 is 50 % more expensive than ZTE Open C, and 8 GB Moto G is twice the price.
Now, Lumia 520 has better camera and perhaps better screen and CPU, and Moto G is whole different matter (720p, quadcore, 1 GB RAM), so the prices make sense. The cheap Chinese devices that you can get for the same money (like Huawei Y330) have generally the same hardware, so I don't think ZTE is overpricing the ZTE Open C.
So, while I can't give you prices, it's possible that the ZTE Open C is more competitive in markets like Eastern Europe or South America.
EDIT: the reason to get ZTE Open C instead of say, Lumia 520 or Huawei Y330 would be that FxOS devices should have better browser performance for the money, at least from the impressions from the SVG comparison video, and the browser seems to be much better integrated to the system than on Android or Windows Phone.
I was unaware you could run Firefox OS on a Lumia 520. Do you have a link that describes how to do that? Or is there a vendor selling Lumia 520's with Firefox OS? I also have not seen Moto G's running Firefox OS.
EDIT: Possibly I should add some context to my question. I'm not sure why the comment is comparing a phone running a different operating system and different software. So I thought maybe these other phones could run Firefox OS and I just didn't know. I've been using Firefox OS for about a year and would not want to use a phone on a different OS. The article was about a new version of a Firefox OS phone.
At the bottom it lists the support and I see all browsers with "Not Supported" and then this line "This API is currently available on Firefox OS only for any installed applications."
Do the "principles" in your case revolve around openness, freedom, and so forth?
I've heard a lot of people use such ideals when advocating for Firefox OS, but I just don't see it all holding true in practice.
Firefox OS is one of the more restrictive environments, at least for developers. I'm basically stuck using JavaScript, HTML and CSS. If I want to use any other language, I have to try to molest it through something like Emscripten. If I want to create a native app, I'm out of luck.
At least a platform like Android gives developers a comparatively wide variety of options, from Java, to C and C++, to JavaScript/HTML5/CSS.
By limiting the freedom of developers to create apps as they see fit, then it directly impacts the freedom of end users to use such apps.
And I don't see Firefox OS as being particularly open in other respects. Maybe the code is available under an open source license, and maybe Mozilla will accept minor bug fixes from the community, but I really doubt an average user would have any ability to influence/impact/control Firefox OS beyond that. Decisions are foisted upon the users. It doesn't seem any better than Android, or iOS, or whatever other platform you want to consider.
The same goes for the "But we implement open standards!" claims. The process to come up with such standards isn't very open at all. It ends up being controlled by a small handful of major browser vendors, with minimal to no input from others. Merely being published does not make a standard "open".
All in all, it makes no sense to me to choose Firefox OS on a matter of principle. It doesn't actually meet whatever standard is being set by those principles, yet it still gives a much inferior experience to the alternatives.
There are different kinds of freedom and openness.
FxOS is made by Mozilla, which is very different in both goals and culture from Google, Microsoft and Apple. You don't need special account with OS vendor to unlock full functionality of the phone like with Android and WP, or to even use it at all as with iOS. You don't need special license (that actually costs money, IIRC) to load you own software to your own device like with iOS or WP. You can develop the software for FxOS on any operating system, unlike with iOS and WP.
This is different kind of openness than "can I use C", but to me it is more important. Personally I hate Javascript with strength of thousand suns. But FxOS seems to be worth the price.
Here's a semi-review by someone who has had the phone for a week [1]. It is not the most professional of reviews, but it could give you some impressions how the phone feels.
That's an exceptional value. So cheap for such good features. And the firefox marketplace has lots of great apps. FirefoxOS really seems to be taking off, particularly in Latin America.
https://blog.mozilla.org/blog/2014/02/23/new-developer-hardw...
It is due to be shipped soon, is going to be used widely internally for development and full public builds / a good dev experience has been promised.