4 ms·

When I write JavaScript, I make as many things immutable as I can. Sometimes it adds verbosity and leads to less efficient computational patterns, but overall

When I write JavaScript, I make as many things immutable as I can. Sometimes it adds verbosity and leads to less efficient computational patterns, but overall I believe I run into far fewer bugs that are hard to make sense of. There are things about the design of Temporal I don't really like, but immutability was a solid move. What I don't understand is why they had to make string formatting so rigid. Maybe it has to do with internationalization? I'd have liked if it included a sort of templating system to make the construction of rendered date-time strings much easier.

kandros 7mo ago
I remember the first time I got in touch with Elixir and immutability as a core principle. It changed the way I wrote JavaScript since
WorldMaker 7mo ago
> What I don't understand is why they had to make string formatting so rigid. Maybe it has to do with internationalization? I'd have liked if it included a sort of templating system to make the construction of rendered date-time strings much easier. I think Temporal takes the right approach: toString() is the (mostly) round-trippable ISO format (or close to it) and every other format is accessible by toLocaleString(). In Python terms, it is a bit like formally separating __repl__ and __str__ implementations, respectively. Date's toString() being locale-dependent made it a lot harder to round-trip Date in places like JSON documents if you forgot or missed toISOString(). Temporal's various toLocaleString() functions all take the same Intl.DateTimeFormat constructor parameters, especially its powerful options [1] argument, as Date's own toLocaleString() has had for a long while and has been the preferred approach to locale-aware string formatting. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/DateTimeFormat#options https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- Dragory 7mo ago
  The problem is that sometimes you want a very specific format, not a locale-based format. This currently still has to be implemented in userland [1]. [1] https://github.com/js-temporal/proposal-temporal-v2/issues/5 https://github.com/js-temporal/proposal-temporal-v2/issues/5
  - WorldMaker 7mo ago
    A lesson I've picked up from what little localization work I've done is to avoid "specific formats" as much as possible. Some user's locale is never going to fit your "specific format" and the more you try to (micro-)manage the output format of your dates the more you are likely to make that user upset or show them a very broken experience. The short/medium/long formats you can get out of Intl.DateTimeFormat/toLocaleString aren't perfect, they are compromises, but they work and users can generally trust them. (If you are using a specific format for something other than display to a user, maybe consider the standardized ISO format instead. Machine-to-machine communications could definitely use a whole lot fewer "specific formats" and explicit Date parsing. Very few backend languages don't have out-of-the-box support or easy found library support for ISO format today.)
devnotes77 7mo ago
[flagged]

kandros 7mo ago

I remember the first time I got in touch with Elixir and immutability as a core principle. It changed the way I wrote JavaScript since

WorldMaker 7mo ago

> What I don't understand is why they had to make string formatting so rigid. Maybe it has to do with internationalization? I'd have liked if it included a sort of templating system to make the construction of rendered date-time strings much easier. I think Temporal takes the right approach: toString() is the (mostly) round-trippable ISO format (or close to it) and every other format is accessible by toLocaleString(). In Python terms, it is a bit like formally separating __repl__ and __str__ implementations, respectively. Date's toString() being locale-dependent made it a lot harder to round-trip Date in places like JSON documents if you forgot or missed toISOString(). Temporal's various toLocaleString() functions all take the same Intl.DateTimeFormat constructor parameters, especially its powerful options [1] argument, as Date's own toLocaleString() has had for a long while and has been the preferred approach to locale-aware string formatting. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/DateTimeFormat#options https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Dragory 7mo ago
The problem is that sometimes you want a very specific format, not a locale-based format. This currently still has to be implemented in userland [1]. [1] https://github.com/js-temporal/proposal-temporal-v2/issues/5 https://github.com/js-temporal/proposal-temporal-v2/issues/5
- WorldMaker 7mo ago
  A lesson I've picked up from what little localization work I've done is to avoid "specific formats" as much as possible. Some user's locale is never going to fit your "specific format" and the more you try to (micro-)manage the output format of your dates the more you are likely to make that user upset or show them a very broken experience. The short/medium/long formats you can get out of Intl.DateTimeFormat/toLocaleString aren't perfect, they are compromises, but they work and users can generally trust them. (If you are using a specific format for something other than display to a user, maybe consider the standardized ISO format instead. Machine-to-machine communications could definitely use a whole lot fewer "specific formats" and explicit Date parsing. Very few backend languages don't have out-of-the-box support or easy found library support for ISO format today.)

devnotes77 7mo ago

[flagged]