Firefox for Power, Safari for Stability

Okay, so I've been doing quite a bit of development on this site and my church web site at home. When in Linux, I always use Firefox. It's convenient and has all the tools I need for web development, which is nearly all I do at work. On Linux, it's also pretty solid---not rock solid, but I use a heavy load of plugins.

However, at home, I do a combination of blogging, reading email, sorting photos, Bible study, etc. in addition to the home development projects I work on. When I'm browsing the web for anything other than development, even research for development, I nearly always run Safari. However, when working on web development, I nearly always use Firefox (except to test how things look in Safari. Why?

On Linux, Firefox is pretty solid. On Mac OS X Tiger, it's rock solid, but it bogs down and eats up the memory of my poor little Mac Mini if I do much with it. When I'm doing development, I usually try to close out everything I don't need and cope with the shortness of memory (which is really the problem since my Mini isn't fully upgraded in that arena). Safari, on the other hand, is rock solid and lightning fast all the time. It doesn't bog down, but it doesn't have all the tools I use in Firefox that make web development go so well. Anyway, I use both very heavily and flip between them pretty regularly.

The moral? I don't really have one, I'm just saying that's how I work and since I'm in blogaholic mode, I felt like a writeup on the topic. However, while I'm at it, I will recount my absolute favorite Firefox extensions, which are the reason why I use it for development. If you read any of the following be sure to read the first and last bullets!

• Web Developer. This is a must have for any web developer. It places a toolbar menu in Firefox which allows for quickly testing forms, discovering form details, live editting of CSS, turning on/off plugins, clearing authentication data, and learning other information about a page.
• Colorzilla. This is a prerequisite for web design. It gives you an eyedropper you can use on a page to figure out what any color is. I've had a few problems with it over the last few months claiming that my browser wasn't supported (when it worked before, bah), but that seems to have been fixed now.
• Aardvark. Ever want to know which parts of the page are in which boxes and what tag that is or what the class is? Once started, it visually highlights and names which box your mouse is hovering over. I use this in situations when I just want to check real quick because there are a couple other options available for digging deeper.
• Google Toolbar. This isn't explicitly for development, but it does make getting to my favorite search engine a lot faster.
• Venkman. This tool is overkill for most the problems I face. This is a full debugger for JavaScript in which you can set breakpoints and really get into the guts of the JavaScript engine. I suspect this would be very useful for anyone building Firefox extensions, but it really is too much for debugging nearly any web page issue I've faced. I still have it installed, just in case.
• Google Browser Sync. Since I use many of the same resources at home and at work, this tool is very useful. It synchronizes my bookmarks and other data between computers and even allows me to resume a previous session if my browser crashes or if I just want to pick up where I left off when I move from the kitchen computer to downstairs.
• Firebug. This is the coolest plugin ever! It provides a nifty debug console that you can use with JavaScript by just inserting console.log() statements to your scripts. It shows a status bar widget that shows how many JavaScript or CSS errors have occurred on the current page since it was loaded. It contains a basic debugger that is much simpler and has just the right level of functionality for trying to work out the harder script errors. Finally, it has a very detailed inspector that has an Aardvark-like inspection feature which outlines boxes in the top pane while showing the tags in the parsed source in the bottom pane. This shows the DOM tree as it exists after your JavaScript has modified it as well, which is super helpful. You can drill down pretty far.