> if we could ship an alternative browser engine implementation with competitive JIT'ing JavaScript engine
Which is not possible on FirefoxOS. So I don't see how 'open' wins here (I'm using 'open' as the GP used it: a marketing buzzword synonymous with Mozilla).
Re:Webkit.js
by ndesaulniers on Friday June 20, 2014 @03:00PM
(#7922253)
I agree that "FirefoxOS will host Safari / Chrome apps, before iOS will allow a Firefox." doesn't lead to "Open FTW." I think Open still wins, for other reasons I've been trying to document. [0] Firefox OS is still young, and if it can establish meaningful marketshare, it puts Mozilla in position to change the industry.
For example, what if Mozilla had leverage over device manufacturers to say "no locked bootloaders" and device manufacturers complied? I'm not sure Mozilla has that leverage today, but what other ways could Mozilla affect the industry for good once it does?
[0] https://github.com/nickdesaulniers/What-Open-Source-Means-To...
> Chrome on iOS offers nothing in the way of additional html5 APIs and is just a new UI on the same old Webkit (to my knowledge).
No, they forked Webkit due to all the browser related #ifdef's they had scattered across the source code. They were diverging to much and damaging the quality of the code.
https://en.wikipedia.org/wiki/Blink_%28layout_engine%29
Edit: They're still pretty similar, though.
Re:Webkit.js
by matthewbauer on Friday June 20, 2014 @09:17PM
(#7923770)
Chrome on iOS doesn't use Blink because Apple doesn't allow it.
For instance, as of about a week ago Safari on iOS just got WebGL support (as you alluded to). How long would we have had WebGL support on iOS if we could ship an alternative browser engine implementation with competitive JIT'ing JavaScript engine (like Firefox's Gecko & SpiderMonkey engines) on iOS since the beginning? Would alternative browser engines with more APIs drive the Safari for iOS team to ship features faster? Bottom line: competition is healthy; developers and thus users win.