Escaping the SPA rabbit hole with modern Rails • Hacker News Board

Re: Escaping the SPA rabbit hole with modern Rails

#31

Post by wjossey » Sat, Jul 07, 2018, 11:33 PM UTC

debaserab2 wrote: post #25

sho wrote: post #22

Earlier quoted context omitted.

> I felt a lot of pain once I began to try to mix in a lot more interactivity in the app I don't think you're actually disagreeing at all. You're using the right tool for the job. You started with one job and the right tool, and when the job changed you switched tools. That's as it should be! Use Rails until you can't. That's what you did and I can't see the author disagreeing. You can generalise this to most technol…

Another plus to this "ramping up" of tools as necessary is when you get to a certain point where your entire UI is sophisticated enough you can cut the views out of your rails app and basically transform it just a REST API with another service responsible for serving the UI layer. Rails makes a fantastic REST framework, especially if you build your app that way right from the start.

Good point, and this is exactly what I did. I actually was running the SPA + the rails app side by side. Took me about 6 months, but I cut over every page / app one by one till I was done.

And, to the parent commenter, good point. I do think the gist of the author is to use the right tool for the job, and they are not dogmatic about "never write an SPA". Thanks for keeping me honest.

Re: Escaping the SPA rabbit hole with modern Rails

#32

Post by zitterbewegung » Sat, Jul 07, 2018, 11:39 PM UTC

wjossey wrote: post #6

To the author of the article- Kudos! Well written, well reasoned, with minimal hyperbole or unnecessary “X is dead” style declarations. Hope we see more writing like this bubble up to the top on HN. I’m not swayed by the argument, but that’s personal bias. I’m the technical cofounder / solo coder of a venture backed startup, and I built our platform on rails 5. I migrated our front end to Vue over the winter and coul…

I think that prototyping your software with (insert server side software ) and jquery is a really good way to prototype. It lets you get to market and or fail faster .

Re: Escaping the SPA rabbit hole with modern Rails

#33

Post by EGreg » Sat, Jul 07, 2018, 11:59 PM UTC

wjossey wrote: post #6

To the author of the article- Kudos! Well written, well reasoned, with minimal hyperbole or unnecessary “X is dead” style declarations. Hope we see more writing like this bubble up to the top on HN. I’m not swayed by the argument, but that’s personal bias. I’m the technical cofounder / solo coder of a venture backed startup, and I built our platform on rails 5. I migrated our front end to Vue over the winter and coul…

If you use PHP and you like turbolinks etc. then look at this:

https://qbix.com/platform/guide

It has pages and AJAX out of the box, and works with existing web tech. Turn your website into an SPA.

Re: Escaping the SPA rabbit hole with modern Rails

#34

Post by meesterdude » Sun, Jul 08, 2018, 12:04 AM UTC

A very well thought out and articulated article.

I love Rails and the power it offers in development productivity and quality. It's code is very maintainable and actually enjoyable to develop in; even when it's someone elses codebase.

Oddly enough, I finally came upon a use case in a project where an SPA frontend (Vue) / ruby backend make more sense given the platform nature and operational needs (runs on a pi, no "models")

9/10 Rails is the way to go though for developing something.

Re: Escaping the SPA rabbit hole with modern Rails

#35

Post by rlafranchi » Sun, Jul 08, 2018, 12:37 AM UTC

wjossey wrote: post #6

To the author of the article- Kudos! Well written, well reasoned, with minimal hyperbole or unnecessary “X is dead” style declarations. Hope we see more writing like this bubble up to the top on HN. I’m not swayed by the argument, but that’s personal bias. I’m the technical cofounder / solo coder of a venture backed startup, and I built our platform on rails 5. I migrated our front end to Vue over the winter and coul…

I’ve had a wonderful experience using Vue in Rails applications and there are ways to do this without building a full blown SPA. The philosophy towards JS frameworks has usually been full throttle or not at all. I think there is a happy medium where you can use Vue when it makes sense to. This is a great application especially for existing projects that need to be more interactive.

Re: Escaping the SPA rabbit hole with modern Rails

#36

Post by mythrwy » Sun, Jul 08, 2018, 12:38 AM UTC

woah wrote: post #20

schizoidboy wrote: post #14

> For your SPA logic, you will want a rich model of objects that represent your domain and its rules. And you still need the same for your server logic. And this recipe is just a duplication waiting to happen. Great article overall but one premise I question is: how often do you really need a non-jQuery JS framework at all in the client? It seems to me that most apps are simple CRUD apps and server-side rendering is…

In jquery programming there’s a huge difference between how the stuff that shows up when loaded is programmed (on the backend) and how the changes you make after it’s loaded are programmed. This leads to a lot of weird inconsistency if you’re doing anything more than showing and hiding existing content. Also, with jquery everything involves a lot of imperative programming and stashing state in random places in the DO…

It's not necessarily the case that jQuery code devolves into a huge pile of spaghetti. It's very possible to stay organized without a framework, even for fairly sizable JavaScript apps. It takes a bit of foresight and thinking ahead and discipline, (usually resulting from having written piles of spaghetti in the past). But most large jQuery in the wild is indeed spaghetti, with that I will concur.

Re: Escaping the SPA rabbit hole with modern Rails

#37

Post by mythrwy » Sun, Jul 08, 2018, 12:39 AM UTC

codingdave wrote: post #17

schizoidboy wrote: post #14

> For your SPA logic, you will want a rich model of objects that represent your domain and its rules. And you still need the same for your server logic. And this recipe is just a duplication waiting to happen. Great article overall but one premise I question is: how often do you really need a non-jQuery JS framework at all in the client? It seems to me that most apps are simple CRUD apps and server-side rendering is…

You can go one step further and ask, if jQuery does the job for you, why do even need it? The core problems it solved (cross-browser reliability and DOM selections) aren't really problems anymore. Not that your point is invalid - many people do jump into modern frameworks for sites and apps that are simple enough to not need them. And SPAs don't need to be anywhere near as complex as this article proposes. But if you…

jQuery makes it easier though, particularly if you know it well.

Re: Escaping the SPA rabbit hole with modern Rails

#38

Post by woah » Sun, Jul 08, 2018, 12:55 AM UTC

mythrwy wrote: post #36

woah wrote: post #20

Earlier quoted context omitted.

In jquery programming there’s a huge difference between how the stuff that shows up when loaded is programmed (on the backend) and how the changes you make after it’s loaded are programmed. This leads to a lot of weird inconsistency if you’re doing anything more than showing and hiding existing content. Also, with jquery everything involves a lot of imperative programming and stashing state in random places in the DO…

It's not necessarily the case that jQuery code devolves into a huge pile of spaghetti. It's very possible to stay organized without a framework, even for fairly sizable JavaScript apps. It takes a bit of foresight and thinking ahead and discipline, (usually resulting from having written piles of spaghetti in the past). But most large jQuery in the wild is indeed spaghetti, with that I will concur.

Yea, you can write your own framework to avoid it becoming spaghetti. But most developers are going to mess it up. I've seen a lot of bad jquery apps and a lot of bad react apps. The bad react apps, they might be hard to understand, but at least they behave consistently.

Re: Escaping the SPA rabbit hole with modern Rails

#39

Post by Mc_Big_G » Sun, Jul 08, 2018, 1:21 AM UTC

korm wrote: post #19

Mc_Big_G wrote: post #8

Without any input from me and several other js devs in our org, it was decided that we'll do a complete rewrite of our Ember.js app in React. The primary reason stated was hiring and the secondary was build times. The first should have been performance but they've been pretending like performance doesn't matter and that it's good enough. It's not. Since it's easier to develop, our backend admin system is built in .NE…

I think if the conversion is led by a very experienced React developer this could be a good decision. We decided to write all our sites in React a long time ago and couldn't be happier. It doesn't have to be a SPA because it's React, we have static sites too. Judging by how your org made the decision without the devs input though, I'm not too confident it won't be disaster. It's depressing but I've been offered too m…

No one on the team has ever used React.

Re: Escaping the SPA rabbit hole with modern Rails

#40

Post by adjkant » Sun, Jul 08, 2018, 1:42 AM UTC

everdev wrote: post #5

Anyone have good experiences with an SPA architecture?

Yep, it's my go-to for any not huge web project. Plays well with any server-side tech you want, though I find Python (Flask, again with the right architecture, is a good experience) to be quite easy and enjoyable. The key is a sane and simple enough architecture from the start, which comes with experiences (aka making mistakes). But I personally go with Vue/Angular 1 consistently, trying to go more Vue now that Angular 2+ has IMO gone off the rails (heh).