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

381–390 of 533 posts

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

#381

Post by ramon156 »

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

Why is that a mess? From my experience you have to recalibrate your project constantly. the framework that's hip and new will be phased out in 5 years.

I don't mean that rewrite hell is a permanent state, but you will always be rewriting parts of your project. I'd rather choose an ecosystem where the friction for rewriting is minimal.

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

#382

Post by petetnt »

Great that it's working for them, but for the end user the feel of the site nearly unusable. There's 1s+ of delay on every interaction - pressing "home" button from explore tab takes 1,85 seconds (on a gigabit connection) before home view comes active, without any other feedback to the end user except for "Home" icon becoming active.

You cannot just blindly trust the page speed metric but it should be impossible to miss things like this when you are actually using the site. Compare the experience to something like GoodReads that's using plain old SSR and you'll immediately notice the difference.

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

#384

Post by vinnymac »

gameman144 wrote: post #283
vinnymac wrote: post #194

Earlier quoted context omitted.

If you’re asking if it would incentivize us to be more careful when introducing additional interactive functionality on a page, and how that functionality impacted performance and page speed, I expect it would. Thinking about how the web was designed today, isn’t necessarily good when considering how it could work best tomorrow.

> If you’re asking if it would incentivize us to be more careful when introducing additional interactive functionality on a page, and how that functionality impacted performance and page speed, I expect it would. Not quite, I wasn't trying to make a bigger point about is/ought dynamics here, I was more curious specifically about the Google Maps example and other instances like it from a technical perspective. Current…

“Worse” here is relative to how we have designed sites such as Google maps today. The current web would fundamentally break if we stopped supporting scripts after page load, so moving would be painful. However, we build these lazy and bloated monolith SPAs and Electron apps because we can, not because we have to. Other more efficient and lightweight patterns exist, some of us even use them today.

If you can exchange static content, you need very little scripting to be able to pull down new interactive pieces of functionality onto a page. Especially given that HTML and CSS are capable of so much more today. You see a lot of frameworks moving in this direction, such as RSCs, where we now transmit components in a serializable format.

Trade offs would have to be made during development, and with a complex enough application, there would be moments where it may be tough to support everything on a single page. However. I don’t think supporting single page is necessarily the goal or even the spirit of the web. HTML imports would have avoided a lot of unnecessary compilers, build tools, and runtime JS from being created for example.

https://www.w3.org/TR/html-imports/

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

#385

Post by vinnymac »

sgustard wrote: post #314
noodlesUK wrote: post #25

Earlier quoted context omitted.

I completely agree with the sentiment that we don’t need SPAs and similar tech for news sites and dashboards and the myriad crud apps we use on a day to day basis but I think what you’re proposing is throwing the baby out with the bath water. How would a site like google maps, which I’m sure we can all agree is extremely useful, work in a Web 1.0 style world? It needs to dynamically load tiles and various other resou…

> How would google maps work in a Web 1.0 world? We had that in the form of MapQuest, and it was agonizingly slow. Click to load the next tile, wait for the page to reload, and repeat. Modern SPAs are a revelation.

What’s cool is that with html includes (import specification) we could have supported this without any JS.

https://www.w3.org/TR/html-imports/

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

#386

Post by fideloper »

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

“just add more complexity”

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

#387

Post by gedy »

PapaPalpatine wrote: post #358
gedy wrote: post #295

Earlier quoted context omitted.

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

> Rails UI integration tests took a very long time How many integration tests do you have? I generally only test a few core flows and then leave the rest to controller/request tests.

A lot. We were moving towards that approach when I left, though the detailed UI tests were then in JS tests which didn't need the whole app running.

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

#388

Post by makeitdouble »

karmakaze wrote: post #151
benblue wrote: post #134

Earlier quoted context omitted.

I agree that ActiveRecord isn't particularly opinionated about how to deal with updates to batches of records, but there are multiple ways of approaching this and AR won't get in your way. upsert_all[1] is available to update a batch of records in a single write that does not invoke model callbacks. activerecord-import[2] is also very nice gem that provides a great api for working with batches of records. It can be a…

By upsert_all not invoking model callbacks, it's admitting that the ActiveRecord approach doesn't scale. "It can be as simple as extracting your callback..." Isn't this the kind of repetitive thing a framework should be doing on your behalf? To be fair, ActiveRecord isn't a fault Rails invented. Apparently it's from one of Martin Fowler's many writings where each model instance manages its own storage. Even Fowler se…

TBF no framework will do everything perfectly, and having clean escape hatches is pretty good in itself.

Even outside of batch processing, there will usually be a few queries that absolutely benefit from being rewritten in a lower layer of the ORM or even plain SQL. It's just a fact of life.

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

#389

Post by yellow_lead »

petetnt wrote: post #382

Great that it's working for them, but for the end user the feel of the site nearly unusable. There's 1s+ of delay on every interaction - pressing "home" button from explore tab takes 1,85 seconds (on a gigabit connection) before home view comes active, without any other feedback to the end user except for "Home" icon becoming active. You cannot just blindly trust the page speed metric but it should be impossible to m…

I don't have this delay personally. Probably the page speed metric is more accurate because it smooths out anecdotes like ours.

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

#390

Post by xutopia »

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

I think there are a lot of Rails developers available. The concern many devs have is that they fear they can't get a job anymore (they're mostly mistaking the downturn of the entire market for one limited to Rails).
Post reply on HN