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?
I read the specs and tried to bring out the modern key parts with a focus on what I thought a developer should know or be aware of. The reason you don't see much written about this topic is the specs are not easy to read in relationship to each other. What do you suggest for syntax styling?
I agree there is a surplus. I tried to write a book that had not been written before. Or more so, a book that was written in a systematic fashion breaking down the nature of the JavaScript object. I've not seen this done before. Most JS books ignore the object nature because they don't believe most people will follow along.
I actually want/plan to follow this book up with a modern day DOM JavaScript book without mention of a library. However, I first believe the masses need to understand objects.
This is a great book. But its more broad than it is specific. Its extremely wide in its purpose. The intention of JavaScript Enlightenment" is to focus in on the nature of objects and the native workings of JavaScript objects. I don't see these books sharing the same purpose.
A free preview chapter and review is coming...I'm still working out the details.
And...while JavaScript is the same...breaking down the nature of objects into small conceptual sections supported by executable code (jsfiddle.net) is anything but old hat. IMO!
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?