4 ms·
Anecdotally, at Bloomberg we're in the middle of ramping up TypeScript support in our core server-side stack. Our custom IDE is Windows based, so it was very st
by apaprocki 10y ago
Anecdotally, at Bloomberg we're in the middle of ramping up TypeScript support in our core server-side stack. Our custom IDE is Windows based, so it was very straightforward to integrate the tserver into the workflow to give developers the choice of writing vanilla JS or TS with additional annotations we send down to the IDE for the core stack. We have the largest single collection of JS I'm aware of and we're eager to see TS take off as we iron out a few corner cases and really get 2,000+ devs using it daily. This isn't the web or Node, so make of it what you will -- but the tserver integration and ease of layering on top of the existing vanilla JS in a progressive manner made it a simple decision.
- jonursenbach 10y agoCurious, but why do you guys have a custom IDE?
- apaprocki 10y agoWe started using server-side JS around 2005 so things were a bit different back then. The main driving force for it was that we had to have WYSIWYG integration with the product and the only way we could achieve that was by embedding an HWND from the running product to ensure it wasn't some faked runtime that would behave slightly differently during development / in production.
- oblio 10y agoThat sounds really interesting. Could you give more details about your adoption plan? Which version of TS are you using? Are you planning to migrate to TS 2.0, when it comes out? In your experience so far, have the conversion done until now caught any bugs?
- apaprocki 10y agoIf I'm remembering correctly it first went live to some early adopters with 1.6.1 and it is using 1.8 now. We obviously want to track the latest releases as fast as we can because they bring new features we're interested in. I would need to ask some of the teams that tried converting larger projects specifically what they found that they felt was important. I'm certain TS would find some bugs in any sufficiently large project, but I'd have to go dig up data to know roughly how many or how serious they were. Just because there was a technical quality issue with the code doesn't mean that the vanilla JS version of it wasn't producing the actual desired result. It's hard to gather numbers for that type of thing. It's very similar to the let-down a lot of people feel with using static analyzers on mature, battle-tested C++ code for the first time. It will certainly find some nits, but most likely they were not that important to begin with.