single-page-application – What are the advantages and disadvantages of SPA (Single-Page Application)?

Question:

From what I could understand, SPA ( Single-Page Application ) are basically pages that do not undergo constant reload (hence the name, in free translation, " Single-Page Application "), that is, they change their content dynamically by interaction user, unlike a conventional website, where each page with different content is loaded individually.

Searching on the subject , I saw information that large sites such as YouTube, Gmail and Facebook use this feature. I also noticed that almost everything is handled on the client side.

So I would like to know what are the advantages and disadvantages of using a SPA, in terms of security, SEO, maintenance, performance and what you can add will be very useful in terms of information.

Answer:

Benefits

  • One of the biggest advantages, which encompasses the others, is that the rendering is client-side.
  • There is a better overall user experience, of course, since everything is done right, especially latency until final rendering is extremely reduced.
  • There is a reduction in traffic to the server and this is obviously very good.
  • Especially parts that are always the same just don't travel anymore.
  • It removes load from the server that has a lot to do and little slack and tries to save on it by passing the heavy work to the client that always has a lot of slack, even helping to reduce the chances of successful attacks.
  • In times of very variable portviews and even midway changes rendering on the client side is very important. Imagine each change having to go to the server and bring up the entire page again.
  • As everything is there monolithically, it is easier to control the state between the different moments of the application, when it involves HTTP we have no state and we have to simulate a way to control it.
  • If done properly, some parts may still work without connection.
  • Not because of the SPA itself, but the fact that the application as a whole was designed for your use makes it easier to use the same application for other customers.

Disadvantages

  • In general it's harder to get it right, almost everything we see out there is fraught with problems.
  • Especially it is difficult to code SPAs, difficult to test, monitor, analyze, rework, understand state passes, detect errors, catch security issues, etc.
  • Opens up more security holes.
  • You have no control over what happens to the client, and you need to be more careful with what comes from there, although this care should always be absolute.
  • It is much more difficult to maintain some state, history, position and other controls that complicate precisely because it maintains state or because the client doesn't know how to deal with it since it was more prepared to deal with several transacted pages, in short, the navigation can be worse.
  • It can be quite complicated to maintain good SEO, so SPA works better in applications, preferably closed to logged in users, and not for content websites that need to be found. Although some think that this is not a problem today, it is easy to fall into situations where the content is not indexed, especially when the person wants to make fun of the content and needs human interaction for it to appear. It is possible to solve all situations, but with a lot of work, a lot of difficulty to know if everything was answered and worsening the experience for the user. It usually doesn't pay off, and almost no one knows how to do it right, so it's best to consider that your SEO will always suffer.
  • You need to have mechanisms when you fall into content that is not the site's entry point, and that's not that simple, and almost always overlooked.
  • Most web programmers don't understand the medium and can't produce adequate usability for something more complex like that, which they need to take care of, and which isn't easy.
  • If you have a version change on the server you need to have a mechanism for the client to know about this and transition accordingly. It is not simple to do without losses, and almost no one does it, probably not even aware of the need for it.
  • Any browser version change or non-normal usage may cause further problems. It's not that it's free if you choose to render on the server, but the more you use modern features, the more you abuse JavaScript, the more it complicates the code there, the less you have control over exact rendering. Remembering that there are people who do not enable JS or even use a browser capable of performing this. Maintenance can turn into a freak show, and all for yesterday, a lot of the work is putting out fires you didn't create. Of course, many don't, because they don't have control mechanisms if the client is working and create pages that few people use, so everything goes unnoticed. That's why there are more and more sites that don't work. Do you get in touch to let me know that it doesn't work? Only if it's critical to you. In general, it doesn't work all its life.
  • The browser is a very heavy and bad platform. One page quickly takes up more resources than all of Windows XP uses with many applications running. And people complained that XP was heavy, now everything is beautiful, you'll understand people's minds… If I abandon the use of the web (I can keep the sites simple, without SPA) I need a computer with half or even 1/4 capacity. The application does not scale well.
  • JavaScript is not a language created for large applications and therefore does not scale well. At the very least TypeScript should be used. In fact TS has several of the problems of JS and therefore avoiding using these languages ​​can bring more quality to the whole (although this also has its negative implications). Development does not scale well.
  • Most people who work with the web are not real programmers and don't know how to make complex applications. They do well with a server-side scripting language to deliver simple rendered pages there and eventually some client-side script to make a fuss, but doing a full application on top of a single document is way more complicated and we see horror shows out there. . It seems that people feel bad about not doing something simple, they want to do the same as Facebook thinking they are Facebook, without understanding how much the leading social network invests in talent to make it work.
  • When the SPA is used in place of a desktop or mobile application it can be detrimental to the user experience in a number of ways.
  • The initial load can be significantly higher, which can frighten the Internet user. Not only load, there are cases that the experience is worse due to latency, or incredibly increases server access. It's full of pages that respond more slowly with SPA. It's always a problem for someone who doesn't know how to do it, but a problem that occurs a lot.
  • SPAs are often less accessible for people with special needs.
  • People want to be funny, abuse it, it seems irresistible to put on unnecessary frills.

As a curiosity I see a lot of people saying that SPA is more responsive, and the term is used correctly. The problem is, people also use "responsive" to viewport measurement differences. This term was never adequate and at this point we see that they have two problems, in addition to having no meaning, it is ambiguous with another characteristic in the same context. Responsive is that: responding fast; forget the other usage, we need another term for the fit to the screen.

Scroll to Top