Is It Time for the JavaScript Temporal API?
blog.openreplay.com
blog.openreplay.com
The community seems to be moving towards functional programming/away from classes.. and pretty much every mainstream JS lib is function rather than class oriented (yes, I know classes are simply special functions)
Also adds unnecessary verbosity/more syntax noise.
Is there some internal performance reason for why ordinary functions couldn't be optimized to perform the same as "new"? (Seems like it would be easy to wire the prototype internally to the function, resulting in same semantics).
At this point better to be consistent, but I'd still use a date library just to avoid added verbosity of this native solution. Luxon API reads a lot better than this... Though I'm sure there are reasons a standard implementation needs added complexity (has to cover every edge case)
I was quite against adding the class keyword to begin with to be honest.
Think a lot of that came at the tail end of the "JavaScript is terrible" generational mentality, and the idea was to copy other languages rather than improve what they had independently.
To be clear, having additional functionality is fine in and of itself, but now the waters are mudied between function oriented and class oriented approaches, and by and large community seems to be settling on function oriented.
In the end, class just created unnecessary fragmentation.
Is it more readable? Yes.
Do I feel like we are dumbing JS down? Yes.
Is it worth it when we consider that it helps onboarding hundreds of thousands of developers who want to choose JS? Oh f* yes!
Or you can simply separate out functions into utility objects rather than attaching to the specific data object, and performance should be the same as using prototype, without any of the special syntax
This model of programming is also much simpler, I'd argue. There is no use of "this", everything is explicit. Especially in JS, "this" sucks because the semantics change depending on whether you use function declarations or arrow functions. And "this" will also reference the caller, so changes if the function gets passed around. Much more obvious to pass an explicit argument to a function than to rely on "this"
I do agree there are use cases where prototypes are more useful, performance sensitive games/server code etc. But pretty rare that you can't take one of the approaches described above. And people writing performance sensitive code aren't generally also going to be the newbies. Additionally, could have had syntax sugar for functions that wired prototype without the new/class paradigm, which I argue just adds unnecessary verbosity to the language.
Also I should mention that in the rare case when I did use the prototypes, I always used the adapter pattern (an adapter function that takes a slice of "this", calls an independent function, and merges it back to "this"), it was easier to test.
But people are so unused to declaring dependencies as parameters (even function dependencies aka services), they cry untestable whenever they see independent (static) functions. I know this from the PHP, Java and .NET world. To this day, it didn't help to explain what they call DI is just passing parameters (but rather more bureaucratically).
But contrary to what you're saying, most popular userland libs are indeed function oriented, and they don't end up like you're suggesting. E.g. RxJS, lodash
By function oriented in this context, I mean that they don't rely on the new keyword for ordinary code. Which reads cleaner
Anyway, functional stdlib can be pretty clean, such as something like Stream(persons).filter(person => person.age > 18).map(person => person.firstName).
Also there's the Pipes spec in the works that would allow for chaining distinct functions that are not on same obj. Not sure of current status
functional stdlib can be pretty clean, such as something like Stream(persons).filter(person => person.age > 18).map(person => person.firstName)
I see a stream object with at least a couple of methods, how is it functional? What does functional mean here, callbacks? I mean, array.filter(predicate) also takes one. If that’s the thing, nobody takes it away, it’s already natural to js, since it’s multiparadigm. And we already have piping, it looks like foo().bar().baz() or map(foo).filter(bar) or Object.keys().reduce(quux). If you want a class deconstructor for FP-101 code, here it is:
const fize = (name, …args) => (obj) => obj[name].apply(obj, args)
array.map(fize("toString", "hex"))
I understand the different approaches you propose, and I could even write some decent Haskell in my experimenting ages, but my main question is what problem do we solve here and how this solution would be functional and not “move methods to same-named pojos, write them explicitly and pretend it’s FP”.
The community seems to be moving towards functional programming/away from classes
The community moves to where React is, no real CV choice. Other parts of the community are non-functional, e.g. new WebpackPlugin, etc.
Class was something pushed by all the next gen framework authors at the time. Then most next gen frameworks abandoned class, because it proved to be worse in many ways than ordinary functions did. Which was the position I held at the time, and seem to have been borne out.
The easy way to tell types apart in ordinary JS is to have consistent naming conventions. If you always name things such that the name implies the type (not Hungarian style, but more natural language oriented), you can infer the type from the name correctly 90% of the time. E.g. always write arrays as plurals, map-like objects as keyToValue, and so on.
But the easier answer is to just use Typescript.
Inferring type from instantiation point is pretty meaningless anyway. The type needs to be inferrable at the consumption site to be readable, not the production site. Understanding a type only matters in the context where it's used
Apps Hungarian wasn't actually a stupid idea. It just got bastardized into Sys Hungarian, which was. Apps Hungarian could tell you whether the string was unsafe (and needed to be sanitized), or safe to use. Or tell you if the integer type you were using was an offset, or a row number, or whatever. It was supposed to give you semantic info that wasn't necessarily obvious from the given type.
Sys Hungarian told you that you were using a long pointer to a zero terminated string. But not what the string actually meant. It just regurgitated the type of the object again.
No thanks, not an easy way. instanceof and typing are the tools, not some funny notation that I have to rely on everyone to follow and parse, including me, under a pressure, after a year. Nobody can infer/assert types three modules away from a scope of their commit when it’s in the name.
But the easier answer is to just use Typescript.
Typescript is duck typed, you can’t save your day by “type Date = string” in it in a sense of a type safety. Nothing is wrong with object classes, apart from personal affinities accumulated from scary blog posts about classes in non-js languages and how that was bad. Objects have different types and different operarions on them. There is no clear reason to erase this difference and to evict methods only to group them into a scope and match by name manually, losing literally all benefits just for a functional swag.
Having a whole layer of abstractions and keywords built around class literally just adds complexity. Not to mention how obtusely "this" works in JS. The whole layering of special syntax around class just serves as a crutch for those coming from other languages.
Nowhere does it simplify anything really, aside from those who are already familiar with that abstraction. It's objectively simpler to have fewer abstractions, given that you can use object literals and regular functions to achieve the same results in similar amount of code. If class saved a lot of verbosity from alternative approaches, there may be a compelling argument for it. 99% of userland code does not need or use prototypes in modern JS
Typescript largely obviates need to do runtime type checking, except at API boundaries. But networked apis can't return classes by definition (not supported in JSON spec).
If I were to create shapes, I would interface the data and have a simple type field like "rectangle" "circle", etc. Or even simply duck typing it. Very easy and consistent way to check without having special prototype specific syntax of instanceof.
Using fields to imply the type is json compatible too, and works sent across the network. With Class you would need to have hooks at Json receipt point to instantiate the instances of the class. Class is a whole layer of unnecessary abstractions that don't even reduce verbosity.
is any process with a 10% margin of error really an easy one?
Of course you could literally spell out the type. But verbosity not worth it. Also no guarantee the name was written correctly.
But I've found most JS codebases don't have rigorous standards around naming to begin with, so even doing that is a big win
And speaking of everyone moving to functional programming: i work with several hundred developers in four continents in a very dynamic envirnment.... And I have not seen a FP advocate. Not that FP is not good (I prefer it where applicable) but mindset/winning/moving towards are words I would not choose when it comes to describing the state of FP and OO in the world. There is a strong influence but not to a degree where an established language changes its core paradigm: see Java, C#, JS, ...
Be it in React, where hooks are pushing everything to be functional; to the fact that Monads have started showing up in unexpected places in codebases I’ve worked on; to the fundamentally functional nature of frameworks I have to use every day working at a FAANG.
Along the way, until the FAANG, I never met any functional advocates. What I did meet are people who reach for the appropriate functional tools when building solutions; others see the much better solutions they arrive at, and copy.
Not particularly -- JIT vms should inline `(() => new Thingy)()` as `new Thingy`. The temporal API provides a lot of nice factory functions that don't need any `new` keyword. Here are the first several examples of the Temporal API all concatenated together with comments removed:
Temporal.Now.instant().epochSeconds;
Temporal.Now.instant().epochMilliseconds;
Temporal.Now.zonedDateTimeISO();
Temporal.Now.timeZone();
Temporal.Now.zonedDateTimeISO('Europe/London');
Temporal.Instant.from('2022-03-04T05:56:78.999999999+02:00[Europe/Berlin]');
Temporal.Instant.from('2022-03-04T05:06+07:00');
Temporal.Instant.fromEpochSeconds(1.0e8);
Temporal.ZonedDateTime.from('2025-09-05T02:55:00+02:00[Africa/Cairo]');
Temporal.Instant('2022-08-05T20:06:13+05:45').toZonedDateTime('+05:45');
Temporal.ZonedDateTime.from({
timeZone: 'America/New_York'
year: 2025,
month: 2,
day: 28,
hour: 10,
minute: 15,
second: 0,
millisecond: 0,
microsecond: 0,
nanosecond: 0
});
As a side note, there are concrete performance reasons to use class/prototypes over plain objects or closure-over-hidden state in your own code:
- Class and/or constructor functions helps ensure your long-lived objects instantiate their properties in a regular order. V8 has trouble unifying objects with the same properties but different property orders into the same hidden class. Each hidden class costs JIT time and memory space, so minimizing both is nice. You can fix this yourself by forcing instantiation of a value to go through a factory function to normalize property order, but at that point, why not use a class to take advantage of `instanceof`?
- Closures over hidden state, eg long-lived closures you would use to implement your own object system over enclosed local variables, cost more than plain objects or class instances. It's more straight-forward to define classes at the top level and wrap them in sugared factory functions than to code-review factories that manually build objects with function properties.
There's also all sorts of optimizations you have to depend on to avoid excess object allocations, etc.
That said object allocation in JSC and V8 (not sure about spider monkey) is essentially a pointer increment in the common case, so its not exactly expensive.
Factory functions can return objects that have a prototype just the same as "new", there is no inherent reason object constructors should require "new". Given that most of modern, idiomatic JS relies on factory functions, it seems very inconsistent to me to then randomly require invoking "new" to construct an object.
Why not simply Set([1, 2, 3])? The noise comes when you have a nested expression with random "new" statements sprinkled in which disrupts the flow. Though I agree that overly complex expressions are an anti-pattern
My underlying point is that "new" does not provide any clarity, given that objects are created and returned all the time without "new", so represents an inconsistency in design to me. The presence or absence of "new" basically tells you nothing, except implying that the object likely has prototype functions. But whether or not they are prototyped is more of an implementation detail anyway.
I agree with you that most of Temporal has factory functions that obviate "new".
To your point on performance of closures, this isn't going to materially matter for majority of use cases. Yes, prototype is more efficient than closures functions, but benefits of prototypes can also be achieved through separation of data and function (singleton utility functions that operate on data).
Also syntax sugar for prototype could have been done in an (IMO) more consistent way through some syntax addition to functions rather than creating class. Generally modern userland code shouldn't really be using prototype and "this" anyway, as "this" has tons of footguns in JS, and I would guess majority of developers don't understand the intricacies of "this" when passing functions around, or when using arrows vs classical function declarations.
Often objects that are class based will expose a `of` or `from` method that abstracts over the `new` keyword `Array.from()` is one example instead of `new Array()` (of course the most common way is `x = [1, 2, 3]` but these other options exist too).
This seems fairly functional to me.
If your concern is `whatever(date)` vs `date.whatever()` then the issue you run into is pollution of the global object, which is bad, and frequently not possible due to naming collisions with existing sites (fun story, `let` required some exciting rules to deal with existing content using variables named `let`). Given an inability to add a million new functions to the global object your concise `whatever(date)` becomes `Temporal.whatever(date)`
Otherwise you end up like Mathematica, which has ten thousand or so functions in a single namespace.
Or PHP which had (has?) a similar problem (but on a smaller scale).
Anecdotal observation follows:
In the span of my career so far it looks like the community moved from imperative programming with a few classes/prototypes sprinkled in there, to imperative programming with a few lambdas and HOF sprinkled in there.
I've yet to come across anything significantly functional or OO in the wild, it's still mostly plain old data mutable structures and for loops.
Now of course you could provide a plain function that returns a special, nominally-identified object. But at that point there are basically no advantages over using a constructor (unless you need multiple such functions that take different kinds of arguments); the difference is almost entirely superficial, and constructors do a slightly better job of advertising that their return values are special, and also have precedent and therefore familiarity
My guess, and it is only and just that, is because classes, being a newer part of the language, allow the developers and designers to work with a cleaner environment, if you will, avoiding some of the pitfalls that have lingered since ES1.
Classes are strict, by default, e.g. I can imagine other benefits, but I am too little caffeinated to articulate them right now.
Basically, if one sticks with “the old way”, one runs the risk of one’s users using poor idioms that could cause support grief, but by using the new way one avoids these.
Note also that JS classes aren’t pure OO, at least not yet, but are really a different and arguably better approach to function/object (in the JS sense) design and implementation, and that JS is slowly pulling in FP concepts as well.
https://mobile.twitter.com/hillelogram/status/13292284196289...
https://maggiepint.com/2017/04/09/fixing-javascript-date-get...
The reason it apparently feels weird to many people to have months be zero indexed is that months are often referred to by their ordinal number, and ordinal numbers obviously start at 1.
What do you mean by “often”? Humans always use ordinal numbers for counting things like months, days, weeks, etc. There is no concept of 0 to be applied here, except for programming array indexing purposes.
This is a potential cause for confusion when writing computer code, because it’s very common for code to refer to items in a collection starting at zero.
Date & time APIs must match local reality.
parseInt('0700') returns 700. But parseInt('0x700') will be parsed as octal, so now it's just a more subtle gotcha.
Loose parsers (such as parseInt(), and Date.parse() in JS) are one of the worst ideas ever. Nothing like tracing a bug, and finding that a junior dev is trying to parse DD/MM/YYYY strings using Date.parse(), except that instead of throwing on trying to parse an incorrect [non-RFC] format, the parser makes a best-guess and propagates an incorrect date because it was parsed as MM/DD/YYYY.
Parsing floating point values correctly is not a trivial amount of work - to the extent that there have any been security vulnerabilities in implementations.
Same with dates. Don't try lots of formats on an arbitrary string, force the user to specify the expected format somehow.
That is, if I do this
float f = 123.456;
Console.WriteLine(“value is “+f);
For parsing, the argument should even be explicitly required I think. So
float f = Float.Parse(“1,23”, frenchLocale);
Otherwise I agree with you whole heartedly - I have been stung by absurd locale dependent behaviour in the past (windows’ font loading APIs inexplicably translate the font variant in the programmatic api)
For instance, RFC 1945 (HTTP 1.0) specifies three acceptable date formats. Add ISO dates, and now you're writing software that needs to handle 4 different formats. Easier to just use a heuristic parser that's capable of accepting HTTP, email, Usenet, and ISO timestamps.
Fortunately, these days it's generally considered a bad idea to use anything but ISO timestamps, with the exception of a former colleague who tried arguing that DD/MM/YYYY was an acceptable format to be transmitting and storing dates in.
In the interim, JS-Joda [0] seems pretty decent, and doesn't use the wrapper approach.
Even the simplest of future cases is handled poorly by these other libraries. If you want to say that something happens on a certain date in the future (say, a due date), your only option is to use an instant as an approximation (often midnight utc on that day). It works ok, but you’re better to have a proper datatype that represents a day without a time and timezone component (it’s effectively a 50hr ish window). Temporal gives you all that and more.
I don’t quite get the point of the other libraries like moment etc. They have a bunch of convenience stuff, but unless you’ve modelled the different types of times that crop up in real life, it’s all a bit pointless. When I first read through the Temporal api, I was physically nodding along in agreement. It’s dates and times done right in js. Can’t wait to be able to use it.
So we're dealing with an API that has been considered great, and an excellent way to deal with dates/times, for nearly 2 decades. Seems like a safe bet to copy :)
I hand-wrote date and dt types with basic operations instead. Limited functionality, eg timezones, formatting etc, but behaves as you'd expect.
Another option might be to wrap Rust's Chrono lib in WASM, then call from JS; it's the best DT lib I've seen in any language.
Yes? Or at least, I don't think this is the, "obvious question that leads to the rest of the article" that the author may have assumed.
As another commenter mentioned, Day.js is 2kb. That's the answer: use Day.js.
But I guess that doesn't get you a blog post you can reference when applying to jobs, so here we are.
Is 74Kb really a cause for concern on modern internet connections? I realize death by 1,000 cuts, etc...but for such a core set of functionality that seems pretty reasonable.
DayJs is 2 (two) Kb. Perfectly reasonable for any app with minimal date handling needs.
(BTW I'm 100% in support of a native temporal API also, although have some gripes with the Dev Exp of what's shown in this post)
I’d say that time-related API being core functionality makes it more of a reason why this should be baked into the standard JS API. Why make users download something that most sites and web apps use?
You can have LTE+ or even 5G in cities, but traveling by train means that in some areas only a select few extra-lightweight pages like Hacker News are able to load before a timeout or connection loss occurs.
So yes, in some situations even that amount of payload could have a meaningful impact.
“Modern” connections are irrelevant if we are talking about regions, which are not viable for a high-speed infrastructure. And such places are almost everywhere. Mountainous parts of Japan, many American regions, or sparsely populated Polish regions.
Of course, how much it is important varies greatly.
That depends on how you define what a modern Internet connection is. If you mean a fast, low latency, unmetered connection then 74kb is obviously fine.
If you mean a 4G connection on a train, or a metered rural satellite connection, or a typically-low-income-user pay-for-data connection, or even a fast cheap Internet connection but with a low-end device that will waste a lot of battery power parsing and running all that JS code, then it's a lot less obvious.
Most of the time you don't know who the user is, so it's best to assume the worst case. If your site works well when things aren't ideal then it'll be awesome when they are good too. Only thinking about the happy path of users with M1 Macbooks with unlimited gigabit ethernet will mean everyone else has a sucky time on your site.
Also, if someone posts your site on HN, most of the comments will be about how bad the code is and you'll miss out on feedback that's actually useful. If you're deploying a 74kb date library, think of your karma.
If there is solution that removes the necessity of a 74kb package then I think we should embrace it.
I’m still fairly new to TypeScript but it’s quickly replacing Python as my daily driver for most things that aren’t back-end APIs.
If there is solution that removes the necessity of a 74kb package then I think we should embrace it.
I’m still fairly new to TypeScript but it’s quickly replacing Python as my daily driver for most things that aren’t back-end APIs, and Date is certainly one of those things I would love to see changed.
I think people assume Starlink will bring high-speed internet to every corner of the globe, but that being the case, there’s more situations where groups of people will share a single downlink, and still every kilobyte counts.
A considerable fraction of all the data ever sent on the internet is JS libraries that could have been bundled into browsers instead of every web page using slightly different versions.
Not too long ago, Google tried to push AMP on all of us because devs were getting way too careless with their bundle sizes. We're still not to a decent place just yet. Internet speeds in The United States, Europe and populated Asia may be growing but there's an entire world that are still at "slow-3G" speeds.
I like it. Here's a summary.
A datetime has three representations:
- (real) number of milliseconds since the epoch,
- string in some standard format (e.g. ISO 8601),
- plain old object with the following properties: year, month (one-based), day, hour, minute, second (real), zone, week, weekday.
Then there are four functions for generating datetimes and converting among the representations:
- Date.now() -> Number
- Date.object(Number | String, zone info? ...) -> Object
- Date.string(Number | Object, format and/or zone info? ...) -> String
- Date.number(Object | String, format and/or zone info? ...) -> Number
You'd need the tz database under the hood and maybe exceptions for impossible or ambiguous datetimes.
Aside from bundling the tz database, I don't see this library needing to be very large. And if it's small, it's not a big deal if it isn't standard.