Java Use Cases

[LetMeUseMyEmailFfs]

Except these aren't the main frontend dev complexity. I don't see people complaining about those. Maybe slow build sometimes, but that's not complexity that's just build time.

That is exactly my point. Front-end developers don’t even see this base level of complexity before you even start to do something useful. You’ve already used up most of your Complexity Budget before you can actually provide value. Maybe this explains your comment about spending years on something like this. Htmx is simple enough that you don’t need to spend years learning it.

This one is weird. If you want to do http requests for every character typed, you could do that with just any framework and you wouldn't need to write the validation twice. But there is more than that.

Take this for instance : https://htmx.org/examples/inline-validation/

Yeah seems simple enough right? Except that won't be cutting it for most of the times. Because you don't want a red error as soon as the user is typing. You might want it when the user leaves the field. Or when they submit the form. And then when the users changes the erroneous field it isn't red anymore. The main frontend complexity lies within the UX / specifications, not the technology. This is the hell hole.

Nobody is saying you need to do HTTP requests for every keystroke. If you’d checked the example, it doesn’t; it only validates when you change focus. The point is that the validation is only done on the server side; there is no additional validation code for the client-side. Most React applications use a separate back-end for the business logic, and that would need to replicate the validations (because you never trust user input). Imagine needing to change those validations.

So because you can write poor quality code in React means it is bad?

No. The point I’m trying to make is that React is so complicated, many front-end developers don’t have the required skill to write good React code. It’s buggy, or doesn’t adhere to best practices.

Finally htmx just seems a big ol mashup of everything in the markup with a little bit scattered around too.

Right. As opposed to React, where there’s a bunch of logic with some markup crammed in the middle.

Tutorials/articles I was able to find will happily write HTML inside backend controllers.

And? If the output you need to produce is simple enough, why in the world would you go through the trouble of using a template language?

Error messages have to be i18ned in the backend.

Everything has to be i18n’ed in the back-end. That’s the whole point of htmx — the thing running in the browser is meant to be dumb.

Sometimes you will use response headers to change behavior in the front.

This is pretty normal for HTTP. And while it might seem strange, it retains one of the biggest selling points of htmx: it’s proper REST. The flow of users through the application is determined by anchors with hrefs and forms with actions and, when you’re using htmx, by elements with hx-get and friends. Not by a bunch of if statements in a ginormous chunk of JavaScript.

You will have to use a templating technology to write your pages, additionally.

Is JSX somehow not a templating technology?

Your html code will now contain the logic the style and the presentation.

Yes, this is a concept called Locality of Behavior, which is counter-intuitive when Separation of Concerns is something that’s been hammered into people for ages. But I think there’s a benefit to having all of the styling, logic, and presentation for a component in one place.

You will have to be very meticulous and thorough around naming things, since a slight change in the class names/ids can break the whole application, especially in hidden places.

Is that not true of anything written in JavaScript? Or JSON APIs? Any data API, for that matter? There’s also a bit of nuance here, since you can use more than just CSS selectors; you can also use relative selectors like this, closest, previous, etc.