0xblinq

+1

We're also using Inertia in a pretty large project and we're super happy with it.

I think you're actually agreeing with me :-). Just extending my take to all of Rails, which I think it makes sense too.

Yeah, Inertia is great. We're supper happy with it. It simplified a lot of things and makes us feel we're building something robust and maintainable.

+1

Backend devs doing "just simple rails views" only works when those views are really simple, and mostly for internal tools. Otherwise it becomes a total nightmare to maintain.

I agree the "popular" JavaScript solutions are a complexity, over engineering and maintenance nightmare (I'm talking about Next.js mostly here).

But if you use somethink like Inertia, which TL;DR basically just makes React (or Vue) a templating library for your backend framework, it becomes super simple and easy to maintain. I find Inertia great because it's the perfect bridge that can make both backend and frontend devs happy, as it gives you the best of both worlds.

Hotwire is great, but you do need to invest into its way of doing things, and believe me... backend devs who hate on JS doing frontends leads to disaster in the same way JS devs hating on PHP/Ruby/Etc doing backend also leads to disaster.

Last year we replaced Hotwire in a medium size Rails app with Inertia because even if it was quite fast to build new features with, it became a total nightmare to maintain. Simple things such as a modal were split in 4 or 5 different files... some logic was in controllers, other in templates, then the stimulus controller for this and that, and the frames, and... nobody knew what to change.

The problem with Hotwire is that you need to be super "creative" with your solutions and take decisions like should I use a stimulus controller, a frame, a stream? or what? at every single step, and a single functionality ends up split in multiple different places. While with React or Vue it would be just a single component with an isOpen=true/false and done.

I insist... if you look at the "modern frontend" situation thinking on Next.js, Redux, css-in-js, etc... yes... it's a f*ng over engineering marketing hype bullshit hell.

But React/Vue on their own do provide some real benefits and real solutions to actual problems.

I think inertia brings to backend frameworks all the benefits of these tools, with minimal (and worth it, in my opinion) trade offs.

If you end up using Hotwire, just be careful and be warned... it's very likely to become a mess sooner, especially if used by JS haters.

horrible

I find the combination of a component framework such as React with a fully fledged backend such as Laravel or Rails with Inertia.js is perfect. The best of both worlds.

All this server side components is just over engineering no one needs, and even if you think you need it the complexity and vendor lock in introduced is not a trade off worth to do in my opinion.

This.

HTMX is in NO way a replacement for frontend libraries. If you can achieve what you wanted to do with HTMX you didn’t need any frontend framework to start with.

Also, repeating this again… the hype and the marketing from HTMX is something I never thought I would see, it’s worse than vercel’s

The “just use js and HTML” doesn’t work for anything but trivial projects.

Not using a framework leads to either spaghetti code, or reinventing your own undocumented, untested, unproven framework.

I think all this RSC is a big fuck up.

A feature nobody needed that breaks the ecosystem and introduces huge amounts of complexity.

It hurts to see.

I think you are confusing a productive language with a productive ecosystem.

Using typescript and next maybe you are super productive writing code, but in the big scheme of things you are not productive if you have to reinvent the wheel and write your own framework.

Neither Next nor typescript will give you an integrated solution for translations, background jobs, schedules, validation, ORM, queues, file uploads, authentication, authorization, etc.

Granted, you’re super fast writing typescript but we are not talking about the same kind of productivity I think.

To make it worse, there are like 10 half assed frameworks claiming to be the “rails” of node.

Not a single one of those provide even a way to do translations, run a background job and most don’t even provide an ORM or a way to validate input.

It’s a freaking joke.

Laravel + Hotwire if working alone or with a small team. Laravel + Inertia if working on a large team or with dedicated backend and frontend teams.

I’ve moved to use Laravel + Inertia (with react) and I’m so glad I did.

In those cases you use alpine, and do the interactivity on the client side.

> Every interaction in a livewire type system requires a round trip

You’re wrong on this. You’d use Alpine and do the interactivity client side. If you don’t miss use the tool, Livewire is supposed to reach to the server in the same situations an SPA would reach to the server (updating or refreshing server state)

Nothing is great for everything.

What would be the engineers doing otherwise? You get bored if you don’t.

This. I love php, and especially Laravel. But the Wordpress community continues in the Stone Age of the development practices.

People just look for ways to justify their already taken decisions.

> fronted dev can work with their favourite patterns and frameworks

And this is a big problem in my opinion. We should decide the stack that better solves the problem, and then hire people that are happy to work with that, not the other way around.

It's like saying you're in the business of putting screws into walls, but you do it always with hammers because most people like to use hammers.

Another day another JavaScript framework.

Also, to me at least, just because it’s able to execute code on the browser and on the server doesn’t mean “full stack”.

Let me know when it supports all the real stuff you need to build actual “full stack” applications.

Sorry, I don’t know anything about Asp.net.

My comment definitely applies to the other two options you listed.

And none of those combinations reach 5% of the features Rails provides. These answers are incomplete and hide the underlying problem: You have to tie together 10s of third party libraries or services, or alternatively reinvent the wheel and implement everything from scratch. That's the point.

It's either a cobbled together mess or reinventing the wheel (framework). There are not many more options.

Ha, that's the problem! Everyone will give you a different list of 143 packages (minimum).

Also, the list they gave you will be different next month.

In my experience codebases that do not age well tell more about the developers and the managers than the tech stack.

I've seen marvels and disasters in every stack.

asdf is awesome. It renders useless each language's own version manager.

Those frameworks (Remix, Next, etc) give you like 5% of what you get with Rails or Laravel. There’s no point of comparison.

I don't think that.

My last sentence on the parent message was directed to the comment I was replying to (which said they couldn't set up node properly).

What I do think is that there's a huge % of Rails devs that hate on JavaScript as if it were some kind of enemy to beat or something, and often that leads to people not wanting to learn it properly.