Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Htmx Is the Future

quii.dev

Post reply on HN
Print view View original

311–320 of 875 posts

Re: Htmx Is the Future

#311

Post by petepete »

ZephyrBlu wrote: post #206
emodendroket wrote: post #82

Earlier quoted context omitted.

I don't understand why that should be the case. There are a lot of checks that end up needing to be repeated twice with no change in logic (e.g., username length needs to be validated on both ends).

You shouldn't have to wait until you submit something to get feedback on it. It's poor UX. Frontend and backend validations are also different. Frontend is more about shape and type. Backend is content and constraints.

> It's poor UX.

It's not as easy as that. Showing validation while people are editing can be even worse, especially for less-technically able users or people using assistive technology.

Having an announcement tell you your password isn't sufficiently complex when you're typing in the second letter might not be bad for us, but how does that work for a screen reader?

Re: Htmx Is the Future

#312

Post by afavour »

robertoandred wrote: post #302
afavour wrote: post #181

Earlier quoted context omitted.

Right, so you agree: you have to reimplement it. You can just use a framework to do so. It might be news to folks to learn that every single SPA framework has solved the problem entirely because it's really not an uncommon experience to have your browser history broken by a SPA. I believe that most frameworks implement the API correctly. I also believe a good number of developers use the framework incorrectly.

That's like saying you have to reimplement assembly arithmetic, you can just use the Calculator app to do so. Bad websites are the results of bad developers, not the tool. You can have your history messed up by any kind of website.

No, it’s like saying you’ve been provided with a calculator but may, if you wish, create your own calculator with some parts provided. No guarantee it adds numbers together correctly.

Re: Htmx Is the Future

#313

Post by kitsunesoba »

obpe wrote: post #3

It's kinda funny to me that many of the "pros" of this approach are the exact reasons so many abandoned MPAs in the first place. For instance, a major selling point of Node was running JS on both the client and server so you can write the code once. It's a pretty shitty client experience if you have to do a network request for each and every validation of user input. Also, there was a push to move the shitty code fro…

> But that isn't because of the technology, it's because all the devs writing shitty MPAs are now writing shitty SPAs. If this becomes popular, they will start writing shitty MPAs again.

I think the root cause of this is lack of will/desire to spend time on the finer details, either on the part of management who wants it out the door the second it's technically functional or on the part of devs who completely lose interest the second that there's no "fun" work left.

Re: Htmx Is the Future

#314

Post by listenallyall »

themodelplumber wrote: post #285
listenallyall wrote: post #178

Earlier quoted context omitted.

HTMX is quite easy to code. Your prompt sounds rather generic, I mean, you can just serve 10 days of weather forecasts without any interaction whatsoever. https://www.wunderground.com/forecast/us/ak/north-pole It isn't clear what you were asking ChatGPT to provide, therefore not surprised it didn't come up with the exact answer you expected. I'd suggest learning HTMX by reading the docs, the majority is just a single…

ChatGPT made it very clear it understood exactly what I wanted, short of writing the code. The steps it offered were long, and far from generic. So. Why no code? It offers code for other langs all the time, even unprompted. It was like...if you've ever been mansplained before, when you know how to code something, but are asking a specific question that interests you, related to the process of having a service do that…

I don't really use ChatGPT but regardless, it seems strange to evaluate the merits of a JS library based upon ChatGPT's prowess with it. Your time would be far better spent, I think, by reviewing the docs yourself and building a basic site.

Re: Htmx Is the Future

#315

Post by hdjjhhvvhga »

PaulHoule wrote: post #179
obpe wrote: post #3

It's kinda funny to me that many of the "pros" of this approach are the exact reasons so many abandoned MPAs in the first place. For instance, a major selling point of Node was running JS on both the client and server so you can write the code once. It's a pretty shitty client experience if you have to do a network request for each and every validation of user input. Also, there was a push to move the shitty code fro…

I remember that all the web shops in my town that did Ruby on Rails sites efficiently felt they had to switch to Angular about the same time and they never regained their footing in the Angular age although it seems they can finally get things sorta kinda done with React. Client-side validation is used as an excuse for React but we were doing client-side validation in 1999 with plain ordinary Javascript. If the real…

> felt they had to switch to Angular about the same time and they never regained their footing in the Angular age

And in this case what actually happened is exactly what we had expected would happen: tons of badly-written Angular apps than need to be maintained for foreseeable future because at this point nobody wants to rewrite them so they become Frankensteins nobody wants to deal with.

Re: Htmx Is the Future

#316

Post by robertoandred »

afavour wrote: post #312
robertoandred wrote: post #302

Earlier quoted context omitted.

That's like saying you have to reimplement assembly arithmetic, you can just use the Calculator app to do so. Bad websites are the results of bad developers, not the tool. You can have your history messed up by any kind of website.

No, it’s like saying you’ve been provided with a calculator but may, if you wish, create your own calculator with some parts provided. No guarantee it adds numbers together correctly.

Why would anyone choose to create and use their own unreliable calculator instead of what came installed?

Re: Htmx Is the Future

#317

Post by doodlesdev »

No it's not. Honestly, the fact that this website displays like shit without JavaScript enabled is ironic considering it uses HTMX.

Please just use the damn full-stack JS frameworks, they make life simpler, just wait for WebAssembly to allow us to have full-stack Rust/Go/whatever frameworks, and then you can abandon JavaScript, otherwise you get the mess of websites like this one where the developer has not written JavaScript, but the website still needs it for me to be able to read a _damn blog post_.

Otherwise, stick with RoR, Django, Laravel, or whatever ticks your fancies, but HTMX just ain't for everyone and everything, it's supposed to be used for hypermedia, not for web apps or anything else, just that: hypermedia.

And no, JavaScript libraries aren't all "complicated" and "full of churn", React is. Stop using React, or otherwise accept the nature of its development, and stop complaining. There are hundreds of different JavaScript libraries and yet every single time I see people bashing on full stack JavaScript they just keep repeating "React" like it's the only library in the world and the only way developers have written code for the last decade.

Also, tangentially related, can we as an industry stop acting like kids and stop following these "trends"? The author talks about a "SPA-craze" but what I've been seeing more and more now is the contrary movement, however it's based on the same idea of a hype cycle, with developers adopting technology because it's cool or whatever and not really considering what are their actual needs and which tools will provide them with that.

Rant over.

Re: Htmx Is the Future

#318

Post by myth2018 »

v0idzer0 wrote: post #234
PaulHoule wrote: post #179

Earlier quoted context omitted.

I remember that all the web shops in my town that did Ruby on Rails sites efficiently felt they had to switch to Angular about the same time and they never regained their footing in the Angular age although it seems they can finally get things sorta kinda done with React. Client-side validation is used as an excuse for React but we were doing client-side validation in 1999 with plain ordinary Javascript. If the real…

It really wasnt about client side validation or UX at all. You can have great UX with an MPA or SPA. Although I do think it’s slightly easier in an SPA if you have a complex client like a customizable dashboard. Ultimately it’s about splitting your app into a server and client with a clear API bounday. Decoupling the client and server means they can be separate teams with clearly definied roles and responsibilities.…

> Decoupling the client and server means they can be separate teams with clearly definied roles and responsibilities

How desirable this is depends on the UI complexity.

Complex UIs as the ones built by google and facebook will most likely benefit from that.

Small shops building CRUD applications probably won't. On the contrary: the user requirements often cross-cut client and server-side code, and separating these in two teams adds communication overhead, at the best of the hypotheses.

Moreover, experience shows that such separation/specialization leads to bloated UIs in what would otherwise be simple applications -- too many solutions looking for problems in the client-side space.

Re: Htmx Is the Future

#319

Post by wahnfrieden »

PaulHoule wrote: post #277
v0idzer0 wrote: post #234

Earlier quoted context omitted.

It really wasnt about client side validation or UX at all. You can have great UX with an MPA or SPA. Although I do think it’s slightly easier in an SPA if you have a complex client like a customizable dashboard. Ultimately it’s about splitting your app into a server and client with a clear API bounday. Decoupling the client and server means they can be separate teams with clearly definied roles and responsibilities.…

Ouch! I’ve worked in two kinds of organizations. In one of them when there is a ‘small’ ticket from the viewpoint of management, one programmer is responsible for implementation but might get some help from a specialist (DBA, CSS god, …) In the other a small ticket gets partitioned to two, three or more sub teams and productivity is usually reduced by a factor more than the concurrency you might get because of overhe…

Speaks some truth to Graber's Bullshit Jobs thesis

Re: Htmx Is the Future

#320

Post by loxs »

Am I the only one who actually thinks that a SPA is simpler than server rendered UI? I always go for a SPA when I can sacrifice indexability and never seem to regret it.
Post reply on HN