Friday, October 18, 2013

Web Apps Development - Clearing the mist

Web 2.0, Ajax, REST, HTML5, javascript, jquery, node.js, single page apps, backbone.js the list goes on. How are all of these relevant? how do they fit in? when to use what? I found myself asking all these questions and things kept on getting misty, till finally I decided to look at all these "trends" in a way they had naturally evolved. Here is a log of that realization...

HTML, servlets, JSPs, the grand daddies of web apps
Post the decline of windows based business applications, since the late nineties, the browser based web applications have served business requirements well. Typically server side technologies like servlets and JSPs/ HTMLs were the work horses of such applications. These web apps were very much page centric, with html based pages dishing out functionality, navigating to additional pages etc. The need for reducing complexity and controlling page flows centrally was naturally was felt

Enter JSF..
JSF with their server side component models and declarative flow logic were quite a hit. But navigating to pages over http at internet scales, meant a rather poor user experience as compared to say desktop applications. Could this pain be reduced if not removed...

Enter ajax...
Ajax brought with it the ability for browsers to asynchronously communicate with server sides. Partial pages could now be refreshed on demand, by using javascript to issue out ajax requests. The data gotten over an ajax request was often many times lesser than the entire html page going over the wire. As ajax got more popular and powerful libraries like jquery emerged, it became a very accepted thing to load the html, css, javascript etc in the browser and then merely get the dynamic portions i.e. data to be requested over ajax calls.Server sides also started catching up and providing interfaces that could be easily consumed by clients like HTML+javascript.

Enter REST...
Emergence of REST-ful architectures and REST webservices, only added fuel to this fire and increasingly mashups and web apps were consuming REST services and were getting more decoupled from the server sides

Emergence of mobile apps and devices...
The same REST services could be consumed not only by browser based clients but also by native apps like iOS and android. since all they needed was a capable HttpClient. Soon mobile apps were all the rage and it only a matter of time before people started comparing them with conventional web apps. Mobile apps, with their native code, seemed much more responsive and provided much better UX, as compared to browser based apps. Could we have a browser based app, that communicated with the server only when it needed data, rather than request the entire view (with data)?

Enter Single Page Apps 
In single page apps, all necessary code – HTML, JavaScript, and CSS – is retrieved with a single page load, or the appropriate resources are dynamically loaded and added to the page as necessary, usually in response to user actions. The page does not reload at any point in the process, nor does control transfer to another page. Single page apps, optimize traffic between client and server, by going to server only for data input or output.This results in the role of the web server evolving into a pure data API or web service. Also, the UX is markedly improved since, unlike in page centric apps, views in UI dont travel across the wire. The notable cons, until recently were browser history, SEO to name a few. Everything said and done, the client sides and server side(REST services) are distinct.

Enter backbone.js and javascript frameworks explosion
With UIs increasingly getting built with client side technologies like HTML/5, CSS3, javascript, etc the complexity started moving over onto the client sides as well. To manage this complexity of maintaining, views, models in sync, view navigation logic, validations etc there was a dire need of frameworks and thus MVVM, MVC frameworks like backbone.js have started emerging out.Try having a look at sencha extjs to understand one more flavor of a pure javascript single page app framework

Enter node.js
Since the server side increasingly started becoming  a mere provider of REST services aka data, there was a need for simplifying server sides as compared to Java EE servers and also with the intention of making the server sides more scalable. hence the emergence of frameworks like  node.js

Enter full-stack frameworks like meteor
With node.js its very much possible to use javascript on server side and as a result, transparent client/server communication is possible, no longer do we need to develop web apps as strictly in client and server silos, we can reuse code such as validations across client and server and also using transparent client-server bridges/pub-sub, it is possible to write client javascript code to persist to a NOSQL database like mongodb. This simplifies the web application stack by order of magnitudes


Though the above stacks have been mentioned in evolutionary order, each has its own relevance no doubt and rather than picking out a winner or eventual winner, my attempt is to raise awareness about these options, so that the right tool can be used for the right job.


Cheers!

3 comments:

Seth Bobrow said...

Ganesh- This is cool stuff. Even for a non-techie with a strong interest in technology, you present development ideas that are clear, cool, and easy to comprehend. You are still one of the smartest guys I know.

Seth Bobrow said...
This comment has been removed by the author.
Anonymous said...

Wonderful article to understand how, which and why the JavaScript technologies have exploded.