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

We fell out of love with Next.js and back in love with Ruby on Rails

hardcover.app

Post reply on HN
Print view View original

201–210 of 533 posts

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#201

Post by hijp »

sosborn wrote: post #41
hijp wrote: post #33

I think if Rails had focused on giving real first party support to interoperability with whatever frontend framework you brought to the table it would be so much bigger right now. They put a lot of work into Hotwire but I just want to use React, and I'm sure others want to use what they're familiar with.

API only Rails has been a thing for a long time: https://guides.rubyonrails.org/api_app.html Many teams use this with React.

I've built api only. It would be sick if it were easier to sprinkle react/vue/svelte/whatever in your haml views if you only needed a little bit of interaction but didn't want to spin up a whole other frontend.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#202

Post by recursivedoubts »

throwaway7783 wrote: post #53
qudat wrote: post #20

Earlier quoted context omitted.

Having a server provide an island or rendering framework for your site can be more complex than an SPA with static assets and nginx. You still have to deal with all the tooling you are talking about, right? You’ve just moved the goalpost to the BE. And just like the specific use cases you mentioned for client routing I can also argue that many sites don’t care about SEO or first paint so those are non features. So ho…

I have repeated this elsewhere. APIs for UI tend to diverge from APIs in general in practice. For applications that are not highly interactive, you don't quite need a lot of tooling on the BE, and since need to have a BE anyway, a lot of standard tooling is already in there. React style SPAs are useful in some cases, but most apps can live with HTMX style "SPA"s

https://htmx.org/essays/splitting-your-apis/

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#203

Post by dingnuts »

brandensilva wrote: post #165
0cf8612b2e1e wrote: post #64

Earlier quoted context omitted.

I think the DX is significantly better as well with fast reload… As a user, the typical SPA offers a worse experience. Frequent empty pages with progress bars spinning before some small amount of text is rendered.

We have been moving to localized cache stores and there aren't any client side loaders anymore outside of the initial cache generation. Think like Linear, Figma, etc It just depends on what you are after. You can completely drop the backend, apis, and have a real time web socketed sync layer that goes direct to the database. There is a row based permissions layer still here for security but you get the idea. The clie…

>and have a real time web socketed sync layer that goes direct to the database

you might be able to drop a web router but pretending this is "completely drop[ping] the backend" is silly. Something is going to have to manage connections to the DB and you're not -- I seriously hope -- literally going to expose your DB socket to the wider Internet. Presumably you will have load balancing, DB replicas, and that sort of thing, as your scale increases.

This is setting aside just how complex managing a DB is. "completely drop the backend" except the most complicated part of it, sure. Minor details.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#204

Post by throwaway7783 »

whatnow37373 wrote: post #122
throwaway7783 wrote: post #53

Earlier quoted context omitted.

I have repeated this elsewhere. APIs for UI tend to diverge from APIs in general in practice. For applications that are not highly interactive, you don't quite need a lot of tooling on the BE, and since need to have a BE anyway, a lot of standard tooling is already in there. React style SPAs are useful in some cases, but most apps can live with HTMX style "SPA"s

Agreed. We started with one API to rule them all. What happened? Now we got two.. and now we have to communicate like this: “So the backend gave this weird …” “What backend?” “The backend for the frontend…” “So not the backend for the backend for the frontend?” I jest, but only very slightly.

Exactly. And state is in two places now. It's like building two applications and trying to somehow keep them in sync.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#205

Post by demilicious »

princevegeta89 wrote: post #135
catlover76 wrote: post #119

Earlier quoted context omitted.

What would you say the good and bad of GraphQL are? Like, when it is a value-add, and when should it be avoided?

The good news is GraphQL is very quick and easy to pick up and it gives that inbuilt functionality to fetch exactly the amount of data that we need. On top of it, it also has enough flexibility to integrate with your business logic. So it can be a straightforward replacement for a traditional REST API that you would have to manually build. For the disadvantages, I cannot think of any. It is a bit slower than hand rol…

My biggest gripe is losing the entire layer of semantics that HTTP gives you. POST is the only verb and different error states are conveyed via error objects in the returned JSON.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#206

Post by insane_dreamer »

copperx wrote: post #40

Rails is still wonderful. But someone should fork Rails so it ceases to be associated with DHH. CEOs who reveal who they really are become really toxic to the brand. We've seen that happen with Tesla.

I disagree. DHH is opinionated, and a bit arrogant at times, but he's not obnoxious, petty and childish like Musk.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#207

Post by jefozabuss »

int_19h wrote: post #167
zozbot234 wrote: post #73

Earlier quoted context omitted.

> As a user, the typical SPA offers a worse experience. Your typical SPA has loads of pointless roundtrips. SSR has no excess roundtrips by definition, but there's probably ways to build a 'SPA' experience that avoids these too. (E.g. the "HTML swap" approach others mentioned ITT tends to work quite well for that.) The high compute overhead of typical 'vDOM diffing' approaches is also an issue of course, but at least…

My biggest annoyance with SPAs is that they usually break forward/back/history in various subtle (or not so subtle) ways. Yes, I know that this can be made to work properly, in principle. The problem is that it requires effort that most web devs are apparently unwilling to spend. So in practice things are just broken.

I still have some ptsd from payment gateway integrations via iframes about 6-7 years ago. If you thought SPAs are bad by themselves for history tracking imagine those banking iframes randomly adding more entries via inside navigation/redirection that you have to track manually.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#208

Post by veqq »

brandensilva wrote: post #165
0cf8612b2e1e wrote: post #64

Earlier quoted context omitted.

I think the DX is significantly better as well with fast reload… As a user, the typical SPA offers a worse experience. Frequent empty pages with progress bars spinning before some small amount of text is rendered.

We have been moving to localized cache stores and there aren't any client side loaders anymore outside of the initial cache generation. Think like Linear, Figma, etc It just depends on what you are after. You can completely drop the backend, apis, and have a real time web socketed sync layer that goes direct to the database. There is a row based permissions layer still here for security but you get the idea. The clie…

> We have been moving to localized cache stores and there aren't any client side loaders anymore outside of the initial cache generation. Think like Linear, Figma, etc.

That's never the case.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#210

Post by tomnipotent »

actsasbuffoon wrote: post #185
tomnipotent wrote: post #139

Earlier quoted context omitted.

Every SPA I come across, especially when using React, uses persistent state so that in-memory changes are synced to cookie/localStorage/server so they survive refreshes. Every popular state management library even supports this natively. And all of that state combined still requires less memory than any of the images loaded, or the JS bundles themselves.

I absolutely loathe that. State is the source of most bugs. If the page crashes then refreshing it should clear out the state and let me try again. Anecdotally, it seems like I encounter a lot more web apps these days where refreshing doesn’t reset the state, so it’s just broken unless I dig into dev tools and start clearing out additional browser state, or removing params from the URL. Knock it off with all the damn…

I can remember vastly more instances where I've been frustrated as a user of an app or website by losing state, than remember state.
Post reply on HN