[This is an extended essay on the news out of Norway yesterday. See the closing for encouragement toward Opera and its fans, whatever the open source projects they choose to join, from me on behalf of Mozilla. /be]
Founder Flashback
I wrote about the founding of HTML5 in June, 2004, without dropping that acronym, mentioning only “Opera and others” as partners, because Apple was shy. Fragments of memory:
- @t was then working for Microsoft (he’s at Mozilla now, it’s great to have him) and sitting in front of me during the second day of the workshop.
- Vested interests touted XForms as inevitable (the UK Insurance Industry had standardized on it!).
- Browser vendors were criticized as everything from uncooperative to backward in resisting the XML Utopia.
- JavaScript took its lumps, including from Bert (whom I met years later at SXSW and got on fine with).
Hixie (pre-Google, already working on Web Forms 2) and Håkon of Opera joined David Hyatt of Apple, Mozilla’s @davidbaron and me at a San Jose pub afterward. There I uncorked and said something like “screw it, let’s do HTML5!”
We intended to do the work in the WHAT-WG. Håkon reminded us that the only likely path to Royalty-Free patent covenants remained the W3C, so we should aim to land specs there. He also correctly foresaw that Microsoft would not join our legal non-entity, rather would prefer the W3C.
So we drank a toast to HTML5.
Fast-Forward to 2013
In early January, I heard from an old friend, who wrote “Some major shift is happening at Opera, senior developers are being laid off, there’s a structural change to the company….” Other sources soon confirmed what became news yesterday: Opera was dropping Presto for WebKit (the chromium flavor).
One of my sources wrote about Mozilla and why it matters to him:
Smart people, and people I know and like, at that. Interesting work going on in [programming languages and operating systems]. Probably the last relatively independent web technology player (not something I cared about historically, but after leaving the Apple iOS fiefdom for the Google Android fiefdom, I find I’m just as locked in and feel just as monitored).
I hear this kind of comment more often lately. I think it’s signal, not noise.
Why Mozilla Matters
The January signal reminded me of mail I wrote to a colleague about “How Mozilla is different”:
- We innovate early, often, and in the open: both standards and source, draft spec and prototype implementation, playing fair and revising both to achieve consensus.
- Our global community cuts across search, device, social network businesses and agendas, and wants the end-to-end and intertwingled mix-and-match properties of the Web, even if people can’t always describe these technical properties precisely, or at all. What they want most is to not be “owned”. They seek user sovereignty.
- We restored browser competition by innovating ahead of standards in user-winning ways. We’re doing it again, and with allies pulling other platforms up: Samsung is patching WebKit to have the B2G-pioneered device APIs.
- Because we are relatively free of agenda, we can partner, federate, integrate horizontally instead of striving to capture users in yet another all-purpose vertical silo.
- We advance the vision of you owning your own experience and data, attached to your identity, with whatever services you choose integrated. Examples include the Social API and the new Firefox-sync project that outsources storage service via DropBox, Box, etc.
The last point is hugely important. It’s why we have had such good bizdev and partnering with Firefox OS. But it is also why we have a strongly trusted brand and community engagement: people expect us to be an independent voice, to fight the hard but necessary fight, to be willing to stand apart some times.
I see these as critical distinguishing factors. No competing outfit has all of these qualities.
Thoughts on WebKit
I read webkit-dev; some very smart people post there. Yet the full WebKit story is more complex and interesting than shallow “one WebKit” triumphalist commentary suggests.
First, there’s not just one WebKit. Web Developers dealing with Android 2.3 have learned this the hard way. But let’s generously assume that time (years of it) heals all fragments or allows them to become equivalent.
WebKit has eight build systems, which cause perverse behavior. Peel back the covers and you’ll find tension about past code forks: V8 vs. Apple’s JavaScriptCore (“Nitro”), iOS (in a secret repository at apple.com for years, finally landing), various graphics back ends, several network stacks, two multi-process models (Chrome’s, stealth-developed for two years; and then Apple’s “WebKit2” framework). Behind the technical clashes lie deep business conflicts.
When tensions run high the code sharing is not great. Kudos to key leaders from the competing companies for remaining diplomatic and trying to collaborate better.
Don’t get me wrong. I am not here to criticize WebKit. It’s not my community, and it has much to offer the world on top of its benefits to several big companies — starting with providing a high-quality open-source implementation of web standards alongside Mozilla’s. But it is not the promised land (neither is Mozilla).
If you are interested in more, see Eric Seidel’s WebKit wishes post for a heartfelt essay from someone who used to work at Apple and now works (long time on Chrome) at Google.
My point is that there’s no “One WebKit”. Distribution power matters (more below near the end of this essay). Conflicting business agendas hurt. And sharing is always hard. There are already many cooks.
In software, it’s easier in the short run to copy design than code, and easier to copy code than share it. In this spirit the open-source JS engines (two for WebKit) have learned from one another. Mozilla uses JSC’s YARR RegExp JIT, and we aim to do more such copying or sharing over time.
Web Engine Trade-offs
Some of you may still be asking: beyond copying design or sharing pieces of code, why won’t Mozilla switch to WebKit?
Answering this at the level of execution economics seems to entail listing excuses for not doing something “right”. I reject that implied premise. More below, but at all three levels of vision, strategy, and certainly execution, Mozilla has good reasons to keep evolving Gecko, and even to research a mostly-new engine.
But to answer the question “why not switch” directly: the switching costs for us, in terms of pure code work (never mind loss of standards body and community leverage), are way too high for “switching to WebKit” on any feasible, keep-your-users, current-product timeline.
XUL is one part of it, and a big part, but not the only large technical cost. And losing XUL means our users lose the benefits of the rich, broad and deep Firefox Add-ons ecosystem.
In other words, desktop Firefox cannot be a quickly rebadged chromium and still be Firefox. It needs XUL add-ons, the Awesome Bar, our own privacy and security UI and infrastructure, and many deep-platform pieces not in chromium code.
Opera, as a pure business without all of XUL, the Mozilla mission, and our community, has far lower technical switching costs. Especially with Opera desktop share so low, and Opera Mini as a transcoding proxy that “lowers” full web content and so tends to isolate content authors from “site is broken, blame the browser” user-retention problems that afflict Opera’s Presto-on-the-desktop engine and browser.
Nevertheless, my sources testify that the technical switching costs for Opera are non-trivial, in spite of being lower relative to Mozilla’s exorbitant (multi-year, product-breaking) costs. This shows that the pure “business case” prevailed: Opera will save engineering headcount and be even more of a follower (at least at first) in the standards bodies.
The Big Picture
At the Mozilla mission level, monoculture remains a problem that we must fight. The web needs multiple implementations of its evolving standards to keep them interoperable.
Hyatt said pretty much the last sentence (“the web needs more implementations of its evolving standards to keep them interoperable “) to me in 2008 when he and I talked about the costs of switching to WebKit, technical and non-technical. That statement remains true, especially as WebKit’s bones grow old while the two or three biggest companies sharing it struggle to evolve it quickly.
True, some already say “bring on the monoculture”, imagining a single dominant power will distribute and evergreen one ideal WebKit. Such people may not have lived under monopoly rule in the past. Or they don’t see far enough ahead, and figure “après moi, le déluge” and “in the long run, we are all dead.” These folks should read John Lilly’s cautionary tumblr.
@andreasgal notes that the W3C tries not to make a standard without two or more interoperating prototype implementations, and that this now favors independent Gecko and WebKit, since the only other major engine for WebKit to pair with is Microsoft’s Trident. We shall see, but of course sometimes everyone cooperates, and politics makes strange bedfellows.
I expect more web engines in the next ten years, not fewer, given hardware trends and the power wall problem. In this light, Mozilla is investing not only in Gecko now, we are also researching Servo, which focuses on the high-degree parallel (both multicore CPU, and the massively parallel GPU) hardware architectures that are coming fast.
If we at Mozilla ever were to lose the standards body leverage needed to uphold our mission, then I would wonder how many people would choose to work for or with us. If Servo also lacked research partners and good prospects due to changing technology trends, we would have more such retention troubles. In such a situation, I would be left questioning why I’m at Mozilla and whether Mozilla matters.
But I don’t question those things. Mozilla is not Opera. If we were a more conventional business, without enough desktop browser-market share, we would probably have to do what Opera has done. But we’re not just a business, and our desktop share seems to be holding or possibly rising — due in part to the short-term wins we have been able to build on Gecko.
Future Web Engines
So realistically, to switch to WebKit while not dropping out of the game for years, we would have to start a parallel stealth effort porting to WebKit. But we do not have the hacker community (paid and volunteer) for that. Nowhere near close, given XUL and the other dependencies I mentioned, including the FFOS ones. (Plus, we don’t do “stealth”.)
The truth is that Gecko has been good for us, when we invest in it appropriately. (There’s no free lunch with any engine, given the continuously evolving Web.) We could not have done Firefox OS or the modern Firefox for Android without Gecko. These projects continue to drive Gecko evolution.
And again, don’t forget Servo. The multicore/GPU future is not going to favor either WebKit or Gecko especially. The various companies investing in these engines, including us but of course Apple, Google, and others, will need to multi-thread as well as process-isolate their engines to scale better on “sea of processors” future hardware.
There’s more to it than threads: due to Amdahl’s Law both threads and so-called “Data Parallelism”, aka SIMD, are needed at fine grain in all the stages of the engine, not just in image and audio/video decoding. But threads in C++ mean more hard bugs and security exploits than otherwise.
I learned at SGI, which dived into the deep end of the memory-unsafe SMP kernel pool in the late ’80s, to never say never. Apple and Google can and probably will multi-thread and even SIMD-parallelize more of their code, but it will take them a while, and there will be productivity and safety hits. Servo looks like a good bet to me technically because it is safer by design, as the main implementation language, Rust, focuses on safety as well as concurrency.
Other approaches to massively parallel hardware are conceivable, and the future hardware is not fully designed yet, so I think we should encourage web engine research.
Strategic Imperatives
Beyond these considerations, we perceive a new strategic imperative, both from where we sit and from many of our partners: the world needs a new, cleanish-slate, safer/parallel, open-source web engine project. Not just for multicore devices, but also — for motivating reasons that vary among us and our partners — to avoid depending on an engine that an incredibly well-funded and lock-in-prone competitor dominates, namely WebKit.
Such a safer/parallel engine or engines should then be distributed and feed back on web standards, pushing the standards in more declarative and implicitly parallelizable directions.
Indeed more is at stake than just switching costs, standards progress, and our mission or values.
One pure business angle not mentioned above is that using an engine like WebKit (or what is analogous in context, e.g., Trident wrappers in China) reduces your product to competing on distribution alone. Front end innovations are not generally sticky; they’re in any event easy to clone. Consider Dolphin on Android. Or observe how Maxthon dropped from 20+% market share to below 1% in a year or so in China. Observe also the Qihoo/360 browser, with not much front end innovation, zooming from 0 to 20% in the same time frame.
Deep platform innovations can be sticky, and in our experience, they move the web forward for everyone. JS performance is one example. Extending the web to include device APIs held back for privileged native app stacks is another. So long as these platform innovations are standards-based and standardized, with multiple and open source implementations interoperating, and the user owns vendor-independent assets, then “quality of implementation and innovation” stickiness is not objectionable in my view.
Back to Mozilla. We don’t have the distribution power on desktop of our competitors, yet we are doing well and poised to do even better. This is an amazing testimony to our users and the value to them of our mission and the products we build to uphold it. In addition to Firefox on the desktop, I believe that Firefox OS and Firefox for Android (especially as a web app runtime) will gain significant distribution on mobile over the next few years.
Take Heart
So take heart and persevere. It is sad to lose one of the few remaining independent web platforms, Presto, created by our co-founder of HTML5 and the unencumbered <video> element. I hope that Opera will keep fighting its good fight within WebKit. Opera fans are always welcome in Mozilla’s community, at all levels of contribution (standards, hacking, engagement).
We don’t know the future, but as Sarah Connor carved, “No fate but what we make.” Whatever happens, Mozilla endures.
/be
Other voices:
I hope Mozilla will feel the heat and pour more resource in Firefox. Which is severely lacking behind in performance. Especially UI snappiness. All the OMT works and SuperSnappy, ( I heard recently that even SuperSnappy is stopped and going back to e10s again ) , are long overdue.
And to be honest a lot of Fans are putting up with these problems for years just because we trust Mozilla’s value and your commitment to improve.
“to avoid depending on an engine that an incredibly well-funded and lock-in-prone competitor dominates, namely WebKit”
It’s worth pointing out that anyone depending on WebKit always has the option to fork the engine if they feel the current owners aren’t leading the project in the right direction, leaving them free to innovate at their own pace (subject to having the will and development resource).
I’m not suggesting Opera are about to create a fork, but I could see Chrome forking, if the Apple-Google relationship were to deteriorate.
Brendan,
I have a hard time believing your pledge to diversity given Mozilla’s non-support for Gecko embedding.
There’s a number of Gecko-based browsers, e.g. Camino, and you’ve left their users in the lurch by ending support for Gecko embedding. Mike Pinkerton has for years been voicing rightful criticism that Mozilla is focussing on Firefox and nothing else.
If you really want diversity, why hasn’t Mozilla made an effort to make Gecko attractive for embedding, thus providing an alternative to WebKit? Instead you’ve done the exact opposite.
thanks Brendan, wholeheartedly agree. Really looking forward to Firefox OS which I’ve contributed money towards.
Is there any thought towards how we might encourage diversity outside of the few very deep pocket companies with the resources to credibly implement the many complex standards backing the web platform? It seems like the cost of producing a competitive web browser has become high enough that the most we’re likely to see are WebKit or Gecko forks in part because there’s no way for someone like Opera to capture much of the benefit which the larger web community receives from another independent implementation.
It’s hard to imagine a startup, CS group, etc. with some neat ideas wanting to try building a new browser – and certainly not just to try something like a safer/more concurrent implementation language. This feels dangerous even though the current state of the open web is thriving.
But isn’t XUL too going to be phased out?
And what is the backstory to those China browser changes? I heard something about Qihoo’s 360 vs. QQ?
Chris Adams wrote:
“It seems like the cost of producing a competitive web browser has become high enough that the most we’re likely to see are WebKit or Gecko forks in part because there’s no way for someone like Opera to capture much of the benefit which the larger web community receives from another independent implementation.”
I don’t think this is a new problem. It took Mozilla four years from 1998 to release a production ready browser (Mozilla 1.0 / Netscape 7), and both Trident and WebKit were forks of existing browsers, despite being created by huge companies. Brendan’s probably to blame, for introducing the scripting that allowed websites to become as complex as they are today 😉
If we take it as a given that it’s too much work to create a brand new browser, is that a problem when two of the three major engines are open source and can be forked? This is where funding and market share are potentially more important than the code base that’s actually being used. The problem with IE6 was that there was a huge installed base of users tied to one vendor who had stopped development – that wouldn’t be the case even if Safari and Chrome had 45% of the market each.
Not only that Mozilla matters but it creates competition and out of that we get quality.
Brendan, I really appreciate the work that Mozilla has done in developing and inventing the web platform. I also appreciate the work done by Apple, Google, Opera and recently Adobe. Thank you for taking the time to develop standards and test suites (especially as most of us find writing code and building products much more fun ;)).
One of the things you mention about WebKit is its political situation. It’s true that some patches can be hard to land because they change core code to support a standard that doesn’t have buy in from one of the stakeholders. But I think this is a good sign — WebKit has grown rapidly and is experiencing some growing pains right now.
Mozilla doesn’t seem to have this conflict but doesn’t have any external stakeholders either. I am currently working on a (non public) WebKit port, and choosing WebKit over Gecko was easy:
1. WebKit has a bunch of external ports which are peers to apple-mac in ews (not breaking other’s ports etc) except recently in WK2. This is a big deal — it’s no fun being downstream of someone large who doesn’t care if their changes break you.
2. WebKit has fairly clean abstractions for plugging in your own graphics engine or compositor, so if you’re lucky you can generally only make changes in WebCore/platform and not touch the rest of it.
3. WebKit is well ported to different architectures and operating systems. I was able to get WebKit compiling and running on Android using the NDK (crystax originally, but now the Google one thanks in part to patches submitted by Mozilla) in 3 days; I was able to do this because others had already built it for weird and wonderful OSes and landed patches. Only Mozilla is porting Gecko nowadays.
4. WebKit has mature support for transforms, transitions and animations which Mozilla lacked when I made the choice.
To me WebKit feels much more like a “framework for building web-enabled things” whereas Mozilla feels (to me!) more like it’s complete assembled package and less of a pick-and-mix. This ought to confer an advantage for people who just want a webview in their product, but in practice most of those people use WebKit too (and some of the previous users of Gecko, like the various GNOME Browsers, epiphany, etc, have switched to WebKit — at the time they said being downstream of Mozilla was tough; see point 1 above — couldn’t you have integrated an epiphany test run into your process like WK has with EWS bots?).
Mozilla does have some great technologies that I’m jealous of when working on WebKit; DLBI for example. But you’d have a better chance at addressing monoculture if you were to make Gecko a more appealing choice for embedders and hackers. The work that goes into Mozilla is almost all bought and paid for by the Mozilla Foundation, and that’s smaller and more focussed than the WebKit ecosystem (thus missing some interesting edge uses that might become mainstream one day, such as phones [why wasn’t MicroB integrated — Moz could have been everyone’s first choice after iPhone Safari came out?]).
I really want Mozilla to succeed and thrive. I believe a plurality of engines is essential for the health of the web. I wish you’d made it easier for “ports” 5 years ago. I think Mozilla would “matter” a lot more if it was essential to a lot of people’s software the way that WebKit has become (in my opinion by being more friendly to ports).
(Apologies if this comes off as a rant on Mozilla; I really like Mozilla and appreciate the mission, and should I ever tire of startup land it’s the first place I’d look for work).
Ed: Snappy and MemShrink have made good progress, but you are right: desktop needs OMTC/A and more.
So yes, a more careful E10S-redux project is going, and the OMTC/GPU stuff we had to do kind of “pirate-ship” style on B2G, which finally made it to Android last year, must come to desktop — and soon. Total agreement. I’m now in charge of engineering, so I get blame if this does not come to pass this year.
Ian: forking is an option, and different versions of WebKit see wide distribution via disjoint channels already, but as roc pointed out, there’s a heavy anti-forking incentive too. We shall see. In many respects, chromium is an active and costly downstream fork, which Google can well afford to subsidize.
Lukas: you’re right, we failed at embedding, going back to AOL days. Given our urgent priorities and small size, I doubt we’d succeed with Gecko starting now, even if we had the resources. But the good news is that Servo is embeddable from the get-go.
/be
Chris: the cost of producing a browser has been high for a while. In the U.S. v. Microsoft case, IIRC, it came out that MSFT spent $1B on IE. Not all was engineering, of course, but many heads were involved for years.
The Web is a complex evolving system. Path dependencies make lock-in and winner-take-80%-to-all effects.
Standardization helps, though. Part of the motivation for HTML5 back at that pub in 2004 was to write down all of the quirks, so someone could more easily build a browser from scratch. We are not done yet!
I do think a dedicated and hacker-talented research team at a University could clean-room a lot of a new browser implementation. Perhaps this is already happening?
Brenno: XUL is not going to be phased out of desktop Firefox, as far as I know!
On China, I heard the same thing. Uninstall wars, propagation via malware including a faked Windows Update, Google and Baidu SERP scraping and advertiser poaching, conversion of malware-propagated browser installed base into distributed search-engine indexer. Wild.
Randallu: thanks for the comment, I think you are mostly right. However, the WebKit OMTC/Animations/Transforms stuff was a mix of open source at webkit.org and closed source behind apple.com firewalls. On Android 2.3 (Gingerbread) a lot of this stuff works incorrectly, slowly, or not at all.
Chrome coming to ICS helped, but for a long while the “batteries not included” nature of WebKit meant anyone wanting 60fps smooth animations and touch-scrolling, etc., needed to do it themselves. We did this work in Gecko for B2G.
/be
Quick!
Hire all those senior opera developers and throw them at servo
Perhaps this is only tangentially relevant to this post, but I’m curious about why people would consider Android a fiefdom like iOS. The source code is available, and on every Android device I’m aware of, users have the choice to install apps from sources other than the Play Store, in contrast to iOS.
True, new functionality can only land in official Android if it gets approval from Google. But the Android SDK and NDK give application developers the freedom to do nearly anything they want; Firefox for Android is evidence of this. Contrast this with the Web platform, where in practice, new functionality requires buy-in from multiple competing vendors, and there isn’t an escape hatch akin to Android’s NDK.
I, for one, would accept Android as the de-facto application platform of the future.
Randallu, most of the performance improvements were integrated into core gecko. Some of the same people that worked on MicroB are continuing to work on a similar embedding solution which you can find here:
https://wiki.mozilla.org/Embedding/IPCLiteAPI
If you have questions about this API, please email me or Oleg.
Matt: my correspondent will have to speak for himself, but I agree with him that there is a fuedal aspect to Android. The source is “delayed open”, with privileged partners getting early access. The latest OHA requires Chrome as default browser, IINM. Perhaps most objectionable in making the user a serf, the out-of-box experience wants to sign the user up for everything in Google’s vertical silo, starting with identity.
Yes, Android is much more open than iOS. Contrast with Windows and its broad platform and many ISVs in the ’90s, compared to Apple as Jobs came back and tightened up the controls. Android is the new Windows, with delayed-open source and browser choice _a la_ Windows after the U.S. v. Microsoft consent decree — but still a lot of control.
Also, Android is fragmented, as Windows was in the ’90s and noughties.
Glad you like it, but I disagree that it’s the application platform of the future. No single-vendor system can be that. I say the Web is that platform. See https://asmjs.org/ for another nail in the proprietary single-vendor coffin.
/be
Wow, that was an essay (and bit of a treatise :).
I appreciate you covering the many bases so well and clearly.
I’m curious, is there a possibility that Presto might go open source? If so, might there be algorithms or code that could benefit Gecko?
Caspy7: @hsivonen wondered about Presto open source too. I’ll ask but my Opera contacts are disappearing.
/be
XUL is an albatross around Mozilla’s neck. I’ve heard Mozilla for more than a half decade say, “We can’t do that because of XUL” at every turn. I’ve never seen a quality, mainstream need for and implementation of XUL outside of the innumerable dependencies that Mozilla makes for itself. Yet even though it’s always the excuse, they never realize it’s the problem.
It’s also quite humorous hearing open source advocates contorting Webkit into a locked-in monoculture. “Monoculture is bad… and there’s actually at least eight major versions of it too!” Huh?
Tim: I’m a sucker for trolls who use half-truths as bait — makes for good “teaching moments”.
XUL is used for addons.mozilla.org, and more than 80% of our user base has at least one add-on installed. That’s a sticky win we value and go to great lengths to support.
Add-on authors appreciate this compared to the more restrictive extension model (now requiring Chrome Web Store hosting?!) in Chrome. Even Safari has extensions now, validating the thesis that they add user value and declutter the stock UX.
BTW, *everything* along an evolutionary path can become an albatross: JS, CSS, HTML. XUL is in some ways the least of it. We have to keep evolving, improving what works, isolating what didn’t (note past tense) so it can fall into disuse.
The big parts of XUL including flexible box CSS layout and XBL (Web Components) are being standardized now, so in critical ways in which we need XUL now, we need it less or not at all in the future.
In that future, everyone wins cross-browser — both add-on and web devs — by virtue of the standardization of “XUL, the good parts” into the web platform. This leads directly to the next point.
With Servo there’s no XUL, but there will be new add-on models that win on multicore devices. Then we’ll start all over again ;-).
Your last paragraph shows poor reading comprehension on an unrelated point — try reading again.
Eight build systems signify polyculture where not wanted, due to fragmentation and less than ideal governance. I’m sure WebKit leaders can fix this, but it buttresses my points about lack of “One WebKit” and “many cooks”.
/be
Caspy7: Presto might get its source released, but at the moment all effort is on getting WebKit-based products to market.
Tim: We rewrote the Android version of Firefox without XUL because we could not get the performanc we needed with a XUL front end. But we did that without sacrificing the browser extensibility, so we still have add-ons on Android – there is some porting to do for those that have a UI, but that was needed in general when adapting desktop add-ons to run on mobile.
Shorter term than Servo, we also need to devise a way to provide extensibility for b2g/Firefox OS in a webby way, but that’s a slightly different topic…
Brendan I am going to ask a ignorance question, Would asm.js help to speed up PDF.js, which is current quite slow compared to native version.
And since so many parts of Firefox Browser is based on JS, would asm.js help with that as well?
As a sysadmin at a large university, a browser is a commodity. I’m looking at removing Firefox and leaving IE as the only browser in our classrooms, because Firefox has never addressed the issues of enterprise deployment and control. When I upgrade FireFox (one of the harder products) do all of the dozen users per day on each computer really need to be told that they have a new version, or click through the ‘help mozilla improve’ stuff? Come on! They’ve had this product for years. don’t get me started on the ESR branch.
Ed: asm.js and its OdinMonkey JIT could indeed help parts of PDF.js (e.g., JPEG2000) but without profiling the slow case(s) you see, no point in guessing. I am rallying troops to profile again (and hackers should Always Be Profiling).
Rex: IBM folks didn’t patch this problem long ago? Checking…
/be
Two points.
+ About XUL. I really like this technology, when it came out it was ahead of its time. Shame it never really got on by other platforms.
– WebSQL. Mozilla’s stubborn failure to try to support despite developer’s voicing support for this. Ignore the developers and users at your own peril. Hard to see how you really claim to support open standards in this regard.
Ivan: two replies:
* XUL is going into standards, see my comment above: CSS flexible box layout, Web Components (XBL2, based on XUL’s XBL).
That’s how we roll in general. XUL as desktop toolkit tech (overlays, fastload, etc.) of less interest to other browsers.
* WebSQL failed in the w3c. Microsoft was obdurate. Mozilla should not have jumped in line for punches from monoculture fans, though. The fact remains that SQLite C code as “spec” is a terrible idea, no one was going to reverse-engineer it into an abstracted specification.
IndexedDB has issues but it is open-spec with multiple interoperable implementations, which is relevant to this post.
/be
Thanks for replying Brendan and Doug. Yes, the compositor implementations have been hairy in WebKit (I’ve done a couple myself, and since a good one requires a whole asynchronous tiler it’s a huge chunk of work — however Chromium definitely went out of their way to have a hard time of it [no compositor, bad WebCore-based one with lots of junk in WebKit, better WebCore-based one still with WebKit mess, pull it out of WebCore entirely with mess and hooks in WebKit…]).
The IPCLiteAPI looks fine though shadow layers can be tricky — the TexMap/CoordinatedGraphics code in WebKit2 has gone through a couple of iterations on this, dealing with tricky stuff like running animations in the UIProcess and correctly handling their interruption/other layer-tree updates from WebProcess.
(Also, I’m glad WebSQL died; it was a terrible API that required too much code to do basic things. IDB is much better and more straightforward to implement).
asm.js looks really interesting. You said you might be doing something in this area way back in 2009 on es-discuss:
https://mail.mozilla.org/pipermail/es-discuss/2009-June/009559.html
As a response to something I raised:
…ecmascript in the tracemonkey, v8 and nitro generates
x86/ARM code. Maybe there could be a ecmascript subset which generates fast machine code for algorithmic intensive code. ie ignores global object and prototype and is maybe typed.
And:
‘performance modules’ which would be written in and parsed as a subset
of ES which is *extremely sympathetic to the machine code generating
infrastructure* of the ecmascript engines and thus generates efficient
machine code. Without being to closely tied to (specific)
implementations.
https://mail.mozilla.org/pipermail/es-discuss/2009-June/009558.html
https://mail.mozilla.org/pipermail/es-discuss/2009-June/009547.html
Please could you write a blog post about firefox OS update mechanism please? Will there be an exe that we can run with phone connected via usb and update to the stock firefox o.s (non-branded) so we can get updates for as long as you make them for our specific hardware? Or will we be stock in the same situation as android whereby we have to hope that our carrier releases an update? Or maybe you release an update that doesn’t alter any branding so that we can get the latest updates without any custom network changes being lost?
I assume major updates would have newer faster javascript engine updates and gecko updates which would presumably make the phone a little faster with each update?
another thing, what are your plans with the kernel? Will you be using the kernel from android 4.2.2? Will you be using the latest version of the kernel with each new release or will you fork it and create your own modified version?
I’m pretty sure that android o.s or the kernel has backdoors in it for govts to spy on you. I’m not sure if you are legally allowed to remove those and sell phones in u.s and u.k without backdoors, what are your thoughts on this?
P.S have you any plans to allow firefox browser users to encrypt their saved passwords instead of having them plaintext, it would be nice if there was a checkbox to encrypt them with a password.