The concept of a “thick client”, “fat client”, or “rich client” application is not new wave thinking. Adobe flash applications poked at this problem for years. It’s adoption as a web application architecture might still be seeping into the enterprise mainstream but building an application in the frontend that talks to an interface/API is not exactly ground breaking. Hybrid web 2.0 applications have been doing this to some degree for years. Sprinkling AJAX or JSONP strategies into web pages and calling it a thick/fat/rich client is almost old hat. From here however, where are we headed?
Where are we headed from web 2.0 and how do we categories and refer to the evolution of thick client applications that can be popped up with ease by using static files and third party services from the frontend?
Popup frontend applications are typically completely driven by third party backend services (e.g. mailgun, firebase, userapp, stripe). Pragmatically speaking, a backend is not exactly absent, but instead the backend has become a plug and play service component to the architecture which provides an interface (be it a REST api or some special JS sugar kit) to commonly needed application functionality. In other words, applications typically require parts that do things like email communication, data storage, user management, and payments. As of late, all of this can be provided as a third party service and handled in the client using some form of a public interface/api. Because the frontend is doing the interfacing the application logic itself (i.e. html, css, and js) can be served statically.
Now, given the static nature of the files sent to the client and the third party approach to backend services this new frontier is currently being labeled as “static”, “no-backend”, “un-hosted” or “backend-less” application development. I find these terms confusing and and to some degree outright misleading.
This new frontier is not about static files alone. The files themselve are very much dynamic in nature/function and are not unlike the notion of a dynamic web page of the past, but I suppose strictly speaking they are served statically. However, while literally served statically, their nature is still very much dynamic. Thus, the term “static apps” does not seem appropriate to me.
As for this idea of no, un, or less backend. Well, none of that is exactly true. It’s not no, un, or less backend, it’s simply a backend that is not custom built or maintained by the same developer(s) who construct the static application logic. This does not mean the backend is gone, it simply means that the backend is relegated to a foreign land (i.e. third party) and has become a service switch that frontend engineers can turn on and off and scale as needed.
But let’s not consider this new frontier a complete off the shelf backend black box either. That would be a mistake as well. To setup a service still requires some backend chops and in the future knowing how to configure the switches is still a requirement to get started.
I believe this new frontier can best be described as a land of frontend applications that one can simply popup by standing on the shoulders of robust services providing simple and commonplace interfaces.
Is “Popup Frontend Applications” the correct term, well, I’m not sure. What do you think?