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

141–146 of 146 posts

Re: Firefox.html: Rebuilding Firefox UI in HTML

#141

Post by rancur »

epa wrote: post #108
cptskippy wrote: post #99

Earlier quoted context omitted.

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

Excellent analysis

why? he waved his hands and said exponential growth will continue, citing the fact that it always has

that's not a valid argument when we're talking about running out of atoms to work with

Re: Firefox.html: Rebuilding Firefox UI in HTML

#142

Post by STRML »

adl wrote: post #135
STRML wrote: post #111

Earlier quoted context omitted.

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),…

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…

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.

Re: Firefox.html: Rebuilding Firefox UI in HTML

#143

Post by cptskippy »

rancur wrote: post #139
cptskippy wrote: post #99

Earlier quoted context omitted.

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

perhaps you didn't look at the atoms in the picture I linked. At 4nm no amount of dielectric will save you from the quantum tunneling.

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.

Re: Firefox.html: Rebuilding Firefox UI in HTML

#144

Post by joev_ »

com2kid wrote: post #140
kristiandupont wrote: post #124

Earlier quoted context omitted.

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, 30…

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

Re: Firefox.html: Rebuilding Firefox UI in HTML

#145

Post by com2kid »

joev_ wrote: post #144
com2kid wrote: post #140

Earlier quoted context omitted.

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, 30…

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

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

But pure CSS before CSS3? Bleck.

Re: Firefox.html: Rebuilding Firefox UI in HTML

#146

Post by rancur »

cptskippy wrote: post #143
rancur wrote: post #139

Earlier quoted context omitted.

perhaps you didn't look at the atoms in the picture I linked. At 4nm no amount of dielectric will save you from the quantum tunneling.

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.

Post reply on HN