Merce

Javascript

The language browsers speak

  • Input validations Javascript is grossly undervalued by most programmers in the Indian IT industry. Most job applicants we interview claim to know Javascript. We then discover that their familiarity is limited to validating input values on the browser. Javascript would remain a minor tool if that was all it was capable of.

    We first started using Javascript in 1999 to validate input fields and control some parts of the page behaviour. We built an online examination system at around that time where we used Javascript to forcibly submit the test paper to the server when the examination ran out of time. By 2004, we began to work on projects where we generated interactive browser-based reports with drill-down facilities. This drill-down was implemented through Javascript. After 1-2 years more, we incorporated HTTP requests in Javascript to pull data from servers dynamically. At that time, we began to suffer from browser-specific idiosyncracies of the Javascript engines.

  • Frameworks We began studying advanced dynamic behaviour in Websites and reviewed our practices in about 2007, and realised that we cannot write Javascript code to achieve what others were achieving. We implemented prototypes applications using some of these technologies, including Java Server Faces and Google Web Toolkit. After a detailed evaluation, we decided to opt for a framework where the programmer would write native Javascript code, using libraries written by others. We did not like the code-generation approach -- it seemed too opaque to us. We also did not want to get locked down with a toolkit which required knowledge of Java, since we work with various other programming languages, specially Perl and PHP.

    The two most well-known Javascript toolkits at that time were jQuery and Dojo, and we chose Dojo, because it appeared to be the more suitable framework for large and complex projects. We occasionally use jQuery for odds and ends. Our first engagement with Dojo and Digits was with v1.3. We began to work with v1.7 in mid-2012.

  • Large applications We have begun to appreciate the difficulties of creating large front-end systems in Javascript. We have built entire modules of applications in Javascript, where the bulk of the code was in Dojo calls and UI handling code and the server-side code was essentially doing some core object management and responding to the browser in bursts of JSON.

    Our current preferred approach puts relatively equal amounts of weight on the front-end and server-side code. We sometimes prefer to use server-side template engines and generate HTML fragments, marked up with CSS class tags and small amounts of Javascript. We then use relatively lighter Javascript code on the browser to handle the user interaction and error handling.

  • Future relevance We are seeing Javascript move beyond the browser. It is becoming the new de facto scripting language in the strangest of places where an embedded scripting language is needed. The most interesting example of this trend we saw a few years ago was CouchDB, the non-SQL database with fantastic distributed features. CouchDB uses Javascript to allow programmers to embed business logic and configuration customisations inside the database. We are also seeing JSON emerge as a "language" to express arbitrarily complex data structures in deep hierarchies, an area previously thought to be dominated by XML. JSON can represent relationships between the elements of a complex data structure more precisely than XML.

    We are beginning to explore HTML5. We believe that HTML5, CSS3 and Javascript will be the basis for thick apps of the future, specially on the mobile platforms. We have seen the world move from Foxpro to PowerBuilder to Gmail -- all of which are thick-client applications in different forms. We believe thick client applications will continue in new garbs, and Javascript may the core of such software for the next few years.

RELATED READING