Speaker 1: Hello everybody, and welcome to another episode of React Roundup.
Speaker 1: My name is TJ. Van Told and with me on
Speaker 1: the panel today is Jack Herrington. Hello, and our special
Speaker 1: guests today are Mark Story and Priscilla Alivera. Hopefully I
Speaker 1: pronounced her name correctly. Yeah, welcome, excellent, welcome to React Roundup.
Speaker 1: Why don't you introduce yourself and tell us who are
Speaker 1: what you do while you're famous those sorts of things.
Speaker 2: I don't think I'm n okay okay 'all, thanks for
Speaker 2: having me. My name is Priscilla. I'm a software engineer
Speaker 2: based in Vienna, and I'm a grank To employee That's
Speaker 2: Sanctuary work on the user interface of our application, so
Speaker 2: I'm more like a front end engineer.
Speaker 3: I'm Mark Story. I also work at Center It's Prisona.
Speaker 3: I work partially on the front time and then also
Speaker 3: a lot on the back end on their building system.
Speaker 3: And I'm in Toronto, Canada.
Speaker 4: All right, So looks at y'all have an article out
Speaker 4: on converting from javascripts to typescript for your application and
Speaker 4: what the advantages work, and you kind of give us
Speaker 4: a bit of a high level synopsis on that.
Speaker 3: Yeah, so the high level synopsis is we converted the
Speaker 3: application from JavaScript to typescript. To Typescript is a statically
Speaker 3: analyzed language that compiles that a JavaScript if you've not
Speaker 3: used to it before. And so over the coross of
Speaker 3: eighteen months, we converted the whole applicate, the whole front
Speaker 3: end application for Century from JavaScript from JavaScript into typescript,
Speaker 3: and then we wrote a blog post around how we
Speaker 3: did it and some of the challenges we had and
Speaker 3: some of the benefits of that.
Speaker 4: So, what were some of the challenges you had.
Speaker 3: Big code bases take a long time to migrate. I
Speaker 3: bet so for scale like Centuries, around ninety thousand lines
Speaker 3: of code in JavaScript, and yeah, it just took a
Speaker 3: really long time because we weren't allowed to stop delivering features.
Speaker 3: So yeah, the process we kind of documented was doing
Speaker 3: that without stopping. Because there's kind of like two approaches
Speaker 3: you can take with converting a large CUD base. You
Speaker 3: can like try and freeze the earth and do everything
Speaker 3: at once and then not do any future work. And
Speaker 3: the other one is like do a re right, which
Speaker 3: is also very dangerous, and the other one is that
Speaker 3: we approach we took, which is like you modify the
Speaker 3: code in place and then incrementally kind of change things over.
Speaker 1: I guess maybe we could start with what precipitated this change,
Speaker 1: like where you internally sold and typescript and decided it
Speaker 1: was the right move, because obviously putting in that whole effort,
Speaker 1: you must have saw some value in doing the work.
Speaker 3: Yeah, I can answer that. I guess the impetus was
Speaker 3: we were having we had several kind of production incidents happened,
Speaker 3: customer facing pression incidents that were caused by front end
Speaker 3: problems and the after like in the retro for like
Speaker 3: why did we have this incident? A lot of the
Speaker 3: like paths forward where you know, if we had better
Speaker 3: tooling or static analysis, then we would be able to
Speaker 3: prevent these kinds of problems. And so that was kind
Speaker 3: of that happened multiple times, and the solution came up
Speaker 3: multiple times was to you know, if we had better
Speaker 3: linting support or better static analyzation that could come from
Speaker 3: a tool like touch script, then we would be able
Speaker 3: to prevent these kinds of problems because they would be
Speaker 3: compiled tim errors versus runtime aerrors that we catch in production.
Speaker 3: So that kind of came through and then a century
Speaker 3: overy year has like a hack week, like many companies
Speaker 3: and a bunch of engineers took the time to kind
Speaker 3: of start the genesis of touch script conversion and make
Speaker 3: it possible to incre mentally move the application over as
Speaker 3: part of their project, and then so we have kind
Speaker 3: of a proof of concept, and then from there we
Speaker 3: were able to get buy in on converting the rest
Speaker 3: of the application over.
Speaker 1: I'm curious the setup because I sort of agree with
Speaker 1: your how you laid it out, Like when you're tackling
Speaker 1: something big like this, I think very often, at least
Speaker 1: in my experience, freezing everything, like for a big rewrite
Speaker 1: is almost never an option, just because like, if you
Speaker 1: have an app that's that much code, chances are it's
Speaker 1: doing something important, and chances are you have to keep
Speaker 1: updating and working on it. And also, like business users
Speaker 1: don't tend to like things of like, yeah, we're going
Speaker 1: to spend two three months on this and you'll notice
Speaker 1: no changes. Hopefully you'll notice no changes because we might
Speaker 1: break something too, right like those those arguments don't go
Speaker 1: over so well. But I am curious, like because I've
Speaker 1: absolutely never attempt this with Typescript specifically, I'm very curious
Speaker 1: of the architecture you came up with to make this possible,
Speaker 1: because I'm assuming like you were pushing out typescript files
Speaker 1: like or at least I'm assuming it's a mechanism where
Speaker 1: you could like convert one file the typeescript, push it up,
Speaker 1: push it to production or whatever, and then just like
Speaker 1: keep on working. So I'm curious, like, how like technically
Speaker 1: you set that up to work. Is it just like
Speaker 1: some fancy webpack canfig or what was going on to
Speaker 1: make that possible?
Speaker 2: Oh? Yes, So we decided on converting our files incrementally
Speaker 2: to type script, and so every day we were pushing
Speaker 2: files to production and we used our own.
Speaker 5: Application to monitor errors.
Speaker 2: Yes, and so we had to use some webpac confix
Speaker 2: some configuration to be able to do that. But this
Speaker 2: is something nice in type script. You don't need to
Speaker 2: convert the whole code base at once. You can do
Speaker 2: it incrementally. So this was also one of the reasons
Speaker 2: we decided to introduce typescript.
Speaker 4: So how many developers are on your team and how
Speaker 4: did they fare in terms of learning pypescript And you
Speaker 4: mentioned in the articles some educational stuff. How did that work?
Speaker 5: So I think we are twelve developers. Some of some
Speaker 5: of our colleagues.
Speaker 2: They only work on the front end, and some of
Speaker 2: our colleagues they are FULLD stech. So the education was
Speaker 2: the key in this process because some colleagues they didn't
Speaker 2: know much about typescript and we would like to. First
Speaker 2: we created a documentation. In terms of documentation, we also
Speaker 2: tried to motivate the colleagues to adopt a typescript and
Speaker 2: once they saw the benefits, they started to use typescript
Speaker 2: by themselves. So we never used the tooling to block
Speaker 2: some on of pushing JSX COLDE to our code base.
Speaker 5: This was naturally. This happened naturally.
Speaker 4: So what were the big like aha, benefits for these
Speaker 4: front end developers on like, oh, now, yes, typescript, that's awesome.
Speaker 4: You know, it's so much better than JSX. Now I'm
Speaker 4: never going to do JSX again.
Speaker 5: So auto completion for example.
Speaker 3: Yeah, yeah, I would say like autocompletion and compile time
Speaker 3: checks were the two big ones. Also, like improved code navigation,
Speaker 3: so instead of having to get your editor to go
Speaker 3: up and find the symbol ref like most editors, when
Speaker 3: you have the language server setup, you can jump to
Speaker 3: symbols or like preview symbols in line with like little
Speaker 3: floating windows. And so because the editor ecosystem, the touch
Speaker 3: script team spent a lot of time making like the
Speaker 3: dev experience really well. It was that like improved developer
Speaker 3: experience that really kind of like helped convert people over.
Speaker 4: Just a quick follow up, so for editor we're talking
Speaker 4: vs code, we're talking web the Storm or what.
Speaker 3: Yeah, so we have of the twelve to twenty people
Speaker 3: that work on the front end, there's a mix of
Speaker 3: people in bs CO. There's some Vim users and then
Speaker 3: there's some like web Storm or like pie Storm pie
Speaker 3: chterm users as well. So getting it to helping people
Speaker 3: get set up with vs cod is pretty straightforward. And
Speaker 3: then the VIM users have their own like flag channel
Speaker 3: where they all share a vimscript and you just hang
Speaker 3: out over there.
Speaker 1: I don't know what you all are doing, hu, I
Speaker 1: imagine you a specially invite to and it's I'm.
Speaker 3: One of those Vim people as well. So it was, yeah,
Speaker 3: we all work together to get it all working nice.
Speaker 3: So yeah, once once everyone had their editors set up,
Speaker 3: then the benefits become a lot more visible and a
Speaker 3: lot more tangible. And through that and like a code
Speaker 3: review like Priscilla was mentioning we're able to kind of
Speaker 3: like a guide and educate people forward. And then there
Speaker 3: was also some pair programming along the way, like you
Speaker 3: should do this in in the persons I don't know,
Speaker 3: and then we're like, okay, well we can just sit
Speaker 3: with you and help you or like video chat with
Speaker 3: you sitting. But yeah, that's the kind of approach we took.
Speaker 4: It's impressive that you did it over a pandemic, that's
Speaker 4: for sure.
Speaker 3: Yeah. That affected the timelines. Yeah. When we started the project,
Speaker 3: the timelines were like RMVP was like, well when do
Speaker 3: you think you'll be finished? And we gave a timeline
Speaker 3: which was complete rubbish. The pandemic came and then the
Speaker 3: timelines were very much rubbish, and then we were dealing
Speaker 3: with like team burnout. So yeah, just like trying to
Speaker 3: keep people motivated was one of the harder parts. I
Speaker 3: would say.
Speaker 1: One kind of nice thing or fun thing I see
Speaker 1: in your article is you have on here that it's
Speaker 1: certain points, like certain messier points. You would just leave
Speaker 1: in comments that were like to do use like tackle
Speaker 1: this later, And personally I kind of like that because
Speaker 1: it's like you're talking about like using the typescript like any,
Speaker 1: which is like the get out of jail free typescript trick.
Speaker 1: But I'm curious about that approach. I think I actually
Speaker 1: kind of like it because I'm guessing your point was
Speaker 1: you want to get this conversion done right, like addressing
Speaker 1: some of the messier type script aspects would potentially break
Speaker 1: your code unnecessarily, when really you just wanted to get
Speaker 1: things changed and get things out there. Presumably.
Speaker 3: Yeah, I would say we tried to use any sparingly.
Speaker 3: We tried really hard to do the proper typing, but
Speaker 3: there are some places, especially where our type striped interfaces,
Speaker 3: where with React, where you can't type it all properly.
Speaker 3: I think it's like create ref as the one that
Speaker 3: is really annoying, Like you can't put generics through create
Speaker 3: create ref it drops them. So we had we had
Speaker 3: a few things like that, And we have a lot
Speaker 3: of like higher order components because Century is a long
Speaker 3: lived REACT applications, so there's many different patterns. There's a
Speaker 3: lot of higher artwork components, and we had a lot
Speaker 3: of problems with like default props not being able to
Speaker 3: tunnel their way through through a higher ardor component. So
Speaker 3: those are some of like the Typeescript challenges we kind
Speaker 3: of like had.
Speaker 2: To hack around, yes, and we used to do so
Speaker 2: we can now after the conversion, we are doing that.
Speaker 2: Now we are checking those places, those places where we
Speaker 2: added to do, and we are trying to find a
Speaker 2: better type and yeah and remove to.
Speaker 5: Do with the correct tack.
Speaker 3: And we were using libraries that had some like not
Speaker 3: ideal typing support. So we're using create react class and
Speaker 3: some of the types get kind of squidgy when they
Speaker 3: go through create react class. So we went back and
Speaker 3: like removed all of create react class and like tried
Speaker 3: to simplify some of the higher components. And we still
Speaker 3: have a budget to Doo's love to do. So while
Speaker 3: we're while we're done, we're not like one hundred percent
Speaker 3: no any anywhere. There's still some.
Speaker 4: So when just typescript it was it was kind of
Speaker 4: more generalized. Repass it with the whole system and refactor
Speaker 4: some of the old cruft it was stuck around in
Speaker 4: there kind of thing.
Speaker 3: Yeah, we tried to try to focus, like when you're
Speaker 3: converting a file to type script or converting a module
Speaker 3: to typescript, like just do the typescript conversions, don't make
Speaker 3: too many run time changes unless the typing becomes really
Speaker 3: really challenging, because conflating the run time changes with the
Speaker 3: with the type changes kind of sets you up for
Speaker 3: more problem BOMs than what you you'd want to take
Speaker 3: on at this point in time.
Speaker 4: Oh loo could go wrong.
Speaker 3: Yeah yeah. Another thing that helped us make progress was
Speaker 3: to kind of put like a moratorium on any like
Speaker 3: other large scale refactoring. So another thing that we've been
Speaker 3: battling with is is enzyme is no longer being maintained
Speaker 3: as well as we would like to have, and we
Speaker 3: want to like be upgraded to REACT seventeen, and enzyme
Speaker 3: required some workarounds to make that work. So we also
Speaker 3: wanted to shift off of enzyme for testing, but we
Speaker 3: didn't want to start that until the typescript was finished
Speaker 3: because we'd have too many like inflight projects, and you
Speaker 3: get everything half done and then everything is just awful
Speaker 3: for a long long period of time.
Speaker 5: Yes, we also we agreed that we wouldn't.
Speaker 2: Use reacted hooks before the conversion, before the conversion was complete.
Speaker 2: So this was one of the things that's motivated MEATS
Speaker 2: to convert to even more fires.
Speaker 5: I think not only be but to many many other colleagues.
Speaker 2: So finally, now after the conversion, we can use react
Speaker 2: to hooks.
Speaker 5: Yay much better.
Speaker 4: Yeah, all right. I mean it's only been a couple
Speaker 4: of three years since React Hooks came out. I think
Speaker 4: something like that two years. It's been a while. Yeah, yeah,
Speaker 4: it's nice. That's a long time. So interesting A question
Speaker 4: for you about the educational side of the house. I've
Speaker 4: actually done a lot of Typescript education and written, done
Speaker 4: a bunch of videos on it and all that, and
Speaker 4: a lot of questions that I get are around the
Speaker 4: misconception that Typescript has a run time to it, that
Speaker 4: it's going to bloat your code because it's going to
Speaker 4: do all this type checking and things like that. And
Speaker 4: I find it challenging to kind of get through to
Speaker 4: folks that Typescript is just at compile time only. There
Speaker 4: is no run time version of Typescript. How how much
Speaker 4: of a challenge was that for you to get that
Speaker 4: across to your team members and what do you say
Speaker 4: or do to make you get them to kind of
Speaker 4: grock that.
Speaker 3: I don't remember that coming up as a big problem.
Speaker 3: We're fairly conscious of or bundle signs, so like just
Speaker 3: comparing bundle size from the code that webpacker's generating from,
Speaker 3: like the down compilation from like Yes six down to
Speaker 3: or whatever version we were on, but Yes current down
Speaker 3: to Yes five, and then comparing the typescripts compiled down.
Speaker 3: We'd be able like it was pretty easy to demonstrate,
Speaker 3: like there's no significant runtime cost on bundle size. So
Speaker 3: I think that was the way to end that argument,
Speaker 3: was like the bundle size is actually the same or smaller,
Speaker 3: so it doesn't matter why typrip is doing it right.
Speaker 4: Well, I think there's also things like like, for example,
Speaker 4: if you put it an interface around where you're saying, okay,
Speaker 4: this is what we expect from the server, right, and
Speaker 4: then you get a response from the server and it
Speaker 4: doesn't match the payload although the type that you have
Speaker 4: in the interface, and people kind of expect that. Oh wait,
Speaker 4: I thought typeseop was going to validate what was coming
Speaker 4: back from the server. And you're like, no, that's not
Speaker 4: the way that No, that's not type peop's not going
Speaker 4: to do that for you. So is that something That
Speaker 4: kind of thing is something that I find challenging.
Speaker 2: Yes, yeah, so we are fortunately actually don't we don't
Speaker 2: have our payload to type it. So many times we
Speaker 2: have to cast it or we already know what data
Speaker 2: we are going to get, so we we we add
Speaker 2: in the front end the correct type.
Speaker 5: But that's that's what we do.
Speaker 3: That's what everyone has to do, though, Like there has
Speaker 3: to be at the network boundary, you have to be like,
Speaker 3: this is what's coming in. I promise.
Speaker 4: I think you swear, I promise. That's the thing, right.
Speaker 4: I think I think people have this understanding misunderstanding like oh,
Speaker 4: type that actually going to be like a joy or
Speaker 4: a yup which actually goes through and literally checks to
Speaker 4: make sure that like oh there should be an idea
Speaker 4: here and there's not that kind of thing. But it's
Speaker 4: not gonna do that. Yeah, no, it doesn't do that.
Speaker 3: That's her.
Speaker 1: Are there any other learning guides you would recommend, like
Speaker 1: any like you know, courses or books or anything that
Speaker 1: you use for for learning or teaching others that you
Speaker 1: might recommend teach typeescript. Yeah, and if not, that's okay too.
Speaker 1: It's just so I.
Speaker 2: Think in my face. For example, I learned it on
Speaker 2: a daily basis. I needed to do something, so I
Speaker 2: googled it and then I found a solution. I tested
Speaker 2: and tried some things out, and yeah, I think it's
Speaker 2: pretty much it. That are a lot of materials on internet. Yeah,
Speaker 2: but I don't know one specific.
Speaker 3: Yeah, I think we gave people like some links to
Speaker 3: like learning typescript guides, Like there's a couple of well
Speaker 3: published webbooks that are good. The official docs are really good,
Speaker 3: and there's a lot of like if you want to
Speaker 3: learn it, just like like message one of us on Slack,
Speaker 3: we'll sit with you and talk you through it, or
Speaker 3: like work with you on it. And that was a
Speaker 3: lot of how we did it. And like I learned
Speaker 3: to strip through this commersion. I never used typescript before,
Speaker 3: so for me, it was just like learn on the job,
Speaker 3: how do I do this? Like, Yeah, a lot of
Speaker 3: a lot of that and my reading other people's code
Speaker 3: stealing ideas.
Speaker 2: When I joined at the Center, the typescript convey ession
Speaker 2: was already happening, So I was happy because I had
Speaker 2: typescripts and knowledge, and I was glad they could help
Speaker 2: the team consequently speeding up the process so then we
Speaker 2: could use hooks for example.
Speaker 1: Yeah, so I'm curious now that you have typescript out
Speaker 1: in production. Well, I guess, first of all, has it
Speaker 1: helped stop some of the random bugs that you got
Speaker 1: in with the first question? And I'm also curious, like,
Speaker 1: now that you have a complete typescript code base, are
Speaker 1: there any things that came up with typescript specifically that
Speaker 1: you maybe didn't think about early on.
Speaker 3: I would say the promise of, you know, solving some
Speaker 3: of the runtime errors that could be caught by compilers
Speaker 3: has come true. We haven't had a front end code
Speaker 3: production incident that could have been caught by a compiler
Speaker 3: that wasn't anymore, so we still have like people still
Speaker 3: make mistakes. Type script is not a panalcya to solve
Speaker 3: all bugs and prevent all problems. Doesn't do that, But
Speaker 3: what it does do is stop you from like accessing
Speaker 3: nulls and accessing undefines. So I would say those kinds
Speaker 3: of like very visible customer problems have not been happening,
Speaker 3: and it's forced people to think about types a little
Speaker 3: bit better. So I feel like it helps design a
Speaker 3: little bit ask for like things we didn't expect to happen.
Speaker 3: Bill times have gotten longer just because the compiler. We
Speaker 3: have a lot of Typescript, not a lot of touchcrip code,
Speaker 3: but we have a sizeable chunk of Typescript codes, so
Speaker 3: there is some added compile time. So we've tried to
Speaker 3: mitigate that by like keeping as current as we can
Speaker 3: with Typescript so that we always get the fastest compiler.
Speaker 3: I guess how.
Speaker 1: Much longer are we talking? How long does it take
Speaker 1: the typescript compiler and your year app a couple of minutes? Okay,
Speaker 1: and that's something you only experience. Like dev time is fine,
Speaker 1: right because it's like compiling as you go, But just
Speaker 1: when you build for like a release or whatever, I.
Speaker 3: Think there's well, building for releases happens, like you merge
Speaker 3: to master and then holding stuff happens, and then Docker
Speaker 3: images have to be built, and like that whole Docker
Speaker 3: image build process is the is a long part. I
Speaker 3: would say the CI and local dev is the slower part,
Speaker 3: where like spinning up webpacks, it has a like an
Speaker 3: initial lead time of about a minute for it to
Speaker 3: get started, and then in CI, like the linting and
Speaker 3: type scripting checking takes a couple of minutes.
Speaker 4: Interesting, Okay. I'm playing a lot with es build and
Speaker 4: SWC lately, which are like Rust and go jsts compilers,
Speaker 4: and in the right context, they can make a significant
Speaker 4: difference in those compiled.
Speaker 3: Times good time. That's the thing I would like to do.
Speaker 3: We have a lot of we have a couple of
Speaker 3: custom webpac module like custom web pack plugins, which makes
Speaker 3: it hard because we're deeply entwined into Webpack. I've used
Speaker 3: VTA on our fight on a little side project and
Speaker 3: it was awesome. The compile times completely go away. But yeah,
Speaker 3: we were kind of deep in the webpack pool.
Speaker 4: Yeah, VAT is amazing. So I've heard a lot of
Speaker 4: issues around a typescript and just kind of naysayers like
Speaker 4: I just don't want to do typescript when it comes
Speaker 4: to more comfortable jobascript. One of another complainert here is
Speaker 4: that it makes code ugly. So is that something that
Speaker 4: you had any resistance on folks saying I just don't
Speaker 4: like the look of it.
Speaker 3: Yes, Yes, the CTO was very much like typescript just
Speaker 3: makes code ugly and hard to read, But we did it. Anyways.
Speaker 3: I would say that like we also, like Century is
Speaker 3: a is a mixed shop. So we have something we
Speaker 3: have a lot of JavaScript, we have Python, and then
Speaker 3: we also have Rust, and so typescript is not nearly
Speaker 3: as ugly as rust, so it's quite.
Speaker 4: Palatable fighting words right there.
Speaker 1: It's funny. It's all in the idea to beholder, because
Speaker 1: I worked for a company that was a long time
Speaker 1: dot net shop, and they considered typescript like the height
Speaker 1: of elegance, right because it's it's made by the same
Speaker 1: person behind like c Sharp, who's like the dot net guru.
Speaker 1: So they considered like tight script to be like an
Speaker 1: enlightened form of JavaScript. And so I think it's it's
Speaker 1: all relative to what your background is or what your
Speaker 1: personal preferences are.
Speaker 3: Yeah, so like the touch script is ugly. Camp came
Speaker 3: from like Python, where everything is like very syntactically very
Speaker 3: like it's low low noise or like low volume, I guess,
Speaker 3: and touch script has a lot more like punctuation to it,
Speaker 3: and Rust has more punctuation. I don't think Rust or
Speaker 3: typescript are ugly, Like they're both very readable. They're just
Speaker 3: you just have to have a lot more like the
Speaker 3: dense they're just dense languages.
Speaker 4: Oh no, I think we should stick with that because
Speaker 4: it makes a great subtitle for the podcast. Is you
Speaker 4: know once it again typescript, It's nowhere near as ugly
Speaker 4: as rust.
Speaker 1: And that's it right there, not as ugly as rust.
Speaker 1: We should just call it is typescript code ugly. Just
Speaker 1: I think it's like bait title right there. What you're
Speaker 1: used to right like, you're not used to list list
Speaker 1: could be very ugly.
Speaker 4: All yeah, I think you can. There can definitely be
Speaker 4: some readability issues when it comes to generics, and I
Speaker 4: don't think any language that supports generics has actually solved
Speaker 4: that challenge. But generics are incredibly important in retaining the
Speaker 4: type safety of your components or whatever you're you're using.
Speaker 4: So have you seen folks maybe almost go too far
Speaker 4: with generics. I mean I've definitely seen that. As another complaint,
Speaker 4: which is people saying, oh, you know, it gets really complex.
Speaker 3: I would say we have we don't have a ton
Speaker 3: of generics. We have a lot of intersection types, and
Speaker 3: we've had typescript yell at us that the type is
Speaker 3: too complicated. This came up when with our like main
Speaker 3: event payload if you include all of the properties types
Speaker 3: trips like no, I don't want to really, I've never
Speaker 3: seen them. Yeah, Or that's another one we had was
Speaker 3: the top level form like form input, where you can
Speaker 3: push a type as a string, and then you can
Speaker 3: get to all of the various input types in that
Speaker 3: we have in century. We were just trying to like
Speaker 3: intersection all of those types of like union, all of
Speaker 3: those different formats together with a discriminated field and a
Speaker 3: certain point too is like Noah, I don't want to
Speaker 3: do this, Like there's too many conflicts. Wow, type it's
Speaker 3: too big, please stop.
Speaker 4: WHOA, I've never seen that.
Speaker 3: It was not a good thing to say.
Speaker 5: I don't think we have a lot of generics in
Speaker 5: our cult.
Speaker 3: Yeah, we have some, but not as not many, not
Speaker 3: like there's not a lot of like three tier generics,
Speaker 3: like the like generic of a generic of a generic,
Speaker 3: Like we don't try just trying to do that.
Speaker 1: One thing I've noticed from doing this podcast is that
Speaker 1: the people that struggle with typescript the most seem to
Speaker 1: be people like library authors that have these like general
Speaker 1: purpose APIs, because those are the ones that are really
Speaker 1: hard to configure, like if you're the person that's in
Speaker 1: charge of making the types for like reactor or like
Speaker 1: some of the libraries you were speaking of that had
Speaker 1: for support, I imagine part of the reason why they
Speaker 1: have pre support is that they have to get into
Speaker 1: like crazy levels of like generics and intersection types because
Speaker 1: they're kind of designed for general purpose use. So that's
Speaker 1: where I think some of the struggles with typescript comes in.
Speaker 1: But the thing is like in your average app, even
Speaker 1: like big apps, like the ones you're working on, like that,
Speaker 1: those are like fringe situations I feel like, because I mean,
Speaker 1: most of the time the types you're dealing with while
Speaker 1: you have objects to raise strings numbers, right, you're you're
Speaker 1: not doing anything like crazy, And it sounds like that's
Speaker 1: sort of the case with what you've been working on
Speaker 1: as well.
Speaker 3: Yeah, I would say, like for a lot of like
Speaker 3: web applications, you're dealing with like API responses and then
Speaker 3: converting those around like munging that data and then turning
Speaker 3: it into into use state, right Like, so I would
Speaker 3: completely agree that you're not dealing with the crazy generics,
Speaker 3: I would say, yeah, And I think you're respont on
Speaker 3: with like the library the library author part, Like, especially
Speaker 3: if the library started off as as a JavaScript library
Speaker 3: and then was converted to typescript. I think that's where
Speaker 3: you really run into it because they've leveraged the dynamic
Speaker 3: properties of JavaScript and like the ability to be very
Speaker 3: polymorphic on anything and not kind of bite someone they
Speaker 3: try and turn into the typeescript. Yeah.
Speaker 1: I think it was last week. Week before, we were
Speaker 1: talking to an author of a form library and they
Speaker 1: were relaying horror stories of like it sounds like you
Speaker 1: have a similar experience as well, Like they had form things,
Speaker 1: but forms can contain all sorts of types, so they
Speaker 1: got into some insanity in terms of defining that.
Speaker 3: Yeah, I could see a form library being really hard.
Speaker 5: Yeah.
Speaker 4: One of the nice things about that though, is sometimes
Speaker 4: you can kind of contain that in insanity. If you've got,
Speaker 4: for example, a set of shared components, like the button
Speaker 4: that you're using everywhere, right, the type definition of a
Speaker 4: button might be a little bit complex because you might
Speaker 4: be bringing in like detailed HTML props, which has a
Speaker 4: really weird complex signature, but you want to get all
Speaker 4: of the extra types for a button and you don't
Speaker 4: want to define those yourself. So that's actually really nice.
Speaker 4: But the complexity is sort of contained within that that
Speaker 4: that library of your your share components, and then as
Speaker 4: as a user, right, you just pull you just import
Speaker 4: button and the next thing, you know, you get hinting
Speaker 4: for on click and everything just works, and so that's
Speaker 4: kind of nice. And sometimes, you know, you can hide
Speaker 4: the complexity a little bit of the of the typescript stuff.
Speaker 4: It's not in your face like all the time. I
Speaker 4: feel like you get tuk with like well designed libraries. Yeah,
Speaker 4: but it is tougher, I guess for older libraries that
Speaker 4: were written in a style that was less kind of normalized.
Speaker 4: Maybe you know, you have to start using some of
Speaker 4: the weirder features of typescript to deal with that, like
Speaker 4: function overloading, which I don't even think people know exists
Speaker 4: inside typescript, but actually it does and you can use it.
Speaker 3: We had to use it.
Speaker 4: Oh there you go, Okay, you know when you need it.
Speaker 4: It's actually really handy, but it's a it's a weird implementation.
Speaker 4: It's not like C sharp or C plus plus or Java.
Speaker 4: It's a sort of it's it's just kind of like
Speaker 4: multiple signatures for actually what's really just one function.
Speaker 3: But to use a lot of type guards to break
Speaker 3: down our unions too into those. Yeah, those are some
Speaker 3: of the like the weirder types of stuff we have
Speaker 3: to use. Was function overloading, a lot of like type guards,
Speaker 3: custom type guards and big unions and intersections.
Speaker 1: Cool nice, So one thing it'd be fun to talk
Speaker 1: about because I'm I know we have a lot of
Speaker 1: listeners that are working on similar types of apps, right,
Speaker 1: large projects that have been around for a while, and
Speaker 1: that they also have a laundry list of things that
Speaker 1: they want done, whether you know, they want to be
Speaker 1: using hooks or they want to be using typescript or
Speaker 1: whatever the case may be. So I'm curious, and we
Speaker 1: did discuss some of this, but I'm curious if you
Speaker 1: have any other advice for convincing like management that like, hey,
Speaker 1: like this is a worthwhile effort, because I know that
Speaker 1: can be a struggle for a lot of people to
Speaker 1: get time sort of approved to do this, and then
Speaker 1: also like seeing these projects through, because not every large
Speaker 1: scale effort like this ends with one hundred percent conversion
Speaker 1: and success, right, So it's kind of impressive that you
Speaker 1: you push this to the finish line. So I'd be
Speaker 1: curious if you have any other advice in terms of
Speaker 1: how to make that sort of thing happen and how
Speaker 1: to see something of this scale through.
Speaker 2: So how to convince management to adopt type script. I
Speaker 2: would say that only the possibility to catch errors on
Speaker 2: the compiled times.
Speaker 5: It's amazing, you know, So this is amazing.
Speaker 2: Also we could reduce the need for API documentation because
Speaker 2: type script it self self explain everything the type and
Speaker 2: also autocompletion. So I believe this type script the team,
Speaker 2: it's faster, the product productivity is faster than usual.
Speaker 3: Guess on the like how do you get it to finish?
Speaker 3: We're really fortunate that we have we have like a
Speaker 3: front end steering community, and the main contributors to the
Speaker 3: Techica project were also part of that kind of steering committee,
Speaker 3: and so we just had to kind of stick to
Speaker 3: our guns, like no new big projects until this one
Speaker 3: is finished. And towards the end of the project, we
Speaker 3: were kind of like every week kind of asking people
Speaker 3: like how many files are you going to convert? People
Speaker 3: would volunteer like convert a couple, or I'll convert two
Speaker 3: or I'll convert three, and then every week check in
Speaker 3: with those people like did you get your stuff done?
Speaker 3: What are you going to do next week? And that
Speaker 3: helps kind of like gamify lightly people's desire to be involved.
Speaker 3: I would say another thing that helped us finish was
Speaker 3: that we did it in the long term, and so
Speaker 3: we weren't rushing to meet a deadline. Instead, we were
Speaker 3: just giving updates on like when we would finish. So
Speaker 3: instead of it being like you must be finished by
Speaker 3: December of twenty twenty, or your project is out of gas,
Speaker 3: it was more like we're just going to do this slow.
Speaker 3: We're going to do it the right way, like the
Speaker 3: right way for us, which is like not slap any
Speaker 3: on everything and do a machine organization. We're going to
Speaker 3: take our time, going to do it, you know, so
Speaker 3: that we have something that we're proud of when we're finished,
Speaker 3: and then just give updates on when we will be done.
Speaker 3: And then as long as people were meeting their project
Speaker 3: delivery like deliverables, the front time folks were able to
Speaker 3: focus as much as they wanted on tuch script. That
Speaker 3: was the kind of like their B project was converting
Speaker 3: to touch script, and all the managers, like all the
Speaker 3: team managers knew about it, all the engineering managers knew
Speaker 3: about it, knew who was contributing to it, and so
Speaker 3: they were kind of like on board, like this is
Speaker 3: this person's be project.
Speaker 1: Yeah, I think all that is great, Like I like
Speaker 1: Priscilla's points of proving to management. It's like a lot
Speaker 1: of those points you made were really about proving that
Speaker 1: this is going to be long term a net positive right,
Speaker 1: like well, like the fewer bugs and more productivity will
Speaker 1: make this time like pay off and the long run.
Speaker 1: And then I also like the points just in terms
Speaker 1: of keep seeing this through to the finish, like the
Speaker 1: accountability bit, like having someone that's in charge of the
Speaker 1: project that reaches out and forces people to say, I'm
Speaker 1: going to do this and almost gamifying it a little bit,
Speaker 1: or at least like holding people accountable so that there's
Speaker 1: that constant update, like it doesn't get lost because I
Speaker 1: know what, I've been involved in projects like this before.
Speaker 1: Sometimes it's going well, but then some big feature comes
Speaker 1: down from business or some big bug happens, and then
Speaker 1: all of a sudden, like this thing that's very low
Speaker 1: priority gets sidetracked sometimes to never reappear. So I think
Speaker 1: having like someone on it and someone constantly checking in
Speaker 1: through all of that can make a big difference.
Speaker 6: Yeah, I'd also say another thing that helped us was like, yeah,
Speaker 6: constantly checking in, constantly double checking, and then also making
Speaker 6: sure all the new code was written in touch shriped
Speaker 6: was a big monumental thing to get done, was like
Speaker 6: convince everyone that touch script is worth learning and then
Speaker 6: also get them to stop writing JavaScript, because if we
Speaker 6: never stopped writing.
Speaker 3: JavaScript, we would never finish. And so for us to
Speaker 3: be able to complete, like and to prove that the
Speaker 3: tuchrip project was going to actually finish both through ourselves
Speaker 3: and up management, was to get everyone to stop writing cabscript.
Speaker 3: And we're way past that point now, but that was
Speaker 3: a that was a key turning point, was getting everyone
Speaker 3: on board.
Speaker 4: Yeah, so that actually leads a question, So would you
Speaker 4: personally ever want to work on a streat JavaScript application?
Speaker 3: Again, Yeah, it would. It's not as good as like typeshrip,
Speaker 3: Like you get a lot more benefits out of having
Speaker 3: it in type strip. And if I was to start
Speaker 3: a new project, I would definitely start it in typescript.
Speaker 3: Sure how about you, Priscilla?
Speaker 5: Yeah, me too, Me too.
Speaker 2: Last week we had again heck quick and I work
Speaker 2: it on two projects and I used typescript. So I
Speaker 2: started from scratch and I decided to use tapscript because yeah,
Speaker 2: I really like it.
Speaker 4: And I think that's something again with talking to management, right,
Speaker 4: hiring is always an issue. It's a very hot hiring
Speaker 4: market right now. People can move between jobs very quickly,
Speaker 4: and people are evaluating what they're going to be going into.
Speaker 4: And if you're saying, hey, you know, we're doing React
Speaker 4: circa twenty fifteen in JavaScript, come on down, we were
Speaker 4: going to be like, I really enjoy you know, typescript
Speaker 4: and hooks. I mean Rizilla's like, yes, hooks, you know,
Speaker 4: so you want to work in a modern code base.
Speaker 4: And I think that's the thing, you know, when you
Speaker 4: talk managements as a selling.
Speaker 3: Point, Yeah, for sure, And I think that was something
Speaker 3: our like our vps knew as well, Like the VP
Speaker 3: that we were working with then is like very much
Speaker 3: understanding of that. People want to be on the vanguard
Speaker 3: and want to be working with new stuff when Century
Speaker 3: as a company does that a lot as well. So
Speaker 3: I think that's an important point to make if you're
Speaker 3: in an organization where that isn't part of the company's culture.
Speaker 2: I'd like to addit that we are always trying to
Speaker 2: introduce new technologies and for example, now we just introduced
Speaker 2: reactive Testing Library, so we are planning of converting our
Speaker 2: tests to from ENSIGN to reacted Testing Library, and that's
Speaker 2: pretty cool.
Speaker 1: Yeah, I was just going to say that the it's
Speaker 1: a really good point that like sometimes like you, you
Speaker 1: are not in control of your management and your your
Speaker 1: team or like entire organization. And not to put this
Speaker 1: to blunt, but I mean, if if your organization is
Speaker 1: really obstinate, if your managers aren't great, you know, it
Speaker 1: is a hiring markets. You know, there are other decent
Speaker 1: teams out there. So if you really are like super
Speaker 1: super struggling and working on stuff you're not interested in,
Speaker 1: maybe you consider other things as well, because they're everybody's
Speaker 1: got like old code you know, bad code bases and such.
Speaker 1: But having a culture that encourages that sort of thing
Speaker 1: and allows you to you know, ramp up over time,
Speaker 1: I think is a really big deal.
Speaker 3: Like century is an old code base, it's coming up
Speaker 3: on eight nine years. But at the same time, we
Speaker 3: also like to fix it and see the value in
Speaker 3: investing it and making it current and like keeping it
Speaker 3: up to day. Like on the on the not front time,
Speaker 3: we've just finished like a humongous amount of Python upgrades,
Speaker 3: like from Python two to Python three, from Jengle one
Speaker 3: to six, all the way to gay Go two point two.
Speaker 3: Like that's been eight months of work, and all of
Speaker 3: that is to get us up to a new version
Speaker 3: of Pythons so we can get performance. Actually the main
Speaker 3: driver of that.
Speaker 1: And I have to imagine too, like like pushing those
Speaker 1: things to production is immensely satisfying as well. Like it's
Speaker 1: it's like the same sort of things that like when
Speaker 1: you finish. Like for me, it's like if I'm I
Speaker 1: like if I mow my lawn, Like there's that moment
Speaker 1: like when you're done, Like I hate mowing my lawn,
Speaker 1: But at the same time, when I'm done, like looking
Speaker 1: out over it, it's like, yeah, I crushed that, Like
Speaker 1: look how good that grasped.
Speaker 4: Yeah, I was gonna say, like that last puzzle piece,
Speaker 4: you know, when you got a thousand piece puzzle. I
Speaker 4: can only imagine like that last JSTS file, right, the
Speaker 4: last commit was like, yes, we did it, you know
Speaker 4: as a team. You know, if you're in slack, you're like, yeah,
Speaker 4: that last little.
Speaker 5: Bit, Yes, we celebrate it.
Speaker 4: I want Yeah, nice, Priscilla, was that your your file?
Speaker 4: Who was the last person to actually like do the
Speaker 4: last file?
Speaker 3: I think it was vin a right of us. I
Speaker 3: think it was one of the other one of the
Speaker 3: other folks.
Speaker 2: We let the lashest files, the most complex files.
Speaker 5: To the end, and yeah, I can't remember the last
Speaker 5: to us.
Speaker 3: Yeah, there's some like changing of tactics through it. It
Speaker 3: was like start with the biggest, start with the files
Speaker 3: that are important the most. Then start with the files
Speaker 3: that are imported with the least because these most important
Speaker 3: files are becoming annoying. And then it was like important
Speaker 3: you do like one whole view tree. There was a
Speaker 3: bunch of different tactics, but yeah, there was a bunch
Speaker 3: of big rocks at the end.
Speaker 4: Yeah, you did mention that in the article where you mentioned,
Speaker 4: you know, there's sometimes you work from the core and
Speaker 4: other times you work from the leaves. And that's actually
Speaker 4: a very interesting question out there is, hey, we get
Speaker 4: the typescript is awesome, you know, how do we go
Speaker 4: and take our twenty thousand and thirty thousand file project
Speaker 4: and bring that over? Like, what what are some good strategies?
Speaker 4: And I don't unfortunately I think the answer probably there
Speaker 4: is It depends terrible answer. Yes, yes totally.
Speaker 3: I would say, like, try a bunch of different approaches
Speaker 3: and see which ones help you get progress, Like the
Speaker 3: if your goal is to convert that twenty thousand file project.
Speaker 3: Over do the things that are going to help you
Speaker 3: get progress, like if you're going to measure progress on
Speaker 3: number of files, aim for like choose whatever tactic is
Speaker 3: going to yield you the most amount of progress at
Speaker 3: the beginning, so you can get a good foothold so
Speaker 3: you can get people invested and get people ready to
Speaker 3: help out.
Speaker 4: Yeah, you want to finish up on that. I feel
Speaker 4: like you left out. Okay, that's cool, all right, awesome,
Speaker 4: very cool. Well this has been really really fun. I
Speaker 4: think now is the time to get into this week's picks,
Speaker 4: So mark one, lead us off on your pick for
Speaker 4: this week.
Speaker 3: Sure, yeah, I would say the new version of them,
Speaker 3: NEOHIM zero five has native language server support, so you
Speaker 3: can configure neovim with LUO, which is nice. You don't
Speaker 3: have to use vimscripts, which is my least favorite programming language,
Speaker 3: and you can use LUI descripted and then the native
Speaker 3: LSP look looks really good and works really well. So
Speaker 3: check out new of them and some of the new
Speaker 3: native LSP. Very cool about you, Bricella.
Speaker 5: Oh I think so?
Speaker 4: Yeah?
Speaker 2: So that is this library D and D kit. I
Speaker 2: really like that one. It's They have an amazing documentation.
Speaker 2: It's very easy to customize and yeah, it's amazing the library.
Speaker 2: It's very light as well.
Speaker 4: What did you do? D and D kit? Yeah, it's
Speaker 4: not disturbed.
Speaker 2: So recently we had to introduce dragon drop in century
Speaker 2: and we founded this library and it's amazing.
Speaker 5: We are really enjoying using it.
Speaker 3: Cool.
Speaker 4: Yeah, there's so many D and ds. There's dragon draw
Speaker 4: theres do not disturb Dungeons and Dragons. It's very very popular,
Speaker 4: you know, three letter combination.
Speaker 3: I guess.
Speaker 5: Yeah.
Speaker 4: And for my pick, I am going to go with
Speaker 4: a bit more metaphorical. Just the power of saying no.
Speaker 4: I know that we just we talked a little bit
Speaker 4: about burnout in the beginning of this episode, and the
Speaker 4: I find the major key for me to avoid burnout
Speaker 4: is to just say no, you know, reduce the amount
Speaker 4: of stuff on your plate. You get less stressed out,
Speaker 4: and you just feel better about the attraction you make
Speaker 4: in a day by saying no to a lot of
Speaker 4: these small projects, even the ones that you want to
Speaker 4: do for yourself. So I think that's really important.
Speaker 2: I think here, I read a book about it, but
Speaker 2: I can't remember the title. How to give a sheet.
Speaker 2: I don't I cannot remember the time, but it was
Speaker 2: exactly about it the.
Speaker 5: Power of no.
Speaker 4: Yeah. I know we all want to be nice people,
Speaker 4: we all want to help out our friends and all that,
Speaker 4: but you know, you can just get snowed under on
Speaker 4: all these things, and work is just work alone is
Speaker 4: very stressful. So you know you don't want to take
Speaker 4: on too much. You want to live a happy and
Speaker 4: healthy life and you know, go out and do kayaking
Speaker 4: or whatever you enjoy. So take that time and be
Speaker 4: confident and say no, yes, definitely, TJ, you want to
Speaker 4: take us out.
Speaker 1: Yeah. I will not be picking comcasts this week, as
Speaker 1: I hope this doesn't come through the editing, but my
Speaker 1: Internet has been catastrophic here lately. But I will pick
Speaker 1: a window manager for the Mac called Divvy dvv y,
Speaker 1: one thing that I am shocked the Mac still doesn't
Speaker 1: have it built in, just a way of snapping a
Speaker 1: window to a certain part of a screen. It's crazy
Speaker 1: to me that you have to like look out for
Speaker 1: a third party app for that. But Divvy is a
Speaker 1: pretty decent one if you don't already have one, and
Speaker 1: I'd recommend it, especially if you have like a widescreen
Speaker 1: monitor just because being able to dock windows is super
Speaker 1: nice and super time saving.
Speaker 4: Absolutely thanks for that. I'll check that out all right. Well,
Speaker 4: thank you so much for showing up. That was an
Speaker 4: awesome episode and we'll see you next week.
Speaker 5: See