Htmx Is the Future • Hacker News Board

Re: Htmx Is the Future

#121

Post by 0cf8612b2e1e » Fri, May 05, 2023, 4:54 PM UTC

pier25 wrote: post #109

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 agree but one important point to consider is the dev effort of making a proper SPA which is not a very common occurrence. "The best SPA is better than the best MPA. The average SPA is worse than the average MPA." https://nolanlawson.com/2022/06/27/spas-theory-versus-practi...

Can we even weight that statement? The average SPA is significantly worse than the average MPA. There is so much browser functionality that needs to be replicated in a SPA that few teams have the resources or talent to do a decent job.

Re: Htmx Is the Future

#122

Post by yawaramin » Fri, May 05, 2023, 4:55 PM UTC

emodendroket wrote: post #83

nagyf wrote: post #63

Earlier quoted context omitted.

Everything has to be validated on the server side simply for security reasons. Even if you do all validation on the client side, which prevents the users submitting a form with invalid data, an attacker can work around that. e.g. submitting the form with valid data, but intercepting the request and modifying the values there. Or simply just using curl with malicious/invalid data. You still need the client side valida…

Yeah but that doesn't answer why you can't share validators between the backend and the frontend if both are written in the same language.

Because HTML form validation is a built-in native feature of HTML, and it's integrated in the browser:

Constantly reinventing the wheel in every app is silly.

Re: Htmx Is the Future

#123

Post by randomNumber7 » Fri, May 05, 2023, 4:55 PM UTC

danielvaughn wrote: post #94

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…

100%. Saying that [technology x] will remove complexity is like saying that you've designed a house that can't get messy. All houses can be messy, all houses can be clean. It depends on the inhabitants.

Yes, but some technologies make it easier (or harder) to keep everything clean.

Like in my opinion you can write clean code in C, but since you dont even have a string type it shepherds you into doing nasty stuff with char*... etc.

Re: Htmx Is the Future

#124

Post by recursivedoubts » Fri, May 05, 2023, 4:55 PM UTC

tomhallett wrote: post #118

recursivedoubts wrote: post #65

Earlier quoted context omitted.

it absolutely is hypermedia we generalize HTML's hypermedia controls in the following way: - any HTML element can become a hypermedia control - any event can drive a hypermedia interaction - any element can be the target of a hypermedia interaction (transclusion, a concept in hypermedia not implemented by HTML) all server interactions are done in terms of hypermedia, just like w/links and forms it also makes PUT, PAT…

have you seen any interest by the browsers to build htmx features as experimental browser features, with the goal of htmx features becoming browser standards? When looking at the various options, I always enjoyed your architectural choice of htmx being an extension of html, for that very reason. Similar to "phonegap" hoping that the phonegap code base would get smaller and smaller as mobile browsers built more of tho…

i haven't heard of any browsers implementing these features, but that's the right thing: they would be far more effectively implemented by the hypermedia client and it wouldn't be too much work technically

my sense is that HTML is constrained by social/organizational issues rather than technical ones at this point

hopefully someone on the chrome team notices htmx at some point and HTML starts making progress again

Re: Htmx Is the Future

#125

Post by adrr » Fri, May 05, 2023, 4:55 PM UTC

pphysch wrote: post #18

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…

Client side validation is for UX. Server side validation is for security, correctness, etc. They are different features that require different code. Blending the two is asking for bugs and vulnerabilities and unnecessary toil. The real reason that SPAs arose is user analytics.

I don't understand how spa is different than vanilla web app in terms of user analytics? A beacon is a beacon. Whether its img tag with a 1x1 transparent gif or an ajax call.

Also validation is usually built on both client and server for the same things. Like if you have a password complexity validation. Its both on UX and the server otherwise it will be a very terrible UX experience.

Re: Htmx Is the Future

#126

Post by jeremyjh » Fri, May 05, 2023, 4:55 PM UTC

mtlynch wrote: post #119

jeremyjh wrote: post #66

Earlier quoted context omitted.

Alpine is a lightweight client side framework, not really at all equivalent to htmx.

I'm not sure what you mean. htmx and alpine.js are both client-side frameworks. To me, they seem to have similar goals and similar functionality. What do you see as the difference?

The purpose of htmx is to enable the server to send fragments of markup to update the dom in response to UI events. Alpine.is is purely client side, you may not even have an application server.

Re: Htmx Is the Future

#127

Post by [deleted] » Fri, May 05, 2023, 4:55 PM UTC

pphysch wrote: post #111

blowski wrote: post #44

Earlier quoted context omitted.

> The real reason that SPAs arose is user analytics. Can you go into that a bit? I don't really understand what you mean.

HTML gives very limited tools for tracking what a (potentially JS-less) user is doing. There are various tricks, like "link shorteners" and "magic pixels" that allow some tracking. But if you want advanced tracking, like tracking what a user is focusing on at a particular instant, you need to wrap the whole document in a lot of JS. SPA frameworks came out of AdTech companies like Meta, and I assure you it wasn't beca…

[deleted]

Re: Htmx Is the Future

#128

Post by runlaszlorun » Fri, May 05, 2023, 4:56 PM UTC

tomca32 wrote: post #32

onion2k wrote: post #16

Earlier quoted context omitted.

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. Nothing about this technology will stop that. This is only sort of true. The problem can be mitigated to a large extent by frameworks; as the framework introduces more and more 'magic' the work that the developer has to do decreases, w…

Unfortunately, developers often write code in a framework they don't know well so they end up fighting the framework instead of using the niceties it provides. The end result being that the surface area of things that can go wrong actually increases.

True. But I also find that a lot of frameworks are narrowly optimized for solving specific problems, at the expense of generality, and those problems often aren’t the ones I have.

Supposedly declarative approaches especially are my pet peeve. “Tell it what you want done, not how you want it done” is nice sounding but generally disappointing when I soon need it to do something not envisioned by its creator yet solved in a line or two of general purpose/imperative code.

Re: Htmx Is the Future

#129

Post by mtlynch » Fri, May 05, 2023, 4:56 PM UTC

recursivedoubts wrote: post #69

mtlynch wrote: post #58

I really want to switch over to htmx, as I've moved away from SPAs frameworks, and I've been much happier. SPAs have so much abstraction, and modern, vanilla JavaScript is pretty decent to work with. The thing that keeps holding me back from htmx is that it breaks Content Security Policy (CSP), which means you lose an effective protection against XSS.[0] When I last asked the maintainer about this, the response was t…

htmx can work w/ a CSP, sans a few features (hx-on, event filters)

My understanding based on the docs[0] is that htmx works with CSP, but it also drastically weakens its protection, as attackers who successfully inject JS into htmx attributes gain code execution that CSP would have normally prevented.

Am I misunderstanding? If I can use htmx without sacrificing the benefits of CSP, I'd really love to use htmx.

[0] https://htmx.org/docs/#security

Re: Htmx Is the Future

#130

Post by dtagames » Fri, May 05, 2023, 4:56 PM UTC

pphysch wrote: post #111

blowski wrote: post #44

Earlier quoted context omitted.

> The real reason that SPAs arose is user analytics. Can you go into that a bit? I don't really understand what you mean.

HTML gives very limited tools for tracking what a (potentially JS-less) user is doing. There are various tricks, like "link shorteners" and "magic pixels" that allow some tracking. But if you want advanced tracking, like tracking what a user is focusing on at a particular instant, you need to wrap the whole document in a lot of JS. SPA frameworks came out of AdTech companies like Meta, and I assure you it wasn't beca…

This is not correct. SPAs and web components were pioneered by Google with the introduction of Angular. Later, Vue was invented by a previous Google employee who had worked on Angular. Finally, Facebook came up with React (it's a "reaction" to Angular) because they could not be seen using a Google product.

If anything, SPAs make metrics harder because they hide the real behavior of the page in local JS/TS code and don't surface as much or any information in the URL. Also, fewer server interactions means fewer opportunities to capture user behavior or affect it at the server level.