Frontend Friday: Tools of the trade

I’m finally pushing through with an idea I’ve had for a while: Frontend Friday! Every Friday, I will be posting an entry about frontend development work, which includes topics on HTML, CSS, JavaScript, and basically anything related to the implementation of designs and UI on the web. These may be simple solutions you might know about, or weird experiments and topics that concern those who code layouts, whether done as a hobby or as part of work.

For the first Frontend Friday post, I’ve decided to write about a topic that’s rather central for all web developers: the tools that we use. We all use different programs and extensions and scripts to help us code up a nice layout for our websites. I wanted to share some of mine, and I hope you find them useful.

My top 7 tools:

  1. Aptana Studio

    I’ve been using Aptana well over a year now, and in fact I wrote a review about the web IDE before. Because it stems from Eclipse, and Java, it suffers a bit of lag especially when working with large files; I wouldn’t recommend using it for that quick 30-second style fix on your website.

    But working on websites that contains quite a few bells and whistles, I find Aptana to be quite helpful. The Project pane stores all ongoing projects, the Validation tab is quick to look up typos which result in syntax errors, the Outline pane makes jumping between functions and HTML nodes a breeze, and Code Suggest is always great to have around. (You should take a look at my review if you want to know more; while that was for the beta version, it’s still relevant.)

  2. Firefox

    Yes, Firefox just had to be there. I will admit that as of late I’d been very frustrated with Firefox’s memory-hogging practices and annoying lag, and if it weren’t for Firefox being insanely great for web development, I might have dropped it for the faster Safari. Firefox is a great standards-compliant browser, plus it provides an avenue for a plethora of web-developer-friendly tools, some of which are…

  3. Web Developer Toolbar

    Chris Pederick’s Web Developer Toolbar is impossible to live without. It’s lightweight and contains a lot of helpful tools: disabling cache to make sure you see your CSS updates, cookie manipulation, CSS lookups, markup and style tools for debugging, browser resizer, viewing generated source (for all those whizzy JS things), and more. If you’re a developer and you don’t have this on Firefox yet… what cave have you been living in?!

  4. Firebug

    Actually, Firebug vied with the Web Developer Toolbar for the “must have” spot, with the toolbar winning simply because it’s lighter and more mainstream: even if you’re a hobbyist making personal websites during your free time, the toolbar is useful. Firebug is also a must-have, but mainly for more heavy duty stuff, and especially for debugging purposes: completely clueless what styles are messing things up on a certain element? Lost as to what is happening to your variables when running JS? Firebug makes digging into code easy. I can’t count the number of times Firebug has saved me hours of trawling through CSS or numerous alert() calls.

  5. Multiple Internet Explorer installations

    There are numerous multiple IE tools out there, but the one I personally use on my Windows test machine is TredoSoft’s Multiple IE. I really only test for IE6 and IE7, though (I should install IE8 soon, too…). It’s a bit of a pain, but that’s the way life rolls. The IE Developer Toolbar is also a must-have for IE-proofing your website. I hope they update the toolbar to include a debugger soon.

    Naturally, you will also need other browsers installed, according to what you wish to test with. I test according to Yahoo!’s list of A-grade browsers, even for my personal work (well, in varying degrees, as I don’t have multiple images of Windows sitting in my personal machine, for instance).

  6. YSlow

    YSlow analyzes my pages’ load times. I typically only use this nearer to the end of development, to check if I need to combine more images into sprites, chunk together CSS and JS, etc. It’s definitely a good guideline checker for webdev best practices, which may or may not be critical for you, depending on what you are working on.

    YSlow takes into consideration Yahoo!’s rules for high performance websites, which every web geek into making websites should read through at least once.

  7. Fiddler and/or Tamper Data

    These two are mostly useful for deeper digging into the communication between your website and the server, and may or may not be applicable for the type of work you do. I find it highly useful for verifying form submissions’ raw data and AJAX requests — you can stop the data transmission, fudge up the content, and release it, which helps you trap bugs and issues.

    Tamper Data is a nifty Firefox extension for this purpose, and Fiddler is an HTTP debugger tool, much more robust than Tamper Data. Unfortunately, Fiddler is not available on Mac OSX — I’ve been looking for a good alternative for a while now (Paros looks like an interesting alternative, but for some reason I can’t get it to start monitoring traffic).

So those are the top 7 tools I use for working with code. What are yours?

4 comments

  • Thank you!

    Yeah, that happens–see my response to Matt’s comment above :) For QA teams and testers I’d definitely push for a VM to test things on, but when doing development work, Multiple IE is good for quickly cleaning things up without needing all that resource used up. Like I mentioned, a last pass in a VM instance is still the best bet. :)

  • I’d disagree about the use of Multiple IEs. I’ve experience so many issues with our QA team at work logging a bug for an issue that only happens in that version of IE. We just use the free virtual machine version Microsoft gives out for free now.

    I’m loving your blog, though.

  • Thank you, Matt! Running VMs simply for IE is a pain, and something I’m having to do when I’m working on personal projects at home (since I only have one machine–my MacBook). I’m thankful I don’t need to run more than one (due to Multiple IE), and that at work I have a separate Windows machine.

    However, there are drawbacks–sometimes I do notice a few discrepancies between a “real” IE6 and one from Multiple IE. So while it can help you fix most issues without firing up a VM or going to another computer, your last check should still (ideally) be a “real” installation of your target version.

    Good luck!

  • matt h said:

    Hey Angela, found your blog via a recent YUI Blog comment you made re: “Production JavaScript Debugging”. Love the idea of a Front-end Friday, got you bookmarked, looking forward to seeing what you post up.

    Didn’t know you could have multiple IEs outside a VM, so thanks for posting about TredoSoft’s Multiple IE.

«