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

121–130 of 533 posts

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

#121

Post by welder »

Just eww... you were an expert at Rails 10+ years, failed to become an equivalent expert at Next.js so you went back to what you're used to. You just didn't dive in deep enough.

I was the same expert level with Python, now I'm using trpc, nextjs, drizzle, wakaq-ts, hosted on DO App Platform and you couldn't pay me enough to go back to Python, let alone the shitstorm mess that's every Rails app I've ever worked on.

I've also not seen the 1s Next.js pageloads you had, but I'm confident of figuring a fix if that becomes a problem.

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

#122

Post by whatnow37373 »

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

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.

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

#123

Post by omneity »

thunky wrote: post #106
omneity wrote: post #7

Earlier quoted context omitted.

What makes Rails stand out is the focus on convention-over-configuration as a guiding principle in the ecosystem which results in a lot less code (have you seen these relatively thin models and controllers?), as well as established dependencies and the lack of tendency to bikeshed in libraries (geocoder or devise for example have been mostly stable over close to a decade, with few popping up to replace it)

> What makes Rails stand out is the focus on convention-over-configuration as a guiding principle in the ecosystem which results in a lot less code Convention over configuration and less code is fine, but unfortunately Rails is not a great example of it IMO. The "rails" are not strong enough; it's just too loosey goosey and it doesn't give you much confidence that you're doing it "the right way". The docs don't help…

Do you have a recommendation for a better incarnation of the principle?

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

#124

Post by pier25 »

dmix wrote: post #104
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…

The obsession with DX tooling is exactly why JS is such an awful developer experience. They always chase something slightly better and constantly change things. Maybe the answer was never in JS eating the entire frontend, and changing the tooling won’t make it better, as it’s always skirting what’s actually good for the web.

> The obsession with DX tooling is exactly why JS is such an awful developer experience.

I used to agree but these days with Vite things are a lot smoother. To the point that I wouldn't want to work on UI without fine-grained hot reloads.

Even with auto reload in PHP, .NET, etc you will be wasting so much time. Especially if you're working on something that requires interaction with the page that you will be repeating over and over again.

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

#125

Post by tomnipotent »

bckr wrote: post #98

I keep hearing good things about Rails. What are the downsides, other than learning a new language and framework?

You have to be comfortable with the ORM in every layer - it lives inside your domain models, rather than in another layer shuffling DTO's to presentation/rendering. It also makes it easy to avoid separation of concerns and stuff all your logic in a controller method and call it a day.

The upsides is that by not trying to hide the database and pretend it doesn't exist you can avoid a whole class of work (and the safety abstractions provided) and be incredibly productive if the requirements align.

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

#126

Post by stavros »

tomnipotent wrote: post #109
stavros wrote: post #78

Earlier quoted context omitted.

Not between page loads.

You absolutely did. It was common practice to stuff things in cookies or query strings to retain state between trips to the server so that some JS could do its job. Every form also normally ends up duplicating validation logic both in JS for client-side pre-submit UX and server-side with whatever errors it returns for the JS to then also need to support and show to the user.

Right, but validation logic and state transferred by the server isn't in-memory state. The fact that the pages completely reload on each request clears a lot of cruft that doesn't get cleared on pages whose lifetime is tens or hundreds of views.

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

#127

Post by IshKebab »

bckr wrote: post #98

I keep hearing good things about Rails. What are the downsides, other than learning a new language and framework?

You have to program it using Ruby which is not a good language. It's slow. It doesn't have good static type annotations (as far as I can tell the community "gets it" even less than in Python).

Rails also uses way too much magic to dynamically construct identifiers and do control flow.

The over-use of magic and the under-use of static types makes it extraordinarily difficult to navigate Rails codebases. It's one of those things where you have to understand the entire codebase to be able to find anything. Tractable for tiny projects. For large projects it's a disaster.

Rails is a bad choice (as is Ruby).

My favourite web framework at the moment is Deno's Fresh. You get the pleasure of TSX but it's based around easy SSR rather than complex state management and hooks. Plus because it's Deno it's trivial to set up.

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

#128

Post by boomskats »

zozbot234 wrote: post #73
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.

> 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…

> Your typical SPA has loads of pointless roundtrips

This is an implementation choice/issue, not an SPA characteristic.

> there's probably ways to build a 'SPA' experience that avoids these too

PWAs/service workers with properly configured caching strategies can offer a better experience than SSR (again, when implemented properly).

> The high compute overhead...

I prefer to do state management/reconciliation on the client whenever it makes sense. It makes apps cheaper to host and can provide a better UX, especially on mobile.

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

#129

Post by qq99 »

If you're thinking about going back to SSR, I think you owe it to yourself to check out Phoenix LiveView (Elixir) and play with it for an afternoon.

I've built a few apps in it now, and to me, it starts to feel a bit like server-side React (in a way). All your HTML/components stream across to the user in reaction to their actions, so the pages are often very light.

Another really big bonus is that a substantial portion of the extras you'd typically run (Sidekiq, etc) can basically just be baked into the same app. It also makes it dead simple to write resilient async code.

It's not perfect, but I think it's better than RoR

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

#130

Post by pier25 »

austin-cheney wrote: post #27

When I see articles and discussions about web + stack I can’t but ask “What problem are they actually solving” ? The answer is always: put text on screen . When your business goal is put text on screen the next logical step is to ask how much time and money does the tech stack really save? I have never found a developer that answer that question with a number. That’s a really big problem.

> The answer is always: put text on screen.

I wonder how you'll handle image uploading, drag and drop, media players, etc with simple static content rendering.

Post reply on HN