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

Htmx 1.0.0 Release

htmx.org

Post reply on HN
Print view View original

51–60 of 62 posts

Re: Htmx 1.0.0 Release

#51

Post by recursivedoubts »

midrus wrote: post #47

I find unpoly so much better and complete than this. Unpoly just has bad marketing.

That's fine, unpoly is a reasonable approach to building front end code, but it's a very different model.

htmx is focused on improving html qua html. It doesn't have any notion of the server side beyond that which html has: URLs. As such it is attempting to say within the original model of the web: a hypertext architecture with REST/HATEOAS as the bedrock.

It isn't a complete framework in the flavor of unpoly, and so it won't have the expressive power of unpoly in many cases. That's an intentional tradeoff based on the core motivating concept of the library.

Which is fine: different strokes for different folks.

Re: Htmx 1.0.0 Release

#52

Post by recursivedoubts »

bobthebuilders wrote: post #43

Apologies if I missed it, but how would authentication work? I'm trying to figure out where ok the scale from Spring Security to JWT and React it falls on.

Authentication works the normal way: you login via a login screen and that typically would establish a session cookie.

You can also use events to hook in CRSF tokens if you need to do so.

But it tries to use the original security model of the web as much as possible.

Re: Htmx 1.0.0 Release

#53

Post by recursivedoubts »

tarsinge wrote: post #46
no_wizard wrote: post #17

Earlier quoted context omitted.

Sure okay, the DSLs are different. So who’s the target audience? I’m curious to know the typical developer attracted to libraries like this. That is t saying it’s bad or anything. It’s different enough I have a genuine curiosity

In our agency augmented HTML (Htmx/Intercooler, AlpineJS, etc.) is very useful for web designers, they can go further with interactions and behaviors while staying in a HTML/CSS environment. Also it helps a lot in the communication between the design and developer teams, because there is a lot more understanding of what's going on.

That's great to hear and one of the big benefits to an HTML-first architecture: it's much easier to understand the entire stack, for feature development as well as optimization.

Thanks for mentioning it!

Re: Htmx 1.0.0 Release

#54

Post by recursivedoubts »

hrjet wrote: post #42
recursivedoubts wrote: post #6

I'm the creator of htmx, glad to see this make HN. Happy to answer questions.

htmx sounds great! I am interested in this from the security angle. If browsers were to natively support htmx (or something similarly declarative), it might reduce the need for Javascript and hence improve security.

It definitely helps improve your security complexity over things like, say, GraphQL, where row-level security is necessary to prevent people from firing off random queries from the browser console.

There are a couple of places in the code where eval()/Function code are fire off which require some security-thinking:

https://htmx.org/attributes/hx-trigger/

hx-trigger evaluate expressions for the event filter. This typically isn't an issue since you would be unlikely to use user input in this context.

https://htmx.org/attributes/hx-vars/

hx-vars evaluate expressions to include in the request. This is a bit more dangerous, because you might try to pass values through with this mechanism. If this includes user input then you should use hx-vals instead:

https://htmx.org/attributes/hx-vals/

Re: Htmx 1.0.0 Release

#55

Post by rasso »

This looks amazing! I never adopted any of the frameworks (vue, react, angular, ...) because I think they should only be used for web apps, but not for classic websites. JS for everything frontend-related in my opinion just has too many downsides for an open web (possibly bad SEO for crawlers that don't support javascript, reliance on the users device for rendering)

Htmx might be the perfect tool to stay with classic server-side rendering and still have the "pop" of SPAs.

Re: Htmx 1.0.0 Release

#56

Post by aecay »

err4nt wrote: post #3

> It's worth mentioning that, if you prefer, you can use the `data-` prefix when using htmx I don't know why people who make frameworks either prefer invalid HTML, or if they do allow people to write valid HTML they seem to show the invalid code in the docs You are not allowed to invent any old attributes you want and add them to any element and have it be valid HTML, but you can invent any attribute you want so long…

> If you want to stop polling from a server response you can respond with the HTTP response code 286 and the element will cancel the polling.

Oh wow, it gets a lot worse...

Re: Htmx 1.0.0 Release

#57

Post by err4nt »

wongarsu wrote: post #27
kzrdude wrote: post #15

Earlier quoted context omitted.

Using data- which is the niche made for this in the standard, seems to be the solution that's more likely to still work 15 years down the line.

The only real practical concern is that if you don't use data- you might use an attribute that will become meaningful to future browsers. But what are the chances of html gaining an attribute that starts with hx-?

When you camp on the platform namespace it ties the hands of standards bodies - we will not get in HTML for real because too many people already went ahead and did it. Same for , etc. Look up 'Smooshgate' for a similar example in JavaScript.

Our workflows should have us practice writing _valid_ code, which our tools can then take and transform into other _valid_ code. Any workflow where the humans practice doing the _invalid_ thing so the tool can magically fix it later is a bad idea IMO. Practice writing good code and use tools to make it even better!

Re: Htmx 1.0.0 Release

#58

Post by err4nt »

oconnore wrote: post #18
err4nt wrote: post #3

> It's worth mentioning that, if you prefer, you can use the `data-` prefix when using htmx I don't know why people who make frameworks either prefer invalid HTML, or if they do allow people to write valid HTML they seem to show the invalid code in the docs You are not allowed to invent any old attributes you want and add them to any element and have it be valid HTML, but you can invent any attribute you want so long…

There seems to be a bit of irony citing whatwg in your attempt at shaming here —- the standard that was created to be a living document tracking what web developers and browser creators were implementing in the real world. I’m not sure there is a good reason to require web authors to type an extra 5 character prefix every time they want to attach data to an element. This is supported by the fact that browsers can fig…

Those five letters are the difference between safe code and unsafe code. If you've used data-* you can rest assured your attributes will always be author-defined and not interfere with any future real attributes defined by HTML, whatever those may be.

But if you invent and use invalid attributes, any browser could do something with that, any day, for any reason, and it wouldn't be a bug - you're the one that would have chosen to build on top of undocumented and non-standard behaviour. Does that sound like a reasonable approach to you when the safe and future-proof approach is so clearly marked and cheap and easy to do?

Re: Htmx 1.0.0 Release

#59

Post by err4nt »

ezequiel-garzon wrote: post #9
err4nt wrote: post #3

> It's worth mentioning that, if you prefer, you can use the `data-` prefix when using htmx I don't know why people who make frameworks either prefer invalid HTML, or if they do allow people to write valid HTML they seem to show the invalid code in the docs You are not allowed to invent any old attributes you want and add them to any element and have it be valid HTML, but you can invent any attribute you want so long…

I don't know why people who make frameworks either prefer invalid HTML I’m guessing people do this to make it less likely to have a name conflict with a custom attribute used by another library.

The HTML spec mentions this:

    JavaScript libraries may use the custom data attributes, as they are considered to be part of the page on which they are used. Authors of libraries that are reused by many authors are encouraged to include their name in the attribute names, to reduce the risk of clashes. Where it makes sense, library authors are also encouraged to make the exact name used in the attribute names customizable, so that libraries whose authors unknowingly picked the same name can be used on the same page, and so that multiple versions of a particular library can be used on the same page even when those versions are not mutually compatible.
This is saying that if you have `data-thing`, then putting your own name in there is better, like `data-mylib-thing` to tell it apart from `data-yourlib-thing`, but the ultimate in flexibility and compatibility is if the end-user of your library can configure this part so they can safely tell `data-yourlib-v3-thing` apart from `data-yourlib-v4-thing` etc.

Re: Htmx 1.0.0 Release

#60

Post by err4nt »

tarsinge wrote: post #45
err4nt wrote: post #3

> It's worth mentioning that, if you prefer, you can use the `data-` prefix when using htmx I don't know why people who make frameworks either prefer invalid HTML, or if they do allow people to write valid HTML they seem to show the invalid code in the docs You are not allowed to invent any old attributes you want and add them to any element and have it be valid HTML, but you can invent any attribute you want so long…

Custom attributes are used since many years now and work on every browsers. Maybe the spec should be updated to reflect the usage.

Custom attributes (without data-*) are invalid HTML unless you're using them on a custom HTML element. If you're defining a custom element, you're responsible for defining what its attributes mean - outside of that, no they aren't allowed and yes they are unsafe to use, and restrict the standards bodies from being able to move forward freely without risking breaking the web because of invalid code in the wild.
Post reply on HN