My 2 cents on the future (today and beyond) of web development

I was asked my opinion on the future of web development.  I blasted out my not well thought opinion, only from the development angle.  I think I owe myself a well organized response to express my point of view better next time.

AngularJs + RESTful data service + pre-composed HTML

I believe a web framework/system should handle/serve data and static assets separately.  The job of composing the UI html DOM will be handled by javascript framework - AngularJs.  If there is a need for the home page to display near real time "dynamic content" in a fast and robust fashion, the home page html will be pre-composed by a worker process at the server side and save the html to the CDN servers.

Better Customer Experience

There are many pages, especially home page and SEO pages, serving the same "dynamic content" over a long period of time - P, where P is the length of time the "dynamic content" is updated.  

I think the worst user experience are getting 500 error or a nice error page.  This happen when sever side scripting logic is having uncaught exception to compose the html of a requesting page.  Serving static html with the pre-composed "dynamic content" can effectively reduce the 500 error, and improve customer experience and performance.

When the traditional GET/POST round trip is encountering error, browser is redirect to the error page == customers yell WTF.  UX building around ajax or websocket interaction, provide better workflow experience because both browser and its user are in the same continuous context, rather than redirect, load and rebuild context. 

Same level of Security

The same security protocol that is used to protect a MVC web server can be used to protect the RESTful data service.  After all, RESTful data service is just another MVC web server using the same HTTP protocol.

Better Availability

When 500 responses are reduced, the web site availability increase.

With the separation of static and data server, scaling can be better tailored and customized to the I/O bounded and CPU bounded strategy, in contrast to the server side scripting web system.  For example, static file server, CDN, can adopt caching strategy with less CPU resource, while more CPU/memory budget can be invested into data servers, or even adding more instances to host the heavy weight data service.

Effective scaling improve availability as well.

Better Performance

In terms of composing static HTML, it is simply O(1) vs O(n); the static content needs to be composed once and serve n requests; while server side scripting compose n times to serve n requests.

In terms of constructing dynamic data, the data service only need to construct and return the data payload in an ajax call; while the server side scripting need to construct and return the entire html. 

Complete Separation of Concern

Modern web site heavily depends on javascript scripting.  I remember 10 years ago, web design/development still needed to consider the case of browser with javascript turn off, while today browser having javascript disabled == who cares, not my customer.

Base on the software system design principal - separation of concern, I believe all UI manipulation logic be contained within the same code base as much as possible.  When javascript DOM manipulation is a requirement, the UI logic/assets should be contained in client side code base as much as possible.

Even with the best practice of MVC on server side scripting development, the view and view manipulation logic are sharing responsibility with the client side javascript UI code.  Embedding javascript in the view and in-lining dynamic value in javascript when composing at server side causes more confusion and inconsistency in the system.

Easier for Testing

Since decoupling presentation and data logic into 2 sub system, testing on each sub system is simpler.

For client side testing, a data stub can be easily injected to mock the data coming from data service under AngularJs framework,  The UI testing parameters can be easily setup on client side scripts.

For data service testing, since it is a RESTful web service and the return payload is JSON string, the tests can be easily scripted and automated.  Validating a JSON string is much easier than validating a HTML string.  For lazy developer like myself, I use Chrome App - Postman to do minimum sanity check.

For pre-composed HTML testing, a test step can be added to the end of automated HTML composing process.  The end result HTML can be loaded into headless browser, like PhantomJs or simply be parsed and validated.