Here's an explanation of the different levels in the evolution and the benefits gained at each level.
Level 1: PHP tags inside HTML markup
This is the simplest way to create a web page with dynamic content. Starting from a standard pure HTML document, PHP (or any other script language) tags are inserted instead of some of the static content (like replacing "Peter" by <?php echo $firstname;?>).
This makes it possible to write just one web document for all users instead of one per user, which would make projects like google or facebook simply impossible.
The disadvantage is that inserting tags inside markup is messy, and very limited because this approach considers the document a static one with some dynamic bits, instead of a fully dynamic (generated) page that takes advantage of all the possibilities offered by programming.
This makes it possible to write just one web document for all users instead of one per user, which would make projects like google or facebook simply impossible.
The disadvantage is that inserting tags inside markup is messy, and very limited because this approach considers the document a static one with some dynamic bits, instead of a fully dynamic (generated) page that takes advantage of all the possibilities offered by programming.
Level 2: HTML echo'd by PHP (or any other language)
This is the second step in the evolution, and it has the major benefit of considering the whole page generation process as a program, and not just parts of it.
That approach reveals a lot of cases where templating, markup generation, and other techniques can largely simplify and clean up the page generation logic and code. This not only means that much more can be achieved with less, but also that the resulting solution will be much easier to maintain because of its smaller size.
The disadvantage of this approach is that this increases server costs massively, partly because most web languages are notoriously inefficient, and partly because more work is being done on the server.
Level 3: Pure AJAJ (JSON, not XML)
There are many benefits to switching to such a technique, the first of which is the major decrease in server costs and the consequent increase in usage of client-side resources.
In this case, the only thing that ever transfers between the server and the application front end is the data itself, i.e. the strict minimum that you can transfer in order to have an interactive application.
In this case, the only thing that ever transfers between the server and the application front end is the data itself, i.e. the strict minimum that you can transfer in order to have an interactive application.
The page rendering process happens entirely on the client-side, no markup is generated server-side, and the little HTML that is required to start the application is simply cached as a static file, freeing up lots of server capacity.
Because so much more happens on the client side, many client-server trips are simply eliminated, and the user interface becomes incredibly more snappy, especially in higher latency regions.
This style has yet to become standard though, and most current web applications are still stuck between level 2 and 3, like for example google or facebook, who both use some AJAX/AJAJ (Level 3) but still base the core of their applications on server-side rendered HTML (Level 2).
Because so much more happens on the client side, many client-server trips are simply eliminated, and the user interface becomes incredibly more snappy, especially in higher latency regions.
This style has yet to become standard though, and most current web applications are still stuck between level 2 and 3, like for example google or facebook, who both use some AJAX/AJAJ (Level 3) but still base the core of their applications on server-side rendered HTML (Level 2).
Level 4: And beyond...
There are still good ways to improve on Level 3, most of which will focus on improving the architecture of the front end itself, a necessary upgrade as its complexity increased with the increased responsibilities.
Some good first steps are to create a front end API, which will be the channel through which all API requests are made, or a front end storage, which will enable advanced caching and save even further on server costs while offering even better snappiness.
Other approaches to automate the markup generation, bind data to its representation, and generally remove data from the markup enable us to consider it more as a pure presentation layer, resulting in a much cleaner, efficient and maintainable solution.
At Kanpeki, all of our projects are Level 4 and we are continually developing improvements on Level 4, in the hope of one day finding yet another critical improvement (Level 5) to deliver more value to our customers.
No comments:
Post a Comment