Re: Why SPAs are usually a waste of time/money

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

On Tue, Oct 30, 2018 at 7:22 PM Nicola Mingotti <[email protected]> wrote:

>
> The author analysis is very long and it is out of my possibilities
> to do a full review.
>
> But, skimming through it these are my naive thoughts:
>
> *] 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
>
>
>
>
>
>
> On 10/30/18 6:53 AM, Greg Navis wrote:
>
> 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
>
>
> Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <[email protected]?subject=unsubscribe><http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
>
>
>
> Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
>


Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>