I've built that. Just to be clear: this is a personal project, not a mozilla project (even though I'm a mozilla employee).
Also - many people find it silly to use HTML instead of the operating system toolkit library. But it's not HTML or native. It can be both. In this case, the HTML code define the layout, and we can draw native widgets inside (look at the <input type=submit> tag in HTML, it's a native widget). For example, if you run the current build on Mac, you'll see that new tabs use Yosemite "vibrancy" effect. Native look and native performance, can, in theory, be achieved.
As a guy who works with primarily back end server code. I hate UI stuff primarily because even creating small input UI windows requires jumping though hoops of fire it feels like with strange API calls, and documentation that says, "Just follow the example it'll all be fine in a couple minutes." But I'm 8 inheritance levels deep trying to figure out why my text box isn't rendering.
I've often wondered why OS's just don't host browser render engines internally and draw their UI with that.
Well I don't for long, I know HTML is much younger then X. Also browser engines are massive resource hogs. But with the advent of 8-16+ GB of ram in consumer computers can we really say 2-3GB for windows rendering is heavy?
Especially if it offers that much empowerment to developers.
> But it's not HTML or native. It can be both. In this case, the HTML code define the layout, and we can draw native widgets inside (look at the <input type=submit> tag in HTML, it's a native widget).
The browser shipped with Blackberry 10 was written in HTML and was a real joy to develop.
Edit: some more public details
The default browser on the BlackBerry 10 platform was a completely new browser application. The chrome was written in HTML, CSS and JavaScript. Being able to develop the chrome on your desktop browser or being able to run inspector remotely and using your desktop was very handy. The core was a command line application called webplatform that "launched" a url that was a "webapp". The webapp had API's exposed to it such as creating WebView's in or out of process (yup blackberry has had multi-process tabs for a while now...). One joy was being able to pull up the Javascript console for the browser WebView and dynamically calling exposed c++ API's in any WebView in any process to test out features or diagnose problems.
It started out as a quick little proof of concept I tossed together over a day and the upside was large enough to invest time into. One of the reasons for making the main browser in html was that as a platform we wanted web application to succeed. Eating our own dogfood we made sure webapps could handle the job. The API's that were needed were there, memory usage were low, startup time was fast etc. And if you search for reviews of the blackberry 10 browser you will find that the end result was a success.
Edit 2: Much more in depth information can be found on this video which was a presentation given at Blackberry Jam by several of my colleagues. Skip to the 23 minute mark to see some actual code of what a webapp browser would look like.
Another very cool feature I forgot about was that when developing the browser application on the device it would not actually have any browser bits on the device, but just have the environment variable CHROME_URL set to my desktop where I had a webserver serving up my browser files. This let me very rapidly develop the html/css/javascript code without having to transfer my "mobile app" to the device. Reducing the edit/"compile"/see cycle was a big win.
I'm very excited at the potential of the browser chrome being implemented entirely via standard web technologies. And given that Servo is never going to implement XUL, it would save a lot of effort that would otherwise be spent implementing a bespoke, minimally-functional UI (which has been tentatively named Crow, if the MST3K reference wasn't already obvious).
I realize this is a personal project, but this is deeply amusing considering that:
1. Way back when (circa 1998-2001?), the Mozilla project started as a radical redesign of the next gen Netscape browser. One of the core principles of the architecture was that the browser itself would render the UI elements (using an HTML-like tech call XUL).
2. The Firefox browser (then called "Phoenix") was a reaction against the above, which was thought to make the browser too heavyweight and slow. Originally Phoenix was the Gecko engine in a native UI window without all the XUL overhead (and without all the other components of the Mozilla Suite like the email client).
Now we're seeing the reverse trend, 15 odd years later.
EDIT: It turns out I misremembered about Phoenix dropping XUL completely--rather they dropped XPFE for a "new light-weight XUL toolkit", along with dropping all the non-browser components of the Mozilla suite.
You're getting your browser history mixed up a little -- Phoenix was a reaction against the general bloat of Mozilla, but it was still a cross-platform XUL-based affair.
"Phoenix is a redesign of the Mozilla browser component, similar to Galeon, K-Meleon and Chimera, but written using the XUL user interface language and designed to be cross-platform."
Similar concepts from Microsoft (browser wars era):
Microsoft integrated Trident (Internet Explorer HTML engine) to Win95 with the ActiveDesktop refresh (part of IE4 installation) and shipped with Win98 by default. The desktop background wallpaper was a large HTML page, there were DHTML widgets, the Explorer sidebar was HTML. In Windows 2000 and ME you could even preview Videos in the HTML based sidebar. WinXP's sidebar is HTML based too, also the slow applications window where you can uninstall applications, as well as the control panel. Even in Win7 and more modern versions the UI render code for the control panel, some new popup dialogs, and some Office UI and Windows Media Player is based on a forked render code that happened in the XP era. The EU even mandated that Microsoft has to release the API to the public, so that other developers could create such beautiful Windows applications based on that UI code.
Use your favorite PE resource explorer (e.g. reshacker) to verify it. The DHTML source is in various shell related dlls in the Windows directory.
> Originally Phoenix was the Gecko engine in a native UI window without all the XUL overhead
I'm not sure Phoenix was ever a reaction to XUL. Phoenix was more a reaction to the kitchen sink feature-list of Netscape 5 and Mozilla Application Suite, seeking to pare down the feature set to a minimally viable browser.
In XUL (and moreso XBL) Mozilla had a web technology that there was talk of submitting for standardization and which brought with it a level of expression that HTML didn't offer at the time. As HTML, CSS and JavaScript have evolved, XUL/XBL bring less and less to the table.
You are wrong. When we started Firefox (before "Phoenix") one of the primary goals was to prove that XUL on Windows could be fast enough and look native enough that no one would care. We succeeded.
Well, XUL was quite ahead of its time. Most of XUL has now been incorporated (and improved, and optimized) in HTML.
Also, Phoenix kept using XUL, just a rewrite that didn't attempt to do everything from scratch, but relied upon native components wherever available. Most of the Firefox UI is either XUL or HTML.
I think Firefox mostly started out from an urge to make a "Browser product", rather than whatever the hell the suite had become. It shows in the release notes:
This is great. My experience with XML for UI went something like this.
1. build an XML language for abstracting C++ UI MCF or gtk
2. realizing the need for HTML content - embed mozilla/xulrunner
3. realzing xulrunner /mozilla already provide a cross platform toolkit use XUL to build the user interface with xpcomm wrappers
4. realize that HTML is better for user interface, and only write HTML/javascript with xpcomm wrappers.
5. switch to web development completely and avoid desktop apps all together :)
6. from time to time check in on the state of desktop/app development and see if they've finally figured out html is better for interfaces than any interface builder
> from time to time check in on the state of desktop/app development and see if they've finally figured out html is better for interfaces than any interface builder
Is this for real? I can name numerous advantages of Web Apps have over desktop/native Apps, "Building better interfaces" is not one of them.
Trying to build a UI with CSS and DOM manipulation (not to mention <div> hacks, Bootstrap, Dojo/JQueryUI, different rendering engines, etc) is an exercise in pain compared to basically _any_ modern UI toolkit. (From XAML to Qt, Android, hell even GTK.)
edit: minor correction, I meant to say " build a UI" not "build a native UI"
Color me surprised, but when we get to the point where we run HTML to build a browser that is supposed to be the tool used to render and display such HTML... haven't we gone too far? Is a browser necessary? What is rendering that HTML if not a browser?
I mean, I get it, a browser is used to browse (duh) the internet, not necessarily to render HTML, but at this point we really need to ask ourselves "why are we doing this, again?".
EDIT: Still impressive though, nice proof of concept!
EDIT 2: As much as I hate the "Why am I getting downvoted?" shenaningans that people usually pull, I want to clarify the intent behind this post. I'm not flaming or hating on the project, it's a cool idea. I was trying to spark some insightful conversation on "where do we want to go from here?" and "do we really need a browser if we have gone this far?". If you want to downvote me, why not just reply to this post and have a nice interesting conversation instead?
A browser is 2 things: a HTML engine and a UI (tabs, urlbar, back button, …). Usually, the UI is built in C++/ObjectiveC/XUL. Here, I'm proposing to use the HTML engine to render the UI as well. It's already the case with Firefox, the engine also renders the UI. But it doesn't use html, but another markup language (XUL).
I don't think the search-box and tabs are rendering it.
The firefox interface is already described in an XML format (XUL) and rendered from that. Instead of having two markups and two renderers, this allows you to simplify and consolidate to a single one.
I would hardly construe that as having "gone too far".
This is a fantastic idea and I'm really glad to see experimentation in this area. It's already great to look at how things like Webkit's dev tools are implemented in HTML and see how that idea might be extended.
At it's core, a browser is an HTML/JS rendering engine with some chrome to allow users to manage what pages they're looking at – and in most cases, that chrome is actually pretty minimal. It seems like a natural evolution to play with the idea of implementing that chrome in the natural UI language of the browser engine too. Yeah, the tools aren't there yet – but experiments like this will give us some scope to play around with what might be possible and identify the pain points that must be overcome to make it a reality.
This has worked on Firefox since the beginning of time. One could use the DOM inspector and venkman JS debugger, then Firebug chrome inspector and more recently the Firefox developer tools to inspect Firefox's XUL.
What widgets are used? (I'm not a web dev and only dabbled in that over 15 years ago) If you use native widgets, then you end up with a cross-platform app framework. If you create your own widgets, then you end up with a cross-platform GUI toolkit and app framework. Which is it? Either way, this seems quite interesting. OTOH, can you do apps this way with anything other than js?
There are discussions on that topic. However, everybody needs to realize that this is Paul's personal project, not an official Mozilla project, so don't get your hopes too high.
That being said, I'm quite excited about that project, I opened a pull request a few hours ago and it was accepted :)
Interesting. But on Android Mozilla already deviated form this approach of "webbiness" in favor of using native UI. Same as Sailfish browser does with Qt and Gecko through IPCembedlite.
If not for that, Sailfish browser could reuse the UI.
>we could drop XUL and close the gap between B2G and Firefox Desktop
I hope not. Customisability is always the first thing to die in mobile 'apps'. As soon as that happens on the desktop, I'm moving to Pale Moon permanently.
What about this (using HTML instead of XUL) would make it less customizable? If anything, it's at least more accessibly customizable because more of us know HTML than know XUL.
Also, I imagine if this truly the way forward, XUL will be removed from the FF code base, thus making a XUL based Pale Moon trickier since it would be so different from upstream at that point.
[+] [-] paulrouget|11 years ago|reply
Also - many people find it silly to use HTML instead of the operating system toolkit library. But it's not HTML or native. It can be both. In this case, the HTML code define the layout, and we can draw native widgets inside (look at the <input type=submit> tag in HTML, it's a native widget). For example, if you run the current build on Mac, you'll see that new tabs use Yosemite "vibrancy" effect. Native look and native performance, can, in theory, be achieved.
[+] [-] valarauca1|11 years ago|reply
I've often wondered why OS's just don't host browser render engines internally and draw their UI with that.
Well I don't for long, I know HTML is much younger then X. Also browser engines are massive resource hogs. But with the advent of 8-16+ GB of ram in consumer computers can we really say 2-3GB for windows rendering is heavy?
Especially if it offers that much empowerment to developers.
[+] [-] alex_duf|11 years ago|reply
It may or may not be used in the end, but I'm excited by the potential.
[+] [-] ANTSANTS|11 years ago|reply
No troll, I thought that was what XUL was.
[+] [-] lucianmarin|11 years ago|reply
[+] [-] Sophistifunk|11 years ago|reply
[+] [-] icefox|11 years ago|reply
Edit: some more public details
The default browser on the BlackBerry 10 platform was a completely new browser application. The chrome was written in HTML, CSS and JavaScript. Being able to develop the chrome on your desktop browser or being able to run inspector remotely and using your desktop was very handy. The core was a command line application called webplatform that "launched" a url that was a "webapp". The webapp had API's exposed to it such as creating WebView's in or out of process (yup blackberry has had multi-process tabs for a while now...). One joy was being able to pull up the Javascript console for the browser WebView and dynamically calling exposed c++ API's in any WebView in any process to test out features or diagnose problems.
It started out as a quick little proof of concept I tossed together over a day and the upside was large enough to invest time into. One of the reasons for making the main browser in html was that as a platform we wanted web application to succeed. Eating our own dogfood we made sure webapps could handle the job. The API's that were needed were there, memory usage were low, startup time was fast etc. And if you search for reviews of the blackberry 10 browser you will find that the end result was a success.
Edit 2: Much more in depth information can be found on this video which was a presentation given at Blackberry Jam by several of my colleagues. Skip to the 23 minute mark to see some actual code of what a webapp browser would look like.
https://www.youtube.com/watch?v=bZ8vxhTezvs
[+] [-] icefox|11 years ago|reply
[+] [-] mdm_|11 years ago|reply
[+] [-] icefox|11 years ago|reply
[+] [-] soapdog|11 years ago|reply
[+] [-] of|11 years ago|reply
[+] [-] passwordis|11 years ago|reply
[+] [-] kibwen|11 years ago|reply
See also this other thread linked from the discussion in the OP, "Moratorium on new XUL features": https://lists.mozilla.org/pipermail/dev-platform/2014-Octobe...
[+] [-] bkeroack|11 years ago|reply
1. Way back when (circa 1998-2001?), the Mozilla project started as a radical redesign of the next gen Netscape browser. One of the core principles of the architecture was that the browser itself would render the UI elements (using an HTML-like tech call XUL).
2. The Firefox browser (then called "Phoenix") was a reaction against the above, which was thought to make the browser too heavyweight and slow. Originally Phoenix was the Gecko engine in a native UI window without all the XUL overhead (and without all the other components of the Mozilla Suite like the email client).
Now we're seeing the reverse trend, 15 odd years later.
EDIT: It turns out I misremembered about Phoenix dropping XUL completely--rather they dropped XPFE for a "new light-weight XUL toolkit", along with dropping all the non-browser components of the Mozilla suite.
[+] [-] kemayo|11 years ago|reply
Check out the Phoenix 0.1 announcement: http://website-archive.mozilla.org/www.mozilla.org/firefox_r...
"Phoenix is a redesign of the Mozilla browser component, similar to Galeon, K-Meleon and Chimera, but written using the XUL user interface language and designed to be cross-platform."
[+] [-] frik|11 years ago|reply
Microsoft integrated Trident (Internet Explorer HTML engine) to Win95 with the ActiveDesktop refresh (part of IE4 installation) and shipped with Win98 by default. The desktop background wallpaper was a large HTML page, there were DHTML widgets, the Explorer sidebar was HTML. In Windows 2000 and ME you could even preview Videos in the HTML based sidebar. WinXP's sidebar is HTML based too, also the slow applications window where you can uninstall applications, as well as the control panel. Even in Win7 and more modern versions the UI render code for the control panel, some new popup dialogs, and some Office UI and Windows Media Player is based on a forked render code that happened in the XP era. The EU even mandated that Microsoft has to release the API to the public, so that other developers could create such beautiful Windows applications based on that UI code.
Use your favorite PE resource explorer (e.g. reshacker) to verify it. The DHTML source is in various shell related dlls in the Windows directory.
[+] [-] mirzmaster|11 years ago|reply
I'm not sure Phoenix was ever a reaction to XUL. Phoenix was more a reaction to the kitchen sink feature-list of Netscape 5 and Mozilla Application Suite, seeking to pare down the feature set to a minimally viable browser.
In XUL (and moreso XBL) Mozilla had a web technology that there was talk of submitting for standardization and which brought with it a level of expression that HTML didn't offer at the time. As HTML, CSS and JavaScript have evolved, XUL/XBL bring less and less to the table.
[+] [-] asadotzler|11 years ago|reply
[+] [-] Yoric|11 years ago|reply
Also, Phoenix kept using XUL, just a rewrite that didn't attempt to do everything from scratch, but relied upon native components wherever available. Most of the Firefox UI is either XUL or HTML.
[+] [-] maxerickson|11 years ago|reply
http://sourceforge.net/p/xul/mailman/message/1494849/
I think Firefox mostly started out from an urge to make a "Browser product", rather than whatever the hell the suite had become. It shows in the release notes:
http://website-archive.mozilla.org/www.mozilla.org/firefox_r...
A bunch of stuff about convenience and fast and fixing problems and usability is in there.
[+] [-] cwyers|11 years ago|reply
http://www-archive.mozilla.org/roadmap/roadmap-02-Apr-2003.h...
[+] [-] nevir|11 years ago|reply
[+] [-] taf2|11 years ago|reply
1. build an XML language for abstracting C++ UI MCF or gtk
2. realizing the need for HTML content - embed mozilla/xulrunner
3. realzing xulrunner /mozilla already provide a cross platform toolkit use XUL to build the user interface with xpcomm wrappers
4. realize that HTML is better for user interface, and only write HTML/javascript with xpcomm wrappers.
5. switch to web development completely and avoid desktop apps all together :)
6. from time to time check in on the state of desktop/app development and see if they've finally figured out html is better for interfaces than any interface builder
[+] [-] adl|11 years ago|reply
Is this for real? I can name numerous advantages of Web Apps have over desktop/native Apps, "Building better interfaces" is not one of them.
Trying to build a UI with CSS and DOM manipulation (not to mention <div> hacks, Bootstrap, Dojo/JQueryUI, different rendering engines, etc) is an exercise in pain compared to basically _any_ modern UI toolkit. (From XAML to Qt, Android, hell even GTK.)
edit: minor correction, I meant to say " build a UI" not "build a native UI"
[+] [-] tracker1|11 years ago|reply
[+] [-] Morgawr|11 years ago|reply
I mean, I get it, a browser is used to browse (duh) the internet, not necessarily to render HTML, but at this point we really need to ask ourselves "why are we doing this, again?".
EDIT: Still impressive though, nice proof of concept!
EDIT 2: As much as I hate the "Why am I getting downvoted?" shenaningans that people usually pull, I want to clarify the intent behind this post. I'm not flaming or hating on the project, it's a cool idea. I was trying to spark some insightful conversation on "where do we want to go from here?" and "do we really need a browser if we have gone this far?". If you want to downvote me, why not just reply to this post and have a nice interesting conversation instead?
[+] [-] paulrouget|11 years ago|reply
[+] [-] lamacase|11 years ago|reply
I don't think the search-box and tabs are rendering it.
The firefox interface is already described in an XML format (XUL) and rendered from that. Instead of having two markups and two renderers, this allows you to simplify and consolidate to a single one.
I would hardly construe that as having "gone too far".
[+] [-] matthewmacleod|11 years ago|reply
At it's core, a browser is an HTML/JS rendering engine with some chrome to allow users to manage what pages they're looking at – and in most cases, that chrome is actually pretty minimal. It seems like a natural evolution to play with the idea of implementing that chrome in the natural UI language of the browser engine too. Yeah, the tools aren't there yet – but experiments like this will give us some scope to play around with what might be possible and identify the pain points that must be overcome to make it a reality.
Great stuff.
[+] [-] nacs|11 years ago|reply
There is a 'browser in a gist' [3] using Breach which is a good example of its use.
[1]: http://breach.cc/
[2]: https://github.com/breach/thrust (I believe this is the new core of Breach by the same people)
[3]: https://gist.github.com/morganrallen/f07f59802884bcdcad4a
[+] [-] browserxul|11 years ago|reply
[+] [-] ehsanu1|11 years ago|reply
[+] [-] agumonkey|11 years ago|reply
[+] [-] kbrosnan|11 years ago|reply
https://developer.mozilla.org/en-US/docs/Tools/Tools_Toolbox...
[+] [-] espadrine|11 years ago|reply
[1]: https://github.com/rogerwang/node-webkit
[+] [-] paulrouget|11 years ago|reply
[+] [-] simonw|11 years ago|reply
[+] [-] agumonkey|11 years ago|reply
ps: not my work, see : http://www.reddit.com/r/programming/comments/2ow1g0/firefoxh...
[+] [-] misuba|11 years ago|reply
[+] [-] grumblestumble|11 years ago|reply
[+] [-] phkahler|11 years ago|reply
[+] [-] hawski|11 years ago|reply
[+] [-] 1ris|11 years ago|reply
[+] [-] Yoric|11 years ago|reply
That being said, I'm quite excited about that project, I opened a pull request a few hours ago and it was accepted :)
[+] [-] shmerl|11 years ago|reply
If not for that, Sailfish browser could reuse the UI.
[+] [-] minor_nitwit|11 years ago|reply
[+] [-] blueskin_|11 years ago|reply
I hope not. Customisability is always the first thing to die in mobile 'apps'. As soon as that happens on the desktop, I'm moving to Pale Moon permanently.
[+] [-] dschep|11 years ago|reply
Also, I imagine if this truly the way forward, XUL will be removed from the FF code base, thus making a XUL based Pale Moon trickier since it would be so different from upstream at that point.