I think the author would agree. They are bemoaning Typescript which is everything but lightweight and the build chain.

JS for me was a very nice change from the heavyweight OOP languages but now what the usual stack implies is just as bloated and obtuse.

This was my main reason to switch to mainly front-end: to get away from clunky, badly written C# and Java back-end programming. 2/3 of a code file are just the coder wrangling the OOP typesystem instead of just coding the functionality that is needed.

I do like Typescript if you just use it minimally: you can type (I prefer interfaces usually) argument types and rely on the compiler to infer types.

But then the OOP fundamentalists got their hands on it and now they want strict type checking and believe that it makes their code bulletproof https://indepth.dev/posts/1402/bulletproof-angular

Strict type checking does make your code bulletproof. Unfortunately, TypeScript doesn't provide anything close to that. It's easier to mask errors with TypeScript than auto-detect them. Its strict typing should be considered hints for the programmer.

Real strict type checking (as in, eg, Haskell ) does indeed make your code resistant to a certain type of bug. But the kind of type checking Typescript gives you is mostly useful as autocomplete.

(and, if I'm not mistaken, at run time, you can still add or remove properties from an object and re-introduce bugs. Which can happen with 3rd party libraries, for example.)

At runtime, you can pass primitives to a function that expects a very specific DOM object (say), and it'll just plough on ahead like JavaScript does, until you get an exception that nothing catches because FooFunction doesn't raise any exceptions, and everything breaks.

Oh, and did I mention that virtually every browser API these days is potentially optional, with the undefined primitive replacing bits and pieces of them at seemingly random, depending on browser version and configuration, and the presence or absence of certain extensions…? I like the idea of TypeScript, I really do, but don't even try to use it for FFI (where “foreign” is anything outside your TypeScript module).

Yeah the setup-project boilerplaye stuff is a mess.

Luckily for backend it's super easy to set up typescript as the default are good enough for weekend projects/prototypes:

``` mkdir my-project cd my-project npm init -f npm i -D typescript ts-node @types/node npx tsc init touch index.ts npx ts-node index.ts ```

I do agree indeed! It has its quirks, but all-in-all easy to use and get stuff done. Not to mention no need to set-up a compiler or anything. It just works.

> No other language has async built in at such a fundamental level.

I'm not sure that that is true. Rust and Python both have built-in async; while they both have their own takes on what that means, I wouldn't say JavaScript's “syntactic sugar on top of promises, which are object sugar on top of callbacks” is any more of a fundamental level.

Rust does have syntactic support for async but that's not the only thing you need to use async. You also need an async executor runtime, for example tokio. This can cause all sorts of headaches in practice when you want to use libraries which rely on incompatible async runtimes.

You only need an async executor to deal with threading issues; you can completely side-step it if everything's single-threaded (coöperative multi-tasking) or thread-agnostic (Send + Sync). And an executor like smol has no compatibility issues with anything; you just run it.

Python has an async executor, yes, but only to let you do things you can't do with coöperative multi-tasking.

JavaScript has an executor, too. The only difference is that you can't turn it off. It's actually less capable than (most of the) Rust implementations, because JavaScript's single-threaded. (Python's an in-between case, thanks to the Global Interpreter Lock; good JavaScript engines should be able to match Python's concurrency capabilities.)

Executors are only important for things like timers. JavaScript's promises rarely make use of them, except when they schedule their callbacks based on something external to the JavaScript (your “primitive” promises on top of which everything is built). Both Python and Rust work the same way.

The only difference with JavaScript is that it Just Works™ (or, rather, just works; because it does) – but that comes at the cost of sticking JavaScript with a permanently single-threaded runtime.

I think Kotlin beats JS on all those metrics by a long way. And you can compile Kotlin to JS if you want.