[drethemadrapper]

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.

[frozenport]

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.

[asmicom]

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.

[asmicom]

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.