People may forget what you did, but they'll remember how you made them feel. It's been years since I've used TS, but I remember it failing to solve about half the problems that I had with JS. I think they did the best they could given the constraints though.

This article is a good example. TS can't fix the underlying APIs, standard library etc.

Kotlin and even modern Java are both preferable for me. There’s no shortage of JVM roles.

As of the last couple years, you're probably not wrong. Basically every open role right now requires TypeScript, Node, Next.JS, etc.

Swift is a bliss to write and easy to get paid to write it.

i was paid to write rust for a couple of years.

Meh, I used to have that feeling, especially when discovering fp-ts and then effect (neither of which I've been paid to write), but after about four years, I'm tired of writing it period. The standard library for node is horrible; the ecosystem is okay but not great. And I don't even care for effect anymore. I also write go in my job and it's just okay, but the standard library is much better.

I've been playing around with rust in my free time and like it. I think it's a good FP middle ground. Gleam also looks interesting. But to your point I imagine there aren't many jobs paying for rust and practically none for Gleam.

C# pays fine

Agree. While people argue and split hairs over X language is better than Y language (noobs if I’m being honest, even if they have 20 yr experience), one can ship actual products and make money using TS.

It’s a good language that scales quite well to the point where you can then extract specific parts to more performant languages.

99.9% of people won’t have that problem, so I think they should just use TS and solve problems.

Anyone else can be safely ignored and they can complain in the corner.

I'd love to disagree, but every other language's ergonomics just seem so clunky or too magic, whereas with TS and the standard web APIs you have so much room to code how you see fit. Sure, I'd rather a LISP for purity but I'm a realist. If only Brandon Eich had really gotten his way, we'd have Scheme.

People aren't mad that errors aren't fixed automatically, people are mad that the behavior is inconsistent and weird for no fundamental reason other than "that's how the interpreter worked when it all started and it's too late to fix the spec now".

Python is a dynamic language as well and in many ways worse than JS, but

  [] + {}

In JS

  [] + {}

  {} + []

> the near decade of WAT snark

For today's lucky 10,000:

https://www.destroyallsoftware.com/talks/wat (2012)

Yeah this is a fair take - I guess my unwritten stipulation was don't expect anything from the JavaScript standard library to behave as you'd expect, outside of fairly narrow paths.

TBH even when working with other languages I'd skew towards doing this, possibly because I've worked with JavaScript/TypeScript too much. It's a balance but there's a certain comfort in making constraints really explicit in code you control over blindly trusting the standard library to keep it's behaviour over the lifetime of the product.

> when timezones change, countries make changes to when their summer time starts, etc. Which happens all the time.

The frequency in which time zones are changed surprised me the first time I looked it up. For a single country it's probably quite a big deal that doesn't happen too often. But internationally there are several changes each year. I think it was like 4-6 changes per year in the past decades.

The IANA timezone database does occasionally revise historical rules when relevant information comes to light. So you might have calculated that some historical figure died at such-and-such a time UTC (based on a documented local time), but actually that's inaccurate and you might not know because you haven't redone the calculation with the new rules.

Are any other languages more sane with this stuff? Because I've also been to this particular corner of hell. Also in a web app.

But - wouldn't this be just as horrible in Go or Rust or any other language? (Or god forbid, C?) Are there better timezone APIs in other languages than what you can find in NPM that make these problems any easier to deal with?

Databases like postgres need timezone stored separately anyway, so for scheduling store local time and time zone it was scheduled in separately.

> you want to display the time in the local time of the restaurant

Many European railway timetable amd booking websites fall foul of this.

The entire point of a parser is to parse unknown values. That's the entire job of a parser: take unstructured (usually string) data and turn it in to something structured, such as a date. If it can't do that reliably with error reporting then it's not a good parser on a very fundamental level.

There are so many valid and reasonable cases where this will bite you.

"Real-world data" from CSV files or XML files or whatnot (that you don't control) and sometimes they have errors in them, and it's useful to know when instead of importing wrong data.

You do something wrong by mistake and getting wrong/confusing behaviour that you literally never want, and then you need to debug where that's coming from.

The user gives you a date, you have no idea what they entered and you want to know if that's correct.

A parser is supposed to reject invalid input, not generate semi-arbitrary outputs.

> Burn it and start again

Good news! The builtin Temporal API is on its way. It's widely regarded as a solid API, learning from some of the best time APIs in other languages.

In terms of parsing, it looks like Temporal only accepts RFC 9557 strings (an extension of ISO 8601 / RFC 3339). Anything else throws an exception.

As is usual with these JS critiques, the problem is that you'd never do most of this. Yes, it's silly, but nobody passes random strings into the date constructor because all you really need to know is that the date constructor does weird shit with random strings.

You don't need to burn it, you just need to never rely on the constructor for parsing user input. It all works fine as long as you know the structure of the data before you pass it in.

That's not the last progress update. Most recent is https://github.com/tc39/notes/blob/d5b5db6969359fad11b6898b7....

Implementations are ongoing and open source, so you can contribute if you want it to come faster! V8 is currently aiming to use https://github.com/boa-dev/temporal IIRC.

Ha-ha, thanks, I couldn't help but chuckle a bit at that intro. As for them taking their time... Well, yes, it's all rather sad, but I personally came to terms long ago with the snail's pace of JS proposals rolling out. And after all, working with dates and time zones is a rather complex matter in itself, so no judgment here.

I've had to develop interfaces built entirely around date and time operations, and it was painful not so much because of the awful and broken date parsing in JS (although it definitely doesn't help), but rather because of the inherent complexity of how we represent calendar dates and times, and how we build abstractions around these representations. Definitely NOT looking forward to developing that booking system at work...

Javascript put me off a career in IT for 20 years, and even today I still avoid it like radioactive waste.

Some notes that I have noticed. First, why does it seem that the V8 date parser is heavily inspired by the Windows date parser (https://devblogs.microsoft.com/oldnewthing/20200304-00/?p=10...)? EDIT: Apparently not, "new Date('Savvyday 29 Oatmeal 94')" is invalid both in Firefox and Chrome.

Second, I opened this in Firefox with the console open to answer these questions, and found these divergences (to summarize, Firefox is strict):

Question 14:

  new Date("12.1")

Firefox returns an Invalid Date object instead.

Question 16:

  new Date("12.-1")

Again, Firefox returns an Invalid Date object instead.

Question 19:

  new Date("maybe 1")

Seems a broken record, but this is still an Invalid Date for Firefox.

Question 20:

  new Date("fourth of may 2010")

Ibid in Firefox.

Question 21:

  new Date("May 4 UTC")

No, Firefox is still not accepting this one.

Question 22:

  new Date("May 4 UTC+1")

Neither this one.

Question 23:

  new Date("May 4 UTC+1:59")

Firefox: Not really.

Final note: It parses Question 24 as you expect in Firefox. Which honestly, it shouldn't!

It’s a mean thing for me to have done, and I did originally have an extra little disclaimer on the questions where it was relevant, but I removed it because it felt like the shock value was more funny.

I can understand why JS' Date is the way it is, but Moment, and even more so Luxon and Day.js, have no excuses - Joda Time has been around since what, 2005?

Fix the font for the description field that appears after someone picks an answer. On a normal Windows 10 install, the 0 (zero) is rendered identically to a lowercase o.

If you're going to use fancy fonts at least make them webfonts.

Oh hi! Thanks for the great quiz

Good job Sam! Been a while since we spoke on Twitter, but good to see you here :)

This matches my experience. This is a bit of fun but I’m hoping it has the positive side effect of making people more cautious about how they use Date.

> date.getFullYear() => 2025

`getYear` is literally deprecated everywhere and is not part of the spec.

https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec...

Today you should use getFullYear() => 2025

getYear() returns 125 as it was standard for dates to be offset from 1900 (which led to the Y2K problem). This behaviour should be maintained forever. "Nothing is more important than backwards compatibility"

Or rather, that should be mindset, so that we can achieve at least 90% backwards compatibility in practice.

Thanks. More info in this thread:

https://x.com/BrendanEich/status/1752615257615528205

> parsing of strings that do not remotely resemble actual dates.

But this is somehow my point, what were the reasons that lead to parse those strings as dates. I guess the answer is usually legacy, but in that "legacy" why did someone need to take those decisions? My naive way of parsing dates would be to reject everything that doesn't have a well defined format while the format is well defined and at least somehow composable, but here someone had the need (I hope the had the need) to parse these seemingly random strings, I wonder why.

may I ask how long are you programming in JS for?

Well, because fun is an amorphous concept defined to be human-specific, your comment should say:

I am willing to (sarcastically) stake something of value on the premise that you are considered to be an interesting individual to interact with by your interlocutors and bystanders at socially coordinated gatherings of individuals convened for the explicit purpose of engaging in recreational, celebratory, or convivial activities, often characterized by the consumption of food and beverages, the enjoyment of music or other entertainments, and the collective participation in structured or unstructured merriment.

But who came up with such a confusing „logic“?

„0“ and „1“ are for years, everything above are month.

Does the text parsing only work for English or other languages too?

For the same reason dogs aren't the square root of two and justice isn't golf? They're not the same kind of thing at all, if you insist that we should be able to compare them then they're not equal, and since programmers are human and make mistakes probably comparing them is itself a mistake.

yea that's an odd example to pick. expecting type conversion to add meaning to strings is a programmer problem not a language problem. really comes down to developers not thinking about types and their meaning anymore.

there are plenty of javascript examples that are actually weird though, especiall when javascript DOES apply meaning to strings, e.g. when attempting implicit integer parsing.

edit: I'm mostly wrong here.

Because "0" is false. In a logical world, a non-empty string being truthy is fine even if the value is "false". Javascript isn't logical.

“false”, not false. So there’s odd type coercion, but the problem is that it can happen without you asking for it.

Python does the same thing. I don’t like it there either, but at least it’s more consistent about it.

The string with the value of "false" evaluates to true.

In other words

If ("false") { /* You will be here */ }