4 ms·

How to you solve humanized time with htmx? Humanized time means, now, a second ago, 3 hours ago etc. When you create let's say a post and it's returned the re

How to you solve humanized time with htmx? Humanized time means, now, a second ago, 3 hours ago etc. When you create let's say a post and it's returned the rendered humanized time, every post you create will return "now" as its time. And next how to you keep track of the humanized time client side. Riddle me this and I'll start believing in htmx

naasking 3y ago
The server is aware of the client's local time.
- mamcx 3y ago
  Not only that, doing localization/parsing on server side is easier and is more secure.
- monomers 3y ago
  I think it doesn't need to be for relative time intervals like "1 min ago".
danpalmer 3y ago
Why does this need doing? Pages aren't kept open for that long, especially not when using HTMX and page loads happen more often. Saying "now" for the post you've just submitted isn't that useful, but neither is saying "1 minute ago" when you leave the page open for 1 minute. Humanisation of date times is easy to do server side, so the next time you render the page it will have newly correct timestamps. The vagueness of humanised times also reduces the need to update as they can be quite out of date and still look up to date.
uallo 3y ago
Web Components, e.g. https://github.com/github/relative-time-element https://github.com/github/relative-time-element
- jakswa 3y ago
  Came to upvote this. I think that github component in particular worked really well for me on a recent experiment. Server-rendered HTML can use custom components in our fancy world today! It's a feel-good place to be compared to just a decade ago imo.
- stmblast 3y ago
  TIL! I didn't know this even existed.
- aitchnyu 3y ago
  Do webcomponents apply css from their parent tags? Years back I found it a diva.
  - uallo 3y ago
    It depends on how you set it up. https://css-tricks.com/styling-a-web-component/ https://css-tricks.com/styling-a-web-component/
robertlagrant 3y ago
This is often one of the most annoying things about modern web pages. "About a year ago" on every post in a thread.
- 0cf8612b2e1e 3y ago
  Especially if they hide the original time so it is impossible for a user to pin down an exact date. Infuriating when exact date deltas matter.
stmblast 3y ago
It depends, but typically you wouldn't keep a page open long enough to be able to do this. If you were, you could probably use an SSE stream that maps to humanised time and then send an event every second. However, I'm not sure this is 100% optimal as it requires an update every second which is probably more overhead than you want.
davidjfelix 3y ago
Not really an htmx user or supporter but as an outside observer I think this can be accomplished but it might not be what you want -- which is okay. So, if I understand correctly, I think what you're saying is you "create a post" and the timestamp might have "now" listed as a humanized representation of it being just posted. When it reaches 1 minute, what you're saying is you'd like it to say "1 minute ago" etc. I think this is generally against the goals of htmx and the way you'd accomplish this is one of two ways: * Find a humanized representation that does not need constant updating * Use ordinary clientside javascript alongside htmx rendered data attributes to update the output. I don't think htmx aims to do loads of rerender cycle updates like this. I don't think that means its not a good library, just not a good fit for sites that need this. There are plenty of tools like django templates, rails templates, hugo sites etc that all act like this and require some hand-authored clientside js to handle updates. I think the goal of htmx is to require *as few as possible* without overtly adding js to clientside runtimes.
bccdee 3y ago
The point of htmx is to introduce more flexible tools for interacting with the server through html. Instead of being limited to forms which redirect you to a new page when you click submit, you can send requests and dynamically replace parts of the page on arbitrary events. You can use htmx to regularly send the server the current time and have it respond with an updated humanized timestamp, but that's not really what you want. You're looking for some client-side display sugar, which is not the type of problem htmx was designed to solve. You can just use a client-side javascript snippet. htmx complements js; it doesn't replace it.
tannhaeuser 3y ago
Don't know why this would be a problem with htmx in particular; I'd expect this to work like with every other site, by using moment.js and a JS timer event changing date text into a relative date/time. Not a good practice to send "now" or other indeterministic data as string in a server-rendered page anyway, and I wouldn't expect anyone to do it like that (well, except for fingerprinting or sth). Though I don't even know if it's possible to tunnel your own JS through hmtx pages after all tbh. If not, that would be a problem/a no go from my PoV as I see absolutely no reason to add (or subtract, for that matter) syntax constructs to/from HTML when SGML has plenty, and in fact can already describe adding or replacing fragments at a purely syntactical level without mixing in opinionated "semantics".
infecto 3y ago
Unsure why these kind of questions always pop up around HTMX. I do not think HTMX sets out to solve state problems. HTMX to me is an easy way for me to render HTML partials. If I needed to do something like update state such as your example, I would write javascript function inside of that html partial to update the time based on the posts timestamp...yes I am sure there is some complexity or issue around the clients, time and the posts timestamp I am handwaving that issue for the sake of the example.
recursivedoubts 3y ago
you use the server for that htmx does one thing: it generalizes hypermedia controls that's it

naasking 3y ago

The server is aware of the client's local time.

mamcx 3y ago
Not only that, doing localization/parsing on server side is easier and is more secure.
monomers 3y ago
I think it doesn't need to be for relative time intervals like "1 min ago".

danpalmer 3y ago

Why does this need doing? Pages aren't kept open for that long, especially not when using HTMX and page loads happen more often. Saying "now" for the post you've just submitted isn't that useful, but neither is saying "1 minute ago" when you leave the page open for 1 minute. Humanisation of date times is easy to do server side, so the next time you render the page it will have newly correct timestamps. The vagueness of humanised times also reduces the need to update as they can be quite out of date and still look up to date.

uallo 3y ago

Web Components, e.g. https://github.com/github/relative-time-element https://github.com/github/relative-time-element

jakswa 3y ago
Came to upvote this. I think that github component in particular worked really well for me on a recent experiment. Server-rendered HTML can use custom components in our fancy world today! It's a feel-good place to be compared to just a decade ago imo.
stmblast 3y ago
TIL! I didn't know this even existed.
aitchnyu 3y ago
Do webcomponents apply css from their parent tags? Years back I found it a diva.
- uallo 3y ago
  It depends on how you set it up. https://css-tricks.com/styling-a-web-component/ https://css-tricks.com/styling-a-web-component/

robertlagrant 3y ago

This is often one of the most annoying things about modern web pages. "About a year ago" on every post in a thread.

0cf8612b2e1e 3y ago
Especially if they hide the original time so it is impossible for a user to pin down an exact date. Infuriating when exact date deltas matter.

stmblast 3y ago

It depends, but typically you wouldn't keep a page open long enough to be able to do this. If you were, you could probably use an SSE stream that maps to humanised time and then send an event every second. However, I'm not sure this is 100% optimal as it requires an update every second which is probably more overhead than you want.

davidjfelix 3y ago

Not really an htmx user or supporter but as an outside observer I think this can be accomplished but it might not be what you want -- which is okay. So, if I understand correctly, I think what you're saying is you "create a post" and the timestamp might have "now" listed as a humanized representation of it being just posted. When it reaches 1 minute, what you're saying is you'd like it to say "1 minute ago" etc. I think this is generally against the goals of htmx and the way you'd accomplish this is one of two ways: * Find a humanized representation that does not need constant updating * Use ordinary clientside javascript alongside htmx rendered data attributes to update the output. I don't think htmx aims to do loads of rerender cycle updates like this. I don't think that means its not a good library, just not a good fit for sites that need this. There are plenty of tools like django templates, rails templates, hugo sites etc that all act like this and require some hand-authored clientside js to handle updates. I think the goal of htmx is to require *as few as possible* without overtly adding js to clientside runtimes.

bccdee 3y ago

The point of htmx is to introduce more flexible tools for interacting with the server through html. Instead of being limited to forms which redirect you to a new page when you click submit, you can send requests and dynamically replace parts of the page on arbitrary events. You can use htmx to regularly send the server the current time and have it respond with an updated humanized timestamp, but that's not really what you want. You're looking for some client-side display sugar, which is not the type of problem htmx was designed to solve. You can just use a client-side javascript snippet. htmx complements js; it doesn't replace it.

tannhaeuser 3y ago

Don't know why this would be a problem with htmx in particular; I'd expect this to work like with every other site, by using moment.js and a JS timer event changing date text into a relative date/time. Not a good practice to send "now" or other indeterministic data as string in a server-rendered page anyway, and I wouldn't expect anyone to do it like that (well, except for fingerprinting or sth). Though I don't even know if it's possible to tunnel your own JS through hmtx pages after all tbh. If not, that would be a problem/a no go from my PoV as I see absolutely no reason to add (or subtract, for that matter) syntax constructs to/from HTML when SGML has plenty, and in fact can already describe adding or replacing fragments at a purely syntactical level without mixing in opinionated "semantics".

infecto 3y ago

Unsure why these kind of questions always pop up around HTMX. I do not think HTMX sets out to solve state problems. HTMX to me is an easy way for me to render HTML partials. If I needed to do something like update state such as your example, I would write javascript function inside of that html partial to update the time based on the posts timestamp...yes I am sure there is some complexity or issue around the clients, time and the posts timestamp I am handwaving that issue for the sake of the example.

recursivedoubts 3y ago

you use the server for that htmx does one thing: it generalizes hypermedia controls that's it