Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Firefox.html: Rebuilding Firefox UI in HTML

mail.mozilla.org

Post reply on HN
Print view View original

111–120 of 146 posts

Re: Firefox.html: Rebuilding Firefox UI in HTML

#111

Post by STRML »

adl wrote: post #77
taf2 wrote: post #52

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 wr…

> 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 hacks, Bootstrap, Dojo/JQueryUI, different rend…

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.

Re: Firefox.html: Rebuilding Firefox UI in HTML

#112

Post by jbergens »

userbinator wrote: post #91
jwcooper wrote: post #59

Earlier quoted context omitted.

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.

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 ben…

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.

Re: Firefox.html: Rebuilding Firefox UI in HTML

#114

Post by blueskin_ »

rancur wrote: post #58
valarauca1 wrote: post #53

Earlier quoted context omitted.

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 d…

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...

It's both.

Re: Firefox.html: Rebuilding Firefox UI in HTML

#115

Post by blueskin_ »

JacobEdelman wrote: post #63
rancur wrote: post #58

Earlier quoted context omitted.

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...

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?

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".

Re: Firefox.html: Rebuilding Firefox UI in HTML

#116

Post by yAnonymous »

valarauca1 wrote: post #53
paulrouget wrote: post #9

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 tag in HTML, it's a native widget). For example, if you run…

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 d…

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?

Re: Firefox.html: Rebuilding Firefox UI in HTML

#117

Post by dreen »

com2kid wrote: post #92
valarauca1 wrote: post #53

Earlier quoted context omitted.

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 d…

> 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 posi…

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.

CSS is good for styling but not for layouts.

Re: Firefox.html: Rebuilding Firefox UI in HTML

#118

Post by realusername »

donniezazen wrote: post #109

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 expa…

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.

Re: Firefox.html: Rebuilding Firefox UI in HTML

#119

Post by espadrine »

voltagex_ wrote: post #96
paulrouget wrote: post #39

Earlier quoted context omitted.

weaknesses: I built it in a couple of days. It's ugly. Designed for Firefox.html only. Don't use it :)

How did you build it? I always thought the Firefox code was huge and monolithic and couldn't be used like this.

The main commit seems to be this: https://github.com/paulrouget/gecko-dev/commit/a3bb11e9bcf8c...

You may notice a thin layer of XUL.

Re: Firefox.html: Rebuilding Firefox UI in HTML

#120

Post by k00pa »

joev_ wrote: post #89
k00pa wrote: post #73

Earlier quoted context omitted.

> 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 o…

> 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/implem…

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.

No need to add extra layers on top of those.

Post reply on HN