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

241–250 of 533 posts

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

#241

Post by sensanaty »

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.

Are people on this site just stuck in the 90s or something? The product I work on is nowhere near Figma or Google Docs level of complexity, but we're still MILES away from "just rendering text on screen".

That's about as absurd a statement as saying all of Backend is just "returning names matching a certain ID" for how out of date and out of touch it is.

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

#242

Post by brightball »

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 honestly feels so much closer to the old jQuery approach of using JS for enhancements but ensuring you could gracefully degrade to work without it.

I loved building things that way.

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

#243

Post by jimbob45 »

dmix wrote: post #104
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…

The obsession with DX tooling is exactly why JS is such an awful developer experience. They always chase something slightly better and constantly change things. Maybe the answer was never in JS eating the entire frontend, and changing the tooling won’t make it better, as it’s always skirting what’s actually good for the web.

There’s just no way for the abominations that are HTML, JS, and CSS to be used in an accessible and maintainable way. It’s absurd that we haven’t moved on to better technologies in the browser or at least enabled alternatives (I weep for Silverlight).

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

#244

Post by morsecodist »

I feel like the elephant in the room here is that their back end was in RoR before Next.js and remained that way the entire time. They then switched from next.js to a framework designed, in part, with RoR in mind. It seems unsurprising that they had a much better experience using a thing that was tailored to their use case.

I love Next.js. I have used other frameworks including RoR and there is nothing like it (except Svelte or Nuxt but I view them as different flavors of the same core idea). But I only use it to make monoliths. I can see getting frustrated with it if I was using it alongside a different back end.

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

#245

Post by SkepticalWhale »

actsasbuffoon wrote: post #185
tomnipotent wrote: post #139

Earlier quoted context omitted.

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.

I absolutely loathe that. State is the source of most bugs. If the page crashes then refreshing it should clear out the state and let me try again. 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…

Minimizing state simplifies the codebase but it’s a trade off.

There are times the user experience is just objectively better with more state, and you have to weigh the costs.

If I am filling out a very long form (or even multi-page form) I don’t really want all that state lost if I accidentally refresh the page.

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

#246

Post by quantadev »

sensanaty wrote: post #234
spenczar5 wrote: post #71

Earlier quoted context omitted.

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…

I agree. My preference is React, but I've got 4 years of Vue experience and so I know Vue is good too, and mature. There are just some people who are anti-framework entirely, and they're never actual professional web developers, but mostly hobbyists or college dabblers, who've never been involved with a large project, or else they'd know how silly their anti-framework attitude is.

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

#247

Post by morsecodist »

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.

What kind of answer would you expect to a question like that? I couldn't tell you how much time and money I save writing in a programming language instead of raw machine code but I can rest assured that it's the right call.

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

#248

Post by freeone3000 »

SJC_Hacker wrote: post #120
freeone3000 wrote: post #29

Earlier quoted context omitted.

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

You haven’t had to deal directly with JS on front end since Dart released over 10 years ago

Dart hasn’t been much better in my experience, but you have reminded me to revisit Kotlin/JS!

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

#249

Post by waprin »

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

Earlier quoted context omitted.

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 ?

Expo is the most popular React Native framework and markets remote updates as a feature and highlights that it lets you skip App Review update and Apple hasn't stopped them (Expo updates not exactly server-side mobile UI but it's similar idea).

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

#250

Post by quantadev »

lazypenguin wrote: post #19
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…

That’s absurd, that’s like saying we should only use C++ for backend code because my CRUD business app might one day scale to infinity. Better be safe than sorry and sling pointers and CMake just in case I need that extra juice!

imo, even if the only "interactivity" a web app has is just a login page, then even that alone is enough to warrant using a framework rather than doing direct DOM manipulation (or even worse, full page refreshes after a form submit).

It's not about using the most powerful tool always, it's about knowing how to leverage modern standards rather than reinventing and solving problems that are already solved.

Post reply on HN