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

101–107 of 107 posts

Re: Insights from Adopting TypeScript at Scale

#101

Post by hvidgaard »

thelazydogsback wrote: post #88
hvidgaard wrote: post #80

Earlier quoted context omitted.

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

I like the structural type system, but it's not my experience that the power of it is unquestionably a good idea to use for long lived projects. The simpler something is, the easier it is to maintain.

Re: Insights from Adopting TypeScript at Scale

#102

Post by SiVal »

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…

It wasn't an option back then, but now, if you wanted both a typed language and rapid code-build-run-debug for the server side, you could go even faster and simpler (snappy single-step compile to native executable) with Go. If you were starting now, would that work even better for you, or would other benefits of server-side JS outweigh the more complex toolchain and deployment?

Re: Insights from Adopting TypeScript at Scale

#103

Post by apaprocki »

SiVal wrote: post #102
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…

It wasn't an option back then, but now, if you wanted both a typed language and rapid code-build-run-debug for the server side, you could go even faster and simpler (snappy single-step compile to native executable) with Go. If you were starting now, would that work even better for you, or would other benefits of server-side JS outweigh the more complex toolchain and deployment?

One benefit of working with JS is that it was an easy transition to providing both client-side and server-side JS within the same application/project. Go would work on the server, but integrating it into a native MSVC Windows app, yet alone Chromium, would be... not fun.

Re: Insights from Adopting TypeScript at Scale

#104

Post by SiVal »

apaprocki wrote: post #103
SiVal wrote: post #102

Earlier quoted context omitted.

It wasn't an option back then, but now, if you wanted both a typed language and rapid code-build-run-debug for the server side, you could go even faster and simpler (snappy single-step compile to native executable) with Go. If you were starting now, would that work even better for you, or would other benefits of server-side JS outweigh the more complex toolchain and deployment?

One benefit of working with JS is that it was an easy transition to providing both client-side and server-side JS within the same application/project. Go would work on the server, but integrating it into a native MSVC Windows app, yet alone Chromium, would be... not fun.

This seems to imply something about the client side of your strategy that I wasn't aware of (but maybe I should have realized) that probably matters: that your clients will (almost?) all be Windows machines running the new-MS-strategy MSVC native apps written (at least partly) in JS, where "JS" on Windows now (as in Node) means Chromium specifically.

In a situation where you get to build the client all the way to the hardware, you're like Apple. You can probably get more advantage than most by matching client and server more deeply than the usual talk-to-the-API level. In your case, it sounds as though it's Microsoft's TS-in-Chromium spanning both.

Re: Insights from Adopting TypeScript at Scale

#105

Post by mirekrusin »

evmar wrote: post #98
mirekrusin wrote: post #59

Earlier quoted context omitted.

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

Suppose project B uses lax tsconfig settings. Now suppose strict project A imports from B. If A uses B via d.ts it may be ignorant of most of B's choices. But if A uses B as source, A's strictness settings will now attempt to apply to B.

But you can use compiler option skipLibCheck, right?

Re: Insights from Adopting TypeScript at Scale

#106

Post by thelazydogsback »

hvidgaard wrote: post #101
thelazydogsback wrote: post #88

Earlier quoted context omitted.

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

I like the structural type system, but it's not my experience that the power of it is unquestionably a good idea to use for long lived projects. The simpler something is, the easier it is to maintain.

Agree, but I think it excels at it's intended purpose, as a "gradually typed" system where types can be added at the various places, and inferred types that "meet in the middle" will structurally type as intended. If you want to simulate nominal typing in places, you can always use tagged unions, as TS now offers several different ways to do this. (However, this info will typically not get erased at run-time, so you get reflection whether you like it or not :))

Re: Insights from Adopting TypeScript at Scale

#107

Post by apaprocki »

SiVal wrote: post #104
apaprocki wrote: post #103

Earlier quoted context omitted.

One benefit of working with JS is that it was an easy transition to providing both client-side and server-side JS within the same application/project. Go would work on the server, but integrating it into a native MSVC Windows app, yet alone Chromium, would be... not fun.

This seems to imply something about the client side of your strategy that I wasn't aware of (but maybe I should have realized) that probably matters: that your clients will (almost?) all be Windows machines running the new-MS-strategy MSVC native apps written (at least partly) in JS, where "JS" on Windows now (as in Node) means Chromium specifically. In a situation where you get to build the client all the way to the…

Yes to Chromium, not so much for anything specifically MS-related. Using Chromium as a low-level GDI replacement lets you leverage higher-level constructs and work in web-space to implement rendering, and TS nicely spans between client-side Chromium and server-side V8.

Note -- it doesn't need to be specifically Chromium or specifically Node. It just so happens that Node bet on V8 and Chromium is embeddable, so you can get even more leverage out of using the two together. (We actually also use TS with server-side Spidermonkey as well, so TS has definitely proven itself as a better way to interop at the tooling level across these different implementations.)

This all comes with a Titantic-iceberg-sized caveat, however. Keeping up with Chromium is difficult. Any embedder is not Google and embedded use cases are not the web. You can leverage all the collective work put into making the web work quickly, but you have to back it up with your own resources to leverage the source and make changes and contributions where necessary.[1] It's definitely a balancing act!

[1]: https://github.com/bloomberg/chromium.bb/branches/active

Post reply on HN