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 with the advent of 8-16+ GB of ram in consumer computers can we really say 2-3GB for windows rendering is heavy?
This attitude is why we have phones with 1G of memory and 1Ghz+ CPU's lagging when just trying to read email.
Yes, there is more memory available than before, but that doesn't mean we should just waste it for useless stuff.
For example if we eat 2-3GB of memory on a system with 8GB of memory, thats over 25% of the usage. Then some applications that are actually used. (Let me use my own process mem counts here...) 1.3Gb for Firefox, 0.6Gb for Android emulator, 0.5Gb for Visual studio....
And there would have gone over half of the 8GB of ram!
I am sure my current memory usage would be half of what its now if developers would actually give some shit about memory usage... Not just allocate too much memory because "there is so much memory it doesn't matter"
> Yes, there is more memory available than before, but that doesn't mean we should just waste it for useless stuff.
I disagree. I think the point is that it's not useless, by its own existence. It saves dev time (which allows more - and better! - programs to be built), it allows richer features and interactions, it lowers the barrier to entry for maintenance work, and most of all prevents constant re-inventing/implementing the wheel, which is reflected to the user in a lack of many common types of bugs, annoyances, and accessibility issues.
I'd argue against it saving dev time. See my above comment, HTML+CSS is not the fastest way to design an app. If it is all you know then yes, it is faster, but inherently it is not a /good/ system. It gets worse even faster if you add JS to the mix!
I think it's a great system. It's surely the fastest way for me personally, in spite of it not being "all I know". With Bootstrap or Foundation, you need very little code to make something look nice, there is great documentation and lots of online resources.
If I want to make a UI in C#, I can pull up WinForms and use one language. If I want to have nice separation of style from code, I can use XAML (which is purpose designed for making layouts easy) and be using 2 purposefully technologies.
There is a lot more mental overhead to HTML + CSS + JS (and then the DOM somewhere) than to just type in
Button accept = new Button("Accept!", new size(100, 45));
form.Add(button, 300, 50);
If I want to style my button, I set some properties on the button.
(And if I want to use XAML, I send a file off to a designer who pops it into a purpose built XAML editor who can play around with the styling and layout to their heart's content!)
The thing is, web tech was designed for a non-interactive page based model, and then interactivity was added.
Then someone wanted curved boarders, and what had to be done to make curved borders was rather nasty. So after a good long time web standards caught up with fashion and an ability to add curved borders was added to CSS.
And damn you to the neither regions of hell if you want squiggly borders (Back to nasty scaling PNGs, or a few thousand 1 pixel DIVs!) However, I'm sure if those do come into style and enough people complain, that squiggly borders will also be added to the spec.
In comparison, a real UI framework lets you override the Paint function and do whatever you want.
On that note, about 2 quarters of freshman Java will have students be able to create custom UI widgets that do whatever is desired.
For someone who already knows programming? Point them at OnPaint, "here override it, draw whatever you want, have fun!" The set of concepts needed to modern UI development on the desktop is tiny. This is a problem space that has had three decades of effort put into making it simple and easy.
Again, want separation of concerns? About 2 hours of XAML will have someone making custom widgets, in fact that is the entire way XAML works! (It was sort of a mind twist for me that the easiest way to make an image button in XAML was not to override an OnPaint method and draw an icon, but rather place the XML nodes for an Icon and a Button together!)
But take someone that knows programming, well first you have to introduce them to CSS, which is a bunch of fields that you have to memorize (or rather just keep looking up) with a number of different types of units supported (none of which do exactly what you want, but I'll grant that is the case for all resolution independent UIs). Then of course they get to learn the newest flavor of HTML (semantic everything, don't you dare use <bold>). Then you get to show them JavaScript (Packages? Namespaces? A language in which imports can silently override my variables causing havoc and dismay? Wow, C's #DEFINE is considered harmful, but this is a whole new level.)
But hey thankfully CSS3 makes 3 box layouts no longer an exercise in pain! So that is a good thing. (I've been using flexible layouts that auto adjust the positioning and sizing of elements since the late 90s, it is nice that the web finally caught up by introducing yet another boxing model!)
Of course the final lesson is "oh and by the way this all sucks so you really want to use a third party JavaScript UI framework. Also CSS is sort of painful so you may want to use a preprocessor. Yeah just shove your content in the middle of your client side generated DIVs. Well yes generating the exact same page on every visitors PC is sort of silly and a huge thermodynamic waste, but it is currently in style so stop complaining about it. Yes I know the comments section takes 10 seconds to load. What do you mean BBSs on a 9600 baud modem responded faster?"
(Edit: Of course the last bit about responsiveness isn't relevant to using a web stack for client side apps, it is just me complaining about the poor state of the web in general)
> If I want to style my button, I set some properties on the button.
You cannot be serious. A 1000+ line long setup() method that creates a ton of one-off elements, sets a million properties, and saves them all as instance variables is in no way superior to using some XML to structure your elements, and then a separate, extracted layer for styling. I've done the procedural shit before, in Java, UIKit, Cocoa, you name it. There's just no way you can actually think that is better. Presentational separation is a good thing. (btw you can write your UI in the same procedural way in Javascript if you think it is superior/are a masochist).
The rest of your comment is very rambling and does not really have a point so I will hold off on replying to it. I write polished, pixel-perfect, cross-platform interfaces, and HTML/CSS is the best tool I have found for the job. Nobody will ever say it is perfect of course, but IMHO it beats the hell out of WinForms! You are right, it is a lot to learn for a 1st year developer, but you are going to get a shitty UI out of a 1st year developer, who cares?
> You cannot be serious. A 1000+ line long setup() method that creates a ton of one-off elements, sets a million properties, and saves them all as instance variables is in no way superior to using some XML to structure your elements, and then a separate, extracted layer for styling. I've done the procedural shit before, in Java, UIKit, Cocoa, you name it. There's just no way you can actually think that is better. Presentational separation is a good thing. (btw you can write your UI in the same procedural way in Javascript if you think it is superior/are a masochist).
Depends what I am doing.
Shipping a large scale commercial app with thousands of UI elements? I sure as heck pull everything out.
But if I am making an app that has a dozen UI elements and maybe a couple of screens in total? It isn't worth my time to switch tabs between my code and an XML file.
> I write polished, pixel-perfect, cross-platform interfaces, and HTML/CSS is the best tool I have found for the job.
Pixel perfect is trivial in any system. Winforms can do pixel perfect, and has a damn hard time doing anything else!
A UI that scales across screen sizes? A UI that auto adjusts itself as needed? You can do it in CSS (many websites do!) but isn't fun.
And I do wonder how you found CSS, a layout language which until recently couldn't even do simple math, to be the best tool for creating UIs.
There have been decent CSS pre-processors out for awhile, sure, those work. If you do parts of your layout using JavaScript at run time, hey, that can also work.
Isn't inefficient coding, which is what we're discussing really, possibly needlessly forcing the specifications of hardware to be more and more powerful rather than getting the best out of the hardware we have now by better coding?
I rather expect causality flows the other way: coding is getting less efficient because hardware is getting faster. Or as the old saying goes, "Intel giveth, and Microsoft taketh away."
Adding HTML to the GUI coding is re-inveting the wheel. There are native toolkits for UI, there are crossplatform UI libraries for a reason. They work, they are fast.
Most desktop applications have a terrible interface compared to modern websites. That wouldn't be the case if the UI libraries were half as good as some people here claim.
Most new desktop applications have a really crappy interface. Mostly because they are trying to copy some new homepage layout and instead is missing lots of information and buttons and fading in/out text and buttons instead of letting me click them directly. Not to mention taking several seconds to load a form that on my 8MHz Atari would have loaded instantly. Yes I'm old, get off my lawn!
Desktop apps from the late 1980s to around 2004 or so were very usable. There were clear UI standards in place for most platforms, and thus a high degree of consistency between applications, even from different vendors.
Even Java's AWT, which came at the tail end of this and pretty much only targeted UI functionality that was common between different UI systems, could create desktop apps that were and are much more usable than the inconsistent web-inspired desktop apps we deal with today.
Let me add myself to the chorus of people standing up for native desktop applications. Sure, there are bad and good examples of both desktop and web UIs. But whats so horrendous about the original Mac OS interface? What was so bad about Gnome 2?
> I've often wondered why OS's just don't host browser render engines internally and draw their UI with that.
CSS is, by far, not a good way to try and do UIs. It sort of works, and it is getting better, but it started out with lots of legacy cruft and things have only gotten worse.
One can make any sort of layout imaginable in any of the modern UI frameworks within a few hours.
Want 3 columns boxes at a precise position in CSS? Well thankfully the latest version of the spec has support for that, but up until very recently....
But for code running on the platform, you can take any 1st year CS student who has passed a class or two and have them put that sort of app together in Swing. WPF is a bit more work due to the data binding magic, ignoring that the layout stuff is also incredibly easy!
On the web, getting data is the easy part, making the UI is the hard part. On the PC, getting the data is the hard part, putting the UI together is easy!
Compare the richness of apps even on mobile phones to what you get in the browser. Sure if you hire top notch web developers who have been studying web development for 3+ years you can get something that is just like an app, but holy crap.
I agree with this, despite that as a web developer I have written most interfaces in my life in CSS.
I did, however, have brief exposure to various native toolkits in Java and would love to see a proper constrained-based scene graph in the browser.
Im workong on having a plugin built that will give us the flexibility of constraint-based control in CSS but in a way that makes more sense to the CSS way of doing things.
no more software layers please! my PC was much faster when my programs were native. Apps rendered with chrome rendered with webkit...8GB used to be enough, then all these "developers" with their "development machines" who think it's no big deal that their Hangouts implementation takes 200MB when Pidgin takes 20.
people used to complain about Firefox hogging memory, I think it's Chrome we should be worried about...
At my day job I create apps for TV decoders. Most of those render and run in browsers.
The boxes have 1 GB memory, the browser uses just a small fraction of that. A lot of the browser memory is used for graphics (think bitmaps), the JS-heap is only 4 MB, not sure about the rendering engine.
Granted, we use SVG, not HTML/CSS, for most of these apps.
At the same time, it's likely much more expensive to code native apps than it is to just build an html/css/js app using chrome with a lot of the heavy lifting already done for you (at the expense of increased resource consumption).
A lot of these apps wouldn't exist if they couldn't have been built quickly and cheaply.
You see those little dots? Those are individual silicon atoms from one of a few fins in the gate on Intel's 22nm node.
Also, I Am A C Programmer. I Think Everything Should Be Written In C. C Is Close To The Hardware And Is Faster And Use Less Resource Compared To The JavaSlow and WebKittenz and CSS. But I Like CSS Because It Has C In It. I Am A C Programmer.
Get back to me when we have compressed ZRAM implementations and Same Page Merging everywhere to save memory on each Chrome process and each JS interpreter instance. Don't you want to do the green thing?
Congratulations, I thought I'd managed to go a whole year without hearing about process limits and the grim future we face. Seriously, every 6 months or so for the last 15 years or more there is an article published explaining the end of the PC revolution. Google the terms "end of silicon" or "end of moore's law" and add a custom date range like 1998-1999 and you'll get dozens if not hundreds of articles from reputable sources saying that we've come to an impasse or that in 3, 5 or 10 years we will be screwed.
When chips started hitting the limits of the photo-lithography process, they switched to lasers, UV, DUV, and now EUV. Transistors start leaking so they redesign them time and time again. We've gone from completely 2D Circuts to 2 layer 3D to what's it at now 16 layers? The end is nigh and has been since Moore came up with that god damn law.
My point is that there's a lot a really brilliant people in the field who've been working for years if not decades to address problems we haven't even had yet. We're perpetually on the verge of a crisis, and simultaneously on the verge of a solution to said crisis.
We're in an age of ridiculously powerful machines that we don't know what to do with. If suddenly all progress halted in chip development and we had to make due, we'd probably enter into an age of hyper optimization where software engineers would be scrutinizing every clock cycle furthering the annual performance gains we've had for the last 40+ years.
I'm not suggesting a solution, I'm simply stating that lots of brilliant people have been aware of this eventuality and have been actively working on next generation processes to address it.
if "next generation processes" is really the best you can come up with...
Those people are working on EUV at ASML. Those are the next generation processes. What you're suggesting is they have some super science quantum-tunneling barrier that the world has never heard of nor seen nor thought could exist.
I'm with you. I'm a "mechanically sympathetic" anomaly amongst my age group and even many of my senior colleagues who came up in the 90s when Moore's Law == clock speed. My whining about cache thrashing and branch mispredictions might fall on deaf ears now, but I'll be ready to fix all the slow-ass code when people realize that silicon atoms aren't getting any smaller and heat isn't getting any less hot.
you have my approval :) I've been toying with the notion of continuing to focus on embedded C since most of the Computer Science d00ds I've worked with have no clue how things work "what? the runtime takes care of it" besides O-notation.
If we do hit process limits on process node limits, we'll start going massively parallel, it which case you still won't be using C to program your 10000 processor machine.
I don't agree that it's "much more expensive" - and I've been developing applications with UIs in Win32 for a long time.
Also, even if native apps were "more expensive", that's only from the developers' perspective -- and for a good app, the number of users far outnumbers its developers, so any "increased resource consumption" gets foisted on and effectively multplied by all the users. Only the developers get any benefit from this; but even then, since developers are themselves users, if they use apps that others have similarly developed with this culture of "selfishness", they get to experience the "increased resource consumption" too. In the end, I don't think this vicious cycle of waste benefits anyone except the hardware manufacturers.
In general, I think treating resources like they're infinite and "there will always be more" is almost certainly guaranteed to make it so there won't ever be enough.
This Firefox.html is a fun experiment to push boundaries, like WebKit.js and all the other interesting things you can do with JS and an HTML rendering engine (e.g. see Fabrice Bellard's complete PC emulator in a browser), and somewhat reminds me of other tricks like nesting VMs.
As long as the users want more and more apps very cheaply they might have to accept the performance they get. It has also been a problem that most OS's have different GUI frameworks which means you have to re-devlop every app/application multiple times. This is an enormous time sink. When all operating system uses the same GUI framework (and possibly the same languages) it might be very effective to use that instead of html+css. Until that it is still expensive and as I started with, the users want more for less.
> it's likely much more expensive to code native apps
No, and not even close. Web tech is primitive compared to the native SDKs and there is no sign of that improving anytime soon. All what happens is reinventation of some MVC and reshuffling the libs.
I've been gradually moving back to native apps: hexchat for IRC, pidgin for gtalk+fb messenger, thunderbird for email (heavy, but can't find something better for me).
With this setup I can boot to a system that uses about 1.5GB of RAM occupied with Firefox with a couple of tabs open.
Some stuff that I'm trying to eliminate that's a big memory hog: dropbox (150MB), skype (150MB).
I don't like the idea of developing for current machines. With the constant advances in computers the next generation of applications, "developer apps" should be made for the next generation of computers, meaning that its okay if it's a bit of a hog. I mean, 200MB is just a drop in a bucket now.
...and fuck those people who can't afford to build a new bleeding edge gaming rig ever year, right? </s>
Developer arrogance like this is exactly why all software sucks. It's actually a lot worse than it used to be due to mobile phones, which are hugely underspecced but attract the same mentality of "my code is surely the only important thing users will ever run so it's ok to use 700MB for a browser".
If you want to have bleeding edge developer software than you may need bleeding edge developer hardware. To clarify, I don't think mainstream applications or even betas should aim at bleeding edge hardware, just that when we plan on making some new piece of software that may take years to build its okay to assume that people in the future will have better computers.
In 2006, the next computer was the iPhone with 1GB of memory and the iPhone 6 still has 1GB today. I wouldn't count on everything being a 16GB+ monster rig just to bring a browser up.
I don't necessarily disagree that stuff is getting too bloated, but the iPhone 1 had 128 MB of RAM. So iPhone memory is doubling every 2-3 years so far. That trend will likely continue as Apple's software is also getting more bloated.
Didn't Windows use to do this until they got dinged by the anti-trust suit? MSFT had to spend a lot of engineering time decoupling IE from being a critical component in rendering basic file explorer views
AFAIK, Windows 8, Gnome, Unity and others offer desktop html+javascript compositing with support for webservice calls. Some may be more powerful/limited, but it's something already being done.
Even in a thread earlier today there was a post about the state of desktop web apps... node-webkit and atom-shell aren't bad options either.
I always wanted to like XUL, but a shell mode for HTML+JS that can have more control over iframes than is allowed in the browser... it would definitely be interesting. It would be more interesting if it followed node's API (at least for JS-level modules).
Game Dev Tycoon is a neat example of this. It started as a Windows 8 game developed with VS Express (using JavaScript), then it became it's own thing on Steam, not sure if they use node-webkit or what, I can't remember, but it runs smoothly on Linux and other platforms as a result.
Windows Presentation Foundation does just this with the XAML markup language. It's almost like designing a web app. You can use this markup for designing windows phone apps. I'm sure Apple also has their own markup as well for developing desktop/mobile apps but I have no experience in this so I'm not completely sure.
HTML+CSS are better than any other layout engine and if the performance is good enough to make apps for mobile devices, it's good enough for any system.
Why spend time on other UI systems that will only end up requiring more work for a visually worse result?
> 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 problem (or at least one of them) is that maintaining XUL and HTML is expensive. XUL, like HTML, has a bunch of weird corner cases, tricky layout behavior, complex interaction between elements, etc. The focus of the platform developers at Mozilla is obviously on the Web, so XUL has been in a crappy maintenance mode for a long time now.
Doing the Firefox chrome (heh) in HTML is another way to put our money where our mouth is, like the Firefox OS and Web App Runtime efforts.
It might even make more sense to just use fonts for the icons and leave SVG out of it entirely. I'm referring to the OpenType COLR/CPAL tables Microsoft is pushing:
I was looking for a similar solution recently, and came across Stackicons[0], basically icon fonts with multiple color layers, essentially what Microsoft is proposing.
But there's a huge flaw with the whole approach: you can't have color gradients. Of course you can still emulate gradients by using lots of layers, but it's going to look like crap when you increase the resolution.
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 left RIM in 2012 so I could not confirm that this is how the browser works in new devices released today. But given the success and advantages that having the html browser gave us there would have to be some really compelling reason (or $$$) to abandon it. The group I was part of was formally TorchMobile and as a group had significant browser experience having written a fair number so we understood the hassles of maintaining two projects. Being able have webkit developers help with part of the browser made development go faster on both sides (webkit devs could easily abuse the browser to test new feature). Even if it isn't used in the browser as mentioned at the bbjam the weblauncher application was used by not only the browser, but for a number of other purposes.
I can only imagine there is a fair amount of overlap in Mozilla where there are two developers working on the same thing, one for xul, one for html.
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"
You're right - but the real win here is that hundred of thousands of developers already know HTML + CSS, and very few developers know XUL or even any native UI API. Given that these native APIs change with the platform, many developers have given up on them since HTML + CSS will be useful for the foreseeable future.
Is XUL really better than HTML + CSS? Probably. But HTML + CSS is getting a lot better (flexbox, etc), and tons of developers know it now and can contribute. Plus, dogfooding. I think it's a really good move!
Sure, RAM usage will probably get worse, but perhaps it will motivate them to improve that as well, and all users of the browser on all pages will benefit as a result.
I don't know if XUL is better than HTML + CSS, I haven't used XUL. I have used XAML and Qt, and the Android Layout Manager. and they are way easier to deal with.
In HTML, a button is not a button, it's a DIV with an CSS properties (which render differently depending on the browser) + some images + some Javascript. And that abstraction leaks a lot.
The equivalent in native code will be having to deal with Xlib in X11 or GDI on Windows every time you debug.
That said, there is value in HTML/CSS/JS UIs, I don't deny that, and I use them when appropriately. I still think native UIs are 'cleaner' to develop.
While that's true, a lot of the frustration with HTML/CSS/JS melts away when you have only a single target environment and don't have to worry about browser compatibility. Targeting a modern environment like Gecko would actually be quite nice; you could use a lot of modern ES6 features and Flexbox.
see it's crazy. I don't know how to relate and I see it's the same for you. To me there's nothing easier than building UI in HTML with CSS and JavaScript. Using code to tweak padding and positioning in native code with a compile step is much slower IMO then
10.times { alt+tab, edit, cmd+r } -> perfect
[edit] - i should mention I spent a lot of time building desktop apps but haven't put much time into the newer mobile apps ios or android maybe it's improved a lot in ten years?
[edit] - last edit, I know it's improved and I suspect it's a matter of taste and proficiency that makes the difference.
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".
The rendering engine (Gecko). I guess for it to make sense you must separate the drawing engine from the browser, which adds things like tabs, bookmarks, themes and add-ons.
This can be seen today in Servo, which can browse the internet but has no GUI of to speak of (e.g. to visit a URL you must pass it as a command-line parameter to the executable).
In addition to things mentioned by other users, a browser also enforces a security model and (nowadays) provides a Javascript engine and the browser object model, and handles HTTP and session state,
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.
Ha, weird, I never felt the same direct access to the metalevel as in Chrome. Just the other day I spend an afternoon trying to access Firefox restore session url list through the developper tools without any luck, the XUL ~DOM element was an opaque type I couldn't inspect.
Possibly, yes. Though I would not recommend implementing it as is... XUL was never versioned as far back as when I used to work with it, which is about 5 years ago. It's messy. Not easy to use. Although still easier than the new flexbox standard that evolved from it.
Anyway I'd hope for something better than XUL/XBL. The potential was always there. Mozilla the platform! —
I massage HTML and CSS professionally since 1996, and I must say I'd prefer something like "XUL2" over my beloved web standards any day. I wouldn't mind if "XUL2" was in actuality created with web components. Though seriously, CSS and DOM (HTML/XML) were created to make you suffer. That's their true purpose.
There is no easy way out of this. And rewriting the web won't work either.
There have been many attempts at a chromeless app runner for Gecko, including Prism and WebAppRT. If I recall correctly, Paul is using a variant of WebAppRT as a runtime.
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.
Yep, and most of the UI in Firefox is either XUL or HTML, both of whom are rendered by Gecko. This is not the case on Android, for technical reasons (libxul is too long to load, so we rely on Java, which is pre-loaded by the OS, to display the UI).
The one thing that absolutely annoys me about the current Firefox is the location of the refresh button, which is a tiny icon stuck in the far right of the location bar. Worse of all you can't customize it natively. You have to download extensions to change the UI and still you won't get it to look 100% how you want it. Being able to modify a HTML based UI would be awesome.
I have been running Firefox for almost a month now. The divide between firefox and Chrome is getting bigger and bigger.
1. What do you guys think about sidebars and multiple toolbars? There is only a limited space available on screens these days for most people. I find them very archaic.
2. Dropdown arrows - I also don't understand the purpose of actually showing that if you click here a menu will open. A folder expands when you click it. There is nothing to be said about it.
3. Lack of overlay icons. There is literally a block with yellow background which shows number.
4. Lack of interest in devs to innovate on Firefox. There is a difference in versions of Evernote webclipper for Firefox and Chrome. Diigo extension is in atrocious condition.
Why do you think a solid browser like Firefox is lagging behind in UI compared to Chrome?
It depends on your point of view, I could bring up similar arguments with Chrome. There is still no way in Chrome to open more than 25 tabs without the tabs being so small we can't see them and the Settings page of Chrome is not an example of clean UI either.
They both are great browser. I am not trying to say one is good and other is bad. What I am trying to say is that because of the reasons mentioned above it has been hard for me to adopt to Firefox. Chrome is Google's platform they want to push their services and has become more of an application platform with Chrome only apps and less of a browser. I would like a browser that promotes a free web.
For example, Diigo's addon doesn't have overlay icon so it is impossible for me to tell if I have already bookmarked a page or not. Like many addons on Firefox Diigo has both sidebar and toolbar. So basically they have developed 3 UI elements and none of which work well. There is clearly Diigo's fault here but applications are as good as platform.
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.