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

261–270 of 533 posts

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

#261

Post by esperent »

mattgreenrocks wrote: post #170
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.…

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.

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

#262

Post by t-writescode »

Frontend and Backend developers have never really been good at talking, for as long as I've been a developer.

As a historically backend-developer, I've tended to dislike Html/JS/CSS. It's a meaningfully different paradigm from the Swing/Awt, WinForms, Android UX, etc. That alone was enough to frustrate me and keep me on the backend. To learn how to make frontend, I've had to since learn those 3. They're finally becoming familiar.

BUT, for front-end developers, they needed to learn "yet another language"; and a lot of these languages have different / obnoxious build systems compared to nvm and friends. And then, like anyone who's ever changed languages knows, they had to learn a whole bunch of new frameworks, paradigms, etc.

Well, they would have, but instead, some of them realized they could push Javascript to the backend. Yes, it's come with *a lot* of downsides; but, for the "Get Shit Done" crowd - and especially in the world of "just throw more servers at it" and "VC money is free! Burn it on infra!" these downsides weren't anything worth worry about.

But the front-end devs - now "full stack devs" but really "javascript all the things" devs -, continued to create in a visible way. This is reflective of all the friggin' LinkedIn Job Postings right now that require Next.JS / Node.JS / whatever roles for their "full stack" positions. One language to rule them all, and all that.

Just some ramblings, but I think it's strongly related to why people would choose Next.JS __ever__, given all its downsides.

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

#263

Post by realusername »

freedomben wrote: post #140
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.…

We currently have two major apps, One in typescript and one in rails. I have to hire devs for both, and I have not experienced it being any more difficult to find a rails developer or a node/typescript developer. If anything, I think finding a rails developer with relevant experience is even easier because the stack is so much more standardized. With people with node experience, there is a huge chance that they won't…

That's a point which cannot be underestimated, almost every Rails codebase looks mostly the same while I've never seen two similar node projects. Standardization also has advantages on training and hiring.

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

#264

Post by ummonk »

const_cast wrote: post #197
nine_k wrote: post #75

Earlier quoted context omitted.

Unless you can guarantee RTT under 100ms, you have to manage some state on client side, else your UI will feel sluggish.

It’s trivial to achieve under 100ms in the US with even just one server. Most companies aren’t international.

Without keep-alive, any HTTPS request requires multiple round trips to complete.

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

#265

Post by hirvi74 »

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

> they just need partial HTML swaps.

Been a web dev for over a decade, and I still use plain JS. I have somehow managed to avoid learning all the SPAs and hyped JS frameworks. I used HTMX for once project, but I prefer plain JS still.

I was a JQuery fan back in the day, but plain JS is nothing to scoff at these days. You are right though, in my experiences at least, I do not need anything I write to all happen on a single page, and I am typically just updating something a chunk at a time. A couple of event listeners and some async HTTP requests can accomplish more than I think a lot of people realize.

However, if I am being honest, I must admit one downfall. Any moderately complex logic or large project can mud-ball rather quickly -- one must be well organized and diligent.

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

#266

Post by hirvi74 »

jefozabuss wrote: post #207
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.

I still have some ptsd from payment gateway integrations via iframes about 6-7 years ago. If you thought SPAs are bad by themselves for history tracking imagine those banking iframes randomly adding more entries via inside navigation/redirection that you have to track manually.

A lot can be said for just putting a "back" button a page. I still do it occasionally for this very reason. Then again, my user base for the apps I write are the most non-technical folks imaginable, so many of them have no concept of a browser back button to begin with. I am not being hyperbolic either.

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

#267

Post by hirvi74 »

jimbob45 wrote: post #243
dmix wrote: post #104

Earlier quoted context omitted.

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

> (I weep for Silverlight).

'Twas before my time. What was so great about it? I remember needing it installed for Netflix like 15 years ago. Did you ever work with Flash? How was that?

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

#268

Post by apothegm »

boomskats wrote: post #128
zozbot234 wrote: post #73

Earlier quoted context omitted.

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

> Your typical SPA has loads of pointless roundtrips This is an implementation choice/issue, not an SPA characteristic. > there's probably ways to build a 'SPA' experience that avoids these too PWAs/service workers with properly configured caching strategies can offer a better experience than SSR (again, when implemented properly). > The high compute overhead... I prefer to do state management/reconciliation on the c…

Except for a user on a lower specced device that can’t performantly handle filtering and joining on that mass of data in JS code, or perhaps can’t even hold the data in memory.

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

#269

Post by hirvi74 »

t-writescode wrote: post #258
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…

You can accomplish the "don't have to reload the page to see my changes" with htmx and it's still "server-side rendering" (or mostly server-side rendering). Legendarily, the fastest website on the internet uses partial page caching to achieve its speed

What do you like about HTMX? I coming from a world of plain JS usage -- no SPAs or the like. I just felt like HTMX was just a more complicated way to write what could be simple .fetch() requests.

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

#270

Post by falcor84 »

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.

Really, what would you be looking to achieve?

I suppose you could have custom CSS (e.g. via Stylebot) remove 90% of the elements and all but one of the pictures, but would that really make the amazon purchasing experience better?

Post reply on HN