Best Practices for Large-Scale TypeScript Migrations with Josh Hargreaves
Joe chats with Josh about the best practices for migrating large code bases to TypeScript at Bloomberg and Netflix.
Josh is a software engineer who graduated from the University of Bristol with a master’s degree in computer science. Upon graduating, he began working for Bloomberg in London. After moving around and working in various roles within the company, he ended up on the infrastructure team.
Josh mentions that working through code that you didn’t write, and converting it to TypeScript, is a fantastic and effective way to learn the code base.
He talks about the approach he uses when taking on a large-scale migration, such as the one he handled at Bloomberg, stating that building a dependency tree for the application is quite useful. He says that a good place to begin the conversion is the leaves of the tree. The reason for doing this is that any file that imports other files that are not TypeScript either needs to be converted to TypeScript or have type definition files written.
Josh talks about type validation within TypeScript in order to eliminate runtime errors - for example - checking if a property is a particular type of DOM node.
He also mentions the improvements in typing higher-order components within React TypeScript compared to how difficult it was in its earlier days.
- Josh Hargreaves: https://medium.com/@joshyhargreave
- Josh on GitHub: https://github.com/joshjhargreaves
- Josh on LinkedIn: https://www.linkedin.com/in/joshjhargreaves
- Josh on Twitter: https://twitter.com/joshjhargreaves/
[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: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: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: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: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: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: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: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: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: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: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: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: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: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:35:02] Josh Hargreaves: But I do get a feeling sometimes, it would be nice perhaps,
[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: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: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: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.