Why SPAs are usually a waste of time/money

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

This article assumes a lot about the problem being solved and the team
solving it. In general it's also dangerous to just categorical assert that
an entire suite of apps in the wild are doing it wrong. It also entirely
disregards several of the benefits of SPAs. Having a CDN deliver your
frontend can save you money, time, and performance. Separating your API
from your frontend can push forward the timeline of opening up your API so
that other companies can integrate with you. Testing on MPAs on the
actually frontend interface tends to be disregarded, whereas with SPAs it's
a first-class citizen.

I'm all for sticking with the monolith and rolling with the Rails blessed
path, but this article comes off more as an uninformed viewpoint about the
quality of frontend development these days than it does a discussion of the
tradeoffs. There is more complexity there for sure, but there are many
benefits not discussed.

Also just saying anything is a bad architectural choice 99% of the time is
wrong. Everything has to come with context.

···

On Tue, Oct 30, 2018 at 9:53 AM Greg Navis <contact@gregnavis.com> 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.

The Architecture No One Needs | Greg Navis

Thoughts?

Best regards
Greg Navis

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

--
*Kevin D. Deisz*
CTO, CultureHQ <https://www.culturehq.com>

My 10p:

I can see that if you have separate, skilled front-end developers then SPA’s make sense as a way of splitting up the work. But from the development side, you’ve significantly added to the list of skills your programmers need and the list of technologies that you depend upon.

From the user point of view, an SPA adds a lot to a site’s footprint. Most React sites behave poorly on my phone when I’m away from home!

Looking good is not everything. Maybe websites should look like websites, not apps. But yes, there will be times when writing all of your user interface in Elm or React makes sense.

···

From: ruby-talk [mailto:ruby-talk-bounces@ruby-lang.org] On Behalf Of Greg Navis
Sent: 30 October 2018 13:53
To: Ruby users
Subject: Why SPAs are usually a waste of time/money

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

Click here to view Company Information and Confidentiality Notice.<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer>

Please note that we have updated our privacy policy in line with new data protection regulations. Please refer to our website to view the ways in which we handle your data.

You raise some valid questions to consider. But imo the credibility of the
articles suffers because, as others have pointed out, you’re seriously
overstating your case.

Thanks for posting this!

···

On Tue, Oct 30, 2018 at 11:37 AM Andy Jones <Andy.Jones@jameshall.co.uk> wrote:

My 10p:

I can see that if you have separate, skilled front-end developers then
SPA’s make sense as a way of splitting up the work. But from the
development side, you’ve significantly added to the list of skills your
programmers need and the list of technologies that you depend upon.

From the user point of view, an SPA adds a lot to a site’s footprint.
Most React sites behave poorly on my phone when I’m away from home!

Looking good is not everything. Maybe websites should look like websites,
not apps. But yes, there will be times when writing all of your user
interface in Elm or React makes sense.

*From:* ruby-talk [mailto:ruby-talk-bounces@ruby-lang.org] *On Behalf Of *Greg
Navis
*Sent:* 30 October 2018 13:53
*To:* Ruby users
*Subject:* Why SPAs are usually a waste of time/money

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.

The Architecture No One Needs | Greg Navis

Thoughts?

Best regards

Greg Navis

Click here to view Company Information and Confidentiality Notice.
<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer&gt;

Please note that we have updated our privacy policy in line with new data
protection regulations. Please refer to our website to view the ways in
which we handle your data.

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

--
Sent from Gmail Mobile

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.

The Architecture No One Needs | Greg Navis

Thoughts?

Best regards
Greg Navis

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

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 <nmingotti@gmail.com> 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.

The Architecture No One Needs | Greg Navis

Thoughts?

Best regards
Greg Navis

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe> <ruby-talk-request@ruby-lang.org?subject=unsubscribe><http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt; <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;