Live data from Hacker News

Insights from Adopting TypeScript at Scale

techatbloomberg.com

21–30 of 107 posts

Re: Insights from Adopting TypeScript at Scale

#21
post #18

Earlier quoted context omitted.

The TypeScript ecosystem is amazing - partly because of the large number of users also also because of the sense of community. It is run as a true OSS project. Roadmaps are release plans are all public on GitHub. Even as outsiders we've been able to contribute significant features, e.g. Private Fields in TypeScript 3.8. https://devblogs.microsoft.com/typescript/announcing-typescr...

Yeah TypeScript it's the only thing that makes me hate/doubt M$ a little less...

What about VS Code?

Re: Insights from Adopting TypeScript at Scale

#22
post #18

Earlier quoted context omitted.

The TypeScript ecosystem is amazing - partly because of the large number of users also also because of the sense of community. It is run as a true OSS project. Roadmaps are release plans are all public on GitHub. Even as outsiders we've been able to contribute significant features, e.g. Private Fields in TypeScript 3.8. https://devblogs.microsoft.com/typescript/announcing-typescr...

Yeah TypeScript it's the only thing that makes me hate/doubt M$ a little less...

TypeScript was in the right place at the right time, and the team prioritized the right features in the beginning, allowing for the great adoption.

But I'd still place TypeScript firmly in the "worse is better" category (products that are technically inferior then the state of the art, but succeed due to circumstance), it's a band aid on top of a the broken JS ecosystem. Its ad-hoc, Hodge-Podge type system and poor meta-programming is sad to see for such a popular language.

I'd rather write TypeScript then JS, but as soon as there's an opportunity to write software that works across all platforms without dealing with JS, and with a type system that's actually built on a solid foundation, I'm taking it.

Re: Insights from Adopting TypeScript at Scale

#23
post #11

What is the proportion of JS libraries in the wild which provide TS type declaration files, either via DefinitelyTyped or provided by the lib itself? Is it normal to have to write your own declarations, or do most libs provide them these days?

As an outsider I'm puzzled how any TS library repo keeps up with the pace of change in TS. With JS you can more or less write it once.

Re: Insights from Adopting TypeScript at Scale

#24

"9. Generated declarations can inline types from dependencies" Why do they generate .d.ts files instead of publishing .ts files alongside .js files? This should solve inlining issue, no?

That's an excellent suggestion! It's true you could just have every package publish the raw TypeScript source-code. So that when an app imports a library, it type-checks against the original source code of the library. No need for DTS files from your dependencies! I have never seen this done in practice for a large system. It's not as scalable as using bare-minimum type declarations that you find in DTS files. It req…

It works quite well, you can forget about src/ lib/ directories, just structure package as you want (ie files at the root), generate js files along ts in the same directory (relative paths to assets stay the same, import paths are the same in js/ts, very useful), add in vscode rule to auto hide .js file if .ts with the same name exists `{"files.exclude":{"/*.js":{"when":"$(basename).ts"}}}` - coding is pleasure, you just see and work with ts, no need to generate js files most of the time (on prepublish yes) etc.

Re: Insights from Adopting TypeScript at Scale

#25
post #23
post #11

What is the proportion of JS libraries in the wild which provide TS type declaration files, either via DefinitelyTyped or provided by the lib itself? Is it normal to have to write your own declarations, or do most libs provide them these days?

As an outsider I'm puzzled how any TS library repo keeps up with the pace of change in TS. With JS you can more or less write it once.

Whilst TS does technically contain breaks, these are normally simple increases in the power of the type-checking. It's finding more errors in code that previous seemed fine. Think of it like adding more ESlint rules.

It's rare for there to be a breaking change in the JS emit.

The TypeScript team work hard to preserve compatibility. Breaking changes are explicitly managed and communicated ahead of time. There is a concept of a breakage-budget per-release. This means if you stay up to date, the cost of each upgrade should not be huge. Orta and Nathan on the TypeScript team talk about this in this podcast episode: https://dev.to/devteam/devnews-s1e4-typescript-4-0-gitee-chr...

So "keeping up" is not too hard.

Re: Insights from Adopting TypeScript at Scale

#26

Oh wow they went from C/C++ to JavaScript? That's just trading one dangerous footgun for another. Glad to see they finally found a better tool. I can't function in JavaScript without Typescript...I constantly have to be looking up docs cause I don't have intellisense, and once something works I'm terrified to ever touch it again. Typescript made front end development reasonable again...not perfect, but not so patheti…

That seems to be pretty common statement about JavaScript, but strangely not one I share. I have been programming since the early 80s, and my experience with JS has been pretty positive, especially compared to the slog through the unreadable mud that is enterprise Java. (If I was going to rage quit on something, it would be the verbose, obtuse, repetitive Java sludge I’ve had to read the last decade and a half) Types…

Have you used TS much? In my experience idiomatic TS isn't much different to idiomatic JS and a far cry from Java style OOP code (the Angular ecosystem which was admitedly an early adopter of TS is an exception and best avoided).

Re: Insights from Adopting TypeScript at Scale

#27

Earlier quoted context omitted.

I think the key here is: > Back in 2005, the company started migrating those apps from Fortran and C/C++ to server-side JavaScript Since their use of Javascript predates Node (and the rest of that ecosystem, like Webpack or Babel or whatever), they've built up their own Javascript environment that doesn't rely on Node or Node conventions at all. Not so much a "get around odd shitshows" situation as much as a parallel…

Yes - you deduced correctly! There was a long period of parallel evolution. Over the last few years we've been able to get back on the standards track. The article describes this as one of the guiding principles. It's why we participate in TC39. Nowadays our tooling stack now uses TypeScript, Babel, Rollup & Terser which I regard as the most mainstream of choices. And we go out of our way to keep things aligned with…

Bloomberg often gets accused of "not invented here" syndrome. But often times in the past, it's been the case that what they need hasn't been invented yet.

Re: Insights from Adopting TypeScript at Scale

#28

Oh wow they went from C/C++ to JavaScript? That's just trading one dangerous footgun for another. Glad to see they finally found a better tool. I can't function in JavaScript without Typescript...I constantly have to be looking up docs cause I don't have intellisense, and once something works I'm terrified to ever touch it again. Typescript made front end development reasonable again...not perfect, but not so patheti…

That seems to be pretty common statement about JavaScript, but strangely not one I share. I have been programming since the early 80s, and my experience with JS has been pretty positive, especially compared to the slog through the unreadable mud that is enterprise Java. (If I was going to rage quit on something, it would be the verbose, obtuse, repetitive Java sludge I’ve had to read the last decade and a half) Types…

> I hope TS doesn’t turn JS into Enterprise Java, The Next Generation.

No chance. And frankly, I don't get the comparison you are making to C++/Java/C#. TS is fundamentally different than those languages. From structural typing to a default functional/imperative paradigm, it really is just JS with better static analysis.

Your IDE is not as good for JS as it would be for TS. The entire impetus for TS is/was to provide better tooling/ergonomics around JS. Whether or not you need better tooling is a subjective matter.

Re: Insights from Adopting TypeScript at Scale

#29

Oh wow they went from C/C++ to JavaScript? That's just trading one dangerous footgun for another. Glad to see they finally found a better tool. I can't function in JavaScript without Typescript...I constantly have to be looking up docs cause I don't have intellisense, and once something works I'm terrified to ever touch it again. Typescript made front end development reasonable again...not perfect, but not so patheti…

That seems to be pretty common statement about JavaScript, but strangely not one I share. I have been programming since the early 80s, and my experience with JS has been pretty positive, especially compared to the slog through the unreadable mud that is enterprise Java. (If I was going to rage quit on something, it would be the verbose, obtuse, repetitive Java sludge I’ve had to read the last decade and a half) Types…

> The Jetbrains IDEs do autocomplete just fine on vanilla JS

I find that hard to believe because it's not a solvable problem without type annotations.

Re: Insights from Adopting TypeScript at Scale

#30

Oh wow they went from C/C++ to JavaScript? That's just trading one dangerous footgun for another. Glad to see they finally found a better tool. I can't function in JavaScript without Typescript...I constantly have to be looking up docs cause I don't have intellisense, and once something works I'm terrified to ever touch it again. Typescript made front end development reasonable again...not perfect, but not so patheti…

Fashion.
Post reply on HN