There's a number of Gecko-based browsers, e.g. Camino, and they've left their users in the lurch by ending support for Gecko embedding: http://caminobrowser.org/blog/2011/#mozembedding
Mike Pinkerton has for years been voicing rightful criticism that Mozilla is focussing on Firefox and nothing else, see e.g. this interview of 2006: http://mozillamemory.org/detailview.php?id=7277
If Mozilla really wants diversity, why haven't they made an effort to make Gecko attractive for embedding, thus providing an alternative to WebKit? Instead they've done the exact opposite.
I think Mozilla's announcement makes their reasoning fairly clear:
My summary is:
- The old embedding infrastructure was difficult to use and expensive to maintain
- It was also a technical dead end
- Better embedding infrastructure depended on complex architectural changes to Firefox
- Firefox is Mozilla's bread-and-butter, in terms of visibility, influence and revenue
- Mozilla has ambitious goals and does not have infinite resources
Forget for a moment that we're talking about Mozilla, Firefox and Gecko embedding. In a different context, what would you do?
It's not clear to me that FireFox OS has done anything for Mozilla's mission. Indeed, the Firefox OS home page seems to indicate Firefox's goal is to provide carriers and OEMs with an alternative to Android, and help them maintain customer relationships. WTF? Open source vendor lockin?
I mean come on, Firefox isn't even distributed in 64-bit as an official option. It's really on it's last legs waiting for the next gust to carry it.
Oh and that http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/lates...
Frankly I think the Mozilla folks learned the wrong lesson from this, but they did learn something.
I agree that Mozilla should start supporting it officially. Especially after they decided to kill mobile XUL Fennec off: https://bugzilla.mozilla.org/show_bug.cgi?id=831236
With official Mozilla being too engrossed in Android, this remains the only alternative for normal mobile Linux to use Gecko.
The part about there not really being "One Webkit" is the bit that stuck out for me since it seems (warning: generalization ahead) most outsiders (even web-developers based on articles and comments I have observed on HN) do believe that Webkit is mostly one engine worked on by one basically happy family of corporate sponsors.
"To make an apple pie from scratch, you must first create the universe." - Carl Sagan
And then Mozilla became very inimical towards the idea of implementing forward looking things, and giving ideas a chance to win or lose in the "marketplace" (not a perfect metaphor, but whatever). Remember the debacle over mng support? The argument basically reduced to "nobody's using it" at a time when no browsers supported it. And nobody was going to use it, until some browser(s) did support it. But IE didn't, and IE was the target. Oh yeah, there was some argument about the size of the code, etc., yada yada, but even when the developers reduced the size of the mng code dramatically, it was still rejected.
Mozilla leadership never seemed willing to try and lead and expect IE to begin to see Firefox as the target. XForms? Mozilla absolutely should have implemented XForms properly. The one place they did actually get "ahead of the curve" a bit was SVG, and - while still hardly dominant - SVG has finally made into IE.
Honestly, while Firefox is a great product in many ways (I'm using it to compose this post) I think it has fallen short of what it could be, and one reason for that - IMO - is an overly dogmatic, top-heavy leadership model and lack of willingness to incorporate feedback from the larger OSS community.
Mozilla has shown little interest in leading in terms of browser innovation, from what I've seen. Of course, the argument now has probably changed from "IE doesn't do that" to "Chrome doesn't do that", but whatever...
Edit: Also, just to be clear... I'm not saying Mozilla never do anything innovative. They were, for example, one of the first, if not the first, browsers to support MathML. They were also early to the SVG party. I just think they fell short of what they could have been, if they'd been more aggressive towards incorporating new things. shrug
I'm very sad that not only Flash 11 but also Silverlight and Unity Web Player are all doomed by the enthusiasm of the "open" standards. Therefore, I feel that current Mozilla is full of hypocrisy.
And Mozilla, you must implement the Web Audio API ASAP. Without this, all interactive "HTML5" demos with audio will be developed only for WebKit browsers. "We innovate early, often"? I don't think so.
Plugins are each a monoculture. Flash, Silverlight, etc. - these are not multiple implementations of the same standard (like WebKit and Gecko are). Plugins are each a single implementation of non-standard.
> And Firefox OS should allow users to install browsers other than Firefox.
Firefox OS is really just the Firefox browser and minimal stuff around it to make it run. I'm not sure I see the point of allowing installation of another OS from it (replacing firefox there means replacing basically everything).
> I'm very sad that not only Flash 11 but also Silverlight and Unity Web Player are all doomed by the enthusiasm of the "open" standards.
None of those are doomed, except for Silverlight which Microsoft decided to discontinue. And the thing that is dooming Flash is not open standards, but iOS which did not allow it to run, which eventually made Flash irrelevant on mobile.
> And Mozilla, you must implement the Web Audio API ASAP.
Of course, work on this is well underway. You can follow here,
So I think there's truth to NinjaWarrior's argument that plugins protect from monoculture.
But they are security risks and cause lots of problems for browsers, as well as the monoculture issue (I can't run Flash on linux anymore because they decided to deprecate the flash linux NPAPI plugin).
So I don't think browsers should promote them. But native apps are still fine for them - Unity is flourishing especially on mobile, far more than on desktop browsers; Unity ships native apps on mobile.
And about "We innovate early, often", keep in mind that we had a counter-proposal to the Web Audio API, that we implemented. The W3C has chosen Google's instead of ours, and I believe that the fact we are late to implement this particular spec is quite normal.
Mozilla countered with another proposal, the Stream Processing API (https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProc...) but this was a bit too late.
Another advantage of the Google proposal was they had a spec and implementation from the start. The Mozilla proposal had a wiki page write up and an implementation and I don't think there was as much effort put into promoting it as Google did into theirs.
Granted, Silverlight was "open" in the sense that it had defined specs, but the specs were clearly written by a single company, and competing implementations would be at a significant disadvantage.
Allowing opaque plugins encourages weakly specified technologies with just one defacto implementation and leads to monocultures.
HTML5 games have been able to use <audio> to play sounds since before the Web Audio API existed, but Google never bothered to actually make it work right in Chrome. They were too busy coming up with their own thing.
Chrome was always the loser here; I won't speculate as to the reasons why, only state that for multiple versions, playing simple sound effects with Audio instances had severe latency, audio quality issues, and even crashes. Why wouldn't devs praise the Web Audio API if the only alternative was broken? I certainly was happy when I finally managed to get my HTML5 games to play audio in Chrome without crashing, but that doesn't mean the Web Audio API is well-designed or that it was a good idea for me to have to write Chrome-specific code just to play sound effects.
I'll acknowledge that Web Audio's design probably delivers better runtime performance in scenarios where you're playing dozens or hundreds of non-streaming sound effects, but I still question the motives of anyone who prioritized that over having basic support for audio working correctly.
EDIT: Because I forgot to mention this - I mean seriously, you put a method call in the Web Audio API that blocks the UI thread to synchronously decode audio? In 2012??? And didn't cover the documentation in 'don't use this' warnings?
Procedural audio is also effectively a corner case compared to the vast majority case, which is playing static sounds.
Practically nobody uses a browser, or any other product, only to "fight monoculture". It may be an honorable goal, but a product needs compelling advantages beyond that.
TreeStyle Tabs is basically my #1 reason why I'm sticking with Firefox.
Tree Style Tabs is, of course, one of the greatest things ever to happen to Firefox. It's on the list immediately after FireBug.
These days, I have been switching over to xmonad (and other simple window managers). Instead of using tabs inside of a browser, I use windows for each page. Next, I have a global key binding (C-o) that brings up windows as I type out tags which I can set with C-j. This way, I don't need tabs anymore, and I don't need impossibly long lists. I can just type the thing I want. C-o mdn, done. C-o google, done. C-o gmail, done. C-o irssi, yep.
I am still trying to figure out if this is better than constantly seeing a list of open tabs.
For browsers, I would need some kind of hierarchy support, though. A bit harder to do in a window manager, but then you'd have it for all kinds of applications. Maybe even combine it with some additional exposed information -- so without support you manager your hierarchy yourself, but if there's an easy way to get a buffer list, the top-level would be from the wm, and the second level from that list.
I would need some kind of display for a browser, though. I'm fine with on-demand buffer lists in editors (and actually turn off sidebars when I use Sublime), but for my browsing habits I'm better off with a list that's always visible.
Firefox's memory usage is a bit less predictable (and can get crazy, especially when you leave badly coded js websites open for days in a row) and there are more situations when you say to yourself "I'm leaking memory, I'd better restart", but Chrome memory usage grows faster when you open more tabs.
Plus, Chrome UI is less suited to many tabs: favicons stop appearing beyond around 30 tabs (for me, it's probably machine-dependent), and the omnibar doesn't give you a way to switch to already open tabs by default.
Plus, Chrome autoupdates aren't exactly optimized for low-end configs.
But even from Chrome's birth, Firefox was already using less memory with lots of tabs.
Firefox uses far less memory per tab, but still chugs down more memory with time. Chrome uses metric shit-tons of memory, but its multi-threading allows individually killing tabs (or just massacring them in bulk if necessary, which it is).
When memory's tight, Firefox seems to bog down as a whole, while Chrome gets boggy on individual pages (and you can kill/reload these as needed).
I find myself using both though I'll fairly routinely go through and kill off Chrome tabs, and periodically restart Firefox, to keep memory management reasonable.
Firefox's tab and state management is far superior to Chrome. Chrome plays better with some advanced sites (notably Google's own webpages, surprise, surprise).
Now I have a 32GB system so it's less of an issue, but Chrome is still seriously a memory hog.
In comparison, I know several people who regularly have more than 500 tabs open in Firefox -- 1200 is the highest number I've heard, though not all of these were loaded at once thanks to Firefox's "Don't load tabs until selected" option.
I'm really curious, why would one do that?
Personally, I find I never need more than ~10 for the task at hand. Also, if I ever DO have more than that open, the titles get too small to read and I start forgetting what I have. I either go flipping through all of them to find one, or I just give up and open a duplicate tab, making the problem worse.
Instead, if I want to look at something later, I usually tag it in Pinboard. Later, I can scroll down through a readable list of things I've recently bookmarked, or if I vaguely remember it, I can search by tags or text to find it.
Given this, I can't see a reason to have so many tabs open. Can you explain why you like to work that way?
I've tried using all manner of sites like Pinboard, but none of them work as I like. I want a one-click bookmark button where I don't have to tag anything. Maybe I should finally get around to building the bookmarking app I really want.
Pinboard has several different bookmarklets you can use. One of them is a single-click one that tags the page as "read later".
With some one-click extension.
Because I can do it without any slowness.
I'm one of the two Opera users.
Reading up on one alternative often leads to multiple links which I can either read one an one, return from, figure out what is the next link, follow that, maybe recurse another level then step back etc. To me this is cumbersome.
Instead of keeping this tree in my head I can just ctrl-click any interesting link, ctrl-tab to the next tab when I'm finished with the current one and continue ctrl-clicking.
Finishing up I can even use the save tab set feature of pinboard to stash it all away under a nice label.
But reading the entry, it is actually rather good reasoning for why Mozilla won't switch to WebKit. I am not sure WebKit-dev really needs more companies telling them what to do. Or fight over what to be done.
While others may disagree, I consider XUL a compelling advantage over the alternatives, because I can modify my browser to my liking, without writing my own browser from scratch.
I am not trying to be conservative, but I like the way Firefox does things. Yes, there are issues, it is hardly perfect (I use Chromium to watch Flash and use Java at home, because I fear Firefox's heavy memory footprint).
And Firefox's desktop share has remained rather stable the past year, along with Chrome's share.
 Although, in fairness, I do usually have over 100 tabs open.
OP is not arguing people should be using Firefox or other Mozilla products to "fight monoculture". OP is arguing that in order to deliver browsers (and other products) with compelling advantages in a way that advances Mozilla's mission, Mozilla needs to maintain their own rendering engine(s).
I'm talking about stuff like getting rid of the traditional menu bar and status bar, hiding the protocol in the URL input field, support for SPDY, the new tab page, silent updates, the built-in PDF viewer of the upcoming Firefox 19, and forth.
Meanwhile, we've also seen them spinning their wheels with failed me-too initiatives like Firefox for Mobile and Firefox OS, rather than producing any true innovation.
Ever since Firefox 4, all that Mozilla has managed to deliver is the Chrome experience, but in a less-effective manner. It makes perfect sense why people are leaving Firefox for Chrome; they'll get a nearly identical UI in Chrome, but they'll get new features sooner, and with better performance.
What you seem to be completely ignoring is the proposal of a WebAPI standard that allows web applications to access hardware and OS features and how this enables a vendor-neutral app ecosystem that doesn't have to answer to Apple or Google. This is way more important than hiding the protocol in the URL.
Firefox for Desktop, Firefox for Android and Firefox OS are a combination that will soon allow you to have the freedom of the web (aka cross-platform apps that doesn't require permission from your vendor to exist) on all your devices.
This is not only innovation but this is fighting for a web that belongs to the users and not an ecosystem where the user is the product being sold.
Have you ever considered why Firefox for Desktop appears to evolve in a slower pace than Chrome or Safari? Its because of standards. Mozilla works in the open, heck, you can have access to all the steps of production of a Firefox feature and Mozilla strives to make things standard in the W3C or whatever standard organization deals with that feature while Safari and Chrome will often implement things and not care about interoperability. They can do this because they are the spear point of two companies, named Apple and Google that have their own objectives. As companies, they need to differentiate from the competition and thus need to evolve fast. The choice of evolving fast and differentiating alone or working together in cooperation between companies and committees is this gap you see in browser evolution. I'd rather have standard W3C backed WebAPI and Firefox than WebKit features that do not work on Gecko and Trident and whatever engine launches in the future.
Different from you, I see Mozilla as really innovative because fighting for users and a free standard web is an innovation in these days of vendor lock-in and "I have this feature, you don't".
and here's me thinking it was because Firefox and Gecko consist of 20M lines completely unmaintainable, crufty C++!
How many lines is WebKit? And how crufty or maintainable? ;)
How is a me-too ChromevOS clone innovative?
The reason so many non-techies are using Chrome is that Google has a much stronger brand presence than Mozilla and has, at least in the UK, spent a fortune on advertising.
I love both of these browsers for different reasons. Please don't claim they're the same just for the sake of making a point.
could you explain what these changes are and how they're noticeable to the general public?
I'm a developer who's written a Comet webapp you've likely used or at least seen, and I have yet to notice...
Observing the activity on interesting support tickets, I believe that Firefox designers/developers have generally been far more responsive to user requests than have the Chrome designers/developers.
I think those are the two reasons why Firefox is so important: It is a true community project, and it is a browser suitable for power users.
Mozilla can only survive if a sizable percentage of end users perceive Firefox as the best browser for them, and this usually means that Firefox needs to provide the best user experience.
Personally I think that other browsers currently provide a better user experience, and I see a lot of people around me switching from FF to Chrome. The reason for that is not Webkit , but Firefox's user interface.
In the end only the product matters.
So its not just monoculture. It's also Mozilla's wast ecosystem of customization and the good will it's projects generate.
Look at it this way - Did Chrome made/sponsor PDF reader in JS? Did it sponsor a Flash VM in JS? Did Google Chrome team made tools other than would help all vendors equally? Dart and NaCl are valiant efforts but they help Chrome first and other browsers second.
he didn't imply it was bad, just that no one in this environment is going to switch to or stick with Firefox just to fight monoculture.
If we want that to change – particularly for ambitious projects like major security or parallelism improvements – it seems like there has to be some way to bring the scale back to the level where a small group can effectively enter the field.
So there is no "at that point" decision. Firefox+Gecko codebase is here to stay for a few years.
Well, no. The whole "Thoughts on WebKit" section of the article spells out problems with WebKit that do not exist in Mozilla-land; most people would call that criticizing.
Which is perfectly fine (how would you write this article without critically comparing the different projects), but please be honest about it and spell it out.
PNaCL doesn't exist yet, so there is nothing to push.
Dart is a much more interesting question.
If you want to produce an alternative, there's no chance of it being accepted.
Imagine this sort of total language myopia in any other general purpose platform.
Get your tums out, pal. We're taking PNaCl down for good this year with http://asmjs.org/. Cross-browser.
No, you've simply held back the only other entity interested in making the web a viable app platform:
- MS and Apple, and Google's behavior are aligned with their corporate incentives.
- In theory, Mozilla's behavior ought to be aligned with the interests of the web at large, but in practice, Mozilla is aligned with you, and your behavior is aligned with your own personal interest in a web platform monoculture based on your technology.
Mozilla and Google, in concert, have the ability to make it a market necessity for Apple and Microsoft to follow suit. Google alone does not.
This makes you the lynchpin at an organization that in theory was created for the very purpose of advancing the interests of the web.
> Get your tums out, pal. We're taking PNaCl down for good this year with http://asmjs.org/. Cross-browser
It takes a True Believer to abandon decades of research, ignore repeated market successes (in the application platform space) that vastly surpass anything they've produced, and then continue to myopically push their own invention into areas where it simply does not belong.
This is death by a thousand cuts.
It is actually quite easy to implement asm.js; you just carve a "native mode" out of the VM infrastructure that already exists. Much easier than inventing a full-stack VM from scratch.
And no, it's not a robust application development platform. Working with it is an exercise in constant compromise between bad technologies and the quality of the user experience.
You're smoking something too, if you're equating the content-centric web with the breadth and depth of the market of native mobile and desktop apps.
Of course, I also get a better experience from the NYTimes mobile app; it's simply that the web can do content less badly than it can do apps.
The myopia of the web crowd is why your platform continues to suck.
I'm surprised you find that approach controversial. Have you not seen the awesomesauce that Re2 and PyPy bring to the table by defining strict subsets of PCRE and Python, respectively?
Which is precisely what the Mozilla Emscripten project does.
[high level language] -> [low level representation] -> [high level language] -> [low level representation] -> [execution]
This is ridiculous to aim for as your first-order target.
Yes, but Mozilla still needs to be convinced that the new technology makes sense for the web. Mozilla collaborates with Google on lots of new things for the web (WebRTC, see recentl HN stories on interoperability between Chrome and Firefox there, Web Intents, etc. etc.), but it does disagree on NaCl for example.
Breakdown of low-level targets:
Google: Native, NaCL, PNaCL, Dalvik
Apple: Native, LLVM (eg, for OpenGL feature emulation).
MS: Native, CLR
Oracle: JVM, Native
Maybe Mozilla dislikes NaCL because there's actually a lot wrong with it?
Eich is the CTO and sets the technical direction for one of the four major browsers. The browsers can only move forward standards in cooperative with one another.
This isn't a fantasy world.
> Maybe Mozilla dislikes NaCL because there's actually a lot wrong with it?
To me the choice is between more convenient encoding format for the bytecode and backwards compatibility with all browsers, and going with the latter sounds eminently reasonable to me. The x86 bytecode encoding is really ugly too (look at those one-byte-long binary coded decimal instructions), but the survival characteristics of backwards compatibility are undisputed...
A better technical solution and lower development friction throughout the entire stack. The hackiness of the web already introduces an enormous amount of cumulative friction, and asm.js just adds more.
In the same period of time, entirely new and proprietary mobile platforms have emerged and eaten a huge portion of the application market's mindshare and marketshare.
Perhaps it's time to stop listening to someone who can't think outside his own box, and instead choose a technology that is actually well-suited to the problemspace.
> To me the choice is between more convenient encoding format for the bytecode and backwards compatibility with all browsers ...
That could be achieved by generating JS from the bytecode, which would turn the problem into a temporary one that disappears as browsers are updated, instead of yet another time and resource draining wart on the web platform.
I would love to be able to target the web instead of proprietary platforms, but the technology stack isn't there and won't be as long as people like Eich are running the show, and remain fixated on what worked for web documents as the solution for what will work the future of web apps.
Going with a worse-is-better solution for the purposes of backwards compatibility is always an admission of defeat. But it's a very practical one. It's an admission of defeat that has made Intel and Microsoft billions, for example.
"That could be achieved by generating JS from the bytecode, which would turn the problem into a temporary one that disappears as browsers are updated, instead of yet another time and resource draining wart on the web platform."
And then Web developers have to ship two binaries. Foisting the problem of backwards compatibility onto Web developers for the sake of making a nicer bytecode parser doesn't seem like a win to me.
Do you think a systems/application developer, who believes in those ideas, would choose to work at, or be a part of, Mozilla, given Eich's clear and verbose positions that stand entirely apart from decades of success shipping consumer applications for desktop and now mobile devices?
As someone who writes consumer applications, I want a common application platform, but I'm not going to sacrifice my tooling, work quality, or user experience to contribute to a fundamentally flawed approach, just because it's "open".
NaCl and Dart were both created in a Dart room without anyone else's input.
Google at least understands the flaws. Web developers seem to have their head in the sand while mobile may very well eat their lunch.
Mozilla is not a dictatorship - it's a nonprofit open source project. Obviously Brenden is a pivotal figure but people have many opinions on many topics, just read the mozilla mailings lists (which are public).
On this topic, AFAICT the great majority agree with Brendan.
I'm just not interested in continuing to try fit the square peg of DOM/CSS/JS into the round hole being an application platform. It has been made clear from Brendan (for at least half a decade now, if memory serves) that this is what they're doing and will continue to do.
In the meantime, iOS and Android appeared from nowhere and turned the engineering departments of many companies -- most of which were previously focused solely on server+web -- on their head.
At the same time, Google can barely give Chrome Books away. This must tell you something about the efficacy of these strategies.
NaCl actually offers crappier APIs than the Web platform, and it runs in a box where it can't directly manipulate the real Web APIs. asm.js is intriguing because it offers a very natural path to a foreign function interface to all the stuff exposed to JS.
They also provide great battery life and user-visible performance (iOS especially), have incredibly well integrated development tools (see Apple's Instruments and its power, CPU, syscall, et al profiling), and give software authors the escape hatches they need to maximize performance when absolutely necessary.
With all that in place, then I'd use whatever reasonable (JS isn't) language existed as a norm on the platform to write applications to target the browser, instead of Android, iOS, and Max OS X.
My only allegiances are to user experience and the quality tooling necessary to ensure it. The web as-is provides neither.
You assert this, but you haven't provided evidence. Web application developers are providing great user experiences. What tools do you need to provide a good user experience that the web as it is now doesn't have?
Are you serious, or are you really just that out of touch with how we work on desktop and mobile apps?
> What tools do you need to provide a good user experience that the web as it is now doesn't have?
- Performance, performance, performance, performance.
- The ability to use the right language for the job. The right language isn't the right language if the performance is pot, so no, Emscripten isn't a solution. I'm talking about everything from exposing SIMD intrinsics when writing time-critical software to languages that actually support compiler-checked type-safety.
- Standard library which provides the functionality necessary to conform with platform exceptions and integrate with the platform.
- Tools. Debuggers, compilers, and most especially, profilers and deep instrumentation.
- Platform integration. This isn't just "cameras". It's also the iTunes/Media query APIs, in-app purchase, airplay, spotlight plugins, quickview plugins, menu items, and the mountain of other things that platform vendors implement to provide an integrated and coherent experience. Platform vendors push forward the user experience by providing richer platforms. Web vendors don't.
- Unification of code, UI, and styling. The DOM has to go, as does CSS and JS as separate entities. It's a ridiculous model for UI development and it makes producing genuinely re-usable and interoperable component toolkits very difficult.
I could probably go on all day. I WANT a non-proprietary, open, standardized application platform, but I need a platform that lets me provide the best available experience to end-users, and the web isn't it. I'm writing my software for my customers, and choosing technology over user-experience doesn't do my customers any favors.
It seems to me, on reflection, that I have been playing the role of religious apologist, while you have been the skeptic. This is ironic, because I have been in the opposite sitaution with regard to my former real religion for the past couple of years.
It seems to me that Android is the closest thing we have to a non-proprietary application platform, and even that is more tightly controlled by one company than we might like.
For now, I guess the best approach to writing great apps is to write the UI-independent core in a reasonable cross-platform language, and then use each platform's native UI constructs. iOS makes this difficult for any language higher-level than Objective-C, since there can be no JIT compilation for iOS. But I'm thinking now that C# might be a reasonable cross-platform language, given Xamarin's work on Mono for mobile platforms.
How does separating UI styling from UI construction code make creating reusable components more tricky exactly ? Other points might be close-ish to the mark but this one seems way off.
> Are you serious, or are you really just that out of touch with how we work on desktop and mobile apps?
It seems to me that while mainstream desktop and mobile platforms have been mediocre in their various ways, none has forced mediocrity upon the application developer as much as the Web platform.
> - The ability to use the right language for the job. The right language isn't the right language if the performance is pot, so no, Emscripten isn't a solution. I'm talking about everything from exposing SIMD intrinsics when writing time-critical software to languages that actually support compiler-checked type-safety.
When I was defending Mozilla and the Web platform, my response (in true quasi-religious fashion) would have been to keep having faith in the almighty tracing JIT compiler. But I was reading yesterday about tracing JIT compilers, and I noticed that they need guards around loads and stores in case the inputs to a particular invocation of a trace are of different types than the types for which the trace was compiled. You're right to point out that compile-time type safety has some performance benefit. For truly performance-critical code, asm.js does provide for static type checking and AOT compilation. Still, we have yet to see how many browser makers will implement these things.
Yes! Yes! I most emphatically agree with this point. It seems to me that modern web application UIs are still a free-for-all, with many app and toolkit developers defining their own widgets as they see fit. In contrast to the Apple platforms, GNOME, and even Windows IIRC, there's no set of human interface guidelines for the Web platform.
> - Platform integration. This isn't just "cameras". It's also the iTunes/Media query APIs, in-app purchase, airplay, spotlight plugins, quickview plugins, menu items, and the mountain of other things that platform vendors implement to provide an integrated and coherent experience. Platform vendors push forward the user experience by providing richer platforms. Web vendors don't.
Mozilla is introducing new APIs to expose more platform features, at least for Firefox OS and Firefox for Android. But that does little good for today's mobile application developers. And I guess it's a distinctive behavior of any "true believer" to have faith that promises will be fulfilled at some indeterminate future time, and encourage others to do the same.
> - Unification of code, UI, and styling. The DOM has to go, as does CSS and JS as separate entities. It's a ridiculous model for UI development and it makes producing genuinely re-usable and interoperable component toolkits very difficult.
I'm not quite convinced on this one. Reusable component toolkits do exist for the Web platform, so presumably most application developers don't have to do this very difficult work. Can you elaborate some more on what's wrong with the HTML/CSS/JS trio, or point me at an existing critique that you think is on target?
You also assume that Mozilla's insistence on the DOM and other existing standards, rather than PNaCl + Pepper, is unequivocally holding back the Web as an application platform. Let's drill down into specifics. What features do NaCl and Pepper provide that aren't (yet) covered by standardized APIs? My understanding was that Canvas and WebGL are helping a lot.
Finally, you may be unaware of some limitations in NaCl. Specifically, because of the way NaCl validates code, you can't run a JIT compiler on top of NaCl. So, if you thought that NaCl would be a better target for Java/Python/Ruby/pick your favorite than JS, think again. For good performance, you'd need something to compile your source language to something else anyway, either JS or LLVM bitcode. Might as well be JS.
I think I have demonstrated that Mozilla's insistence on JS and other standards is not holding back the Web as an application platform by any means. Indeed, none of the other major players you've mentioned, not even Google, is as serious about the Web -- the open Web -- as Mozilla.
I don't really believe that you have. As simple aggregate counter-evidence, I will point to the popularity, performance, consumer, and developer adoption of mobile platforms.
In the earlier days of Java, a common refrain was that the JVM could get better-than-native performance because it could make runtime decisions about JIT optimization. In reality, the complexity of performing this task generally outweighs the benefits compared to native code, and the JVM hasn't really succeeded outside of specific micro-optimizations. As a whole, the JVM is still slower than most native code.
Your argument seems to be predicated on a similar fallacy. The notion that since you can, in _theory_, optimize JS down to an efficient byte-code (or even AOT compile it), it is as good as an efficient and well-defined byte-code to begin with.
Yet, we have numerous historical examples of how adding more complexity between you and your intended target (eg, performance, versatility) doesn't help you achieve it. JS is an expensive and complicated intermediate.
This is equivalent to selling something at a loss and claiming you'll make it up in volume. You're adding complexity and challenge to an already challenging problem.
> You also assume that Mozilla's insistence on the DOM and other existing standards, rather than PNaCl + Pepper ...
Actually, NaCL and Pepper have nothing to do with the DOM argument. The DOM argument is just an example of where rigorious adherence to what worked for documents is not working for applications.
> Finally, you may be unaware of some limitations in NaCl. Specifically, because of the way NaCl validates code, you can't run a JIT compiler on top of NaCl. So, if you thought that NaCl would be a better target for Java/Python/Ruby/pick your favorite than JS, think again.
You are aware that Mono AOT compiles C#, correct? As does RubyMotion. JIT is not strictly necessary here.
This only implies that native mobile applications are more popular than mobile Web applications; it doesn't imply any particular reason why. At best, NaCl was still in the research phase when native mobile apps started to catch on, so Mozilla's refusal to get behind NaCl is irrelevant to the popularity of native mobile apps.
> In the earlier days of Java, a common refrain was that the JVM could get better-than-native performance because it could make runtime decisions about JIT optimization. In reality, the complexity of performing this task generally outweighs the benefits compared to native code, and the JVM hasn't really succeeded outside of specific micro-optimizations. As a whole, the JVM is still slower than most native code.
Are you arguing that for optimal performance, applications will always need to be distributed as native machine code? I will be disappointed if it turns out that they do, because that's how we get locked into proprietary platforms, at the CPU level if not at the OS level.
> You are aware that Mono AOT compiles C#, correct? As does RubyMotion. JIT is not strictly necessary here.
Yes, I was aware. Perhaps I overstated the importance of JIT compilation. However, I think we need more data. Some comparative benchmarks between RubyMotion (in the simulator) and a JIT-compiled Ruby (on the same Mac) would be relevant.
(Or did I, from my Throne of Skulls, send my T-1000 back in time to stop NaCl from being used by Apple on the first iPhone? Mwa-hah-hah!)
On Skatepark's planet it seems (a) Android (definitely a mobile platform, now the biggest one by users) has native-speed Dalvik apps; and (b) most developers write those in preference to hybrid or web-only apps.
Not so on Earth. Regarding (a), SpiderMonkey (and I'm pretty sure V8) beat Dalvik on same hardware on standard benchmarks. On (b), when last I checked over 70% of Google Play apps used embedded WebViews.
Only by reading "mobile" as "iOS" do the commenter from another planet's performance assertions even half-way hold up. The historical cause/effect claims just don't make sense (unless I do have backward time travel).
The JVM is a much higher-level bytecode than asm.js; asm.js is essentially just a JS encoding of LLVM. To name just one example, the JVM's memory model is composed of garbage-collected objects, while asm.js' memory model is a heap and stack as a linear array of bytes. There's a world of difference between the JVM intermediate language and the LLVM/asm.js intermediate language.
The idea that the LLVM intermediate language cannot be compiled into something as efficient as native code is trivially disproven by the fact that this is how clang works: it compiles to LLVM IR and then to native code.
"You are aware that Mono AOT compiles C#, correct? As does RubyMotion. JIT is not strictly necessary here."
Polymorphic inline caching, essential for performance of dynamic languages, requires self-modifying code.
This seems like a bit of a stretch; how do you encode an indirect branch in JS?
It's an interesting design space and I will be curious to watch the project evolve.
"Making it safe will require performance compromises, like guards on loads and stores."
Naturally, but this is also the case with NaCl or PNaCl, unless NaCl drops all of its software fault isolation techniques and starts relying solely on the OS sandbox. I suppose in theory one could compile asm.js in this way if it was really desired. The entry and exit points from asm.js to the DOM are fairly well defined, so in theory one could IPC them as well.
In reality, that goal was achieved ;-)
> You are aware that Mono AOT compiles C#, correct?
Java can be compiled straight to native code too. GCJ works like that for instance. The resulting performance from binaries of such compilers is abysmal though.
C# is not really a good example because C# was designed for AOT compilation. For example, most methods in the standard library are not polymorphic and methods in C# are final by default, whereas with Java it's the complete opposite, with methods being virtual by default. With all respect to Mono and Xamarin, it's hardly an epitome of performance.
Also, right now JRuby trumps in performance just about every other Ruby implementation available, including MRI, RubyMotion, Rubinius or IronRuby.
> JIT is not strictly necessary here
All known techniques for optimizing dynamic languages or runtime-polymorphic method dispatch require recompilation of code based on changing conditions.
This ... has not been my experience. And I write a lot of high-performance native and Java code.
> For dynamic languages, if you want decent performance, all the known techniques require JIT techniques.
* JS already has first-class access to the DOM -- the API that all the browsers already have -- as well as all the other up-and-coming APIs.
* There are already JS debuggers, and with source maps, these debuggers can even be made to work with other languages that can be compiled to JS. All JS developers benefit from this, as well as all developers who use languages that compile to JS.
So basically, JS has a head start over NaCl, Dart, or any other potential "clean" replacement.
As far as I can tell, your only objection then is that there's something aesthetically wrong with using a quirky high-level language as a compilation target for other languages. To that I can only say that worse is better. We might as well get on with the business of writing great apps with the tools we have.
So, I hope Firefox stays and I hope that the $1 billion Google gave them doesn't change their priorities.
Also remember that, initially, Firefox's Google contract expired without being renewed. Instead, the renewal came a few weeks later. At the time there was plenty of speculation that Google was letting Mozilla twist in the wind. Considering how much Google came back with, it certainly looks like any twisting went in the other direction.
(see: Apple and the rumored billions Google gives them for being the iOS search engine placement)
Yeah but Google is trying, hoping and praying to destroy Apple's 50-Billion-in-profit business.
Personally I was not happy since it makes it harder for any competing search engine and we sure do need competition.
Mozilla's board are accountable only to themselves. It's a personal playground and cash machine for Baker and Eich.
But so that there is no confusion on the part of readers who haven't been around the block, or around the valley, and therefore might be taken in by your libels, here's a personal testament:
You (byefruit) may be young, and/or not in my Silicon Valley job market. Look at my peers of around the same age as me. Many are independently wealthy. Those at executive or C-level (Chief of...) positions make similar salaries, not counting stock options from public companies which generally remunerate them to a much greater degree.
I'm not looking for a new job, but I get head-hunter contacts often enough. From the non-startups, the promised packages are as good or better in terms of salary. Doing a startup would mean a reduction in exchange for more founders' equity.
I have had invitations and targeted recruiting pitches from Google starting in 2002 and running up to this year. Had I gone in 2002, I would be set for life. I'm not independently wealthy, in spite of a decent salary for someone at my age and level.
Getting Firefox out, restarting JS standardization, helping build Mozilla, competing with Chrome, starting Mozilla Research (http://www.mozilla.org/research/), launching Firefox OS -- these add up to hard work, as hard as I've ever done save for the crazy Netscape days in 1995-6. This is especially true lately with lots of travel, which is not easy on my wife and small children.
Meanwhile, open source means living in a fishbowl, and Mozilla with its mission and people-first social movement roots means finding a business structure that doesn't loot our brand or screw volunteers by trying to cash out via an IPO or acquisition.
The structure that we chose was a U.S. 501(c)(3) Foundation, with IRS approval up front, but then with IRS reneging after a couple of years, followed by a fight to deny us our status and tax our early revenue that had been declared tax-free at the time by that same agency.
In the course of this "package audit", I had the joy of a personal IRS audit, which I passed cleanly (I defended myself). And Mozilla prevailed on the question of its public benefit status.
I don't live in Atherton or Palo Alto. I don't drive a fancy car. I'm in a house built in 1960 that was enlarged in the '70s but is modest by any standard (and very messy right now!).
So, do you really think I am just in this for the money?
This is not a boast, it doesn't make me great or even good. Like most who have some years of sustained work and credit/blame on their backs, I am little by myself. I'm much less than some truly great people who work for a good cause for no more, and often a lot less, than I make.
I am 100% sure that I could not persuade most of Mozilla's top talent of anything if I were merely an empty suit adding no value and sucking a big salary.
So it is just galling to hear your spin on thetruthaboutmozilla, which by the way seemed in that 2007 piece to say that I was worth every penny (not that I'm giving it any credence :-|).
If I'm right that Mozilla matters, then it matters no matter what I make or where I go. If I'm valuable to Mozilla, then my staying will help. I have to consider that too, in negotiating compensation.
"Know thyself" is as important now as it was at Delphi in ancient Greece. I'm not at Mozilla to make money. I'm here to make the web better for everyone, users, developers, your parents -- without having to face business-agenda or personal-financial conflicts of interest.
Aristotle and Jesus agreed on this point regarding money (Mammon) vs. "the good" (God): you can't serve two masters.
So, enough about me. Whom or what do you serve, and why?