views:

741

answers:

12

When coding new javascript heavy websites, which order or web browser do you code for?

I can see these possible orders, but I am not sure which I like best:

  1. Code for one first and get it working well, then start testing with other and fix errors as I go.
    • This will allow for the most rapid development (with Firefox at least) but I've learned from experience that debugging IE with so much going on at once can be a pain!
  2. Code for both at the same time. In other words, for each new feature, ensure it works with both browsers before moving on.
    • This seems like it will actually take more time, so maybe do several features in Firefox then move to IE to patch them up.

What do you all do?

Edit 1: To respond to a couple of answers here.: @JQuery usage: For some reason I was not expecting this kind of a response, however, now that this seems to be the overwhelming accepted answer, I guess I should tell everyone a few more things about the specifics of my app. This is actually the DynWeb that I started another question for, and as I'm developing, a lot of the important code seems to require that I use document.whatever() instead of any JQuery or Prototype functions that I could find. Specifically, when dynamically importing changing CSS, I have to use some similar to:

var cssid = document.all ? 'rules' : 'cssRules';  //found this to take care of IE and Firefox
document.styleSheets[sheetIndex][cssid][cssRule].style[element] = value;

And I expect that I will have to continue to use this kind of raw coding currently unsupported by either JQuery or Prototype in the future. So while I would normally accept JQuery as an answer, I cannot as it is not a solution for this particular webapp.

@Wedge and bigmattyh: As the webapp is supposed to build other webapps, part of the criteria is that anything it builds look and work functionally the same in whatever browsers I support (right now I'm thinking Firefox and IE7/8 atm, maybe more later on). So as this is a more interesting (and much more complicated) problem; are there any sites, references, or insights you may have for specific trouble areas (css entities, specific javascript pitfalls and differences, etc.) and how to avoid them? I'm almost certain that I am going to have to have some sort of isIE variable and simply perform different actions based on that, but I would like to avoid it as much as possible.

Thanks for your input so far! I will keep this open for the rest of the day to see what others may have to say, and will accept an answer sometime tonight.

+7  A: 

Use jQuery and do them all at once.

Greg Hewgill
i was about to post my answer when the orange bar told me one answer has been posted, and there you go, jquery
lock
...because jQuery is a magic cure-all that solves IE6's woeful HTML/CSS support...?
bigmattyh
it's amazing how if you code jQuery properly, you don't have to fix things for IE! spiffy!
contagious
Don't know JQuery, but if it's anything like Prototype and Scriptaculous it's not the universal panacea it's often made out to be. I'm working with scriptaculous' draggables and sortables and the cross browser experience is not good. I'm tempted to start again with JQuery but also very sceptical.
Noel Walters
This is actually a pretty flippant and unhelpful answer. Yes, using jQuery (or any other framework) will help smooth out the bumps of running your JavaScript under JScript, but that does nothing for the many, many non-JS quirks and bugs in IE (or, for that matter, any other browser).
Ben Blank
Wow. I really like jquery, but just using it doesn't mean you can stop testing with different browsers.
Kevin Tighe
+1  A: 

I do IE first, and then add Firefox.

My experience is that once it works in IE, it continues to work in IE, and the question why something not work in Firefox is usually easy to answer.

buti-oxa
+8  A: 

FireFox first then IE. If it works in FireFox, it is more likely to work in the other non-IE browsers, IE sometimes requires special magic.

jrcs3
+1  A: 

If you have to code for IE6, the most frustrating part is coding the CSS and HTML. jQuery and other libraries make it easier to code the behavior -- but you generally can't get around the fact that IE6 has so many weird rendering issues that you'll be frequently banging your head on the keys trying to make it do what Firefox, Safari and Opera do right the first time.

So Javascript isn't the hardest part. Dealing with HTML and CSS is. In my experience, if you're working with any reasonably interesting design, you're better off coding for IE first and then testing on Firefox. You probably won't have to make many adjustments if you do IE first, but you definitely will have to spend some time refitting your code to make IE do what you wanted it to, if you only code in Firefox. It's like repeating yourself. It's a pain. So it's better to get it done first so you don't end up wasting too much time.

bigmattyh
A: 

If you have look at Web Browsers market share, you will find that IE and Firefox are on the top and so close to each other so, You should put both of them in your consideration either using cross-browser Javascritp like JQuery or go on your way by testing both of them.

Ahmed
A: 

I think its best to design for Firefox but like others have mentioned the JavaScript isn't the hardest part, its the CSS that is the hard part. Personally I used to code for both FF and IE at once, but I find that it takes longer because your likely to make major changes during a development cycle so don't even bother coding for both at once, it could be wasted effort.

Another thing to consider when choosing which browser to start development under is if you are more familiar with W3C standards or the IE "standard" imposed by its majority user base. Its kind of a funny thing about web standards, many if not most web developers are not happy with IE's standards support, but at the same time any code IE supports is the real standard of the web.

teh_noob
+2  A: 

Code for Firefox first, but test with IE as you go. This lets you fix any quirks as they arise. It's important to test with Firefox first because it's more standards-compliant. You should learn how to write HTML/JS the right way. Fix things as you go to get a better idea of how IE renders things differently.

You may not need to test with IE for every feature you add, but test often enough so that issues don't pile on top of each other. Repeat with other browsers/browser versions to get the overall picture of your site's compatibility.

By that argument, you should test with Opera first, since it's the most standards-compliant of the lot. "Standards compliance" doesn't always equate with "looks the same everywhere" - browser vendors can and do interpret standards differently.
Rob
+15  A: 

This is sort of a trick question. In my opinion you need to work in this order:

1: Conform to Standards

This gets you closest to working in every browser without having to test against every browser. Additionally, you gain the huge benefit that your site should work with any new browser that comes along (Chrome is a good example) so long as it's well made and standards compliant. It also makes it easier to tweak your site to work in specific browsers because the way that the popular browsers deviate from standards compliance is well known.

2: Support the Most Used Browsers (For Your Site)

Note carefully the distinction between the breakdown of browser usage on the internet vs. browser usage on your site. On the internet as a whole IE is the most popular browser with Firefox a close second and Safari, Opera, and Chrome taking up most of the remainder. However, the demographics of your site's visitors can turn these numbers upside down. On sites that cater to a more technically savvy crowd it's common for firefox to be the dominant browser with IE in the distinct minority.

3: Support Other Browsers as Needed

You need to be very explicit about the fact that browser compatibility is an operating cost for your site, and you need to decide where you draw the line. Depending on your site's purpose and business model it may be fine to support only the most popular browsers, or even a subset of them. On the other hand, it may be a vital business concern to support everything under the Sun, including IE5. It's ok to make a conscious decision to not fully support every browser if you think the cost/benefit ratio is too high to justify it. Indeed, many of the most popular sites on the internet do not work well in older and niche browsers. Though you should strive to make your site still functional in the least popular browsers, even if there are serious appearance or usability problems.

Wedge
+3  A: 

I always test on both FireFox and IE7. And then fix and botch for IE6 and other browsers.

If it works on FireFox it will almost certainly work on Opera, Safari, Chrome, etc with only a few minor tweaks

Same thing goes for IE7 and IE6, If it works on 7 it won't take too much to get a reasonable rendering on IE6

I normally use Firefox as my main development browser because of its superior debugging tools and I code very incrementally, write a few lines and test several times an hour. But at least every hour or two I make sure that what I am doing will work on IE7 as well.

As soon as I get into an area where IE7 causes problems I start to rethink the way I'm doing it, In my experience fixes tend to multiply and get out of control very rapidly. It's often better to accept defeat and move on with a simpler design.

I've been bitten too often in the past by developing something that works perfectly on FireFox only to find that it needs a complete rethink to get it working in IE7 as well - and vice versa. It can take days to sort out and can be very disheartening.

Noel Walters
+1  A: 

I code for both, and write (or use) abstraction layers where there are differences between the browsers. IMHO, it's much easier in the long run to be continuously testing in a cross-platform setting. This keeps me from doing something that's tuned to one browser that simply won't work well in the other: I find out very early in the development cycle what the compatibility issues will be.

When I'm making a small change, I might first do it for one browser, but before I consider that feature or change to be complete, it must work at least in firefox and IE.

Mr Fooz
+2  A: 

are there any sites, references, or insights you may have for specific trouble areas (css entities, specific javascript pitfalls and differences, etc.) and how to avoid them?

A good resource for this is quirksmode. The author (Peter-Paul Koch, or PPK) has lots of compatibility tables for CSS and JavaScript support. He also has articles dealing with specific issues and how to write cross-browser code.

They don't deal with JavaScript, but Position is Everything is a valuable resource for CSS issues (mostly IE6).

Like others have mentioned, I just use jQuery to avoid these issues. If there's something it doesn't support, it's pretty easy to write custom plugins.

Matthew Crumley
+1  A: 

To minimize your issues now, and downstream, work with the worst to the best, in size of their existence.

Edit: If you can do the below keeping in mind of "how could this degrade gracefully down to ie6 via modified jQuery elements, etc... it might be a bit clearer.."

So, today based on Market Share, it is:

1) IE 6

2) IE 7

3) Firefox

4) Safari..etc.

Coincidentally enough, the major issues with browsers occur in that order too.

This means the majority of the issues your users will face will be in that order, and in those proportions.

On our team I have banned initial-development testing in Firefox. It has to survive the weakest link, not the strongest. Inhumane, I know, but we have cut down going back and fixing bugs related to browsers by 80%, because 80% of browser bugs are IE. Yeah, there's a ton of debugging tools in Firefox that can be used ONCE we find a problem in IE.

On the flip side we put in extra-features that are Firefox only to reward the firefox users. A simple browser type check and it takes care of the rest.

Jas Panesar
+1 for really cool idea of rewarding Firefox users... Unfortunately I can't really do that for this project, as I am mainly catering to other developers who will want their stuff to work and know at least a fair amount of web design... So maybe next time :)
Mike
Lol, thanks! Its our humble declaration of rewarding the behavior we believe in, using Firefox.
Jas Panesar
I could not disagree more with this approach! To start with, the development tools available for IE6 are next to none, code that works fine in IE(6) may be completely invalid in other browsers (even later versions of IE. Code to standards first, developing in your choice of Firefox, Chrome, Safari, or Opera. Then go to IE8 and see what needs fixing (likely minor), then IE7 (catch remaining stuff still broken), then IE6 (final sweep). Along the way you'll develop common fixes for IE bugs so they won't hit you again.
scunliffe
@Scunliffe, I've only managed some developers for about 10 years so your experience might be different. IE6 testing gets neglected and can cause headaches (Why didn't we test this before we built it out this far) if ignored until the the end, so maybe a middle ground can be found. More importantly, use a browser tested library like jquery, etc to avoid most of this mess to begin with. Re0inventing the wheel to get the same UI elements working in the same browsers over and over can get tiring. This approach has worked well for me in addition for the above. All the best! :)
Jas Panesar
@Jas - you're right, there are different skill levels etc. and in reality sometimes you need to do both (e.g. start with IE... can IE even do this really cool thing I'm thinking of?). What I fear most (and I've seen it a lot) is when developers build *for* IE first, with all kinds of invalid crap code that only works due to really, really loose parsing rules in IE... then developers blame FF or Chrome for choking on it... and hack it even more to make it work in non-IE browsers. Whereas if they built it cleanly from the start it would just work (with minor tweaks for IE) ;-)
scunliffe
@Scunliffe, I think what you might be highlighting is a key difference in developing a web app vs a website? I'd probably be more concerned with using the newest doo-dads for a website than a web app -- typically I'll be taking a jQuery, YUI, or ExtJs and building it up from a foundation that's already (and largely) hopefully pressure tested to gracefully degrade to ie6. Neither of us sound like fans of re-inventing the wheel if it can be avoided. :) I should clarify my post to focus on the "could this degrade nicely to IE" part as it would make my point clearer..
Jas Panesar