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

Temporal: The 9-year journey to fix time in JavaScript

bloomberg.github.io

Post reply on HN
Print view View original

51–60 of 284 posts

Re: Temporal: The 9-year journey to fix time in JavaScript

#51

Post by Waterluvian »

Aurornis wrote: post #46
Waterluvian wrote: post #18

Earlier quoted context omitted.

The worst are methods that both mutate and return values. I know this gets into a complex land of computer science that I don’t understand well, but I wish I could define in TypeScript “any object passed into this function is now typed _never_. You’ve destroyed it and can’t use it after this.” Because I sometimes want to mutate something in a function and return it for convenience and performance reasons, but I want…

> but I wish I could define in TypeScript “any object passed into this function is now typed _never_. Having explicit language to differentiate between pass by reference and pass by value avoids this confusion. It requires a little more thought from the programmer but it’s really minimal once you internalize it. Rust takes this a step further with an explicit ownership and borrowing model. The compiler will refuse yo…

Yeah exactly. That's what I've loved about Rust and hated about real-world JS. I end up having to reason about an entire case that might not be real at all: does this function mutate what I'm passing it? Should I eagerly deep copy my object? UGH.

Re: Temporal: The 9-year journey to fix time in JavaScript

#52

Post by flyingmeteor »

VanCoding wrote: post #37
qcoret wrote: post #32

Earlier quoted context omitted.

All Temporal objects are easily (de)serializable, though. `.toString` and `Temporal.from` work great.

That's not what I mean. Even though it is serializable, it's still not the same when you serialize/deserialize it. For example `JSON.parse(JSON.stringify(Temporal.PlainYearMonth.from({year:2026,month:1}))).subtract({ years: 1})` won't work, because it misses the prototype and is no longer an instance of Temporal.PlainYearMonth. This is problematic if you use tRPC for example.

You would need to use the `reviver` parameter of `JSON.parse()` to revive your date strings to Temporal objects. As others have said, it's a simple `Temporal.from()`

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: Temporal: The 9-year journey to fix time in JavaScript

#53

Post by kandros »

ravenstine wrote: post #50
patchnull wrote: post #6

[flagged]

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…

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

Re: Temporal: The 9-year journey to fix time in JavaScript

#55

Post by VanCoding »

perfmode wrote: post #44
VanCoding wrote: post #31

A big step in the right direction, but I still don't like the API, here's why: Especially in JavaScript where I often share a lot of code between the client and the server and therefore also transfer data between them, I like to strictly separate data from logic. What i mean by this is that all my data is plain JSON and no class instances or objects that have function properties, so that I can serialize/deserialize i…

This is a real pain point and I run into the same tension in systems where data crosses serialization boundaries constantly. The prototype-stripping problem you're describing with JSON.parse/stringify is a specific case of a more general issue: rich domain objects don't survive wire transfer without a reconstitution step. That said, I think the Temporal team made the right call here. Date-time logic is one of those d…

It's not that much about type safety. Since TypeScript uses duck typing, a DateTime could not be used as a ZonedDateTime because it'd lack the "timezone" property. The other way around, though, it would work. But I wouldn't even mind that, honestly.

The real drawback of the functional approach is UX, because it's harder to code and you don't get nice auto-complete.

But I'd easily pay that price.

Re: Temporal: The 9-year journey to fix time in JavaScript

#56

Post by recursive »

LunaSea wrote: post #15
recursive wrote: post #14

Earlier quoted context omitted.

Given the ubiquity of react, I think immutability is generally rated pretty appropriately. If anything, I think mutability is under-rated. I mean, it wouldn't be applicable to the domain of Temporal, but sometimes a mutable hash map is a simpler/more performant solution than any of the immutable alternatives.

Props data passed to React itself isn't immutable which is probably one of the missing bricks. React only checks references but since the objects aren't immutable they could have changed even without the reference changing. Immutability also has a performance price which is not always great.

Yes, you can mutate props. But no, it's probably not going to do what you want if you did it intentionally. If react added Object.freeze() (or deepFreeze) to the component render invoker, everything would be the same, except props would be formally immutable, instead of being only expected to be immutable. But this seems like a distinction without much of a difference, because if you just try to use a pattern like that without having a pretty deep understanding of react internals, it's not going to do what you wanted anyway.

Re: Temporal: The 9-year journey to fix time in JavaScript

#58

Post by LoganDark »

vimwizard wrote: post #27
Waterluvian wrote: post #18

Earlier quoted context omitted.

The worst are methods that both mutate and return values. I know this gets into a complex land of computer science that I don’t understand well, but I wish I could define in TypeScript “any object passed into this function is now typed _never_. You’ve destroyed it and can’t use it after this.” Because I sometimes want to mutate something in a function and return it for convenience and performance reasons, but I want…

Rust ownership model ("stacked borrows" I believe it's called) is basically this

Actually there's tree borrows now. https://www.ralfj.de/blog/2023/06/02/tree-borrows.html

Re: Temporal: The 9-year journey to fix time in JavaScript

#60

Post by chrisweekly »

VanCoding wrote: post #31

A big step in the right direction, but I still don't like the API, here's why: Especially in JavaScript where I often share a lot of code between the client and the server and therefore also transfer data between them, I like to strictly separate data from logic. What i mean by this is that all my data is plain JSON and no class instances or objects that have function properties, so that I can serialize/deserialize i…

It should still be possible to continue using date-fns (or a similar lib) to suit your preference, right?
Post reply on HN