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

231–240 of 533 posts

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

#231

Post by lmm »

realusername wrote: post #225
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…

Maybe I'm biased but I don't see any scenario where GraphQL ever makes sense, the complexity is never worth it. You throw away all the debuggability and simplicity of rest for close to zero advantages

How so? You've got all the same debuggability that you'd have with rest - sure you need to look at your requests and responses through your tools rather than directly, but that was already the case unless you're not using HTTPS (which is a bigger problem). Throw up GraphiQL on one of your developer/admin pages and you've got easier exploratory querying than you could ever get with an old-style Rest API.

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

#232

Post by cultofmetatron »

tmnvix wrote: post #159
qq99 wrote: post #129

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

I've been curious for a while now. One thing that gives me pause though is how Phoenix LiveView apps perform when you're dealing with high latency. I'm aware that many apps will be serving primarily the US market and so might not recognise this as much of an issue. I'm also aware that I could deploy 'at the edge' with something like fly.io. Still, when I run a ping test to 100 different locations around the world fro…

while its true that phoenix liveview's default is to have all state be on the server, there are hooks to run javascript behavior on the frontend for things like optimistic updates and transitions. This gives plenty of ways to make the frontend feel responsive even when the roundtrip is 300+.

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

#233

Post by waprin »

torben-friis wrote: post #228
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,…

This is not my field, but my mental model was that server side mostly died when mobile apps started being mainstream, and treating the web app as another frontend for your common api was considered the best way to handle client diversity. Was this not the case? And if so, what has fundamentally changed?

It's one of those things that's like "write one HTML file with zero styling, then you can have multiple different CSS files style the same content completely differently! Separation of Concern!" Sounds perfect in theory but just doesn't always work.

Having one API for web and mobile sounds good but in practice often the different apps have different concerns.

And SEO and page speed were always reasons the server never died.

In fact, the trend is the opposite direction - the server sending the mobile apps their UIs. That way you can roll out new updates, features, and experiments without even deploying a new version.

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

#234

Post by sensanaty »

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.

We still have Vue 2 apps running strong. Our experimental stuff is on Vue 3, which is backwards compatible with Vue 2 for the most part if you avoided mixins (which even in the Vue 2 days was the common advice).

People who say stuff like this have obviously never actually used modern day FE frameworks, because they have all been very stable for a long while. Yes, APIs change, but that's not unique to JS/frontend, and also nothing really forces you to update with them unless you really need some shiny new feature, and at least IME Vue 3 has been nothing but gold since we got on it.

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

#235

Post by CuriouslyC »

baq wrote: post #133
sroussey wrote: post #62

Earlier quoted context omitted.

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

If your axiom is ‘JS is fine’ then yeah. It isn’t, though. TS is much closer to ‘fine’, but still can’t avoid some dumb JS decisions.

I've been a professional programmer for ~20 years and worked in a variety of languages on a variety of different types of projects, and Typescript with Bun is mostly just fine. It lacks some low level primitives I'd like to have available for certain projects (e.g. Go channels), and the FFI interface isn't as nice as I'd like, but it's basically serviceable for for a very broad range of problems.

You should still know a language like Rust or Zig for systems work, and if you want to work in ML or data management you probably can't escape Python, but Typescript with Bun provides a really compelling development experience for most stuff outside that.

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

#236

Post by chao- »

freedomben wrote: post #140
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.…

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…

>If anything, I think finding a rails developer with relevant experience is even easier because the stack is so much more standardized.

This has been my experience.

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

#237

Post by realusername »

lmm wrote: post #231
realusername wrote: post #225

Earlier quoted context omitted.

Maybe I'm biased but I don't see any scenario where GraphQL ever makes sense, the complexity is never worth it. You throw away all the debuggability and simplicity of rest for close to zero advantages

How so? You've got all the same debuggability that you'd have with rest - sure you need to look at your requests and responses through your tools rather than directly, but that was already the case unless you're not using HTTPS (which is a bigger problem). Throw up GraphiQL on one of your developer/admin pages and you've got easier exploratory querying than you could ever get with an old-style Rest API.

Simple questions like "which teams own the slowest endpoints" suddenly become a nightmare to compute with GraphQL. There's a reason why every industry moved to division of labor.

Then the security looks also annoying to manage, yeah sure the front-end can do whatever it wants but nobody ever wanted that.

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

#238

Post by cjonas »

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…

> You still have to deal with all the tooling you are talking about, right? You’ve just moved the goalpost to the BE

This. From a security perspective, server side dependencies are way more dangerous than client side.

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

#239

Post by int_19h »

ezekiel68 wrote: post #181
int_19h wrote: post #174

Earlier quoted context omitted.

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.

What is the specific pain? Are you just referring to dynamic content on the client in general or different issues?

The oldest web apps - web email clients being probably the canonical and most familiar example - didn't do dynamic refresh at all, because there was no way to fetch data from the server, so you couldn't do it even with JS. Any user action that required any part of the page to be updated involved a (very visible) whole page refresh. You could limit the scope of refresh with frames to some extent, but it was still very noticeable.

Microsoft introduced XMLHttpRequest in 2000 for this exact reason - its original purpose was to allow the newly introduced Outlook web UI to fetch data from the server and use that to update the DOM as needed. This was then enthusiastically adopted by other web app authors (most notably Google, with GMail, Google Maps, and Google Talk), and other browsers jumped onto the bandwagon by providing their own largely compatible implementations. By 2006 it was a de facto standard, and by 2008 it was standardized by W3C.

The pattern was then known as AJAX, for "asynchronous JS and XML". At first web apps would use the browser API directly, but jQuery appeared right around that time to provide a consistent API across various browsers, and the first SPA frameworks showed up shortly after (I'm not sure if I remember correctly, but I think GWT was the first in 2006).

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

#240

Post by torben-friis »

waprin wrote: post #233
torben-friis wrote: post #228

Earlier quoted context omitted.

This is not my field, but my mental model was that server side mostly died when mobile apps started being mainstream, and treating the web app as another frontend for your common api was considered the best way to handle client diversity. Was this not the case? And if so, what has fundamentally changed?

It's one of those things that's like "write one HTML file with zero styling, then you can have multiple different CSS files style the same content completely differently! Separation of Concern!" Sounds perfect in theory but just doesn't always work. Having one API for web and mobile sounds good but in practice often the different apps have different concerns. And SEO and page speed were always reasons the server neve…

>In fact, the trend is the opposite direction - the server sending the mobile apps their UIs. That way you can roll out new updates, features, and experiments without even deploying a new version

Is that allowed by app stores? Doesn’t it negate the walled gardens if you can effectively treat the app as a mini browser that executes arbitrary code ?

Post reply on HN