But something newer is brewing in the world of application development. Developers are pushing the idea of a thick/fat/rich application to the point where the client is completely in the driver's seat and building a custom back-end is an unnecessary, if not an obsolete, endeavor.
I believe this is occurring because of the following 16 ideas/movements/factors that have been percolating in the web community for a couple of years now.
As a front-end engineer, I have been taking note of these movements for a couple of years and it seems to me that we are departing from a previous understanding of how applications are developed. When this happens new conversations need to occur and new terms need to be crafted for these conversations.
Several terms have been proposed (e.g. static, no back-end, un-hosted apps) describing various aspects of this shift to client-heavy applications that are decoupled from an abstracted back-end. None of these concepts have caught on because of the semantic baggage from words like "static", "back-end", and "hosted". The term I have settled upon is "Front-end Driven Applications" or FDA's. The definition of the term is still very much a work in progress but the gist is this:
Front-end Driven Applications run on the client first from static files (html, css, js) and rely on XHR or Web Sockets at runtime to connect to decoupled, non-custom, independent, third party back-end services (e.g. data storage, file storage, search, user management, emailing, payments etc.) that can't occur on the client alone.
I've already gotten push back that the term "Front-end Driven Applications" is really just another name for a thick/fat/rich application and completely unnecessary given that this isn't anything new. The reason I think we need a new term is because part of the definition of a FDA is the notion that the entire application runs first on the client and anything that can't occur in the client is passed off to a third-party service that is not a custom back-end. This, I believe, is a completely new way of thinking about the construction of an application, even if some of the parts are old hat.
Only using back-end services when needed and only doing so from the client is certainly not the ideal architecture for every application. In many cases, thinking of the back-end as a set of independent black box services is just not realistic. However, given the attention this area of thought has seen recently, it is obvious that some people believe FDA's to be a viable alternative to a traditionally built back-end. I believe the following five scenarios exist that might lead a person to build a Front-end Driven Application:
If none of these scenarios resonate with you just consider in general that FDA's are generally simpler, quicker to develop and test, and cheaper to host. And that might be all the reason you need to implement one.
Building an FDA is far from a perfect endeavor. Several details complicate the construction of a Front-end Driven Applications.
I have no idea what the repercussions of building FDA's will be, or if it will even gain mainstream mindshare. This movement to Front-end Driven Applications might simply be a small stepping stone to the next major shift in web applications. The important thing is that, as a front-end engineer, FDA's help me build applications faster, with less risk and dependencies, without having to care about the back-end. If that sounds good to your brain, then give it a try. I recommend starting with a combination of UserApp, Firebase, Swifttype, and Zapier or Telerik's all in one Backend Services if you are building an application. If you are building a website you might try something like Contentful or Prismic.
Cody Lindley is a front-end developer working as a developer advocate for Telerik focused on the Kendo UI tools. He lives in Boise, ID with his wife and three children. You can read more about Cody on his site or follow him on Twitter at @codylindley.
Subscribe to be the first to get our expert-written articles and tutorials for developers!