Decoupling the View from the Logic: Part 1 of 2 by Julian Flaks

Decoupling the view from the logic in an application is an old concept, and it is a concern which still affects choices in the back end and front end alike. In part 1 of this 2 part article, EQengineered will discuss the big picture and history of this separation; then, in part 2, we will focus on contemporary versions of the same challenge, and especially upon how global state fits into solving this in React and Angular.

Server side rendering

Before the SPA and as far back in web applications as CGI, requests to the back end resulted in rendered pages of markup coming to the browser. With the same code responsible for putting text into spans, as for manipulating data and applying business logic, the risk of muddling them together was great. JSP pages became unreadable nestlings of markup within control flow statements, and Perl and PHP pages struggled to develop strong code structure.

Templating grew deliberately more constrained. In the Java world, technologies like Velocity tried to enforce a sane differentiation between a limited function set needed for generating output, while not allowing all the other tasks that belonged in different layers of apps.

AJAX and data endpoints

Gmail was perhaps the most high profile application that spread the new approach to web applications: the XMLHttpRequest which would let JavaScript fetch only new data, without a new web page with its consequent memory wipe.

Performance and UI complexity were the most obvious winners, but the benefits it led to in architecture were profound. Developers saw the light, realizing over time that the browser-server divide was a perfect vehicle for separating view and logic. REST, born out of slightly more specific goals in server architecture, made an ideal companion to this trend, and brought a discipline and form to what a data and logic server-side would look like within the architectural whole.

The divide has changed how most of us conceive web technologies today. Even the disciplines of developers have divided into server concerns and user interface needs - scalability and resilience on the one side, and responsiveness on the other. Those developers who truly cover the full stack of web apps must look at it with the technical awareness of both camps rather than by shortcuts which fall short of either.

At its purest, this separation via a REST contract can allow a complete replacement of either the front-end codebase or the server-side, without the counterpart needing to change - a powerful insurance policy for the future support of an application.

In part 2 of the article, EQengineered will consider how the struggle to separate view from logic still plays out today, not only inside our modern front end frameworks, but also in the subtleties of architecture - and ways to stay alert to the mission.