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

311–320 of 533 posts

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

#311

Post by DangitBobby »

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.

Yes it's pretty good though it falls short of my golden standard (Django) by missing good automatic migrations and transactions in migrations.

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

#312

Post by grey-area »

WuxiFingerHold wrote: post #288
0cf8612b2e1e wrote: post #64

Earlier quoted context omitted.

I think the DX is significantly better as well with fast reload… As a user, the typical SPA offers a worse experience. Frequent empty pages with progress bars spinning before some small amount of text is rendered.

There's no way around waiting for the data to arrive. Being it JSON for SPA or another page for MPA / SSR. For MPA the browser provides the loading spinner. Some SPA router implementations stay on the current page and route to the new one only after all the data has arrived (e.g. Sveltekit).

With SSR all the data usually arrives in 100-200ms, in SPAs all the data tends to take seconds to arrive on first load so they resort to spinners, loading bars etc.

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

#313

Post by Bombthecat »

princevegeta89 wrote: post #135
catlover76 wrote: post #119

Earlier quoted context omitted.

What would you say the good and bad of GraphQL are? Like, when it is a value-add, and when should it be avoided?

The good news is GraphQL is very quick and easy to pick up and it gives that inbuilt functionality to fetch exactly the amount of data that we need. On top of it, it also has enough flexibility to integrate with your business logic. So it can be a straightforward replacement for a traditional REST API that you would have to manually build. For the disadvantages, I cannot think of any. It is a bit slower than hand rol…

The biggest issue is security. More often then not, the API allows you to see more than you should.

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

#314

Post by sgustard »

noodlesUK wrote: post #25
vinnymac wrote: post #16

Earlier quoted context omitted.

I believe allowing the dynamic loading of scripts was a mistake, and we should undo support for it. So were iframes. Everything after ready should have been static content.

I completely agree with the sentiment that we don’t need SPAs and similar tech for news sites and dashboards and the myriad crud apps we use on a day to day basis but I think what you’re proposing is throwing the baby out with the bath water. How would a site like google maps, which I’m sure we can all agree is extremely useful, work in a Web 1.0 style world? It needs to dynamically load tiles and various other resou…

> How would google maps work in a Web 1.0 world?

We had that in the form of MapQuest, and it was agonizingly slow. Click to load the next tile, wait for the page to reload, and repeat. Modern SPAs are a revelation.

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

#315

Post by damagednoob »

tedunangst wrote: post #110
stavros wrote: post #67

Earlier quoted context omitted.

If you reduce things so much that all detail is lost, you can't really reason about the original thing any more. The obvious counterpoint here is, you try turning amazon.com into a plain TXT file and see how much sales increase.

I would use a craigslist skinned amazon.

One might suggest that you may not be the only target demographic of Amazon.

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

#316

Post by petre »

pjmlp wrote: post #307
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?

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 website with a home screen icon. Most of the native vehicle, asset or fitness tracking apps need a backend anyways and they fail miserably when disconnected from the network.

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

#317

Post by pjmlp »

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…

Might be easier for the user, sucks as developer experience.

Better do a mobile Web friendly website and leave it at that.

Most users hardly tell the difference anyway.

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

#318

Post by aryehof »

bckr wrote: post #98

I keep hearing good things about Rails. What are the downsides, other than learning a new language and framework?

Downside? … One day when you’re successful and have large numbers of customers, you might need to migrate aspects of your stack to something else.

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

#319

Post by [deleted] »

WuxiFingerHold wrote: post #298
littlecranky67 wrote: post #37

I wonder why there is a debate Next.js vs. SSR. Nextjs is a hybrid and performs quite well. Contrasting with other SPA frameworks, Nextjs produces prerendered html output for fast first loads, efficient js chunks, config switches to eagerly-load those chunks (ie. when hovering over a link or preloading all n+1 links after page render) and efficient image (pre-)loading depending on breakpoint (usually the achilles hee…

NextJS has a lot of significant drawbacks, that's why there's an ongoing debate (which is healthy): - Cost - Complexity - Learning curve - Scalability - Frequent changes - And surprisingly bad performance compared with the direct competitors Nowadays, NextJS is rarely the best tool for the job. Next and React are sitting in the "never got fired for buying IBM" spot. It is a well earned position, as both had a huge in…

[deleted]

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

#320

Post by gls2ro »

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.

I am not sure why people are comparing a web framework with writing your own code in another programming language.

How many CVEs have you had reported yet against your custom code for probably the middleware you wrote to get a request with params available to use them (the params) in an SQL query?

Of course if you are good at this and have a lot of experience than even using an LMM I am sure your code is more than fine. But on average I think it is safe to say that any middleware or library code to deal with HTTP requests and make the information available for business logic generated by an LLM has probably a lot of bugs (some subtle some very visible).

For me the power of Rails is that if you do CRUD web apps it is battle tested and has a long history of giving you what you need for fast building business logic for that CRUD app. Is it the knowledge that is put into designing a web framework that works for 90% of the operations you need to write your custom business logic.

Post reply on HN