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

441–450 of 533 posts

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

#441

Post by lelanthran »

apothegm wrote: post #268
boomskats wrote: post #128

Earlier quoted context omitted.

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

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

Just how low-spec and/or how much state-data are we talking about here? I ask only because I am downloading an entire dataset and doing all the logic on the client, and my PC is ancient.

I'm on a computer from 2011 (i7 870 @ 2.9GHz with 16MB of RAM), and the client-side filtering I do, even on a few dozens of thousand of records retrieved from the server, still takes under a second.

On my private app, my prospect list containing maybe 4k records, each pretty substantial (as they include history of engagements/interactions with that client) is faster to sort and filter on the client than it is to download the entire list.

I am usually waiting for 10s while the hefty dataset downloads, but the sorting and filtering happens in under a second. I do not consider that a poor UX.

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

#442

Post by lelanthran »

const_cast wrote: post #424
balencpp wrote: post #325

Earlier quoted context omitted.

So you make incrementing a counter a full page reload?

What's the business usecase for incrementing a counter? We can sit here all day and think up counterexamples, but in the real world what you're doing 99% of the time is: 1. Presenting a form, custom or static. 2. Filling out that form. 3. Loading a new page based off that form. When I open my bank app or website, this is 100% of the experience. When I open my insurance company website, this is 100% of the experience.…

> What's the business usecase for incrementing a counter?

Notification count in the top right?

Remaining credit on an interactive service (like the ChatGPT web interface)?

So, maybe two(!) business use-cases out of thousands, but it's a pretty critical two use-cases.

I agree with you though - do all normal HTML form submissions, and for those two use-cases use `setInterval` to set them from a `fetch` every $X minutes (where you choose the value for $X).

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

#443

Post by lelanthran »

ysavir wrote: post #373
balencpp wrote: post #325

Earlier quoted context omitted.

So you make incrementing a counter a full page reload?

You don't need an SPA to handle incrementing a counter. If a page needs dynamic behavior you add JS to it, whether it's just adding an in-memory counter or an API call to store and retrieve some data. It's not difficult to write JavaScript. The problem with SPAs is that they force having to maintain a JS-driven system on every single page, even those that don't have dynamic behavior.

> You don't need an SPA to handle incrementing a counter. If a page needs dynamic behavior you add JS to it, whether it's just adding an in-memory counter or an API call to store and retrieve some data. It's not difficult to write JavaScript.

I agree with this. Sprinkle in the JS as and when it is needed.

> The problem with SPAs is that they force having to maintain a JS-driven system on every single page, even those that don't have dynamic behavior.

I don't agree with this: SPAs don't force "... having to maintain a JS-driven system on every single page..."

SPA frameworks do.

I think it's possible to do reasonably simple SPAs without a written-completely-in-JSX-with-Typescript-and-a-5-step-build-process-that-won't-work-without-25-npm-dependencies.

I'm currently trying out a front-end mechanism to go with my high-velocity back-end mechanism. I think I've got a good story sorted out, but it's early days and while I have used my exploratory prototype in production, I've only recently iterated it into a tiny and neat process that has no build-step, no npm, and no JS requirement for the page author. All it uses is `` in the ``, with no more JS on the rest of the page.

Very limited though, but it's still early days.

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

#444

Post by CooCooCaCha »

lemonwaterlime wrote: post #403
quantadev wrote: post #147

Earlier quoted context omitted.

I agree, just use React from day one. The reality is that web pages are hardly ever perfectly static, and once there's any dynamic nature to it at all you need something like React or else you'll have a train wreck of JS DOM-manipulation calls before you know it. React is perfect. You just update your state and the page magically re-renders. It's a breeze.

Multiple times in this thread you have been taking the hardline stance that a framework is always necessary while stating that others are saying the same in the opposite direction. In reality, most people seemingly advocating for non-React are actually saying to start simple and add the complexity where and when it’s needed. Further, being against a bloated framework is not the same as being against frameworks. Those…

Your reading of my point is very strange. When I said “best practices” I clearly meant the most commonly repeated best practices. If I cast doubt on those best practices then clearly I intend to replace them with other best practices that I think are better, and that’s what I did. And suggesting better practices doesn’t imply that I think people should blindly follow them.

> Most people seemingly advocating for non-React are actually saying to start simple and add the complexity where and when it’s needed.

In my experience that’s actually not the case. That might be what people claim, but in my professional experience some people really don’t like frontend work and they try to avoid frontend frameworks because they think it’ll make their work more tolerable, but what usually happens is they start out “simple” but pretty quickly product requirements come in that are hard to do without some framework, then there’s a scramble to add a framework or hack it into some parts of the app.

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

#445

Post by ysavir »

lelanthran wrote: post #443
ysavir wrote: post #373

Earlier quoted context omitted.

You don't need an SPA to handle incrementing a counter. If a page needs dynamic behavior you add JS to it, whether it's just adding an in-memory counter or an API call to store and retrieve some data. It's not difficult to write JavaScript. The problem with SPAs is that they force having to maintain a JS-driven system on every single page, even those that don't have dynamic behavior.

> You don't need an SPA to handle incrementing a counter. If a page needs dynamic behavior you add JS to it, whether it's just adding an in-memory counter or an API call to store and retrieve some data. It's not difficult to write JavaScript. I agree with this. Sprinkle in the JS as and when it is needed. > The problem with SPAs is that they force having to maintain a JS-driven system on every single page, even those…

A codebase doesn't need that toolset to be an SPA. An SPA is just a website where all the site's functionality is done on the "root page", and it uses JS to load the data, handle navigation, etc. Doesn't matter whether that's all done through React in TypeScript and compiled by Vite or by handrolled JavaScript fetched in .js files.

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

#446

Post by CuriouslyC »

AlchemistCamp wrote: post #414
CuriouslyC wrote: post #235

Earlier quoted context omitted.

I've been a professional programmer for ~20 years and worked in a variety of languages on a variety of different types of projects, and Typescript with Bun is mostly just fine. It lacks some low level primitives I'd like to have available for certain projects (e.g. Go channels), and the FFI interface isn't as nice as I'd like, but it's basically serviceable for for a very broad range of problems. You should still kno…

It reminds me of an older dev I met when I was just beginning who had worked even more years and said Fortran 95 was "fine". And he could use it to build pretty much anything. That doesn't mean that more powerful language features couldn't have increased his productivity (if he learned them).

There's something to be said for using the right tool for the job. There's also something to be said for maximizing your ability to hire developers. Software is a game of tradeoffs, and while I can and do still pick up modern hotness when warranted (e.g. Zig), sometimes the path to minimum total software cost (and thus maximum company value) is to take well trodden paths.

As fun side anecdote, if you're doing scientific computing in a variety of fields, Fortran 95 is mostly still fine ;)

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

#447

Post by apothegm »

lelanthran wrote: post #441
apothegm wrote: post #268

Earlier quoted context omitted.

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.

> 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. Just how low-spec and/or how much state-data are we talking about here? I ask only because I am downloading an entire dataset and doing all the logic on the client, and my PC is ancient. I'm on a computer from 2011 (i7 870 @ 2.9GHz with 16MB…

10s is painful. A server-rendered app should be able to deliver that data, already rendered, in closer to a fifth of a second. Fast enough that the user doesn’t even notice any wait.

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

#448

Post by lelanthran »

apothegm wrote: post #447
lelanthran wrote: post #441

Earlier quoted context omitted.

> 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. Just how low-spec and/or how much state-data are we talking about here? I ask only because I am downloading an entire dataset and doing all the logic on the client, and my PC is ancient. I'm on a computer from 2011 (i7 870 @ 2.9GHz with 16MB…

10s is painful. A server-rendered app should be able to deliver that data, already rendered, in closer to a fifth of a second. Fast enough that the user doesn’t even notice any wait.

> 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 already so large that the user has been waiting a long time for it already; they already know that this dataset takes time.

FWIW, the data is coming in as CSV, compressed, so it's as small as possible. It's not limited by the server. Having it rendered by the server will increase the payload substantially.

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

#449

Post by lelanthran »

ysavir wrote: post #445
lelanthran wrote: post #443

Earlier quoted context omitted.

> You don't need an SPA to handle incrementing a counter. If a page needs dynamic behavior you add JS to it, whether it's just adding an in-memory counter or an API call to store and retrieve some data. It's not difficult to write JavaScript. I agree with this. Sprinkle in the JS as and when it is needed. > The problem with SPAs is that they force having to maintain a JS-driven system on every single page, even those…

A codebase doesn't need that toolset to be an SPA. An SPA is just a website where all the site's functionality is done on the "root page", and it uses JS to load the data, handle navigation, etc. Doesn't matter whether that's all done through React in TypeScript and compiled by Vite or by handrolled JavaScript fetched in .js files.

> A codebase doesn't need that toolset to be an SPA.

That's kinda the goal I'm trying to reach. If you know of any SPA that doesn't come with all the baggage and only uses ``, by all means let me know.

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

#450

Post by boomskats »

apothegm wrote: post #268
boomskats wrote: post #128

Earlier quoted context omitted.

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

What mass of data? Can you give me an example of the kind of device and the kind of use case you're talking about?
Post reply on HN