From my point of view it was really a game changer. The first time debugging and understanding web-applications became accessible. Probably all browser dev tools were inspired by this tool
Firebug is the reason Firefox broke IE’s crown. On one project we had management tell us specifically not to support Mozilla. Fuck you man. We get the software running on Mozilla first because it’s the only place we can debug properly. Then we fix whatever IE bugs are left over by dead reconning. We’re still going to be Mozilla first, we just won’t tell you about it anymore. And you just lost some trustworthiness so good luck convincing us of something difficult next time.
I still think the Mozilla team did Firebug a dirty by reimplementing what was an inferior version instead of bringing it home.
Exactly that. When Mozilla started reimplementing it, it seemed somehow error stack traces started breaking for both firebug and the horrible builtin developer tools
That's when we switched to Chrome for debugging, and only come back to Firefox to debug endless loops and stack overflows (because their Javascript VM is still better at being able to suspend/trace those)
Well, Mozilla itself was the result of a failed attempt at a rewrite. Jamie Zawinski decided that being a bar owner was a better career option shortly after that experience.
It’s hard to tell with autodidacts if they really got pissed off about something or just needed an excuse to deep dive into something completely unrelated, and I would definitely peg him as one.
Firefox 1(?) already had the error console, which told the _correct line_ where the error happened with more meaningful messages. Unlike IE where the message was something like `Unknown error at line 10203` when you had only a big HTML table and some inline JS.
That was already a big improvement, but then Firebug was another dimension.
> Probably all browser dev tools were inspired by this tool
Joe Hewitt begat DOM Inspector[1], which, after Hewitt left Netscape, begat Firebug (originally "FireBug"), and then pretty much every other Web developer tool began as an attempt to create something that could compete with what was available in the Mozilla ecosystem.
It certainly changed my life when I saw it for the first time. In fact, I do remember the exact situation when I was shown Firebug, and my realization that my live as a (then) frontend developer would change for the better from that moment on.
I can't even comprehend how anybody was able to do Javascript development pre-Firebug. I dabbled in client-side web development a bit in the early days of IE and found that the default behavior of a Javascript-enabled page when it encountered an error was to render a blank page and not log or report an error anywhere. I immediately retreated back to server-side development and didn't go back for years.
I taught myself programming with ASP Classic (VBScript) completely unaware of debuggers and it was normal to dump variable values to the output to try understand what was happening.
I did the same with PHP and initially the same with JavaScript.
However, once I learnt how to debug in Chrome’s dev tools, the idea of working without a debugger for any programming became unthinkable.
Actually, console.print was a later addition - when I started looking at Javascript, you could only do alerts, or you could call "status" to display something in the lower part of the frame. And if you accidentally alert()-ed inside a loop...
Still, I can't comprehend how you could develop anything in Javascript with just console.print either. You have my respect and admiration.
I remember there being a console window in the late 90s... don't remember what the full functionality was at the time however. Maybe it only showed warnings/exceptions?
It wasn't too dissimilar to developing a gui app, you could print to the console, raise a dialog, or if you wanted to be fancy implement a log with a window or pane to show them. Logging is what I use today for backend systems. It is usually enough, only breaking out a debugger once or twice a year.
Firebug enabled me to be a "real" web developer. Prior to that I was just slinging ASPX files with no real idea what I was doing. This tool was the gold standard for powerful developer tools that aren't overly complicated.
An interesting convention that ~started with Firebug was the use of angle brackets in the DOM/Elements view. (eg a DIV element is shown as `<div>`). HTML, as a text format, uses angle brackets to denote tags. But DOM is an in-memory object model; it doesn't have tags, but elements, and those have nothing do with angle brackets (other than getting el.innerHTML will serialize back).
From a usability POV, it's entirely defendable: make the DOM visually look like the HTML you authored. But Firebug and our current browser devtools only add them for aesthetics and familiarity.
It rarely causes problems, but it'll explain why you'll see `<tbody>` in DevTools even if your HTML doesn't have it. Still, I think dropping the HTML-y representation of DOM elements could be a win — removing end tags in particular would improve the information density.
Bonus: A Firebug Cheatsheet I made in 2007, 4 years before I was working on Chrome DevTools: https://imgur.com/I2KbZWm
The pseudo-source view also came (and still comes) with noticeable performance drawbacks. Opening the inspector on a nested element using today's browsers' built-in inspectors (which are implemented in HTML nowadays) can be slower than if you were to do the same thing on the same graph with a Web development extension in Firefox, since extensions were able to use the XUL platform, and that meant being free to implement nsITreeView.
And that's even with the advantage of modern hardware and and the trick where modern development tools will choose to elide elements in favor of showing a message that says that some nodes are hidden, with a button to e.g. "Show all 347 nodes". I just tried this with a 5000-row table, and clicking the "Show all[...]" button in Firefox's built-in developer tools has seemingly no effect at first—the inspector appears appears unresponsive for several seconds, before finally painting the expansion. In programs from 15 years ago running on 15+ year old hardware, on the other hand, this could expected to be nearly instant.
Jamie Brandon recently complained about this sort of thing, comparing the experience of creating an information-dense UI using imgui versus doing the same "on the web" (i.e. in the browser, using HTML):
Wow, I remember that cheatsheet was really handy! Thanks for that.
I still google "box sizing paul irish" every now and then to get to your blog… I can hardly believe it has been 10 years since you published that, time flies.
Firebug was some truly excellent work - but I think it's worth also mentionining its precursor Venkman - which in turn built upon the js/jsd low-level debugging APIs inside the mozilla suite.
> I think it's worth also mentionining its precursor Venkman
Is it, really? The experience of Venkman was horrendous. Not quite as bad as MS’s Script Debugger (I don’t remember venkman crashing multiple times per session, and it was able to debug the toplevel frame), but still just awful all around.
And more relevant, it was nothing special, at least that I remember. It was notable in being a “normal” extension, but that aside it was a pretty standard if not sub-par debugger experience for the time.
I do remember Venkman crashing multiple times, but to be fair it was the older "sort of stand-alone"-ish Venkman. The later version packed as an extension was a bit more stable.
But going back to the relevance subject, I don't really think it is worth mentioning. But not because of performance but because it was a fairly different thing. Mostly just a JS debugger with a couple of additional tools and little/no support. Usually you would need a bunch of other scripts such as XRAY [0] and others to reach a functionality somewhat comparable to Firebug.
Strong disagree. Compared to Venkman, Firebug had the following misfeatures:
- modal interface*
- bloat
- dubious** interface labels, like "DOM" (or whatever) to look at the object's property tree
- totally sucked at debugging any part of the Gecko runtime/toolkit code, or anything that wasn't a Web page (including e.g. Firebug's own code)
* This is a misfeature that every browser's built-in devtools copied, and it's completely mystifying. Thanks, Firebug, but I want the script debugger to be separate from the DOM Inspector, so I can have both on screen at the same time (and I want to be able to have multiple inspectors for multiple objects open at the same time, too, for that matter, so I don't have to keep flipping back and forth between them like I'm navigating fullscreen mobile apps and being forced to think through a straw. I don't even use multiple large displays; I use a 13" laptop screen for everything. No idea why all the proponents of large, multi-screen setups don't bristle about this to an even noisier degree.)
** Generous description; "inaccurate" (or just plain "wrong") would be accurate
I think I just answered that. It's also a piece of software, not a person. The sort of criticism I gave (especially in response to a remark that described another piece of software as "horrendous") is imminently fair game.
As for persons, I like the decisions that Hewitt made when he made DOM Inspector before going on to do Firebug. It was like UNIX pipes (incl. that you can string them together to arbitrary lengths), but with dynamic visual inspectors on each side, instead of bytestreams/text. Firebug was not that. It was one step forward, two steps back.
My former employer is still using HTA (HTml Application) to dynamically render a lot of tool windows in their massive legacy COM application on Windows. HTAs render using an IE6-era renderer that is still present in Windows. (I wasn't in the group that built these tool windows, but I did build a lot of in-house web apps to help with various workflows.)
A few years ago, I had a colleague come by with bug he couldn't solve in an HTA tool window. There's no built-in console or anything... but I showed him how to copy/paste the Firebug Lite minified JS into a <script> tag, and how he could then press F12 to bring up Firebug Lite inside the HTA tool window. (Note Firebug Lite supported IE all the way back to 6). He was able to quickly debug & resolve the problem.
Firebug Lite enabled debugging directly within the tool window -- i.e. the Firebug UI appeared on the bottom edge of the HTA UI area (not a remote debugging scenario).
Firebug is what made HTML, CSS, and JS click for me. Seeing a website interactively update as you made changes, as well as inspecting existing websites to see how they worked made all those concepts so much easier to grasp.
Firebug was a game-changer when I discovered it back in 2008 or so. I wasn't a particularly good developer then, and the complete lack of debugging tools made it even worse: alert("this thing happened!") was literally the only way to debug anything (that I knew of anyway).
Afterwards, IIRC, Microsoft released a debugger for IE built into Visual Studio, and later both IE and Chrome followed Firebugs footsteps.
I wasn't a particularly good developer then,
and the complete lack of debugging tools made
it even worse
Yeah! Before Firebug, I was strictly a "do it server-side" guy at all costs. The experience of trying to debug JS on any browser, let alone multiple browsers, was just a total crapshow. I was 10x, maybe 20x more productive server-side.
Firebug changed that. It truly paved the way for actually-sane client side development/debugging.
It is not an understatement to say that Firebug changed the world.
And alert was incredibly annoying because it required interaction to continue and the log wasn't visible to provide history. When I got really desperate I would stick a <pre id=log> at the top of the page and then start adding lines to it.
Firebug is why I've been using Firefox as my primary browser since Firebug first came out. Firebug was such a huge game changer for web development. Before firebug we had to use alerts or writing to the DOM to debug. It is hard to imagine a web development world without Inspect, Console, etc., but that was the reality for many years. Then Firebug came around! Eventually Chrome added developer tools, but I was so used to Firebug that I never even tried Chrome. I was quite sad when Firefox created official developer tools and Firebug ceased to exist. It was hard letting go of an old friend who led the way.
In the beginning we used Show Source and Console. As web pages grew in size it became difficult to navigate the source code, and you still had no direct way to view how CSS was being applied.
The first web inspector that I used was Xyle Scope in 2004. It was an early tool based on Apple's new Safari engine. It was a few years before Firebug was released, and even then it took a while for Firebug to beat Xyle Scope in features.
I still have the lingering feeling that Xyle Scope's UI was better at directly inspecting HTML and CSS than our current tools. Although that maybe the haze of nostalgia. I found it hard to find any really good screen shots but here is one:
Of course, FireBug and its successors do so much more than just HTML/CSS inspection. I would often jump between Firebug and Xyle Scope. Eventually, Cultured Code the developers for Xyle Scope focused their talents on creating their Things task manager.
On this topic, and Chrome Dev Tools, does anyone else struggle with getting access to the state of their app?
I find that because of all the encapsulation and transpilation tricks, it’s basically impossible to get a hold of my state or functions in the dev tools during runtime. The best I can do is forcibly set window.state and do a bit of work.
I can set breakpoints and do all that stuff. But I remember back in the bad days when it was pretty easy to “find your app” from the dev tools.
I’m probably doing a poor job describing it, but does anyone else experience this?
It's a known problem, especially with the move away from self-styled OOP paradigms and the rise of closure-infested programming. (I.e., "OOP, but with closures—and which (for overall very bad reasons) we're going to insist on describing as FP".)
Recent thoughts by one of the Eve/Light Table developers:
I think Flash lost because it shot itself in the foot, Firebug or not.
Flash was way beyond the web stack of that time in pretty much every aspect, and it would still have some advantages even today if it was still supported.
But Adobe completely dropped the ball. The plugin was a buggy mess, which regularly topped the charts in term of vulnerabilities and accessibility was pretty bad, all fixable problems they didn't fix. Adobe also didn't work with browser vendors and web standardization bodies to improve integration, instead relying on the already obsolete nsapi. Browsers kept nsapi support just for Flash, but as some point, enough is enough. I believe that with a bit more care from Adobe, Flash could have been part of the web standards, and I think it would have been better that what we have now.
I don't know much about Silverlight but it looks like a Flash knockoff that didn't fix any of the core issue Flash had.
i think the greatest thing we lost with flash is even non-technical people making something in an editor, hitting export, and getting a single small file that worked similarly enough to an image that it was trivial to just upload somewhere and have it be embedded there.
This. I hated flash sites, but it gave non-technical people a chance to be creative. Designers especially loved it, though they often used it for wrong purposes (web pages) too.
But good luck teaching them how to make that tetris clone in React nowadays...
Flash is a shining example of the concept, “Faster than Possible”.
When all of the vendors have a similar product, you chose based on feature set and cost (not all costs are monetary). When only one vendor has an interesting feature set, you need to ask yourself why, and it it’s too good to be true.
Flash absolutely would have become more entrenched.
You get the feeling that Apple wasn't going to support Adobe's Flash plugin on the iPhone, no matter what. Too battery-inefficient, too laden with security holes. They weren't going to pour billions into the iPhone just to have it be a delivery mechanism for Adobe's mess of a runtime.
I see three alternate histories:
1. The iPhone launches without Flash, and it flops, because most of the Alexa top 500 is totally reliant on Flash.
2. The iPhone launches without Flash, just like in our timeline, and it's good enough that people still embrace it. Eventually this kills off Flash just like in our timeline, but it's a slower and more painful transition.
3. Apple agrees to support Flash on the iPhone, but only via an agreement with Adobe that lets Apple develop their own (safer, performant) Flash layer that stays in sync with Adobe's plugin via legally binding terms of the contract or whatever.
In two out of these three alternate histories, we're still stuck with Flash today.
"Too battery-inefficient, too laden with security holes."
Lol. The reason Apple didn't support Flash was it was too good. If flash was supported 100% (practically natively) - there would be no point creating native apps in objective C (Flash was a full decade ahead). Flash devs would have coded circles around objective C devs. This could have screwed over the entire ios ecosystem. Once flash was dead and gone: SWIFT!
> The reason Apple didn't support Flash was it was too good.
The competition with native may have been part of the consideration, but this was far from the full argument. It was also much too bad. It was power hungry, as noted by others, because flash content tended to be driven by a million timers, but also, its interaction model was a disaster on touch screens. Even on desktop, one of the problems with Flash content was confusion about whether UI events were owned by some object inside the Flash widget or the enclosing browser. Plus, Flash was a whole universe of nonstandard UI elements that would have made uptake of the iphone interface more difficult.
There is no part of me that believes the idea that "Flash devs could have coded circles around objective C devs." If the mobile app explosion had happened in Flash, it wouldn't have been an explosion. It would have been a flop.
The other perspective to add is historic: in the early days of the Macintosh Apple helped make Adobe Type 1 Fonts a printing standard and a deep OS level font standard and then Apple had a long relationship of depending on Adobe for binaries for Adobe Type Manager for core OS experiences. Adobe Type Manager had a long and interesting history, including and in particularly its huge share of OS-level, kernel breaking vulnerabilities. In OS X Apple paid Adobe to finally get the source code for ATM so they could do their own vulnerability reviews and own that code locally. Presumably at great cost.
(Aside: Microsoft got caught in the same proprietary "standards" problem having to ship Adobe Type Manager with Windows for just about the entire history of Windows and then eventually paying Adobe enough to get to the source code and fork their own version of it that they could entirely own for vulnerability scanning while maintaining backwards compatibility. Also presumably at great cost.)
It certainly seems easy to understand why Apple might have been hesitant to depend on yet another proprietary binary drop from Adobe as core OS service in iOS had they embedded Flash into iOS Safari given that expensive history already with Adobe Type Manager.
(Adobe may have indirectly killed Flash just by that history/reputation of being a bad, expensive vendor with tons of vulnerabilities and charging Apple and Microsoft an arm and a leg to fix those vulnerabilities.)
> The reason Apple didn't support Flash was it was too good
It wasn't good on mobile. And at that point it was barely good on desktop, too. By good we mean: power and memory consumption, security vulnerabilities etc.
You just don't remember how badly Adobe mismanaged the whole thing.
Internet Explorer 6 also had the Microsoft created IE Dev Toolbar that came out around the same time as Firebug (I think it was 6 months after?). It really was a powerful tool, but somehow not really well known in the dev world at that time.
I'm really sad that Microsoft put all thier eggs in the Chrome/Chromium basket, instead of continuing thier own engine, or supporting Firefox.
I think people forget that debuggers used to crash the IDE as a matter of course (and they didn’t auto save as a matter of course).
VisualAge for Java, the precursor for Eclipse, was the first IDE where the debugger was stable. However the editor would just up and crash instead, which is worse. Symantec had the first generally stable IDE in VisualCAFE.
I learned to obsessively type CTRL-S on word processors in college. But that came to adulthood with me because of shit IDEs. I’ve used Jetbrains for more than 15 years. I know it saves when it loses focus. And I still hit save about ten times a day.
Firebug was a godsend back in the day. I also used Firebug Lite pretty heavily which was a javascript file you could inject into your website to get a variation of Firebug working in browsers such as IE6
Being able to embed that in IE was just a total leap forward. Anyone who remembers the ambiguous "A JavaScript error occurred..." dialogs with zero helpful information will probably also remember the first time that Firebug gave you the actual location and file of the error. Breakpoints?! Amazing.
For sure. I think Firebug, Gmail and Google Maps are approximately of the same age and they all opened up a new era, showing the way to a more modern web. I am unsure if the Web 2.0 moniker applies to what happened around this time but I think it was around then too.
Isn't Web 2.0 the web with user-contributed content, i.e. social media? For me, being part of Web 2.0 would not be something to be proud about, it's the tech that brought uninformed, angry populist rage online...
I think Web 2.0 was more when the web became more interactive. Instead of only static web pages there were forums, UIs that responded to your actions, and early social networks (but not the modern monsters we currently have). It enabled them, but it wasn't strictly "Web 2.0".
That said, even at the time the definition was not really clear. I remember a joke, why Web 2.0 is like teen sex... Everyone is talking about it, almost noone is doing it, and even those that are, are probably doing it wrong.
Fun times. You could change the image without reloading the page. Woohoo!
It’s so weird to me when people use the phrase “fight the good fight (of faith),” without knowing the latter half of the expression or where it comes from.
It makes web debugging sound like a religious struggle.
I still remember where I was when I first learned about Firebug and how magical it felt. I can picture the open workspace I was in and another developer mentioning it to me. It was like going from console.log/print_r/var_dump/etc-ing to using a debugger to attach and step through code, just a night and day difference.
Nowadays we take the dev tools for granted but I'll always remember Firebug as the original dev tools and it being absolutely amazing for the time.
Firebug was a game changer in frontend development, suddenly everything made sense and things got a lot more simple.
Before firebug in the IE6 days, there was a script that you could inject into your page which created a draggable floating window in the document with a basic console and maybe some DOM view. I can't remember the name.
I'm still not sure whether adapting it as the main browser tool was a good choice. It would've been interesting to see various extensions working with e.g. a deep-internal API. Probably with none installed by default, making the browsers a bit more modular.
I still miss the possibility to `console.log` functions and have a clickable log that automatically open the right source at the right line, something that it's still not available on "native" `console`s
Can't you click on the filename/number on the right hand side? That works for me in Chrome. Source maps even allow it to open to the correct file inside Chrome.
In Edge Dev Tools (so I'm sure it is similar in Chrome Dev Tools) it doesn't show source/line information in the log message directly (though it does have a link to the source line for the console.log message on the far right), but right-clicking a logged function includes a context menu choice for "Show function definition" which will jump to addStuff's declaration on line 1.
From my point of view it was really a game changer. The first time debugging and understanding web-applications became accessible. Probably all browser dev tools were inspired by this tool