Why everyone should use Safari for rich web development

http://mir.aculo.us/2009/07/09/why-i-use-safari-for-development/

by ahoyhere • 17 years ago

63 66 17 years ago

mir.aculo.us

Micro-Optimizations are bad? That is just a load of shit.

If you can prove that Firefox's optimizations actually make incorrect results in any way, I am 100% behind whoever claims that micro optimizations are bad. However by firefox making them it means that I don't have to worry about the nitty gritty details about what order of instructions will perform better without changing the code. Or things like loop unrolling that don't have to be done in my checked in source.

Yea I think this argument is about 30 years too late...

If anything this proves FF3 is awesome.

Regarding web standards... As much as I am 100% for having good web standards, what good is adhering to a standard when no one can use it. I use the acid tests as an indication that browser x, y and z are browsers I want to be supporting. Unfortunately I always have to support IE... Sometimes even IE6, so acid tests are just nice-to-haves at this point. I just can't wait till IE7 completely dies (hopefully it won't be as long as IE6).

ahoyhere• 17 years ago

> However by firefox making them it means that I don't have to worry about the nitty gritty details about what order of instructions will perform better without changing the code

Actually, Firefox benefits the most from tweaks like this, because its engine is so slow. For whatever reason. That's why I thought this post was interesting!

GrandMasterBirt2• 17 years ago

A good point. If the FF engine is so slow it needs this, then the engine needs help.

However I see no reason why you should not be able to indicate to firefox that for this page do not optimize the javascript, then vuala good debugging. The only catch is that the optimizations need to be proven to be correct in all cases.

Once we have Safari for Linux I will consider using it as the main browser...

Scratch that, once at work we officially support it ill consider it :)

rufo• 17 years ago

Micro-optimizations aren't bad for users, but they can be bad when you're debugging. The source code you wrote is not necessarily the source code that Firefox displays to you.

beamso• 17 years ago

I use both Safari and Firefox for my web development. Safari's web inspector has a nicer user interface for javascript debugging, but Firebug has better support for editing CSS on the fly.

ROFISH• 17 years ago

It took me awhile to figure this out, but if you double click on the element styling you want to add additional CSS to (for example, the right column shows #content p has "color:#bbb;", double click on the "color:#bbb" part), add semicolons and the new style after the old one. (with the example the single line textbox should have "color:#bbb;padding:2em;") It'll correctly parse and add the new styling.

robotron• 17 years ago

Except that Safari has not been released for the operating system that I do web development under. So no.

trezor6• 17 years ago

According to the author that just means that you are using the wrong OS for web development, because despite how the world wide web is supposed to be platform independent, there is only one OS for web development</sarcasm>.

Besides a few profiling tools, his list of arguments seems to boil down to "things are prettier in Safari". Maybe it's just me, but that's really not my number one feature when looking at development tools.

zimbabwe5• 17 years ago

Safari's available for Windows and the Mac. That means that 99% of computer users can use Safari.

Since when was "things are prettier" a bad thing? I do extensive Windows testing using browsers, and Safari's rendering engine is leagues ahead of everything else, its developments tools are more polished than Firebug and easier to figure out, and it's one of only two browsers that fully supports HTML 5. Firefox renders things shittily (even on the Mac, which has possibly the best rendering engine out there available for all apps by default, it fails Acid 3 at the moment, and while Firebug's great for some things, at other things it fails hard.

madrobby• 17 years ago

So what do you care for if it's not prettiness, speed or standards compliance?

uggedal• 17 years ago

Many (all?) of the browsers using libwebkit (uzbl, surf, midori, arora) contains the Web Inspector.

ruddzw• 17 years ago

"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)."

I don't get it. A lot of the hardship that comes with web development is that stuff that works great in modern standards-based browsers like Safari doesn't work when you try to view it in IE. I can't count the number of times I've taken a webpage that I developed to work in Safari (or Firefox) and seen it break completely in IE. And it often takes more than "minor tweaks" to fix it.

rickharrison• 17 years ago

Yea this line also baffled me. I love safari and I use it for my development, but I didn't understand his reasoning behind this.

trezor6• 17 years ago

Indeed. Sounds very much backwards to me.

If anything, stuff developed to work with the restricted CSS-support in older MSIE versions (MSIE8 is actually not that bad) has a much higher chance of rendering correctly in Firefox, Opera and Safari than the other way around.

rimantas• 17 years ago

It may sound backwards but is it not. It is a broad topic and much can be said on this, but the short version is: it is always advisable to develop looking at more standards compliant browsers and then tweak it to work in IE. Usually it will take less effort.

The reason for this is that IE let's you deviate more from standards, and then fixing it for other browsers will take more time. Also, other browsers albeit having own quirks are much more consistent – that means that if it works in Safari it is most likely to work in Firefox and Opera too.

Of course IE does not support a lot of things other browsers do. Maybe it is time to weight you options there: are you sure you want site to look the same across all the browsers and is it worth the effort? Or can you live with simpler version for IE but gaining advantage of having to write and maintain less code?

Highly recommended site ;) : http://dowebsitesneedtolookexactlythesameineverybrowser.com/

lanaer• 17 years ago

If you happen to like inline-block (which I do), you’ll break FF 2 fairly reliably, as well.

encoderer2• 17 years ago

+1 for inline-block

ned• 17 years ago

I've always used -moz-inline-block for FF2, and it has worked for me so far, although PPK warns that it's not always the case: http://www.quirksmode.org/css/display.html#inlineblock

But at this point in time, I'd drop FF2 support (pixel perfection) for most projects.

emontero1• 17 years ago

Evidently, the author got a bit carried away there. The implication that just because your HTML works in Safari means that it'll also work in IE or Firefox with "minor tweaks" is simply bogus. Anyone with any significant web development under his/her belt would vehemently disagree. I think the author is just an ardent Safari user. That's all good and dandy if you ask me. However, we should call it for what it is: that was a blanket statement. As such, it lacks verifiable, factual information.

mikeyur• 17 years ago

The only way I can see this is when talking about Firefox. I have built stuff using Safari and when I test it out in FF my padding is off by like 5 px or something silly.

Using another browser like IE usually breaks the whole thing.

arohner• 17 years ago

I'm new to web development, and I keep asking this question but I've never heard and answer to it:

What's stopping us from making a tool that parses HTML/CSS and points out constructs that are known to be bad in certain browsers? Sort of like lint: "It looks like you're sending element foo inside element bar to IE6. This probably won't work right"

I personally don't have a windows box to test IE, and I'm not looking forward to the day when I'll have to test on IE. Surely there is a better solution than manually testing browsers?

wooby• 17 years ago

It would be cool to have HTTP proxy software that did this. So you set it as 'ie6' and it looks at your CSS and HTML and translates it into the "ie6 view" with problems annotated.

chaosmachine• 17 years ago

I suspect this kind of thing is a lot harder than it sounds.

There are a few things you could catch, like CSS features that just don't exist in IE6, but trying to predict if your particular mix of content+HTML+CSS is going to "look wrong" when viewed in IE is not a trivial problem.

lhorie• 17 years ago

You could probably match some patterns, but things can get really complicated when you introduce javascript into the mix. All of a sudden your tool needs to test every button on a page to make sure your ajaxed data tables won't blow up your layout.

Also, web development tends to push the envelope often. I've built literally hundreds of web sites / apps and I still come across nasty unexplicable post-ajax redraw bugs in IE6 that I've never seen before (using markup that I used to consider "safe", but which turns out to break under a new novel condition).

treyp• 17 years ago

have you heard of ie7-js? it uses javascript to fix many such problems.

http://code.google.com/p/ie7-js/

jonny_noog• 17 years ago

I realise you're hoping for a better solution than manual testing and I can assure you, so is everyone else. However, if you do not have a real or virtual Windows box to test on, you might find these links of interest:

http://www.browsrcamp.com/

http://www.browsercam.com/

Maciek416• 17 years ago

I really want to use Safari for debugging but every time I get down to trying to do so, I find some irritating hangup in terms of clunkiness and polish versus Firebug, and I end up heading right back to Firebug. Two things off the top of my head:

1) console output is just not as good as Firebug. Example: try going on jquery.com and doing console.log($("p")). Instead of a pretty printed array with styled items as in Firebug in the form of <p>, with all their classes and ids and visibility status hinted in the rendering, you get an expandable HTMLParagraphElement object (and its name doesn't even respond to a click..). If you expand that, the first thing you see is a big list of DOM constants like DOCUMENT_FRAGMENT_NODE: 11, etc. In Firebug these are sorted, filtered, censored to fit to the way web developers actually work.

2) I've never been able to resize the Console/Debugger when displayed as a split pane in the Windows version. In OS X, it seems to work, but in Windows, nothing. Again, a huge irritant when you're trying to get a better look at something that's gone wrong.

Nit picks? Yes. But some of us work with these things many hours a day. Workflow issues and missing little details like these prevent my uptake of the otherwise very impressive developer tools in Safari.

jpcx013• 17 years ago

I totally agree. These small issues have also caused me to drop Safari dev tools in favor of Firebug.

m0th87• 17 years ago

I'm developing a web service that spits out json. I dropped Safari immediately because it automatically downloads anything that is application/json, whereas Firefox will display it and syntax highlight it with the JSONView plugin [http://ajaxian.com/archives/jsonview-json-browser-from-withi...].

Despite the great improvements Safari has made with respect to its developer tools, it can't top Firefox's amazing third-party plugin selection.

halo• 17 years ago

I don't really find these arguments compelling.

Using the Acid3 test in this context is misleading. Acid3 tests a random selection features to ensure they work corrrectly. In this case, Firefox 3.5 fails on 7 of the tests and 5 of these are due to SMIL (pretty much SVG animation) and SVG fonts. They are obscure features, and don't provide a compelling reason to choose Safari over Firefox, least of all for development where you won't be able to use those features in the real world until other browsers implement them. Whatsmore, in designing Acid3, Hixie deliberately picked on browser bugs so the test didn't favour one vendor, irrespective of how they effect the real world - taking a single number out of context and point at that to prove the innate superiority of one browser over another, or that one browser follows "better standards", is incredibly simplistic, let along drawing conclusions that sites will be easier to port because of it. At worst, all it could tell you is that one vendor is focusing on passing a test and another isn't.

I don't really see the pre-optimisation as a real-world issue, and I seriously doubt bugs creep in through it. It feels very much like somebody making a problem out of nothing.

All projects have long niggles and bugs that have been there since the dawn of time. The fact that Firefox has bugs spanning years is more of a sign that the Mozilla project has been around for years than inehrent tardiness.

I also don't really understand the conclusion that "OS X is the only system that allows me to test all major browsers side-by-side by means of virtualization software". In actuality, if testing is your priority, then Windows would probably be the platform of choice as it's the only platform that can run all the major browsers (IE6, IE7, IE8, Firefox, Safari and Chrome) natively. Linux can also virtualise all the browsers not available natively through virtualisation of Windows, no different from Mac OS X.

jonbwhite• 17 years ago

Arguably, the only reason why OSX could be considered the only system that test via virtualization is that Apple makes it illegal to virtualize OSX in the first place.

costan• 17 years ago

I believe the license says you have to run OSX on Apple-labeled hardware. So as long as you use a Mac Pro / Macbook... :)

dtf• 17 years ago

OS X is the only system that can run a virtualized IE?

edw519• 17 years ago

OK, maybe I'm stupid or slow, but there's something I just don't get about "browser wars".

Exactly where does it say that HTML, CSS, & Javascript has to be source code? If browser differences cause you so much grief, why don't you just treat whatever goes out to the client as "object code" of your own engine.

That engine would have to create a different page for each browser that you decided to support. Sure, it would be 4 times the work for every page, but that's work done by your engine, not you. Browser differences are accomodated through maintenance to your engine, not every page or library.

IE is not going away any time soon, so your output better be able to handle it's DOM. While you're at it, take a look at your user's resolution as well, and serve it the way they want to see it, not what you decided is best. No one likes horizontal scrolling or white space on the edges.

zimbabwe5• 17 years ago

That's an interesting idea. The problem with it is that it takes a very long time and, depending on the OS being used to develop, would be a pain to work with. I'd have to be in Windows constantly to test the IE pages as I built them, and since there are 3 separate Internet Explorers I'd probably have to build 3 separate pages. If you combine both browser usage and resolution detection, suddenly I've got to make a dozen pages for every page on my web site, which is time consuming and not exactly a comprehensive approach either.

This approach works for the iPhone, which is standardized completely, but not for the complex and varying desktop browser scene.

moe• 17 years ago

If browser differences cause you so much grief, why don't you just treat whatever goes out to the client as "object code" of your own engine.

You mean like, swf?

Browser differences are accomodated through maintenance to your engine, not every page or library.

You mean like, by adobe?

While you're at it, take a look at your user's resolution as well, and serve it the way they want to see it, not what you decided is best. No one likes horizontal scrolling or white space on the edges.

Well if these are your priorities then I suggest to take a look at Flex.

You limit your audience to clients who have the plugin - but other than that it just works™.

lpgauth• 17 years ago

My only complaint is that the dev tools gives colors in rgb instead of hex.

willwagner• 17 years ago

The RGB thing also drives me completely crazy to the point that I have started muttering obscenities under my breath like a mad man every time I see one.

boucher2• 17 years ago

I cannot, for the life of me, understand why anyone would want to specify a color in hex.

OmarIsmail• 17 years ago

The whole "This is the best thing EVAR!" articles really need to die.

In general the "best" tool is whatever one is best for the current job. Fortunately in the Webdev world our tools are free and easily accessible.

I personally use Safari, Chrome, Firebug AND IE8 (seriously, the built-in developer tools are actually decent!). Usually I start with Firebug, and if I run into a small issue instead of wasting time trying to fix the tool in that case I just try another tool. Usually one of the tools will handle the case with no problems and I can continue debugging/developing my core project instead of debugging the tool.

rgrieselhuber• 17 years ago

I've recently switched to Safari as well, for a very simple reason. Firefox performance was just too bad to deal with any longer. The combination of nutso RAM / CPU it took was bringing everything else on my machine to a slow crawl.

rbanffy3• 17 years ago

Is it my impression or this is one more of those "Why I do X and why everybody should do it too because if they don't they are doing it completely wrong" posts?

pkulak• 17 years ago

The only thing Firebug has over Safari is adding styles to a page. That's pretty huge when you are trying to get something to look right without 4 million page reloads. It's only one thing, but it's pretty huge.

keefe• 17 years ago

linux port? (:

jonursenbach• 17 years ago

In addition to using Safari for rich web development, I assume we should all be using Textmate and working on our Macbooks in dimly lit coffee shops.

Give me a break. Use whatever you want to use for web development. As long as whatever you're doing works across _all_ A Grade browsers, I could care less what you use.

chewbranca• 17 years ago

I recently switched from firefox 3.0 to safari 4 beta when it first came out, and then back to firefox 3.5.

Originally I switched to safari 4 beta because I'm on a machine that has limited ram and firefox 3.0 would buckle my system. Safari 4 is slick and runs much lighter and faster than firefox 3, however firefox 3.5 really levels the playing field and makes the comparison about features rather than resource consumption.

When you compare the two on features, safari is lacking. While safari has clean tools built in for web development, they are more for looking at a page rather than messing around with it. I find it a pain to go and change styles or elements in safari and also you can't delete elements out of the dom in safari which I find very annoying. Firebug is not as polished looking, but it definitely has the best set of features. Also firefox's extensive set of plugins is tough to live without.

I enjoyed my time with Safari, it was a very elegant polished experience, but web hacking is rarely both, which is where firefox and its plugins feature set really shines.

Devils-Avacado• 17 years ago

Do Safari's developer tools allow you to change CSS and HTML on the fly like Firebug?

jpcx013• 17 years ago

Almost. You can edit CSS styles, but not add new ones. You can add attributes (style=) to elements. It's been extremely clunky for me, but I have hope it'll be smoothed out in the future.

zmimon2• 17 years ago

I know I risk getting downmodded to oblivion, but the developer tools in IE8 have actually brought me back to using IE for development some of the time. There are some specific features that are very handy - the debugger is awesome - better than the one in firebug. The CSS tracing features are even better than FireFox's for some specific situations. I now probably spend about 20% of my time in IE when developing pages (as opposed to almost never except for one off checking prior to IE8).

jpcx013• 17 years ago

I like Safari's dev tools, but its missing some really basic stuff that Firebug makes easy.

In Firebug, you can double click on anything in the dom view and edit it. In the CSS view, you can easily add new attributes. The autocomplete for CSS styles is awesome.

Also, you can grab any asset file (css, js) and open it up in your default text editor.

Safari 4 web dev tools isnt quite there. It only needs a few tweaks, but they don't seem to be adding them anytime soon (people have been asking for these features for about a year now).

Why everyone should use Safari for rich web development

Related Stories