Slashdot Mirror
Firefox 15 Coming With Souped-Up, Faster Debugger
StormDriver writes "Firefox 15 has hit the Mozilla pre-beta Aurora channel, and it features a redesigned, built-in debugger."
The original weblog post has more. Thanks to improved debugger internals in SpiderMonkey, supposedly code should run just as fast with debugging enabled as without (ever try loading Slashdot with firebug accidentally enabled?). There are also new tools for testing mobile layouts from the comfort of your workstation, and the debugger can attach to remote processes (Something Emacs users have enjoyed for years now, albeit in a hackish manner and without support for mobile Firefox).
Honestly, "Web 2.0" transforms so much otherwise perfectly functional hardware into environmentally-unfriendly junk that you might as well just stick your dick in an endangered species.
The web ten years ago was fine: people programmed for content and efficiency. Why can't we stay that way, with the advancement being in quality and quantity of /content/?
(ever try loading Slashdot with firebug accidentally enabled?)
Yeah, it takes forever. But what is much faster is using the built in Web Console in the tools menu in newer versions of Firefox. I forget what version it was that started natively supporting debugging but it got a lot better (4 I think?). I'm very excited to see these improvements but my JavaScript has to support versions of Firefox all the way back to 3.6 so I'm still using Firebug and I'm still super grateful that Firebug came around. It literally revolutionized debugging web applications for me. There could have been tools before it but, man, that was the final nail on IE's coffin for support from us. Hell, even Chrome's built in debugging is way better than anything I can find on IE. I know the latest IE versions have gotten better but it's my strong opinion that every single person who uses the internet should be thankful for Chrome, Mozilla, Venkman and these debugging tools. They made the web experience a hell of a lot better and open by empowering developers.
My work here is dung.
Correct. Debugging scales down 3.8462 times when producing a final release.
So why not focus on faster browsing rather than debugging ?!?
As a web developing, most browsers (yes, even IE) have gotten to the sub millisecond rendering ranges. I mean, we're getting to the point where the browser is negligible compared to your network. Yes, you have broadband and it should be lightning fast but there are even little unavoidable delays for each GET or POST. So the next best thing is to empower developers who write the JavaScript code to be able to find out where their delays are. As debugging improves, we can even breakdown the experience and display that to the developer in the browser for each resource (images, CSS, JS, etc) on a page and then the developer can think about turning all those images into a spritesheet or improving some code. I mean, this is actually making the browsing experience faster for everybody by putting the right tools in the developer's hands. You can spend forever optimizing the backend but it doesn't mean jack squat when you're querying for 99 separate little images when the user first hits the page.
My work here is dung.
Quit whining and just use the ESR release
Can all these noobish people with their issue with version numbers get over it? Every Slashdot post has these idiots cribbing.
You can disable automatic updates. Why are you whining? You don't like something called 15? Write a Greasemonkey script to display the correct version number however you want.
All version numbers as supposed to say is which distribution came first and which came later. 15 > 14. That is all you need to know from a version number.
Entia non sunt multiplicanda praeter necessitatem.
Yes they did. There was a benchmark story in slasdot a little while ago. It is as good as or better then chrome
The web 10 years ago was not fine. People were still supporting Netscape 4, which in practical terms meant that everybody was stuck with inaccessible, inefficient, inflexible table layouts that had to transmit style information for every page load. Mobile websites were practically nonexistent; where they did exist, it was a severely cut-back version. Using a single responsive design to cater to desktop and mobile uses would have been impractical even assuming today's mobile hardware. Lots of JavaScript was essentially written twice - once for Netscape and once for Internet Explorer, because the various DHTML and layout methods were different and incompatible. Netscape transcoded from CSS to JSSS internally, and lots of websites only supported Internet Explorer on Windows - a single browser on a single platform, both by the same corporation.
From a content point of view, it was still difficult to produce and manage content. Anything beyond basic stuff usually involved a very limited CMS and writing code. The "WYSIWYG" editors generated terrible, inefficient code that often only worked in one browser. Security was far worse than it is now, developers were largely clueless about even the most basic vulnerabilities, and things like the PCI standard weren't put in place yet.
These days, people are paying more and more attention to content because the technology is largely at a point where they can. Consider YouTube, Wordpress or Facebook - people generating content at phenomenal rates. Efficiency is still a prime concern due to mobile browsing, and techniques such as CSS, caching and CDNs have improved efficiency immensely. User-empowering features such as user stylesheets, user JavaScript and add-ons have grown into a thriving ecosystem, and accessibility support continues to grow.
Ten years ago was a really low point for the web. It lacked the client diversity that came before it, it was rife with incompatibilities and the inefficient designs necessary to compensate for them, and it lacked the compatibility and accessibility that mostly came afterwards. In all of the history of the web, that is probably the one point I'd least like to be stuck in.
Bogtha Bogtha Bogtha
ftp://ftp.mozilla.org/pub/firefox/releases/10.0.5esr
From my (totally unscientific) observation, most of the page load time is due to every page requesting crap from 10 different ad networks and trackers, which are inevitably overloaded. You can optimize the pages you serve all you want, but this may be a case where developers need to adjust the attitude of the commercial people involved instead.
except in the real world, that isn't true, just in somebodies "benchmark"
Except in the real world, Firefox has been running for three weeks on this machine with about 20 tabs open and it's using a whole 320MB of RAM. That still seems a lot, but it's a tiny fraction of the available RAM.