Revisiting how we build Firefox
mail.mozilla.org
mail.mozilla.org
There are two high-level components which make up Firefox. The first is Gecko, the rendering engine. The second is Firefox, the application itself, which uses Gecko to render Web pages and itself.
Firefox, built on top of Gecko, is written primarily in XUL and XBL (and JS).
https://en.wikipedia.org/wiki/XUL https://en.wikipedia.org/wiki/XBL
What's going on here is that Mozilla is considering getting rid of XUL and XBL and building Firefox with the same technologies that people use to build Web content.
There are at least three big advantages to doing this:
1. Eliminate the need to support XUL and XBL in Gecko.
2. Contributing to Firefox gets easier because there is no need to learn what are essentially Mozilla-specific languages.
3. Mozilla learns more about what it takes to build complex applications like Firefox itself using Web technologies.
The only real downside is the amount of work involved.
That's not the primary driver of this plan. But it might be a happy side effect.
Servo is still in early stages, we aren't making product plans around it.
- currently browser.html runs on top of a gecko runtime (called graphene) which is based on the one we use for FirefoxOS.
- getting gecko to work on gonk is not different from adding support for other platforms like linux/mac/windows/android. Basically you need to provide implementation for low level windowing and input events. On non-posix systems there's a bit more to do in the nspr library, but that's not the case for gonk.
- we already have a port of servo that runs on gonk.
FirefoxOS has been using a 100% html UI since about 4 years, so it has been leading the way here.
Gecko and Firefox are quite intertwined. Even if we ignore XUL/XBL, there are things like XPCOM which are still deep-rooted. While this brings us a step closer to making Servo a drop-in for Gecko, this is not a step in a direction we're particularly interested in. At least not now, not that I know of (I'm a volunteer on the Servo team, as such there may be internal plans I'm not aware of).
For Servo one potential way ahead is bringing browser.html up to Firefox's level. Not the other way around :)
Improving performance is an explicit goal of this work.
Mozilla spends much more time optimizing HTML and other Web content tech than it does optimizing XUL and XBL. I wouldn't worry too much about this project slowing down Firefox. It might even speed it up a bit.
>Because XUL and XBL aren’t web technologies, they don’t get the same platform attention that HTML does (for good reason!). Performance problems go unfixed and it creates a lot of unnecessary complexity within Gecko. It’s harder for even experienced web developers to get up to speed. It’s further from the web, and that doesn’t help anybody.
In terms of performance -- there is no deep reason for it being slower, but of course the code might end up being a bit less optimized compared to stuff that has been battle-tested for 15 years. On the other hand, getting rid of XUL could deliver dramatic results. It's all speculation really, but there is no real technical reason for "XUL-less FF" to be incredibly slower than current offering.
https://github.com/mozilla/firefox-iosThis is a huge gap for Firefox IMO.
(Plugins need to just go away, and they mostly have.)
Can you explain to me why Firefox would be better off if I didn't have Rikaisama for my Japanese studying or one of a number of Youtube plugins that make the site bearable again by forcing annotations off and 1080p on.
Add-ons are brower extensions like the examples you provide.
Plug-ins are Flash, Silverlight, Unity Web Player, and the Java plug-in.
Only the going away of the latter is being called for.
This is most likely an addon, a Firefox extension written in (mostly) JS and XUL. Plugins are the external runtimes embedded in browsers with NSAPI &al: Flash, Java, Silverlight, etc...
Edit: eek, looks like it's been removed by the author :( https://addons.mozilla.org/EN-US/firefox/addon/youtube-disab...
Please share this miracle you speak of.
The advantages are numerous, so I can understand why they're going this route.
But Firefox devs have clearly spent a great deal of effort to make these faux-context menus look native. What an enormous waste of development energy to emulate what the platform already provides!
Rather than pushing forward with a layer that provides even less access to platform UI elements, I wish they would recommit themselves to keeping the native elements native.
I sometimes feel like I can sense when a UI is not native; it's completely useable, and I have no functional complaint, but it might just seem...off.
I felt a small bit of delight when I switched back to Firefox on my Windows machine and saw the snappy animations for new tabs and its menus. It made a kind of subconscious difference.
If you want to share the same code base you need to grantee the same functionality. The easiest and most predictable way is to run this through an intermediate and then render that intermediate. This is why compilers use intermediate representations like bytecode, you don't want to write a compiler that builds only x86 and then another when you need to build ARM. You don't want to write a rendering engine with different implementations for each widget kit.
Firefox has traditionally not been very popular on Mac for this very reason. They've gotten better at imitating OS X slightly, but even today it's still out of the question for me (and I suspect many Mac users) to use Firefox. It feels really awful to use. Whilst Chrome and Safari have nice native scrolling, rubber banding and smooth zooming, just like any other native app, Firefox feels jarring. It only just supports gestures (there's no nice animation like in Safari or Chrome).
My day-to-day browser is Safari. Not because it's faster or technically better (it really isn't) but because it's fully native and integrates properly with the system, e.g. it integrates properly with the downloads folder (showing the progress bar on the file and on the folder icon) and it looks and feels like any other Mac app. Chrome may be faster, Firefox may be more extensible - but I choose Safari because it works properly with the OS.
I really love Mozilla and I would love to use Firefox. I really hope they go with a OS-specific native shell - although I suspect they'll go with building the UI in HTML/CSS. But if they do, there's a good chance I'll switch.
> The correct thing to use is AppKit on OS X, WPF on Windows, GTK+ on Gnome, and Qt on KDE.
WHAT?! Personally, being asked to rewrite the UI for X different native platforms is rage-inducing.
Some people who write their apps in Web technologies have done native UIs and are sick of the duplicated effort. ;)
I really, really don't think that is the case.
(also, what happened to the edit link? "UKs" was obviously supposed to be "UIs" above.)
I think that the idea that somehow if the UI is written in web technologies that it's somehow lesser quality is a false dichotomy. Web developers and native developers can make UIs that look exactly the same to the point where they are indistinguishable.
You have 2 hours after posting to edit a ~~commit~~ comment. Not my favorite "feature."
My most-used GUI apps are Chrome, Visual Studio, Ableton Live, and Photoshop. All of them have heavily customized user interfaces. Their custom controls and tiling/layout systems are tailored to the application domain. Except for Chrome, these are "do your life's work" applications. They should aim for maximum productivity, even if it makes the application harder to use. I think they would suffer if they tried to "look native".
Most everything else is done in web apps these days. Users don't seem to have a problem dealing with different button CSS in different web apps.
Certain things, like the "open file" dialog, really suffer if they look non-native. But I think users don't care about most other cases.
As an aside, it's the no. 1 reason I don't use Atom: An ugly, slow UI that doesn't render native elements.
So no, it's not indefensible. I think your conspirator's OP comment "As a non-OSX user, I don't care about your UX" is more vain.
Sure it's vain. We all have personal priorities. People suggesting that Mozilla spend time developing the perfect OS X product are expressing their priorities as well.
I could say that I'm a BeOS user and I really think that Firefox should have a fully-integrated native UX because the way a product looks and works is important. But no one cares about BeOS UX because they're vain.
It looks like OS X users are the only ones who really care. Windows users have been dealing with non-standard UIs since tabs first stopped being MDI, and, comparing Chrome's adoption with how it looks, they're mostly fine with them. Linux users are mostly just straight-up crazy and Firefox is fine for them. Smartphone users have seen more non-standard than standard UIs and it doesn't seem to have been a problem for the Facebook app. The question is then is it worth caring as much about OS X UI, or is it more useful to make a better product for the 80+% of users who don't use OS X?
And, I'd argue, Firefox is far, far, far from "technically superior" on any number of axes, regardless.
User experience is important. Dismissing that aspect as "animations [that] aren't as nice" misses an important point - things like animation, consistency with the host system, integration with platform features and so on are really very important to the quality of an app.
Technical capability is also important, obviously. It's why I use Firefox and when building web projects on the Mac - best feature set. But I use Safari instead for day-to-day browsing, because of things like better scrolling and zooming, and better integration with platform services.
I do think the way a product looks and works is important, and developers who dismiss that are why we have so many awful UIs out in public.
I agree user experience is important, but experience is so much more than simple aesthetics.
I'm not saying they're totally unimportant, which is why I included the qualifying clause about "undue hardship", but I have no respect for users that will put themselves at a functional disadvantage so that their experience can be "prettier" (aka "more native"). These people have their subculture, called "Apple", and frankly, I want as little to do with it as possible. Prioritizing glitz above function shows serious problems in critical thinking.
If we can make an application look better, cool, we should add that to the list somewhere. I'm not opposed to that. I strongly disagree that this should be anywhere near the primary criterion used to judge an application's value.
Edited to add: And I disagree with them, however I'm downvoting to show disagreement is something that HN has always been against, to it's credit.
I'll tell you what I can't comprehend – people who apparently find it difficult to accept that other people have differing priorities to them, and aren't mentally subnormal as a result.
k-melon for windows http://kmeleonbrowser.org/
I don't really care if an application is native or not, Firefox works great for me on Os X and I really appreciate I can run the same browser on all platforms I have to use or developer for.
Although your point isn't lost. In 2015 Mozilla probably won't release a Motif build for the WindowMaker users.
Current HTML is capable enough. It's nice to see them talking about adopting that in mainline Firefox.
Still makes me a bit sad to see it go, though; I'm old enough to remember when XUL seemed like an exciting potential platform for general-purpose app development. Which never really panned out, alas, but was fascinating at the time.
I'm not mad at Mozilla for all that, lots of platforms are complicated to build on, especially ones that are new and still evolving (which XUL definitely was, at the time). It's just not an experience that I feel like I can put into the "win" category. It was a dead end, at least for my needs.
Sailfish browser did it as well (using native UI). Desktop Firefox also can benefit from IPCembedlite. But the question will be, what should be used to write the UI. Qt as well?
I'm a bit torn on that, since switching away from "Webby" interface basically killed Fennec for Meego, and only Android started getting UI improvements (that's what triggered a separate browser for Sailfish to begin with).
Use this chance and port Firefox to Qt:
There are a lot pro`s, who speak for that, front in the row the huge community, the portability, the performance, and the fact that many devs rewrite there existing GUI to Qt, like Musesore, Frescobaldi, Wireshark, Subsurface, VLC, Gcompris, Mkvtoolnix, Dropbox, Megaglest`s Map editor, OpenShot, ufw-frontends, Dolphin-Emu and even two DEs: LXDE and Unity.
Please do that and i am Firefox user for my lifetime. :)
Together with work on improving addon APIs (APIs for CSS features were discussed, for example) this could be very interesting.
Think about it like this, you're using Firefox and you get a notification... "Feature X is ready to test, would you like to try it out? Yes/No" If you select Yes, the feature is rolled out to you and other volunteers immediately (potentially without restarting, depending on the feature), and you can then feedback your experience to Mozilla on how well the new feature works out for you. The feedback from this control group then informs whether Feature X is ready for prime time.
In some ways it seems like it's a restructuring of the Firefox development channels, a mix of beta and stable releases in the same channel.
The model is that we want to make Firefox itself more webby in the way it ships. Features should be independently updatable from the core browser, and we should be able to do phased rollouts to help us watch for issues, control for load, and so on.
We are looking at offering very experimental stuff in a purely opt-in process, and updates to regular features as if they were third party add-ons (with some twists in how they have to be implemented).
I'm working on the Go Faster project. We hope to deliver a 1-2 features this way by the end of 2015. We have just started on building out needed changes to the client, update service, and build pipeline.
Do not make tabs cuter, I don't care about it.
But PLEASE - do something to stop Firefox from being such a bloated memory hog - I deeply care about it.
[2] https://support.mozilla.org/en-US/kb/firefox-uses-too-much-m...
[3] https://blog.mozilla.org/nnethercote/2014/05/14/adblock-plus...
Until suddenly the show stops and I have to kill it via Taskmgr to inject new life into it due to memory suffocation.