> Junior devs losing their minds over why useEffect runs twice
Oh now now, even senior devs do this too :)
Please just try HTMX
111–120 of 530 posts
Re: Please just try HTMX
#112The proselyting over frameworks is the worst bit of the web ecosystem. If your solution is actually good, it will get adopted eventually... Forget React, there's still stuff written in jQuery and JSP. Why the rush to convert everything - you're not a missionary on a mission, just build your stuff in stuff you like? The attack on npm is ridiculous, when (apart from introducing a permanent vulnerability in the form of…
> If your solution is actually good, it will get adopted eventually...
This has never been more incorrect. The entire world of software is people using garbage solutions because the CTO is convinced Oracle/Microsoft/what ever new random software is the best thing since sliced bread. In no fashion has the best software solution ever been a factor.
Re: Please just try HTMX
#113Sorry, but it's a no from me. htmx is a great idea, but it's not necessary anymore. We're very close to invokers being baseline (and even that is just an extension of the "composedPath includes -> invoke" pattern), and that will take care of plenty of what htmx was designed to do. Between features like that, and web components, I'm very happy to stick with "plain HTML" (no frameworks; my web components do not draw fr…
> We're very close to invokers being baseline, and that will take care of plenty of what htmx was designed to do. From what I've seen, invokers without extra code are designed for client side interactivity (e.g. showing a modal), which is orthogonal to the (correct, IMO) use case of HTMX. You shouldn't use HTMX to turn every custom user interaction into a network round trip, you should use it instead of fetching JSON…
> You can add custom commands with invokes and custom JS, but at that point you're basically re-implementing HTMX yourself[...]
Exactly. So why use a library? If it's that simple, the suggestion is akin to using a library for a toggle, when a checkbox would do. Yes, there are reasons to do it, but no, it's not what I'm going to do most of the time.
ETA: sorry; I should have mentioned, I'm ignoring server stuff because it's not my use case. I don't hydrate code on a server and send it down to people. I just write HTML or let javascript compose it in the browser. Since I don't use frameworks, that's the way I've developed to be efficient. Since I can't speak to how useful htmx is for server-rendered stuff, I'm staying out of it. Just talking about what htmx can do for me, which is very little.
Re: Please just try HTMX
#114Earlier quoted context omitted.
> Frontend and backend must agree on every scenario When is this not the case?
When an API returns JSON, your JS framework can decide what to do with it. If its returning HTML that's intended to go in a particular place on a page, the front-end has far less flexibility and pretty much has to put it in a specific place. Hence why they said endpoints can return 3-5 different versions of HTML.
> When an API returns JSON, your JS framework can decide what to do with it.
The JS framework is the frontend, so you're still coordinating.
> If its returning HTML that's intended to go in a particular place on a page, the front-end has far less flexibility and pretty much has to put it in a specific place.
Well yes, because presumably that's what the app is supposed to do. If it's not supposed to put it in that place, why would that be the specified target?
If this kind of static assignment of targets is not flexible enough for some reason, then use OOB updates which lets you replace fragments by id attribute. That lets you decouple some of these kinds of decisions.
Although "endpoints can return 3-5 different versions of HTML" is also a bit of a red flag that you're not using htmx correctly, generally endpoints should be returning 1, maybe 2 fragments in unusual cases.
In any case, you might find DataStar more to your liking, it's partway between React and htmx.
Re: Please just try HTMX
#115> "I'm not a fucking saint" You're not a fucking person, this is LLM output. It starts with the overdone sweary thing then mentions it's overdone and says it's not gonna do it, and it's almost enough to make me think the article is going to offer someone's point of view. But once again the LLM has erased any point of view the author may have had going in (or prevented them from developing it) and replaced it with a m…
I don't think this is straight LLM, it's probably an homage to a line of websites like https://thebestmotherfucking.website
For sure the author had an idea and went to the LLM to produce the post. And I'm aware of those prior sites (some of which are linked at the bottom.)
I mean nothing is straight LLM, you must prompt them and people are putting their ideas in and linking to other sources and getting stuff like this out. And hopefully editing or iterating, but not enough it would seem most of the time.
I'm saying their perspective doesn't shine through the crap and I'm sick of reading mediocre infodumps from LLMs.
Re: Please just try HTMX
#116Earlier quoted context omitted.
> you can just use the heavier one for everything Because people don't like using heavyweight solutions needlessly. That's the logic that begat C++ and Ada and Multics and ASN.1 and CORBA. All of which were good solutions useful for "everything" in their domain. But people hate them, mostly. Historically big "everything" solutuions end up losing in the market to lighter weight paradigms with more agility and flexibil…
The thing is most of us have jobs where we can't unilaterally switch to the 'cooler' solution, and I value my own context-switching overhead much more than I value a slightly smaller bundle or dep tree. I'll much sooner optimize the former than the latter and so the general purpose solution that will solve both my own projects and the work ones typically wins.
> most of us have jobs where we can't unilaterally switch to the 'cooler' solution
Which is exactly why the uncool solutions persist in the market. They're useful and practical! If they weren't they never would have been successful at all. I'm just saying that that this is fundamentally the logic of the frumpy old curmudgeon, and the kids will always have something better to offer along with their confusing new ideas.
And to be clear, I'm also just saying that as someone looking in from the outside (I do firmware!) the front end webdev developer onboarding story has long since jumped the complexity shark and things are quite frankly an impenetrable disaster ripe for disruption.
Re: Please just try HTMX
#117I did. My startup did. And now we’re going to rip it all out and move to a React front-end. HTMX makes response handling much more complex. Every endpoint returns 3–5 different HTML fragments. Frontend and backend must agree on every scenario — success, validation errors, system errors, partial updates, full reloads. And HTMX is still a fairly obscure library. The documentation and examples are lacking, there isn’t a…
It's terrible, why would I want my endpoints to return random HTML fragments? I realize thats how you did it in the JQuery times, but I was never in those - at that time we simply had template engines in the backend so this HTML slop wouldn't contaminate everywhere.. Most of the frontend stuff I do is for internal pages on embedded devices, and I'm very happy with a structure where I have the frontend being a full Re…
The HTML fragments aren't random.
Re: Please just try HTMX
#118Earlier quoted context omitted.
Right, it's also bothered me that the Vue docs spend so much time showing how it's a "progressive" framework. "Just use it for one component!" And show examples of how it can be lazy loaded in for your special complex spot that needs vue. Like c'mon, if I'm using Vue, I'm using Vue. Same for React. Strap me into the native state management solution for your framework, your router, your preconfigured bundler. I'm not…
Not having to deal with npm and a build step can remove a huge barrier to adoption for a large number of potential adopters, or people that just want some lightweight interactivity in an app.
Yep, can confirm. I first used Vue in 2016 to write some simple calculators for my group's use in Eve Online. Without its "progressive" affordances, I don't think I would have gotten anything off the ground. I had no idea how to set up a build pipeline at that point, and I think Vue was new enough that there weren't many vue-specific tutorials so I'd have been learning from React tutorials and trying to figure out what to change with zero JS background.
Re: Please just try HTMX
#119Earlier quoted context omitted.
To put a bit more colour on this, I think the fear of most devs with an ultra-simple framework like this is that eventually you hit a wall where you need it to do something it doesn't natively do, and because the only thing you know is these magical declarative hx-whatever attributes, there's no way forward. I appreciate the basic demos, but I think what would really sell me is showing the extensibility story. Show m…
What I don’t get is why I’d use it if I can’t write a reasonable complex SPA with it. React is easy for small websites so why would I use a separate framework when I can use one framework for everything?
I recently tried a hello-world in react. It made ten network requests on page load and probably had a sizable first download. That’s why web pages are so slow today.
Re: Please just try HTMX
#120Hey, I created htmx and while I appreciate the publicity, I’m not a huge fan of these types of hyperbolic articles. There are lots of different ways to build web apps with their own strengths and weaknesses. I try to assess htmx’s strengths and weaknesses here: https://htmx.org/essays/when-to-use-hypermedia/ Also, please try unpoly: https://unpoly.com/ It’s another excellent hypermedia oriented library Edit: the arti…
fwiw I'm the CEO of htmx, and I am a huge fan of these types of hyperbolic articles.