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

371–380 of 533 posts

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

#371

Post by ndriscoll »

pier25 wrote: post #293
jdsleppy wrote: post #219

Earlier quoted context omitted.

HTMX has a very nice drag and drop extension I just found, though. And old-school forms can include image files. The little image preview can be a tiny "island of JS" if you have to have it.

> The little image preview can be a tiny "island of JS" if you have to have it. I would consider that the bare acceptable minimum along an upload progress indicator. But it can get a lot more complicated. What if you need to upload multiple images? What if you need to sort the images, add tags, etc? See for example the image uploading experience of sites like Unsplash or Flickr. HTMX just ism't the right tool to solv…

> along an upload progress indicator

I could be misremembering, but didn't browsers used to have this built in? Like there used to be a status bar that showed things like network activity (before we moved to a world where there is always network activity from all of the spying), upload progress, etc.

I don't remember if it was in Firefox, but SeaMonkey even has a "pull the plug" button to quickly go offline/online in the status bar.

Bizarre that "progress" is removing basic functionality and then paying legions of developers to re-add it in inconsistent ways everywhere.

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

#372

Post by catlover76 »

princevegeta89 wrote: post #135
catlover76 wrote: post #119

Earlier quoted context omitted.

What would you say the good and bad of GraphQL are? Like, when it is a value-add, and when should it be avoided?

The good news is GraphQL is very quick and easy to pick up and it gives that inbuilt functionality to fetch exactly the amount of data that we need. On top of it, it also has enough flexibility to integrate with your business logic. So it can be a straightforward replacement for a traditional REST API that you would have to manually build. For the disadvantages, I cannot think of any. It is a bit slower than hand rol…

[dead]

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

#373

Post by ysavir »

balencpp wrote: post #325
const_cast wrote: post #195

Earlier quoted context omitted.

No you really don’t. I’ve worked on exceptionally complex legacy applications with essentially no state in the front end. At most, you’re looking at query parameters. You just make everything a full page reload and you’re good to go.

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.

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

#374

Post by buzzerbetrayed »

lmm wrote: post #330
fvdessen wrote: post #324

Earlier quoted context omitted.

> There might be some queries expressible in your GraphQL that would have severe performance problems or even bugs, sure, but if your frontend doesn't actually make queries like that, who cares? People with bad intentions can make those slow queries happen at high volume with custom tooling, they don’t have to restrict themselves to how the frontend uses the queries

> People with bad intentions can make those slow queries happen at high volume with custom tooling, they don’t have to restrict themselves to how the frontend uses the queries Depends how your system is set up. I'm used to only allowing compiled queries on production instances, in which case attackers have no way of running a different query that you don't actually use.

So un-graphql-ing your graphql. This shit is wild.

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

#375

Post by catgirlinspace »

t-writescode wrote: post #256
vdfs wrote: post #216

Earlier quoted context omitted.

What did you move to? We've been using NextJS as a frontend with somehelpful server-side/api handling, but the backend is done in Django. We are basically just using ReactJS with the convenience of NextJS (like file based routing)

Not OP; but when I was thinking about using Next.JS, and doing a deep investigation, I came to the decision that, for server-side rendering, I'm quite happy to use Kotlin and Ktor (my backend is also Kotlin - I have a lot of client-types, which is why they're separate), and I've been quite happy with Ktor's html dsl + htmx for speed. And Kotlin + Ktor feels very good to write in on serverside. Fast, easy and fluent t…

How are you doing reusable components with the html dsl? From the little bit I’ve tried ktor this was something I could not figure out and it kinda just pushed me away since I couldn’t find anything.

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

#376

Post by ryantownsend »

WD-42 wrote: post #254
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.

This exactly. It seems like the last 10 years of JavaScript framework progress has been driven by DX, not UX. Like at some point everyone forgot this crap just needs to work at the end of the day, no user benefits from 3 rewrites over 5 years because the developer community decided functions are better than classes.

In my view, DX should be renamed "Developer Convenience" as we all know that convenience is often a trade-off.

Please forgive the self-promotion but this was exactly the premise of a conference talk I gave ~18 months ago at performance.now() in Amsterdam: https://www.youtube.com/watch?v=f5felHJiACE

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

#377

Post by selfmodruntime »

princevegeta89 wrote: post #60
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,…

As somebody with an expert level knowledge with MVC frameworks like Ruby on Rails and Phoenix Framework, etc., and an experience building large-scale enterprise-grade apps using simpler technologies like jQuery, StimulusJS and plain old JavaScript on the front end with a little bit of React thrown in here and there, I found Development cycles to be much faster with these simpler stacks overall. The complexity of the…

I never get these comments. I would choose a Next.js / React project to work on 99% of the time compared to the hellish nightmare that is jQuery.

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

#379

Post by solatic »

lmm wrote: post #330
fvdessen wrote: post #324

Earlier quoted context omitted.

> There might be some queries expressible in your GraphQL that would have severe performance problems or even bugs, sure, but if your frontend doesn't actually make queries like that, who cares? People with bad intentions can make those slow queries happen at high volume with custom tooling, they don’t have to restrict themselves to how the frontend uses the queries

> People with bad intentions can make those slow queries happen at high volume with custom tooling, they don’t have to restrict themselves to how the frontend uses the queries Depends how your system is set up. I'm used to only allowing compiled queries on production instances, in which case attackers have no way of running a different query that you don't actually use.

Do you understand that decompilers and reverse engineering are a thing?

Adversaries are not restricted to using your system the way you designed your system. GraphQL queries are trivial to pull out of Wireshark and other sniffers. If you deliver it to the browser, any determined-enough adversary will have it, period. I wouldn't be surprised in the least if it is already a thing for LLM models to sniff GraphQL endpoints in the quest for ever more data.

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

#380

Post by Zarel »

int_19h wrote: post #239
ezekiel68 wrote: post #181

Earlier quoted context omitted.

What is the specific pain? Are you just referring to dynamic content on the client in general or different issues?

The oldest web apps - web email clients being probably the canonical and most familiar example - didn't do dynamic refresh at all, because there was no way to fetch data from the server, so you couldn't do it even with JS. Any user action that required any part of the page to be updated involved a (very visible) whole page refresh. You could limit the scope of refresh with frames to some extent, but it was still very…

While this is mostly true, there were similar techniques even before XMLHttpRequest. iframes could communicate with parents, and also JSONP. I think JSONP was mostly pioneered as a technique after XMLHttpRequest, but the iframe trick did work (I even used it! just a tiny 16x16 iframe communicating with the parent element by calling functions on window.parent, worked great on IE5).
Post reply on HN