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

61–70 of 533 posts

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

#61

Post by omneity »

joshstrange wrote: post #21

I'm thankful that I don't work on projects that have SEO needs. SSG (for JS frameworks specifically) feels too unstable for me. I get the value, I understand why people need to do it, but it just makes everything more complicated. Also, I'm not sure if you can have an offline site with SSG? They might be compatible but I'm not sure. I know some SSG is essentially "SPA with the first page rendered already" so maybe th…

Tangential but I noticed a certain common conflation between pre-rendering and server-side rendering. Very often plain SSR is all it takes for good SEO performance, SSR in this case simply being rendering the page on-demand before serving it to the user.

Pre-rendering (as popularized by static site generators) is the additional step that increases complexity significantly, sometimes security issues too when session-protected cached pages are mistakenly served to the wrong users.

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

#62

Post by sroussey »

freeone3000 wrote: post #29
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…

But on the flip side, you can program the backend in anything you like, instead of being bound to javascript.

JS/TS is fine. Why switch back and forth between languages and frameworks and data models and…

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

#63

Post by __abc »

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…

If you truly need for MVC to manage all things state, component communications, and complex IxD in the front-end, sure, but not every app has that level of front-end complexity to warrant a SPA, in my opinion.

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

#64

Post by 0cf8612b2e1e »

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…

  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.

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

#66

Post by ronbenton »

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?

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

#67

Post by stavros »

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.

If you reduce things so much that all detail is lost, you can't really reason about the original thing any more. The obvious counterpoint here is, you try turning amazon.com into a plain TXT file and see how much sales increase.

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

#68

Post by dismalaf »

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.

Rails can be API only and use any frontend you want.

Hotwire is the default and they develop it because DHH wants to, but they're not putting up any barriers to you using whatever you want.

Also, DHH doesn't seem to care about how big it is. His stated goal is for it to forever be a framework that's usable by a single dev.

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

#69

Post by moralestapia »

grey-area wrote: post #45
moralestapia wrote: post #30

I never really got the appeal of SSR, and I've implemented it a cuouple times with Next.JS and things like htmx. Can anyone come up with the ideal use case where SSR shines? I'm willing to buy it if I see it.

Websites. Most websites are significantly simpler to build and maintain with SSR and traditional tools. An entire generation has forgotten this it seems and still thinks in terms of JS frameworks even when trying SSR. As one example take this website, which serves the page your wrote your comment on using an obscure lisp dialect and SSR.

>Websites.

Wait, is SSR a thing outside the context of websites?

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

#70

Post by procaryote »

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.

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