3 ms·
They don’t really mention the ongoing developer experience impact (even if it is outweighed by the popularity of TypeScript) of losing Skew’s niceties, they jus
by dgreensp 2y ago
They don’t really mention the ongoing developer experience impact (even if it is outweighed by the popularity of TypeScript) of losing Skew’s niceties, they just talk about the one-off transpilation of them when migrating the codebase. For example, the fact that it’s easy to end up with files that need to be imported in the right order in TypeScript, or things will break; or the fact that destructuring is slow and so should not be used (when performance is at all important). I know from using TypeScript for years that there are dozens of these gotchas (some inherited from JavaScript, some not), requiring an extensive style guide at the very least, especially if you have a lot of engineers.
I wonder if some engineers were sad to see Skew go.
- reasonableklout 2y agoIt was certainly important for us to make sure developers were happy with the result. That's why our rollout included stuff like a phase where developers continued writing Skew but their changes automatically checked-in generated TS. This way, devs could see what it would look like in PR review and report issues. As for performance and runtime correctness, you're right that there are some gotchas with TS. We caught issues like the array destructuring one with instrumentation and strict monitoring. I was definitely sad to see some features of Skew go. For example, operator overloading and integer types. But the move was ultimately a decision the whole team made, and I agree with them that it was the right one.