Replacing the entire body with every request seems a bit overkill. If you want SPA interactivity without moving control to the client side, try intercooler.js
Escaping the SPA rabbit hole with modern Rails
41–50 of 137 posts
Re: Escaping the SPA rabbit hole with modern Rails
#42I 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…
Components aren’t a well defined thing. Most people mean “React class” when they say component. React apps are much more than components. Some components have their own state, some don’t, some touch global state, routing and data fetching are often not components.
“Component” web apps are by no means simple.
Re: Escaping the SPA rabbit hole with modern Rails
#43I had this same experience. SPAs, especially for small teams and solo developers, hurt more than they help.
Re: Escaping the SPA rabbit hole with modern Rails
#44To 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…
If you use Rails until you can't and then start making a SPA you'll have the common pattern of an application where you never have any idea whether any given thing is built in the Rails templates or in the JS or in some combination of the two.
Re: Escaping the SPA rabbit hole with modern Rails
#45To 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 .
I think that quickly becomes untrue if you have any significant amount of front-end functionality.
Re: Escaping the SPA rabbit hole with modern Rails
#46Anyone have good experiences with an SPA architecture?
Try developing Slack or Discord with Rails and turbolinks. The point is, some apps are naturally SPAs. For those that aren't then it is unneeded complexity to make them SPAs. Also personally, I have had great experience with Vue in an SPA.
Re: Escaping the SPA rabbit hole with modern Rails
#47Earlier quoted context omitted.
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 .
I think that quickly becomes untrue if you have any significant amount of front-end functionality.
Can you expand on significant amount of front-end functionality ?
Re: Escaping the SPA rabbit hole with modern Rails
#48To 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 .
Maybe for you. I write React and a web API (using Swagger in Ruby or TypeScript/NodeJS) significantly faster than I do any server-side framework I've ever used. React components are an easier way to frame HTML--here, let me not remember how Bootstrap elements are created and just invoke --and JSX is the most fluid and flexible templating system I've ever used.
Dealing with stateful and rickety jQuery is why I stopped doing web stuff in the first place. Having React and a halfway decent dev environment in ES6/ES2017 and now TypeScript brought me back.
Re: Escaping the SPA rabbit hole with modern Rails
#49Earlier quoted context omitted.
> 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 bus…
If new developers start at Y-way, we can assume they'll add more advantages to Y-way like improved tooling etc..., so maybe Y-way will eventually surpass the X-way.
In tech, it's not what one particular developer thinks but the consensus among the contributors which decides which one out of X or Y will end up having more benefits.
Re: Escaping the SPA rabbit hole with modern Rails
#50Earlier 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…
If you use Rails until you can't and then start making a SPA you'll have the common pattern of an application where you never have any idea whether any given thing is built in the Rails templates or in the JS or in some combination of the two.
Is that really a common problem? Can't say I've ever had much trouble remembering what's doing what.
If it really was an issue you could just tell one of the environments to throw a banner up the top of the screen or something in dev mode saying where it's from.