Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Insights from Adopting TypeScript at Scale

techatbloomberg.com

Post reply on HN
Print view View original

51–60 of 107 posts

Re: Insights from Adopting TypeScript at Scale

#51

Post by evmar »

robpalmer wrote: post #17
mirekrusin wrote: post #14

"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…

Another consideration is that it only works if all the code agrees on tsconfig settings (e.g. strictness settings and path resolution). That can work in a monorepo but won't work if you mix libraries.

Re: Insights from Adopting TypeScript at Scale

#52

Post by spaetzleesser »

Chris_Newton wrote: post #31

Interesting how much emphasis they seem to place on treating TS as precisely JS + types and nothing more, even to the extent of excluding evolutionary TS features. That does seem a reasonable argument for avoiding enum types in TS. Those have semantics that go beyond how enumerations work in most languages and implementing them in the underlying JS is going to introduce some runtime cost. I wonder whether their codin…

“ Those have semantics that go beyond how enumerations work in most languages and implementing them in the underlying JS is going to introduce some runtime cost.”

Do you think this runtime cost will make much of a difference compared to everything else that goes on in the code? My impression that in the last few years the pure code performance is so fast that it almost doesn’t matter much anymore. Of course unless you manage to do incredibly stupid things.

Re: Insights from Adopting TypeScript at Scale

#53

Post by jariel »

It seems what they really want is something that is not javascript.

The TS team was adamant they wanted to not be a runtime, i.e. it was JS + Typing only.

Partly I wish they just dumped ECMA and just made TS proper, but perhaps that's just Dart.

Re: Insights from Adopting TypeScript at Scale

#54

Post by mistersys »

munificent wrote: post #39
mistersys wrote: post #22

Earlier quoted context omitted.

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 m…

> 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. I think it's important to distinguish between "worse is better" and path dependence, which is what you're getting at here. "Worse is better" is a blank slate design philosophy. It says a syste…

Yeah, I agree it was lazy of me define "worse is better" the way I did, I think they're 2 separate thoughts, but I still think TypeScript uses the "worse is better" approach to design, in the sense that C used it.

My usage of "worse is better" means "worse is more marketable, and easier to implement", as opposed to actually being better when adopted. The original use of "worse is better" was not advocating for it as a design style in the general case, but commenting on the survival and adoption characteristics of systems designed in this style, as well as that it's often a good approach in the beginning of a project.

TypeScript makes a simple promise, add types to your existing code base using an easy to understand structural type system, and it works on top of JS, just as C was designed as simple layer on top of Assembler.

If C ("Worse is Better") is now being disrupted by Rust ("The Right Thing"), I think we'll see a similar player for JS / TypeScript.

If you're in a position where you can decide what stack a large swath of developers are going to use, you should perhaps keep an eye open to JS / TypeScript alternatives with growing ecosystems. Your choice could turn into a competitive advantage, even if it means a smaller community in the beginning.

Re: Insights from Adopting TypeScript at Scale

#55

Post by no_wizard »

I envy this. If you guys are ever hiring, I'd do anything to be apart of such an innovative place!

This is the kind of work that gets me excited to live every day.

This really shows though, to the point of the article, that TypeScript at scale really lives up to its name, albeit with some quarks (and in this case, some of those quarks are also due to the environment it operates in). I have also found over the years my experience has been positive when you adopt, most notably, the points about keeping all your packages across projects/repos up to date, particularly keep your TS versions rolling upward to prevent definiftion file incompatabilities is necessary.

I'm curious though, as I'm sure there are several authored libraries (not every repo I assume is a pure app), do you guys run into issues where you have to use a lot of complex typings (like using a function type to infer a given type even though the type you're inferring isn't a function, and other type dances) or has this not been the case? I've not had much of an issue with this, though I've had to do some pretty complex extends [[type]] ? stuff to get it to infer correctly in some situations where I want things to be as generic as possible.

This was an informative and interesting read, and I'm grateful you guys published it. Keep up the excellent work!

Re: Insights from Adopting TypeScript at Scale

#56

Post by smrtinsert »

Roboprog wrote: post #20
darksaints wrote: post #3

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…

For simple method and field references sure, but once you push it with method chains and transformations it becomes pretty underwhelming quickly. Typescript also isn't invincible to this, but it's better. If you are going into a small well scoped code base vanilla js should be fine. For a large code base with plenty of package sharing, good luck in either. To me the investment in TS sounds like someone crossed their arms and said "I'm not doing java". Their loss, as a java dev I rarely think about languages. Stuff gets done fast, with few or no errors and no need for special tooling or forced approaches. Kotlin is an area of interest for me these days but that's about it.

Re: Insights from Adopting TypeScript at Scale

#57

Post by erikerikson »

munificent wrote: post #37
jgalt212 wrote: post #27

Earlier quoted context omitted.

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.

Would that make it "invented here" syndrome?

Traditionally NIH is the reason for rejecting things. The inverse would be accepting things because they are invented here.

Re: Insights from Adopting TypeScript at Scale

#58

Post by uglycoyote »

ralmeida wrote: post #38
IshKebab wrote: post #29

Earlier quoted context omitted.

> 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.

Maybe not in the general case, but practically speaking, static analysis can infer the types of probably most completion you would need in day-to-day development.

This is contrary to my experience. For instance if the types of function parameters aren't specified, the IDE won't have any way of knowing what the types of those parameters are and will therefore not be helpful with completions.

Re: Insights from Adopting TypeScript at Scale

#59

Post by mirekrusin »

evmar wrote: post #51
robpalmer wrote: post #17

Earlier quoted context omitted.

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…

Another consideration is that it only works if all the code agrees on tsconfig settings (e.g. strictness settings and path resolution). That can work in a monorepo but won't work if you mix libraries.

Yes, they mention taking over tsconfig management because even generated .d.ts files are sensitive to tsconfig - article mentions type being different depending on the tsconfig setting.

But in general publishing the most strict ts should work fine when using from weaker tsconfig.

Personally I don't use custom path resolutions, can't comment on that.

ps. oh wait, but why does it matter? .d.ts file won't be different if you change strictness in tsconfig - why would it make difference for published .ts files?

Re: Insights from Adopting TypeScript at Scale

#60

Post by yaacov »

robpalmer wrote: post #9
JonathonW wrote: post #7

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…

Why did Bloomberg adopt server-side JS in 2005?
Post reply on HN