Earlier quoted context omitted.
> 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.
Firefox.html: Rebuilding Firefox UI in HTML
121–130 of 146 posts
Re: Firefox.html: Rebuilding Firefox UI in HTML
#122Earlier quoted context omitted.
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.
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.
Re: Firefox.html: Rebuilding Firefox UI in HTML
#123Earlier quoted context omitted.
> 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.
Re: Firefox.html: Rebuilding Firefox UI in HTML
#124Earlier quoted context omitted.
> 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…
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!
Re: Firefox.html: Rebuilding Firefox UI in HTML
#125Earlier quoted context omitted.
> 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…
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?
Re: Firefox.html: Rebuilding Firefox UI in HTML
#126Earlier quoted context omitted.
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
#127Earlier quoted context omitted.
> 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.
I want to build unbreakable responsive lauouts!
Re: Firefox.html: Rebuilding Firefox UI in HTML
#128Earlier 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...
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.
Re: Firefox.html: Rebuilding Firefox UI in HTML
#129Earlier quoted context omitted.
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!
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.
Re: Firefox.html: Rebuilding Firefox UI in HTML
#130I 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.
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.