TypeScript’s usage plateaued around 2020 (at a little over a 3rd of the JS ecosystem having adopted it), and in the past year finally showing its first signs of decline as it is replaced with better, simpler alternatives like eslint-plugin-jsdocs (get started here), and a potential comment based ES202X official type system that will likely lead to a rapid decline in the need for creating .ts files. With these potholes filled, TypeScript will need to either find new potholes to try to smooth out and justify it’s existence, or accept that it’s job is done and slowly fade away.
As an outside observer (with a partner that is a front-end dev) I’ve not seen this at all. From what I’ve seen TS remains extremely popular. Anyone in the space seen otherwise?
Nope. I’ve just seen a bunch of frontend developers who were initially skeptical and now their code looks like Haskell code golf.
They may be going overboard now but as new converts to the wonderful world of typing they are enthusiastic.
I honestly think the typescript type system is just very well designed and ergonomic. I say that as someone who writes a lot more go than typescript. I also lived through the days of 1/2 assed type documentation in comments in JavaScript and Python. I believe the current state is better.
This is probably a reference to the common convention in TypeScript to give type variables single letter names. That combined with complex types (e.g. those using ternaries, infer, etc.) tends to be very hard to read. This is mitigated somewhat by using more descriptive type names. For example:
type Reverse<T> = T extends []
? []
: T extends [ infer X, ...infer Y ]
? [ ...Reverse<Y>, X ]
: never
…vs…
type ReverseTuple<Tuple> = Tuple extends []
? []
: Tuple extends [ infer Head, ...infer Tail ]
? [ ...ReverseTuple<Tail>, Head ]
: never
I was making a joke more about very complicated higher order type programming. Although maybe C++ template abuse would be a better joke. Stuff like this:
type GetFieldType<T, P> = P extends `${infer Left}.${infer Right}`
? Left extends keyof T
? FieldWithPossiblyUndefined<T[Left], Right>
: Left extends `${infer FieldKey}[${infer IndexKey}]`
? FieldKey extends keyof T
? FieldWithPossiblyUndefined<
GetIndexedField<Exclude<T[FieldKey], undefined>, IndexKey> | Extract<T[FieldKey], undefined>,
Right
>
: undefined
: undefined
: P extends keyof T
? T[P]
: P extends `${infer FieldKey}[${infer IndexKey}]`
? FieldKey extends keyof T
? GetIndexedField<Exclude<T[FieldKey], undefined>, IndexKey> | Extract<T[FieldKey], undefined>
: undefined
: undefined;
Anecdotally, this is certainly not the case for me. I was very skeptical for years. I thought it’d be another CoffeeScript and kept waiting for an eslint-plugin-jsdocs-like solution to come along. Now that I’ve been using TypeScript regularly for a couple of years, I find myself starting all new projects in it and even slowly porting old projects to it as well. I would even plead guilty to occasionally going overboard with types, but overall, I’ve found it to be possible to get near Elm-levels of runtime errors (close to none). Overhauling data structures and doing major refactoring is a relative breeze now. Full “erasability” is turning out to be an excellent design goal and should make it possible for JS runtimes to run TypeScript without a build step.
Sass is a huge success, like jQuery. All of its features have been adopted by real CSS. The tool itself has less reason to exist in new projects as a result, but it absolutely won as a historical matter.
I think that’s the point. The success criteria for something in this space is that the need for it goes away: it provides a bunch of things that fix limitations one layer down and then those fixes are adopted in the underlying system. As such, baking something in this category into a system is a bad idea because its goal is (or, at least, should be) to obsolete itself.
I’m not a JS developer really, but IMO the almost-unspoken benefit that the Bun project would bring is breaking the implementation monopoly, particularly as it’s not based around V8 - so you have competing implementations down to the actual JavaScript engine itself.
Additionally - claiming that a JavaScript runtime is not “production ready” because it doesn’t run on Windows is kind of fucking bizarre, and mentioning “90% of people use Windows” doesn’t help your argument, because 90% of computer users will probably never use a JavaScript runtime on their computer.
Like it or not in web development, developer use of macOS is often considered the “default” choice. Linux desktops are more popular than ever and Windows has built in Microsoft-supported means to run a Linux VM easily.
Additionally - claiming that a JavaScript runtime is not “production ready” because it doesn’t run on Windows is kind of fucking bizarre, and mentioning “90% of people use Windows” doesn’t help your argument, because 90% of computer users will probably never use a JavaScript runtime on their computer.
Depends a lot on what it’s used for. If it’s for server use, Windows folks will probably use WSL / WSL2 and deploy on Linux (though Azure Functions has Windows runners that can run Node.js functions on Windows). Mac developers may run Linux via Docker / Podman and deploy on Linux, or may develop natively and just fix Linux weirdness close to deployment time.
If you’re looking at something like Electron, I would suspect that the vast majority of uses are on Windows. Electron is basically Chromium + Node.js and might be the most widely deployed instance of Node (I suspect that the average number of Electron apps on a Windows machine is greater than one).
That sounds like a bit of a straw man to me. AFAIK even the projects making use of Electron, don’t directly control the nodejs runtime that gets used for their eventual application, it’s an inherent part of Electron (ie you can’t “bring your own nodejs”).
Something doesn’t have to be production ready for every single use-case it might hypothetically be usable for, before it can be considered production-ready.
I think it’s good to reflect on these things, but I strongly disagree. Bun is a much bigger deal than Yarn ever was. It’s not just a replacement for npm, it’s a replacement for node, npm, babel, webpack/esbuild, and jest. Even if npm catches up in performance (big if), there’s a lot of value in having an all-in-one tool that provides a great developer experience. I find it a breath of fresh air compared to the status quo of creating a JS/TS project, and I’m glad it’s introducing more competition into the space.
I thought the argument in favour of bun was that it gave you a non v8 node environment?
Making Node conceptually a runtime with multiple implementations.
Because let’s be clear the speed and performance of node.js or bun is not because of the application layer. It’s the result of the JS engines neither embedding environment is involved in any of performance sensitive work.
As an outside observer (with a partner that is a front-end dev) I’ve not seen this at all. From what I’ve seen TS remains extremely popular. Anyone in the space seen otherwise?
Nope. I’ve just seen a bunch of frontend developers who were initially skeptical and now their code looks like Haskell code golf.
They may be going overboard now but as new converts to the wonderful world of typing they are enthusiastic.
I honestly think the typescript type system is just very well designed and ergonomic. I say that as someone who writes a lot more go than typescript. I also lived through the days of 1/2 assed type documentation in comments in JavaScript and Python. I believe the current state is better.
What does this mean? Lots of interfaces? Weird infix operators?
This is probably a reference to the common convention in TypeScript to give type variables single letter names. That combined with complex types (e.g. those using ternaries,
infer, etc.) tends to be very hard to read. This is mitigated somewhat by using more descriptive type names. For example:…vs…
I was making a joke more about very complicated higher order type programming. Although maybe C++ template abuse would be a better joke. Stuff like this:
Anecdotally, this is certainly not the case for me. I was very skeptical for years. I thought it’d be another CoffeeScript and kept waiting for an eslint-plugin-jsdocs-like solution to come along. Now that I’ve been using TypeScript regularly for a couple of years, I find myself starting all new projects in it and even slowly porting old projects to it as well. I would even plead guilty to occasionally going overboard with types, but overall, I’ve found it to be possible to get near Elm-levels of runtime errors (close to none). Overhauling data structures and doing major refactoring is a relative breeze now. Full “erasability” is turning out to be an excellent design goal and should make it possible for JS runtimes to run TypeScript without a build step.
it’s ubiquitous with little signs of decline. Further the ecma proposal referenced in quote is nowhere close to being accepted (if ever): https://github.com/tc39/proposal-type-annotations
Sass is a huge success, like jQuery. All of its features have been adopted by real CSS. The tool itself has less reason to exist in new projects as a result, but it absolutely won as a historical matter.
I think that’s the point. The success criteria for something in this space is that the need for it goes away: it provides a bunch of things that fix limitations one layer down and then those fixes are adopted in the underlying system. As such, baking something in this category into a system is a bad idea because its goal is (or, at least, should be) to obsolete itself.
Ernie Miller gave a great talk about this idea a few years back: Lies
TIL Firefox recently shipped nested selectors!
I’m not a JS developer really, but IMO the almost-unspoken benefit that the Bun project would bring is breaking the implementation monopoly, particularly as it’s not based around V8 - so you have competing implementations down to the actual JavaScript engine itself.
Additionally - claiming that a JavaScript runtime is not “production ready” because it doesn’t run on Windows is kind of fucking bizarre, and mentioning “90% of people use Windows” doesn’t help your argument, because 90% of computer users will probably never use a JavaScript runtime on their computer.
Like it or not in web development, developer use of macOS is often considered the “default” choice. Linux desktops are more popular than ever and Windows has built in Microsoft-supported means to run a Linux VM easily.
Depends a lot on what it’s used for. If it’s for server use, Windows folks will probably use WSL / WSL2 and deploy on Linux (though Azure Functions has Windows runners that can run Node.js functions on Windows). Mac developers may run Linux via Docker / Podman and deploy on Linux, or may develop natively and just fix Linux weirdness close to deployment time.
If you’re looking at something like Electron, I would suspect that the vast majority of uses are on Windows. Electron is basically Chromium + Node.js and might be the most widely deployed instance of Node (I suspect that the average number of Electron apps on a Windows machine is greater than one).
That sounds like a bit of a straw man to me. AFAIK even the projects making use of Electron, don’t directly control the nodejs runtime that gets used for their eventual application, it’s an inherent part of Electron (ie you can’t “bring your own nodejs”).
Something doesn’t have to be production ready for every single use-case it might hypothetically be usable for, before it can be considered production-ready.
[Comment removed by author]
I think it’s good to reflect on these things, but I strongly disagree. Bun is a much bigger deal than Yarn ever was. It’s not just a replacement for npm, it’s a replacement for node, npm, babel, webpack/esbuild, and jest. Even if npm catches up in performance (big if), there’s a lot of value in having an all-in-one tool that provides a great developer experience. I find it a breath of fresh air compared to the status quo of creating a JS/TS project, and I’m glad it’s introducing more competition into the space.
I keep using yarn out of inertia, but I really should switch to just plain NPM at this point.
Using new features is not tech debt. That’s not what that phrase means at all
I thought the argument in favour of bun was that it gave you a non v8 node environment?
Making Node conceptually a runtime with multiple implementations.
Because let’s be clear the speed and performance of node.js or bun is not because of the application layer. It’s the result of the JS engines neither embedding environment is involved in any of performance sensitive work.