8 ms·
How we failed, then succeeded, at migrating to TypeScript
- AriaMinaei 7y agoI was looking at some of my old repos today. Enjoyed the nostalgia. Lots of CoffeeScript there. I had to switch to ES and then TypeScript because CoffeeScript was abandoned at the time and I was stretched over other projects to be able to help maintain it. Reading my old code, I was surprised by how clean it looks. How easy it is to digest. There is a certain sense of calm when your brain doesn't have to process all the visual clutter of a C-style syntax. I miss that. I wish I didn't have to choose between CoffeeScript and TypeScript. TypeScript first and foremost is about type safety and tooling. Its architecture is largely syntax-agnostic. It operates on the AST, so the parser and code generator can be swapped for a different syntax. CoffeeScript is all about syntax and does not (and should not) concern itself with most of the semantics. They could theoretically be used together if TypeScript simply allowed custom parsers/generators/formatters to be plugged in. This would work with ESLint and other JS tooling as well. I did a POC on that a few years ago [0]. [0] https://github.com/gkz/LiveScript/issues/821#issuecomment-183640299 https://github.com/gkz/LiveScript/issues/821#issuecomment-18...
- switz 7y agoYou just gave me an idea.. because we've shared a similar experience. I really miss the elegance of Coffeescript. ES6 is great, Typescript is great, but sometimes I feel like I have to visually parse a lot of static cruft to read the essence of the program. What if one's editor had a toggle hotkey to hide typescript typings. Maybe you could turn it off to visually parse the program real quick, before turning it back on to edit it. Hmm...
- AriaMinaei 7y agoYou're getting in the realm of "projectional editing." It's a fascinating idea: https://news.ycombinator.com/item?id=15534555 https://news.ycombinator.com/item?id=15534555
- minxomat 7y agoYep. You can take MPS today and implement an AST projection that looks like whatever you want. No parsing involved, impossible to even write syntactically invalid code (since it is not code you're writing, but an AST projection).
- switz 7y agoI love reading about stuff like this, thanks for sharing. Developer UX still has a lot of room to grow.
- gherkinnn 7y agoInteresting. I sometimes wish to only see the types and get rid of the rest.
- droidist2 7y agoWhat about instead maintaining the type definitions in a separate file, and then having the editor add in the type hinting?
- sa46 7y ago> How easy it is to digest I’ve not had this experience. I’ve found the ambiguity in coffeescript a maddening adventure in syntax confusion. - function call syntax doesn’t need parens except if a 0 parameter method - commas are largely optional both in arrays and function parameters. How do you parse: [f, f(), f a b c] - implicit returns are a terrible idea. - the @ syntax refers to either a ‘static’ method or an instance variable depending on the context. - I have to do a double take for the object literal syntax every time
- AriaMinaei 7y agoDon't want to invalidate your experience. For me though, I rarely struggled with ambiguity. > function call syntax doesn’t need parens except if a 0 parameter method Function call syntax doesn't require parens so to make multi-line calls punctuation-free. Especially if some args are objects. > commas are largely optional both in arrays and function parameters. How do you parse: [f, f(), f a b c] Well commas are not optional. > implicit returns are a terrible idea They're especially elegant in writing declarative code. It takes some getting used to though. > the @ syntax refers to either a ‘static’ method or an instance variable depending on the context. Agreed. These are all tradeoffs though. For me, they struck the right balance between ambiguity (very little) and expressiveness. LiveScript in comparison was much more sugary (which I preferred): https://livescript.net/ https://livescript.net/
- k__ 7y agoHaha, yes. LiveScript should have won. It were awesome times. Well, guess it's Reason for me now :D
- Jare 7y agoI was very excited about CS when I learned about it, and in my initial tests found it really pleasant to write. However, before committing to using it more, I went and read some other projects written in it. At that point I decided that the reading experience was confusing, and the lack of "visible" syntax elements to guide me drove me nuts.
- dagw 7y ago
- zachrose 7y agoIf you want the quiet syntax of CoffeeScript and even better type safety than TypeScript, you might be interested in Elm. https://guide.elm-lang.org/ https://guide.elm-lang.org/
- AriaMinaei 7y agoI love Elm. Never got to use it in production though. Can't afford to get even further from the metal :)
- The_rationalist 7y agoElm is not compatible with js library or at least it's not seamless.
- zachrose 7y agoYeah well, sometimes js library isn’t compatible with js library either
- k__ 7y agoCS is what happens when you let Ruby devs write JS. TS is what happens when you let .net devs write JS. Let's see how that turns out in the long run.
- Waterluvian 7y agoTypeScript is so syntax heavy. But my perspective is that there are costs incurred at time of development and maintenance in return for stability at runtime. And I think the latter is far more important if you're writing production code. When it comes to experimentation, I love Javascript and Python because of how fast they are to write when you're not thinking hard about types. Then it's just discipline to know how to promote experiments to production code. TypeScript is beautiful because you can just turn it on and add them in. Same with Python type hints.
- pointerpointer 7y ago> Reading my old code, I was surprised by how clean it looks. How easy it is to digest. There is a certain sense of calm when your brain doesn't have to process all the visual clutter of a C-style syntax. I miss that. Indeed, Coffeescript is one of the finest languages I wrote in. Consider that 95% of the time we are reading code, what is the win of TS with a linter? The TS codebases I've worked on really hurt my eyes and brain, and that for some stupid website where type safety hardly makes any difference at all. And all those average web developers I've worked with bragging about type safety while the code they are producing is full of wrong constructs, bad naming, dependent on heavy tooling, etc..
- gingerlime 7y agoWe’re now considering switching from coffeescript to ES6 (or maybe also Typescript). But coffeescript is seeing a bit of a revival, and I’m starting to wonder if we should stick with it?? Tooling seems a bit behind and also lacking things like tree shaking etc (??). But coffeescript is so clean and fun... Any tips/thoughts??
- davidjnelson 7y agoDepends on your team size. 5+ engineers and need to refactor things? Typescript will make those needs far easier. Tooling support is amazing, for things like autocomplete, module import insertion and sorting, symbol renaming, function extraction, linting capabilities, correctness of code after changing designs. There’s some learning around how to type things, but not too hard and very worth it. Need at least one teammate / leader who has used c++/java/c#/etc. extensively on large codebases to mentor others. Teams of one, es6 is fine, typescript setup is probably overkill, especially for an mvp.
- eropple 7y agoDunno about you, but I do all of the things you mentioned, regularly, on a solo project. My test burden is greatly shrunken (getting rid of all those “did I pass sane args?” tests that one needs between modules) and I have much more confidence that I’m not shipping broken stuff. I don’t think writing TypeScript actually takes longer once you’re practiced and it eliminates entire categories of error. YMMV, of course, but in 2019 it’s hard for me not to think of a new JavaScript project as somewhat unserious.
- davidjnelson 7y agoI agree, it doesn’t take me personally any longer to write typescript. In fact, it saves me tons of time and endless headaches. I _love_ typescript and use it at work in react and have used it in node for side projects. The benefits are incredible as you mentioned! I guess it depends on what you’re doing. Setting up the tooling can sometimes be a bit of a pain in combination with other tools which are not designed with typescript in mind from the get go, such as react_on_rails. If you’re doing a quick mvp in a weekend, I’m still not sure typescript is right. But it really depends on what other tools you are using and how well they integrate. If the mvp works, ya, definitely switch to typescript ASAP. That’s a fine line and really depends on the use case.
- deleted 7y ago[deleted]
- seieste 7y agoTypescript seems to be approaching C++ levels of syntax and expressiveness. The main difference seems to be the existing tooling, tutorials, libraries, etc for node.js and others. But if compiled languages like C++ or Go had as many dedicated libraries for webserver management as JavaScript, would there really be a benefit to using Typescript?
- crooked-v 7y agoYes, because you can't run C++ in the client, while some Node libraries can now use the same code for pre-rendering pages on the server or rendering new pages on the client. This gets you the best of both worlds, where a first load or refresh has the page content baked in like a traditional static site, but once it loads you get faster naetvigation and live content updates. (WASM and WAPI might eventually let you run WASM-compiled C++ in the client, but there's still a lot up in the air for interop purposes there.)
- mschuetz 7y agoYes, build times of a few seconds instead of minutes. Easier and more robust "write once, run everywhere". Integrating third party libraries in a matter of minutes instead of hours, sometimes days. Generally much faster prototyping capabilities. And so on.
- longcommonname 7y agoShort build times come with less compile time checking. You can get cpp programs down to seconds for incremental builds with good management while having compile time checking.
- throwaway_bad 7y ago> Typescript seems to be approaching C++ levels of syntax I've been a bit traumatized by C++ so I can't help but see this as a bad thing. A lot of the insanity in C++ is because template metaprogramming made a lot of micro-optimizations possible. You can use CRTP to achieve static polymorphism. You can use SFINAE for tag dispatch to choose a different algorithm at compile time. You can even fold entire algorithms down to a constant with constexpr. This is great if you care about low level control of your code, but this is usually premature optimization in the JS world. Luckily typescript will be immune to this because the types can't affect runtime at all. So far I haven't seen any truly monstrous generics that are so prevalent in C++.
- davidjnelson 7y ago> The most important realisation we had going into this renewed effort was that a successful migration has to be centered around people, not just tech. Key insight. It’s always people first, code is a far distant second. Love Kent Beck’s series on this, so insightful https://medium.com/@kentbeck_7670/software-design-is-human-relationships-part-3-of-3-changers-changers-20eeac7846e0 https://medium.com/@kentbeck_7670/software-design-is-human-r... Great read, Heap team! Thanks for sharing :-D
- pointerpointer 7y ago> It’s always people first, code is a far distant second. I'm afraid that's kinda political. In order to get the migration successful, hmm.. I assume developers did not have much of a choice, either accept it or leave. You can try to brainwash them by impose your subjective point of view in a friendly way, but in the end it's all about power, that's the untold story.
- EdwardDiego 7y agoI routinely bore people with the Abelson quote that programs are written for humans to read and only incidentally for computers to execute.
- Scarbutt 7y agoYes, we were adding TypeScript code, but we were adding CoffeeScript at a faster rate So the devs were able to iterate faster with CS than with TS?
- breakingcups 7y agoAnother interpretation would be that a majority still picked Coffeescript out of familiarity and interop issues in their specific codebase. Iteration speed could be comparable or better in Typescript too, we don't know.
- karthikshan 7y agoOften the reason is as simple as "This file I'm adding to is in coffeescript and I don't want to convert it right now"
- RangerScience 7y agoAFAIK, Ruby is the only language that people make other languages look like (CoffeeScript) and JS is the only language that people make look like other languages (CS, TS). Are there others? Edit: Well, I guess the JVM would be considered another?
- pointerpointer 7y ago> Yes, we were adding TypeScript code, but we were adding CoffeeScript at a faster rate. Unsurprisingly. > how do we get our coworkers to buy in to this new paradigm? By forcing them? > and we’re all happy to spend hours figuring out exactly how we’ll set up our TypeScript config. Oh yes what a joy! > our data access layer (“ORM”) is ubiquitous, and most files use it in some way. Use SQL instead, it's better. > We also made tooling and configuration a priority. Of course, there's no way to go down the TS rabbit hole without it! > Finally, we converged on a set of agreed upon linting rules The code soup that's generated with the 'airbnb' setting, I know it's a terrible read. > When we began analyzing TypeScript adoption patterns, it became clear that using TypeScript wasn’t a seamless process for our engineers, who would often need to import special utilities (ts-node/register) or create intermediate CoffeeScript files that did nothing but import their TypeScript equivalents. How productive! > We avoided using any in this phase, instead opting for the stricter unknown. Yes, the dream of type safety ends with using 'any' or 'unknown'. But are you sure only in this phase? I've never seen a TS codebase without it! > Tackling a migration like this means asking your teammates to give up a way of doing their jobs that they’re comfortable and effective with So tell me, no one left because they didn't like to have the joy sucked out of their lives? > To do this we created a #typescript channel in Slack, and made sure developers getting stuck could get unblocked. Another great addition to the workflow. But you mean 'stuck' like you cannot continue building because of TS? I only hear from TS proponents that it improves productivity? > From the beginning, we knew that bulk, overnight migration was not a possibility, and that it would likely take a year or more to complete the process. Ok, so more than a year with the entire team to kill a few type related bugs? How did you have to lie to get this agreed upon by the CEO? > As we continue with this migration, we hope to keep learning, and to use this knowledge to make the next big project even easier. Yes, keep learning because soon TS will be exit with the upcoming WebAssembly and you can start all over again in another hyped language or framework. But for the record, instead of fixing a few type errors a once in a while and create proper tests for it, you went rewriting the entire app and fucking up your entire dev team that were happy with Coffeescript? I'm also really curious how much this entire operation has cost the company, and what the actual benefits are? Is it that the dev now can hover with his mouse over a variable see the related type? Or is the app really looking and working much better now? Always when I worked on a TS project the benefits were mostly imaginary and the pain real. Unfortunately there are way too many inexperienced web developers that think they look incredibly smart doing TS.. Vanity is a thing. Doing a dynamically typed language is for the poor minds that don't understand type safety, not? You are all way smarter than Brendan Eich I guess.