This all comes with a Titantic-iceberg-sized caveat, however. (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.) 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. Note - it doesn't need to be specifically Chromium or specifically Node. 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. Yes to Chromium, not so much for anything specifically MS-related. This was an informative and interesting read, and I'm grateful you guys published it. 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 ] ? stuff to get it to infer correctly in some situations where I want things to be as generic as possible. 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. 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). This is the kind of work that gets me excited to live every day. If you guys are ever hiring, I'd do anything to be apart of such an innovative place!
0 kommentar(er)
