We are on the verge of a conversion. For years, our company supported only IE for its internal (intranet) home-built tools.

Since a few of our users are still on XP, which means IE only goes up to 8... a heavily JS / jQuery site wont even load!

We have been in the process of converting to use Chrome instead, to make use of its javascript performance.

But, it has now been suggested that we support all common browsers... internally for these tools. Which means more development time to scale-back some of these new applications, more time to test in all browsers, and we are already under staffed.

Are there any good informational sites/posts out there, that already make this argument?

  • Remember that you might also be asked at some point to support mobile device browsers. "Bring Your Own Device" is becoming a popular option at some corporations. It's also becoming common to have to support Android and other Java based devices, such as barcode readers, within web apps. If this happens at your company, you may find yourself doing some rewriting to support these trends.
    – jfrankcarr
    Dec 10, 2012 at 19:24

2 Answers 2


It would probably be more effective if you put together a simple document that explained what it would require for you to support multiple browsers. Realistically, different organizations with different sets of applications can end up with very different experiences. Organizations that build lots of internal tools (rather than buying third-party tools that they host on the intranet) often end up building relatively simple front ends with relatively minimal amounts of Javascript that support multiple browsers relatively easily. If you have a relatively bleeding-edge front end, though, you may have a much more difficult challenge. Organizations that have automated testing tools that can run the full regression suite in every browser engine relatively quickly will have a much easier time supporting multiple browsers than an organization that requires lots of manual testing.

I would tend to put together a quick 1-page document laying out exactly what you would need to support multiple browsers. Estimate the time required to tweak the Javascript, list the hardware, software, VMs, etc. you would need, estimate how much time that requirement would add for new development (both in terms of additional overhead that reduces the number of hours you have to develop and the additional complexity required to develop and test against multiple browsers), and estimate what sort of impact that might have on the UI if you would expect to need to simplify the UI to make it work across browsers. Then compare that to the benefits of allowing internal users to use whatever browser they want. If you show meaningful drops in productivity or declines in user interface quality, it may make perfect sense to limit support.


My company is currently going through a similar process, redeveloping old web-based software that was built for xp/ie set ups and moving staff onto Chrome. Fortunately we have quite a small team so moving everyone to Chrome and limiting support was doable, but when we were considering the other option it was helpful to keep this little gem in mind:


Quaint as it is the message is sound; as long as everyone is able to do everything that's needed you don't necessarily need to try and please everyone with one end-product. Consider focusing on progressive enhancement, maybe building something basic that does everything it needs to in IE but use heavier JavaScript in better browsers to enhance the interfaces, take advantage of AJAX etc.

Manage peoples expectations from the outset and you may even get people choosing to move from IE once they see the better experience they could have in another browser!

  • Thanks for the input! We have a fairly small user base as well, less than 100. Providing neat features in chrome, while leaving the application pretty basic in IE is one option... but I have hopes we can abandon IE completely until they get their game together... if ever!
    – adam
    Dec 11, 2012 at 17:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.