959 karma · joined September 19, 2022
But if HTMX is enough for your project, then your problem was picking the wrong tools from the get go. You didn’t even need react. They’re very different tools for very different kinds of UIs and frontend complexity.
The fact that you prioritize the vercel one and not the node native one proves what OP implies in my opinion.
So every year we get a new “new way” to do it. Like that xkcd… this time this is the standard that will work!
It's not 10 years yet, but we're pretty close to that.
Yes, time flies.
LOL
The simplicity and the power it brings is so good.
I’ve also used SolidStart for a project and it’s by far the best meta framework I’ve tried so far. Again, simplicity, power and extensibility.
If you like template like syntax and single file components the. Vue provides the same benefits, with a bigger ecosystem and better team behind it (non vercel backed, that’s a big advantage).
If you prefer JSX, performance, simplicity and integration with vanilla js then why not use Solid instead?
I’ve used svelte for a medium size project and ended up regretting it. (For the above reasons).
We're now using Solid for another project, and so far we're very happy with it.
Many React of the core devs work for Vercel, so they have to promote Next and anything that leads people towards their platform.
May I ask about the feedback you provided and they didn't include?
> The biggest issue I have with Tailwind is how it clutters the HTML
You're 100% clearly in the first group. Maybe I shouldn't have said "hate" in that group, just people that don't like it or see its benefits.
> Like Web Components
That's a nice solution, but in practice as of today and relatively speaking: nobody is using them.
> and Styled Components
Except the performance is a lot worse. And you still have to come up with names for every single div that needs a minimal one line style.
And both of these solutions end up with huge CSS files. Huge CSS files are worse than having larger HTML markup, because CSS is a blocking resource and HTML is not.
> I really value keeping HTML very short and readable by not mixing presentational styles directly in the markup
People used to say this about React, they preferred their HTML separate from their JavaScript, all nice and clean. I'm now 150% sure you're in the first group.
> Yes, I've read the docs but never tried it out, I don't hate it, but I can't understand why I would choose it over other options. The fact of having a million classes in the middle of plain HTML makes them both unreadable for me.
Alright, now you've recognized it.
> These two approaches allows me to not have to read presentational things in the middle of my html, and allow my html to be more clear and readable.
That's a non issue. There are extensions that will just hide classnames. You're just blending your mind looking for reasosn to justify your "I don't like it".
I promise the day you use it in a real life project where you're working with > 3 other people you will understand it's benefits, and how having "large class lists" is a non-issue and a totally acceptable trade off over the practical benefits it provides. Both on performance of the resulting CSS and maintainability over a large period of time. And think in the insane amount of discussions you'll avoid regarding if we're calling this div "styledDivWrapper" or "WraperContent" or "CardWrapper" or ".card__item--dark". Not an issue if you work alone, but when working with others this becomes a real annoyance that tailwind completely removes.
Tailwind is not for your, don't use it.
Tailwind is not for purists and architecture philosophers.
Tailwind is for pragmatic people, working on real life projects within teams where they have to ship and spend less time philosophizing on the purity and beauty of things.
There's those that never used it for more than 30 minutes, that just tried it out or just skimmed through the docs. Those are the people that hate it and prefer "vanilla CSS" or similar.
Then there's the people that actually used it for a real project, within a team with more than 1 single person. Those are the people that understand its value, accept its trade offs and love it.
I've seen a lot of people jump from the first group to the second group. I've seen almost none jump from the second to the first.
That's why Tailwind is so successful.
It might not be beautiful in the eye of the purist, but it's absolutely fantastic in the eye of the builder and pragmatic.
Even more, maybe it's not even the django adapter but the overal "assets" and frontend stuff integration in django which is somewhere between non-existent and 15 years outdated.
I can guarantee it works incredibly well with Laravel, Rails or Adonis.
This works perfectly fine for me, both in the Rails and the Adonis projects. In both cases using Vite. Sounds to me like a misconfiguration somewhere.
>Having to add custom code to for flash, their special form handling, and other Inertia specific parterns that only I really understood made it difficult for some collaborators. I don't remember the specific of the form handling either but from what I remember it would have been difficult to instrument client-side validation such as react-hook-form as well.
How's that "custom code" for flash worse than having to add custom code for routing, authentication, sessions, validation, etc?.
> It is annoying. They are pushing people towards Remix as well, which I have tried and prefer to avoid unless I absolutely must have SSR. But their docs for older versions are still around so you can stick to what you like.
Ha! bingo!... you're like half a year late on this. Remix is not the thing they push for anymore. It's having a "nap" they said. Now you're supposed to be using react router in "framework mode". This is exactly what we're talking about here.
> React Router is excellent.
When you compare it to Next, etc... yes, I agree. The issue I have is the constant change of mind their devs have regarding how to do things, even when they say "it's stable"... it's not... every day they come up with "a better way" to do things which usually is not better, just different.
But using it when you already have django/rails/laravel/adonis means you have to do a ton more work and reinvent a lot of things (such as authentication, validation, etc).
Care to extend on what problems you found or what you didn't like about inertia?
I've never used it with Django (there's an adapter here https://github.com/inertiajs/inertia-django) but I did use it a lot with AdonisJS and Rails.
It's wonderful. The best of both worlds. TL;DR you can use React/Vue as your "template" layer and keep everything in your batteries included backend framework of choice, avoiding all the bull**t and madness going on with Next, Remix, React Router, etc, etc...
:facepalm:
Tell me you're a backend developer with little to no experience on this stuff without telling me you're a backend developer.
This approach doesn't work if you need to SSR any of the content of those components.
This is also a terrible solution UX wise. Your users will see some content and after some time (more or less noticeable, depending on resources, network conditions, etc) the rest of the components start to pop up, cause layout shifts and overal jankiness.
You either use and embrace one of these frontend frameworks or you don't and do progressive enhancement using HotWire, Alpine, Unpoly, Livewire or whatever.
The sprinkling of components is the worst of both worlds.
I’ve used it in a largeish project and I liked it a lot.
I rally hope I never have to deal again with redux or sagas
It's just a thin layer of glue between your frontend (React, Vue, etc) and a real batteries included fullstack framework such as Laravel/Rails/Adonis.