There is something magical about Firefox OS
rawkes.com
rawkes.com
This kind of happened before: http://en.wikipedia.org/wiki/HP_webOS
What went wrong? Well, apparently[1] there were some big performance issues—and IIUC Gecko has some of those already.
[1]: http://www.slashgear.com/hp-ipad-2-webos-testing-double-touc...
Then we asked about that device. It was a crappy ZTE with 600 MHz CPU and with the poorest Qualcomm chipset. This blew out my mind: a non-optimised system was running with acceptable performance on the lowest of smartphones. I can't imagine how will this perform when it's fully optimised on a high-end smartphone. They're doing a great work.
Edit: Didn't read carefully. You already mentioned that developer versions would be available worldwide soon. Any mailing list to subscribe for the announcement?
Like all Mozilla projects, this is developed completely in the open. You can get an original Galaxy Nexus and flash it over to the latest nightly relatively easily. It probably works on other phones, but the nexus is what they gave out at JSConf so that's what I use. ;)
https://developer.mozilla.org/en-US/docs/Mozilla/Boot_to_Gec...
Surprised that even the tech community doesn't understand the significance of this.
Yeah, and I find the complete and utter lack of any mention of WebOS in TFA troubling.
> What went wrong? Well, apparently[1] there were some big performance issues
Your link points to insufficient hardware though, not software issues. Hardware which seems to have been the main recurring problem on all WebOS machines (according to reports, there were also issues with the software being shipped far too early for v1.0, against the wishes of the engineers working on it)
And the fact that after installing Android 4.0.4 on it, it feels like whole new machine (speed-wise) - I really blame webOS here.
The rest of the article is really exciting, and I really hope you can launch and get some traction. I agree that Mozilla is important in this space for exactly the same reasons Firefox was important when it launched. I just think it would be kind to tip your hat to WebOS along the way.
I am not trying to criticize them but there are inherit differences between the two projects. I am thinking Mozilla is also partly betting its reputation of protecting user information while being developer friendly.
The free market will decide of course but at least initially that free market won't be North America.
https://developer.mozilla.org/en-US/docs/Mozilla/Boot_to_Gec...
@gcb.
Just curious gcb, you know you are hell banned but keep on posting - why is that? Have you tried appealing?
Of course I can only see you because I keep "show dead" on.
FxOS is all web pages (even the IME!) though currently has the same basic PalmOS launcher model that iOS and Android have; no multitasking window manager.
Enyo2 was released recently and is being incorporated into Open WebOS: http://enyojs.com/
How anyone can stand to use javascript for anything significant is beyond me, but Enyo, and hopefully whatever FxOS uses, can have substantial parts of an app's logic written in something like Coffeescript or Clojurescript.
One of our engineers answered this recently on Quora, I hope it helps explain the differences a bit: http://www.quora.com/How-does-Mozillas-Boot-2-Gecko-compare-...
* WebOS added custom API's to handle parts of the phone hardware that are not web standard, for eg. phone calls, SMS
* The Firefox project also added custom API's, except they are submitting them for standardization as web interfaces
Why not just implement the WebOS API's and thus make them a standard, or are they considered flawed in some way that the B2G project now solves?
This option would have had the added bonus of immediate interop with WebOS applications, developer learning curve, documentation, etc.
I'm sure that Firefox OS used the WebOS API's as inspiration though.
This would have been great if webOS was in a form ready to be adopted by Mozilla or someone else.
As it stands, open webOS has still yet to ship (hopefully soon). Most likely because it has taken this much time to untangle the non-open bits.
Even though I understand the reasons why, I'm still extremely bummed that this effort does not cover the Pre3 (or phone based device). Which means people will not be able to go back and retroactively fix a lot of the unfinished bits on the phones.
For example, they moved from a Java based solution to JS using v8 from webOS 1.x to 2.x.
Hopefully, Firefox OS will not suffer from the same issues. And I would certainly like to hear more about the under-the-hood architecture. It's pretty eye candy but things like power management quickly jump to the forefront when you actually try to use the device as a phone on a regular basis.
As far as the webOS performance issues go, it was less the hardware and more the fact that most of the software were not optimized and shipped with an ENORMOUS amount logging turned on. Put simply, Palm essentially did a "make debug_build" and shipped it.
Not trying to be harsh, just what I have observed from poking around webOS.
Wow, you may want to do some basic checking on your assertions there:
* webOS never used Java, Luna (webOS-to-be) was a skunkworks alternative to the Java-based Prima project. there was java stuff below from Prima, it was not the application core and was never made available to developers
* webOS always used both Webkit and V8 for its application runtime (Palm was the first company to ship a mobile V8 port)
http://blogs.gurulabs.com/dax/2009/06/palm-pre-webos.html
http://www.theverge.com/2012/6/5/3062611/palm-webos-hp-insid...
I was having a brain fart moment last night and meant node when I mentioned v8. Specifically, webOS 2.x+ shipped with node based services which replaced a lot(all/most?) of the java based services.
Those two things IMO were major things affecting webOS. Pretty much all the phone devices shipped with insufficient memory.
And given that Fx OS is JS, HTML etc. based, those things have a tendency to chew up a fair bit of mem. Throw in a JIT and suddenly you are in a mem swap situation (which is definitely not batt friendly).
So, yeah I would like to see more docs about how those are going to be addressed.
edit: oh and as to the failing of the author to acknowledge WebOS speaks to the author's knowledge or honesty, take your pick.
If there's a subset of the world for whom an iPhone or a high end Android smartphone is just a pipe dream, then the pipe-dream devices won't be much of a distraction.
[edit] If someone offers you n options, always pick option n + 1.
Isn't that a bit like saying "OS X is based on BSD so it will only be of interest to hackers"?
Execution is important - just because somebody screwed up an idea before doesn't mean that nobody else can make it work.
WebOS was straight webkit with additional APIs for telephony and hardware access, and a bundled framework to help with laying out.
Said framework having been extracted for regular in-browser JS[0]
> Firefox OS runs on pure HTML5 standards.
Firefox OS runs straight Gecko with additional APIs for telephony and hardware access, without a framework to help getting started.
It's the exact bloody fucking same thing.
--
Edits: changed "ALL existing web applications" to "ALL modern web applications," which better reflects what I intended to say; added a bit of context in response to robhawkes's comment below.
For example, this is JavaScript: https://developer.mozilla.org/en-US/demos/detail/bananabread
The expected difference between C and JS should be more like one order of magnitude in the worst cases (and much better in the best).
While JIT is getting better over time, you are soon going to hit the law of diminishing returns - the JIT is already extremely sophisticated, but still being a few times slower on average even than JVM. And JVM has it much easier, because it has full explicit type information, while JS has to first figure it out. So I wouldn't expect miracles here.
For example, BananaBread compiles 120,000 lines of code of a C++ 3D game engine, including AI and physics and so forth. It also uses 3 cores during startup processing
The difference between JavaScript and C++ is less than one order of magnitude, and note that this is a hard case to optimize for JS engines since LLVM inlining creates huge functions that JS engines just give up on optimizing currently. So that the game ends up still running as fast as it does in JS is a nice surprise.
There are also lots of other compiled examples of real-world code, like Box2D and Bullet. Typically the speed of JS compared to C is 5X-10X slower, again, much of it because of large functions not being fully optimized.
It is also possible that circuitlab is not well-optimized JavaScript.
I will say that it also depends on the problem domain. You can make a fast 3D game in JavaScript because WebGL does hardware acceleration of the graphics. You can also make a fast todo list in JavaScript because, well, it's a todo list :)
But the original point is basically right - one day JITs will be faster.
Seems like a completely accurate definition. As responsive as expected, similar looking and integrated as expected, and able to access the unique parts of my phone.
What is missing, other than having a different build/compile process?
It's not quite up to iOS or Android 4.1 performance, but it's running on far less powerful hardware. It definitely feels better than the initial releases of Android in terms of responsiveness.
> Give me an example of one app out there that's in the same ballpark of quality as the stuff you can find on iOS or even Android.
The HTML5 version of Cut the Rope works pretty great on Firefox OS; the experience is effectively identical to Android and iOS.
Technology evolves and in time hardware improves to a point where the performance difference between native code and something that runs through an intermediate layer is not noticeable in a user interface (although there will always be a difference, it just wont be be relevant any more).
The mobile web rendering performance might never hit the 0-grade latency standard where we put native, but it will eventually get so close to it as to not make any difference whatsoever to anyone but cold-hearted scientists the likes of whom whish they could keep their science drinks at absolute zero chilly bins.
If your argument is more in the line of why do games keep getting bigger and meaner, needing more resources, when we could have stopped advancing 3D a decade ago and every computer would be able to play any game today; then that's a whole other discussion. But I like the path towards true virtual reality with photorealistic graphics.
Here are some other high quality HTML5 games:
http://worldsbiggestpacman.com/ http://www.wordsquared.com/ http://www.pirateslovedaisies.com/ http://browserquest.mozilla.org/
Smartphones these days live and die by their app ecosystem. I would love to be working on mobile apps, but for the expense of buying an iPhone, an Android phone and a Windows phone, plus licenses for software to develop for all three. Not to mention the daunting prospect of dealing with Objective C, Java and C# simultaneously. This is a ludicrous prospect for a lone developer.
Give me a platform that costs nothing to develop for and lets me use my existing skills. If there's a website version of my application, let me share components between the two versions instead of locking my mobile version up in your platform's chosen systems programming language and development environment. Firefox OS ticks all these boxes.
I just might be the most average developer out there these days: a web developer. If you enable people like me to develop applications for your device without any bullshit, then you automatically have a bigger set of possible contributors than the competition.
That is why I am cautiously optimistic about Firefox OS. If you build it, we will come.
Perhaps that's true for a hobbyist. But any professional software developer should already be familiar with at least one (if not all) of those languages, and should be able to pick up the others with very little work.
Once you know C#, for instance, you'll quickly see that Java is essentially a subset of it these days. Sure, there are differences, but they're quite minor. The same goes for Objective-C, to some extent. The syntax is a bit different, but most of the concepts are similar enough. Even the most commonly-used libraries for each don't actually differ that much in practice.
In fact, many developers with experience in industry will have already had to use multiple languages at the same time throughout their careers. They'll already know how to work on several projects simultaneously, using several languages, and many more libraries.
In fact, I'd suspect that most of these professionals would feel very handicapped if they were forced to use JavaScript for all development. JavaScript has proven time and time again to not be a good language for anything but short scripts. Languages like C++, Java, C#, and Objective-C have core features that make large-scale, distributed software development possible. JavaScript lacks these, and anyone working on a large JavaScript code base will know the pains that arise.
It won't be good for Firefox OS if only the most inept developers are attracted to it. That's not the kind of ecosystem that produces useful applications.
Once you have built it in one framework it will be much faster porting it to the others. I know it requires 3 updates when you add a new feature but it's not a major pain and you get native apps running very fast.
I think "doing it wrong" would be _porting_ the same code to 3 platforms. A blind port to three different mobile platforms is going to look out of place on at least 2/3 of them.
Unless you're talking game development (where you pretty much invent the UI and UX from scratch), each OS has very well established human interface guidelines.
I largely agree with you, but I think GP is incorrect in assuming it's 3 parallel branches of the same code.
The three ports should all be different, in some cases _drastically_ different, or they're bad ports. The business logic may be the same, but the presentation should not.
Also you point out a very good way to separate the business logic without rewriting it three times. Though I wonder if you could write the business logic in C as well?
I know it could be used as a lowest common denominator between iOS and Android. Android does provide the NDK and JNI so you could bind to C libraries, and Objective-C (IIRC) would allow you to link C libraries as well. Not sure what the Windows Phone toolkit looks like these days, though, so I can't comment on that.
define short. Yeah, maybe javascript isn't good when building a large app with > 100K LOC that uses a bunch of existing code built in C. However, you sure as shit can built a very sophisticated product with javascript. Learn how to use prototypes and you have OO (or avoid that if you don't like it). Use modules (many ways to do this). geez.
Maybe this just struck a cord with me because I am in the middle of a huge project that uses a metric shit-ton of configure scripts that seem screwed up six ways to sunday. I feel handicaped by all the BS that you have to do to get stuff working C++/java that is so trivial elsewhere.
I don't think that JS would do much worse than "naive C" in such a situation. To do well on these sorts of problems, you need to pull in a library that properly uses the CPU's vector unit or the GPU, no matter whether you're using C or JS.
Well, do you really need to develop on all three?
Among the reasons I got into Android development was because the upfront cost was $0. I just needed any laptop or desktop made in the past ~5 years, which I think all of us have already.
After several weeks -- when I decided I didn't hate it completely, and I got tired of using the emulator -- I got an old phone off of eBay, and I actually spent less on that than I did on a book from O'Reilly.
It's very easy to start programming for Android.
I'm dubious unless they've made serious improvements to the emulator since I last used it. (I haven't updated my SDK in probably 3-6 months.)
I ran it on a fairly beefy laptop (although ~1.5-2 years at the time) and it was not an environment I'd consider "fun" to program in.
They have ways to image the emulator for faster load-times, but that's not that much of an improvement, and it only affects the emulator boot-up time, not the application speed.
I should try it again on my new desktop, complete with SSD and gobs of RAM.
But honestly I would not develop for Android [relying solely on the emulator] on a machine much older than a year or two.
I guess your mileage varied, but my experience developing for Android [w/o physical hardware] on fairly recent hardware was not pleasant. Had it been a hobby, and not my career, I would've been entirely put off with the experience. I probably wouldn't have gotten a phone, and I would've moved on to developing for another platform.
Possibly WebOS, I remember it caught my eye back when the Pre launched; and I think it had the whole $0-up-front aspect in its favor.
Still, I got a decent-enough Android phone off of eBay for less than $30. Now I only pull up the emulator as the last part of testing before sending the app off to Amazon.
Who does this? The vast majority of mobile developers I know specialize on one platform. A small handful are competent on two. Most companies that care enough to be on more than one platform will hire out to specialists for that platform.
And you can always just embed a webview and use html + js if you really want, though that is much harder to work with and less versatile imo.
That is the reason I am not cheering for firefox OS. Why on earth would I want to be limited by html and javascript. Show me a high end game that is written in html 5, or really even a mid tier one. This does not include webgl.
You say "doesn't include WebGL", but WebGL is just the visual output… a game like BananaBread requires epic performance from JavaScript aside from WebGL: https://developer.mozilla.org/en-US/demos/detail/bananabread
WebGL is one of the main reasons why we can do so much more with JavaScript games so it's silly to cast it aside. Canvas is more than capable for most things, but WebGL is the future of the high-end that you're talking about.
I meant NaCl and other kinds of techs that are really just a bridge that lets code written in C++ or with XNA or Unity run in a browser.
Also that link doesn't work.
I mean, it just doesn't really seem like html 5 is a serious option yet for game development. I'm not saying you can't make a casual kind of game in it. I'm just not sure why you would vs flash for a simple game, or the many much more powerful options which let you deploy to a wider audience(like Unity, Unreal, XNA, even Source).
The only reason I can think of is because it is in javascript, but no one should pick an engine based on the programming language it is written in.
Have you got a source on this? I am just curious. I love my smartphone, but I basically use whatsapp and the internetm, mp3, video, and fbreader 99.5% of the time.
b) It's often not enough to just have an app for a specific task, it needs to also tie into a specific ecosystem. For example I don't need generic VoIP software on my phone, but I absolutely must have access to Skype. For somebody else it might be WebEX instead.
c) Even when there's no ecosystem lock-in like that, there are very difficult categories of apps for new platforms to get access to. Maps would be a prime example. It's absolutely core to the smartphone experience, and perhaps the second most important function of the device.
The existing mobile web experience for maps is rubbish compared to the native apps even for basic things. But it'll get worse once you get into things like off-line use or turn by turn navigation. So who is going to fix that? Unlikely to be Nokia or Google unless Firefox OS becomes wildly successful. Nobody else really has cost-effective access to good data.
Of course there's never going to be a totally authoritative source for this kind of thing. You're not going to be able to do a double blind trial of the market success of two smartphone platforms with everything being equal except the app availability.
I'm trying not to be argumentative, but you're tempting me :).
a) The list of the apps you use basically exclusively is completely missing most of the most used categories of apps. No games (used by 67% of smartphone users), weather (65%), social networking (60%), maps (55%), and news (42%). You do have music (45%) there, so that's fine. These numbers are from Nielsen Social Media Report Q3 2011 (I have no reason to trust these number particularly, it's just the first non-anecdotal data I found with a search).
Both the lack of overlap with your list, and the the low usage numbers for even the most popular categories of apps (let alone specific apps), should make it completely obvious that people's usage scenarios are completely different.
b) If you seriously dispute the presence of ecosystem lock-in that means apps in the same category are not fungible, there's no point in having a discussion. Even your own list has WhatsApp that can't be substituted to by any other instant messaging app. Its utility depends purely on your contacts using the app too. Something like iMessage, or BBM, or Google Voice might be in a similar category of usage, but they can't replace WhatsApp for you.
Another example you had was an ebook reader. Again, for a lot of people a generic ebook reader is of little use, since they're already tied into the Kindle ecosystem. While presumably for you the Kindle app is of no use as well.
The prime example of this is InstaGram. Yes, anyone could build a camera app with a fake polaroid filter. But 50 million people wouldn't install it. All of the value of the app was in the ecosystem.
And the list here is seemingly endless.
The harsh reality is that these apps are not getting ported over to every single platform. Can FxOS become an important enough platform that it warrants porting to? Maybe. But it almost certainly needs to become an important platform first. And becoming a major platform without having the apps is tough. Hell, even getting a good review for a device without the apps is going to be tough. See e.g. reviews for the Nokia N9, Lumia 900 (and we're talking WP7 here!), any Android tablet.
c) Let me turn this around. Where do you think a good mapping solution for FxOS is going to come from?
There is a reason MBAs are taught market analysis. Its important to position your product for maximum effect (usually maximum profit, but that may not be the case here)
The arguments for FirefoxOS seem to be
1. It's OSS 2. It's Web-technologies only 3. It's aimed at the "emerging" markets' mobile users 4. It runs on cheaper hardware better than the competition
1 and 2 are great. And no-one but us cares, except in 20 years when no child has even seen a line of code because OSS gets wiped out as all PCs are replaced by mobile devices.
(This is the reason I want this to succeed, and I want laptops to be certified FreeBSD compliant. It matters!)
Anyway this is about market positioning, not OSS. So.
Its a well-known truism that don't be in the middle of any market - you get squeezed from both ends.
The emerging markets have adapted enormously well to only having SMS and no smartphones (see anyone in Mumbai). That is not going to go away, so the true bottom end of the market is SMS capable devices. They will probably just give them away.
If Firefox OS says we are not as good as iOS then thay are squarely putting themselves in the middle of the market.
Aim higher folks. The world is not segmented into feature phones and smartphones. It is segmented into one market "I want to use a networked mobile app to get laid or get cash." You will never be the bottom end - that belongs to sending cash by SMS, or selling your harvest with a text.
So its the top of the market - what the cool kids have.
And so, 1 & 2 might just be our saviours. Apple made a great new product that was catnip to the coolest kids in the West. Firefox OS is geeky cool - it might just appeal to the coolest kids not in the West. And they will want to buy the 'best' phone - aim high folks.
I hope you succeed.
While these guys are off saving the world from the evils of proprietary software, is it ok if I just get on with teaching my kids to program using Codea on our iPad?
Edit: Ok, I too wish Apple devices in particular were a little less locked down, but hysterical prognostications about the end of hacker culture don't do the cause any favours.
If it weren't for these guys we'd be much worse off than we are today. Firefox single handedly dethrowned IE.
It's philosophical but in the same way that IE was at one time the best browser and quickly became the worst - it's not unimaginable that iOS will do the same.
I'm a pragmatist myself but if it weren't for folks like RMS and Mozilla there would be no voice at all for FLOSS. I don't agree with RMS on many things but it's vital that someone as unwavering as him pushes back.
Anyway, my first home computer was a Sinclair zx80 that booted into a minimal shell and needed you to read the manual before anything worked.
So to use a pc I was forced to program. And RTFM.
But that was ok because there was a whole popular culture surrounding learning to use these new devices - I learnt basic and z80 assembler from magazines I bought in my small town newsagents, and watched prime time tv shows on using the BBC micro (way too expensive for us).
In short the devices were unlocked, the culture was encouraging and the prevailing expection was the devices were to be used for programming and put no blocks in the way (other than it was a z80 with plastic keyboard)
I cannot say for sure I would have found my way here otherwise, but it seems unlikely. So based on my one personal data point, I can say that a future where it is harder to program your devices to do what you want than it was for a kid in the 80's, is then likely to be a future that produces less programmers than my past.
if that is FUD then I must accept that. I am trying to start a after hours coding club at my local school, my nephew gets put onto Mac's term everytime I go round. But a country where most of our children are discouraged from learning to program will be a future that our country is at a competitive dis-advantage. That does sound like FUD I admit. But it also sounds like logically inevitable FUD.
Edit for clarity.
To be clear, I'm not educated in business so my thoughts are my own (potentially naive) conclusions.
However, there are some very sound business decisions behind us chosing to go with Brazil first, and to go with cheaper, low-end devices. I'm sure they know what they're doing more than I do!
As an aside, we do have versions of Fx OS running on high-end devices and it runs amazingly well. It's not our market though (for now) so it's merely a cool "look what we could do with the power" moment.
I hope we succeed too.
Get it running brilliantly on cheap hardware. Don't waste anything. Make the OS efficient. Do things in the most direct way possible with a minimum of red tape. Expose the bare metal to Javascript. Put the bare minimum features in the OS and let open source grow around that.
My phone runs Linux, and it has 512MB RAM and a 1GHz ARM processor.
Marketing isn't that complex. Unfortunately business people do tend to hide behind a facade of secrecy (often for good reasons -- you don't want to reveal your hand to your competitors because someone in your org leaks inside information). But that can also be used to hide poor / complete lack of analysis and bad decision making.
Fantastic work - and if you dont mind answering dumb questions, what device would you recommend getting if I fancy playing (B2G_build_prerequisites has a list of a few - but I have no idea how to be sure I get specifc models, or if I can buy an Otoro in UK. Basically, really horrible starting questions :-)
Happy to be told just google harder
Cheers
I'm not sure. Gecko is faster and lighter than Dalvik now? Since when?
That's only if people actually perceive feature phones as the same "market" as smartphones. I very much doubt this is true. 2nd hand smartphones are already widespread in 3rd world markets. Having a "real smartphone" will have considerable cachet, functionality notwithstanding.
tl;dr - "mobile phone" isn't a market. "Mobile phone" is one market and "smartphone" is another people aspire to.
Sure, if functionality were everything, Palm would still be ruling the world with Treo phones. Functionality is not everything. People are status and style conscious, even in the 3rd world.
Sell it to them as an alternative to Android. That's all they need to know if they want it or not. If they want more, you can go elsewhere.
We need carriers to be dumb pipes we buy data plans from; then this entire class of problem goes away. Until then, any platform that doesn't let carriers charge us different amounts for bits from different places is going to die on the vine.
Ideally, they shouldn't "use" any phone, because they are not the user. We should buy whatever phone we please somewhere else, with financing if necessary, and then buy service from the carriers. The whole "subsidizing" thing is a scam unless you get cheaper service by bringing your own phone, or after your phone is paid off.
Getting some popular third-party phone vendors in the US and making phone subsidies a line item in your cell phone bill are the first steps toward carriers as dumb pipes and towards true choice in phones.
I agree with what you're saying, but how do we get to a state where we can have "dumb pipes", yet have an open, privacy driven and easily user controllable OS on a device?
Is there an alternative to always needing to "add value"? Isn't earning our coin off carrier charges, data etc enough?
This is new to us, but I'm confident we'll come up with something satisfactory.
Saying that, we can't stop someone taking the code from GitHub and producing their own non-Fx OS system and not referring to Fx OS.
If Firefox OS is to be open source (OSS-compliant), then you can't impose this sort of restriction.
And per the article, one of the benefits of the OS is the ability to modify the GUI and default apps with simple HTML+CSS+JavaScript.
Deleted comment
Let's look at few possible reasons:
1. JavaScript/HTML/CSS are better tools for developing software than anything else out there. No.
2. It's open source. So is WebOS, Android.
3. It's more efficient - same software can run on cheaper hardware. No, Java & Objective C are more processor-efficient. If Firefox OS runs on $100 hardware, than iOS can run on $50. The fact that nobody is making an ulta-cheap smartphone is because there's little demand for one (it's like making a shitty Porsche)
4. Developers can package existing web applications as native mobile applications. There's already a thing called PhoneGap for that.
5. More teenagers know JavaScript than any other language
It seems like #5 is the only valid reason. A lot of kids don't know Objective C or Java, so they must love Firefox OS if they just know the web stack. But sometimes you've got to ask yourself - why rewrite an OS in a new cool language? Just because you can? Look how far Apple has come with Obj-C, why constantly replace the hammer? Having said that, the force of teenagers is not to be underestimated.
It's literally just a web browser running directly on a smartphone. Any web apps that you're using right now will Just Work on Fx OS. No rewrites required.
One last point: it seems intuitive that Java would be more processor-efficient than Javascript, but SpiderMonkey is waaaaay more mature than Dalvik (Android's Java VM). I'd like to see some hard performance numbers before making that call.
Your whole post smacks of elitism. What's with the "More teenagers know JavaScript than any other language" and "A lot of kids don't know Objective C or Java" comments? Are you just trolling, or trying to be insulting?
I would therefore like to raise the question “how will Firefox OS encourage a consistent and usable experience across applications?” Gnome[1], iOS[2] and Windows have comprehensive human interface guidelines and the systems tend to be user-friendly as a result.
The latest WHATWG HTML standards do make an attempt to improve user interface consistency by adding new, specific tags. While this will help to some extent, I do not think it will solve the underlying problem. Web developers are accustomed to creating whatever interfaces they like with little regard to usability considerations including consistency with other websites. Different colours, typography, borders, page structures, navigation styles, etc between websites and applications produces a difficult user experience.
[1] http://developer.gnome.org/hig-book/3.5/
[2] https://developer.apple.com/library/ios/#documentation/usere...
https://wiki.mozilla.org/MozCampEU2012/Design-Principles-beh...
As is the case with other mobile platforms I noticed a wide array of button styles. Small symbolic buttons in applications such as the photo gallery and messages screen, large glossy buttons for the radio and calculator, blue rectangular buttons for the time and date selection screen and a long red button for cancelling a call. Some applications are dark and 2D, others are light, colourful and 3D.
I do like a lot of the work shown off in the presentation but still get the feeling that applications/screens on the phone are not tightly integrated or connected. This isn't criticism of Firefox OS. Rather it is an observation that I have for all mobile platforms I have used.
I will look out for the detailed write-up to get the details of what is planned.
"aiming at middle market"
"performs well on low end hardware"
Instead this has the potential to be "the best" phone in most emerging markets - the most desireable OS, because it can appeal to the very same people who iPhone appealed to - the cool and influential geeks and designers.
Shout from the rooftops guys, its high-end, high-value, cool. Let the network providers sort out how to put 50 USD worth of hardware into the hands of boys and girls in the favelas. Just make sure everyone wants one.
And that means not apologetically aiming for the middle market.
Aim higher.
* http://en.wikipedia.org/wiki/List_of_minimum_wages_by_countr...
edit: this was an edit on my other post here, but it is so different in tone it just was better reposting.
That's not true.
First of all, low-end refers to the range of the product. A 50-USD cell phone is low-end because there aren't many models that cost less than that (modulo subsidies etc) just like a U$15k new car is low-end, notwithstanding the fact that relatively few people can afford one in Brazil.
Besides, the bulk of households in Brazil earn more than the minimum wage. C class in the graph below corresponds to people in households earning around 2~4x minimum wage. While in developed countries these people would be definitely considered "poor", in Brazil they're basically "lower-middle class". And yes, many of them can afford low-end cell phones.
http://www.asiacomentada.com.br/2011/03/melhoria-da-distribu...
(i live in s america and would love the kind of thing being described. but i am pretty odd and currently use a dumbphone that cost $20 - i know plenty of people with fancy phones here.
so i would like what you suggest to work, but in practice i think people would perceive it as aimed at "second class citizens" - kind of condescending, in a way. you have to remember that even though people have less money on average (and higher prices for imported goods) they swim in a similar media context - can access the same internet sites, see the same aspirational movies, etc)
So, yes we do all live in the same global media village, but things will change. It will be harder to knock Apple off top spot in the US or UK because of the installed base. But the battle for hearts and minds is at the top of the market - if you dont compare yourself to apple, no one else will.
With all its sensors and social and personal applications, there seems to be a high potential for individual customizations and connections, probably more than what your average PC-of-yore office suite would warrant. Yet there's nothing like VBScript or (A)Rexx on mobile devices. (Some of you might remember Apple's NewtonScript, from their superior mobile device they're still trying to ignore)
Part of that is that it's all in the hand of the people financially benefitting from it, i.e. us developers. You could easily make a new site/app that connects social platform A and social platform B. Which is part of why we've got that huge mess of redundant, barely interoperable cloud ad sellers and allowance pinchers.
What if teens could trade JavaScripts to do the same? Script their calculator app to better fit their teacher's views and their curriculum? Connect their text messaging app with the hip new microblogging platform. Set up little JS "cron jobs" whenever they enter a certain WLAN range (or GPS quadrant)…
Apart from security issues there's little technological reason to prevent this. But it seems all over the place we've moved away from interoperation. From what I see, end-user scripting is pretty low. Nobody's talking about document-centric desktops anymore (ah, OS/2, how I miss thee). It's all about apps and services, maximum hype, maximum profit.
http://code.google.com/p/android-scripting/
It does not seem to be explosively popular. But it has to be sought out and installed and all that stuff, so who knows.
Or just a standard class interface, if you're scripting in the main application development language, which is why this would be an easy fit for a JavaScript-based system.
What I can't see is how this would "going to change everything" from an user perspective. I only can see this as increasing the amount of apps in stores very quickly. But stores already feel very dense with numbers like 500k apps.
Can anyone tell me what I am missing? because I can't see this changing everything.
Scary thought ;)
For this reason I kinda want Dart to succeed. Why not make the browser truly polyglot if we are trying replace OS with browsers?
Because of that it's also a pretty awful assembly target, something which is only now being addressed with things like invokedynamic, finally moving Java byte code beyond Java 'the language.'
'1' - 0 is 1. Guess what '1' + 0 is? Nope, it's '10'.
Crockford's JavaScript truth table is mind-bending. On top of that, semicolon insertion.
I find the weird scoping rules around 'this' and the verbosity of anonymous functions far worse. [1]
(Sincerely and non-rhetorically) Do you really find the former more annoying than the latter? I see a lot of people using those examples to call out JS inappropriateness for development, but it seems like they're focusing on the wrong things to me.
[1] I know they can be fixed by using a language that compiles down to JS. So can the parent's criticisms.
.
You have to be kidding me, my amiga 500 (released 1987, 7mhz) offers similar games to that (but better graphics). That puts it literally 20 years behind modern smartphones today, where the cutting edge games are in a similar position vs xbox 360 games.
.
Firefox OS clearly isn't going to appeal to anyone looking for gaming on release-- However, i do not want to shit on it, unlike many..
I think it is a great idea, could do wonders for openness as well as the advancement of web technologies, and the web as a platform. I can certainly see FFOS devices becoming a standard smartphone for 'regular folks'.. web browsing and the kind of things that web-apps could easily do; media playback, calendar and clock apps.. i'm sure this covers 80% of all smartphone apps today anyway. As time goes on and performance (and web features) continues to increase, with 3/4 smartphone platforms (plus 3/4 more 'desktop' platforms), the appeal of developing once for all platforms is going to become an overwhelming advantage.
It is very different to webOS, which suffered from limited, expensive devices, constricting user base, which failed to inspire developers. Is it the most computationally efficient way of doing most things? no. Does it offer other advantages that could offset this? absolutely.
If you start comparing these mobile HTML5 games with any device or platform that was originally build to run games well then you'll always see issues – though we are working on improving that. Games on the Web are probabably never going to be quite the same, and nor should they be.
Still, things are improving each and every day and I think that's the most important thing here. We know things aren't perfect and we also know that we're no where near the limit of performance yet.
I'm really excited to see what those advantages you mention turn into in the future. There is a lot of potential here, way beyond performance and how things compare to other devices.
And by all accounts FF itself has had some serious work done to sort close the performance gap between it and Chrome.
I love Chrome, it's a top notch browsers, only the omnibox (addressbar) seems be deliberately designed to inflict pain and suffering on the user. You could be forgiven for thinking that it's been deliberatly in some kind of bizarre social experiment. Does anybody here prefer it to the Firefox Awesomebar?
I'm seriously considering switching back to FF. God.
JavaScript shows up in new places because everyone already knows it, because it's relatively easy to write a JS app and deploy it to every single platform, because anyone who wants to learn it can probably jump into a REPL from Facebook by hitting cmd-shift-J, because there's a huge amount of code already written in it, because there's intense competitive pressure to optimize the interpreters, etc. etc. etc. The same kind of reasons that English is hard to replace. If you want to improve the situation, you can't just point out the flaws, you have to offer a smooth transition from here to a better language.
But actually, that's already happening. JS is actively, incrementally improving. (As one random snapshot: https://brendaneich.com/2011/05/my-jsconf-us-presentation/) So the answer is, no, we cannot stop putting it everywhere. That is not going to happen. But we can make it better.
I'm impressed by what Firefox OS managed to achieve using web technologies, but I posted this as a warning that users may chain themselves to some proprietary webapp even stronger than to native one. Hopefully Firefox Os will force more webapps to provide offline mode.
[1] Of course DRM tries to take away this advantage from desktop apps.
The apps are cached, auto-updated, and easy to code. They run on the phone and on the desktop alike. That's it. The only OS that really compares, is actually Chrome OS, except Chrome OS has not been ported or made to run on phone hardware.
If it's not fast enough, it will not work. If it is, it has a small chance of making a difference.
To be fair, I think there is much more too it than just HTML5 apps. Think beyond the single mobile phone device… it's more about how concepts will change if many different types of devices run apps and can communicate via the same languages (JavaScript, for example).
The other advantage is that it's free, and open for others to take and turn into whatever they want it to be. That's kinda cool.
We already have 3 good options for OS, We have the cool iOS, the ios copy, android, and the alternative from microsoft.
What we have here is a glorified Android that you can write apps in js, yay, 100 bucks it will never take off.
Perhaps JS optimization has come far enough that speed is not a problem, but how is FxOS going to handle codebase compatibility for bringing large preexisting native-code projects (eg. games) into it? Compiling the entirety of Unreal Engine 3 in Emscripten, for instance, seems a bit far-fetched.
I still think there is a use case for a static C like language (with explicit memory management) for some kernels.
The same way that WebGL has HLSL, it would be nice if there was a WebCPU API with C as the 'shader' language.
(Alternative is LLJS approach - but that has other issues).
You should try it out sometime, it's really not 'terrible' when you get hands on. But your opinion is one I see a lot and we're hoping to change it in the future, slowly ;)
webOS can be left on for days and days IF you turn all the radios off, underclock, undervolt...
Given that most smartphones last for at most a day with actual usage (not sitting there in sleep mode), I would like to see more quantification as to what the usage pattern is that enables you to leave it for days and days.
I'll make sure that we release test results as they are performed, probably on the Mozilla Hacks blog or likewise.
So basing a mobile OS on something like Java (or C#/Silverlight) would be completely silly in your opinion?
The big problem I see with Firefox OS is that it is not going to take much to make the entire "App Store" full of app's that perform horribly, and in return that will make Firefox OS look bad as a result.
Abstracting away all the complexities of making JavaScript/HTML/CSS perform well on mobile into a set of API's that anyone can use regardless of skill doesn't seem feasible to me but I could be wrong and If they have actually pulled this off, great! But it's still not magic.
Can anyone try out:
http://anirudhjoshi.github.com/fluid_table_tennis/ on the Firefox OS and tell me its performance?
I want a standalone operating system that runs on android hardware that gives me low level access, via unix commands and stdio, to phone functions.
So I don't want the javascript dialer, I want /usr/bin/dialer ... I don't want the javascript sms client, I want to run:
/usr/bin/sms --retries=4 --number 800-555-1212 > Hi Joe, I can't make it to the meeting^D ... sent.
So yeah. This article reminded me how much I want something very much like ffox OS, but for unix core principles, like stdio, and not for open web apps (nice as they are).
Why was webOS not mentioned in the article? They have a very nice linux stack, telephony, and radio interfaces as well. Not to mention it's been open sourced (both OS and framework)
That wasn't working last I checked.
https://developer.mozilla.org/en-US/docs/Apps/Getting_Starte...
It's being proposed as a standard, so hopefully Apple and Google adopt the API, but these things take time and politics.
Some strange strategic decisions coming out of Mozilla inc. these days, I would much rather see them focus on their browser instead (and Thunderbird!).
(Wait, what's that? A company/community can work on more than one thing at a time?)
But that's the whole point: they're not, at least not in the case of Thunderbird. Firefox OS clearly has a higher priority for them than Thunderbird.
I use Thunderbird and have done for many years. I would like to see them continue developing it. But Firefox OS is much, much more important. The World needs a free alternative to Android based on open standards.
> There are many similarities
Indeed. And he then goes on to admit that a new version of Enjo JS will address many of the perceived shortcomings in webOS:
> This is a simplification, and I should also note that Enyo 2 (the next version of the webOS application framework, not yet released) is designed to be less platform-specific and allow Enyo apps to run on both webOS and in standard web browsers: http://enyojs.com/
Enyo JS 2 is now available for download: http://enyojs.com/
So again, why reinvent the wheel? What's the real benefit of boot-to-Gecko versus boot-to-Webkit (webOS)?
Secondly, the existence of 2 OSes that support the same apps is not a negative; it is an overwhelming positive. Just as having multiple browsers in Windows is positive. The SysApps working group was created to standardize the (currently incompatible) APIs that exist between Firefox OS, Tizen, Chrome OS, and others. http://www.w3.org/2012/05/sysapps-wg-charter.html
Is green and at 2 o'clock simply how we think of calling someone now?
I get that green is usually associated with starting a call and red ending a call, but why? Why not blue or purple or orange or yellow or black?
Good point on the angle. But why even use the same handset icon? You could use a candlestick phone, a wall phone, a rotary phone.... for fuck's sake, you could use an icon representing the phone itself.
Slide open: given a large touch screen, what's the easiest interaction that has a low likelihood of being accidental?
panes: there are basically two possible metaphors that work well: paged or infinite scrolling. Is it copying if random chance would have a 50% chance of choosing the same answer?
swipe between panes: given a paged screen, what gesture but the same one used for turning pages in a book makes any sense at all?
4x4 grid: given a 3-4" screen and given an icon the size of a human thumb, how many icons fit?
dock: given a paged, gridded metaphor and a need to have the most commonly used functions always available, does anything make any sense but to keep a set of icons pinned and visually distinct? Sure, they could have moved them to the top or to the side or to the middle or something, but that's just change for the sake of change.
If you're an OEM, how would you target these people? As long as you can get a clean, attractive, easy-to-use OS, you'll take an interest in one that's easy for you to customise, and ship with solid default apps, some of which you can monetise on. I think Firefox OS offers that possibility to OEMs, they get to completely control the experience and keep the relationships with customers. And the customisation process - being HTML5 - is arguably simpler and less of a specialised skill.
We're also working with plenty of other partners to bring this to other areas, so there is definitely interest.
I think what appeals to them is the open, customisable nature. Also, remember that this isn't meant to compete with Android and iOS, it solves other problems beyond performance and feature-set.
See also item two in the list at http://www.readwriteweb.com/archives/how_to_spot_openwashing...
Yes, I know it is hard to support development and debugging of a hybrid of script and native code, but regarding battery life and computation intensive apps, JS is not an option. Unless this OS is for really low end phones.
Is Objective C native? Not yet. Is the ARM executable native? Yes. Is javascript native? No. Is the executable code generated by the jit native? Yes.
Just mentioning this as it's something a lot of people not doing games are missing (and maybe one of the main reasons why c/c++ still are dominant in game programming - I mean what's the point of coding in Java when the only way to get a constant FPS is to work throughout with static variables for example?). So if you want games - makes sure you have realtime guarantees.
This is exactly what my job is at the moment, testing games and monitoring FPS across these games on various devices and platforms. I'm confident that JavaScript is more than capable to have games running fast on mobile, we just need to work with the game developers more (to optimise) as well as improve the platform.
This is the real boom to the web community. The fact that Mozilla has to make these things work. I get frustrated when I do a translate3d(-100%,0,0) on Chrome for Android and it's not buttery smooth. Or I use onscroll to achieve an infinite scroll list and it causes scrolling to be laggy.
I'm sure the Chrome (and Safari) teams are aware of these issues and working on them, but to Mozilla they are absolutely essential. This will put pressure of Apple and Google to put a stronger emphasis on web app performance.
I want to buy one but i don't know what is already supported :)
The Kis is merely a test device for now.
I'm glad you didn't use any hyperbole.
it's a mobile OS powered by JavaScript!
And you thought a Java-powered operating system was crappy...
So you might be thinking, "This sounds great, but why use JavaScript to build a phone?" And you'd be right, that's a really important question to ask. The good news is that there are plenty of reasons why this is a good idea, besides making Web developers weak at the knees.
I'm pretty sure this is the only reason to do this. Nobody but web developers are going to give a shit. Grandma doesn't care what OS her iPad runs on. It just needs to work really well. I am wondering how you're going to get real-time priority on threads for the phone app over your slow HTML5 game threads if they're run by the same interpreted scripting engine.
Why the huge performance improvements over browsers in Android on identical devices? It's because of the lack of stuff going on between Gecko and the hardware, meaning things like JavaScript can run at full pelt. So much for JavaScript being slow!
What lack of stuff ? What's going on in this "JavaScript OS" that is different than in a Java OS? What calls are not happening? What memory is not being allocated? What graphics are not being displayed? What the hell are you talking about?
What Firefox OS aims to do here is to use the native everywhere-ness of the Web to provide a platform that allows applications to be enjoyed on a mobile device, a desktop computer, a tablet, or anywhere else that has access to a browser. Wouldn't you want to be able to pick up your Angry Birds game on the desktop where where you left it on your phone? I certainly would!
I think you actually missed the point of the quote right before that paragraph. It's an incredibly powerful idea to make a mobile platform that's as free-to-use as a web browser. A security nightmare, yes. A competing-open-product-that-implements-unsupported-features nightmare, yes. But it could change things, for better or worse.
Because Firefox OS is constructed using HTML, JavaScript and CSS it means you only need basic Web development skills to reach in and completely change the device experience. You could literally change one line of CSS and completely change the way the icons on the homescreen look, or re-write some core JavaScript files that handle phone-calls.
I could have sworn I heard of something like this before... Web Oh Ess or something?
Has the whole world gone nuts? What the hell was wrong with just having a web browser and native apps side by side? You could use your web apps for a universal free experience, and for apps which need a lot of performance like games you would write a fast, minimal native app. Now we're reinventing a reinvention of the wheel, poorly.
Have you people even used S60? That shit was easily skinnable, had tons of developer resources, a free marketplace (once you signed your app), it was fast, stable, cheap. Now it's dead of course (thanks Android) and all we have to fill the space is bloated incompatible buggy crap.
[1] https://developer.mozilla.org/en-US/docs/Mozilla/Boot_to_Gec...