Thomas Fuchs
Hi, I'm Thomas Fuchs. I'm the author of the script.aculo.us user interface JavaScript library, a member of the Prototype core team and a Ruby on Rails core alumnus. You're using my work every day, even if you're not aware of it (sounds creepy, I know!). Need JS foo? Hire me.

Why I use Safari for Development

July 9th, 2009 by Thomas Fuchs, 59 comments »

For web developers, there’s an obvious choice of which browser to use for developing web applications. Firefox it is, right? Wrong.

Standards, schmandards

Let’s compare the two browsers, more specifically Safari 4 vs. Firefox 3.5. Both browsers pass the Acid2 test with flying colors, but when it comes to Acid3, Firefox only reaches 93% compliance (up from 71% in Firefox 3.0). Safari? 100%.

Acid3 on Safari 4

That’s a pretty good start for Safari. Basically, if some HTML/CSS works on Safari, the chances are very high it will work on Firefox 2 and higher, and on IE 6 and higher (with minor tweaks).

Development tools

Firefox comes with no development tools, but it’s easy to install Firebug, the de-facto industry standard for HTML inspection, CSS munging and JavaScript debugging. But Firebug has been haunted by bugs lately, and the new 1.4 series is still in beta. Moreover, it feels a bit tacked-on and sometimes just fails to work or becomes unresponsive, or slows things down (hopefully this will be resolved in the 1.4 final, overall Firebug was one of the awesomest things ever for web developers, and I don’t ever want to go back to the days of alerts).

Firebug 1.4 beta network panel

On the plus side, there’s some really great additional plugins like YSlow and Smush.it. I tend to use those independently of the main development cycle, as these tools are more for deployment optimization anyway, so they don’t really play into the development of the web app as such.

Safari 4 Resources Panel

Safari comes with everything you need installed, and the tools themselves are very stable. And they even look nice, which makes debugging less of a drama. I especially like the Profiler, which has features not found in Firebug that come in really handy if you’re doing advanced JavaScript. The tools are very well integrated and are part of the application instead of an add-on, which also means they can access the browser/network data on a deeper level then Firebug can.

Safari Console Autocomplete

The console in Safari has some nifty features, foremost a well-working autocomplete implementation. Firefox has autocomplete too, but doesn’t show you the current option until after you hit .

The user interface is much more streamlined and cleaned up on Safari as well. The only gripe I have is that I’m not in love with the font the console and debugger on Safari uses (but I’m a font nerd).

JavaScript

And important (for me!) distinction between the two browsers is that Firefox messes with your JavaScript by doing a pre-optimization step on declaration. This means that:

function x(a){
  return 1*2;
}

will be automatically converted into

function x(a){
  return 2;
}

This change is not internal– if you to a x.toString() on the function source code actually has changed. I’m not very much in love with this automatic optimization step– I’d rather see this done by some kind of external tool, like the YUI Compressor, which does some of these microoptimizations. Neither Safari, nor Chrome or IE does that.

Quick, fix that bug!

I’ve done several bug reports to the WebKit project over the years, and all of them where eventually adressed (in big projects like this, it can be expected that non-critical issues might take a while to be resolved). On Firefox, there’s been certain bugs that have a long history of developer hairpulling and nailbiting. Here’s my favourite (Quote: “This bug reveals a problem in Mozilla post-release bug fixing. We have been made to wait 6 years for this bug to be fixed.”).

Note that I’m sure that the people working on the Firefox development team are working very hard (I know some of the awesome people who worked there!), and it’s more of a management issue.

Conclusion

I used Firefox since version 1.0 for my web development, but I’ve switched over to Safari for 99% of my development needs. I only go back to Firefox to make sure it works there and for some of the plugins.

Btw, I know that there are operating systems other than OS X out there. But I’m not using them for development, for several reasons, one of them being that OS X is the only system that allows me to test all major browsers side-by-side by means of virtualization software (I run IE6/7/8 in VMs), and have a Firefox on Linux VM, too. And the iPhone Simulator that comes with XCode runs only the Mac, of course. If you’re serious about front-end web development, there’s pretty much only one OS choice (Let the flamewars begin!).

Post to Twitter Tweet This Post Post to Digg Digg This Post Post to Facebook Share on Facebook

59 comments »

JavaScript Rocks! Peformance ebook
Do you run a web site or web application? Do your users a favor, and grab our ebook on JavaScript performance. Profit from our knowledge gathered in over 15 years of working with the Web and JavaScript and make your sites ultra-fast and your users ultra-happy.

59 Comments on “Why I use Safari for Development”

  1. 1 Enrico Foschi said at 11:54 am on July 9th, 2009:

    Great post. I always thought that the Firebug console was performing a pre-optimization on the JS.

    What do you think about using Safari 4 in a Windows environment, rather than in a osx one?

  2. 2 Simon said at 12:39 pm on July 9th, 2009:

    The only thing that sucks about safari, is you can’t get at the http headers to see what result is being sent.. .
    but i use it all the time too because its just damn quick.

  3. 3 Thomas Fuchs said at 12:44 pm on July 9th, 2009:

    @Simon: If I need to get down to that level, I ouse the Charles web development proxy app, which works great with Safari and Firefox.

  4. 4 andreas said at 1:10 pm on July 9th, 2009:

    very interesting post. i’m just a js lib user, not a js dev (i’m mainly writing the backend stuff) – but from time to time i need to debug some js.

    i used firefox and firebug for this, didn’t know safari has serious dev tools too. i just switched to a mac 4 months ago (after 5 years of linux – love it!) so i use this as an excuse ;)

    after your post i’ll try to find out all the beautifull debug methodes of safari.

    best wishes from the 9th district,
    andreas

  5. 5 Ron Derksen said at 1:12 pm on July 9th, 2009:

    I second Enrico’s question. At work I can’t use a Mac, so I’m also wondering if Safari 4/Win differs much from Safari 4/OSX.

  6. 6 Andreas Windt said at 1:54 pm on July 9th, 2009:

    i currently switched to safari for development too.

    that new “fastest firefox ever” is – at least together with latest firebug (betas, i know) – as fast as microsoft’s “fastest browser in the world”

    [btw. i am using safari in a windoof environment.]

  7. 7 Damian said at 1:58 pm on July 9th, 2009:

    The Safari Web Inspector has improved a lot but there are still things that it can’t do (or I can’t find how to do.)

    For example adding HTML to an existing page. I find this very useful with Firebug for mocking up features.

  8. 8 dude said at 2:21 pm on July 9th, 2009:

    @Ron: Time to find a new job. Doing web development and they wont let you use a Mac? Deal breaker.

  9. 9 David Strauß said at 2:28 pm on July 9th, 2009:

    Interesting post, I will give Safari also a try — on a Windows environment. Because Firefox is behaving sometimes really strange since the last update..

  10. 10 Tim said at 2:29 pm on July 9th, 2009:

    I’m not sure what the point of the Acid3 comparison is. Can you point to an actual case where 100% on Acid3 helped you solve a problem that a mere 93% on Acid3 didn’t?

    Acid3 is not exhaustive, nor was it intended to be. Several features I use in the standards are better supported in Firefox, but didn’t happen to be in an Acid* test yet.

    In other parts of this page, you ignore raw numbers and look at actual features, e.g., discounting the huge number of Firefox extensions and looking at actual functionality. But for Acid3 you ignore specific features and simply play the numbers game. This strikes me as choosing, per-paragraph, whichever method is more convenient to make Safari look good, i.e., rationalization of a choice, rather than analysis of a situation.

  11. 11 Jim Neath said at 2:33 pm on July 9th, 2009:

    Funnily enough, I’ve recently moved over to Safari for my development needs.

    Firefox was constantly beachballing and it was become far too annoying to cope with.

    I had been using Firefox since it was Firebird 0.7.

  12. 12 revetkn said at 2:43 pm on July 9th, 2009:

    @simon – you can see request/response headers in the webkit inspector. in the resources view, click a resource in the left-hand pane. the main pane then shows details about the resource, including header information

  13. 13 Thomas Fuchs said at 2:57 pm on July 9th, 2009:

    @Tim: My comparision method is certainly not scientific, and it’s not intended! It’s just my opinion.

    The huge number of Firefox extensions doesn’t help me with development though (most of them are for pro users), Safari includes all that I need (except for deep header inspection, but I use Charles for that).

  14. 14 Sean said at 3:09 pm on July 9th, 2009:

    That’s an artificial advantage – that OSX is the only OS capable of hosting every browser. That’s only because OSX can’t be run (legitimately) on vanilla x86!

  15. 15 Zach Bailey said at 3:09 pm on July 9th, 2009:

    Great write-up, Thomas. Especially on OS X I feel like Safari still offers the superior experience for day-to-day browsing, although Firefox has gained a lot of ground in terms of launch/rendering speed from the 2.0 days.

    However, I do have to nitpick and say for some specific use cases, Firefox + Firebug is still superior to Safari and its developer tools (when it works as it should. The 1.4 betas have been awfully buggy as of late).

    A lot of times I am tasked with reworking or adding items to an already existing page, and then (re-)styling the page. In this case, Firebug is vastly superior to Safari because of the following features:

    * Firebug allows you to directly edit the markup from the “inspect” window. For instance, I can add a class name, or click “Edit” and then type whole new snippets of HTML anywhere I want. I am not aware of a way to do this in Safari’s developer tools short of using the JavaScript console which you can agree is far clunkier than how Firebug does it.

    * Firebug also allows you to directly style specific elements by right clicking and selecting “Edit Element Style…”. In effect this allows me to style that specific element. Like the above use case, I’m not aware of a way to do this in Safari short of using JavaScript.

    These two items may seem like pretty minor shortcomings of Safari but I find myself using them a lot in day-to-day development work when I am doing front-end development.

    Cheers!

  16. 16 Thomas Fuchs said at 3:19 pm on July 9th, 2009:

    @Zach: You can doubleclick an HTML element in Safari’s Web Inspector and add a style=”blahblah” attribute or edit the existing one for styling a specific element (works only for elements that already have at least one attribute). I agree that the HTML view could be a bit more powerful, hope they’ll continue to add to it!

  17. 17 Andreas Windt said at 3:47 pm on July 9th, 2009:

    best issue i have from time to time on firefox: i quit it, but i see its process running on and on for minutes, cpu usage at about 50% and blowing itself up to about 1,5 gigs of ram. that is, after some simple browsing sessions :-(

  18. 18 Carsten Nielsen said at 4:07 pm on July 9th, 2009:

    I couldn’t agree more, great post!

  19. 19 Ryan Shaw said at 4:54 pm on July 9th, 2009:

    I second what @Zach said. I would love to use safari for development but seriously the 2 deal breakers are not being able to *edit* css styles. so for any webkit / safari team members out there, my wishlist:

    1. let me edit the css styles for a specific element. (easily, like firebug lets me, not by having to try to add a style=”" attribute like @Thomas talks about.)

    2. let me edit the style properties of a css stylesheet rule, like in firebug. ex:
    if I have
    .some_selector {
    color: red;
    }
    in my sylesheet, let me change that color to black or add “margin: 10px” or whatever I want to that rule.

    3. this is a bonus if you want to leapfrog firebug. let me create stylesheet rules on the fly and assign properties to them. so, while I am looking at the page I can say “I wonder what would happen if gave all the h4s on the page an underline and increased their font size to 1.8em” and then I could just create a style h4{ text-decoration:underline; font-size: 1.8em;} and see it in action. (see jquery.rule for more of what I am talking about here)

    With those, then I really would start using safari for development.

  20. 20 Noor said at 5:03 pm on July 9th, 2009:

    Well, I like Safari’s developer tools, but tend to use them less frequently, because I’m kinda used to Firebug.

    And I must agree with your point, that Firefox does some pre-optimization on declarations, and I hate it when it messes with my JavaScript.

  21. 21 Eevee said at 5:10 pm on July 9th, 2009:

    Hm.

    I’m not sure how “Safari does better than Firefox on Acid3″ leads to “anything that works in Safari probably works in Firefox”. Shouldn’t that be the other way around? (Note this is not the same as targeting IE6, as it’s outright wrong more often than it’s merely lacking features.)

    Why is it a problem that Firebug 1.4 is in beta, if it’s better than 1.3? Firebug 1.4 was targeted at Firefox 3.5, which was only just released; it’s hardly a surprise that Firebug doesn’t have a release yet.

    That’s a very pretty time graph Safari has, but I note that it uses up twice the vertical space per file without actually telling me anything more.

    I don’t understand what you’re getting at w.r.t. bugs. Safari bugs are “eventually” fixed, and you contrast this to a Firefox bug that was.. fixed over three years ago? As I recall, the caret painting problem required a fairly large overhaul of caret handling, so yes, “non-critical issues might take a while to be resolved”.

    There’s pretty much only one OS choice for Web development because only one OS has hardware-level lock-in. Fantastic. Even Microsoft *gives away* images containing various versions of IE for Web developers. I think I’ll stick with a platform that doesn’t try to play dirty for market share.

  22. 22 chap said at 5:56 pm on July 9th, 2009:

    Thomas, what do you use to install and run multiple versions of IE in the VM?

  23. 23 Ross Boucher said at 6:08 pm on July 9th, 2009:

    Thomas, glad to see another user of Charles. I love that app (despite some of its major UI flaws).

    Safari has been the only way to go for some time now, in my opinion. Primarily because its so damn fast. Still much faster than FF3.5. And the profiler is now unrivaled in its usefulness.

    Watch out for Chrome though, by the end of this year, I suspect we’ll all be using that.

  24. 24 Thomas Fuchs said at 6:30 pm on July 9th, 2009:

    @chap: I use multiple VMs… :) It’s kind of awkward how much disk space those use, but it’s the only way to have environments that are not “hacked” in any way.

  25. 25 Casey said at 6:33 pm on July 9th, 2009:

    @Chap, VMWare should be able to convert virtual pc images to a vmware native disk. Microsoft provides free VPC images for IE development.

    http://www.microsoft.com/downloads/details.aspx?FamilyId=21EABB90-958F-4B64-B5F1-73D0A413C8EF&displaylang=en

  26. 26 Mark Rowe said at 6:43 pm on July 9th, 2009:

    If there are any enhancements that you feel could make WebKit’s web inspector more powerful, please take a few moment to file a bug report about each of them at http://webkit.org/new-bug

  27. 27 KirinDave said at 6:56 pm on July 9th, 2009:

    To people saying that Webkit Inspector doesn’t give you access to http request headers up near the top (Simon, et al.), have you even bothered opening the resources pane?

    Webkit Inspector’s resources pane is mostly a win over the Firebugs net pane. It’s the CSS attr handling and the sizing issues and the awkwardness of some of the command line placements that are a problem.

  28. 28 Sevastos said at 7:16 pm on July 9th, 2009:

    Nice, i’m going to try it for a while. As for the IE testing you can use http://www.my-debugbar.com/wiki/IETester/HomePage it’s awesome and you can test from IE 5.5 to IE 8 within one program.

  29. 29 Random Links #7 | YASDW - yet another software developer weblog said at 7:47 pm on July 9th, 2009:

    [...] Why I use Safari for Development: Das klingt interessant, schaut wirklich so aus, als währe Safari derzeit die beste Wahl… [...]

  30. 30 William Harris said at 7:53 pm on July 9th, 2009:

    “OS X is the only system that allows me to test all major browsers side-by-side by means of virtualization software”

    Wrong.

    Insert Virtual Box

    http://www.virtualbox.org/

    I’m not even going to try arguing about the rest though its just flame bait you know it lol.

    In my opinion though as you yourself has said Firefox still has Safari beat in plug-ins you know you can’t live without stuff like Url Params and Measure It.

    Safari is nice but its still got a ways to go.

  31. 31 Thomas Fuchs said at 7:59 pm on July 9th, 2009:

    @William I actually use VirtualBox for some virtualization needs (e.g. I’ve a clone of our production server setup on 64-bit Ubuntu running in a VM). The “problem” is that you’re not allowed to run OS X in a virtual machine (except for the server version). Which means you can’t run it on virtualization software on Windows or Linux.

    Not that I would switch, I like use a Linux-like system with a high-performance GUI and apps like Photoshop available (=OS X)…

  32. 32 Thomas Fuchs said at 8:00 pm on July 9th, 2009:

    @Mark Thanks for all the hard work Apple’s WebKit team and the contributors put into Safari. It is very much appreciated.

  33. 33 Ryan Shaw said at 8:13 pm on July 9th, 2009:

    @Mark I put in a feature request: https://bugs.webkit.org/show_bug.cgi?id=27124 thanks a lot! It’s cool to know you guys are listening.

  34. 34 Hannes said at 8:17 pm on July 9th, 2009:

    not allowed to run OS X in a virtual machine does not mean you can’t run it on virtualization software…

  35. 35 Rob Saurini said at 9:35 pm on July 9th, 2009:

    Have you tried Opera 10’s dev console? It’s remarkably like FireBug, but without the slow-downs. It’s a little prettier too and since Opera 10 also gets a 100 on the Acid3 test, it’s worth checking out.

  36. 36 Bob Spryn said at 10:10 pm on July 9th, 2009:

    +1 for Ryan Shaw’s points. Until I can edit css styles directly and easily in the webkit inspector, I’m totally lost. I use that ALL the time. If you aren’t, you should be! It takes SO much time off styling things to be able to prototype right there. Webkit does a little of this, but not enough.

    Also, give me hotkeys. I want to be able to pull up the magnifying glass and inspect elements in one keystroke (ala apple-shift-c in firebug).

  37. 37 Ben Heath said at 11:44 pm on July 9th, 2009:

    I loved your article and became very anxious to give Safari a try. I’ve been using Camino, and Firefox for debugging, but Safari just seemed a lot slower. This is on an iMac 3.06 GHz 4GB with leopard 10.5.7. I wouldn’t have minded a little slower, but thought it was significantly slower.

  38. 38 Maciej Stachowiak said at 12:20 am on July 10th, 2009:

    You can edit both styles and markup in the Safari Web Inspector. Just double click to edit.

  39. 39 Thomas Fuchs said at 10:00 am on July 10th, 2009:

    @Ben: I think I’ve seen slowdowns when debugging very large JavaScript files– if you’ve long JavaScript files (>2k lines or so), try splitting them up in seperate files, and using a tool like http://getsprockets.org/ to concatenate for production. Note that this is a good idea even if debugging is fast… :)

  40. 40 Double Shot #493 « A Fresh Cup said at 10:54 am on July 10th, 2009:

    [...] Why I use Safari for Development – Sales pitch from Thomas Fuchs. [...]

  41. 41 Alexander Kellett said at 11:36 am on July 10th, 2009:

    @maciej, its still far less usable than firebugs file editor. its the only major thing that firebug does better.

  42. 42 Stephen Sykes said at 12:24 pm on July 10th, 2009:

    I use Safari mostly too. But Safari 4 has a huge misfeature – I can no longer select from a complete list of url completions when typing in the address bar.

    Now it only gives 8 options. That’s useless. I used to just type loc and be able to choose from all the pages I visit on localhost.

    Sigh.

  43. 43 t3n-Linktipps: Gratis E-Commerce eBook, FireQuery, Entwickeln mit Safari, Easy-Retweet-Button, ubucon 2009, Ubiquity 0.5 » t3n Magazin said at 2:42 pm on July 10th, 2009:

    [...] Autor von script.aculo.us und Mitglied des Prototype Core Teams, Thomas Fuchs, plädiert für die Web-Entwicklung mit Safari und erklärt dabei, warum er von Firefox auf Apples Browser umgestiegen [...]

  44. 44 Nando Vieira said at 3:56 pm on July 10th, 2009:

    I use Safari exclusively since Leopard’s release and I think it’s great!

    About the HTTP Headers inspection: I use a free app called HTTP Client ~ http://ditchnet.org/httpclient/

  45. 45 Marijn said at 5:25 pm on July 10th, 2009:

    The fact that you can’t see the request GET/POST data is a huge defect in my opinion. Yes the headers are visible but that doesn’t include the actual GET/POST data you sent to the server.

    Installing another app / plugin is not desirable. Let’s hope they include this in an update!

  46. 46 Marijn said at 5:29 pm on July 10th, 2009:

    BTW I just looked it up and it looks like this has been reported in December 2008 already. https://bugs.webkit.org/show_bug.cgi?id=22920

    So a little more attention to it might help! ;-)

  47. 47 Chris said at 4:31 pm on July 14th, 2009:

    “I run IE6/7/8 in VMs”

    IE6? Really? Are you required to make the site useable in IE6, or do you check it just to have a laugh? Because, if you’re required to make the site usable, it seems like you’d have to make it so simplistic that then you wouldn’t *need* any slick development tools and could just use notepad or whatever.

  48. 48 Thomas Fuchs said at 11:22 pm on July 15th, 2009:

    @Chris: Actually IE6 is a pretty capable browser, and in many ways a forefather of the modern browsers.

    There are tons of bugs of course, but if you’re avoiding those by using a cross-browser JavaScript library and not using certain CSS rules you can pretty much do anything on IE6.

    Nonewithstanding that, in our own pruducts we don’t support it because of the additional time required for testing a browser our users don’t have. But I do test for client work, and sometimes I’m surprised how well it can deal with stuff like animation.

  49. 49 Zegarki said at 3:00 pm on July 16th, 2009:

    I tried the Acid3 test with Opera and got only 85%. It’s still my favourite browser (it’s the fastest) but now I see why I need to view some sites in FF.

  50. 50 JT said at 2:53 am on July 20th, 2009:

    Firefox 3.5 + Firebug + Google Page Speed plug-in at this time cannot be beat. Period.

    There are many other plug-ins I use as well, but the two listed above easily make Firefox much better for development.

  51. 51 Alex Wayne said at 11:30 pm on July 28th, 2009:

    One other thing about Firefox I love is the box model diagram:

    http://beautifulpixel.com/assets/firbug_layout_editor-20090728-152815.jpg

    It’s so damn useful. Especially since you can mouse over each area and have it outlined on the HTML document so you know where your padding and margins and borders are falling very precisely, and adjust them accordingly right there.

    This is one of the biggest reasons I still use Firebug.

  52. 52 ardianzzz said at 9:28 am on July 29th, 2009:

    yeah, safari is cool…. but i using chrome…

  53. 53 Luca said at 11:47 am on July 29th, 2009:

    @Marijn
    youre right.
    i dont, and iwont use safari developer tools only for this lack.
    too much important for me.
    i hope it will fixed soon.

  54. 54 itkin said at 1:05 pm on August 3rd, 2009:

    hi !

    Safri dev tool look definitely nice , but 2 thinks make me craisy
    - first the “focus” html button is not really well positionned and quite little, is there any shortcut to launch this functionnality?
    - second the css rules are not associated with the line they are defined but only with their file, this is clearly anoying when you have large css files

    Except theese 2 points i would adopt safari which is far more quick to serve pages, than firefox.

  55. 55 Kjell said at 8:41 am on September 1st, 2009:

    Yup, i would love to switch but i am soooo used to some extensions… It’s crazy.

    Those are more design related, but where to draw the line these days anyway..

    @Thomas:
    - What (if) do you use as a replacement for EditCSS? The realtime editing of CSS in Safari Panel is alot harder than with FB. Very small inputs and TAB jumps to “search”.

    - ColorZilla Replacement? I often just pick the color right from the page for copy/paste rather than scrolling around in some CSS file to find the value. (yeh, i’m lazy like that;)

  56. 56 Shane Mingins said at 10:08 pm on September 18th, 2009:

    Thanks for this post Thomas, it actually got me back to looking at the Web Developer tool on Safari this morning which highlighted a bug I was looking at briefly yesterday. Owe you a beer :-)

  57. 57 Karl said at 12:45 pm on September 26th, 2009:

    “OS X is the only system that allows me to test all major browsers side-by-side by means of virtualization software”

    This is untrue. I use a linux host and using VMWare run OSX and Win VMs. Granted you need a recent processor with VT enabled but this lets you run a decent, uncrippled OS primarily and only dip into OSX or Windows when necessary.

  58. 58 Thomas Fuchs said at 4:16 pm on September 26th, 2009:

    IMHO, “decent” and “uncrippled” are FUD. How is OS X not decent? :)

  59. 59 Dave said at 8:21 pm on October 10th, 2009:

    ….you’re dumb? The Acid tests are for future concepts, NOT current standards. Just because Safari wins the Acid3 contest does not mean it’s the best browser available. For 99.9999999999% of the HTML you will ever write, the Acid test won’t help you. Because it’s not testing standards. Do some fucking research before you go and insult the one browser out there that’s actually geared for web developers.


Leave a Reply