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

61–70 of 875 posts

Re: Htmx Is the Future

#61

Post by RHSeeger »

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…

> We moved away for MPAs because they were bloated, slow and difficult to work with. SPAs have definitely become what they sought to replace.

Plus we now get the benefit of people trying to "replace" built in browser functionality with custom code, either

The SPA broke it... Back button broken and a buggy custom implementation is there instead? Check.

or

They're changing things because they're already so far from default browser behavior, why not? ... Scrolling broken or janky because the developer decided it would be cool to replace it? Check.

There is a time and place for SPA (mail is a great example). But using them in places where the page reload would load in completely new content for most of the page anyways? That's paying a large cost for no practical benefit; and your users are paying some of that cost.

Re: Htmx Is the Future

#62

Post by politician »

obpe wrote: post #21
pphysch wrote: post #18

Earlier quoted context omitted.

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 have never heard this before. Can you elaborate on the differences? What do you validate on the client side that you don't on the server and vice versa?

Client side validations predominately drive user experiences.

Server side validations predominately enforce business constraints.

If you mix the concerns, either your UX suffers (latency) or the data suffers (consistency, correctness).

Re: Htmx Is the Future

#63

Post by nagyf »

obpe wrote: post #21
pphysch wrote: post #18

Earlier quoted context omitted.

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 have never heard this before. Can you elaborate on the differences? What do you validate on the client side that you don't on the server and vice versa?

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 validation for UX. The regular users needs to know if they messed up someting in the form. Also it's a much better UX if it's done on the client side, without the need to send an async request for validations.

Re: Htmx Is the Future

#64

Post by pictur »

infamia wrote: post #50
pictur wrote: post #24

If your project consists of a todo list, these tools will do the trick. but they are useless for projects with larger and more complex needs. and yes, there may be cases where it doesn't work in frameworks like nextjs and you need to apply hacky solutions. but I don't see even libraries like nextjs being so self-praising. Come on, folks, there's no point in praising a small package that can do some operations through…

You can always incrementally add dynamic features using web components when HTMX and similar things aren't a good fit. It doesn't have to be either HTMX or JS-first frameworks. Our industry's fixed mindset of JS/React vs. Hypermedia (e.g., HTMX/Hotwire/Unpoly) needs to change.

I am not for or against anything. I don't live in a fantasy world like in the article. I want to talk about real world problems, not dreams.

Re: Htmx Is the Future

#65

Post by recursivedoubts »

benatkin wrote: post #48
recursivedoubts wrote: post #39

i am the creator of htmx, this is a great article that touches on a lot of the advantages of the hypermedia approach (two big ones: simplicity & it eliminates the two-codebase problem, which puts pressure on teams to adopt js on the backend even if it isn't the best server side option) hypermedia isn't ideal for everything[1], but it is an interesting & useful technology and libraries like htmx make it much more rele…

It doesn't feel like hypermedia to me. It just feels like a vue-like language that is an internal DSL for HTML instead of an external DSL for HTML like svelte and handlebars. Hypermedia advances would be microformats and RDF and the like. http://microformats.org/wiki/faqs-for-rdf

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, PATCH and DELETE available, which allows HTML to take advantage of the full range of HTTP actions

htmx is a completion of HTML as a hypermedia, this is its design goal

Re: Htmx Is the Future

#66

Post by jeremyjh »

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…

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

Re: Htmx Is the Future

#67

Post by iamsaitam »

"If you wish to use something other than JavaScript or TypeScript, you must traverse the treacherous road of transpilation." -- this is the crux of the article.

These kind of takes fall in the bullseye of "I don't want to program with Javascript". The subtext is all about this.

Perhaps.. maybe.. Htmx won't be the future because there are a lot of people that like programming in Javascript?

Re: Htmx Is the Future

#68

Post by jcpst »

pictur wrote: post #24

If your project consists of a todo list, these tools will do the trick. but they are useless for projects with larger and more complex needs. and yes, there may be cases where it doesn't work in frameworks like nextjs and you need to apply hacky solutions. but I don't see even libraries like nextjs being so self-praising. Come on, folks, there's no point in praising a small package that can do some operations through…

I don’t understand how it’s inevitable that projects using this package will become garbage when the codebase grows. It looks like reasonable patterns could be built around it. Am I missing something?

Re: Htmx Is the Future

#69

Post by recursivedoubts »

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)
Post reply on HN