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

291–300 of 533 posts

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

#291

Post by WuxiFingerHold »

zozbot234 wrote: post #73
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.

> As a user, the typical SPA offers a worse experience. Your typical SPA has loads of pointless roundtrips. SSR has no excess roundtrips by definition, but there's probably ways to build a 'SPA' experience that avoids these too. (E.g. the "HTML swap" approach others mentioned ITT tends to work quite well for that.) The high compute overhead of typical 'vDOM diffing' approaches is also an issue of course, but at least…

Yes, pure old school SPAs have at least one additional roundtrip on the first visit of the site:

1. Fetch index.html 2. Fetch js, css and other assets 3. Load personalized data (json)

But usually step 1 and 2 are served from a cdn, so very fast. On subsequent requests, 1 and 2 are usually served from the browser cache, so extremely fast.

SSR is usually not faster. Most often slower. You can check yourself in your browser dev tools (network tab):

SPA: https://www.solidjs.com/

vs.

Poster child SSR: https://nextjs.org/

So much complexity and effort in the nextjs app, but so much slower.

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

#292

Post by molochai »

skydhash wrote: post #217
int_19h wrote: post #167

Earlier quoted context omitted.

My biggest annoyance with SPAs is that they usually break forward/back/history in various subtle (or not so subtle) ways. Yes, I know that this can be made to work properly, in principle. The problem is that it requires effort that most web devs are apparently unwilling to spend. So in practice things are just broken.

An additional one for me is stale state. I can leave most webpages open for days, except SPAs. Especially on mobile.

A small but silly one: breaking middle and right click functionality for links.

An auction site I use loads in the list of auctions after the rest of the page loads in, and also doesn't let you open links with middle click or right click>new tab, because the anchor elements don't have href attributes. So that site is a double-dose of having to open auctions in the same tab, then going back to the list page and losing my place in the list of auctions due to the late load-in and failure to save my scroll location.

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

#293

Post by pier25 »

jdsleppy wrote: post #219
pier25 wrote: post #113

Earlier quoted context omitted.

I don't know. Many interactions are simply better delivered from the client. Heck some can only be exclusively delivered from the client (eg: image uploading, drag and drop, etc). With HTMX, LiveViews, etc there will be challenges integrating server and client code... plus the mess of having multiple strategies handling different parts of the UI.

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 solve this unless you're ready to accept a very rudimentary UX.

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

#294

Post by travisgriggs »

cpursley wrote: post #101
bananatron wrote: post #2

Rails is particularly nice in a cursor-first world (probably true of any elder framework that has strong opinions/conventions).

Languages with stronger types like typescript (unfortunately) perform much better than dynamic languages like Ruby, Elixir or even plain JS in an AI editor world. Because the editors are type smart and you can quickly pop the type error into the AI chat and it will attempt to correct it. The feedback cycle is just insane. I really hate to say it, but Typescript has won.

Have you seen any studies that validate this? I feel this would be the case, but I can’t say I’ve actually seen it work out. Cursor writes better Elixir code for me than it does Kotlin, or at least it anecdotally seems so. I find it confusing.

I remember many years ago an akin experience, talking to John Brant and Don Roberts who had done the original refactoring browser in Smalltalk. Java was on its meteoric rise with tons of effort being dumped into Eclipse. They, and others with them, were eager to port these techniques to eclipse, and the theory was they’d be able to do even more because of they typing. But Brant/Roberts that surprisingly it has been more difficult. Part of the problem was the AST. Java, while typed, had a complex AST (many node types), compared to that of Smalltalk (late/runtime typed) which had a very simple/minimal AST. It was in interesting insight.

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

#295

Post by gedy »

adenta wrote: post #285
gedy wrote: post #276

Earlier quoted context omitted.

Yeah, we were spending 10s of thousands of dollars on CI costs a month for a huge Rails app's integration tests alone..

What CI provider?

Was using TeamCity, then dropped some moving to another system.

The broader point was basically that the Rails UI integration tests took a very long time, and required the whole system up, and we had a pretty large team constantly pushing changes. While not 100% unique to Rails, it was exacerbated by RoR conventions.

We moved much of the UI to a few Next.js apps where the tests were extremely fast and easy to run locally.

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

#296

Post by nop_slide »

trinix912 wrote: post #190
nop_slide wrote: post #100

Earlier quoted context omitted.

SEO. I run skatevideosite.com and accidentally did the first rewrite when I took it over in react because that’s all I knew. I absolutely tanked the seo. Rewrote it in rails and got everything back in shape and it’s been a fun experience!

Unrelated, but big kudos to you for running skatevideosite.com. Such a great resource.

Appreciate it! Holler at me if you have any interest in contributing development -wise or to curate videos. We’re always open to new contributors!

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

#297

Post by pier25 »

dmix wrote: post #146
pier25 wrote: post #124

Earlier quoted context omitted.

> The obsession with DX tooling is exactly why JS is such an awful developer experience. I used to agree but these days with Vite things are a lot smoother. To the point that I wouldn't want to work on UI without fine-grained hot reloads. Even with auto reload in PHP, .NET, etc you will be wasting so much time. Especially if you're working on something that requires interaction with the page that you will be repeatin…

> Especially if you're working on something that requires interaction with the page that you will be repeating over and over again. That’s honestly not that many things IRL. If you look at all the things you build only a minority actual demand high interactivity, or highly custom JS. Otherwise existing UI libraries cover the bulk of what people actually need to do on the internet (ie, not just whatever overly fancy o…

> Rails has a library that will refresh the page when files change without a full reload

What if you have a modal opened with some state?

Or a form filled with data?

Or some multi-selection in a list of items that triggers a menu of actions on those items?

Etc.

And it's true Vite can't always do HMR but it's still better than the alternative.

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

#298

Post by WuxiFingerHold »

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 innovational impact.

Do you need best in class loading and SEO with some interactivity later on? Astro with islands. Vitepress does something similar.

Do you need a scalable, cost efficient and robust stack and have moderate interactivity? Traditional SSR (RoR, Django, .NET MVC, whatever) with maybe some HTMX.

Do you have a highly interactive app? Fast SPA like Svelte, Solid or Vue.

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

#299

Post by WuxiFingerHold »

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

Yes, my experience as well. Last year I had to make a decision for the stack of a small app at work that needs a SPA (3D viewing large data sets using threejs and agGrid if anyone cares) and with long term stability as very high prio.

Long story short: I ended up choosing ASP.NET Core with Minimal APIs. The main reason was indeed EF Core as ORM, which I consider as one if not the best ORM. In the Node world there's so much promise (Prisma, Drizzle, ...) but also so much churn.

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

#300

Post by hliyan »

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

The JS ecosystem would be so much better if developers concentrated to contributing to libraries rather than writing new frameworks. After about 10 years of JavaScript, I recently moved over to .NET and I'm finding that my team can focus on actually developing features than maintaining the plumbing.
Post reply on HN