Hacker News Reader

Comment by millstone | Hacker News Reader

I hate the trend of building native UIs in HTML, because the result never feels right. For example, Firefox does not use OS X native context menus, and it shows in how they look, position themselves, animate, respond to keyboard and mouse events, etc.

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.

View on HN

There's broadly two directions Firefox could go: do everything in HTML, or use native widgets. Firefox for Android initially used XUL just like Firefox desktop, but switched to native. They've had a lot of success with that. This email is the start of a discussion that will include that option.

Is there an official line that Firefox is taking on this? As a novice to their development decisions, I've always wondered this myself.

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.

I would guess that there's some functionality provided via XUL which doesn't exist in the native OSX context menus (i.e. precisely the same functionality doesn't exist, not that the native OSX context menus are somehow deficient). That's going to be particularly relevant for extensions.

A lot of people agreed with you and built Camino and K-Meleon.

I can't agree more. Where does this plan leave desktop app dev. with Mozilla technologies? There are tonnes of projects (desktop apps) using XUL, XPCOM, e.t.c. SUre, the future is the Web (like Web OS, Unity, i.e. UI in HTML). Why can't they improve on XUL/XBL by releasing a new version with the desired features while they try to simplify building extensions/apps with XPCOMs? They should standardize apps dev. for FFOS (gonk{+necko}/gecko/gaia) & FF(gecko+necko/xul). This effort does not necessarily mean spending much time on enhancing the UI for FF but rather ensuring seamless app. portability between FF and FFOS.

Here is a difference of opinion:

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.

Well, the XPCOMs represent the bytecode in your opinion. One still can't get an XPCOM for FF to work on FFoS, I meant the simplest one without making huge changes to the code base. Yes, one UI engine is needed and so is a (cross-)compiler in your case OR alteration of the code base for FFoS of FF to ensure portability. I guess it would be the FFoS code base that might need to change. BUt that could be tricky since it leverages the Andriod's core - a component-based linux OS.

You are on point Dre! I know frustrating it could be building FF extensions and FFoS Apps. There need to be an efficient way to port one to the other.

Reply on news.ycombinator.com