Insights from Adopting TypeScript at Scale • Hacker News Board

Re: Insights from Adopting TypeScript at Scale

#81

Post by robpalmer » Thu, Nov 12, 2020, 12:03 PM UTC

cryptica wrote: post #74

coding123 wrote: post #5

I'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…

Corporations seem to be desperately trying to create more jobs at the moment. TypeScript, by being less efficient and adding complexity, allows massive job creation to take place. Nothing to do with bugs, efficiency, etc... It's all about job creation so that companies can justify receiving more, bigger government contracts and loans on favorable terms from banks and they get more political influence by coercing thei…

Busted.

It's true. The Big TypeScript lobby has been secretly working for years on a product called TypeScript Enterprise Edition. Many jobs will be created to support all those AbstractVirtualFactoryManagers.

Undeniable evidence: https://twitter.com/drosenwasser/status/1259946589902106624

This is just as serious as Bjarne Stroustrup's famous leaked interview in which he revealed why he created C++: https://www.stokely.com/lighter.side/stroustrup.html

Re: Insights from Adopting TypeScript at Scale

#82

Post by robpalmer » Thu, Nov 12, 2020, 12:19 PM UTC

spaetzleesser wrote: post #52

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

For our purposes, the primary problem with enums is not the runtime overhead. The runtime code for TS enums is a little verbose but it's not huge. The semantics are a little wacky as described in Axel Rauschmeyer's article: https://2ality.com/2020/01/typescript-enums.html

The primary problem is the potential conflict with future ECMAScript. Multiple TypeScript team members have talked about how this feature is now regretted. The article features Orta's famous meme-slide communicating why runtime features (specifically calling enum) should not really be in the TypeScript language. Anders talked about it three weeks ago during the Q&A session at TSConf: https://www.youtube.com/watch?v=vBJF0cJ_3G0

enum is highly unlikely to be removed from TypeScript because of the strong commitment to backwards compatibility. But that doesn't mean we should encourage proliferation. Especially when many use-cases can be served more simply by string unions.

  type Color = "red" | "blue" | "green";

Re: Insights from Adopting TypeScript at Scale

#83

Post by Chris_Newton » Thu, Nov 12, 2020, 12:23 PM UTC

spaetzleesser wrote: post #52

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

Do you think this runtime cost will make much of a difference compared to everything else that goes on in the code?

Perhaps not. It’s hard to imagine a program that you’d write in a language like JS in the first place where the small overhead of a look-up would be significant even for a feature as commonly used as enums.

However, there is a wider issue here than just whether to use one specific TS language feature or not. If you’re establishing principles that are going to affect thousands of developers working on thousands of different programs, which appears to be the case at Bloomberg from what I can see, then erring on the side of caution is a reasonable position to take. It’s difficult to objectively evaluate risk at that scale, whether from individually small but pervasive runtime performance hits or from potential future (in)compatibility with JS.

Re: Insights from Adopting TypeScript at Scale

#84

Post by robpalmer » Thu, Nov 12, 2020, 12:29 PM UTC

hvidgaard wrote: post #80

robpalmer wrote: post #76

Earlier quoted context omitted.

No one should interpret a deep-dive article like this to indicate a language monoculture - we also use many other languages on the server-side including Python and a lot of C++.

That is very true. But I still have a hard time to see the justifications of using JS on the server.

I'll offer one advantage we have nowadays, which is to permit writing and atomically deploying apps that have both client and server parts - there's no need to preserve compatibility or worry about coping with independent versions.

Our platform allows you to write this all inside one project - so the ability to use a single language across both sides helps app developers maintain mental flow and reduces context-switching. It's even better now that we have TypeScript to perform instant type-checking across the client-server boundary.

Gary Bernhardt shows off similar powers in his awesome video "End-to-End TypeScript: Database, Backend, API, and Frontend": https://www.youtube.com/watch?v=GrnBXhsr0ng

Re: Insights from Adopting TypeScript at Scale

#85

Post by robpalmer » Thu, Nov 12, 2020, 1:56 PM UTC

cryptica wrote: post #72

nicoburns wrote: post #26

Earlier quoted context omitted.

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

I used TS for several years and also don't like it. Nothing wrong with the language itself but the transpilation step adds significant complexity and is very slow so it breaks my train of thought and slows down my development iteration speed significantly. In addition to slow iteration speed, I got tired of encountering source mapping issues in some environments, version compatibility issues and TS config issues (esp…

This is interesting. The things you list as problems are the same set of things we tried to solve:

- automatic compilation that is fast

- sourcemaps work

- decoupling of packages to help compatibility

- automatic tsconfig management

I wonder if you would have a different conclusion with these things taken care of.

I agree that TypeScript makes it easier to have functions with complex parameters - because they are now documented and more understandable. So yes, this demands more discipline on the API designer to keep APIs simple.

Re: Insights from Adopting TypeScript at Scale

#86

Post by 0x445442 » Thu, Nov 12, 2020, 2:30 PM UTC

robpalmer wrote: post #67

exdsq wrote: post #63

Earlier quoted context omitted.

I really want to know the answer to this question, seems a hell of a risk to move to JS prior to Node (for me it’s still a risk even after node because JS!).

In the early 2000s it was recognized that the C/C++ code-build-run-debug development feedback loop was taking too long for efficient application development. 10-30 minutes to try out changes. It would have been risky not to try something new. JavaScript revolutionized this, bringing the developer feedback loop time back down to a few seconds. Andrew Paprocki's 2011 JSConf talk demonstrates this. https://www.youtube.c…

> The main competing technology at the time was Lua

The main competing technology for what exactly? I could easily think of 10 other server side choices off the top of my head from the 2005 time frame; like Java or C# to name a couple. Something is missing here.

Re: Insights from Adopting TypeScript at Scale

#87

Post by darksaints » Thu, Nov 12, 2020, 4:03 PM UTC

cryptica wrote: post #70

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…

What I've found is that senior developers with 10+ years of experience with many different paradigms and projects tend to enjoy JavaScript and many hate TypeScript (particularly because of the build step and complexity that it brings). But for some reason Microsoft is running a lot of propaganda campaigns to promote TypeScript. My guess is that they're trying to push all the JS devs to TS and then once they have enou…

I have found the exact opposite.

Re: Insights from Adopting TypeScript at Scale

#88

Post by thelazydogsback » Thu, Nov 12, 2020, 4:12 PM UTC

hvidgaard wrote: post #80

robpalmer wrote: post #76

Earlier quoted context omitted.

No one should interpret a deep-dive article like this to indicate a language monoculture - we also use many other languages on the server-side including Python and a lot of C++.

That is very true. But I still have a hard time to see the justifications of using JS on the server.

I think TS on the server is a great choice for all the reasons that make TS interesting -- esp. the expressive structural typing system which is not found in the other languages. What is missing is a better runtime that supports true shared-memory (w/o serialization overhead between workers) multi-threading (for async thread pools or true parallel workloads) like other modern servers. This would be ideal for me at the moment.

Re: Insights from Adopting TypeScript at Scale

#89

Post by addicted » Thu, Nov 12, 2020, 5:38 PM UTC

0x445442 wrote: post #86

robpalmer wrote: post #67

Earlier quoted context omitted.

In the early 2000s it was recognized that the C/C++ code-build-run-debug development feedback loop was taking too long for efficient application development. 10-30 minutes to try out changes. It would have been risky not to try something new. JavaScript revolutionized this, bringing the developer feedback loop time back down to a few seconds. Andrew Paprocki's 2011 JSConf talk demonstrates this. https://www.youtube.c…

> The main competing technology at the time was Lua The main competing technology for what exactly? I could easily think of 10 other server side choices off the top of my head from the 2005 time frame; like Java or C# to name a couple. Something is missing here.

Interpreted languages with no compile time it seems.

Re: Insights from Adopting TypeScript at Scale

#90

Post by addicted » Thu, Nov 12, 2020, 5:40 PM UTC

hvidgaard wrote: post #61

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…

I still cannot understand why anyone would use JavaScript for server-side components. Even Python would be a better choice at that point if you could get around its multithreading limitations (and if they can build their own node, they can). Java was a well proven tech at that point. My immediate thought is that by choosing JS, they attracted young (and cheap) developer.

They adopted in 2005. It was almost certainly the opposite then.

This predated node, and was just about the time GMail came into the picture.

It’s almost certain finding actual developers (As opposed to web designers with a sprinkling of JS knowledge) with JS experience was extremely difficult then, so it’s not likely to be a reason at all.