Hacker News Reader

Hacker News

Comment by fastball | Hacker News Reader

Full thread

fastball

For similar-goal prior-art, see Unpoly[1].

Also the IETF asks[2] that you please stop using "X-" to prepend your custom HTTP headers[3]

[1] https://unpoly.com/tutorial [2] https://tools.ietf.org/html/rfc6648 [3] https://htmx.org/reference/#headers

View on HN

Off topic, but that's a shame about them recommending not to prefix X- for custom headers.

Their entire reason (Appendix B) is that "well, if the header eventually becomes a standard header, then there will be old apps that will only work with X-, and we'll have to keep the X- version around forever!" That seems like a very weak reason to me. Most custom headers are not going to become standard headers, and those that do, well, apps can update nowadays and we deprecate old web features all the time.

I see a lot of value in distinguishing non-standard headers as a matter of principle. Also, there's a little bit of classic charm to X-, it's almost a shibboleth of HTTP. Removing it feels as wrong to me as removing the :// from the URI protocol and saying "we really just need :/"

I agree there. Browsers started to have this issue to, but to fix it they actually got more aggressive about deprecating prefixed stuff. Now if you use -moz-foo, they guarantee that it will break at some point in the future.

The // means use network, while / means use local file, so I think we need both.

I like unpoly a lot, Henning is a perfect gentleman, but the first check in on intercooler.js was before the first check in on unpoly:

https://github.com/bigskysoftware/intercooler-js/graphs/cont...

https://github.com/unpoly/unpoly/graphs/contributors

I'm happy to change the headers htmx is young enough to get away with it. Would you like to issue a pull request?

Fair point – though some might say if you start over in a new repo then you have reset the clock ;). In all honestly though, wasn't trying to imply that this project ripped off Unpoly or anything, just wanted to mention a similar project. Perhaps poor phrasing on my part.

As to a PR for the headers – I might just take you up on that!

it's all good, and please: if there is a better standard for me to follow, now is the time to implement it. You deserve the credit for bringing it to my attention, and the code base is pretty easy to navigate.

I read nothing but good intent in your comment, so this is not me throwing stones, but one comment I would make is that I think using the term "prior art" - coming as it does from patent law - carries an overtone of "I am implying that you might have ripped off someone else's idea".

It's clear that this is not what you intended, but I think from the response from the creator, that was the tone that you accidentally conveyed.

Just a thought for the future :-).

I'm not sure about changing the headers. X- is a widely accepted convention. In the RFC also says this:

> SHOULD NOT prefix their parameter names with "X-" or similar constructs.

It doesn't spell out exactly what would be considered a "similar construct", but I think "HX-" might count as a similar construct.

There's no good way to implement the feature you want that would satisfy all reasonable interpretations of that RFC, so switching to "HX-" would be a half-measure.

I understood exactly what was meant by X-HX- and I think it's a good design.

Still, HX- is shorter and about as intuitive as X-HX- so I think it might still be the way to go, even though IMO that RFC isn't a good enough reason to change it.

I think the spirit of the RFC is mostly about complications arising if such headers ever became standardized, but also that the "X-" just doesn't add any value – it's a convention without a purpose and just makes headers longer. In fact, it arguably becomes less useful the more people use it.

So I think it's better for new projects to drop the "X-".

On the other hand, I think it's reasonable to prepend with "HX-" because these headers apply to functionality that is specifically related to the capabilities of this library (or similar libs). It is highly improbable that this syntax would ever become standardized in either the HTML or HTTP specs, but if it did, the HX in front of headers makes sense given that the tag attributes are also prepended with an HX.

From an entirely stylistic perspective, I also think that shoving an "X-" in front of all your headers is ugly (ugliness can of course be justified by usefulness, but as stated above I don't think that applies here).

But of course these are just my thoughts on the matter, others might like "X-", though I'll admit I don't know why you would.

My upvote for Unpoly. Used it in severa projects and it's awesome. Only drawback I've found so far is that the source is CoffeScript, so it might be a bit harder to read the internals when necessary.

But In my opinion it gets a lot of things right, specially around form submissions, validation, error handling, modals, history, navigation, passive updates, etc. It is like Turbolinks++.

I love Unpoly!

But them using CoffeScript is the only reason for why I've not contributed to Unpoly even though I've found both bugs and stuff I'd like improved :/

fastball has submitted and I have accepted a fix for the headers issue

thank you!

Unpoly examples wrecked my back button. Had to click back like 15 times to get back to HN... Is this a permanent issue because of the way it’s implemented?

Pushing history state is the default, but it can be configured as needed on a case by case basis.

Just set up-history=false on your links

Reply on news.ycombinator.com