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

31–40 of 107 posts

Re: Insights from Adopting TypeScript at Scale

#31

Post by Chris_Newton »

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 coding standards still permit const enums, though, as they are also new relative to JS but work more like traditional enumerations in C-family languages. These ought to be entirely compiled away, so it seems like the same arguments around efficiency and portability/compatibility wouldn’t apply.

Re: Insights from Adopting TypeScript at Scale

#32

Post by lemming »

robpalmer wrote: post #25
cutler wrote: post #23

Earlier quoted context omitted.

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

Do the breaks tend to affect the TS declaration files, or are they more to the language itself?

Re: Insights from Adopting TypeScript at Scale

#33

Post by robpalmer »

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…

There isn't much of a difference between regular enum and const enum when it comes to the usage of the enum keyword. The big difference is what they compile to - where const enum evaporates by inlining the values into the usage sites.

enum is a keyword that is reserved in ECMAScript and therefore may one day clash with TypeScript. It's unlikely any ECMAScript-defined semantics for enum would match today's TypeScript enum. So it's not on any standards track.

There is already a proposal for JS enum that has different semantics to TS enum, and it was created by someone on the TypeScript team: https://github.com/rbuckton/proposal-enum

So the const form doesn't really change the hazard.

Re: Insights from Adopting TypeScript at Scale

#34

Post by robpalmer »

lemming wrote: post #32
robpalmer wrote: post #25

Earlier quoted context omitted.

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

Do the breaks tend to affect the TS declaration files, or are they more to the language itself?

The majority of breaks are due to the checker getting better. So code that passed now errors. Most of the time pre-existing published DTS files still operate fine.

Re: Insights from Adopting TypeScript at Scale

#37

Post by munificent »

jgalt212 wrote: post #27
robpalmer wrote: post #9

Earlier quoted context omitted.

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.

Would that make it "invented here" syndrome?

Re: Insights from Adopting TypeScript at Scale

#38

Post by ralmeida »

IshKebab wrote: post #29
Roboprog wrote: post #20

Earlier quoted context omitted.

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.

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.

Re: Insights from Adopting TypeScript at Scale

#39

Post by munificent »

mistersys wrote: post #22
agustif wrote: post #18

Earlier quoted context omitted.

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 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 system with more failures modes can be a better than a more robust system if allowing those failure modes keeps the system significantly simpler and more understandable to users. A bicycle is "worse is better" compared to a car. You have to check the tire pressure frequently, and clean the chain fairly often. But it's easy to put air in the tires and you can see the chain and tell when it needs to be cleaned.

"Path dependence" means your design is constrained by historical choices that don't benefit future users but are part of the reality you have to design for today. Train railway gauges today are not the best width for optimizing shipping efficiency. It was chosen in the 1800s before anyone really knew, and it's impossible to change because existing trains would be imcompatible with the new gauge.

TypeScript is an example of path dependence. If the world didn't have a few billion lines of JavaScript code, you could certainly design a better language. Simpler, cleaner, easier to statically type, more efficient. But the world does have all that JS code, and TS is the railway that can still run those old trains.

Re: Insights from Adopting TypeScript at Scale

#40

Post by Chris_Newton »

robpalmer wrote: post #33
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…

There isn't much of a difference between regular enum and const enum when it comes to the usage of the enum keyword. The big difference is what they compile to - where const enum evaporates by inlining the values into the usage sites. enum is a keyword that is reserved in ECMAScript and therefore may one day clash with TypeScript. It's unlikely any ECMAScript-defined semantics for enum would match today's TypeScript…

Interesting. So even though the const form isn’t affected by the same runtime considerations, you do still prohibit it because of the potential conflict with a future use of the enum keyword by JS? I can understand the reasoning there, particularly at the scale you’re operating at.

I wonder how likely it is that ECMAScript would introduce its own incompatible form of enum now that TS has become so popular. With static type checking as in TS, enums are very useful, but in the more dynamic environment of JS, the benefit is much smaller. So even if there’s nothing wrong with ECMAScript using its reserved keyword in principle, it feels like a bad idea to introduce a potential source of confusion and maybe subtle bugs when so many developers now use both languages.

Post reply on HN