Best Practices for Large-Scale TypeScript Migrations with Josh Hargreaves

Transcript

[00:00:00] Joe Previte: Hey, Josh.

[00:00:01] Josh Hargreaves: Hey. How's it going? Good.

[00:00:03] Joe Previte: Yeah. Maybe you could just tell us a little bit about your background, like starting from the very beginning.

[00:00:08] Josh Hargreaves: Yeah, sure. So I am a software engineer. I. I went to school in the uk so I went to Bristol and did a master's in computer science. And then I came out as a graduate and started working for Bloomberg in London.

[00:00:26] Josh Hargreaves: While I was there I ended up working on basically native iOS, Android. And then I became interested in React native more cuz I'd always. Really found web technologies, let's say JavaScript to be really productive. So React native, I guess the early versions were released around 2015, 16.

[00:00:49] Josh Hargreaves: So I then ended up moving to New York to work on the Bloomberg Media professional app where we basically rewrote a native application in In React [00:01:00] native. So that was pretty interesting. Lots of kind of challenges early on with the framework and the kind of limitations of it. But as part of that, one of the things we did would migrate the code base from JavaScript to flow.

[00:01:12] Josh Hargreaves: So that was a pretty interesting pretty interesting then and then I. A couple of years there where I then moved to Bloomberg the, an infrastructure team basically working on the application, which is a desktop application, the Bloomberg terminal where I then ended up also doing another large scale.

[00:01:34] Josh Hargreaves: Type script migration or so like typing migration. So there I probably spent about six months converting JavaScript to type script. Yeah, there's got thousands and thousands of lines of code. And it was a really interesting it was a bit laborious at the time, but it was one of those things where it was actually quite a blessing.

[00:01:57] Josh Hargreaves: We only have to worry about the [00:02:00] typing rather than the actual logic of the code, right? So you end up seeing the full spectrum of the kind of subtleties of type typing and especially when people are gonna be consuming your types and the implications for using certain types. So that was interesting.

[00:02:21] Josh Hargreaves: And and then last year I moved moved to Netflix. And since I've been here, it been doing a kind of smaller scale type script migrations. But yeah I migrated a service which was entirely written in JavaScripts to Typescripts and redeployed it on on Linux rather than windows. It's been interesting to see especially coming at it again.

[00:02:42] Josh Hargreaves: How. How much less friction there is to use TypeScript these days versus the earlier days. I saw Jay, you actually liked one of my tweets from 2016 , where I said something along the lines of nothing is harder than using Oh, like joking around. Welcome to Times [00:03:00] scripts where importing a node module is impossible.

[00:03:03] Josh Hargreaves: And. The, I guess the the mpm typings situation these days is significantly better than a few years ago. Yeah, so it's been interesting to see over the years how type script has got better how type script say, let's say the developer friction is a lot less. And it's also sig well, so significantly more Ergon.

[00:03:25] Josh Hargreaves: To use. And one of the reasons I briefly mentioned, we used Flow way back when one of the reasons we did was because at the time it was a lot easier to use Flow with React to get some of these I guess react specific component typings and whereas now it's type script it's.

[00:03:45] Josh Hargreaves: The pretty much there's no, no such issues these days. So one example would be higher order components were difficult to type a few years ago, and flow was pretty good at that. Whereas type script these days has obviously become the mainstream choice for. [00:04:00] Typings in JavaScripts.

[00:04:01] Josh Hargreaves: It looks like obviously type scripts and it's a lot easier to use. I enjoy using type script these days and I don't think I'd write any JavaScript without it with maybe a couple of exceptions. But it's definitely the, obviously the choice and it's definitely great to see it get better as a developer for sure.

[00:04:19] Joe Previte: Yeah. Oh man there's a lot that I wanna unpack there. I think the first thing is, how did you and your team decide to use float or type scripts? Were you part of the decision making process? Were you a champion within the org? Like how did

[00:04:31] Josh Hargreaves: that work? Yeah, so I guess I specifically championed it.

[00:04:35] Josh Hargreaves: And I guess one of the reasons was because I came from a, the more kind of like native development background and to switch teams and. Moved to a code base that was untied. It was fairly dramatic how much harder it was to maintain with just pure JavaScript. So at the time we weighed up flow or type script, we ended up choosing flow.

[00:04:58] Josh Hargreaves: Somewhat regrettably, [00:05:00] because but yeah, the It was a case of championing it. And I think, there's probably a lot of people out there who have had found themselves in similar situations where they've found the, themselves, the found the need to champion typing and often people's A kind of aversion to using it is oh it makes me more slow, slower to develop and all this other stuff.

[00:05:23] Josh Hargreaves: But in my opinion, obviously, and most people's opinion, the the benefits far outweigh the the cons for sure. .

[00:05:31] Joe Previte: Yeah So I guess that's like the main story then, even at different companies. Is it like you come in and they're like, Hey, we have this service or project, we wanna migrate it to type script.

[00:05:41] Joe Previte: Do you want to do it? Or is it like, Hey, we want to do this? Does that sound interesting to you? Like at Netflix,

[00:05:46] Josh Hargreaves: yeah, so I guess I've always been someone to I've always been someone to try and improve things as I go. So sometimes when you see an opportunity to improve things one of those things is converted to types group.

[00:05:59] Josh Hargreaves: [00:06:00] This specific project, which I ended up. Not so much rewriting, but converting to TypeScript. It was an interesting situation and something I've taken away from a rewriting a service which you didn't write in from JavaScript to TypeScript. Sorry. Converting is that. Converting something, code you didn't write to type script is a fantastic way to learn the code base, would you believe?

[00:06:25] Josh Hargreaves: Because you really have to know. Obviously yeah, you could typecast any or whatever, but actually the situation was somebody who owned that. Prior to me joining, I'd moved to a different team and I was going to start maintaining that service. So I took it as an opportunity to not only improve my sanity, but also improve the sanity of anyone else who works at it in the future.

[00:06:54] Josh Hargreaves: So it's almost, it's quite interesting when you. Something written in JavaScript and [00:07:00] convert it to a type language is that you are almost taking that knowledge, which you may have and putting it into code, right? Such that obviously it improves maintainability and all this other stuff, but yeah, so it is actually a really good way to learn a code base is to type up, to convert it to TypeScript.

[00:07:18] Josh Hargreaves: So I've, I often look at those, Situations, there's opportunities to. Improve improve the kind of like when it's like one of those one plus one equals three situations when you have the, I didn't know the service and it wasn't in tight scripts, and thus I do both. I know both now know the service and it's now in type scripts.

[00:07:40] Joe Previte: So I guess for people who don't have TypeScript as part of their default stack or already they don't have buy-in already at their organization, what advice do you have for getting buy-in from like management or leadership?

[00:07:54] Josh Hargreaves: That's a good question. I think the best. It is one of those things where it's it's more of a people problem [00:08:00] than it is a technical problem.

[00:08:01] Josh Hargreaves: So viewing as a technical problem is, there are technicalities to it. One of the best ways is I think it was it Paul Graham who says, Do things that don't scale when building a business. If you are gonna evangelized type script you really need to go and work with everyone individually in a completely non scalable way.

[00:08:23] Josh Hargreaves: But you would be like, Hey look at this. Look at in ENT and this other stuff. Another way of doing this is to try and reduce friction. As much as possible for say, people using touch groups. So one of the things I did at Netflix was I converted our. One of, for new services, we have a it's like a project scaffolding thing.

[00:08:48] Josh Hargreaves: So basically you say, Hey, I want a new service and it generates the service. So one of the things I did was also update that scaffold such that any new [00:09:00] project somebody creates, it will be in high school. So that is, for example, , an interesting way to get people on board. The key thing is quite often I don't find people are adamantly opposed to using time script.

[00:09:15] Josh Hargreaves: It can be more so that people just having got around the converting thing to, I think we're quite lucky these days, that consensus in the industry. And there are probably a lot of case studies out there. I think I've seen numerous from, I think perhaps Coinbase, like big high profile case studies for people who have started using type script.

[00:09:38] Josh Hargreaves: So in my experience, most people, if you open a poll address to convert something to type script, they wouldn't be that adamantly opposed. This said larger projects. The migration path. It can be such that perhaps you add it, you add a configuration to your project where you can just start using types so you can get buy in a [00:10:00] smaller way.

[00:10:01] Josh Hargreaves: Sorry, like a less shall we, , you take over slow, right? So you add a configuration, perhaps you add a build step or whatever. Maybe you already have one and you start writing your stuff in touch group and then soly, it grows and suddenly, you know it, people start to realize that way.

[00:10:19] Josh Hargreaves: Yeah, I think, go and work with people. Try and prove It's one thing that is hard to prove necessarily is, take any example where a, some kind of outage perhaps was caused by. A type error and then you can go and hammer that home to management or whoever if your product and say, Oh look, this would've been caught if we used typings perhaps, or obviously testing perhaps.

[00:10:44] Josh Hargreaves: But yeah, I think there's a, you go and work with people. Just go and do it. Just going outta configuration to type script. I, fortunately, I don't think there's any controversy, not that much controversy these days as to which JavaScripts, [00:11:00] typing system to use. And also just go and make things easier.

[00:11:04] Josh Hargreaves: Like I. There's a people problem in that when somebody creates a new project, if it was like campaign for them, a resistance, shall we say, to create that project and add type scripts, go and figure out like a good project configuration and make it such that people will actually need to actively choose not to use touch scripts.

[00:11:24] Josh Hargreaves: Kind of going. So it does make the path of least resistance type script. That's another good approach, I would say.

[00:11:33] Joe Previte: Yeah. Let's talk about the Blue Bloomberg terminal rewrite. You said you said that you recall maybe spending six months just migrating to JavaScript. That obviously is like a big undertaking, was that something that you also champion?

[00:11:47] Josh Hargreaves: No. So I would say, I think this was talked publicly about at Bloomberg where it There's a, Robert Palmer is the lead on. There was a lot of work which needed to happen to [00:12:00] make type script work at the scale that Bloomberg has. And mainly that's because the way that a lot of the JavaScript on the client side at Bloomberg is written.

[00:12:11] Josh Hargreaves: It's broken down into different modules, which Aren. The same type of modules that the web users, they're not mode modules and they're dynamic modules that are injected at run times. So one of the things that needed to happen was you needed to introduce this kind of cross bundle type checking into the Bloomberg module system, which was a lot of work, and I believe that was talked publicly about.

[00:12:36] Josh Hargreaves: But yeah, the the kind of project itself was. Wasn't championed by me, but I think we needed this. The Bloomberg needed this work done first to enable cross funnel type checking. They ultimately looked to start converting. You libraries that, lots of applications that Bloomberg [00:13:00] use, two type scripts.

[00:13:01] Josh Hargreaves: Thus they get the type safety of all of these kind of libraries that are very commonly used, the kind of the basis of any application. Yeah, that kind of work was was basically done as part of an initiative to obviously convert. This kind of core set of application functionality. And yeah, because there's so much code takes a long time.

[00:13:25] Josh Hargreaves: And I think that's something which a main takeaway of that for me is that there isn't really a shortcut to adding types to your project, right? It's usually quite laborsome. So yeah, it's it's an unfortunate reality, but there isn't really a substitute for just spending your time in a file and.

[00:13:49] Josh Hargreaves: Working out what the types are. So I know that some people have had ideas about perhaps I could infer the types from the runtime [00:14:00] types. That's quite an interesting thing. And there's some clever work there, I'm sure people have done. But this said sometimes it's about. That is just an Im, it's near impossible to drive automatically.

[00:14:12] Josh Hargreaves: So yeah that, that's a big takeaway that there isn't really a substitute for for the hard graph of doing a large scale conversion.

[00:14:21] Joe Previte: What, like what approach do you take? Like how do you break that down and how do you estimate how long it's gonna take for a

[00:14:27] Josh Hargreaves: large estimations?

[00:14:30] Josh Hargreaves: I know a tough question. Yeah. Okay. So how would you do it? I think there's a, there's a broad range of techniques, but ultimately it comes down to. So first, where do you start? Yeah. Something that is quite useful to do is if you take a project and you build a dependency tree of that project and you see where do things depend and you get, say your index file at the top and then maybe you get the bottom some [00:15:00] utilities Utilities a great place to start.

[00:15:02] Josh Hargreaves: Ultimately you are looking to, A good place to start is to convert the leafs of a tree, right? So you start with the leaf nodes and those can be rewritten, converted to type scripts. The reason why you might do this is because any file which imports other files, which are not type scripts, then you either need to convert those to touch script.

[00:15:25] Josh Hargreaves: You either need to, or you write a type definition file for them. Or you dynamically import and discuss it to any, So it tends to make sense to take the bottom leaf nodes and convert them. But it can also make sense to strategically choose. Points in your dependency graph where perhaps there will be a lot of value in writing a type definition file for that note.

[00:15:54] Josh Hargreaves: So if you have a particular utility or. [00:16:00] Something, which itself has a lot of dependencies, but that top level, that node is used by in a lot of places, it can actually make sense to say, let's bring a bunch of type safety to a whole other area of the tree by cutting. The typing here and then we'll say that off that node in the tree.

[00:16:21] Josh Hargreaves: It's still gonna be type unsafe for now, but that will be something we, we tackle later. As for where you start, usually a good place to start is to introduce a build step if you don't already have one. A lot of people use babble and produce bundles anyway, but it makes a lot of sense. The first, introduce a step where type script and JavaScript can operate harmoniously in a project such that, for example, say if I introduced a new utility I added, in type script, wrote the utility, Can I import that type [00:17:00] script file from JavaScript?

[00:17:02] Josh Hargreaves: And if I can, great. That's a really good place to start. And then from then on in, it's picking your battles. It could be, for example, do I have a area of the code, which not that many people. That people are afraid to touch, right? That might be a battle you want to pick because there's a clear business case for converting that to touch script.

[00:17:25] Josh Hargreaves: Because consistently we have errors here that, So yeah, the, you can pick, obviously, you can pick from the perspective of, Oh, this has no dependencies. I'll start here. But you can also choose to. High value places in your code base where, there have been errors before. So for example, you process a lot of payments, maybe that would make a lot of sense, if you are clearly losing money from broken payment, right?

[00:17:54] Josh Hargreaves: So yeah, you can look at it academically. You can also look at pragmatically. [00:18:00] So yeah, there's no real answer, but it's situation dependent. But I usually like to start with things which have not that many dependencies. But like I was saying before, if you want to evangelize type script adoption.

[00:18:15] Josh Hargreaves: Introduce the tooling to build type script in your project and then just start writing it. That's another place to, you don't actually need to go back and convert stuff. You can just start writing it and then slowly before you know it, people will start adopting it. And then you can maybe go back And convert some other pieces, but yeah.

[00:18:38] Joe Previte: Okay. So along those lines, like when you're doing this large scale migration, how do you split up that work amongst team members? What's the approach you've taken?

[00:18:48] Josh Hargreaves: Like I said dependency graph does help. Okay. The way. The way I've worked on it before is create a bunch of Jira tickets, , [00:19:00] and but it's interesting because there can be parts of a project that don't, like I said, don't really necessarily have any dependencies on other things.

[00:19:10] Josh Hargreaves: But you can also reach situations where there can be. Work, which needs to be done before obviously work, other pieces can be typed. For example, this class extends this class, so it can make a lot of sense to unblock people and it's such that the work can be paralyzed as much as possible, but sometimes obviously you need some base level pipings, right?

[00:19:36] Josh Hargreaves: So yeah, it can make sense to not just do this in an ad hoc manner, and plan it out, right? If it's a big conversion, then obviously you can say, break it down into hey, we'll do this. We'll, do you know this, that, and the other different areas of your project, different logical areas, right?

[00:19:54] Josh Hargreaves: So if you're writing, say, a bunch of screens, in a, in an application, [00:20:00] it can maybe make sense to type script convert to type script different screens. So that's a good way of breaking down different logical areas of the application. But like I said, if there's any kind of common utilities in your application, that can be another good place to start.

[00:20:14] Josh Hargreaves: Because and there's also, when we talk about conversion, there's also, the the concept of the type strictness. So just, changing the extension and type casting to any doesn't necessarily provide that much value. Your kind of measure of success. When we talk about conversion can also be how well converted things are, right?

[00:20:39] Josh Hargreaves: So like I said, if you convert a screen to type script, it might import a bunch of different things, which might not have typings yet. So the. Strategically, it makes more sense in a way to do those screens at a point where you have most of the pieces together in terms of the type strictness. [00:21:00] And as you do go on, you do find that it becomes easier and faster to do it because.

[00:21:06] Josh Hargreaves: All of your utilities and types like flowing around. And the safe, there's less casting which, which happens. . And there are also very interesting situations when JavaScript is written typically in a very dynamic way because of the language is dynamic, but type script can't understand.

[00:21:26] Josh Hargreaves: It's not able, due to the nature of the language, it's not able to I guess you would say pass around strictly type type definitions if you've used JavaScript in its true dynamic sense. So sometimes you can actually have to rewrite your code such that it can be type checked samely.

[00:21:46] Josh Hargreaves: And that's really interesting. I've seen some Custom class systems, which are defined by a J spec. And to bring type safety to these, it needed to write some horrific generics [00:22:00] to basically interpret. In type script the object team passed in and generate a type from that.

[00:22:08] Josh Hargreaves: That is pretty much stretching the limits of the type strip compiler. I think I have seen type script compiler errors that basically of the typings have recured too deeply. It, the stack overflow in the type compiler, but that's pretty interesting. But yeah it's there is also a feel something quite therapeutic about converting code to touch scripts, which I enjoy

[00:22:31] Josh Hargreaves: The success criteria is quite understood. It's look, it was JavaScript. Now it's touch scripts. Great. Yeah. I find when I've done a few conversions, I will iterate that I will not fight every battle, right? So I'll look at something and say, I'm gonna cast that to any, So I sometimes will type the type and type script called to do any right

[00:22:57] Josh Hargreaves: Yes. And my success criteria is when I do [00:23:00] a search in the project. When there are very few two duty earnings left, so you don't need to fight every battle to the death for the sake of your own personal sanity. But I go back around, especially if I don't know the types of something. I'll be like, You know what?

[00:23:16] Josh Hargreaves: We'll come back to that later. We'll do some nice trivial stuff and then come back and get rid of these compiler errors.

[00:23:24] Joe Previte: Yeah, no I've definitely adopted a similar technique in migrating larger projects and yeah, cuz like when you're moving quickly, you wanna keep the momentum going and being able to declare that type, like to do or fix me later allows you to fix it, but then come back

[00:23:39] Josh Hargreaves: later.

[00:23:41] Josh Hargreaves: Yeah, for sure. And you can do interesting things on PRS as well. I don't necessarily know if this is a reason not to merge a PR always, but you can do reporting on the you can do reporting. On, the type safety of the, of a [00:24:00] project. And you can also there's some good just rules, no explicit any and stuff like that.

[00:24:04] Josh Hargreaves: Which you can disable, but it's also good sometimes to have to explicitly disable a rule. On a portal request, somebody can ask why did you disable this rule for the file or for the line? And, hopefully you've got a justification for it. .

[00:24:19] Joe Previte: Right. Exactly. Yeah.

[00:24:20] Joe Previte: Speaking of Jess and Eslan or ts Lent rules are there any others that come to mind that have been very helpful for you in the past?

[00:24:29] Josh Hargreaves: Oh, that's a good question. I, it's hard on the spot, but yeah. No explicit any. It's a good one. I think it's also, Sorry. No implicit any, not explicit . I think there are both rules I think, yeah, those are two good ones.

[00:24:45] Josh Hargreaves: One thing that is important, it's not even a lint rule. I think it's typically speaking, it's better in my opinion, not to implicit assign. Any [00:25:00] implicitly to a JavaScript import. So if you have a type script file that imports some JavaScript, the type script compiler for the sake of. Migration or easier migration might actually let you implicitly sign any, I believe there's is just a ts config option where if you import JavaScript with this option, that's true.

[00:25:24] Josh Hargreaves: It will distance sign any to that import. My opinion is I don't like the false sense of security. I would prefer to explicitly give that the type any Such that you know, no one's under any illusion. Cause otherwise you don't know. It looks the same as A type script import.

[00:25:43] Josh Hargreaves: So I prefer, and I think it's probably better to pay the cost of maybe adding. Type definitions. Even if you add a DTS for a module explore any, from that module. But [00:26:00] I think it's better to explicitly give a, give any a type rather than have it be implicit such that you don't get that kind of like false sense of security.

[00:26:12] Joe Previte: . Yeah, no that definitely makes sense. Like depending on the situation, how much you wanna trust the compiler versus like how much explicitness you want to give to your code base, especially when you're doing a large migration.

[00:26:24] Josh Hargreaves: , I was gonna say full sense of security with type things can actually be worse than Yeah.

[00:26:29] Josh Hargreaves: No typings at all, right? You're like, Yes, this is the type. Yeah. And you do see you do see things which are fairly difficult, like API responses are quite difficult to type, and that's why, I haven't actually used it professionally, but like the GraphQL schema type definition stuff, I think from Apollo makes a lot of sense.

[00:26:49] Josh Hargreaves: And you actually get value from having your API to be strictly tight. And I've seen You, I think have similar things in Ag [00:27:00] corporations to basically have this runtime check. It's actually quite useful. And you can do the same thing in type scripts where you say, I can't remember the actual term for it.

[00:27:10] Josh Hargreaves: , but you can basically write a function which tells type script that something is of a certain type. So you can write your own type run time validations. So I tend to I tend to error on the side of, I'd rather throw a runtime assertion. Or, sorry, assert something to be true and then touch script then knows further down the line that is actually true.

[00:27:36] Josh Hargreaves: So rather than let things continue under this false pretense, perhaps I think to prefer to be more defensive in terms of writing these run timer sessions. Rather than, have things go further. Cuz that, that's basically how I've tended to deal with these issues where you don't actually know the type of things.

[00:27:57] Joe Previte: .

[00:27:57] Joe Previte: Yeah. I'm trying to think like a user defined type [00:28:00] guard,

[00:28:00] Josh Hargreaves: Right. Is that I can give you one. I can give you, Yeah. Yeah. The dom is notoriously difficult to type And type guards, if you've done any kind of touching the dom properties and you might even say, Hey, I want to check if.

[00:28:16] Josh Hargreaves: Things, a particular type of dom node, right? So you can actually, some of the I don't know, maybe these utilities don't exist in the typical do typing, but you might actually want to write some kind of validator, which says, Is this a, an ally node? And you can you Google and stack overflow?

[00:28:35] Josh Hargreaves: People will say, this is how you, oh, it's the type or whatever. But you can say, Oh, if this function returns true, then we know it to be of type. Domino. So even if your Dom typings library doesn't have this kind of thing built in necessarily, when I say your dom typings library, I think there is the one on mpm.

[00:28:56] Josh Hargreaves: It's not always perfect. So sometimes it can be useful to write a [00:29:00] custom guard to say, actually we know because of this property being true, that it's of typed this. Even if it isn't, the official like Don property, I can't remember what it's said, Node type or whatever it's for

[00:29:11] Joe Previte: . Yeah. Speaking of working with type script on the web versus working with type script, in, in the mobile space, like with React native, have you found one to be more difficult than the other?

[00:29:22] Josh Hargreaves: I think I found the like I was saying before there was a time where it was quite difficult to type high rodder components.

[00:29:31] Josh Hargreaves: And the. Number in type scripts specifically, there were way less kind of inbuilt types to use. So it's not to say you couldn't define your own types, but specifically for React components, that story is a lot better these days because. Simply put, they have, they exist. Now, it's not to say they were entirely limited by the type system before but now there are these high quality [00:30:00] generic types that you can use.

[00:30:01] Josh Hargreaves: So specifically say you have a component. And it's your component now, it's fairly easy to get a type which represents your component with its properties and stuff like that. And I seem to remember though it was again, I haven't actually written React type script for probably a year or so, but it was if you do funky stuff with a higher order component where you extract a property and then you say, actually, my new component takes the subset of properties.

[00:30:33] Josh Hargreaves: And that a few years ago was quite difficult to do in touch script. So yeah.

[00:30:42] Joe Previte: So yeah. This is probably, Yeah, I'm sure even like you said, it's been a year and like things move so fastly and so quickly in the web, so I'm sure it's completely different now.

[00:30:53] Josh Hargreaves: Yeah, I've think, the most recent thing I've worked on was a node based service.

[00:30:57] Josh Hargreaves: Which in a way is there, I think [00:31:00] the types for node and all the libraries are quite well defined these days. I think. Things get a little bit trickier with generics. Where, obviously React is quite generic. Those typings need to be generic because we are all writing generic components, typically speaking.

[00:31:19] Josh Hargreaves: Sorry, we are writing our own components, thus the typings need to be generic, so there was a time when I think like a few years ago, using flow. Like I said, the higher order components were difficult to type, but any, anything which is doing anything a bit more funky with the type system was just typically difficult, more difficult to to type.

[00:31:43] Josh Hargreaves: But these days with type scripts alone yeah, the the type system is pretty flexible. The React component types are very well done, I think. And it's pretty, it's [00:32:00] a pretty these days there's just a lot more information on, on how to do certain things in types groups. So it's a, like I was saying, Just even from like libraries having types these days is infinitely better than a few years ago.

[00:32:14] Josh Hargreaves: Because the friction and I talked about the friction before, the friction to using type script, people would get a lot more frustrated with typing because it was impeding their ability to write code. If every time you use a library. You have to write type definitions for it. That's a pretty, that's a fairly fairly inconvenient to say the least.

[00:32:36] Josh Hargreaves: Hence my tweet from 2016 . But yeah, no, these days it's a lot better, , it's a lot more pleasant, And I think, we a lot, it just seems to be, type script is obviously. People are reaching for a lot less, Sorry, a lot more now. , funny enough from writing type script, I think I've never really written that much of it myself but a friend of mine who [00:33:00] I'm actually gonna see in Chicago next week, but Peter pco who the co-founder of.

[00:33:08] Josh Hargreaves: Which is a visual, Yeah. Rat native editor. But he's been on the the reason ml or what do they call reason, What do they call it these days? Rescripts. Rescripts. There we go. Yeah. Yeah. Rescript. I think funnily enough when you get a taste of the type safety of type scripts, I almost, and I found myself leaning this way as well as I would almost wish that it was, there were less JavaScript.

[00:33:32] Josh Hargreaves: Nurse in the type system, so if it was pure, So I've never written rescript professionally, but and to be honest, it would probably be. We have to be pragmatic right in, in typing. The reality is the, it's a lot harder to get JavaScript developers to learn a, basically o Camel than it is, just a flavored type flavored [00:34:00] variation of Javas.

[00:34:02] Josh Hargreaves: But I think after I've spent a lot of time writing time script, you get this kind of feeling like it was pure, wasn't any, wasn't just gonna flow through your I to remember, I actually saw a talk react. I react for lung. I didn't react to Europe a few years ago where there was a. Meta engineer who talked about similar kind of thing with the, with messenger.com being written in Rescripts where there's this feeling of this part of your project, which is A sanctuary from the the abuse of JavaScripts in, in some way.

[00:34:41] Josh Hargreaves: And I always say I love JavaScripts it's, , it's, it's been by, I guess my bread and butter for a few, for professionally, for, but yeah, I do get this feeling was I just, you almost wish that it was just, pure. So I say, there's been interesting the people who have all gone all in on type [00:35:00] safety to leave JavaScript behind.

[00:35:02] Josh Hargreaves: But I do get a feeling sometimes, it would be nice perhaps,

[00:35:06] Joe Previte: Yeah, and it's so hard to know. Like you were saying, it's, it's one thing to hire JavaScript developers and teach them type script, but like to hire OK camel developers or hire people who have rescript or reason, experience, That's, That sounds really hard.

[00:35:21] Josh Hargreaves: Yeah, I actually heard of something recent. Oh, it was a few years ago, I think. But it was quite interesting. I think Facebook were running flow on bear metal or something like this by basically transforming strictly typed flow to o came. I think that's what they were doing. Don't quote me on that.

[00:35:45] Josh Hargreaves: But it's quite interesting because when you are hauling around the quirks of the JavaScript dm, and obviously you have no choice but to run it in you have no choice but to run it obviously on the [00:36:00] J Svm. But it's quite interesting that as you potentially, if you were to move away. Strictly type language, then you, it can obviously be a lot closer to machine code, And obviously the machines don't really like this notion of, this could be any type that turns out that's not great for low level assembly.

[00:36:23] Josh Hargreaves: But yeah, like I was saying before about this this notion. You the strictness of the types in your project. I think it's quite interesting and it's no surprise that Facebook have done something completely crazy, to try and transpire flow to reason. This said a strictly typed.

[00:36:42] Josh Hargreaves: JavaScript project with Flow is not too far away potentially from the, reason syntax. Oh, Camel syntax, It turns out. Yeah, it is it's pretty interesting. And there's lots of like potential academic things which can be done as a result of it.[00:37:00] And it is interesting because, I guess being in the React native space there was a fairly large cost to pay to using the JavaScript engine historically in a mobile application.

[00:37:14] Josh Hargreaves: It's fast, but it's not that fast. And one of the costs that had to be paid. And React Native was going across a bridge from Native to React Native and sorry. From Yeah, from native to script and vice versa. And to be able to go from JavaScript into native, particularly when it comes to marshaling types primitive types and whatnot.

[00:37:40] Josh Hargreaves: And so we're now seeing this with. With jsi, which is the JavaScript interface for JavaScript to Native and back with React Native and the new architecture with fabric. Yeah. Some of the work that Facebook have had to do is to try and make it developer ergonomic [00:38:00] to right modules that go.

[00:38:03] Josh Hargreaves: JS to native and back again, but obviously if there was no JS VM involved, then perhaps that would be somewhat more trivial. If the types themselves were closer to to like the native types and not this kind of Java group flavor of types.

[00:38:20] Joe Previte: Yeah, that's, it's super fascinating. I was watching some of your talks and I know you've done a lot of performance work.

[00:38:27] Joe Previte: But obviously like none of that has been affected in any way by type script, right? Like you haven't seen any, you haven't, like we talked about catching runtime, bug. with Typescripts. You're not gonna, I guess from your experience working with Type Script, you haven't had any opportunity where you've, I don't know, caught something that affects performance through TypeScript?

[00:38:49] Josh Hargreaves: No I think TypeScript is typically, a project which is written in Typescripts and a project which is written in JavaScript. In theory, if your JavaScript has no type [00:39:00] typing, sorry, has no bugs, then they'll obviously, they'll run the same, I think something that's become apparent to me, I guess over the last few years, and you can see this with Swift UI and shall we say what was it com I'm trying to remember the other.

[00:39:19] Josh Hargreaves: The Android one, Kotlin Co. Not Kotlin, but the framework that they've built with Kotlin. Leland Richardson went from working at Airbnb to go and work at Bulo on this, but we see these we see these. Frameworks which funnily enough are strictly typed. Swift is typed Kotlin is typed.

[00:39:41] Josh Hargreaves: But it's interesting to see these languages which have basically. First class type support for for the UI frameworks that that they are it's interesting when you think about, let me say performance, , that SWIFT ui, for example, [00:40:00] makes a decision with type checking to say that if you want your, and again, this is based on something.

[00:40:09] Josh Hargreaves: I read saw about a while ago, but it's interesting to, to see from a more academic perspective the choices that these frameworks are making. But I believe Swift actually makes you opt in to having a dynamic part of your hierarchy. So it basically says, as a default, React Native or React will basically let you.

[00:40:36] Josh Hargreaves: Anything of any shape. Whereas Swift ui, I think will essentially make you opt into that behavior if you want something truly dynamic. And that's just simply because of performance. It's more performance optimal to, And so to bring it back to typings, this is enforced by the type system. It basically says, Hey, you're trying to do all the,[00:41:00] all the compilation system, whatever.

[00:41:03] Josh Hargreaves: It will it will catch that compiled time, I believe. So that's interesting because. It's something which React doesn't have. And we actually found this with some of the work I worked on at Bloomberg was I guess I maintained a li a third party reacts render, which I guess I have talked about.

[00:41:22] Josh Hargreaves: And it basically targets Bloomberg's UI terminal UI system called R plus. And The interesting thing is that some of the conversations that we had at Bloomberg were when an application team would ask, Hey, can I use can I use Reactor Plus in our project there are certain considerations.

[00:41:45] Josh Hargreaves: Performance being won. If you are having a big dashboard and for every data tick, you'd have to run the React RECONCILER stands out. That's not very performant. And this is [00:42:00] reasonably well accepted in the industry that That, even a lot of what Facebook have done with the scheduler is not necessarily about making react more performant.

[00:42:12] Josh Hargreaves: It's actually more about scheduling the work to be done at time, which isn't as obvious to the user perhaps. And so it's interesting where we talk about pipes because Al which is I guess it's a library for making applications on the web . It compiles away a lot of this stuff.

[00:42:35] Josh Hargreaves: And there's some interesting demos where you can see side by side with felt and react where well is a lot quicker. And obviously, metrics are, sorry, low performance metrics sometimes can be arbitrary, but the type system actually allow. It's felt to actually glue stuff together and compile away some of this reconciliation, which, which happens to react.

[00:42:59] Josh Hargreaves: And that, [00:43:00] similar philosophies were taken for making certain components, data driven tables and that kind of thing. My previous work because it's a lot easier to wire things. Basically say this thing goes straight to here. From a performance perspective, if you are doing reconciliation of react and working out what's changed that, that turns out that's not very performant to do, but actually the type system or a DSL or some description can actually perhaps compile some of this stuff away.

[00:43:33] Josh Hargreaves: So I haven't actually looked in too much detail about House Felt does some of this stuff, but it's quite interesting. That seems to be a theme going forward in, in UI frameworks is, like I said, with Swift ui, the dynamic behavior of React and the fact that a component function, whatever, can return anything of any shape, actually makes it hard to optimize for.

[00:43:59] Josh Hargreaves: So it [00:44:00] is, yeah, I mean it's, it is interesting and I've actually found more so with looking at large scale react applications, that's a common theme throughout the industry will be, Oh, I optimized my application. Because it turns out it was re rendering every single time anything happened changed in a global state object, so it turns out you have a gazillion reduces and funks and or SS that run. Every single time, like a key press happens, it's potentially not great. Yeah, it's, it is interesting and yeah, I've heard this anecdotally from people over the years and I've spoken to say Christoff from Software Mansion and similar kind of story.

[00:44:46] Josh Hargreaves: They have clients who have an application and they have a screen that's on top of another screen and something's changing on the top. It's re rendering the bottom screen. It's it happens all the time. And I think it comes down to sensible default. [00:45:00] And I just typically have found it's quite easy to write, badly performing react applications.

[00:45:06] Joe Previte: .

[00:45:06] Joe Previte: Yeah. That that definitely sounds tricky, but yeah, I like what you said about Sensable defaults and, it sounds like the industry is moving that way. But yeah. Let's let's wrap there. This has been awesome. I think, the last thing that I want to ask from you is where can people connect with you?

[00:45:22] Josh Hargreaves: Oh you can connect with me on Twitter. It's at Josh j Hargraves, which is my last name. Or you can, cuz you could just add me on LinkedIn or I don't like LinkedIn very much is basically complete cesspool of self-promotion these days. But yeah, Twitter, I like Twitter. It's, it feels.

[00:45:45] Josh Hargreaves: Pure ish. It's it's a good way, it's a good way to connect to people and I've, have met some really interesting people through Twitter. Like I said, Peter Kar, he's a really interesting person. Great engineer and I met him through [00:46:00] there and even went Tora Poland and met Coff and a bunch of other people at Software Mansion.

[00:46:06] Josh Hargreaves: That was actually through a GitHub issue which has Christoff reached out to me on Twitter app. I implemented on Key Press for Android and React Native , and I apologized in advance because turns out key press is Android are pretty difficult.

[00:46:24] Joe Previte: Hopefully no. We don't have an angry mob coming after at

[00:46:27] Josh Hargreaves: you when this goes live. I think, yeah, I think I can't remember. It was a few years ago now, but I think the numbers basically. Didn't fire the key event cuz you know, you essentially needed to opt into a different system event, which I didn't implement , but the, Yeah.

[00:46:45] Josh Hargreaves: Long story short, with that, the thing I was trying to fix, It was ultimately, it was impossible to detect if someone had pressed a backspace on an empty keyboard. So that's, that was the key, no pun intended, the key thing to fix. But [00:47:00] yeah, so yeah. Yeah, definitely. If you got any questions About, software engineering as a whole and the industry.

[00:47:08] Josh Hargreaves: Any questions about Netflix, I would also be happy to answer them as well. So yeah, definitely add me on the social medias .

[00:47:16] Joe Previte: Awesome. We'll we'll get some links and we'll throw those in the show notes after. But Josh, thanks again. This was awesome. Thank you so much for sharing all your knowledge.

[00:47:24] Joe Previte: And we'll catch you.

[00:47:26] Josh Hargreaves: Great. Thanks Joe.