Insights from Adopting TypeScript at Scale
techatbloomberg.com
Insights from Adopting TypeScript at Scale
1–10 of 107 posts
Re: Insights from Adopting TypeScript at Scale
#2I thought Bloomberg was into Bucklescript/ReasonML. Warring factions?!
Re: Insights from Adopting TypeScript at Scale
#3Oh 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 pathetically bad that I want to rage quit like I did before.
Re: Insights from Adopting TypeScript at Scale
#4Oh 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…
C++ is still very much used, along with Python. These languages are generally used for the overwhelming majority of our backend services.
JS/TS are used in the Terminal's view layer. You can make services in these languages as well, AFAIK, but I don't think it is very common.
Re: Insights from Adopting TypeScript at Scale
#5I've seen some shops do things like this. Making their own tools to get around odd shitshows they've gotten themselves into. I suspect that there are a number of people within the org that aren't fans of Webpack or some other set of tools that would have made some of their decisions end up with the consequences in the article. They didn't quite state it but I suspect they're trying to use a specific stack instead of a more obvious stack to make typescript work.
edit: just adding though, that this isn't surprising with a dev base of 2000 js developers.
Re: Insights from Adopting TypeScript at Scale
#6I've seen some shops do things like this. Making their own tools to get around odd shitshows they've gotten themselves into. I suspect that there are a number of people within the org that aren't fans of Webpack or some other set of tools that would have made some of their decisions end up with the consequences in the article. They didn't quite state it but I suspect they're trying to use a specific stack instead of…
The article mentions they have around 2000 engineers, at that scale investing in custom tooling can easily become a significant net gain in productivity and stability, especially when dealing with the JS ecosystem.
Re: Insights from Adopting TypeScript at Scale
#7I've seen some shops do things like this. Making their own tools to get around odd shitshows they've gotten themselves into. I suspect that there are a number of people within the org that aren't fans of Webpack or some other set of tools that would have made some of their decisions end up with the consequences in the article. They didn't quite state it but I suspect they're trying to use a specific stack instead of…
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 evolution.
Re: Insights from Adopting TypeScript at Scale
#8I thought Bloomberg was into Bucklescript/ReasonML. Warring factions?!
Can't beat better ecosystem, better integration with the ecosystem and let other company(Microsoft) do the work for you.
Re: Insights from Adopting TypeScript at Scale
#9I've seen some shops do things like this. Making their own tools to get around odd shitshows they've gotten themselves into. I suspect that there are a number of people within the org that aren't fans of Webpack or some other set of tools that would have made some of their decisions end up with the consequences in the article. They didn't quite state it but I suspect they're trying to use a specific stack instead of…
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 ECMAScript, e.g. preventing the use of "experimentalDecorators".
Re: Insights from Adopting TypeScript at Scale
#10I've seen some shops do things like this. Making their own tools to get around odd shitshows they've gotten themselves into. I suspect that there are a number of people within the org that aren't fans of Webpack or some other set of tools that would have made some of their decisions end up with the consequences in the article. They didn't quite state it but I suspect they're trying to use a specific stack instead of…
The article mentions they have around 2000 engineers, at that scale investing in custom tooling can easily become a significant net gain in productivity and stability, especially when dealing with the JS ecosystem.
Agreed. The article touches on this. When you have hundreds of projects that all target the same tightly-managed evergreen runtime, there's not much justification for having each project select and maintain a different toolchain. It just leads to the same problems being solved over again, and makes it harder for developers to switch between projects.
The fact that we can consider high-quality sourcemaps a solved problem (during both debugging and consolidated crash telemetry) really helps developers focus on building functionality rather than debugging a build system.
I think most large companies have dedicated tooling teams for these kinds of reasons. A related viewpoint in a related thread: https://www.reddit.com/r/typescript/comments/jrgi8z/10_insig...