First off, thank you for sharing your thoughts about SPAs, but I have to ask, what year did you write this article? Not only do you group the idea of all SPAs in with uber frameworks like Angular and Ember (neither of which are the only way to build apps in JS, you should follow the Unix philosophy and build your apps from small composable pieces, which is the Node way), but you also gripe about a lot of issues that are non-issues anymore. Unlike your article, I will provide examples of what I am talking about.
Maybe your single page app is different, but the ones that I know break most of my browser’s features, such as the back and forward buttons, page refresh, bookmarking, sending a link, or opening a link in a new window or tab. They offer no way to link to something that I look at.
The issues surrounding history management and deep linking have been worked out for awhile. As mentioned in other comments not only do the big frameworks have routing libs now, but there are standalone routing libs as well that let you structure your application in route based components which makes it very easy to navigate forward and backward as well as share app state with deep links.
They are bloated and slow to load, even though the actual information they display and the interaction they offer is very simple.
I can almost hear you say: “But I don’t care about the web. I’m building an application, not a website.” To which I say: Go ahead then, build an application, using your desktop’s or mobile operating systems native toolkit, or build an applet, or a Flash or Silverlight application. That’s all fine by me. I don’t even object to you building the same thing using the browser as an application runtime. Just be aware that when you do things this way, your application is on the web just as much as if you had built it as a Java applet. Be aware of what you’re sacrificing.
Honestly, I don’t even know how to respond to this. I have to ask again, what year are you living in? Even if an SPA is overkill and you need some type of embeddable widget, you should not pick a single technology you mentioned. Flash is being stripped from every runtime as we speak. Silverlight is not in Microsoft Edge and with IE 8,9, and 10 no longer supported that means Silverlight will soon be gone. I won’t even talk about Java Applets, WTF? If you don’t need to build an entire app you should be looking at something like Web Components, React components, or jQuery plugins.
Polymer 1.0 has been rebuilt from the ground up for speed and efficiency. The new, leaner core library makes it easier…www.polymer-project.org
Telling developers to build web apps the way we did ten years ago is about the worst advice you can give anyone. Times have changes, technologies have changed. Concerns are not what they once were. The ability to reach people through a multitude of clients has changed the way we need to think about how we store/provide/display the information that users want from us. It also means that we need to change the way we build our applications to better fill those new needs. You say that the server should be a state machine and that you should follow REST principles, “including stateless communication”. How do you accomplish stateless communication when the server is the state manager?
You also said, “Business logic does not belong in the client”, this is correct, that is what APIs are for. What it should say is “state management does not belong in your API”. The server application backing your clients is there to provide data and allow interaction with that data, that is it. Why should another application manage the state of the client? In your Utopia you have one server side app that renders content for all devices. How is that in any way less complex than multiple client apps. I have seen the affects of using a server side app to power mobile and web browsers, it wasn’t very pretty. Ton’s of the gorilla/banana problem starts to pop up when one client needs a feature that is slightly different from other clients. While the gorilla/banana problem focuses mainly on OOP, that same situation comes with inheriting unwanted behavior from extending views and templates.
It is completely fine for clients to handle their own state. In fact they should in most cases. Another issue with your architecture (which you give no details about) is that your build/release process is going to suck big time. Let’s take a look at a real life example of this scenario.
- Design team says button needs new text and color. (5 minute change)
- Developer makes changes (maybe an hour of work, maybe)
- Developer commits and pushes change
- The entire build is run including all tests for all clients and the server application (who knows how long this takes)
- The release can’t go out yet because there is a bug in another client that needs to be fixed found by QA. (A few days)
- The bug is fixed but it produces another unforeseen bug because of all the complex rendering logic for multiple clients is starting to get too confusing. (Another few days)
Your button and text roll out to production two weeks later.
That is a real example that I have seen first hand. Separation of concerns is key, and you will never convince me that my API should be concerned about the state of any of it’s clients. The benefits you portray in your post don’t really give the whole picture. You say not to focus on developer friendliness and instead focus on customer happiness. I think you need to find a spot in the middle. Having great customer focus is awesome, unless you can’t get your product to them quickly, then they will most likely find it somewhere else.
Whether it's a client or server-side component, a Node module or a piece of visual UI, components that are large are…addyosmani.com
Tired of keeping all your dependencies up to date? Uncomfortable with using loose version ranges? Yup, so are we. So we…greenkeeper.io
Some people object to this because they believe that SPA gives you a better architecture. I disagree: With an SPA, your architecture typically is the one suggested by your framework because from a web perspective, your SPA is a single thing the web is concerned with. With a non-SPA approach (which I’m going to call ROCA from now on), the architecture governing your applications is the one of the web itself.
I’m not sure what you are trying to say, sounds like you’re saying that SPA frameworks like Angular and Ember are opinionated and have a pre-defined architecture that they promote. Oh, you mean like Wordpress, Drupal, Laravel, Django, RoR, and all the other opinionated server side frameworks?
Data is collected by scraping the relevant websites once a day via a cron job and then stored in a Postgresql database…www.modulecounts.com
A fantastic example of the problems created by the SPA approach is parallelization of work. If you have a team of multiple people, or God forbid, multiple teams working on the same SPA, you need to come up with a good way to support this. Instead, you can just have each of those teams build their own web application. Each of those applications can be connected to every other one built at the same time by the same organization (as well as to every other web application residing anywhere, if you want to) — in fact relying on the core strength of the web.
Again, Node modules solves this problem. Not to mention that that logic would just live on the server and not the client, how does having it be a server-side application do anything more than have those teams work on a different code base together?
In almost every case I’m aware of, your SPA has zero benefit for the user, and there are only positive sides to embracing browser features instead.
This is quite the bold statement to make, without a single example of it’s merit to boot!
As developers and the creators of products, we strive to deliver a high quality solution that we can quickly and…labs.mlssoccer.com