Live data from Hacker News

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

bloomberg.github.io

271–280 of 284 posts

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

#271

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…

> 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 it easily.

This is known as the "primitive obsession" anti-pattern.

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

#273

Looking at the caniuse results... f*king Safari (and Opera)... https://caniuse.com/temporal

And I have to support safari while dealing with all the problems that are mentioned in this article. Maybe there is a polyfill.

Probably, but I'm guessing it's as big as moment.js ...

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

#274
post #195
post #148

> Whilst Firefox was able to implement Temporal as it was being specced - thanks to the great work of André Bargull (known online as Anba) It's worth highlighting that André is actually a volunteer contributor who managed to implement the whole thing by themselves.

Considering how prolific anba is, the only way we know he isn't an LLM is because he'd have to be several generations more advanced than the current SOTA. (It is possible that he might be an LLM from a few decades in the future, considering the connection to Temporal.) anba implemented all of Temporal single-handedly, plus fixed up numerous places in the spec, plus migrated the implementation over some massive change…

[dead]

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

#275

Earlier quoted context omitted.

Slower to implement new features, but still implementing them, just makes it the new Firefox. IE's larger problem was how popular it had been before it stopped implementing new features. It was like if Google got bored with Chrome and decided to stop all funding on it. People would be stuck on Chrome for years after that investment stopped because of all the Chrome-specific things built around it (Electron, Puppeteer…

The biggest problem with IE from a developer standpoint wasn't the slow feature release cadence, it was that the features it did have worked differently from standards-based browsers. That's very much the position of Safari/WebKit today - code that works across all other engines throws errors in WebKit and often requires substantial changes to resolve. Safari is also pretty popular on iPhones, in fact it has a full 1…

When IE was the Emperor it was seen as IE's behaviors were the standards. The perspective at the time was that the other browsers were non-standard. That did get codified into the standards eventually. `* { box-sizing: border-box; }` that is towards the top of almost every "reset.css" is CSS standard for "use the IE box model". XHR was named XmlHttpRequest as an IE quirk and that set the standard we still mostly follow today; `fetch` is a nicer API but we still colloquially call it a part of/relative to/replacement for XHR including various browsers' Dev Tools where to focus on `fetch` requests you click the XHR tab.

Both of those things (and others) became "standards" when IE was moving quickly and breaking things. It took a while for the actual multi-browser standards to catch up. XHR took a few years to show up in non-IE browsers. CSS `box-sizing` wasn't added to the CSS standards until 2012 (11 years after IE6 was released, the "last" version of IE for a long time; five years without a new version). A lot of the web was built easier on those things or better with those things which lead to so many people using IE up to IE6 as their primary browser and so many developers building IE-only websites up to IE6.

Again, as a developer it can be easy to remember the pain of still supporting IE6 in 2005 (five years before tools like `box-sizing` made it a lot easier to support similar CSS for both IE and non-IE browsers, and a year before IE7 finally broke the "IE6 is the last IE" problem). It seems a lot harder to remember why we were still supporting a "dead"/"final" IE6 in 2005 or still supporting a "dead"/"final" IE6 in 2012 when IE10 was fresh and new and very standards compliant (including supporting both `box-sizing` modes) but not yet winning over the crowds of legacy sites: everyone was using IE6 until Microsoft killed it. A lot of things were built for its version of "standards" (many of which were better/easier to develop for versus their contemporary real standards) and couldn't be easily upgraded until the real standards also caught up to how fast IE had been innovating/changing/upgrading the standards.

The risk to the web platform that I think IE represents the most cautionary tale about is relying too much on the browser rushing ahead of the standards, because it could stop at any moment and may take a decade or more for the standards to truly catch back up. Because they did.

If Google decided today to do a "The Browser Company-style pivot" because the Age of AI means that browsers are dead, everything a browser can do should be done through agentic automation, and asked all of the Chrome team to switch to some new agentic harness or accept a soft layoff, how much work would there be to move websites out of being "Chrome-only" or built on top of Chromium? (Which to be further unfair is also sort of what feels like is already left of Microsoft's Edge team working in Chromium today.) It's real easy to imagine that hypothetical, I already named two companies working with Chromium that have just about done exactly that. The hypothetical is not that far from the inside baseball of what happened to IE6 where Microsoft thought browsers were "done" and pivoted the IE team to new roles on "higher priority" Windows work and/or soft layoffs.

We remember the pain of having to support older versions of IE pretty well, but not enough of us seem to remember the pain of how we got to that point and how easy it feels like companies could do that to the web again. Safari lagging current standards is a relatively smaller problem compared to if Chrome gets burnt we suffer another "internet dark age" of supporting ancient browsers for a decade or two due to legacy apps and in turn legacy users that don't or won't upgrade.

(Some would argue that can't happen in the same way that IE did because Chromium is open source and already has many forks. I can't help up but bring up examples like the word "diaspora" and the tale of "the Tower of Babel" that a messy soup of forks that no one can agree on as the new "standard" can be its own slow train wreck disaster.)

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

#276

Earlier quoted context omitted.

In this day and age when a natural language query can produce the most AbstractBeanFactoryFactoryBeanFactory boilerplate at the same rate as a much more concise equivalent, does verbosity matter as much?

If you want to understand what is going on at all, then yes, good abstraction layers do matter, and a lot at that. Hashtag cognitive debt.

Sure, but if I can summon up a summary of what’s going on for those abstraction layers in a matter of seconds, I don’t particularly care whether they were overly verbose or not. There’s no world where you can hand me a pile of code and expect me to be able to comprehend it faster than an LLM can walk the stack anymore, even the most beautiful pristine code that would make Linus Torvalds praise you is easier to have an LLM parse it and explain it to you than doing it yourself.

And the LLM doesn’t care. You could hand it a pile of the best code ever and a pile of brainfuck and probably the difference between comprehending one over the other is in the seconds if not milliseconds of compute time.

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

#277

Earlier quoted context omitted.

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...

Depending on your needs (i.e. how you would otherwise use your output jspn), using the reviver can have a significant impact on performance. JSON.parse itself is hyper-optimized. At the company I work we used the reviver for almost exactly this, but profiling showed that using the reviver had enormous impact on performance. We cut it out, and won in the seconds of performance for some large json's.

Instead of using the reviver you can deserialize as a plain string, then later reassign the property as the type you want. E.g.:

  const myObject = JSON.parse(text);
  myObject.date = new Date(myObject.date);

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

#278

Earlier quoted context omitted.

If you want to understand what is going on at all, then yes, good abstraction layers do matter, and a lot at that. Hashtag cognitive debt.

Sure, but if I can summon up a summary of what’s going on for those abstraction layers in a matter of seconds, I don’t particularly care whether they were overly verbose or not. There’s no world where you can hand me a pile of code and expect me to be able to comprehend it faster than an LLM can walk the stack anymore, even the most beautiful pristine code that would make Linus Torvalds praise you is easier to have a…

This works only until it doesn't. The stochastic nature of LLMs will not go away. When you have to fix that bug, but the explanations of the LLM are incorrect (root) cause analysis, and you have to dig into the code yourself, you will regret not having taken more care earlier. I have had numerous scenarios in my latest project, in which the LLMs simply did not get on the right track, when I asked them about some issue I saw with a widget or making a custom widget (Python, tkinter). I don't think it will fare much better when analyzing existing code, because ultimately it does not understand things.

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

#279

Earlier quoted context omitted.

Sure, but if I can summon up a summary of what’s going on for those abstraction layers in a matter of seconds, I don’t particularly care whether they were overly verbose or not. There’s no world where you can hand me a pile of code and expect me to be able to comprehend it faster than an LLM can walk the stack anymore, even the most beautiful pristine code that would make Linus Torvalds praise you is easier to have a…

This works only until it doesn't. The stochastic nature of LLMs will not go away. When you have to fix that bug, but the explanations of the LLM are incorrect (root) cause analysis, and you have to dig into the code yourself, you will regret not having taken more care earlier. I have had numerous scenarios in my latest project, in which the LLMs simply did not get on the right track, when I asked them about some issu…

Given the stochastic nature, if I am forced to have to dig into the code because the LLM couldn't figure it out perhaps one out of every 10 times, it's still a huge bonus. Probably it depends on what you are working on. Esoteric COBOL? Erlang? Yeah good luck, you're probably hand steering the thing while the frontier model providers figure out how to train it better. Vanilla-ish Python/Golang/Typescript/Java? I pretty much never have to do that nowadays for things the model is familiar with. If i do have to dig into the code, I've never regretted doing it this way, because 90% of my use cases worked just fine, and in those 90% of use cases I was able to produce working code at 20x the rate of hand writing it if not more. Feels like a huge win to me.

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

#280

Earlier quoted context omitted.

The spec hasn't even reached stage 4 yet. Chrome only added support 58 days ago. Safari already added support in their alphas.

Sure and that’s nice going forward. Yet unlike with Chrome, older devices won’t be updated making this a nice add-on at best.

I checked and you're mostly incorrect.

2018+ Macs/iPhones still receive Safari updates, with security updates going further back.

Chrome is Android 10+, which requires a device not older than 2017/2018 as well.

Chrome is Windows 10+, which I'd say requires 2015+ hardware.

The difference is not that large, how many devices older than 9 years do you use?

Post reply on HN