Web applications evolve. From static HTML sites first to AJAX applications more recently, through multiple dynamic technologies (PHP, ASP, Java, Ruby on Rails…), Web application architectures and their dedicated tools regularly experience major advancements and breakthroughs.
For two years, we have seen a new wave of technologies coming, transforming the landscape of Web applications. Unlike RIA or AJAX before, there is no well defined name yet for this new trend. We will call it « MV* client-side architectures ».
Here is the main principle: the server no longer manages the whole page but only sends raw data to the client; all the pages generation and user interactions management is done on the client side, that is to say in the browser.
In this post, we will go into details of this architecture and explain why it is emerging. In a second post, we will see why it is relevant to embrace it today, opportunities they offer and what are the likely impacts for enterprises.
New Web application architectures: what are we talking about?
This diagram illustrates the evolution of Web application architectures:
Model 1: classic Web application
Model 2: AJAX Web application
This architecture brought more reactivity but also more complexity. It has many pitfalls:
- the extensive use of jQuery can make impossible the application maintenance, without implementing complex technical rules (offered today by MV* frameworks like Backbone.js and AngularJS)
- despite their aim to ease developments, server-side frameworks like Java Server Faces turned out to be very heavy and complex, leading to many bugs and performance issues.
Model 3: client-side MV* Web application
The third diagram shows the new MV* client-side architecture, whose principle disrupts with the previous ones: now the server sends only raw unformatted data and the client is responsible for generating the screen out of it.
The term MV* refers to the MVC pattern, for Model View Controller, widely used server-side to separate data and views management. More and more we use this term MV*, in order to highlight the little differences from pure MVC implementations. But this is an expert discussion…
The important point in this new architecture is the shift of all the UI logic from the server to the client.
This separation of concerns between server and client is not a new phenomenon. It has been taken back by native mobile applications, consuming APIs independent from the client. The new Web application architectures bring this possibility to Web applications.
Why were these architectures not implemented earlier?
The answer is simple: it was not possible; except if you are Google!
- browser limitations in terms of capacities and performances
The end of browser limitations
Unless having the strike force of a Google engineering team, developing a Gmail in Internet Explorer 6 was simply not realistic.
Since Firefox and Chrome have become popular in the browser market, Microsoft has caught up, as shown in this chart:
Since then, performances keep improving significantly. Together with the new capacities of both desktop and mobile devices, the browser can now do more than just displaying Web pages: it can dynamically generate pages, make 2D/3D drawings, execute complex algorithms, etc.
But having a powerful execution platform is useless if we can not develop effectively.
Conclusion of Part 1
In this article, we have presented what we mean by « MV* client-side architectures » and why they are now emerging.
In the following part, we will study why you should now use these architectures, what are the pitfalls to avoid and what are the impacts for enterprises.