In our previous post last week, we delved in detail on cross browser compatibility issues faced in HTML and CSS. So far we have looked into basics of Browser Compatibility and how you can ensure that your website/web application is cross browser compatible.
So far we have looked into basics of Cross Browser Compatibility and how you can ensure that your website/web application is cross-browser compatible. We also looked into some mechanisms of fixing CSS and HTML cross-compatibility issues.
- Memory Leaks is one of the common problems faced by developers. Memory Leak simply means that memory that was previously being used by the application is no longer being used. However, due to some reason (e.g. incorrect handling of global variables, out of DOM references, etc.); the allocated memory is not returned back to the ‘free’ pool of memory. Some of the common reasons for memory leaks are incorrect handling of global variables and out of DOM references.
- ‘Profiling Tools for Chrome’ can be used for memory profiling as well as identifying memory leaks. Below is a sample snapshot of Chrome Memory Profiling in action.
- Variables are used as per their scope (local and global). Ensure that you use consistent naming conventions for different types of variables so that it is easier to maintain the code.
Ensure that your source code does not have any syntax issues.
- Implementing a time-consuming task in a synchronous operation could slow down the performance of your webpage/web application. Ensure that you move that logic to an asynchronous operation so it does not hog the CPU. Since the operation is asynchronous in nature, you have to be careful while using variables used in that operation since they might not be reflecting the latest value (as the async operation execution might still be in progress). Developers are advised to use the Promise object that returns the status (success/failure) of the completion of an async operation. A sample code with Promise is shown below
- Incorrect usage of ‘functions inside loops’ thereby resulting in breakage of functionality.
Similar to the jQuery library about which we discussed earlier, there are many libraries (native and third-party) that might not be supported on many versions of browsers. Before using the library, it is recommended that you do a thorough analysis about the library (in terms of browser support, feature support, etc.). You should also check the ‘development history’ of the library as it shouldn’t happen that there are very few updates to the library and once you use the library, there are no updates to it!
Using User Agents And Browser Sniffing
Every browser has a user-agent string which identifies the browser that the user has used in order to access your website/web application. Developers use browser sniffing code in order to tweak the UI/UX/functionalities based on the browser being used by the user. Some of the common user-agent strings are mentioned below.
Developer can use navigator.userAgent.indexOf(‘user-agent’) where user-agent is the user-agent string (mentioned in the table above). Below is a snapshot of a code where developer can come up with functionalities based on the type of browser.
Based on the target audience, you should provide support for all the latest browsers and some older versions of browsers (depending on your initial market study). You can check out these web analytics tools that would help you understand your customers in a better way. You can also opt for ‘conditional execution’ so that there is always a ‘fallback mechanism’ in case the user is using old browser. There are many old versions of browsers that do not support WebRTC (Video conferencing), Maps API, etc. In the below example, we are using the Geolocation API; the geolocation property of the Navigator object is used for that purpose. If the browser does not support Maps API, the user is given an option to use Static Maps (as a fallback option).
var x = 6 * 5; debugger; /* Logic here */
var x = 6 * 5;
/* Logic here */
Browser Developer Tools
In case you are using the Chrome or Firefox, just right click in the window after ‘Loading the code’ and click on ‘Inspect Element’. Browser Developer Tool also has the ‘Debugger tab’ where the developer can insert breakpoints, check the callstack, add variables to watch window, etc.
Below is the snapshot of the Developer Tool of the Firefox browser.
Developers can also use the Console API for printing logs during the development phase. It is recommended that different kinds of console logs are used for different purposes. For example, console.log() can be used for debugging, console.assert() in case you want to issue an assert and console.error() can be used in error scenarios.
Code Editor Plugins
- Incorrect casing/spelling being used for variables, function names, etc. Many experienced developers accidently make use of built-in functions with wrong casing/spelling. For example, you might use getElementByClassName() instead of getElementsByClassName().
- While performing a code-review, the reviewer should make that there is no code after return statement since that code is redundant (or non reachable).
- Object notation is different from normal assignment and you need to check whether the member names of the object are separated by comma (,) & member names are separated from their values by colon (:).
- Though this is a very basic practice, check whether the semicolon (;) is being used at the right place.
- Always have declarations at the top.
- Follow proper naming conventions for variables, functions, etc.
- Use ‘comments’ consistently throughout the code.
- Declare the local variables using the var keyword.
- Always initialize variables.
- Do not declare String, Number, or Boolean objects.
- Always have ‘default case’ in switch.. case statements.
- Have a close look at usage of == and === operators. Ensure that they are being used in the right place.
- Place scripts at the bottom of the page.
There exists multiple JS frameworks that facilitates development of cross browser compatible websites. Some of the most renowned ones are:
Originally published at LambdaTest
Originally Written by Harshit Paul