The development of modern web applications has become a complex task. Not only are programmers required to combine database, server and client technologies, but libraries to make the application more responsive and interactive must be integrated as well. Such rich internet applications thus consist of three tiers (database, client and server) where the client tier contains a substantial part of the application logic. Instead of manually reconciling the tiers and their own technologies, tierless programming reduces this complexity by taking a single language approach. This way the programmer focuses on the application logic, while a tierless compiler is responsible for distributing the code across the different tiers.
However, concerns like offline availability, latency and security transcend the program logic and the distinction between server and client code. Instead of merely programming in terms of server and client locations, it is more desirable to be able to program in terms of “functionalities”. Such functionalities can contain variables, functions, objects,.. and each functionality can be assigned to a certain tier. Based on the dependence graph, we can derive certain metrics of the program. The programmer can then relocate certain functionalities based on these metrics to another tier.
For example, an assistance tool for offline web applications can easily be built by analysing the tierless code, divided into functionalities, and building the dependence graph. Using an extensive query API on top of this graph, all information that is needed to calculate the percentage of offline availability for each functionality is available. These include counting remote data dependencies, thus meaning that data from another tier is accessed. Based on this report the developer can easily change the location of functionalities to gain a higher percentage for functionalities that must completely or partly work offline.
Furthermore, we can extend this to a scenario where not every functionality is assigned to a tier from the beginning. The developer can choose a “placement strategy” that calculates where these functionalities should belong. We think of strategies that focus on security, offline availability, … or a combination of different concerns. The developer can thus experiment with different placement strategies, in combination with the reports of tools we described earlier on, to achieve different placements of the functionality tiers. Once satisfied with the results, the program can then be compiled into distributed client and server code.
 L. Philips, C. De Roover, T. Van Cutsem, and W. De Meuter, “Towards tierless web development without tierless languages,” in Proceedings of the 2014 ACM International Symposium on New Ideas, New Paradigms,  and Reflections on Programming & Software, ser. Onward! 2014. New York, NY, USA: ACM, 2014, pp. 69–81.