I would like to share my humble opinion. First of all I fell you overstate
your points making it look worse than it is.
*Statefulness: *frontend state is added on top of the already-existing
backed state
When I work with a SPA there is no state in the backend because the client
interacts with the backend based on tokens and request only the information
it needs. State is managed in the front end using setState, Redux, MobX,
etc.
Testing: the test setup is more complicated because we need to make the
backend and frontend talk to each other
Testing the backend api should be independent from the SPA. While they
connect with each other you can test all your API endpoints from your
backend. SPAs have their own tests which can make API calls.
*Performance*: An API-only backend renders and sends less data than an MPA
but the network latency is still there and the app won't be faster than
that.
Network latency is still there but you can use a CDN to greatly improve
your latency something you would only archive by having multiple servers
across different regions using MPA. Furthermore, API only backends send
JSON data which faster and more lightweight than server side rendered
templates especially under higher load. In terms of performance you can
also reduce a lot of requests because you can store a lot of state on the
client allowing you to use simple array manipulation such as filter, map,
reduce to render the views you need with already existing data.
Imagine a feed view where you would server side render all the posts as a
list. When the user clicks on a post you will have to fetch the post by its
id and server render that particular post again with any suggested posts
maybe.
Imagine the same app as a SPA. You would request the first 20 posts or so.
When the user clicks on a post you can filter all the posts in the browsers
using a simple posts.filter(() => {}) and render the post view much quicker
without making separate requests to the server. Furthermore you can
asynchronously load the suggested posts and add them to your client side
state.
Slow First-Time Load
I agree on this. But you can speed things up by configuring webpack/parcel
and only importing the components and libraries you really need.
*State Updates: *we're building an e-commerce site that has a list of
categories. We need to update the list from time to time. In an MPA, the
list is updated on every page load. That's not the case in an SPA though.
When you navigate from view to view you can do requests to fetch the
categories from time to time if it is an important part of your app.
*End note*I get what you are trying to say and I agree with some points
especially when it comes to small, medium sized companies. DHH shows us all
the time how good server rendered apps can be optimized through basecamp. I
do however still feel that SPA have a quicker response time and reduce the
overall weight on the backend. There are so many things that you can do on
the client side such as image uploading, data visualization, let client
state respond to requests instead of the backend. In the case of React you
can mix your views and as you said sprinkle react components where you need
them. Personally I'm still working on a MPA but I started to mix it with
React especially because it is simple and fun to use.
Sincerely Alexander,Good Article
Post by Nicola MingottiThe author analysis is very long and it is out of my possibilities
to do a full review.
*] Interfaces are important. SPA (so called) offer a better user experience
respect to MPA, i guess there is little arguing about that.
You could also say that a GUI is a terrible waste of resources when a shell
script can do the job. But the end user prefers GUI, so we build GUI.
If your GUI is sub-optimal, your competitors will make a better one.
There is no shortage of interface developers.
*] In my opinion managing the logic of a SPA application is easier
because it is a single thread running in the web browser. It is very
similar to write a program on your computer. Global variables are
always there.
You call the server for a DB access or to perform special tasks, but the
idea is clean,
when you need unavailable data call the server, ask a question, get an
answer, update your
page to display the answer. It is similar to what you would do in a non
web GUI.
*] It is my impression that that author thinks of SPA developed through
large frameworks which may be difficult to master. Personally, I develop
web stuff in Javascript/jQuery + Node + HTML + CSS. Once you learn
the basics of Node and control Ajax and the async nature
of the beast, It is not much more complex that developing standalone GUI
applications.
*] At the moment, in my web framework Ruby is running server side, for
automation. All
other stuff is written in Javascript, the server is Node.
*] I have not experience with Rails / Sinatra etc. Other people may tell
you about that.
bye
Nicola
Hey!
I'd like to share an article with you why SPAs are a bad architectural
choice from a business perspective 99% of the time.
https://www.gregnavis.com/articles/the-architecture-no-one-needs.html
Thoughts?
Best regards
Greg Navis
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>