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

491–500 of 533 posts

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

#491

Post by Zanfa »

DanielVZ wrote: post #479
touristtam wrote: post #474

Earlier quoted context omitted.

Github can be horribly slow sometimes (tested from different machines and through different ISPs) and difficult to tell if that is down to the framework used to render the pages or any other parts of the system.

A few years ago it started a transition to react. It has been less snappy ever since to me.

Agree, the new code viewer is horrid. Also breaks right-click navigation between files for no reason. Not once have I triggered the interactive editor mode on purpose, but happens all the time accidentally, trying to select / hightlight a line. So frustrating…

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

#493

Post by recursivedoubts »

hirvi74 wrote: post #490
recursivedoubts wrote: post #284

Earlier quoted context omitted.

maybe check out fixi.js: https://github.com/bigskysoftware/fixi

I appreciate the suggestion. Not sure I am a fan of this implementation though. It looks near identical to the HTMX JS API that is already backed into HTMX. Most of the annoyances I dealt with were around conditional logic based on validation. After enough of the HTMX JS API, I figured, "What is HTMX even buying me at this point?" Even if plain JS is more verbose, that verbosity comes with far less opinions and const…

if you are using the htmx javascript API extensively rather than the attributes, you are not using htmx as it was intended

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

#494

Post by recursivedoubts »

hirvi74 wrote: post #489
t-writescode wrote: post #273

Earlier quoted context omitted.

I like that it still feels like html. I think that's it's biggest selling point. You write: Send Compared to (ChatGPT helped me write this one, so maybe it could be shorter, but not that much shorter, I don't think?): Send async function handleSubmit(event) { event.preventDefault(); // the form submit stuff const form = event.target.form; const formData = new FormData(form); const submitter = event.target; if (submit…

Yeah, the JS could technically be shorter, but your example is functional enough to get the point across. Going with your example, how would you do proper validation with HTMX? For example, the input element's value cannot be null or empty. If the validation fails, then a message or something is displayed. If the validation is successful, then that HTML is replace with whatever? I have successfully gotten this to wor…

two possible approaches:

1. Do the validation server side and replace the input (or a label next to the input, see https://htmx.org/examples/inline-validation/)

2. Use the HTML 5 Client Side form validation API, which htmx respects:

https://developer.mozilla.org/en-US/docs/Learn_web_developme...

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

#495

Post by TranquilMarmot »

welder wrote: post #467
TranquilMarmot wrote: post #430

Earlier quoted context omitted.

That's funny, I would say the go-to is Prisma. We use it heavily and have not had any issues.

I've used both and Drizzle has become the goto now in the TS community.

I'll try it out next time I need to build something.

Where I work, as an org, we have gone all-in on Prisma across dozens of projects so getting buy-in to try something else will be an uphill battle.

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

#496

Post by const_cast »

sroussey wrote: post #484
const_cast wrote: post #421

Earlier quoted context omitted.

It's not a different reality. To give perspective to what JS I've dealt with - I worked a couple years on a legacy webapp. It used vanilla JS and the only library used was jQuery. It heavily used iframes for async functionality in combination with XSLT to translate backend XML apis to HTML. Opening up a 10K lines JS file is like jumping into the ocean. Nothing is obvious, nothing makes sense. You're allowed to just d…

> You're allowed to just do whatever the fuck in JS. I think that’s a feature not a bug. But then again, I generally like and use Typescript.

It's definitely a feature when you're starting out. But as the codebase grows and ages, it becomes a bug.

The problem is that the behavior becomes so complex and so much is pushed to runtime that there's no way to know what the code is actually doing. There's paths that are only going to be executed once a year, but you don't know which ones those are. Eventually, editing the code becomes very risky.

At this particular codebase, it was not uncommon to see 3, 4 or 5 functions that do more or less the same thing. Why? Because nobody dared change the behavior of a function, even if it's buggy. Maybe those bugs are the only thing keeping other bugs from cropping up. It's like wack-a-mole. You fix something, and then the downstream effects are completely unpredictable.

It becomes a self-eating snake. Because the codebase is so poor, it ends up growing faster and faster as developers become more risk-averse.

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

#497

Post by jjani »

Scarblac wrote: post #370
jjani wrote: post #328

Earlier quoted context omitted.

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

That sounds like roughly all work related software? Not so niche at all.

Who uses PWA for work-related apps though? There too, the standard is MDN which uses a curated version of the app stores.

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

#498

Post by lelanthran »

apothegm wrote: post #488
lelanthran wrote: post #448

Earlier quoted context omitted.

> 10s is painful. A server-rendered app should be able to deliver that data, already rendered, in closer to a fifth of a second. How do you know how large the dataset is? All you know from my post is that a dataset that takes 10s to download (I'm indicating the size of it here!) takes under a second to filter and sort. My point is that if your client-code is taking long to filter and sort, then your dataset is alread…

The JS processing and rendering time on an underpowered CPU is the issue, not the payload size. It’s difficult to describe how excruciatingly slow some seemingly simple e-commerce and content sites are to render on my 2019 laptop or how slowly they react to something as simple as a mouseover or how they peg the CPU - while absolutely massively complex and large server-rendered HTML loads and renders in an eyeblink.

Which sites are you thinking off?

I can't really speak for those sites anyway, or why they are so slow doing things on the client, but like I said, I've written client-side processing and used my 2011 desktop, and there has been no pegging of the CPU or large latencies when filtering/sorting data client-side.

> while absolutely massively complex and large server-rendered HTML loads and renders in an eyeblink.

I've not had that experience - a full page refresh with about 10MB of data does not happen in an eyeblink. It takes about 6 seconds. There's a minimum amount of time for that data to download, regardless of whether it is pre-rendered into `` elements or whether it is sent as JSON. Turning that JSON into a `` on the client takes about 40ms on my 2011 desktop. Sorting it again takes about 5ms.

For this use-case (fairly large amounts of data), doing a full-page refresh each time the user sets a new sort criteria is unarguably a poorer experience than a bit of JS that goes through the table element and re-orders the `` elements.

In this case, using server-rendered HTML is always going to be 6000ms whenever the user re-sorts the table. Using a client JS function takes 5ms. On a machine purchased in 2011.

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

#499

Post by vlod »

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

Before rails, a lot of people were either using PHP or Java with JSPs/Servlets. If you were 'cool' you used Spring/Hibernate with a mountain of XML configurations.

Ruby/Rails was a breath of fresh air. Translate: Not a PITA.

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

#500

Post by WorldMaker »

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

I recently blogged about [0] how I felt after some experiments with a traditional multi-page application with simple Web Components as "Progressive Enhancement". Taking an "offline first" approach to the "simple CRUD" of the application (saving everything all the time in Local Storage and then doing very simple "3-way merges" with remote data as it catches up) made it feel enough like a SPA that I was thrilled with overall performance. Think I just need to add CSS View Transitions for one last bit of "SPA-like" polish.

I am starting to think now is a great time to return to some of the Knockout-era ideals of "Progressive Enhancement". Web Components, the template tag, local storage, CSS view transitions, and a few other subtle modern things seem to be getting close to the point where the DX is as good or better than SPAs and the UX feels similar or better, too.

[0] https://blog.worldmaker.net/2025/04/27/book-club/

Post reply on HN