TypeScript adoption at work
I'm a more junior developer with just about three years of experience. Recently, we were given the go-ahead to start using TypeScript for a newer more green field project to test the waters. I think it's been a great experience, and has given me more confidence in the robustness of my code, and in the safety of my refactoring. Currently, something of a round table is happening where devs from various teams are being asked about whether we should use TS for a shared component library that is being started. There's some pushback from some of the more senior developers, in particular one who stated
"The kinds of errors that type safety is intended to assist in the prevention of are generally avoidable with good coding practices.".
Obviously I'm not going to die on this hill. I'm perfectly fine with the conclusion that different teams can make the decision for themselves, and that it should not be enforced necessarily. However, being a bit newer, I want to make sure I'm accurately presenting the biggest advantages. Does anyone have any advice on how to respond to that sentiment, or the sorts of things I can bring up in support?
Thanks, have a great day!
EDIT: I'd also be very interested in hearing some potential reasons NOT to use it. I want to develop and be able to really understand the consequences, rather than trying to be dogmatic. I've brought up the need for people unfamiliar with TS to learn, slow compile times, and potential frustration with errors (which sorta goes hand in hand with the first point), but I'm not sure if there's any other very common reasons people avoid it and would love to get some perspective.43 Replies
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
Thank you very much for the response! What you've said has definitely been my experience thus far, even with the limited amount that I have.
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
I'm in the same boat trying to convince my company to adopt typescript.
They don't want to use it because it "slow them down"
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
questions like this suit the #career channel more
That's good to know, I'll try to keep that in mind moving forward. Sorry about that.
think of the question forum as personal specific questions & the rest of the server as public questions for everyone to benefit from
You can still have runtime errors with typescript
Just far less of them
The main thing you should think about is "does this allow me ship faster or safer or both?"
Hard to explain over text, need a chat channel.so I can do an excalidraw rant on it aha
No, it's fine.
It's fine, appreciate the looking out.
If you can do enough arguing to get typescript into that shared component library as an opt-in situation (devs who want to write ts write ts, devs who want to write js write js), I think you'd be in a really really good situation
The reason why is, there's no real cost for JS first devs, and I believe over time what you will find is typescript will just win. People will find typescript-build components easier to work with either from within or from the outside.
The truth is, typescript being awesome is kind of hard to prove to people that haven't already drank the kool-aid. There's too many arguments like:
1. Types aren't real anyways
2. Types aren't a replacement for unit tests
3. Javascript is just fine so unless it adds tangible value....
The thing is, if you code in typescript every day you know exactly why it's a must have on larger projects (and even smaller ones once you get used to it).
Over time the developers will discover new things that typescript gives them for free, such as:
1. Discoverability of code
2. Automatic Null Checking
3. Way easier refactoring (hard to explain but basically imports and stuff just work better in TS)
4. Less anti-pattern-ey code (For example doing props spreading WAY TOO OFTEN)
We had another conversation which effectively ended the same way. The dev leading the meeting says he sees TS as similar to other libraries I’m unfamiliar with that would effectively write Java code for you. He seems to associate it with OOP heavily for some reason, and once more reiterated that he doesn’t feel type checking is valuable. Another dev backed him up, seemingly mostly off the back of her having a hard time reading TS and not feeling it’s worthwhile to learn.
I had it confirmed that it isn’t just my team that sees the potential value that can be brought, as some other team members have apparently been advocating for it pretty heavily as well. We once more agreed that it can be a team-by-team decision, which I will take as a win for now.
I don’t want to rock the boat heavily, especially since the decision seems so split. I feel motivation and excitement for the tech you’re using is important, and if anything trying to strongarm people will just lead to them viewing it as an inconvenience due to confirmation bias. Thank all of you for your replies, I definitely appreciate all of them.
what are those good practices though? 🤔
I want to know too. Might come in handy.
The newest talking point is that perhaps Flow would be a better choice, as the workflow seems less jarring to them than TypeScript. Having never used Flow I don’t know how to respond to that - I only know TS is more widely used unless I’m mistaken.
id 100% pick ts over flow
you can also incrementally add typescript
That’s how I feel as well, but since I’ve never used Flow it would be disingenuous to take a stance beyond what I really understand. I mentioned I’d read up and familiarize myself a bit with the differences for our next conversation.
I mentioned that a smaller ecosystem means the ergonomics may not be as great when bringing in third party code. Not as many libraries with declarations for it, not sure if something like DefinitelyTyped exists, etc. Not to mention, if it’s less popular by far it may be more difficult to hire devs that already have the syntax in their toolbox, though I doubt it’s too hard to pick up.
Flow lost the battle like 4.5 yrs ago most of the major codebases that had adopted it back 5 yrs ago have nearly completely moved over to TypeScript or are STILL in the process of doing so. Most of the major JS library authoring ecosystem has moved to TypeScript instead of JS for a reason.
They're straight wrong about it being an OOP thing too. Java / C# people look at typescript that way because what it definitely does do is make your Text Editor WAY better at inferring shit. So if you go from C# to JS you'll have a way better time in TS doing OOP, but 10000% you do not need to ever write a class in TS in order to make elegantly coded well performing apps.
Yeah, the tools he mentioned related to Java were MapStruct and Lombok (which I've never heard of), but my understanding is that he's basically grouping them and TS together as "convenience features", and doesn't feel like other devs should need to learn TS for the sake of that. I disagree at a fundamental level, but I'm trying to be diplomatic.
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
Yes, I believe one of the primary motivators for MS with TypeScript was adding language features they felt JS was lacking like classes. That’s obviously less relevant (if still relevant at all) currently.
"2. Types aren't a replacement for unit tests" Is this true though?
yes
I thought it could take away some of the unit test
but, that doesn't mean that types don't reduce the amount of unit tests you need
exactly
a type system won't tell you if your sum function works
but you won't need to write a unit test saying "if you try to pass an array of strings, it will throw an error"
I have never written a single line of uni test, I do alot of E2E though .So I dont really know the benefit of unit testing
For me it depends on the circumstance
If you had to sell someone on using unit test, What example would you give
I think a really good use case for unit tests is an html / markdown parser or something like that
lol I just copied and pasted because I accidentally answered your question before you asked it
haha wow
I think anything that you can think of as an adapter or something like that often benefits from unit tests.
"Convert F to C", make sure the input and output is correct
Iv seen code bases where they check if the button has text "Submit" and Icon "delete.svg", Is that worth writing unit test for?
ha this makes sense
I do also like to write unit tests when I have code that I think to myself "there's a really not-obvious edge case here"
Gotchya, I'll try it out then. Do you recommend I go with Jest?
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
Soemthing jest style, I use vitest. It's easier to set up on something small. If you already did CRA or something like that I'd just use jest since it's there
Yeha I'm down too, Cuz I'm sure most people here are anti unit testing lol , So its nice to hear the pov of people who uses it
Yeah I use React + Vite and Next
do vitest then
you are effectively learning jest by learning vitest
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
I saw that this morning! I asked Matt a question about enums vs string unions and I found his response very insightful 🙂
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
I did see that, although admittedly those results are pretty likely skewed. The devs that took that survey may not be representative of the whole. Still, it makes sense to me and is a very good sign.
Ts is an outlier because of js, If other languages were available on frontend I think jt would be lower