Why SPAs are usually a waste of time/money

89 views
Skip to first unread message

Greg Navis

unread,
Oct 30, 2018, 9:52:58 AM10/30/18
to rubyonra...@googlegroups.com
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.


Thoughts?

Best regards
Greg Navis

Karthikeyan A K

unread,
Oct 30, 2018, 10:57:55 AM10/30/18
to rubyonra...@googlegroups.com
I have always stuck with the rails way and it has paid me huge dividends. Yes, in my company we have experimented with single page apps and have found that it took far greater time to build anything. I am happy that some one is speaking against SPA's.

Its like this, a micro kernel OS looks good on paper, but Linux has won today.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CAA6WWt_2v4SH_oQ5gH8BhZurrw1MrV6k9ybHu-mpAKSCc04o4w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


--
Karthikeyan A K

Founder of Code Tribe https://is.gd/codetribe

fugee ohu

unread,
Oct 30, 2018, 12:05:48 PM10/30/18
to Ruby on Rails: Talk
I notice basic staple sites like gmail rely on real time technologies like let's say React and ActionCable so things going to follow the need for real time 

gvim

unread,
Nov 5, 2018, 7:42:19 PM11/5/18
to rubyonra...@googlegroups.com
On 30/10/2018 16:05, fugee ohu wrote:
>
> I notice basic staple sites like gmail rely on real time technologies
> like let's say React and ActionCable so things going to follow the need
> for real time
>

Most business sites != GMail. In what sense is Gmail "basic staple"? If
anything it's the opposite.

gvim

Rob Jonson

unread,
Nov 6, 2018, 5:48:45 AM11/6/18
to Ruby on Rails: Talk


I notice basic staple sites like gmail rely on real time technologies like let's say React and ActionCable so things going to follow the need for real time 

gmail is a massive complex, hugely expensive site that is built by a large engineering (and management) team. It is painful and slow to adapt and extend.
nothing even remotely basic about it

Karthikeyan A K

unread,
Nov 7, 2018, 10:12:34 AM11/7/18
to rubyonra...@googlegroups.com

On Tue, Oct 30, 2018 at 7:22 PM Greg Navis <con...@gregnavis.com> wrote:
--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CAA6WWt_2v4SH_oQ5gH8BhZurrw1MrV6k9ybHu-mpAKSCc04o4w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

fugee ohu

unread,
Nov 7, 2018, 10:36:59 AM11/7/18
to Ruby on Rails: Talk
I meant everyone uses it 

Jake Niemiec

unread,
Nov 7, 2018, 1:38:18 PM11/7/18
to rubyonra...@googlegroups.com

My jab at SPA’s

Here’s my pointed, but respectful counter-jab.

Lot of boiler plate and decision making must be done before we start to attack the business of delivering results to clients.

I empathise with you, Angular 1 + PHP was a really rough time.

I used to finish a bunch of API’s and watch team of 3-4 front end developers toil with Angular for days. They envied me because it looked to them that I did almost no work, and yes I did almost no work, I used Rails and it di lot of stuff for me!

It sounds like you slapped a `.to_json` on a model without any thought to making the resulting object “consumable” for the JS side. This is difficult to do and involves taking time to learn how your JS coworkers need to consume the data you are providing. Normalizing the data and passing it in a hierarchy that matches the app helps a bunch.

The increase in time comes in the form of communication. The front end dev needs to understand the business, the API’s back end devs provide, next he needs to interact with the designer. There is lot of people to people communication and its a bottle neck, consumes lot of time.

It’s almost like front-end devs have more responsibility and stakeholders to answer to (design, data, security, interactivity). Like I said above, it involves taking time to learn how your front-end coworkers need to consume the data. It sounds like you were unwilling to educate yourself on what the app needed, making the JS side “jump through hoops” to get the desired format.

I have been on both sides of this problem. Here is part of a SPA where this happened: https://gist.github.com/jakeNiemiec/a1836c4d27920c7e51c3b884107c8a76 . If your code needs to do this, there is a problem. 

This time consuming “data massaging” is probably why the “front-end developers toiled” while you “did almost no work”.

Companies in India do love SPA’s, that’s for another reason. If you can show many busy programmers to the client, you can bill more. It a curse in India where people use tech for their selfishness (like Apple and Microsoft) rather than common good for humanity and the economy (like free software foundation). Its very bad.

Oof

all is there and it works like Rolls Royce.

I think this analogy is the opposite of what you intended. Rolls Royces are known to be overly expensive to maintain.

When they moved from prototype + RJS to jQuery I was furious, but they seem to have done the right thing. When they moved to Coffeescript, I was very happy at least I may not need to touch this Javascript directly. I am telling good people on this earth to kill this evil Javascript because I don’t have the power enough to do it….I am a person who likes to sleep at night, earn handsome, do projects to people who do not have deep pockets. How can I go for a SPA?

You could start by learning the pain-points that API-consuming apps face. State management is hard on any platform. Client-side routing is difficult to get right with virtual routes, route guards and managing the transitions between states. I personally would dissuade anyone from SPAs, including Turbolinks (a SPA framework by definition).

I highly recommend giving modern JS a chance, I really like the re-introduction to JS guide from MDN. It’s my experience that most people who “hate” JS never took the time to learn it, it was always that brief annoying chore. Even if JS is “not your job”, people you work with will appreciate the ability to have an informed conversation about what they need from you in order to better do their job. That’s why I, formerly a JS dev, took the time to learn and appreciate what Rails has to offer.


Reply all
Reply to author
Forward
0 new messages