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

371–380 of 875 posts

Re: Htmx Is the Future

#371

Post by ChikkaChiChi »

brushfoot wrote: post #10

I use tech like HTMX because, as a team of one, I have no other choice. I tried using Angular in 2019, and it nearly sank me. The dependency graph was so convoluted that updates were basically impossible. Having a separate API meant that I had to write everything twice. My productivity plummeted. After that experience, I realized that what works for a front-end team may not work for me, and I went back to MPAs with J…

I've felt the same way and it's good to hear I'm not alone. I feel like log4j should have been enough of a jolt to push back on dependency hell enough that devs would start writing directly against codebases they can trace and understand. Maybe this is just a byproduct of larger teams not having to do their own DevOps.

Re: Htmx Is the Future

#372

Post by duxup »

pengaru wrote: post #201
duxup wrote: post #11

Earlier quoted context omitted.

I often work on an old ColdFusion application. It's amusing that for a long time the response was "oh man that sounds terrible". Now it is "oh hey that's server side rendered ... is it a new framework?". The cycle continues. I end up writing all sorts of things and there are times when I'm working on one and think "this would be better as Y" and then on Y "oh man this should be Z". There are days where I just opt for…

> there are times when I'm working on one and think "this would be better as Y" and then on Y "oh man this should be Z". How much of that is just a garden variety "grass is always greener on the other side" effect? > the important thing is to do the thing thoughtfully. And finish! Total losses are still total losses no matter how thoughtfully done.

>How much of that is just a garden variety "grass is always greener on the other side" effect?

In my example not so much. I'm working in a number of frameworks, use them regularly, sometimes ColdFusion is just faster / better suited, sometimes some other system.

Re: Htmx Is the Future

#373

Post by foul »

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…

That demonstration as per OP is dumb or targeted to React-ists. You can, with HTMX, do the classic AJAX submit with offline validation.

In the last years, for every layer of web development, what I saw was that a big smelly pile of problems with bad websites and webapps, be it MPA or SPA, was not a matter of bad developers on the product, but more a problem of bad, sometimes plain evil, developers on systems sold to developers to build their product upon. Boilerplate for apps, themes, ready-made app templates are largely garbage, bloat, and prone to supply chain attacks of any sort.

Re: Htmx Is the Future

#374

Post by BiteCode_dev »

courgette wrote: post #347
BiteCode_dev wrote: post #93

Earlier quoted context omitted.

Django comes with a lot: auth, caching, csrf protection, an orm, the admin, form workflow, templating, migrations, i18n, and yet doesn't come with thousands of deps.

I maintains a side project in Django since 5+ years now. The scope has been reduce to almost nothing. I have spend like 20h on it in 2022. But it still being used. Django helps by how boring and solid it feels. A similar project in node would probably not build anymore

I know of a 15 years django project that runs on 2.7 that is still making money. It got reinstalled this month on brand new Ubuntu servers out of a rubbish requirements.txt, and it worked.

So much for saying python packaging sucks.

Re: Htmx Is the Future

#375

Post by jmull »

> HTMX is the Future

I'm not seeing it. SPAs can be overly complex and have other issues, but I'm not seeing HTMX as a particular improvement.

Also, a bunch of this article doesn't make sense to me.

E.g, one of the listed costs of SPAs is managing state on the client and server... but (1) you don't have to -- isn't it rather common to keep your app server stateless? -- and (2) HTMX certainly allows for client-side and server-side state, so I'm not sure how it's improving things. That is, if you want to carefully manage app state, you're going to need a mechanism to do that, and HTMX isn't going to help you.

It also doesn't somehow prevent a rats nest of tooling or dependencies. It isn't an application framework, so this all depends on how to solve that.

SPA's also aren't inherently "very easy to make [...] incorrectly".

Also, the suggested HTMX approach to no browser-side javascript is very crappy. Your app would have to be very specifically designed to not be utterly horrible w/o JS with such an approach and instead be just pretty horrible. There are just so much more straightforward ways to make apps that work well without JS. Also, this isn't exactly a mainstream requirement in my experience.

I could go on and on. "caching" - htmx doesn't address the hard part caching. "seo-friendliness" - Like all the benefits here attributed to htmx, htmx doesn't particularly help with this and there are many other available way to achieve it.

IDK. These kinds of over-promising hyped up articles give me the feeling the thing being hyped up probably doesn't have a lot of real merit to be explored or else they'd talk about that instead. It also feels dishonest to me, or at least incompetent, so make all of these claims and assertions that aren't really true or aren't really especially a benefit of htmx vs many numerous other options.

Re: Htmx Is the Future

#376

Post by berkes »

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…

Even worse: Client-side validation and server-side validation (and database integrity validation) are all their own domains! I call all of these "domain logic" or domain validation just to be sure.

Yes, they overlap. Sure, you'll need some repetition and maybe, indeed, some DSL or tooling to share some of the overlapping ones across the boundaries.

But no! They are not the same. A "this email is already in use" is serverside, (it depends on the case). A "this doesn't look like an email-address, did you mean gmail.com instead of gamil.com" is client side and a "unique-key-constraint: contactemail already used" is even more down.

My point is, that the more you sit down (with customers! domain experts!) and talk or think all this through, the less it's a technical problem that has to be solved with DSLs, SPAs, MPAs or "same language for backend and UI". And the more you (I) realize it really often hardly matters.

You quite probably don't even need that email-uniqueness validation at all. In any layer. If you just care to speak to the business.

Re: Htmx Is the Future

#377

Post by alethiophile »

kbenson wrote: post #238
jfvinueza wrote: post #225

Earlier quoted context omitted.

Mail is not a good example. Why would you like to read a collection of documents through A Single Page interface? Gmail was a fantastic improvement over Hotmail and Yahoo, and it provided UX innovations we still haven't caught up with, yes, but MPAs are naturally more suited for reading and composing them. Overriding perfectly clear HTML structure with javascript should be reserved for web experiences that are not do…

Mail is good for a SPA because the main central view which shows the different items (emails) to view or take an action on is based on a resource intensive back-end request, so keeping that state present and not having to refresh it on many of the different navigation actions yields a tremendous benefit. You could do some client side caching with local page data, but just keeping it present and requesting updates to…

What exactly is the resource-intensive request here? Loading an E-mail, or list of E-mails? I don't see why that should be any more resource-intensive than any other CRUD app.

Re: Htmx Is the Future

#378

Post by Dylan16807 »

zamadatix wrote: post #72
pphysch wrote: post #55

Earlier quoted context omitted.

You misunderstand: the server only cares if your password is valid (boolean), not if it is "almost valid (0.7 strength)".

I understand the argument I just disagree that having a separate "bool isPasswordValid()" and "float isPasswordValid()" (really probably something that returns what's not valid with the score) function is in any way simpler than a single function used on both sides. Sure, the server may not care about the strength level but if you need to write that calculation for the client side anyways then how are you saving any…

In this situation code for a good strength meter is going to be an order of magnitude or two more complicated than the boolean validity check. Porting 50x as much code to the server is significantly worse than having two versions or having one shared function and one non-shared function.

Re: Htmx Is the Future

#379

Post by robertoandred »

tkiolp4 wrote: post #367

Frontend developers don’t want to write HTML nor augmented HTML. They want to write code, and these days that means JS. Frontend developers want to make good money (like those backend developers or even infrastructure developers who are working with data, servers, and cool programming languages), hence they need to work with complex libraries/frameworks (if you just write HTM?, you don’t get to earn much money becaus…

Incorrect. You can't create a website without HTML. The term "frontend developer" exists because frontend is a complex mix of HTML, CSS, JS, browser functionality, screen sizes, accessibility requirements, privacy requirements, server interactions.

Backend devs just lampoon it because they assume it must be simple.

Re: Htmx Is the Future

#380

Post by robertoandred »

denton-scratch wrote: post #357

How's it not a SPA, if you're updating the DOM in JS without a full page reload? Sorry, I read a load of stuff about React, before I came to any explanation of HTMX. Turns out, it's loading fragments of HTML into the DOM (without reload), instead of loading fragments of JSON, converting them to HTML fragments client-side, and injecting the resulting HTML into the DOM (without reload). So I stopped reading there; perh…

SPAs work with complex, relevant, and unique URLs perfectly fine.
Post reply on HN