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

71–80 of 533 posts

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

#71

Post by spenczar5 »

quantadev wrote: post #15
thembones wrote: post #6

Just my opinion but, server‑side rendering never really went away, but the web is finally remembering why it was the default. First paint and SEO are still better when markup comes from the server, which is why frameworks as different as Rails + Turbo, HTMX, Phoenix LiveView, and React Server Components all make SSR the baseline. Those projects have shown that most dashboards and CRUD apps don’t need a client router,…

I think the confession that "Figma‑ or Gmail‑class apps still benefit from heavy client logic" is a telling one, and the reason I politely disagree with your thinking is that it relies in the app staying small forever. But that's not what happens. Apps grow and grow and grow. I've heard people say they just want "Pure JS" with no frameworks at all because frameworks are too complex, for their [currently] small app. S…

Yeah, wouldn't want to rewrite the frontend in a new framework. Good thing the SPA frameworks are so stable and solid; when I choose one I will surely be able to use it for a good, oh, 3 to 6 months.

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

#72

Post by dan_can_code »

ronbenton wrote: post #66

The whole isomorphic framework trend has always scared the poo out of me. I feel like it's just asking for security issues. For people who commonly use these frameworks -- is it common to have issues where data or code intended only for server execution makes its way onto the client? Or are there good safeguards for this?

Next.js has introduced some keywords such as 'use server' and 'use client' that you enter in the file at the top. Much like 'use strict'. If you attempt to use server code in a client file for example, it will get caught by the ts compiler / Linter.

But for sure the lack of clear lines for where the server ends and the client begins has always been a pain of these kinds of framework offerings.

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

#73

Post by zozbot234 »

0cf8612b2e1e wrote: post #64
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 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 you can pick something like Svelte/Solid JS to do away with that.

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

#74

Post by antfarm »

wordofx wrote: post #47
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.

What’s DHH done?

Maybe parent is referring to DHH's stance on DEI.

https://world.hey.com/dhh/the-waning-days-of-dei-s-dominance...

https://world.hey.com/dhh/dei-is-done-minus-the-mop-up-b3bbb...

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

#75

Post by nine_k »

stavros wrote: post #52
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 disagree, the problem with an SPA is that now you have two places where you manage state (the backend and the frontend). That gives you much more opportunity for the two places to disagree, and now you have bugs.

Unless you can guarantee RTT under 100ms, you have to manage some state on client side, else your UI will feel sluggish.

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

#76

Post by switz »

qudat wrote: post #20
thembones wrote: post #6

Just my opinion but, server‑side rendering never really went away, but the web is finally remembering why it was the default. First paint and SEO are still better when markup comes from the server, which is why frameworks as different as Rails + Turbo, HTMX, Phoenix LiveView, and React Server Components all make SSR the baseline. Those projects have shown that most dashboards and CRUD apps don’t need a client router,…

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…

So here's the kicker: React Server Components don't need a server. They are completely compatible with a static bundle and still provide major benefits should you choose to adopt them (dead code elimination, build-time execution). This is effectively the design of Astro Islands, natively in React Server Components. Letting you write static and client-side dynamic code in a single paradigm through componentization and composition.

If you are curious, my most recent blog post is all about this concept[0] which I wrote because people seem to be misinformed on what RSCs really are. But that post didn't gain any traction here on HN.

Is it more complex? Sure–but it is also more powerful & flexible. It's just a new paradigm, so people are put off by it.

[0] Server Components Give You Optionality https://saewitz.com/server-components-give-you-optionality

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

#77

Post by CooCooCaCha »

quantadev wrote: post #15
thembones wrote: post #6

Just my opinion but, server‑side rendering never really went away, but the web is finally remembering why it was the default. First paint and SEO are still better when markup comes from the server, which is why frameworks as different as Rails + Turbo, HTMX, Phoenix LiveView, and React Server Components all make SSR the baseline. Those projects have shown that most dashboards and CRUD apps don’t need a client router,…

I think the confession that "Figma‑ or Gmail‑class apps still benefit from heavy client logic" is a telling one, and the reason I politely disagree with your thinking is that it relies in the app staying small forever. But that's not what happens. Apps grow and grow and grow. I've heard people say they just want "Pure JS" with no frameworks at all because frameworks are too complex, for their [currently] small app. S…

I’ve been saying this for a long time. It takes very little effort to spin up a react app so there’s little point in starting a project without it or whatever front-end framework you prefer.

As I’ve become more senior I’ve realized that software devs have a tendency to fall for software “best practices” that sound good on paper but they don’t seem to question their practical validity. Separation of concerns, microservices, and pick the best tool for the job are all things I’ve ended up pushing back against.

In this particular case I’d say “pick the best tool for the job” is particularly relevant. Even though this advice is hard to argue against, I think it has a tendency to take developers down the path of unnecessary complexity. Pragmatically it’s usually best to pick a single tool that works decently well for 95% of your use cases instead of a bunch of different tools.

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

#78

Post by stavros »

procaryote wrote: post #70
stavros wrote: post #52

Earlier quoted context omitted.

I disagree, the problem with an SPA is that now you have two places where you manage state (the backend and the frontend). That gives you much more opportunity for the two places to disagree, and now you have bugs.

You had to manage state on the frontend even before spa though, if you wanted anything but the most basic experience.

Not between page loads.

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

#79

Post by CooCooCaCha »

spenczar5 wrote: post #71
quantadev wrote: post #15

Earlier quoted context omitted.

I think the confession that "Figma‑ or Gmail‑class apps still benefit from heavy client logic" is a telling one, and the reason I politely disagree with your thinking is that it relies in the app staying small forever. But that's not what happens. Apps grow and grow and grow. I've heard people say they just want "Pure JS" with no frameworks at all because frameworks are too complex, for their [currently] small app. S…

Yeah, wouldn't want to rewrite the frontend in a new framework. Good thing the SPA frameworks are so stable and solid; when I choose one I will surely be able to use it for a good, oh, 3 to 6 months.

This feels sarcastic but in reality ever since react switch to using hooks I’ve largely written the same style of react code for years. You don’t have to live on the edge.
Post reply on HN