A lot of developers seem to think SPAs are the new default best-way to do things. You can build many wonderful applications with this approach. I know, I’ve built some. And of course we have all used some amazing SPAs. However, the herd-like rush to abandon the simpler web application model works to the disadvantage of many. I will explain why.

First, let us observe what happened with the NoSQL craze of several years ago. A lot of people went out and tried to abandon one of the most proven and valuable technologies of the Information Age — SQL and the relational model. On the plus side, we got Redis. And Postgres got document storage. Then we moved along. However, I know people who lost big contracts, money and even their businesses by too-quickly embracing this fad.

Shepherds have to watch their flock and developers definitely exhibit herd behavior.

Now, let’s take a look at what SPAs are in fact. Heavy Javascript clients really represent a sort of return to the old client/server type applications albeit with different technology. They almost demand a hard split of “front-end” and “back-end.” This strongly incentivizes career specialization.

This split and specialization affects the power balance of employee and employer as well as the power balance between capital and the aspiring entrepreneur. It also affects the ability of the freelancer to hang up a shingle and deliver entire solutions on their own or to build up a small practice into something that would grant him or her financial independence.

With Rails, it became possible for a single individual of even modest talent to develop an entire application.

If we embrace a split into server-side and client-side, most developers will lose this capability and will be dis-empowered.

In the last year we have begun to see something of a backlash against the “full-stack” developer model that Rails did so much to advance.

If you are a “full stack” developer, then you were empowered by the approach Rails championed. I know I was. And that is what excited me so much.

Client/server is basically what many developers were doing 15 or 20 years ago under a new name, with new tech. Most such apps were developed by teams. The architecture, per Conway’s “Law”, followed the organizational structure.

What a lot of younger people may not know is that the advent of the web application was a sort of return to the “mainframe.” Now it is called, “Cloud.” Today anyone can rent micro-virtual-mainframes on digital-ama-rack-hero-ocean-yard-space. Web apps are basically screens, forms and transactions. All the important stuff happens on the server.

The browser replaced the mainframe terminal.

The difference now is that powerful servers cost so little that almost anyone can afford one and start making something useful. That and everyone has terminal in their pocket.

Remember these?

Same schlock different decade

Now, hopefully what you develop doesn’t resemble either of these in appearance. But how different is it logically

Now we are here…

Except for a few key features or window dressing, most apps still reduce conceptually to some form of Create, Read, Update and Delete on a few, tens or even hundreds of record types. This is especially true of all the SaaS apps that aim to “disrupt” various stodgy old line businesses, create new efficiencies and fortunes for their creators. Does your app have forms? Yeah it probably does.

With SPAs, people seem to want to develop the equivalent of full-page Java Applets (only better looking) all over again with less mature tooling. Tread cautiously here. Especially if you are starting out on a new application.

The SPA approach is more interesting the further you get from a form-heavy CRUD transaction type application. But if much of your app conceptually reduces to updating data with forms and/or simple transactions, the SPA architecture is almost certainly overkill.