At some point, JavaScript becomes indefensible

Javascript isn't indefensible because it's a bad language (though it is) with a badly inadequate standard library (though that is as well) and an absolutely horrendous ecosystem (it is) which might as well just be a giant billboard saying "please supply chain attack me" (which, shocker, people do), or because the primary uses are apparently to turn text and media into an unspeakably inefficient, utterly inaccessible opaque executable blob (though they are).

Client-side Javascript is indefensible because, fundamentally and by definition, it is running untrusted code. It cannot be done securely. It couldn't be done before Spectre and Meltdown and Rowhammer, because sandboxing a nontrivial runtime is a practical impossibility, and it certainly can't be done after. And even if you handwave this or decide you don't care, there's no way to control what it does. Don't like Bitcoin? Too bad, there's no machine-distinguishable difference between a Bitcoin miner and a sufficiently-inefficient text-only webpage (and Javascript devs are on the forefront of probing heretofore undiscovered levels of inefficiency).

Why. It's not even that strange of a design decision - rust, for instances, explicitly keeps a small stdlib. https://docs.rs/chrono/latest/chrono/ for instance, to deal with time once again.

JS is a very unique language in the client, because it's effectively the machine language of the world's most commonly used virtual machine. That's also partially why it's so hard to add things to the language spec, you need to get all the players (Google, Apple, Microsoft, Mozilla amongst others) to agree to implement it and how. Herding cats and all.

For the third party ecosystem, it again makes sense to have small packages. After all, any dependency, you must ship to the user. You really only want the minimal possible package to both save your own CDN costs and keep Google from downgrading your site (and users happy, I suppose, with lower load times).

It is what it is, JS is not indefensible, and we will "carry this monumental burden" for many decades to come.

Javascript will have, possibly in the next few months as runtimes start implementing it, a new built-in datetime API called Temporal, which is probably one of the best thought-out datetime APIs I've seen (although a lot of these modern APIs are built on many decades of experience with different libraries in different languages, so I don't think this is particularly surprising).

I would even go so far as to say that I generally tend not to trust the stdlib date API in any language. They're often very old, and because it's very difficult to iterate on stdlib libraries, they tend to be stuck with all sorts of painful warts. You can read this great article about Python's, for example.

I'd also like to point out that whenever I pick up a new language, I go through a phase where all I can see is terrible decisions that make no sense at all. Often these are legitimate criticisms, but I need to work through and understand the ecosystem better to understand why these decisions have been made. It's very easy, during this "getting to know you" phase, to dismiss a language as terrible, but there's usually a reason I'm learning that language, and there's usually a reason other people are using it. Outside of esolangs, I haven't yet find a language that I feel comfortable dismissing out-of-hand.

There are plenty of languages without built-in date/time manipulation, and those who do often have their own issues. And do keep in mind moment is long deprecated.

I do like the way moment is structured and how it's used myself. That's a perfectly good reason to include a third party library... As long as it's not bloating code that you're serving over the network with a webpage. But that only applies to browser engine JavaScript, which means the situation really isn't comparable with that of any other language!

At the time that moment was introduced, basically all programming languages had insufficient date/time handling in their standard library, hence the need for libraries like Joda Time, Moment, arrow, etc. to displace the inbuilt date/time handling.

Since then, many languages have embedded more reasonable datetime libraries in their stdlib (mostly heavily inspired by Joda Time, directly or indirectly). And even JS is getting there with Temporal (while for now, you still need a polyfill, the intent is for browsers/node to support it)

Have you considered the date time capabilities of C, C++, PHP before deciding Javascript is uniquely bad in this regard?

There are a lot of reasonable criticisms of javascript. The same goes for HTML and CSS. But for the most part all three are pretty good.

The biggest problems are in what people do with them. But I look at it this way: These are all technologies that sort of evolved organically with the web. Along the way people used them to do things that the original designers didn't imagine they would be used for. And the languages evolved in response to those innovations.

To me it's a beautiful process, the OG agile development. A process akin to actual evolution in that interdependent organisms in an ecosystem evolve over time in response to a complex feedback system that arises organically out of the relationships between the participants.

A lot of it happened independent of government oversight, corporate control and middle manager think. Just people using what was available to do cool shit no one had ever thought of before. Some of the things people did were dumb, and some of them were brilliant. The resulting languages aren't perfect, but they're not terrible either. They could be so much worse.

These days there's a lot more influence from corporations, middle managers and governments, which was inevitable of course. But you can still use javascript, HTML and CSS to build elegant, relatively efficient, framework free applications if you want to.

It's not javascript's fault that it's become almost a defacto standard to end up with a monstrous, framework driven dependency chain. If it was VBScript instead that had become the standard we'd be in a similar place, only worse because Microsoft.

In conversations about programming languages, I always think of the famous Bjarne Stroustrup quote:

There are only two kinds of languages: the ones people complain about and the ones nobody uses.

Others already pointed out the why, but in general, I don't feel like it is a good idea to judge a language purely based on one singular aspect you encounter. Frankly, that can be expanded to a lot of things.

If I may be so frank, my impression is that you are in general very quick to jump to conclusions. Mind you, this is purely based on the few times I saw you post here on tildes. But in that context it is something that for me seems to track. Quickly reaching conclusions might make things seem easy, but it also will ensure you inevitably will overlook a lot of important details and nuance.

For how many centuries are you going to carry this monumental burden?

This doesn't really have anything to do with JavaScript in particular, really, but that last remark reminded me of this talk by Jon Blow:

Jon Blow - Preventing the Collapse of Civilization - DevGAMM 2019

And on the surface it seems entirely unrelated, but I'm also reminded of this keynote:

Timothy Roscoe - It's time for operating systems to rediscover hardware - USENIX ATC 21 / OSDI 21

The common theme to me seems to be an issue of communication. Passing knowledge from one generation to the next. Passing knowledge from low-level to high-level programmers. Communication from high-level to low-level seems alright, except that there's not much the low-level people can do against sheer momentum aside from micro-optimizations. Coordination and communication between disparate hardware manufacturers, operating systems developers, and platform developers.

I don't think the median programmer fears respects complexity in the way they probably should. Rather than reducing complexity overall, there's a tendency to reduce surface-level complexity by reaching for abstractions over existing complexity that simplify things in the short term. In reality, all that does is add compounding interest when others inevitably do the same process on top of your component.

I don't think the median executive cares about complexity at all. "Executive" is not the right term here - generally, I'm talking about people who are able to direct the labor of others. Truly reducing complexity is hard, takes a lot of resources, and requires cooperation and solid communication among all involved. The only people who can orchestrate that are those who direct labor of others - many others - and why would they invest all that effort when the existing stack is, like, right there?

I don't think I'm quite the luddite (pessimist? extremist? not sure what he'd call himself) that Jon Blow is, but I do try to do my own part to avoid stacking layers of abstraction where I can. It only works to a point, though, I don't have resources to deploy anything more fundamental than an OS-native binary. I can avoid writing new JavaScript, though.

Pretty much any complaint I have about JS is outweighed by Typescript having the best type system of any dynamic language. And when you use Typescript on the front end and back end you can get some fun benefits. I like to define my API as a module of structured types. Then I import those types into the front end. Tada! Instant server/client API contract enforcement (at least on a type level, which is pretty encompassing with TS).

Edit: I want to clarify the API types module pulls the actual response types from the return signature of the API endpoints and the body type from the controller’s file.