

Popup? Frontend Apps – A New Frontier - codylindley
http://codylindley.com/popupfrontendapplications
Popup frontend applications are typically completely driven by third party backend services (e.g. mailgun, firebase, userapp, stripe).<p>Is “Popup Frontend Applications” the correct term, well, I’m not sure. What do you think?
======
codylindley
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?

