Our most recent project is by far the most JavaScript dependent site we have ever made, and it has brought about some interesting development concerns. The toughest of those concerns has been whether we should develop for all browsers simultaneously, or develop a polished version for one browser, and come back to fix things up in the other browsers later. Here is our story, and the conclusions that we’ve made.

Our original outlines told us two things:

  • JavaScript would account for about 50% of the core of the product. This meant that JavaScript would not just be a visual aid (i.e.: mouseovers, animations), but it would be involved in operations that are critical.

  • A functional core product had to be presentable within seven weeks.

After taking those two points into consideration, we confidently started work on the project, making each step work in all major browsers. About three weeks in, feedback started arriving, which sparked change in a few areas. In particular, one area that contained 2000 lines of JavaScript had to be completely rewritten. We knew that with the deadline, we had to drop support for all browsers and continue on with major support in Firefox only. This turned out to be smart because two more rewrites were completed, and many other features got tweaked.

By our deadline, we had a core product working in Firefox, partially working in Safari, and completely broken in IE. That includes both JavaScript and CSS. On the positive side, we were able to bring in beta testers who used Firefox, and get the foundation ironed out. On the negative side, a lingering stress was always around because we weren’t able to set anything aside as completed.

And finally, after deadline day, we were able to bring all other browsers up to speed. It took two people four days to fix 95% of CSS and JavaScript bugs in all browsers. This was actually surprising considering the severity of some of the bugs.

Looking back, I am glad we had a deadline that forced us to drop support of the other browsers because I liked the approach so much that I develop that way today with a couple of cautions I keep around:

  • Know that what you are trying is possible in all browsers. Nothing is worse than making it work in one, or two, and it being technically impossible in the third. Once you’re confident it is possible, there is no stress for singling one browser out.

  • I can’t build an entire project in one browser. I single out each section, or page (i.e.: an account page) and make it work in one browser. After that, I then make it work in the other browsers before moving on to the next section or page.

Overall, this makes the initial development easier to handle, and much more fun. I don’t get caught up in the stress or frustration of multiple browsers. I get to enjoy seeing my code work as expected, and I save the annoyances for later down the road. It works for me, but I can see how it won’t work for everyone. What approaches do you take?

HTML Form Builder
Ryan Campbell

Developing for Multiple Browsers by Ryan Campbell

This entry was posted 4 years ago and was filed under Notebooks.
Comments are currently closed.

· 16 Comments! ·

  1. Ryan · 4 years ago

    I get everything working perfectly on one standards-compliant(ish) browser (Safari, Camino) and then only after I’m done do I venture out to test other browsers.

  2. Terry Apodaca · 4 years ago

    I develope for Firefox first, then the others…and in no particular order. What I do do though…is get all the presentation out of the way, then the behavior, then the code (php, asp, jsp, etc). I’ll have to try your way though…only one page/section at a time and see how I like that for my next project. Seems to have good reason, I’ll let you know how it goes.

  3. Chris Leipold · 4 years ago

    I do it like Ryan (I.): I do the prototype in Firefox (very comfortable due good developer extensions) and get it working later in other browsers. Sometimes with Dean Edward’s IE7. But this is only for Markup and CSS. If I do Javascript everything is tested after each step.

  4. Gillico · 4 years ago

    It’s all still just a work-around for the fact that different browsers display content differently. I have yet to understand why this is acceptable- think what would happen if your tv or your radio could choose how to render your content? That being said, it’s all about developing for Firefox first, then seeing how badly it’s broken in IE…

  5. Drew Yeaton · 4 years ago

    The fact is, tv’s and radios do, in fact, render content differently. Images and sound are presented in a myriad of different ways on different speakers and screens. That is why the mastering process for audio/video is so essential to a good looking and sounding production. This is much like the polishing phase presented in the article.

    I do proof of concepts in Javascript/CSS to see if everything is possible. Then, I work from presentation to back-end. I tend to follow the mantra that “form doesn’t follow function, it’s a part of it.”

  6. Heiko · 4 years ago

    I develop for IE ( because most of the users, use the redmond product ), Netscape, Firefox, Opera, Safari & Konquerer. If u know your job, the browsers and their interpretations of webstandards u don’t need a lot of finetuning to them, except the IE 5.0( PC/Mac ) and Opera ;o) I try to avoid JavaScript if its not necessary. But if I need it it has to test after every step.

  7. hemebond · 4 years ago

    So, when I stumble across this website, using Firefox, Javascript disabled, am I going to see anything? Will it work at all?

    Or have you built another http://shopping.live.com ?

  8. Ryan Campbell · 4 years ago

    hemebond, JavaScript is required for it. Making a degradable version would have doubled to development time, and when you are starting a company you are on a limited budget with limited time and resources. Who knows, maybe one day we will have a degradable version though. For now, we’re happy making the user experience great for 90+ % of users, and we can fine tune for the rest as time goes on.

  9. Joe Clark · 4 years ago

    For your CSS errors, were you using perfectly valid CSS all along? That will shorten your development cycle. (It will be much more dramatically shortened with valid HTML at all times.)

  10. Ryan Campbell · 4 years ago

    The first wireframe always works in all browsers, but as code changes and tweaks need to be made to the layout, things get a little out of hand. Ideally, we would do it all right all the time, but the joy of programming comes from seeing things work, which leads to us getting ahead of ourselves sometimes.

  11. Adriand · 4 years ago

    As a mac user, I tend to leave IE fixes to last too, as dangerous as that may be. I think the key point you made was knowing that it’s possible to do what you want to do in IE. If you don’t know if it will work — make a quick prototype of the concept and test it across your target browsers.

    As you also mention, developing in fewer browsers allows you to be more flexible to change, since you haven’t already invested time in making existing code cross-browser compatible.

    I still feel that having the project broken in IE adds to the stress in the back of your mind though. The time it takes to fix things for IE can be a great unknown.

  12. Kyle Erhart · 4 years ago

    Personally I always try and avoid Javascript as much as possible. I use it occasionally but for the most part I stay away from it.

    As for browsers, I always design for Firefox until I’ve got the page perfect in there, then I perfect it in IE (always always always). Then comes Opera.

  13. Dustin Diaz · 4 years ago

    Ryan, it’s interesting how you mentioned in your comment about the deadline being tight, and having a degradable version would have heavily added more cost to the project. Tis very true. There are many times that Interaction Designers don’t even think about fallbacks and sometimes I wish they did. Then beyond that from a business perspective, developing a fallback application is just wasting money (or at least that’s the conclusion). I could only imagine the kind of fallbacks that would need to take place for something that includes a lot of drag and drop, sorting through menu trees, inline editing, etc, etc. It really does double the scope of the time allotted to get this stuff done. It’s good to know that I’m not the only one who feels this way and has had to make that decision to just go forth with the main plans of getting things right in one browser and at least shipping that… then being a bit late with the rest of the stuff.

  14. Dustin Diaz · 4 years ago

    @Kyle, that’s typically the attitude of someone who doesn’t have much experience in writing JavaScript. Indeed you can make web sites just as accessible with or without JavaScript. But just out of curiosity…

    Personally I always try and avoid JavaScript as much as possible.

    Why?

  15. Mark · 4 years ago

    okie dokie

  16. Ravi Santlani · 4 years ago

    Ravi Santlani : Hi, My Website is a Product that involves download of component and then use it & do most of work with it in javascript. I hav to make it work in atleast 2 of browsers: IE6/7 and Firefox. Can anyone tel me how can i know by any notes or resourse, wheather particular statement will work in both or not. I use Microsoft VS2005 for development & aptana editor for checking if particular tag/attribute is compatible with which browser. Please help me asap in this matter. Please mail me necessary at ravibullish@gmail.com

    — Regards, Ravi Santlani ravibullish@gmail.com