Wednesday 20 June 2012

Barebones Javascript Framework

Basic Philosophy :

Any full fledged web UI ends up becoming tightly coupled with its javascript framework -jQuery, dojo, mootools ,e.t.c. Hence any component developed for one project is hard to reuse for another project . Attempting to use multiple libraries on the same project will lead to performance issues and the usual namespacing problems. This leads us to keep on rewriting the same components.The main problem is that testing and bug fixing done in one place is not applicable for the other because many of the bugs are at times due to the javascript framework.
Eg : improper use of dojo dijits have led to numerous bugs and waste of a development time.

The Suggested Solution :
Instead of overrelying on the framework which have been made keeping in mind ancient browsers relying on many practices which can be considered bad in the long run , we can stick to native Javascript and CSS solutions as much as possible.
Problem :
Many of things achieved in frameworks cannot be achieved using native JS. While that might be the case with older javascript and CSS versions, but in reality the simple utility functions introduced in frameworks have now been adapted into native javascript.

So , the target is to provide the new magic native functions in older browsers and ensure cross browser compatibility. At the same time we start shifting our codebase to native javascript which will basically reduce our dependency on frameworks. And as more browsers support these functions , the size of the library would actually reduce , While frameworks tend to get bloated over time - just compare the core javascript library size of all major frameworks.

Eg: dojo.query ( most important function in dojo core lib of size > 27 kb uncompressed ) or its analogous function in jQuery or other library which take nearly the same size can be replaced with document.querySelectorAll in all modern browsers.

Target Gist :
Make older browsers compatible with latest standards for cross browser compatibility and shift our codebase to native javascript which have all the required powerful functions that we commonly use in frameworks.

Benefits:
- Reusability of testing and bug fixing experience across all UI frameworks
- Can create and maintain a library of useful UI components and be able to use them on any clients projects which already use a specific javascript library , say dojo or jquery .
- Developer learning time won't be wasted mastering multiple frameworks and multiple sets of documentation
- Since we will be not using a lot of hacks hence we have a greater probability that the code would work on mulitple platforms and have proper navigation.
Case in Point : dojo dijits or jquery UI hack the html up using templated markup . Hence they need to manually redefine basic usability stuff like remember password in their code. By using a proper tehnique while their is a chance we might get a less glossier or cooler UI but we would get a UI which would be less buggy across multiple platforms and also get the normal benefits and navigation that the browser provides.

Main Gameplan:
Categorize the required functions as per complexity and frequency of use, then provide guidelines and make them available across all browsers. We can do it step by step in the following manner :

1)Basic Operations
Aim : Make all basic ECMA 3 javascript functions available across all browsers in the same way
Motivation :
    - Make the code which uses basic language features independent of libraries or framework for basic operations
    - Any browser complying with ECMA 3 standards would not need the file
    - code written can easily be moved from a project using jquery to one using dojo or where there are no liraries at all
   
Basic Operations :
    - String operations : directly overloaded into the existing string where the string operations are not available
    - JSON Manipulations : overload methods where they don't exist like JSON.stringify , JSON.parse e.t.c
    - Array operation : slice,join, indexOf unavailable in many older browsers
    - OOP syntactic sugar available in newer versions of JS  ( not sure what all features)
        // TODO create proper best practices document and list cross browser support
       
GamePlan :
    - No library namespace should be used ,add the functions directly to existing class in javascript
    Eg :
        String trim is not available in IE<8
        So we add it as follows :
       
        //Check if function exists
        if (typeof String.prototype.trim !== 'function') {
            //Override so that browser has trim()
            String.prototype.trim = function(s) {
                return s.replace(/^\s+|\s+$/g, "");
            }
        }


2)DOM Operations :
Aim : Basic aim is to make the code as less library dependent as possible
Motivation:
    - Isolate library dependent code and make the code reusable
    - Depend on native selectors
        - One of the most frequently used DOM function is dojo.query or $ to get an array of all required DOM nodes
        An uncompressed version of the selector can be upto 27 kb (dojo.query and nodeList)
        Alternative Solution is to use document.querySelectorAll which is available in IE < 8 , FF <3.1 and Safari < 2.1,  then provide it wherever it is not available
       
Basic Operations :
- Query Selectors   - Use document.querySelector , document.querySelectorAll . Provide it where it is not available
    - Currently unavailable in IE < 8 , FF <3.1 and Safari < 2.1 ( No need of browser detection- directly property detection )
    - Will Reduce code dependency on dojo.query or $ , making the code more reusable .
    - Code Size will reduce when the property is available on all browsers
- Nodelist manipulations - Provide utility functions but of small size to make it similar to dojo.query  // NOTE : Open to debate
- Event Attaching and Registering - Special emphasis on ability to detach whenever required
    - Need to ensure standard event flow on all browsers
        - Event Bubbling
        - Event Order
        - Event Cancelling methods ( prevent Default )
        - Special emphasis on form element events    
    - Maintain global registry
        - Follow model similar to dojo.behavior but with additional capabilities of deleting behavior   
- Standardization of form elements like radio button,checkbox,comobox [ For querying and validation ] without modifying their DOM     structure. Only add extra attributes wherever required to store information.
- Simple animate function and ability to plugin to 3rd party animation code like dojo.fx and jquery.fx
- Simple Timer for time based operations

8 comments:

  1. David Walsh is Mozilla’s senior web developer, and the core developer for the MooTools
    Javascript Framework. David’s blog reflects his skills in HTML/5, JS and CSS, and offers a ton
    of engaging advice and insight into front-end technologies. Even more obvious is his passion
    for open source contribution and trial-and-error development, making his blog one of the
    most honest and engaging around.
    Website: davidwalsh.name

    ReplyDelete
  2. David Walsh is Mozilla’s senior web developer, and the core developer for the MooTools Javascript Framework. David’s blog reflects his skills in HTML/5, JS and CSS, and offers a ton of engaging advice and insight into front-end technologies. Even more obvious is his passion for open source contribution and trial-and-error development, making his blog one of the most honest and engaging around.
    Website: davidwalsh.name

    ReplyDelete
  3. David Walsh is Mozilla’s senior web developer, and the core developer for the MooTools Javascript Framework. David’s blog reflects his skills in HTML/5, JS and CSS, and offers a ton of engaging advice and insight into front-end technologies. Even more obvious is his passion for open source contribution and trial-and-error development, making his blog one of the most honest and engaging around.
    Website: davidwalsh.name

    ReplyDelete
  4. David Walsh is Mozilla’s senior web developer, and the core developer for the MooTools Javascript Framework. David’s blog reflects his skills in HTML/5, JS and CSS, and offers a ton of engaging advice and insight into front-end technologies. Even more obvious is his passion for open source contribution and trial-and-error development, making his blog one of the most honest and engaging around.
    Website: davidwalsh.name

    ReplyDelete
  5. David Walsh is Mozilla’s senior web developer, and the core developer for the MooTools Javascript Framework. David’s blog reflects his skills in HTML/5, JS and CSS, and offers a ton of engaging advice and insight into front-end technologies. Even more obvious is his passion for open source contribution and trial-and-error development, making his blog one of the most honest and engaging around.
    Website: davidwalsh.name

    ReplyDelete
  6. David Walsh is Mozilla’s senior web developer, and the core developer for the MooTools Javascript Framework. David’s blog reflects his skills in HTML/5, JS and CSS, and offers a ton of engaging advice and insight into front-end technologies. Even more obvious is his passion for open source contribution and trial-and-error development, making his blog one of the most honest and engaging around.
    Website: davidwalsh.name

    ReplyDelete
  7. David Walsh is Mozilla’s senior web developer, and the core developer for the MooTools Javascript Framework. David’s blog reflects his skills in HTML/5, JS and CSS, and offers a ton of engaging advice and insight into front-end technologies. Even more obvious is his passion for open source contribution and trial-and-error development, making his blog one of the most honest and engaging around.
    Website: davidwalsh.name

    ReplyDelete