I had a hard time convincing a couple of places I worked to use TS rather than Flow for greenfield projects, but I’d tried them both out and concluded Flow just felt too unstable - the server would consume all my memory and crash and it just didn’t feel like a good dev experience. I managed to convince them by showing them how you could strip out Typescript types in much the same way as Flow if TS did turn out to be a dead end. I also recall having vigorous debates at React meetups where I was the only person in favour of TS haha.

How times changed - you definitely can’t be blamed for choosing Flow at the time though as TS was the outsider. Also MS weren’t such a trusted brand for developers, people still associated them with proprietary stuff like .net/full fat Visual Studio and I think a few people had burned out in the MS ecosystem before and didn’t want to touch their stuff again!

If Flowtype had more resources from Facebook it could still be the dominating language

Even well after TS was clearly the better option (as in 2022) the twitter web team opposed anything being done in Typescript like separate modules that would be a dependency of the web repo.

At least you recognize the better direction now.

I went with TypeScript early on because the compiler chain felt better integrated than the alternatives. No messing with chains of babel translators and source mappings; just use one tool. Maybe I liked the syntax better, also. Although as I recall, in the beginning, somebody my company interviewed had set up TypeScript using Babel, and it was all very over-my-head and impressive. He turned out to be too good to work for us, but some of his ideas really stuck with me.

[1]This is why I dislike cutesy names for software projects. Just call it FacebookTypeAnnotatedJavaScriptFrobulator3003 (FTAJSF3003) or something.

What caused you to choose Flow over TypeScript?

What's today called "namespaces" in Typescript was originally called "modules" and then "inner modules" (to differentiate from "exterior modules") and is a tiny simplification on a JS pattern that was extremely common at the time of Typescript's inception called at the time "IIFE modules". "namespace" is a very C# name chosen in desperation (when it became clear that "exterior modules" were the present not just the future of the language and "interior modules" was too confusing a term to live), but it's a very old (and used to be extremely common) JS pattern that TS gave a tiny bit of syntax sugar to. It was a "standard" that existed at the time that was (rightfully) killed by AMD/UMD/CommonJS/ESM, but it is hard to fault the Typescript team at the early 0.x days thinking the "Stage Wild" JS pattern would possibly live on for many years to come. (This is also relevant to the patch notes for Typescript 5.0 as 5.0 is the first version [!] to itself be written as [proper/"exterior"] modules rather than namespaces. There are some interesting stories, including in these release notes for why that took so long to transition and what the performance benefits have been post-transition.)

Even those things that didn't seem like ES standards have some history as JS "standards". It's not like TS 0.x/1.x didn't support "standards", it is more that the TS team mostly decided to focus more on later stage ES standards (more likely to be accepted by browsers) rather than trying to "prollyfill" Stage 0 and "Stage Wild" standards.

[1] https://github.com/rbuckton/proposal-enum

Too foreign to frontend audiences? It has a lot of fans in flutter

https://rescript-lang.org has a list too

While it's true that TS would have been started with or without Angular, I think OP is largely correct in the influence that Angular's embrace of TS had in TS's long-term success.

It's difficult to see these days, but if you were watching TypeScript's adoption numbers back when Angular made its TypeScript announcement, there is a marked inflection point when that happened. I was running lots of charts and graphs at the time tracking all kinds of data, and in every graph, you could see the Angular announcement in the chart; it's where the line went from kinda slow and linear to kinda fast and exponential. It was a true discontinuity in the second derivative.

We can't run history twice and see what would have happened without Angular, but I think the quantitative impact in this timeline is undeniable.

I have personally never been one of those mega Microsoft haters but I witnessed shouting matches in the office from people that we're hotly opposed to TypeScript being added to the codebase against others using Angular as a core motivation in many of their counter-arguments.

I'm super glad we have TypeScript one way or the other because the team is so dedicated to OSS.

Do you have a source for this. My memory isn't so good but I seem to remember that the Angular team pushed to get this Stage 0 proposal implemented even though the TypeScript team usually waits until Stage 2 or 3 to implement.

- Yarn

- Jest

- Luxon

- Gatsby

- Expo

- Styled-Components

- GitKraken

- GraphQL-js

and that's just off the top of my head. I'm sure there were many more.

FWIW I've been using version 5.0.0-dev.20230223 for a few weeks specifically for this feature - to share code between TS Vite/web and Deno projects - and it's been working without issue.

It's weird to see this:

> commentary in the PR about this new mode being "definitely not suitable for Deno"

I wonder what they meant by that. I mean, this doesn't magically make all TS code Deno-compatible, but nobody expects it to. What it does do is remove by far the most ubiquitous (and silly) barrier to TS code being Deno-compatible. There are others- system APIs, http imports. But this change allows a whole lot of code that doesn't use those to become compatible

> New compiler options

> - allowImportingTsExtensions: Allow imports to include TypeScript file extensions. Requires '--moduleResolution bundler' and either '--noEmit' or '--emitDeclarationOnly' to be set.

To be clear, I'm not using tsc to build code for Deno. I've got module X which imports module Y, neither of which have any platform-specific dependencies. Right now if module X imports Y with the .ts extension, Deno can import X but tsc can't. If module X imports Y without the .ts extension, tsc can import X but Deno can't. With this compiler option, I should be able to include the .ts extension and allow both to (independently) import the same code

I feel like the entire industry has had a "kneejerk reaction" to C++ and its abysmally slow compile times. Everyone jumped onto the interpreter bandwagon and ended up throwing the baby out with the bathwater.

It is definitely possible to have sub-second compile times for large, complex software! Just look at Jonathan Blow's Jai language. He can recompile and reload an entire 3D game engine in about that time.

We can have our cake and eat it to. We can have efficient, compiled languages and still have safety and fast compilation.

This basically describes all of the recent ML – perhaps more specifically OCaml – influenced languages like Kotlin, Swift, F#. (Rust is also heavily influenced by OCaml but its distinguishing feature is manual memory management with lifetimes.)

I do wish we had a good Linux/Posix option with as good of a package manager as Rust's cargo. Kotlin and Swift have some support but are largely focussed on the JVM and MacOS respectively. OCaml itself is of course an option here but its syntax and smaller ecosystem is a stumbling block. Reason is an attempt at a more familiar syntax for OCaml but that community is mostly focussed on transpilation to JavaScript with ReScript.

It's my general purpose language. I also use Rust everywhere Kotlin isn't suitable.

Or as others have said, F#, or maybe Scala. Or if you're feeling really brainy, Haskell.

But Rust was, in its early days, basically inspired by the ML type system, its type inference model, and its pattern matching facilities. The first Rust compiler was written in OCaml.

Arguably the highest quality TS lib out there.

https://github.com/Effect-TS/schema

A pile of thoughts on the subject from back when I first came up with it: http://www.nuke24.net/plog/32.html

There are no types whatsoever as far as processors are concerned. No types in assembly Not for Go or Java, not for C, and not for Rust. All you gotta do is keep compiling.

It's simply impossible to keep up with TS for competing compilers.

Example: https://www.typescriptlang.org/play?#code/MYewdgzgLgBAtgTwLI...

In the example above, the problem is that typescript allows casting function types to omit optional arguments, and also allows using a function with n arguments as a value where a function with >n arguments is expected

Nothing is abandoned and in any case typically only a small set of libraries is needed which should be carefully picked.

Node.js: https://nodejs.org/api/worker_threads.html

Browser: https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...

However, threads are very rarely needed. The common use case in other languages is I/O, and JS environments handle that with async I/O—a superior choice, IMO.

But yeah, they should just go ahead and follow semver from now on.

As such, you could write a function that takes in as an argument a class, and return a new class definition that extends the argument you provided... Or any number of other dubious practices.

    path("/api", () -> {
        before("/*", (q, a) -> log.info("Received api call"));
        path("/email", () -> {
            post("/add",       EmailApi.addEmail);
            put("/change",     EmailApi.changeEmail);
            delete("/remove",  EmailApi.deleteEmail);
        });
        path("/username", () -> {
            post("/add",       UserApi.addUsername);
            put("/change",     UserApi.changeUsername);
            delete("/remove",  UserApi.deleteUsername);
        });
    });