Ruby on Rails Wednesday, November 7, 2018

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.


On Wed, Nov 7, 2018 at 9:12 AM Karthikeyan A K <77minds@gmail.com> wrote:

On Tue, Oct 30, 2018 at 7:22 PM 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.


Thoughts?

Best regards
Greg Navis

--
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-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@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

--
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-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CAJR%2B9kYVw3KKqQw8F2b%3DUPjqhzscmntdQ6Z64JfnaKRf_5%3DavQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
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-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CALn2xuA-qEwUoM8NDzbwzrmW6s2YgBYT3giMpSnpjt1Loj2obw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment