Earlier quoted context omitted.
>Websites. Wait, is SSR a thing outside the context of websites?
There was a time when SSR was the only option. All early web apps were SSR. It gets rather painful though, which is why we don't do that anymore.
We fell out of love with Next.js and back in love with Ruby on Rails
181–190 of 533 posts
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#182Rail is probably one of the most intuitive framework that I have ever used. No doubt it is highly opinionated but it hides all the complexity for small to medium applications.
It’s funny how some claim it’s intuitive while others complain about its magical nature.
I wish I got along better with Rails, honestly.
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#183Earlier quoted context omitted.
What’s DHH done?
He became very unpopular for his no politics at work stance at the time, but it seems to have ultimately been the right call in the long run. The toxic individuals left and 37signals is stronger than ever.
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#184The problem with Next.js, is they over-engineered the whole things for no purpose. But i also think it's related to limitation of technical teams. "Simplicity is achieved when there's nothing left to remove".
That’s funny, after using it on a couple projects I felt that it was under-engineered/lacked some basic things I was used to having in other frameworks.
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#185Earlier quoted context omitted.
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.
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.
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 state! Did we forget the most important lesson of functional programming; that state is the root of all evil?
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#186I keep hearing good things about Rails. What are the downsides, other than learning a new language and framework?
If you "screw up and succeed" by gaining many users/customers, any Ruby or Python framework provides orders of magnitude fewer requests-per-second on the same VM or hardware than a comparable solution deployed with node.js, go, Java, C# (Including DotNet Core on Linux), or rust. And this will quickly ballon your cloud compute costs to keep up.
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#187I’ve written a bit of rails and still don’t really get what the raving is about. It was perfectly fine, I didn’t find anything extra special about it. Having just hit severe scaling issues with a python service I’m inclined to only write my servers in Go or Rust anymore. It’s only a bit harder and you get something that can grow with you
The prevailing sentiment is that once you hit scaling issues with frameworks like Rails or Django you should have enough resources to simply throw money at the problem either in the form of more hardware, cloud computing, or better software engineers that can identify bottlenecks and optimize them. Since most websites will never scale past the limitations of these frameworks, the productivity gains usually make this…
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#188Just 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,…
This is ChatGPT
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#189Re: We fell out of love with Next.js and back in love with Ruby on Rails
#190I 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.
SEO. I run skatevideosite.com and accidentally did the first rewrite when I took it over in react because that’s all I knew. I absolutely tanked the seo. Rewrote it in rails and got everything back in shape and it’s been a fun experience!