Javascript Temporal - another feature no one asked for

[moonbat]

Heads up for future implementation headaches and broken sites

[vannilla]

I asked for it (indirectly). Date sucks and this interface improves it, though almost anything improves over Date.

[daemonspudguy]

According to various friends of mine who are webdevs, people have been asking for it.

[Moonchild]

People have been asking for a new API with 200+ functions to replace Date() and related functions?
How much of this will be just another case of doing the same thing just slightly differently? How much of it is sugar for functions that are already widespread in standard function libraries everyone uses?

[vannilla]

People have been asking for a new API with 200+ functions to replace Date() and related functions?

Yes.

How much of this will be just another case of doing the same thing just slightly differently? How much of it is sugar for functions that are already widespread in standard function libraries everyone uses?

A lot of them, probably, but the issue is that those libraries either use the broken Date or have to re-implement everything from scratch, neither of which are ideal.

[Moonchild]

but the issue is that those libraries either use the broken Date or have to re-implement everything from scratch, neither of which are ideal.

But that work has already been done...

[Moonchild]

A quick read from the linked article, I stopped at this "explanation" for "why":

The major issues with JavaScript's Date object are that it only supports the user's local time and UTC, and there's no time zone support. Additionally, its parsing behavior is very unreliable, and Date itself is mutable, which can introduce hard-to-trace bugs.

So all the work that's been put into the Intl standard to deal with all this is supposed to be thrown out.
I also don't see how the parsing behaviour is unreliable (examples?)
Date being a mutable prototype is a positive, because it allows web devs to change it at will to cater to edge cases of Date or to add only those convenience functions that are needed for their use. What's bad about that?

This really does feel like a setup nobody asked for except those who want to control site scripting from the top down and from an implementation-first, client-code focused approach (i.e. Google Chrome).

[Toa-Nuva]

Date being a mutable prototype is a positive, because it allows web devs to change it at will to cater to edge cases of Date or to add only those convenience functions that are needed for their use. What's bad about that?

I assumed that they talk about the Date objects themselves being mutable, not the prototype.

Code: Select all

var a = new Date();
// a is now: 2025-02-01T22:27:01.342Z
a.setFullYear(2020);
// a is now: 2020-02-01T22:27:01.342Z

and I guess the new API will avoid having these mutating functions, and instead have all functions return a new object representing the new time, i.e. something like this:

Code: Select all

var a = Temporal.Now.plainDateTimeISO();
// a is now: 2025-02-01T22:27:01.342Z
var b = a.with({year: 2020});
// a is still the same as before, and b is now: 2020-02-01T22:27:01.342Z

[Moonchild]

Even if they meant that the Date object is immutable, why would I want that? Forcing object juggling all the time is way worse than simply modifying it as-needed.

[Bilbo47]

Back when developing javascript, it was all annoying because it seemed like a toy language ... what with poor data typing and half-baked intrinsics + functions like Date-stuff. Previously-done work needs to yes be preserved, but also future work needs to be optimized for correctness / development speed. Compare against PHP, which started as a toy language and has grown significantly, without losing too much backward compatibility at one time. Agree most infrastructure changes these days are secretly intended to douse the positive reasons for internet to exist.

[moonbat]

PHP is sadly being abandoned for all the bloated frameworks developed against the latest Chrome canary.

[daemonspudguy]

PHP is miserable as fuck. I don't consider its decline sad. Having to learn how to use PHP in order to fix a WordPress site was one of the most painful experiences I've ever had on a computer.

[Moonchild]

PHP is miserable as fuck. I don't consider its decline sad. Having to learn how to use PHP in order to fix a WordPress site was one of the most painful experiences I've ever had on a computer.

You're entitled to your opinion, of course, but I think PHP is still miles better than running a full site on, say, Python or Java.

[daemonspudguy]

Do people actually run entire sites on Java or Python? That's a nightmare scenario for me. Web-based JVM is not a phrase that should exist.

[vannilla]

Do people actually run entire sites on Java or Python? That's a nightmare scenario for me. Web-based JVM is not a phrase that should exist.

People will try to run web applications on top of their own favourite languages. First Java, then Python, then Go, then Rust, then...

[moonbat]

Do people actually run entire sites on Java or Python? That's a nightmare scenario for me. Web-based JVM is not a phrase that should exist.

Server side Java started off as 'servlets' similar to applets - loaded by a servlet runner to which certain directory paths would be mapped, entirely within the process and security model of the webserver. Separately application servers like JBoss and Websphere were made, to run more complicated server side logic, and for a while there was also Java Server Pages, similar to Microsoft's Active Server Pages. It's a mature, secure and robust technology that delivers on the original Java promise of write once, run anywhere. You can port an old web application that ran on a Sun Solaris server to a modern application server running on whatever flavor of Linux or Windows today, without touching your legacy code. Note that I am referring to web applications, not web pages written with Javascript frameworks as is the fashion now.