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

521–530 of 533 posts

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

#521

Post by yawaramin »

pc86 wrote: post #366
molochai wrote: post #292

Earlier quoted context omitted.

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.

Unless it's not a link but a ...

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

#522

Post by yawaramin »

WuxiFingerHold wrote: post #291
zozbot234 wrote: post #73

Earlier quoted context omitted.

> As a user, the typical SPA offers a worse experience. Your typical SPA has loads of pointless roundtrips. SSR has no excess roundtrips by definition, but there's probably ways to build a 'SPA' experience that avoids these too. (E.g. the "HTML swap" approach others mentioned ITT tends to work quite well for that.) The high compute overhead of typical 'vDOM diffing' approaches is also an issue of course, but at least…

Yes, pure old school SPAs have at least one additional roundtrip on the first visit of the site: 1. Fetch index.html 2. Fetch js, css and other assets 3. Load personalized data (json) But usually step 1 and 2 are served from a cdn, so very fast. On subsequent requests, 1 and 2 are usually served from the browser cache, so extremely fast. SSR is usually not faster. Most often slower. You can check yourself in your bro…

> Poster child SSR

That's not really SSR though, it's partial SSR but then hydrated into a client-side React app, so a SPA. If you really want to compare try an htmx page.

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

#523

Post by yawaramin »

lelanthran wrote: post #442
const_cast wrote: post #424

Earlier quoted context omitted.

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…

Notification incrementing is not purely client-side state though. It's triggered by an event coming from a server. Eg let's say you're on a product page and you click 'Add to Cart'. You want the cart icon's counter badge on the top right corner of the page to increment. With eg htmx when you click 'Add to Cart' we send a request to the server, it updates the cart state in the backend, then sends an HTML fragment response that updates the necessary parts of the page, including the cart item counter badge.

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

#524

Post by yawaramin »

SJC_Hacker wrote: post #120
freeone3000 wrote: post #29

Earlier quoted context omitted.

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

You haven’t had to deal directly with JS on front end since Dart released over 10 years ago

No, you still need to deal directly with JS even with a transpiler like Dart or whatever other language you want to use. When things go wrong, and they will, you'll need to deal with the JS errors. When you're trying to debug or even call out to JS APIs, you better be intimately familiar with how your transpiler interops with JS, otherwise you're kinda screwed.

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

#525

Post by yawaramin »

hirvi74 wrote: post #489
t-writescode wrote: post #273

Earlier quoted context omitted.

I like that it still feels like html. I think that's it's biggest selling point. You write: Send Compared to (ChatGPT helped me write this one, so maybe it could be shorter, but not that much shorter, I don't think?): Send async function handleSubmit(event) { event.preventDefault(); // the form submit stuff const form = event.target.form; const formData = new FormData(form); const submitter = event.target; if (submit…

Yeah, the JS could technically be shorter, but your example is functional enough to get the point across. Going with your example, how would you do proper validation with HTMX? For example, the input element's value cannot be null or empty. If the validation fails, then a message or something is displayed. If the validation is successful, then that HTML is replace with whatever? I have successfully gotten this to wor…

> At that point, especially when you have many inputs like this, the amount of work one has to do with the HTMX JS API starts to look at lot like the script tag in your example

Not sure exactly what you're talking about w.r.t 'the amount of work one has to do with the HTMX JS API', but I've found that form validation with htmx and a backend server works really well with just a tiny bit of JS and a little care crafting the backend's validation error response: https://dev.to/yawaramin/handling-form-errors-in-htmx-3ncg

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

#526

Post by yawaramin »

selfmodruntime wrote: post #377
princevegeta89 wrote: post #60

Earlier quoted context omitted.

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.

I would choose neither; there are much easier options available.

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

#527

Post by yawaramin »

lmm wrote: post #154
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,…

> Every line of client JS brings build tooling, npm audit noise, and another supply chain risk. IME this is backwards. All that stuff is a one-off fixed cost, it's the same whether you have 10 lines of JS or 10,000. And sooner or later you're going to need those 10 lines of JS, and then you'll be better off if you'd written the whole thing in JS to start with rather than whatever other pieces of technology you're usi…

It's absolutely not a one-off fixed cost, it's a constant treadmill of new vulnerabilities, upgrade breakages, and ecosystem incompatibilities. Just because you need 10 lines of JS, doesn't mean you 'might as well' have 10,000.

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

#528

Post by yawaramin »

CooCooCaCha wrote: post #444
lemonwaterlime wrote: post #403

Earlier quoted context omitted.

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

So there are a couple of problems with your characterization. Firstly, your blanket assumption that people who want to avoid frontend complexity are really just frontend haters. Sure, there are some people who hate 'web shit', but there are many others, like myself, who want to build useful webapps that are as simple and performant as possible. It doesn't make us frontend haters, it just makes us different.

The second assumption where I believe you are going wrong is that 'product requirements' will always come in and force using a framework. Imho if I look around at most of the webapps I am using, very few of them actually need a SPA framework. Take Jira for example. Does it really need to be fully a SPA? It has some highly interactive parts, which could be done with eg web components, but it's mostly a boring CRUD app that would work fine with eg htmx.

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

#529

Post by yawaramin »

quantadev wrote: post #250
lazypenguin wrote: post #19

Earlier quoted context omitted.

That’s absurd, that’s like saying we should only use C++ for backend code because my CRUD business app might one day scale to infinity. Better be safe than sorry and sling pointers and CMake just in case I need that extra juice!

imo, even if the only "interactivity" a web app has is just a login page, then even that alone is enough to warrant using a framework rather than doing direct DOM manipulation (or even worse, full page refreshes after a form submit). It's not about using the most powerful tool always, it's about knowing how to leverage modern standards rather than reinventing and solving problems that are already solved.

> ...a web app has is just a login page, then even that alone is enough to warrant using a framework rather than doing direct DOM manipulation (or even worse, full page refreshes

Maybe, but it doesn't necessarily need to be a SPA framework though. There are simpler libraries/frameworks like htmx that considerably reduce complexity and also let you avoid direct DOM manipulation.

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

#530

Post by yawaramin »

lmm wrote: post #464
buzzerbetrayed wrote: post #374

Earlier quoted context omitted.

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

Shrug, databases have been doing the same thing since the 1970s (and consider also e.g. regexes). Turns out a flexible, expressive language for writing queries isn't always the most secure or performant thing to use as your wire format.

That's the exact argument against exposing GraphQL to the frontend.
Post reply on HN