Web Application : Cross Browser Incompatibility Handling Client Side Code Management

The issue of cross browser incompatibility is not new and has been well dealt and criticized. As I am also involved into development of one such project, I am facing same set of problems which people have been dealing with and fixing them. However, what’s more serious problem I am facing is how to manage code development in such scenario. While being through, I learned some of my ways of handling the same, which might sound little unconventional and involves following steps :-
  1. Code is centrally developed only for one browser and its latest version, which is called Parent Browser (Firefox in this case). This is called Parent Code (referred many times later). Codes for removing incompatibilities are copied and edited accordingly later, which is need for each browser. These are called Browser Codes. For each browser, Browser Version Codes are written in order to remove incompatibilities within multiple version of browser itself. This also includes parent browser.

  2. Maintain separate codes for each browser and its different versions. Specific client side codes are downloaded, only after detecting the browser and its version, in order to provide maximum compatibility.

  3. In Browser Codes, codes snippets handling incompatibilities should be marked for each of them. It turns out that only some parts of code are misinterpreted by different browsers, hence marking these sections helps editing them later.

  4. The architecture and data handling should not be changed and should be same as parent code. Variables should not be changed either.

  5. Codes for each browser and version are developed by different set of people, who have gathered knowledge of incompatibilities between parent and other browser and for different versions too. The translation structure is Parent Code => Browser Code => Version Code. Code for browser is compared with Code for parent browser, while browser version codes are compared with their Browser code.

  6. All new code insertions/updations in parent code are well documented, so that it can be easily passed to browser codes. Code transfer is done in terms of versions and not for small changes. Hence, only after certain development, changed codes are updated in browser and its child codes. This method also matches with the idea of releasing versions of web application as a whole, as it synchronizes all these codes before release. Ideally, there should be 1-to-1 mapping to parent and browser codes, however, can be merged into few, as code changes in browser codes would be minuscule for each set of version of parent code.

  7. New code insertions are marked with different color to previous version for easy identification. Color shades are not passed to higher versions (as they will be having their own which would create unnecessary confusion), however, they are retained in the current version for later references. Line numbers can not be used in this case as they would change as more codes are inserted elsewhere. However, unless codes are not updated, new codes should be preferably added in the below in order to maintain line number relation as much as possible. This might sound mismanaged but as code incompatibilities are small, it does not turn out to be. In case color shading is not supported in editor, /*….*/ labels should be used with different syntax.

  8. All future code developments are passed in this manner a) last version of parent code which was incorporated in current version of browser code is taken and compared with current parent code using color shades and line numbering b) new sections are identified and are mapped to places where they should be put or lead to change some codes in the browser code c) current browser code is saved in case of maintaining it as a version, else code changes are directly incorporated in current browser code which are changed to handle code incompatibility wrt parent code. Browser version codes wrt its browser code are maintained in similar manner as parent code and browser code. However, the code updations are much less frequent as compared to them.

  9. As incompatibility codes are not mixed together, it reduces size of client side library to large extent, as well as maintains quality issues to higher level. Similarly, as incompatibility codes are developed by people who have expertise in them, even after being unknown to original application, such operation can be carried out efficiently. As browsers are evolving fast and probably some in same and some in different directions, expertise for handling all such problems by same set of people in same version of code will lead to errors and mismanagement.

  10. It loses the advantage of using one code everywhere, however, such integration of code can also be developed by looking at the changes done in browser code. Such versions can also be kept, however, should not be used at least for development, though may be for distribution.

Hope this helps in some manner to resolve browser incompatibility issues.

2 comments:

  1. kaa re compoooter ker allawa kuch aur nahi likhta hai... eee compoooter ke baare mein kucho nahi samajh aata hai humko.

    ReplyDelete
  2. chhor na be.. mujhe khud samajh mein nahi aata hai ab :( tu life wife wala blog padh.. woh tujhe achha lagega..

    ReplyDelete