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

341–350 of 533 posts

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

#341

Post by Zanfa »

mountainriver wrote: post #187
_mlbt wrote: post #9

Earlier quoted context omitted.

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…

Hard disagree on this. I went with this sentiment and deeply regret it. With LLM assisted coding it's very fast and easy to write a Go or even a Rust server. They have less bugs and can actually do things like threads that you end up working around in python/ruby.

Giving an existing Rails codebase to an LLM and effectively asking it to rewrite it in Go is going to result in a shitstorm of epic proportions.

At least it’ll make for an interesting post mortem blog post.

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

#342

Post by cpursley »

travisgriggs wrote: post #294
cpursley wrote: post #101

Earlier quoted context omitted.

Languages with stronger types like typescript (unfortunately) perform much better than dynamic languages like Ruby, Elixir or even plain JS in an AI editor world. Because the editors are type smart and you can quickly pop the type error into the AI chat and it will attempt to correct it. The feedback cycle is just insane. I really hate to say it, but Typescript has won.

Have you seen any studies that validate this? I feel this would be the case, but I can’t say I’ve actually seen it work out. Cursor writes better Elixir code for me than it does Kotlin, or at least it anecdotally seems so. I find it confusing. I remember many years ago an akin experience, talking to John Brant and Don Roberts who had done the original refactoring browser in Smalltalk. Java was on its meteoric rise wi…

No studies other than some serious experimentation on my own. I’m a strong Elixir dev but Cursor and friends are just more productive with Typescript due to the editor type checking cycle and training. Thought Jośe is working on a new MCP project to help: https://github.com/tidewave-ai/tidewave_phoenix

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

#343

Post by Zanfa »

_mlbt wrote: post #9
mountainriver wrote: post #5

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

If Shopify or Github can handle scale with Rails, maybe it’s not a framework problem.

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

#344

Post by welder »

mattgreenrocks wrote: post #170
madethemcry wrote: post #103

I truly wonder what people do when they want JS full stack both frontend an backend especially with a DB involved. ORM situation looks pretty fragmented or you write pure sql. And then you still have to decide on the backend. Going raw with express? Next.js, well known, but with a questionable agenda (, Remix, Astro, TanStack, and so on. It's a mess, because you always have to recalibrate and re-evaluate what to use.…

Yep. The ORM situation in JS is not great. There’s no one go-to, and it seems like the question often prompts a patronizing response about how ORMs aren't really necessary. Kysely is really great, but it’s not an ORM. My take: the JS ecosystem tends to avoid abstraction for whatever reason. Example: they don’t believe that their web framework should transparently validate that the form submission has the correct shap…

The go-to is Drizzle

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

#345

Post by welder »

esperent wrote: post #261
mattgreenrocks wrote: post #170

Earlier quoted context omitted.

Yep. The ORM situation in JS is not great. There’s no one go-to, and it seems like the question often prompts a patronizing response about how ORMs aren't really necessary. Kysely is really great, but it’s not an ORM. My take: the JS ecosystem tends to avoid abstraction for whatever reason. Example: they don’t believe that their web framework should transparently validate that the form submission has the correct shap…

> There’s no one go-to I thought Prisma.js was the most popular by far? It's the one I've always seen used in docs and examples.

Not anymore, now it's Drizzle

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

#346

Post by pmdr »

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.

The problem is CEO worship. You should worship Rails, not DHH. It's okay that he sometimes has other opinions, we don't have to agree with them to benefit from Rails. And there are a couple of things differentiating him from Musk: first, Rails is a byproduct of his business, not his business. 37Signals isn't even shilling some cloud service like Vercel is with NextJS. Second, DHH isn't involved in government.

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

#347

Post by arrowsmith »

vishalontheline wrote: post #286
freedomben wrote: post #140

Earlier quoted context omitted.

We currently have two major apps, One in typescript and one in rails. I have to hire devs for both, and I have not experienced it being any more difficult to find a rails developer or a node/typescript developer. If anything, I think finding a rails developer with relevant experience is even easier because the stack is so much more standardized. With people with node experience, there is a huge chance that they won't…

I really hope that Elixir / Phoenix will gain more traction. It is very easy to write a server with it, hosting and deploying is painless, upgrading it (so far) has been painless, linting and debugging has been a breeze. If you're coming from Ruby, then learning Elixir requires a small mental adjustment (from Object Oriented to Functional). Once you get over that hump, programming in Elixir is just as much fun as Rub…

And if you're coming from Rails you can start here ;)

https://phoenixonrails.com/

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

#349

Post by homebrewer »

wordofx wrote: post #281
lmm wrote: post #157

Earlier quoted context omitted.

Every webapp built with something other than GraphQL ends up with an ad hoc, informally-specified, bug-ridden, slow implementation of half of GraphQL. Yes, a book tracking app absolutely needs GraphQL. Do you need a separate frontend framework? No, probably not, and that's exactly the problem that Next solves - write your backend and frontend in the same place. Do you need a complicated build process? No. You want yo…

GraphQL is the new mongodb. This fancy new thing that people want to use and makes no sense in reality and just causes more problems than it solves. It solves a very specific problem that makes sense at Facebook. It makes 0 sense for companies that have a web app or web and mobile app. And nothing else. Anyone deciding to use graphql is making a dumb decision.

I sometimes have to write integrations with external data providers (most of them being government agencies), and they love graphql, where (IMHO) it makes a lot of sense. They provide data about some entity¹ split into X fields, your application needs maybe 20% of them, and thanks to graphql you don't have to request anything but those 20%. When loading hundreds of millions of records, it saves you from loading, parsing, and then throwing away gigabytes of unnecessary JSON.

1: one example being tax records with all associated information about tax collecting agencies and taxpayers — it's a lot of data

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

#350

Post by ksec »

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

>Figma‑ or Gmail‑class apps.....

Figma is a definite yes. But Gmail is something we say from late 00s and somehow continue till now. I thought it has been proven we dont need SPA for Email Client. Hey is perfectly fine other than a little slow, mostly due to server response time and not Turbo / HTML / HTMX itself.

I still believe we have a long way to go and innovate on partial HTML swaps. We could have push this to the limit so that 98% of the web doesn't need SPA at all.

Really hopes Rails has more in store this year.

Post reply on HN