Live data from Hacker News

Firefox.html: Rebuilding Firefox UI in HTML

mail.mozilla.org

81–90 of 146 posts

Re: Firefox.html: Rebuilding Firefox UI in HTML

#81

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

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.

Re: Firefox.html: Rebuilding Firefox UI in HTML

#82

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…

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

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.

Re: Firefox.html: Rebuilding Firefox UI in HTML

#83

I'm always pleased when I use chrome devtools on chrome devtools. So I can't welcome this enough. Have fun.

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.

https://developer.mozilla.org/en-US/docs/Tools/Tools_Toolbox...

Re: Firefox.html: Rebuilding Firefox UI in HTML

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

Just imagine... if fewer people agreed with you, my 2.2 GHz quad core pocket supercomputer might be able to animate a list of tabs without stuttering.

Re: Firefox.html: Rebuilding Firefox UI in HTML

#85

I'm always pleased when I use chrome devtools on chrome devtools. So I can't welcome this enough. Have fun.

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. https://developer.mozilla.org/en-US/docs/Tools/Tools_Toolbox...

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.

Re: Firefox.html: Rebuilding Firefox UI in HTML

#86
post #2

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

Slides for the presentation: http://hosting.desire2learncapture.com/RIM/Content/attachmen...

Re: Firefox.html: Rebuilding Firefox UI in HTML

#87
post #2

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

I switched to BlackBerry from Android last year and the browser is amazing (composing this reply with it on my Passport). Just wanted to say thanks!

Re: Firefox.html: Rebuilding Firefox UI in HTML

#88
post #75
post #2

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

Congratulations on awesome tech. Can you confirm the browser still work like this or did they change it to a non-HTML version in recent revisions?

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.

Re: Firefox.html: Rebuilding Firefox UI in HTML

#89
post #73

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…

> 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/implementing the wheel, which is reflected to the user in a lack of many common types of bugs, annoyances, and accessibility issues.

Re: Firefox.html: Rebuilding Firefox UI in HTML

#90
post #58

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

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

Post reply on HN