This leaves me skeptical if you have extensive experience with Typescript. It's way more than "oh this is a number not a string." It's "you forgot this property on an object's return type that you built from a response value" or "your Redux reducer doesn't handle all of the possible action types so it will crash at run time"

That's from Deno's home page. What I'm talking about isn't whether TypeScript is useful for some projects, as that has been proven beyond question. What I'm saying is that as a tool for "quickly scripting", as claimed by Deno, it is unnecessary and counter productive to JavaScript as a whole.

My point is that the Deno project is a high profile JavaScript engine which, in my opinion, is misguided in their end-user focus on TypeScript and I think it's a shame.

Devs are always searching for the "right" way to do things, and can be easily convinced to do things like misuse "const" because some pedantic fool convinced them it was sorta like type safety, and therefore not using it was "baaaaaaad". And the sheep followed and now const is used everywhere, despite the clear and unambiguous intended functionality of the feature's designers, who added it as a way of tracking, incredibly, constants and nothing else.

It would be nice if we saved a generation of devs another debacle like const, NoSQL databases and UML.

It's important to choose the right tool for the job and SQL/ relational DBs fit many usecases but are not always the right choice. Especially when handling massive amounts of data, that can fit into structures such as wide-column stores, databases like scylla or columnar storage with clickhouse, can help massively.

Otherwise, it just ends up being a big flat in-memory table with a badly implemented version of SQL welded on top, written by developers who never bothered to learn SQL or database management in the first place. Then a bunch of fad followers jump on the bandwagon, and before you know it, we have a decade of idiots blathering on about "web scale" technologies.

That's the debacle I'm talking about. Millions of man hours wasted.

Our solution is the right way to do things... for ourselves. Sorry that it upsets you.

And what are all these dr. Strange multiverse possibilities you speak of? Any semi seasoned JS dev has spidey sense for watching out for null and undefined, and generally you should know the type of what you are returning. Is there that much variability in what you are dealing with? If it’s an array of objects, that’s not hard to hold in your brain, just watch out for empty arrays or null/undefined items.

Yes.

I don't mean any disrespect but again it sounds like you really haven't tried Typescript.

Spidey sense can, often and will fail.

That comment reeks of the same biases that C/C++ developers make when they admit that a majority of C/C++ bugs are related to hard-to-detect pointer/memory safety issues, but claim that they're a good C/C++ developer because their own code doesn't have such bugs, despite the bugs by their very nature being hard-to-detect.

How did people write semi elegant Ruby or python all these years, why wasn’t there such a massive push for types in those languages? Most likely because backend people chose the backend language of their choice, but on the frontend they detested JavaScript (you have no choice, you must JavaScript you anti authoritarian shit heads) so much they had to drown it with some kind of ketchup to make it edible (Typescript).

> why wasn’t there such a massive push for types in those languages

Are you just choosing to ignore all of the history of type checking Python and Ruby?

It’s not hard for me to imagine the reversal of this trend inevitably where everyone goes ‘the fuck are we writing all these verbose types for this dumb web app for?’.

> [why] are we writing all these verbose types for this dumb web app for?

You can take anything to the extreme, but types are a zero risk, low effort investment that has a quick return. If someone over-types something it's hardly a problem compared to an over engineered OOP codebase.

There are a bunch of people claiming this and that are OOP. To me OOP is encapsulating a mutable state inside a dynamic namespace (an object, an instance of class), with functions that can access the state and the ability to inherit / extend namespaces.

And I absolutely don't need it, I don't agree with the view some things are better done with OOP. Even gaming or GUI programming, domains typically considered to be the best for OOP, turned to ECS (which is very functional) and Elm style APIs.

Going back at OOP: I consider mutable state to be a necessary evil to be limited as much as possible; inheritance makes it hard to track what code is being run.

The best practice for writing OOP revolves around limiting mutable state and inheritance, so why even bother with OOP in the first place?

I can have encapsulation with namespaces / modules in functional languages as well. I don't need much else and I can live happily without `this` and using composition instead of inheritance.

OOP was the first marketing wave focused at developers and it's gone.

What does is mean to "respect the devs right to choose which ever language they want"?

Also, having to do type definitions for modules which don't have types is a massive pain. Overall, I appreciate the type safety, but I don't think TS delivers on that promise and I'd rather use a real typed language.