There is something magical about Firefox OS(rawkes.com)
rawkes.com
There is something magical about Firefox OS
http://rawkes.com/articles/there-is-something-magical-about-firefox-os
275 comments
Yea well there is something not magical about it too which is normal users do not care what you write your apps in.
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.
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.
Javascript performing well on mobile is NOT magic, its just good engineering.
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.
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.
I hope Firefox pulls this off - native app programming is a complete pain in the ass (especially with multiple platforms). You'd have thought us programmers would've figured this out years ago - seeing as all languages are turing complete and in turn should all run everywhere, all the time, at equivalent speeds (it's all assembly/machine code in the end).
Can anyone try out:
http://anirudhjoshi.github.com/fluid_table_tennis/ on the Firefox OS and tell me its performance?
Can anyone try out:
http://anirudhjoshi.github.com/fluid_table_tennis/ on the Firefox OS and tell me its performance?
I want this, but for UNIX.
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).
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).
Can you Mozilla guys focus on making it so that HTML5 apps can install from web pages with an Install button and then show up on the home screen like a normal app? Please. So that HTML5 developers don't have to rely on people creating bookmarks or typing web addresses and can give users a similar experience as native.
This already works.
How do you do it? And on Android as well as iOS? And its the same installation and launch process?
That wasn't working last I checked.
That wasn't working last I checked.
Sorry, I should have said that this already works on Firefox OS. It may also work on Firefox for Android, but Apple would have to add support for Open Web Apps to Safari on iOS for it to work there (and the same with Google and the standard Android browser or Chrome)
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.
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.
A really minor point- why is it that the phone icon nowadays has defaulted to a handset turned to that angle, with green as the color? That looks similar to the phone icon in some of the Samsung phones that look more like iOS.
Is green and at 2 o'clock simply how we think of calling someone now?
Is green and at 2 o'clock simply how we think of calling someone now?
I came to post this. Seriously, why is this necessary? Are they trying to provoke a lawsuit?
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.
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.
Can it run in a virtual machine? Some folks might not want to give up their current super fast and reliable OS for one that runs only one complex, often insecure and sometimes error-prone application. In a VM I think this could be very useful.
Yes. Probably the only platform that will run HTML5 apps proper. Web developers should wholheartedly lap it up. But the issue is - consumer adoption.
This is another attempt to solve the glory cloud os? another browser-based OS? stop making the whole world dancing. It's a lame concept.
Firefox OS is the start of something huge. It's a revolution in waiting. A breath of fresh air. A culmination of bleeding-edge technology. It's magical and it's going to change everything.
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.
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.
Cool, well done Mozilla! Is this similar to WebOS?
The magic is that it will disappear before ever gaining any kind of recognition or prominence. Why would I choose this over the Open Sourced WebOS?
I wish they would add softkey support and toro support for the Galaxy Nexus. I'd love to try a build out.
Are you sure it doesn't already work? The build prerequisites page[1] makes it sound like all variants should work. I've run it on maguro, but it's definitely the most well-supported of the variants. The lack of softkeys made it astoundingly painful; I ended up using a USB OTG keyboard just to navigate.
[1] https://developer.mozilla.org/en-US/docs/Mozilla/Boot_to_Gec...
[1] https://developer.mozilla.org/en-US/docs/Mozilla/Boot_to_Gec...
I'm really in love with Boot2Gecko, it's the future
> In short, Firefox OS is about taking the technologies behind the Web, like JavaScript, and using them to produce an entire mobile operating system. Just let that sink in for a moment — it's a mobile OS powered by JavaScript!
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...
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...
> This kind of happened before: http://en.wikipedia.org/wiki/HP_webOS
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)
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)
WebOS was written in C++, eventually with a lot of Qt (the window manager, the dock, system dialogs, etc). The apps were written as web pages, though.
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.
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.
A core set of the apps were written in HTML+JS using the Enyo framework, but apps can also be written quite easily in C++, too.
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.
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.
Well, considering that the same chipset (APQ8060) was also used in some variants of Galaxy S II, I really don't think so that Touchpad hardware was that bad.
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.
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.
Fx OS on the SGS2 runs BLAZING fast compared to the device in the video. The reason why we don't shout about that? Because we're not launching with that device and it's not right to raise expectations in that way.
FWIW, I agree with masklinn that it's a little weird not to mention WebOS in the article. In particular when you wrote "In short, Firefox OS is about taking the technologies behind the Web, like JavaScript, and using them to produce an entire mobile operating system. Just let that sink in for a moment — it's a mobile OS powered by JavaScript!" I let that sink in back in 2009 when they announced WebOS. I was pretty excited about it. The way it crashed and burned from internal wrangling, delays, buggy releases and odd marketing was really sad. This is like you're showing up a year after the Hindenburg crashed and saying "Just let this sink in -- we've invented a rigid lighter-than-air flying machine!" That's not where we are in the conversation.
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.
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.
WebOS was targeted as an Android/iOS alternative on higher-end devices using proprietary APIs. It was also being developed by a company with shareholders who were purely focused on the bottom line.
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.
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.
Are we going to be able to load Fx OS onto our own SGS2s when it's released?
AFAIK you can do it right this minute, if you'd like. Here's a guide for dual-booting B2G and Android on SGS2 (though I have no idea how up-to-date it is):
https://developer.mozilla.org/en-US/docs/Mozilla/Boot_to_Gec...
https://developer.mozilla.org/en-US/docs/Mozilla/Boot_to_Gec...
Wow, thanks. I might give this a go.
Be warned that it doesn't work on all GS2 devices though.
Do you know if it works on an original Desire?
No idea. If the Desire is a SGS2 device then it probably works. Actually, best way to find out is to see if Cyanogen supports the phone because B2G uses the Cyanogen code to pull drivers. Last time I tried (April), the T-Mobile SGS2 wasn't supported by Cyanogen (or B2G) because it significantly different internals.
I have a Touchpad that dual-boots into WebOS or Android ICS. I love WebOS but I find Android to be much smoother and snappier. The memory management of Android is also much better.
Off Topic
@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.
@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.
Seems like he was hell-banned for this comment: http://news.ycombinator.com/item?id=4253243
"Firefox OS is based on the same concepts as WebOS so it's doomed"?
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.
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.
Doesn't the article you link to point our performance issues with the TouchPad _hardware_?
WebOS had a proprietary Javascript SDK or something lame. Firefox OS runs on pure HTML5 standards.
> WebOS had a proprietary Javascript SDK or something lame.
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.
[0] http://enyojs.com/
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.
[0] http://enyojs.com/
I posted further up but I'll put it here as well. You might appreciate this piece on WebOS and Fx OS from one of our engineers: http://www.quora.com/How-does-Mozillas-Boot-2-Gecko-compare-...
There might have been some proprietary bits, but you can download the code for the WebOS desktop and build it to a useable state from here: https://github.com/openwebos/build-desktop
Thanks for the comment, the WebOS question is one I see a lot.
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-...
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-...
I might not be reading this right, but in my mind this summarized as:
* 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.
* 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 not intimately acquainted with it, but I believe that some of the WebOS API's were too intimately tied to their Javascript framework.
I'm sure that Firefox OS used the WebOS API's as inspiration though.
I'm sure that Firefox OS used the WebOS API's as inspiration though.
webOS had some ugly bits under the hood that probably would have required cleanup.
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.
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.
Gecko will have an awesome performance. I went to Telefónica offices in Madrid a few weeks ago. They showed us a prototype (ZTE phone) running one of the lastest builds of Firefox OS (not the nightly, though). We touched it and it had pretty good perfomance. It was somewhat snappy on scrolling items, but overall a similar performance that you get on a medium-cost Android phone.
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.
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.
any idea when/if it will be available to buy? or what markets they are aiming at (latin america?)?
Brazil at first, next year. We're working on developer devices that can be used worldwide.
Any developer version that we could buy? I don't mind if we have to pay more. Need to test this for Burma market.
Edit: Didn't read carefully. You already mentioned that developer versions would be available worldwide soon. Any mailing list to subscribe for the announcement?
Edit: Didn't read carefully. You already mentioned that developer versions would be available worldwide soon. Any mailing list to subscribe for the announcement?
> Any developer version that we could buy?
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...
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...
webOS also suffered from execution issues (as a company). They were forever rewriting things under the hood as a fair number of things were duct-taped together.
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.
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.
> For example, they moved from a Java based solution to JS using v8 from webOS 1.x to 2.x.
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...
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...
webOS 1.x shipped with a Java runtime that was used to run basic system services like the email engine. This didn't show up directly in applications, but all the PIM apps made use of the Java code over the Luna Service Bus. 2.0 shipped with all the Java code removed, reimplemented either as native code or node.js-based services, but still communicating over the LSB.
webOS 1.x shipped with Java under the hood.
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.
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.
You might be interested in this: https://wiki.mozilla.org/B2G/Architecture
The fact that the links says nothing about power or memory management worries me.
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.
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.
The world can only process the introduction of so many mobile operating systems at once? I get the impression it was seen as competition to Android, but failed because Palm was a two-bit player in comparison to the Google juggernaut. Maybe if it were being introduced today it would stand more of a chance.
edit: oh and as to the failing of the author to acknowledge WebOS speaks to the author's knowledge or honesty, take your pick.
edit: oh and as to the failing of the author to acknowledge WebOS speaks to the author's knowledge or honesty, take your pick.
> The world can only process the introduction of so many mobile operating systems at once?
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.
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.
One of the great things about Android is that you don't have to be running it on a "high end" phone. Why bother with another new OS for your low-end handset when Android runs pretty well on low-end devices and you still get most of the benefit of Android (Google Apps like Nav, etc, don't require much processor power, they run great even on sub-$100 (off-contact price) phones).
I pick option 3. The author probably knows about WebOS and didn't think that it was necessary to go over it for this article.
[edit] If someone offers you n options, always pick option n + 1.
[edit] If someone offers you n options, always pick option n + 1.
Looks pretty but painfully slow in that demo video.
We have plenty of challenges to overcome but it's nothing that can't be fixed. We're fully aware of some of the frame-rate issues on the really low-end devices (like in the video) and are actively working on improving that (it's a main priority to get 60FPS).
Constant framerate is the thing that matters most to games. 60 fps or just 30 fps doesn't matter as much as that it's constant. You can even play a racer for example at 15 fps, but you fly out the curve the moment a 60 FPS game has a 250ms freeze at the wrong moment.
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.
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.
Yup, you're completely right… it's the constant frame-rate of a game that's important. And even if it's not truly 'constant', it should always stay above 30FPS. You probably shouldn't code a game to be tied to the frame-rate though.
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 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.
Hm, yeah - my point is that FPS isn't as important as the longest frame. You can have 100 FPS when 99 of them are really fast while the last one is stuck for nearly a second :-) Or said otherwise - for a game measuring average over a second is already a too long time-frame. It's nice as a simple feedback number for users, but it's not sufficient for smooth gameplay.
> We have plenty of challenges to overcome but it's nothing that can't be fixed. We're fully aware of some of the frame-rate issues on the really low-end devices (like in the video) and are actively working on improving that (it's a main priority to get 60FPS).
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.
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.
It's an interesting project, and I'm all for competition, but honestly I don't see the value proposition for an OEM to put this on a phone instead of Android. Rendering JavaScript faster is great, but does that really outweigh all the benefits of the Android ecosystem?
I don't know the stats, but I'm fairly convinced anecdotally there's still a huge segment of users who don't know or care about apps, and don't much know or care about the OS either. They'll use whatever ships with the phone.
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.
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.
You'd be surprised, Mozilla is going to launch this with Telefonica next year in Brazil. That's happening.
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.
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.
Part of the value proposition is that instead of waiting for the big code drop (from Google, in Android's case) and then having to scramble to do whatever they need to customize for their phones an OEM can be involved in Firefox OS development all along. And some are.
See also item two in the list at http://www.readwriteweb.com/archives/how_to_spot_openwashing...
See also item two in the list at http://www.readwriteweb.com/archives/how_to_spot_openwashing...
"Android has a cost" (Steve Ballmer). And it could increase (Apple)...
Who assures you that this JavaScript OS is safe from litigation?
"Just let that sink in for a moment — it's a mobile OS powered by JavaScript!"
Scary thought ;)
Scary thought ;)
Web standards apps will always have to make bad compromises. We need browser byte code.
What sort of compromises?
Having to target JavaScript. You then have issues with debugging, overly convoluted build processes etc.
JavaScript is browser byte code. Just like Java byte code it's not that great for a lot of cases but, just like Java, eventually the JIT will get pretty decent.
Only by accident. It has terrible semantics for a target assembly.
I don't know. No matter how often I hear/see this, I just can't plausibly believe it. I think there are a lot of things missing to make JS a plausible Javacript.
For this reason I kinda want Dart to succeed. Why not make the browser truly polyglot if we are trying replace OS with browsers?
For this reason I kinda want Dart to succeed. Why not make the browser truly polyglot if we are trying replace OS with browsers?
The JIT in the JVM is not for Java, but for Java bytecode. That, along with the easy integration into existing Java classes, is what makes the JVM such an attractive target for things like Scala, Jython, and Clojure.
Java bytecode is pretty close to Java "the language." You can try decompiling some Java classes and see how close to the original you end up getting.
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.'
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.'
It is. Sounds like a big waste of performance to me.
You'd be surprised at how well JavaScript performs when allowed.
The scary part of JavaScript is not performance, it is the hell of inconsistency.
'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.
'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.
Type coercion and asi are probably the least troublesome odd parts of js I encounter day to day.
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.
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.
Not inconsistency to me. + is a string concatenation operator, - is not (maybe it could be) and '1' - 0 is just a fallback.
[deleted]
Not really scary day-to-day. If you want to do integer math, make sure you're dealing with integers.
[deleted]
It performs well, until the code is too complex for the JIT compiler to get type inference / speculative optimizations right. Then it suddenly performs very, very poor, because it falls back on dynamic (very slow compared to inline) dispatch and doubles instead of ints.
The language seems in need of refinement to get significant performance in match of JVM JIT, not to mention c.
Probably. I haven't witnessed that yet though.
I think the only major advantage of Firefox OS is that it helps you run full HTML5 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.
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.
Let's just hope that it's fast enough then!
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.
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.
Giving how shockingly similar Firefox OS is to webOS (now also open source), I would have much rather that they support that OS instead of reinventing the wheel.
Some strange strategic decisions coming out of Mozilla inc. these days, I would much rather see them focus on their browser instead (and Thunderbird!).
Some strange strategic decisions coming out of Mozilla inc. these days, I would much rather see them focus on their browser instead (and Thunderbird!).
Yes, it's a shame Mozilla has completely halted desktop Firefox development in order to develop Firefox OS instead.
(Wait, what's that? A company/community can work on more than one thing at a time?)
(Wait, what's that? A company/community can work on more than one thing at a time?)
> (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.
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.
As far as "total users", Firefox OS has the potential to overtake Thunderbird in a matter of weeks after launch.
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.
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.
The World already has it: http://www.openwebosproject.org/
WebOS had its chance and failed. Firefox OS has a much better chance of succeeding, simply because it's backed by Mozilla.
[deleted]
You might appreciate this piece on Fx OS and WebOS: http://www.quora.com/How-does-Mozillas-Boot-2-Gecko-compare-...
Yes I read that from your other comment, the engineer begins with:
> 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)?
> 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)?
First off, B2G started well over a year ago, when there were no signs of WebOS becoming open source (it was more likely that it would be sold). So what you're suggesting is that they either have waited or that they should have stopped working when Open WebOS was announced (even though it was just released a few weeks ago).
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
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
I apologise for writing a long post - I have not time to write a short one
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.
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.
>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.
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.
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.
> 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?
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.
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.
I completely agree, but spreading blatant FUD that anyone can see just isn't true, isn't the way to do that.
I see simonh as a respected and long time member of HN and hope that my reply can be constructive and beneficial to that community.
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.
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.
Thanks for the comment, I really appreciate it!
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.
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.
You are right to start with low-end devices:
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.
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.
Addendum: Don't fall into the Linux trap. Don't start off being "great on old hardware!" but eventually grow so huge as to need the same specs as modern Windows (my i7 laptop with 4 GB of RAM runs like crap, thanks Debian). Do things in a straightforward way, but in such a way that you can expand without tacking on loads of extra code.
I think out of everyone you've really hit the nail here. It's about starting a movement, and taking the platform in a direction it's been needing to go to for a long time. The collaborative nature of open source should grow around this project as soon as the product arrives, and I really hope it does.
Has to be said from experience that I'd never assume business people know what they are doing. Check it yourself.
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.
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.
Its good to see you on here (I tend not to see authors of posts on HN - maybe its me)
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
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
Otoro is a prototype device not generally available. One of the listed models of Nexus S is your best bet right now. There may be something else in the near future, we're trying to firm up a target phone that is available for general purchase.
However, there are some very sound business decisions behind us chosing to go ... with cheaper, low-end devices. I'm sure they know what they're doing more than I do!
I'm not sure. Gecko is faster and lighter than Dalvik now? Since when?
I'm not sure. Gecko is faster and lighter than Dalvik now? Since when?
> If Firefox OS says we are not as good as iOS then thay are squarely putting themselves in the middle of the market.
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.
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.
I really struggle with that - it's the app that counts.
Having a web browser is probably the main dividing line, but having sms networjs that really allow your business to trade over SMS means to me that the functionality counts - it would be nice to buy an iPhone but if a LCD SMS device will allow me to sell my goods each week, then high end and low end are far wider than we presume
> allow your business to trade over SMS means to me that the functionality counts
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.
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.
[deleted]
What's the £50 device? I'm not going to buy a Galaxy variant to play with Firefox OS, but £50 is a different story.
It's a ZTE Kis. You can't use it yet because it's a development version but we're working on getting devices available to developers before we launch properly.
The Kis is merely a test device for now.
The Kis is merely a test device for now.
I really want a cheap test device so I can start hacking on B2G. Sure, I guess I could get a second-hand SGS2, but those are still pretty expensive to use a test device.
This looks like a terrible idea for a mobile OS, where every cycle should count. What about battery life? I think that for now, and foreseeable future, the only reasonable choice for mobile devices are native code based apps and system.
Battery life is very, very good. I can leave this thing on for days and it's still running. Now obviously that's not running too much in the background but there is no reason why a JavaScript phone would have a detrimental effect on battery life.
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 ;)
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 ;)
Have you made any actual power measurements using say powertop etc?
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.
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.
The short answer is no, I haven't used anything scientific to measure this… just my eyes.
I'll make sure that we release test results as they are performed, probably on the Mozilla Hacks blog or likewise.
I'll make sure that we release test results as they are performed, probably on the Mozilla Hacks blog or likewise.
> I think that for now, and foreseeable future, the only reasonable choice for mobile devices are native code based apps and system.
So basing a mobile OS on something like Java (or C#/Silverlight) would be completely silly in your opinion?
So basing a mobile OS on something like Java (or C#/Silverlight) would be completely silly in your opinion?
I don't think it's the best possible option. Afaik WP7's core apps are native, not in C#/Silverlight.
Mozilla seem almost apologetic about Firefox OS.
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.
"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.
> (50 USD is not low-end if minimum wage in Brazil is 322 USD /mth)
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...
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...
it doesn't really work like that. emerging markets have people as rich as rich americans and they know about, want, and own iphones.
(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)
(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)
I think that getting my cool, trend-leading designer friends is possible - apple is not undefeatable. And while google is not very evil, Mozilla is nearly saint-like in comparison.
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.
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.
[deleted]
[deleted]
Looks nice but it's not fluid.
It will be, we're actively working on performance now. We have no reasons to believe that we can't get it 'fluid'.
You could set your watch by the HN response to a story like this. Pure doom, gloom and naysaying.
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.
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.
I'm confused by your statement about "the daunting prospect of dealing with Objective C, Java and C# simultaneously. This is a ludicrous prospect for a lone developer."
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.
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.
The point is not that the these three languages are hard or obscure or that using all three is hard. The point is that maintaining the same code in parallel in three languages is a Wrong thing to do. DRY. Big companies can get away with it because they can throw manpower but it's still wrong.
It depends, if your app is just a dumb UI that calls out to services then all the logic etc should be in the server, the UI code should just be displaying and a bit of caching.
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.
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'd also add that I don't think it necessarily violates "DRY".
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.
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.
"JavaScript has proven time and time again to not be a good language for anything but short scripts." Perhaps this is just troll bait...
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.
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.
It's not about languages. With a certain level of experience languages can be learned to a useful point in a weekend. The problem is the knowledge of the platform, the APIs, the problems each platform has, which parts you should use, which parts you should avoid, what performs better, what hangs your app, what renders things poorly. All those things require a lot more time to learn.
You're right, the difficulty isn't the language in use. Languages are easy. But learning each of the platform-specific APIs is a much more daunting task. Learning web-based APIs are no less daunting, but given that a huge proportion of new developers are starting out with web dev, being able to leverage their existing knowledge is a powerful advantage.
You'd be surprised at what JavaScript can do nowadays… https://developer.mozilla.org/en-US/demos/detail/bananabread
Also HexGL: http://hexgl.bkcore.com/
There is nothing surprising in it. 3D rendering is done mostly by hardware (OpenGL), not JS. But try to code something more sophisticated computationally for CPU, not a one function long microbenchmark where the JIT can guess all the types because code is simple. Something like simulating a complex mechanical or electrical system or some discrete optimisation stuff. Then it quickly turns out carefully hand crafted JS even on Chrome is more than order of magnitude slower than naive Java code.
The JIT should very easily be able to guess all the types in a complex mechanical or electrical system, or in discrete optimization. Matrices are fairly consistently typed.
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.
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.
If it did whole-program optimization, it theoretically could. But it is probably too costly. You don't have that much time and resources to optimize JIT, as you have doing static compilation. That's why, contrary to common beliefs on static vs dynamic compilation, still static compilers win in most cases, compared to even very mature things like JVM or .NET CLR, even though they have much easier task than JS.
I haven't counted how many times I've read "magnitude" in this discussion … Does anyone actually have some numbers to back up the claims?
It's not a function of knowledge. It's a function of time.
Couldn't Agree more. A professional dev should know one of these languages well. They should be judicious enough with their time to know that it doesn't make sense to "just pick up" a language for job-related work.
Could they have used Firefox OS as an opportunity to bring another language to the browser, rather than javascript to native? ie. if you could write [Objective C/Java/C#/etc] libraries for Firefox OS and they could be compiled and served to a browser client.
Perhaps not entirely what you're after, but Mozilla's Emscripten project will allow that: https://github.com/kripken/emscripten
I mostly agree with your points, although I personally think that the JavaScript ecosystem is maturing quite rapidly through node and amd.
Everything this person said is the truth.
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.
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.
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.
> Made in the past ~5 years.
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.
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.
Oh, I did have issues with the emulator. When I was just starting, I thought my hello-world program was broken because nothing was happening, but that was just the emulator taking so long to start up. Once I learned to keep it running I could iterate much faster, although I still had to be careful.
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.
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.
Not to mention the daunting prospect of dealing with Objective C, Java and C# simultaneously.
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.
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.
You can use C# for all three with monotouch. But honestly it doesn't matter much. Objective C is very similar to C# which is very similar to Java. It is really just slightly different syntax.
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.
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.
There are loadds of high-end games written in JS: Cut The Rope. Bejeweled. Angry Birds. As well as many more lesser known ones that push things as far as possible.
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.
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.
Those are not high end games. Those are casual games that look like they would run better and would work in a wider array of browsers in flash. Also I am mistaken, you can include webgl.
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.
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.
Angry Birds is written in Lua.
"Smartphones live and die by their app ecosystem"
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.
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.
a) Your set of 99.5% apps are going to be different from those of other people. You need a lot more coverage than that to make a substantial percentage of people happy.
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.
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.
Erm, but have you got a source for that? As fun as my anecdotal evidence versus yours is...
No. Do you seriously dispute any of the claims I made, or are you just being argumentative? It was mostly reasoning from common knowledge, not generalizing from my own anecdotal experience.
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.
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.
Yes, I seriously dispute the claims you make, but purely based on my own sample of, say, ten users that I have discussed this with. Hence, I have a completely different opinion, but I don't have a large sample.
I'm trying not to be argumentative, but you're tempting me :).
I'm trying not to be argumentative, but you're tempting me :).
Ok. Given the depth of your argumentation, I still have no idea of what exactly you don't believe or find convincing. But I'll try to expand on these:
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?
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?
[deleted]
[deleted]
[deleted]
Terrific stuff.
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).
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).
According to this blog post, Firefox OS is already providing native-like performance in a standard JavaScript+HTML+CSS environment. (By "native-like" I mean fast enough that the application will feel native to users.) If this is true, then I would agree Firefox OS is a game changer, because it means that ALL modern web applications can run unmodified at native-like speeds on mobile devices. The number of apps available for the platform is already in the many millions. Very exciting!
--
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.
--
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.
JavaScript doesn't run at the speed of native, but it certainly runs fast enough on things like Fx OS (or desktop browsers) to run 'native-like' apps. It really depends what you want to do with it.
For example, this is JavaScript: https://developer.mozilla.org/en-US/demos/detail/bananabread
For example, this is JavaScript: https://developer.mozilla.org/en-US/demos/detail/bananabread
So how come e.g. www.circuitlab.com which is a simulator written in pure JS is two orders of magnitude slower on Chrome or Firefox than native *SPICE implementations in C? It is actually even much slower than the already pretty slow Falstad's Java applet.
Two orders of magnitude? That can't be explained by the difference between C and JS. There must be some other difference, like which algorithms are used, or that the C one relies heavily on inline assembly or such.
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).
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).
Just swap base e for base 10, and boom, twice the orders of magnitude.
Since azakai is too humble to mention his own qualifications, I want to point out that is the author of the Emscripten LLVM-to-JS compiler, and the BananaBread first-person-shooter demo linked above, so when he talks about the limits of JS performance compared to C, he really knows what he's talking about. :)
Well, I could agree if I saw any computational-heavy JS application (and not a microbenchmark) doing well compared to native counterpart, especially on multicore. So far, I found only the one I cited - and the fact is, it is damn slow.
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.
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.
> Well, I could agree if I saw any computational-heavy JS application (and not a microbenchmark) doing well compared to native counterpart, especially on multicore.
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.
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.
If you're working on Bananabread, can you check why it's not working on Chrome, the latest stable version? I get an Oops message. I use Windows 7 x64, Core i7 laptop with Nvidia 555m GT .Also just installed Nvidia's latest driver, though I haven't rebooted yet. Could that be it?
Have you enabled mouse-lock in chrome://flags ? It talks about this on the page, if you're curious.
I am aware of a bug in Chrome where the Chrome tab will crash after you play for a while or reload the tab. But in a new tab you should be able to play for a few seconds ok - is that what you are experiencing?
In addition to the responses from the Mozilla guys, I'll also point out that the limiting factor in speed for most web applications is not javascript runtime speed but dom manipulation, reflow, and repaint. The tricks for optimizing these tend to be somewhat browser dependent and not generally known by the web development community.
The term "native-like" means "with a responsive interface" these days.
Oh yeah, by this definition interpreted Python is also native like. Just do all your UI rendering by native libs and use scripting to glue it together. But this is not what most of programmers call native speed.
I think you're misinterpreting the meaning of 'native' in this context; the tradeoff in question isn't one of interpreted/JIT'd v. ahead of time to the metal, but rather one of Web v. every platform's standard graphical application stack(s) (which may or may not be ahead of time compiled).
Hence the context of being magical. It is more of a sleight of hand trick than actual supernatural. The author of the post is misusing a development term to convey a different meaning.
And access to hardware, and with a common, system interface (native widgets) not custom or third-party UI widgets.
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?
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?
Well-optimized C is likely to always be faster than well-optimized JavaScript.
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 :)
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 :)
I don't think C will always be faster. A JIT-compiled language can theoretically be optimized better than a precompiled binary, because the JIT engine can recompile hot code based on observed behavior on the actual system with the actual data.
Theoretically, a c-compiler could produce self modifying code.
Also, this theoretical c compiler could make use of implicit hints (like which variables to place together in memory), making it faster than JS (except asymptotically, when the JIT has run long enough to figure everything out).
But the original point is basically right - one day JITs will be faster.
But the original point is basically right - one day JITs will be faster.
JITs don't have so much time to optimize, as static compilers do. Therefore, they can't do e.g. whole program analysis, or expensive cache related optimizations. Despite 15 years of effort of speeding up JVM, it is still slower in general than optimized C. Not by much (usually good Java code runs within a 2x slower margin), but still - it can't beat static compilers.
Watch the video. That's not native performance. It will never be native performance, because there will always be the layer of the rendering engine between your application and device. The best they'll ever do is "close enough to native that you don't notice", and they're certainly not there yet. And the number of apps is already in the millions? 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 video does look a bit rough, but that's neither final code nor final hardware. For what it's worth, actually touching one of the Firefox OS dev phones is pretty impressive: it feels much smoother than it looks on that video.
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.
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.
There is always a rendering engine unless you're writing pixels to the buffer directly. The thing is that Cocoa/CocoaTouch's rendering and compositing is much faster than Webkit's. Why that is, is left as an exercise for the reader.
Webkit uses iOS's rendering and compositing libraries to render information on screen. That's why it will never be faster than those libraries.
never say never.
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).
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).
And at that point, native would still be faster....
At some point, native would still be faster in the same sense a curve approaches the x-axis but never quite touches it.
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.
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.
I wasn't speaking practically. The GP said "native will always be faster" and that's true. Relevance of that truth is a separate issue.
HTML hit practically 0 latency 10 years ago then we added DHTML, CSS, encryption, Ajax, 3D, multitasking, 2x DPI and 4x screen size, background syncing, ...
When will we stop adding functionality to soak up the hardware power?
If we hadn't added those things, HTML&Cia. wouldn't even be a contender to replace native performance now. It would still be a simple technology meant for static information.
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.
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.
The HTML5 version of Cut the Rope is one example:
http://www.cuttherope.ie/
Here are some other high quality HTML5 games:
http://worldsbiggestpacman.com/ http://www.wordsquared.com/ http://www.pirateslovedaisies.com/ http://browserquest.mozilla.org/
http://www.cuttherope.ie/
Here are some other high quality HTML5 games:
http://worldsbiggestpacman.com/ http://www.wordsquared.com/ http://www.pirateslovedaisies.com/ http://browserquest.mozilla.org/
He mentions it being a "hackable dream for developers". I wonder if we're ever going to get something that's hackable by users. Or in other words, bridges the gap between the common user and the elite app-store backed developer…
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.
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.
Theoretically, this is definitely possible and something that I'd love to see. I know we have some guys within Mozilla working on things that are more 'hackable' for the general user, rather than developers.
Scripting layer for Android if fairly close to what you are talking about:
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.
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.
Well, this allows scripting languages to access the Android runtime APIs, something I'm picturing would require the applications themselves to be scriptable. This would require some integrated hooks, like Apple's AppleEvents or Microsoft's COM.
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.
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.
Is there any bridge between JS and native code?
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.
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.
You seem to assume an existential difference between "native" and "not-native" that does not actually exist.
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.
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.
What makes you think that? Android runs non-native apps and the battery life can be very good (depending mostly on hardware of course).
Mozilla, please don't allow carriers or manufacturers to modify your OS! You need to set the right tone from the very beginning. Otherwise you'll never get that kind of power back later on.
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.
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.
If it's an alternative to Android that doesn't let Carriers "add value" then it's an alternative they won't use. Open Source, in this case, becomes a race to the bottom in every respect.
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.
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.
>> If it's an alternative to Android that doesn't let Carriers "add value" then it's an alternative they won't use.
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.
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.
Here's the real problem: The major carriers charge the same rate regardless of whether you got a free phone from them or not. The phone subsidy doesn't go away even if you paid $500 out of pocket for a Nexus.
My solution: I bought a factory unlocked iPhone 4 from Canada on ebay. I run it with a Straight Talk SIM for $45 a month, no contract, unlimited everything.
So how do we curb this voracious appetite of needing to get into every bit (data, apps, ads, other value adds) of being a telco?
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?
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?
I think the fundamental problem is the carriers' vertically integrated business model -- Verizon and AT&T want to sell you the phone, the phone service, the data service, the TV service, etc. etc.. From the consumers' point of view we need the actual pipes to be infrastructure then we buy devices that use the pipes, and pay for services that send us stuff over the pipes. But how to get there? Massive government intervention of some kind is probably the only option. Left to the market we'll simply get the biggest most monolithic monopolies that the government allows to form.
How is owning infrastructure anything other than a low-margin hot-potato if you let yourself be turned into a dumb pipe?
Why should owning infrastructure be anything other than low margin?
We are working on that, but there is only so much we can do if we want this to be open. If carriers want to use the Firefox OS branding and our system then there will be certain limitations on what they are expected to do in return.
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.
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.
I think the key is making it easy for users to 'reset' the device to stock FxOS. I would hope the firefox brand was strong enough to keep carriers from releasing their own variants to avoid mozilla's requirements.
Your point about the brand is most important, I think most carriers wouldn't want to start something from scratch. Plus, the Mozilla and Firefox brand brings a lot with it.
This. The Firefox OS license for carriers should be "you can modify our OS however you like, but you must take no steps to keep users from installing a clean one, nor penalize them for doing so."
> This. The Firefox OS license for carriers should be "you can modify our OS however you like, but you must take no steps to keep users from installing a clean one, nor penalize them for doing so."
If Firefox OS is to be open source (OSS-compliant), then you can't impose this sort of restriction.
If Firefox OS is to be open source (OSS-compliant), then you can't impose this sort of restriction.
Why? Mozilla does that today, as does Android- if you don't comply with their guidelines, you can use the code, but not the trademark.
It's open source. Mozilla can't (and shouldn't be able to) prevent carriers and manufacturers from tinkering.
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.
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.
They can prevent them from calling it FirefoxOS, though; in fact, they do just that with regular Firefox (see Iceweasel).
[deleted](1)
>There are a few intense games, like Biolab Disaster, that perform stunningly on even the £50 low-end device that I'm testing on — we're talking between 40 and 60FPS.
.
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.
.
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.
Thanks for the comment, I appreciate it.
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.
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.
Can we please stop putting JavaScript everywhere? It's not a good language and people have a tendency to produce frailer code with it than they would otherwise.
This kind of request strikes me as kind of similar to the movements to standardize English spelling. There are groups out there who, for at least a hundred years, have been saying "can we please stop spelling the same sounds in five different ways? It's not a good approach to language and people waste a lot of time that they wouldn't otherwise." It's true, but at the same time, there are reasons they're not making any progress.
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.
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.
What makes you say this?
Really excited to play with this. Also excited to see the people working on it are really geeked. It's going to get really interesting as a web developer over the next couple of years. If you can use HTML, CSS, and JavaScript to manipulate an OS, then wow. Can't wait to see where this goes.
So it's an OS that requires apps to be written in JavaScript (an interpreted language that was designed by Netscape for web scripting and nonprofessional programmers) and HTML (a markup language designed to display static documents in the browser). None of these technologies were designed to help developers create software applications, so why is this magical?
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.
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.
To be clear, the OS is not written in Javascript. It's simply Mozilla's Gecko platform (the same engine used by Firefox, written in C++ since time immemorial) running directly on top of Linux. Nothing was rewritten to get this to work: Gecko was originally designed to be a portable application platform rather than "just" a layout engine (and it was this concomitant complexity that led Apple and Chrome to use Webkit (which is just a layout engine) for their own browsers).
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.
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.
People use javascript not because of what it was originally created for but because of what it has become and is currently being used for. But most of all, because of its ubiquity. Last time I checked, Objective-C doesn't run in a web browser.
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?
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?
Rob, could you put on the article which devices we already can build the OS?
I want to buy one but i don't know what is already supported :)
I want to buy one but i don't know what is already supported :)
Take a look at the list here: https://developer.mozilla.org/en-US/docs/Mozilla/Boot_to_Gec...
Sounds a lot like webOS; huge amounts of potential, only to be plagued by 'being ahead of the game'. Probably still 5 years out, sadly. I really like the idea of a JavaScript OS.
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)
https://github.com/openwebos http://enyojs.com
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)
https://github.com/openwebos http://enyojs.com
I just wish Firefox wasn't coping iOS. Slide open, 4 x 4 grid with a dock, swipe between panes. It's just sad that companies think this is the 'standard' for any phone os and stick to it. Metro gets some respect from me for taking a fresh approach, this, unfortunately doesn't.
Why don't you criticize Toyota for using a circular steering wheel and similar feeling clutches, brake pedals and gas padels while you're at it?
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.
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.
Yes. I was introduced to Firefox OS in detail at Mobile 2.0 the other day, and I instantly fell in love. This is what the world needs: an open platform designed for the people who don't already have an Internet connection, let alone an iPhone. If they succeed in their mission, and current partnerships with telcos like Telefonica suggest that they will, then they could quite possibly change the world. I'm sold, and completely on board.
I saw a talk on FxOS (then B2G) earlier this year, and asked a question about how FxOS will handle native SDKs, considering practically every single mobile OS that used VMs to run apps had eventually capitulated and provided native SDKs for speed and codebase compatibility.
The Mozilla guy who responded was very adamant on keeping HTML/CSS/JS the one and only dev environment for the OS.
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.
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.
Most of the discussion so far has focussed on the development environment (APIs, languages, etc) and performance issues.
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...
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...
UX design guidelines are coming; the designer who is working on them gave a talk at MozCampEU last week. (Only the slides are available for now, but a more detailed write-up should be posted soon.)
https://wiki.mozilla.org/MozCampEU2012/Design-Principles-beh...
https://wiki.mozilla.org/MozCampEU2012/Design-Principles-beh...
Thanks for the link to the presentation.
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.
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.
I enjoyed reading this. I mostly know Java and not so much Javascript, but there's something delightful in the idea the writer lays out. As much as I like Android, it isn't really 'hackable' by the average user, and Firefox OS seems capable for that.
Are web technologies on the phone really the best way to empower users? Sure Firefox and Linux are open source(and I love them for that), but what about online apps? User does not have any control over the web page. If web page changes or disappears he can do nothing(and it can happen with no warning). Storing local copy of webpage may not be possible(because huge part of app may be on server side). Even proprietary desktop apps are better[1] because they do not change on each startup and you could always try to reverse engineer them. Web app also can store user data on server giving him no way to recover and it gives more spoofing opportunities.
Sure we can try to teach users about to choose open source web pages, or pages that can work in offline mode, but unfortunately most web pages does not fit these categories.
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.
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.
This is actually a question for you guys... I realized that this can be very revolutionary for us as developers (making our lives way easier).
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.
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.
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.