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

21–30 of 533 posts

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

#21

Post by joshstrange »

I'm thankful that I don't work on projects that have SEO needs. SSG (for JS frameworks specifically) feels too unstable for me. I get the value, I understand why people need to do it, but it just makes everything more complicated. Also, I'm not sure if you can have an offline site with SSG? They might be compatible but I'm not sure. I know some SSG is essentially "SPA with the first page rendered already" so maybe that can work offline?

I looked at InertiaJS and it feels like too much "magic" for me personally. I've never used it so I could be wrong but it feels like too many things you have to get working perfectly and the instability in the JS ecosystem makes me worry about adding too many layers.

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

#23

Post by joshstrange »

_mlbt wrote: post #14
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,…

People also forget just how far you can get without using client side JavaScript at all today. HTML and CSS have a lot of features built in that used to require JavaScript.

New inputs types have been glacially slow to come out and often underwhelming. Every new HTML thing I've seen (modals, datetime inputs, datalist select, etc) had better JS versions out for years before they released. I understand that the HTML spec is setting a baseline of sorts but most of the UI is ugly and sometimes not themeable/styleable.

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

#25

Post by noodlesUK »

vinnymac wrote: post #16
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,…

I believe allowing the dynamic loading of scripts was a mistake, and we should undo support for it. So were iframes. Everything after ready should have been static content.

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 resources. The web being a place where we can host and instantly distribute complex cross-platform interactive software in a fairly secure sandbox is a modern marvel.

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

#27

Post by austin-cheney »

When I see articles and discussions about web + stack I can’t but ask “What problem are they actually solving”? The answer is always: put text on screen.

When your business goal is put text on screen the next logical step is to ask how much time and money does the tech stack really save? I have never found a developer that answer that question with a number. That’s a really big problem.

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

#28

Post by vinnymac »

noodlesUK wrote: post #25
vinnymac wrote: post #16

Earlier quoted context omitted.

I believe allowing the dynamic loading of scripts was a mistake, and we should undo support for it. So were iframes. Everything after ready should have been static content.

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…

You misunderstand me, I’m not proposing we get rid of JavaScript.

I am saying that allowing for JavaScript to be dynamically downloaded and executed after the page is ready was a mistake.

You can build your Google docs, your maps, and figmas. You don’t need JS to be sent after the page is ready to do so.

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

#29

Post by freeone3000 »

qudat wrote: post #20
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,…

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…

But on the flip side, you can program the backend in anything you like, instead of being bound to javascript.
Post reply on HN