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

321–330 of 533 posts

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

#321

Post by fulafel »

lmm wrote: post #157
3sbi wrote: post #112

I remember reading their blog post about how moving from pages router to app router in Next.js helped their SEO last year. This time they are moving from Next to React+Inertia.js because of growing bills from Vercel even though deploying the same app on your own VPS instead of relying on cloud provider would probably solve the issue. Nonetheless, I still don't understand their yearn for complexity - does book trackin…

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…

Greenspun's rule worked in favour of Common Lisp (to the extent that it did...) because CL solves a lot of hard problems that ad-hoc solutions do poorly, like automatic memory management, DSLs, etc.

But lots of apps can do with a lightweight pull API that can be tailored, fits the applications' access control model (as points of contrast to GraphQL) and it's less work and less risk than finding, integrating and betting on a GraphQL implementation.

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

#322

Post by Zanfa »

pier25 wrote: post #293
jdsleppy wrote: post #219

Earlier quoted context omitted.

HTMX has a very nice drag and drop extension I just found, though. And old-school forms can include image files. The little image preview can be a tiny "island of JS" if you have to have it.

> The little image preview can be a tiny "island of JS" if you have to have it. I would consider that the bare acceptable minimum along an upload progress indicator. But it can get a lot more complicated. What if you need to upload multiple images? What if you need to sort the images, add tags, etc? See for example the image uploading experience of sites like Unsplash or Flickr. HTMX just ism't the right tool to solv…

None of what you described requires anything more than an isolated island with some extra JS. No need for complex client-side state, no need for a SPA framework, no bundling required, not even TypeScript. If you relied on DOM and a couple of hidden fields, 90% of this would be a few dozen lines of code plus some JSDoc for type safety.

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

#323

Post by lmm »

realusername wrote: post #237
lmm wrote: post #231

Earlier quoted context omitted.

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.

Shrug. Your tracing tools need to understand your transport protocol (or you need to instrument all your endpoints), sure, but that's always been the case. Likewise with security. IME the stuff that's available for GraphQL isn't any worse than what's available for raw HTTPS and is often better since you have more information available (e.g. if you want to redact a particular object field from all your responses depending on the caller's authorisation, it's much easier to do that in GraphQL where that field only exists in one place than in a bunch of handwritten endpoints where you have to find every response that field might appear in).

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

#324

Post by fvdessen »

lmm wrote: post #230
Diggsey wrote: post #212

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. Not remotely true. There are plenty of web apps that work just fine with a standard fixed set of API endpoints with minimal if any customization of responses. Not to mention the web apps that don't have any client-side logic at all... GraphQL solves a problem that do…

> With most web apps having their front-end and back-end developed in concert, there's simply no need for this flexibility But also no problem with it. There might be some queries expressible in your GraphQL that would have severe performance problems or even bugs, sure, but if your frontend doesn't actually make queries like that, who cares? > Just have the backend provide the APIs that the front-end actually needs.…

> There might be some queries expressible in your GraphQL that would have severe performance problems or even bugs, sure, but if your frontend doesn't actually make queries like that, who cares?

People with bad intentions can make those slow queries happen at high volume with custom tooling, they don’t have to restrict themselves to how the frontend uses the queries

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

#325

Post by balencpp »

const_cast wrote: post #195
procaryote wrote: post #70

Earlier quoted context omitted.

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

No you really don’t. I’ve worked on exceptionally complex legacy applications with essentially no state in the front end. At most, you’re looking at query parameters. You just make everything a full page reload and you’re good to go.

So you make incrementing a counter a full page reload?

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

#326

Post by ivan_gammel »

jjani wrote: post #301
petre wrote: post #290

Earlier quoted context omitted.

Except you can't really build PWAs with those technologies and most web content is now consumed on mobile. I used to do it like that as well, but clients want a mobile app and management decided to give them a PWA, because then we could use the existing backend (Perl, Mojolicious, SQL). I now agree with them if it keeps the lights on.

> I used to do it like that as well, but clients want a mobile app and management decided to give them a PWA I'm quite surprised to hear this is a common thing. Besides myself, I don't know a single person who has ever installed a PWA. For people in tech, despite knowing they exist. For people outside tech, they don't know they exist in the first place. Does management actually have any PWAs installed themselves?

People outside tech just get installation instructions and do not care if it’s app store or something else. This is how sanctioned Russian banks continue to serve their customers via apps, when they cannot get into app store. The number of users of PWA is probably on the scale of millions.

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

#327

Post by jjani »

petre wrote: post #316
pjmlp wrote: post #307

Earlier quoted context omitted.

For me the whole worker setup filtering requests and storing results on local storage, looks like gimmicks. They should have designed it as a proper native experience.

They don't want to be subject to app store approval policies, shitty TOS, nor pay Google or Apple a 30% cut. Installing the app is easy, visit the web site, clck the install banner, add to home screen and you're good to go. On the developer side you get to deploy as iften as needed. Yes, the service worker thing is annoying but you possibly don't need it if you have a server backend. It's basically a glirified websit…

> They don't want to be subject to app store approval policies, shitty TOS, nor pay Google or Apple a 30% cut. Installing the app is easy, visit the web site, clck the install banner, add to home screen and you're good to go. On the developer side you get to deploy as iften as needed.

And the metrics are saying that people click it?

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

#328

Post by jjani »

ivan_gammel wrote: post #326
jjani wrote: post #301

Earlier quoted context omitted.

> I used to do it like that as well, but clients want a mobile app and management decided to give them a PWA I'm quite surprised to hear this is a common thing. Besides myself, I don't know a single person who has ever installed a PWA. For people in tech, despite knowing they exist. For people outside tech, they don't know they exist in the first place. Does management actually have any PWAs installed themselves?

People outside tech just get installation instructions and do not care if it’s app store or something else. This is how sanctioned Russian banks continue to serve their customers via apps, when they cannot get into app store. The number of users of PWA is probably on the scale of millions.

I had no idea! Cool to learn.

It definitely makes complete sense in that scenario, but remains a very niche usecase where people have no other option.

>People outside tech just get installation instructions

People outside of tech don't need instructions to install non-PWA, store apps. So all this does to me is reinforce that no one is installing PWAs outside of niche scenarios where 1. people basically have to use the app due to a connection to a physical institution 2. they are explicitly told how to do it 3. the app is not available on the stores for legal reasons.

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

#329

Post by int_19h »

creakingstairs wrote: post #282
int_19h wrote: post #274

Earlier quoted context omitted.

Thing is, the browser back button is still there, though. So now you have two identical buttons that do different things. And that's really bad UX.

I’m split on this. I used to agree with you but when I talked to internal users and customers, they really liked having a back button in the app. I would tell them the browser back button is there and we haven’t broken history so it should work to which they just often shrug and say they “just” prefer it. My hypothesis is that they’ve had to deal with so many random web apps breaking the back button so that behaviour…

It's okay if both buttons do the same thing. But OP (if I understood them correctly) proposed the in-app Back button as a hacky solution to the problem of browser one being broken, which kinda implies that they don't behave the same.

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

#330

Post by lmm »

fvdessen wrote: post #324
lmm wrote: post #230

Earlier quoted context omitted.

> With most web apps having their front-end and back-end developed in concert, there's simply no need for this flexibility But also no problem with it. There might be some queries expressible in your GraphQL that would have severe performance problems or even bugs, sure, but if your frontend doesn't actually make queries like that, who cares? > Just have the backend provide the APIs that the front-end actually needs.…

> There might be some queries expressible in your GraphQL that would have severe performance problems or even bugs, sure, but if your frontend doesn't actually make queries like that, who cares? People with bad intentions can make those slow queries happen at high volume with custom tooling, they don’t have to restrict themselves to how the frontend uses the queries

> People with bad intentions can make those slow queries happen at high volume with custom tooling, they don’t have to restrict themselves to how the frontend uses the queries

Depends how your system is set up. I'm used to only allowing compiled queries on production instances, in which case attackers have no way of running a different query that you don't actually use.

Post reply on HN