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

511–520 of 533 posts

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

#511

Post by dismalaf »

hijp wrote: post #200
dismalaf wrote: post #68

Earlier quoted context omitted.

Rails can be API only and use any frontend you want. Hotwire is the default and they develop it because DHH wants to, but they're not putting up any barriers to you using whatever you want. Also, DHH doesn't seem to care about how big it is. His stated goal is for it to forever be a framework that's usable by a single dev.

Yeah but I wish in an alternate reality DHH chose a different route. If you go API only then you lose half of what makes rails great. It would be sick if you could render React/Vue/Svelte easily in your haml views and not have to have a js repo then figure out jwts and auth. Dunno I loved rails, built monoliths, built api only, but when I tried sprinkling a bit of react in my views (say you only need a little bit of…

> but when I tried sprinkling a bit of react in my views

If you need only a sprinkling why not vanilla JS with Stimulus? Pulling in React for only a "sprinkling" seems like overkill.

The benefit of the current approach is that you can use any vanilla JS code, and it's especially easy if it uses ES Modules.

Also the whole point of React/Vue/Svelte is that they're all complete frameworks meant to do your whole UI. Using "just a sprinkling" of these seems like the worst of both worlds.

Dunno, my app pulls in a fairly heavy JS dependency (Echarts) and it took all of 2 minutes to set it up using Stimulus.

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

#512

Post by hirvi74 »

recursivedoubts wrote: post #494
hirvi74 wrote: post #489

Earlier quoted context omitted.

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…

two possible approaches: 1. Do the validation server side and replace the input (or a label next to the input, see https://htmx.org/examples/inline-validation/ ) 2. Use the HTML 5 Client Side form validation API, which htmx respects: https://developer.mozilla.org/en-US/docs/Learn_web_developme...

Well, I never expected to get a reply from the man himself. Thank you for taking the time to respond.

So, I did end up going with #1 with a slight variation.

You also commented on another comment of mine stating:

> if you are using the htmx javascript API extensively rather than the attributes, you are not using htmx as it was intended

There seems to be some confusion, and I apologize. I extensively used attributes. That wasn't the part of the API I was referring to. Rather, I should have specified that I was heavily relying on a lot of the htmx.on() and html.trigger() methods. My usage of htmx.trigger() was predominately due to something being triggered on page load, but also, it needed to be triggered again if a certain condition was met -- to refetch the html with the new data -- if that makes sense.

I should also preface that I was working on this project about two years ago. It looks like a lot has changed with HTMX since then!

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

#513

Post by solatic »

lmm wrote: post #507
solatic wrote: post #506

Earlier quoted context omitted.

So you threw out all the benefits of GraphQL. Instead of allowing the frontend to determine what it needs, you need to write a new backend endpoint that will return what's needed for that page. This is no different from writing some /rpc/bffe/get-profile-page call, which is much simpler to write and has much better tooling.

No, our backend serves all the queries that the frontend uses, but (in prod) only the queries that the frontend uses - we compile the queries at build time. When we want to add a new query we figure it out in dev (which allows non-compiled queries, but is not accessible for people outside the company), write it in the frontend, and it will be included in the next build of the backend. This is all pretty basic off the…

I think I finally understand your earlier comment in context:

> You can write each endpoint by hand instead of using GraphQL, but it's like writing your own collection datatypes instead of just pulling in an existing library.

Everyone else is "pulling in an existing library", they have names like Express and Kysely, and thinking that Apollo is the only library that deserves this designation is a bit of a head-scratcher.

If you take the time to invest in a proper REST API first, odds are the endpoint may already exist, and you may not need to wait for a new backend build; not investing in a custom endpoint for every frontend change unless real-world performance requirements actually dictate it. You get tooling that is more mature and easier to maintain as a result, makes it easier for Product to experiment (remember: not forcing a backend change for every frontend change), and not using a fad-of-the-month just because it came out of a FAANG.

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

#514

Post by Capricorn2481 »

const_cast wrote: post #419
Capricorn2481 wrote: post #396

Earlier quoted context omitted.

> I would actually say overall C++ is much more reasonable. This is where I know that, some people, are not actually programming in either of these languages, but just writing meme driven posts. JS has a few footguns. Certainly not so many that it's difficult to keep in your head, and not nearly as complex as C++, which is a laughable statement. You've "seen null make it to the database," but haven't seen the exact s…

I haven't seen null make it to the database, I've seen undefined . And here you demonstrate one of many problems - there's multiple null types! In C++, there's only one null, nullptr . But most types can never be null. This is actually one area where C++ was ahead of the competition. C# and Java are just now undoing their "everything is nullable" mistakes. JS has that same mistake, but twice. It's not about complexit…

I am really trying to get on board, but I don't know what you mean. I see your anecdote about two different codebases and you found the C++ one easier, and I'm sure it happens.

> And here you demonstrate one of many problems - there's multiple null types

In JS, null and undefined are not meaningfully different unless you're checking for exactly one or the other. And there's little reason to do that. It has never come up for me that undefined made it through where null wouldn't have. But yes, you need to check if things are defined.

> In C++, there's only one null, nullptr. But most types can never be null

C++ absolutely has undefined, it just doesn't tell you about it. If I make a var with `int myVar;` it's undefined. There's no telling what it points to. But C++ will treat it as `int`. And it can be a lot worse. Vars can be memory represented as the wrong type. They can be truncated memory, dangling pointers, memory freed twice.

But with JS, if I access memory that wasn't explicitly set, it says "that's undefined." That's a good and explicit thing to tell me, and I can actually check for it. And the GC, obviously, avoids a whole class of cases where undefined would come up.

> This is actually one area where C++ was ahead of the competition

For the reasons above, I would say C++ is literally the worst option for null safety. Unless we define safety as "don't tell me this is undefined, even though it is."

> It's far too easy to make mistakes in JS and propagate them out

I'm just not sure why. I would say C++ has absolutely every footgun JS has and more.

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

#515

Post by Capricorn2481 »

const_cast wrote: post #496
sroussey wrote: post #484

Earlier quoted context omitted.

> You're allowed to just do whatever the fuck in JS. I think that’s a feature not a bug. But then again, I generally like and use Typescript.

It's definitely a feature when you're starting out. But as the codebase grows and ages, it becomes a bug. The problem is that the behavior becomes so complex and so much is pushed to runtime that there's no way to know what the code is actually doing. There's paths that are only going to be executed once a year, but you don't know which ones those are. Eventually, editing the code becomes very risky. At this particul…

> The problem is that the behavior becomes so complex and so much is pushed to runtime that there's no way to know what the code is actually doing. There's paths that are only going to be executed once a year, but you don't know which ones those are. Eventually, editing the code becomes very risky.

It's clear you've worked on a really bad codebase, but this is totally different from what you were originally suggesting, which was null being a bigger problem in JS than C++.

What you're describing is frontend development with JQuery, not the capabilities of JS. Now, I don't like NextJS for a lot of reasons, but code organization is not one of them. Everything you're complaining about is dead simple in NextJS. Functions are localized, tracking localized state is easy, and even the older React state libraries have lots of support for tracking and visualizing the more global state changes.

I will die on the hill that JQuery, outside of very small interactivity, is fucking bad. People use JQuery terribly and it creates spaghetti code where you can't tell what the execution path is. People don't document QA testing. And JQuery makes you target html attributes to make changes. That's fun if you have to do it once, it's terrible if all of your app interactivity relies on it.

But that's not due to "undefined", and it would be 100x worse in C++. I am assuming the C++ codebase you compared it to was not a DOM manipulating app?

I don't like NextJS for performance and market reasons, but the codebases I've worked on have been very clean.

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

#516

Post by quantadev »

robertoandred wrote: post #458
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…

> most people seemingly advocating for non-React are actually saying to start simple This assumes that non-React approaches are simple.

That's a good point. non-Framework approaches are not simpler actually. It's a tarpit that looks enticing. You think you can keep stuff "simple" by not using a framework, and in only 2 weeks you've got such complexity you're begging for a framework that does it all automatically, which is kinda...ya know...what frameworks are for. lol.

So you delete the non-framework garbage code and start over. lol.

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

#517

Post by const_cast »

Capricorn2481 wrote: post #514
const_cast wrote: post #419

Earlier quoted context omitted.

I haven't seen null make it to the database, I've seen undefined . And here you demonstrate one of many problems - there's multiple null types! In C++, there's only one null, nullptr . But most types can never be null. This is actually one area where C++ was ahead of the competition. C# and Java are just now undoing their "everything is nullable" mistakes. JS has that same mistake, but twice. It's not about complexit…

I am really trying to get on board, but I don't know what you mean. I see your anecdote about two different codebases and you found the C++ one easier, and I'm sure it happens. > And here you demonstrate one of many problems - there's multiple null types In JS, null and undefined are not meaningfully different unless you're checking for exactly one or the other. And there's little reason to do that. It has never come…

C++ is at least somewhat strictly typed and - again - most types cannot be null.

Make std::string null. You can’t. Make std::vector null. You can’t. It’s one of the benefits of a value types.

That, alone, eliminates a whole class of bugs that’s JS has. Yes, there’s edge cases in C++ too. The edge cases are the common cases in JS in this regard and that’s why I class them differently. Really, every language can do everything, basically. But how easy is it, and how common is it?

Also, for the record, using an initialized variable will result in a warning or compilation error.

None of this is to say that C++ does not have other glaring problems that JS does not. But, in my experience, it’s slightly more difficult to create logic bugs in C++. I also have worked with PHP - similar situation to JS. Too footgunny that in practice the codebase is riddled with bugs that rarely manifest, but are there. Everything you do has, like, a dozen implications and edge cases you need to consider.

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

#518

Post by const_cast »

Capricorn2481 wrote: post #515
const_cast wrote: post #496

Earlier quoted context omitted.

It's definitely a feature when you're starting out. But as the codebase grows and ages, it becomes a bug. The problem is that the behavior becomes so complex and so much is pushed to runtime that there's no way to know what the code is actually doing. There's paths that are only going to be executed once a year, but you don't know which ones those are. Eventually, editing the code becomes very risky. At this particul…

> The problem is that the behavior becomes so complex and so much is pushed to runtime that there's no way to know what the code is actually doing. There's paths that are only going to be executed once a year, but you don't know which ones those are. Eventually, editing the code becomes very risky. It's clear you've worked on a really bad codebase, but this is totally different from what you were originally suggestin…

IMO jQuery is a symptom, not a cause. It’s the natural end-state of a stringly-typed “do whatever the fuck you want” attitude. You can create just as much spaghetti without jQuery, jQuery just lets you do it with less characters.

The horrors I’ve seen. Constructing a custom string based off of user input and then tacking on () and calling it as a function? We can do that? Apparently yes we can. The most cursed type of polymorphism where nothing makes sense and you’d have more success communing with the dead than deducing the control flow.

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

#519

Post by lmm »

SpaceNugget wrote: post #510
lmm wrote: post #507

Earlier quoted context omitted.

No, our backend serves all the queries that the frontend uses, but (in prod) only the queries that the frontend uses - we compile the queries at build time. When we want to add a new query we figure it out in dev (which allows non-compiled queries, but is not accessible for people outside the company), write it in the frontend, and it will be included in the next build of the backend. This is all pretty basic off the…

Yea so you have to add the compiled queries to your back-end to be able to get them on prod, which is what you came out swinging against with a somewhat strongly worded to level comment berating people who choose to not use graphql for having to deal with. Exactly what you just described doing is what the parent comment expected you were doing.

> Yea so you have to add the compiled queries to your back-end to be able to get them on prod, which is what you came out swinging against with a somewhat strongly worded to level comment berating people who choose to not use graphql for having to deal with.

What are you talking about?

The build process takes the queries the frontend wants to use, compiles them, and includes them in the backend build. There is no manual step, you don't even change a single line of code or config on the backend, much less write a new endpoint. As far as I'm aware this is the completely normal way to use graphql.

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

#520

Post by lmm »

solatic wrote: post #513
lmm wrote: post #507

Earlier quoted context omitted.

No, our backend serves all the queries that the frontend uses, but (in prod) only the queries that the frontend uses - we compile the queries at build time. When we want to add a new query we figure it out in dev (which allows non-compiled queries, but is not accessible for people outside the company), write it in the frontend, and it will be included in the next build of the backend. This is all pretty basic off the…

I think I finally understand your earlier comment in context: > You can write each endpoint by hand instead of using GraphQL, but it's like writing your own collection datatypes instead of just pulling in an existing library. Everyone else is "pulling in an existing library", they have names like Express and Kysely, and thinking that Apollo is the only library that deserves this designation is a bit of a head-scratch…

> If you take the time to invest in a proper REST API first, odds are the endpoint may already exist, and you may not need to wait for a new backend build; not investing in a custom endpoint for every frontend change unless real-world performance requirements actually dictate it. You get tooling that is more mature and easier to maintain as a result, makes it easier for Product to experiment (remember: not forcing a backend change for every frontend change)

If it's a giant system where your backend/frontend/product teams are separate, maybe - but even then, they can run any custom queries they want on non-prod instances, so it's easy to do internal testing, and always including backend deployment when you do a prod release is not a huge burden.

I still think there's never going to be an advantage to doing N+1 queries - there might be cases where the performance difference doesn't matter, but an endpoint that returns precisely what you want would always be better if you could get it for free. And you can't really set up "aggregating" endpoints ahead of time, unless you pre-emptively create all N*N possible combinations, and that's going to go against having a "clean" normalised set of REST endpoints. Just like in a database schema, there's value in having every individual endpoint orthogonal and then doing the joining at query time, at least for a system under active development where you want to try new things without redoing your whole dataflow.

> not using a fad-of-the-month just because it came out of a FAANG.

I don't think it's a fad at this point - graphQL has been around for 10 years, the systems I've worked on have been using it successfully for about 5, and the design is built on what the likes of Thrift and gRPC were already doing where possible. There are, as you pointed out, multiple library implementations for many languages. It's popular because it works.

Post reply on HN