Re: Food for thought (resurfacing)

On July 24, 2014 at 5:13:45 PM, Marc Fawzi (marc.fawzi@gmail.com) wrote:
> 90% of our bug reports are browser specific, and I just started this job,
> so I'm working with a lot of sub optimal decisions and scenarios, until we
> can get ahead of the defect backlog, which again is 90% cross browser
> issues.

It might be worth looking to see if it's really a Web platform problem, or development/developer problem, or a user problem (out of date browsers). There is a fairly stable and interoperable base across browsers, and if your cross-browser bugs are that significant it might be that the developers at your company are indeed using proprietary features/quirks rather than using core Web platform features. Otherwise, it might be that a subset of your users are stuck on some old browser version and upgrading them might fix the cross-browser issues.   

Calling for the ability to hot-swap engines doesn't address the core problem: interoperability. It actually makes things worst, because it no only means being able to hot-swap the engine, but probably target a particular version of that engine (e.g., IE7). Imagine now how many different engines would need to be bundled into a hot-swap browser. You would have - i.e., 6,7,8,9,10,11,12 + then every version of Gecko + every version of WebKit + every version of Blink. And it means supporting those versions and their bugs forever (which, through their quirks, expose security issues). That is, of course, unrealistic (ask Microsoft how that strategy worked out for them, as they tried to do this a few times over the years with just IE).  

No software is stable, and has to be maintained (this applies to both websites and browsers, obviously). On the Web, we (browser folks) try to support legacy content as much as possible where it makes sense (e.g., silly tags like <blink>) - but we also often have to fix and correct issues to benefit/protect users, which sometimes breaks corporate apps, etc. It's why we have things like Chrome Canary and Firefox Nightly + beta versions of each browser, which allows folks that maintain applications to check that their apps won't break with each new release + gives devs time to fix any issues and test out new features. This buys developers on the ground about 3 months to make sure their apps will work well before users get their browser's automatically updated.

So, my recommendations would be to review the development practices inside your organization + try to understand which browsers users are using (e.g., some users might be stuck on some old browser version - so actually just updating those users to a more modern browser would address the cross browser bugs without the need to fix the web application - which may be actually be fine).  

HTH!

Received on Thursday, 24 July 2014 20:06:57 UTC