“Mozilla today announced that the regional launches of Firefox OS smartphones will begin soon. Deutsche Telekom and Telefonica will release the first Firefox OS devices, the ALCATEL ONE TOUCH Fire and the ZTE Open, soon. Individual partners will announce specifics about launches in each market soon.” Lots of soons in there.
Android, Firefox OS, Ubuntu Touch… I wonder how all of these will compare, and how the competition between them will work out. Actually, I would like to see them all survive (obviously Android’s success is pretty much guaranteed by this point); you can never have too many alternatives for when one of them starts playing nasty. But when you add the fully proprietary competition (iOS and Windows Phone), I seriously can’t imagine all five contenders surviving and thriving for long.
Edited 2013-07-02 06:10 UTC
Personally, I care only for devices that offer native applications, as such I don’t have big expectations for browser only OSs.
All mobile OS already offer mobile browsers, so if you want me to switch OS, the user experience has to be worthwhile.
I agree, and from what I’ve seen in the Firefox OS videos it is considerably laggy on the devices they’re launching.
It seems counter intuitive to me to on one hand want low power utilization, low hardware requirements and great performance but then turn around and write large OS components in javascript.
I’m sure someone will post some microbenchmark or link to a useless webGL tech demo to try to argue against this, but it doesn’t change the core point that it is just a less effective environment to develop in.
There’s no supporting tooling, no competent debugger, no cohesive framework. Its a mish mash of components which doesn’t really add up to a meaningful experience for the developer.
That said, I don’t see why this couldn’t immediately take off. Its a shitty, but less shitty low end Android distribution with Mozilla’s science experiment crammed in.
They aren’t trying to sell this idea to the western countries where people can pay several hundreds of US dollars for a phone.
They are going where lower than where Android can go, the people that currently can only afford a feature phone.
The same people that don’t have a creditcard to buy apps.
That’s great. I was commenting on their stated goal of low resource utilization, while using a language and framework with terrible performance. Real world performance. Not Microbenchmarks.
Re: Credit Cards
Carrier billing is a great thing bringing paid purchases to more people in more places.
Except it is being launched in Spain where it is the European country with the highest percentage of Smart Phone adoption.
That is because one of the carriers is Telefónica they wanted to launch in their home country first I guess. The plan is to launch in South America in a couple of weeks.
Not only I think that browser OSs do suck from a performance point of view, but I think that JS/HTML based interfaces and programming like in Tizen, Metro sucks equally.
While the HTML5 situation in Metro apps is a little better with Blend’s tooling and the option of using TypeScript for development.
Its also helped out by WinRT components written in C++ or C# being callable by JS via projections. A lot of the computational heavy lifting can be offloaded to that.
But honestly, the Windows Store is around 5% HTML5 apps. Given the choice, I’ve seen a lot of developers opt for a native experience.
Unlike all the other attemps the advantage of FirefoxOS is, that it’s only web-technologies. There are no other parts running on the phone. Just a Linux kernel and maybe wpasupplicant for handling WPA/WPA2.
And FirefoxOS is targetting the low-end could be a good idea, there are 6 billion phone users in the world and only 1.1 billion have smartphones. This is because smartphones are expensive. And lots and lots of people can’t afford them.
Also if you look at the number of programmers in the world for all the different langauges together is 20 million, this includes everything from kernel hackers and embedded devices to business intelligence and 8 of them million are webdevelopers.
The number of people building apps for Android and iOS are in the couple of 100.000 range.
Edited 2013-07-03 00:08 UTC
Ever heard of WebOS?
Do you see how many other processes are running on WebOS ?:
http://www.webos-internals.org/wiki/Running_Processes
Right, because Firefox OS will be a Linux kernel with just one process (Firefox) on top.
Actually, seperate processes for different apps for security.
Like what Chrome does. The Mozilla Electrolysis project didn’t make it into the desktop or Android version, but FirefoxOS does have it. And it’s needed as certain parts need to talk to the hardware.
Also, Mozilla handles the updating of the top part and the manufacturer/carrier handle the bottom part (kernel, drivers, so on).
That separation should hopefully mean everyone, even many, many years after the manufacturer/carrier stopped to care about the customer is still running the newest version of FirefoxOS.
Normal people don’t update mobile OS, they get new ones with every contract renewal.
– I was also one of them.
Especially ~10 years ago, when Netscape dumped their working browser. *)
Instead they wrote a bloated cross-platform GUI framework with XML, XUL and whatnot TLAs. The browser was more like a demo program on top of it. Remember the horrible performance of the first Mozillas?
Now in FirefoxOS this framework is all that sits between the kernel and your HTML5 app.
10 years later (13, it’s actually 13!) this passes as lightweight architecture…
I actually toyed around with the FFOS Peak model and was positively impressed. It surely beats the landfill Androids. And performance improvements for the desktop browser (like just reported) should mostly make their way to FirefoxOS.
*) Seminal rant over here: http://joelonsoftware.com/articles/fog0000000069.html
Well if the entire top layer of the OS is basically web-based, then by extension wouldn’t that make all “native” applications web-based as well? If it flops it flops, but who knows how it will turn out. I’ve obviously never used it so I don’t know what it is like. As much as I’m against Ubuntu on the desktop (and I have been for years), I think Ubuntu Touch has the best chance of competing with Android (both technically and on the market). Note that I’m leaving iOS and Windows Phone out here though (I personally don’t want to go all-closed again).
Which browser based mobile OS’s have you tried? Other than webOS since when that was developed it was actually quite smooth and fast for that generation except compared to iOS. I’m wondering why the hate for js/html unless it is just a theoretical dislike?
Edited 2013-07-03 07:24 UTC
Ooh! Ooh! Don’t forget SailfishOS!
It runs native applications (potential to be fast), it can run Android applications (potential to have many launch day applications), it uses Qt (well known API in general), it can be developed for on Windows, Mac OS X, and Linux, and comes “no jailbreaking required”.
…yes, I’m a Maemo fanboy…
Anyway, Jolla hasn’t put a phone on sale yet, but the fact that they’ve created one, shown it to people, and released the development kit is a good sign.
And if this would get released with hardware keyboard…
As I understand The Other Half architecture, you can snap on a hardware keyboard. I have no idea how practical this is until the device and attachments ship, though.
I think its exciting as it suggests that the mobile space is still vibrant. It advances the art, getting software and devices in to the users and developers hands to see what the limits really are.
It’s safe(ish) for developers as any work they do on the JS apps will mostly port to other mobile JS platforms, as well as the web, so investment here is not necessarily wasted.
If FF OS fails, perhaps the others will learn from it and being able to advance. In the end, it will only make Firefox leaner and faster since now they have to focus on limited devices, and make it work. So, that’s even a win for desktop users.
For many apps, JS is “fast enough”, it’s ubiquity is it’s real power, and since necessity is the mother of invention, the more JS work devs need to do, the more tools will be created (by Mozilla, by others) to support them.
But you need to release this stuff and get it into the wild, start getting real world feedback and use cases.
It’s all good.
I think Firefox/Mozilla is doing well in the areas of performance right now:
http://www.tomshardware.com/reviews/chrome-27-firefox-21-opera-next…
http://arstechnica.com/information-technology/2013/05/native-level-…
The Firefox developers are busy getting all the APIs they created on the table at W3C:
https://wiki.mozilla.org/WebAPI#APIs
Some have already been adopted and implemented by others.
Right. On mobile devices (and Firefox OS is a mobile phone OS) being 20% slower is still needlessly terrible.
And asm.js isn’t portable in that it actively hurts performance on non asm.js browsers according to your link.
So now you’re taking a 20% hit and losing the benefit of ubiquity. Talk about making a bad situation worse.
They are targeting the low-end market, people that currently have a feature phone, because they can’t afford a smartphone. Android needs more resources just to be able to run on these low-end devices, FirefoxOS needs less resources.
You need to look at the remember that the Asm.js project is only a few months old and only has a few people working on it.
Asm.js is trying to show the way to introduce new languages and existing native code for the web.
It is trying to be a better solution than the initiatives by Google to introduce their own variant of ActiveX.
You think introducing NaCL or PNaCL from Google is a better idea than asm.js ?
Asm.js does work on any browser. Do you really think the other browser vendors will adopt NaCL or PNaCL or Dart ? Asm.js can be made to work with other languages people are already using to translate to Javascript like Typescript and CoffeeScript. To give developers more choice not less choice.
Right, and the videos I saw on The Verge of Firefox OS devices showed the same stutter experience that is the hallmark of Android low end phones. What exactly is different? I understand Mozilla is saying it needs less resources, but honestly, what’s the experience like?
If a 256MB Firefox OS phone runs just as terribly as a 512MB Android phone then there is no difference. Run better with less, or run better with the same. Don’t run the same with less, because then you’re only saving money. You’re still frustrating users.
And that’s fine and dandy. Even commendable. However a 3 month old project isn’t exactly changing the landscape yet.
What I see here are clumsy implementations. The web has long since needed a new standard bearer language. Google is on the money with Dart. There needs to be a powerful VM with knowledge of types and the optimizations that they bring in order to get great performance out of the hardware.
The interim solution has been PNaCL since most of the scenarios today are for game engines and such, to which this friction is minimal. Similarly, a lot of the asm.js demos are best suited for gaming (given the synergy between webGL and NaCL)
JavaScript itself, the language, has deficiencies that make it not such a good candidate for optimization. Trying to paper over that with asm.js isn’t a long term fix, its a short term hack with questionable ramifications.
I think they’re fundamentally the same thing. asm.js is a less mature idea than PNaCL. As soon as you start wanting to do more complex things, the illusion of asm.js fades away.
Right, but this comes at an obvious performance cost. Firefox being faster while others are slower kind of spits in the face of ubiquity. When there’s a performance wall between the feature in browser X vs browser Y, they might as well not be source compatible.
re: NaCL in other browsers
Well PPAPI originally had Mozilla’s support, so I’m not sure what happened there. I think there are mutual interests in a solution to JS performance on the web.
If Mozilla won’t play game, find another partner. Go to the W3C. Talk to Microsoft. Form a coalition. I don’t know which one will win in the end, but what I do know is that asm.js in its current form isn’t it.
This is a myth, easy to debunk by quoting this:
https://mail.mozilla.org/pipermail/plugin-futures/2010-April/000088….
Edited 2013-07-03 03:01 UTC
Did you miss the part where he said they were his own views?
I can tell you from history it’s any solution that built on what is already there. Which is Javascript, which is asm.js
I think this is premature given that asm.js by your own admission is a few months old. It might be the next big thing…or it might fizzle out and die.
The important take away is that it is pretty much in the same league as NaCL with regards to how much of a hack it is. This isn’t a long term solution, and I hope you can acknowledge that.
Furthermore, using this as an example of how JS is getting faster (along with JS benchmarks which are relative to each other and not native code, ergo irrelevant) does not a coherent argument make.
The benefits of JS, and the reason some of the performance hit is justified is because it is an on the fly language which means that for anything but the hottest traces compilation is costly and time consuming.
Having apps which are known at install time, especially ones transpiled with optional typing can yield significant performance benefits if there is proper compiler support for it. You wouldn’t believe how much faster you can be when you move beyond the least common denominator number type.
So there is a way forward in performance, certainly one more coherent than asm.js, but it isn’t being actively used.
It means that due to the rate of technological progress that the Firefox phone will have that 512mb of ram at or lower then the price point of the 512mb android phone that is using a long EOL’d version of Android that will never receive updates of any kind and will also be incompatible with most newer software even if the hardware can handle it.
I wouldn’t be surprised if Mozilla aren’t more strict about allowing phones to keep their OS up to date then everyone else.
Not entirely sure I follow this logic, but the end result is probably the same one I stated above. It saves Mozilla money, but customers are not spared the headache when their phone still runs like garbage.
JavaScript developers don’t want to write Dart, we want to write JavaScript thanks.
Which is why it is great that Dart is more than the language. More competent frameworks manage to provide powerful and fast static typing while still being able to interface with dynamic languages.
The DLR/CLR combination is an example of this, and how a unified byte code can enable more choice on the web.
I think inversely a crucial bottleneck for a lot of developers is the fact that JavaScript is a pain to work with. Prototype based OO is different, but not necessarily better from my POV.
It is a tragedy that we put up with what we put up with on the web in the name of ubiquity. Its mediocrity in my opinion. We’re better than this, and there’s no reason why a better solution can’t be engineered.
Every pioneer has had to break compatibility at one point or another, if the web needs a disruption then the standard committees have work to do.
JavaScript isn’t a pain to work with, what most devs do is try to program JavaScript like Java/C# because it kinda looks a bit like it.
Once you appreciate the language and program it the right way, it isn’t problematic.
I don’t think you get it, nobody wants to write in Dart. Dart is Google’s second attempt at making GWT, nobody wanted it the first time around.
Once you know what you are doing in JavaScript it actually kinda nice to code in. Why do you think Node.js has got so popular?
Oh come on, the lack of basic compile time semantic analysis is a huge draw back. Hard to debug typos can trip someone up in JavaScript. Did you mean to reference a property or create an entirely new one? Its ambiguous.
When dealing with complex application scale projects (Like Mozilla wants to enable) you quickly run up against a productivity wall.
I held this view for a while. I figured I was too ignorant of the benefits so it only made the drawbacks seem more pronounced. After using it in practice, watching PluralSight courses on the subject matter, and acquainting myself with the paradigm I can’t say I’m convinced.
Its novel, its different, maybe even cool, but its far from perfect and in my opinion does not justify the drawbacks.
Now, that doesn’t preclude me from appreciating the fact that some people do like it which is why I’m in favor of a language agnostic web in which there is a standard byte code.
GWT was an abomination, but Dart is taking on that same problem space with a slightly different approach. While I do prefer the optional static typing in Dart, I am much more interested in a standard web bytecode format.
Node.js got popular because it scales extremely well for a particular set of circumstances, and because it lowered barriers to entry to large scale service programming.
What’s easier, understanding a .NET or Java SDK or using familiar skills? That was the draw of using JS as the basis for Node, but Node is much more than JS.
The entire eventing platform its built on top is what enables the magic, JS is just a language. Could’ve easily been anything else.
Sorry the JS community doesn’t really care about these pretend porblems that you are making up.
Look we have pretty much well defined patterns now which allow us to make a robust testable framework.
Compile Time Checks and Analysis while good don’t tell the whole story about a code base, and I have worked on some truly nightmarish C# and Java beasts.
Also if you really need this stuff most modern JS IDEs have similar tools built in and are affordable. Also there are options for LINT tools and the like.
I kinda agree with you but at the same time I have to say if you write it the right way it eliminates a huge number of problems.
But that is just my experience.
Similar arguments are made against VB.NET, while you can create some hideous code in it and tbh the language is somewhat ugly anyway … if you write it properly it just as good as anything written in C# for the most part.
I think we will have to agree to disagree.
Coming from a Java/C# background I found it harder to think like you do when coding in JavaScript. But maybe that is because of the environments I have worked in .. who knows.
I like the freedom of writing in JavaScript which quite frankly Java and C# don’t give me. I think there are quite a few that prefer coding with the shackles off to a certain extent.
Both are another braindead idea to bend the browser into something it is not.
They offer zero benefit over native applications.
They offer more speed over what is currently possible with Javascript.
That is clearly what it is for.
That is the problem.
The browser is not an operating system, I already have one where it is running on top of.
All my years of consulting with web projects just make me shake my head every time I see spaghetti hacks of HTML/JavaScript/CSS trying to bend browsers into something native applications enjoy since the mid 90’s.
With IE6 and IE7 market share dropping and Webkit popularity on mobile, there are a whole lot of stuff that don’t need hacks anymore.
There are always differences between platforms, but usually isn’t differences like small screen vs. large screen and mouse/keyboard vs. touchscreen.
Those are not hacks, that is because you are running on multiple platforms.
Edited 2013-07-03 06:33 UTC
Is that the new way to speak about Webkit versions?
No, I meant websites/webapps can run on any device and developers have to make their application work so it functions correctly in all these environments from desktop/laptop, tablet and phone, maybe even TV.
This is the problem. The countless hours spent working around CSS/HTML/JavaScript bugs across multiple operating systems and browsers.
Bug fixing across browsers using the same rendering engine.
Bug fixing across versions of the same browser.
All that work to still present a sub-optimal user experience when compared with what native applications can offer.
When you are repeating your point and not understanding my point, it is better to stop the discussion.
Most of what we do on pc’s run through compatibility layers. No reason why HTML5 cannot eventually be optimized the hell out off in the same vain as C++ vs. Assembly
They already proofed it with native like in-browser gaming. Not streamed.
Lately I’ve been feeling attacked by the likes of Apple, Microsoft, and Google: Apple with their closed ecosystem that can only be fully-utilized if you own nothing but the latest Apple products, Microsoft with their model of extensive multimedia advertising within products you already paid for, and Google with their increasing non-standard service lock-in.
Mozilla’s the nonprofit actively creating new industry standards and products to help promote those standards. Firefox OS is an example of that: it’s their way of trying to standardize new web technologies that bring the Web closer to feature-parity with native applications.
I don’t really know or care whether or not Firefox OS will gain any market penetration, but what it represents is intriguing: the advancement of the hardware, operating-system agnostic platform we call the Web.
I agree that Web software development sucks compared to native applications, but it’s getting better. And while performance is lower, the long-term possibilities are more-exciting in my opinion.