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

361–370 of 533 posts

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

#361

Post by qudat »

0cf8612b2e1e wrote: post #64
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…

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.

If you employ a "preload then rehydrate" data sync paradigm then you should never see a blank page -- except on initial JS load. This is just an improper data sync strat and has nothing to do with SPA.

I built a lib specifically designed for this strat: https://starfx.bower.sh/learn#data-strategy-preload-then-ref...

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

#362

Post by qudat »

dmix wrote: post #104
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…

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.

Hmm, JS is "different" because it has completely unique challenges that no other programming language has to deal with: https://bower.sh/my-love-letter-to-front-end-web-development

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

#363

Post by ndriscoll »

ummonk wrote: post #264
const_cast wrote: post #197

Earlier quoted context omitted.

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.

Fortunately every browser made in the last 25 years supports keepalive. e.g. Firefox (and according the the reporter of this bug, Chrome) won't even let you disable it[0].

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=879002

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

#364

Post by qudat »

throwaway7783 wrote: post #53
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…

I have repeated this elsewhere. APIs for UI tend to diverge from APIs in general in practice. For applications that are not highly interactive, you don't quite need a lot of tooling on the BE, and since need to have a BE anyway, a lot of standard tooling is already in there. React style SPAs are useful in some cases, but most apps can live with HTMX style "SPA"s

> APIs for UI tend to diverge from APIs in general in practice.

I'm arguing to just use a single API, not creating one for UI, at least when you want things to be simple for multiple clients.

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

#365

Post by pc86 »

qudat wrote: post #361
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.

If you employ a "preload then rehydrate" data sync paradigm then you should never see a blank page -- except on initial JS load. This is just an improper data sync strat and has nothing to do with SPA. I built a lib specifically designed for this strat: https://starfx.bower.sh/learn#data-strategy-preload-then-ref...

"Devs are doing SPAs wrong" is irrelevant when 90% of devs do SPAs that way. That it's wrong doesn't help the fact that most SPAs have garbage user experience.

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

#366

Post by pc86 »

molochai wrote: post #292
skydhash wrote: post #217

Earlier quoted context omitted.

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…

I would submit this as product feedback if you haven't. One of my favorite things as a dev working on client-facing things is when I get negative feedback that presumably has a pretty easy fix to at least part of it ("add 'href' to these links") where I can pretty quickly make someone's life a little easier.

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

#367

Post by arvinsim »

I fell in love with React because of its SPA approach, as opposed to SSR.

You must imagine my chagrin when React started moving towards rendering on the server(SSR, Server Components, etc). I was happy to move to a full client implementation. Sadly, SEO cannot be ignored.

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

#368

Post by neonsunset »

t-writescode wrote: post #353
ezekiel68 wrote: post #172

Earlier quoted context omitted.

If you "screw up and succeed" by gaining many users/customers, any Ruby or Python framework provides orders of magnitude fewer requests-per-second on the same VM or hardware than a comparable solution deployed with node.js, go, Java, C# (Including DotNet Core on Linux), or rust. And this will quickly ballon your cloud compute costs to keep up.

I believe(?) stats have shown that Java, C#, Elixir, Rust and friends are going to be quite fast, but Node.JS is going to be even slower than Ruby. At least, Next.JS (which is on top of node, I think?) will be.

Sounds improbable. Unlike Ruby, JavaScript has multiple runtime implementations with capable JIT compilers that sometimes let it even compete with Java on numeric code. Ruby is very, very far away. Please note that Elixir is also in the same single-threaded performance ballpark as Ruby and Python, of course it does not suffer from any of the single-threaded bottlenecks the other two do though.

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

#369

Post by dpflan »

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

What “severe scaling issues” have you encountered?

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

#370

Post by Scarblac »

jjani wrote: post #328
ivan_gammel wrote: post #326

Earlier quoted context omitted.

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

That sounds like roughly all work related software? Not so niche at all.
Post reply on HN