Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Escaping the SPA rabbit hole with modern Rails

medium.com

Post reply on HN
Print view View original

21–30 of 137 posts

Re: Escaping the SPA rabbit hole with modern Rails

#21

Post by sho »

lucidone wrote: post #15

Are you building a website? The practices espoused by the author will be ideal. Are you building a web app? Will you have a mobile client alongside your web app? Using a javascript framework for your client(s) and decoupling your data from it's presentation will be a fruitful investment. All of these frameworks and their associated happened for reasons, and they didn't involve traditional MVC being good enough for ev…

> decoupling your data from it's presentation will be a fruitful investment

Very good point. You'll be building an API anyway if you want a mobile app. However, you can probably get away with a much smaller one, for only the most interactive parts of the app - I've gotten a lot of mileage out of simply embedding web pages for fiddly things like settings pages and other complex forms in mobile apps, saving the native API-driven section for only when needed. The hybrid approach can actually save on mobile implementation time in that way, too.

> a culture of staunch refusal to learn or do anything new in that job

Sigh. I have encountered this too. But I think it's mainly a person-by-person, or perhaps team culture, issue, coupled with the fact that Rails has been around a long time. I've been using Rails since it's in beta and am very happy to use React et al when called for.

Sadly, when (if?) React gets to 10 years old, you're going to see the same thing on that side of the fence! There's a certain type of person who's always going to be grumpy about learning something new.

Re: Escaping the SPA rabbit hole with modern Rails

#22

Post by sho »

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 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 technology. I know someone who has gotten it into his head that he needs to write his entire new web app using golang and microservices. I'd suggest that when he actually outgrows Rails enough to require that then he can suggest it to his 50-person-plus engineering team, but in truth I don't think he'll ever actually finish it.

Re: Escaping the SPA rabbit hole with modern Rails

#24

Post by Roboprog »

everdev wrote: post #5

Anyone have good experiences with an SPA architecture?

Yes. I/we are using AngularJS to update some applications (apps, NOT sites) that manage state forms from initiation within private organizations with a workflow through the counties up to the state. There is quite a bit of interactive validation and input formatting / lookup support in a small number of very long forms, so it helps to have most of the interaction on the client side.

Also on the plus side, the back end requires less code now. IMHO, where Java is concerned, less of it is better. (There is still WAAAAAAAY too much of it, compared to equivalent Rails code)

Javascript might not be quite as good of a “Simula 67” as Java is, but it’s a much better Smalltalk or Scheme than Java is :-). (A comparison which probably doesn’t hold for JS vs Ruby)

Re: Escaping the SPA rabbit hole with modern Rails

#25

Post by debaserab2 »

sho wrote: post #22
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 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.

Re: Escaping the SPA rabbit hole with modern Rails

#26

Post by blattimwind »

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…

> by making an AJAX request for any navigation and replacing the page body (instead of doing a full page reload).

This sounds like the "pjax" idea. I did this recently in a prototype; it's about 30-40 lines of JS (not including a shim for the pushstate-API) and maybe a dozen lines in the backend. It just works(R), and makes things as fast as the backend can deliver stuff. Much faster than stuffing hundreds of kB of framework CSS/JS down the browsers throat for each click, and far more simple than any JS-SPA-frontend-bingo-stack.

Re: Escaping the SPA rabbit hole with modern Rails

#27

Post by zmmmmm »

lucidone wrote: post #15

Are you building a website? The practices espoused by the author will be ideal. Are you building a web app? Will you have a mobile client alongside your web app? Using a javascript framework for your client(s) and decoupling your data from it's presentation will be a fruitful investment. All of these frameworks and their associated happened for reasons, and they didn't involve traditional MVC being good enough for ev…

> It also lead to a culture of staunch refusal to learn or do anything new in that job

I find one of the most difficult aspects of software is the very powerful "local minima" of effective (but not optimal) techniques combined with entrenched knowledge. People are so incredibly biased towards what they know well, and that bias is backed by objective evidence: when they do it X-way they are objectively faster AND better, and what's more, X-way has many objective benefits. This is the local minima in a vast multidimensional space of the benefits and tradeoffs of different possible technical approaches. The multidimensional problem of overall comparing X-way with Y-way is nearly impossible to accomplish, so we nearly always fall back to our intuition (aka bias) which nearly always leads us back to what we already know. And consequently most organisations are stuck in some version of a local minima that is very hard to escape, but ultimately represents a big disadvantage over time. But the question of when is the right time to move out of that minima - and incur the expense of navigating the hills between where you are now and the better minima - is really hard to solve.

Re: Escaping the SPA rabbit hole with modern Rails

#28

Post by virtualwhys »

kkrs wrote: post #23
everdev wrote: post #5

Anyone have good experiences with an SPA architecture?

Elm + Scala works for me. I'm using the same elm source with minor variations for both web & mobile (wrapped with cordova). So far, it's been working wonderfully.

That's an odd choice given Scala.js, any reason you're not all-in on Scala?

Re: Escaping the SPA rabbit hole with modern Rails

#29

Post by debaserab2 »

zmmmmm wrote: post #27
lucidone wrote: post #15

Are you building a website? The practices espoused by the author will be ideal. Are you building a web app? Will you have a mobile client alongside your web app? Using a javascript framework for your client(s) and decoupling your data from it's presentation will be a fruitful investment. All of these frameworks and their associated happened for reasons, and they didn't involve traditional MVC being good enough for ev…

> It also lead to a culture of staunch refusal to learn or do anything new in that job I find one of the most difficult aspects of software is the very powerful "local minima" of effective (but not optimal) techniques combined with entrenched knowledge. People are so incredibly biased towards what they know well, and that bias is backed by objective evidence: when they do it X-way they are objectively faster AND bett…

> but ultimately represents a big disadvantage over time.

That presumes that Y-way is inherently advantageous to X-way. There's still plenty of sites that can and are market leaders using an out-of-flavor framework like rails/spring mvc/.net. New frameworks do not necessarily supersede old ones - they are usually a response to new use cases that have cropped up. These use cases may or may not be important to your business.

Re: Escaping the SPA rabbit hole with modern Rails

#30

Post by zmmmmm »

I have to admit, I do not know Turbolinks well, but I feel like the author misses something fundamental about the benefits of modern frameworks. It's not just about building a giant SPA - component-based design is a huge value proposition.

The problem I see at the moment is that client side "apps" - however they are rendered - hit a wall in complexity that is really hard to overcome without a a sane and sensible way to break them down into pieces. Just like every sane regular programming language has concepts of classes or modules or some kind of system for divide-and-conquering problems into pieces, your front end needs that too once it gets complex. And that's what these React/VueJS frameworks are doing for me. What I like is that they make the right solution - breaking a piece of logic or code into its own component - the easiest solution. So I tend to do the right thing, not because it's "the right thing" but because it happens to be the easiest thing to do.

I know this is a bit of a parallel argument with respect to whether you build a SPA or not (especially Vue can live in either world just fine). But I feel like the author is throwing out the component-baby with the SPA bathwater.

Post reply on HN