Priscila Oliveira and Mark Story join the panel to discuss the recent transition at Sentry from vanilla JavaScript to React and TypeScript.

The show starts out with the panelists nerding out over Sentry and how they use it, then they dive into the code transition and the things that they learned from their conversion to TypeScript.

Panel

Guest

Sponsors

Links

Picks

Contact Aimee:

Contact AJ:

Contact Dan:

Contact Steve:

Special Guests: Mark Story and Priscila Oliveira.

Sponsored By:

DAN_SHAPPIR: Hello everybody and welcome to another episode of JavaScript Jalper. Today on our panel, we have Amy Knight. 

AIMEE_KNIGHT: Hey, hey from Nashville. 

DAN_SHAPPIR: AJ O'Neill. 

DAN_SHAPPIR: Yo, yo, yo. Coming at you live from the darkest of dungeons. 

STEVE_EDWARDS: Hmm. I don't know. It looks pretty purple. So it's, I don't know how dark it is. Sort of purple. 

DAN_SHAPPIR: And that's Steve Edwards. 

STEVE_EDWARDS: Hello. Hello from Portland. 

DAN_SHAPPIR: I'm Dan Shapir from Tel Aviv in Israel. And today we have two guests on our show. So double the fun. We have both of them are from Sentry. We have Priscilla. Correct.

PRISCILA_OLIVEIRA: Yes, correct. Hey all, thanks for having me. 

DAN_SHAPPIR: And also Mark, Mark's story, right? So welcome to the show. And where are you guys located? Can you share with us? 

PRISCILA_OLIVEIRA: I'm located in Vienna, Austria. 

DAN_SHAPPIR: Oh, that's very, very cool. And how about you, Mark? 

MARK_STORY: I'm in Toronto, Canada. 

DAN_SHAPPIR: I hope the weather is fine. You're having a bit of an interesting time, no? Priscilla? 

PRISCILA_OLIVEIRA: Oh, yeah, it has been raining a lot here. We have very hot days and then rainy days and yeah it's a weird weather and time. 

STEVE_EDWARDS: Feel free to send some of your rain our way we could use it out here. 

DAN_SHAPPIR: I'm not so sure Steve they're having really significant flooding not so far from where she is I think. 

STEVE_EDWARDS: I didn't say all of it I just said some of it just some of it not all of it. 

PRISCILA_OLIVEIRA: Yeah in Germany, Netherlands and Belgium I think. 

DAN_SHAPPIR: Oh okay then stay safe and today I think we're going to talk about TypeScript or specifically about how to take an existing project and transition it to TypeScript. 

 

This episode is sponsored by Sentry. Sentry is the thing that I put into all of my apps. First, I figure out how to deploy them. I get them up on the web, then I run Sentry on them. And the reason why is because I need to know what's going on in my app all the time. Yeah, I'm kind of a control freak, what can I say? The other reason is, is that sometimes I miss stuff or I run things in development, you know, works on my machine, I've been there, right? And then it gets up in the cloud or up on a server and stuff happens and stuff breaks, right? I didn't configure it right, I'm an idiot, and I didn't put the AWS credential in I didn't do that last week, right? That wasn't me. Anyway, I need that error reported back. Hey Chuck, I can't connect to AWS. The other thing is, is that this is something that my users often won't give me information on, and that's, hey, it's too slow, it's not performing right. And I need to know it's slowing down because I don't want them going off to Twitter when they're supposed to be using my app. And so they need to tell me. It's not fast enough and Sentry does that, right? I put Sentry in, it gives me all the performance data and I can go, hey, that takes three seconds to load, that's way too long and I can go in and I can fix those issues and then I'm not losing users to Twitter. So if you have an app that's running slow, if you have an app that's having errors, or if you just have an app that you're getting started with and you wanna make sure that it's running properly all the time, then go check it out. They support all major languages and frameworks. They recently added support for Next.js, which is cool. You can go sign up at sentry.io slash sign up. That's easy to remember, right? If you use the promo code JSJABBER, you can get three free months on their base team plan. 

 

DAN_SHAPPIR: But before we go there, can you tell us a little bit about yourselves and what you do at Sentry and maybe even what Sentry is all about if somehow somebody doesn't already know? 

PRISCILA_OLIVEIRA: Yes, sure. So my name is Bracila. I'm a Brazilian software engineer based in Vienna, Austria. I am currently employed at Sentry, work on the user interface of our application. Sentry offers an error and performance monitoring platform, helping developers identify, fix, and optimize the performance of their code. 

MARK_STORY: For myself, I also work at Sentry with Priscilla. I'm currently on the revenue team, so I work on the billing and the usage counting aspects of Sentry. But in the past, I helped work on the performance monitoring tool and built all of that out. 

DAN_SHAPPIR: Now I'm familiar with Sentry because we actually, I work at Wix and we actually use Sentry at Wix. But can you tell us a little bit about what Sentry is, if like I said, if somebody doesn't actually know what it is or isn't familiar with it? 

MARK_STORY: Sure, Sentry is a crash reporting and performance monitoring tool. So you can think of like when your application crashes, you may like use a log file. And so what Sentry does is kind of replace that log file with a much richer way to view and analyze error reports. So it's error reporting, then crash reporting and performance monitoring. So we focus a lot on web technologies, web stacks and getting more into native and mobile stacks as well. 

STEVE_EDWARDS: Yeah, I'll jump in here and say that, yeah, GoTry, we're a huge user of Sentry and my boss wanted me to let you know we're big fans. So we live in Sentry every day. I, you know, my...My every morning I come in and see my sentry alerts, my email. 

MARK_STORY: Yeah. So I guess they kind of build on it. Like the, there's like a, we take the errors from your application and then we can do alerting and reporting, give you breakdowns on like what happened and who was affected and how many people were impacted, all that kind of stuff. 

DAN_SHAPPIR: Yeah. One of the things that we use it for is exactly for error monitoring. I mean, for example, if there's some, somehow a bug got deployed in the JavaScript code for the client and you know, an uncalled exception because of and then we get reports for that. And what I really like about it is that it kind of aggregates the error messages together. So it's not like you're bombarded with a ton of error messages that are slightly different because of various browser and device versions, but it's aggregated together so you can actually understand where the error is and you get the stack trace. So it's fairly straightforward to identify the cause of the problem and then either roll it back or maybe deploy a fix or whatever. So we definitely looking at the error counts and error reports is one really important thing that we do with it. 

MARK_STORY: I would say that you kind of hit it up right on the nail on the head. Like when you're dealing with client-side JavaScript, you can't use logging because there's images log into the person's browser. And so where it really shines is environments where you don't have control of the infrastructure. And that's where we've seen a lot of adoption in like JavaScript and in mobile where traditional logging doesn't work. And so error reporting works fantastic there. Like you can actually see what's going on and get the stack trace and get the local variables and be able to see a lot more of what's happening there. 

DAN_SHAPPIR: And I believe you have both a free and a paid version, correct? 

MARK_STORY: So there's two kinds of free. 

DAN_SHAPPIR: Can you elaborate a bit? 

MARK_STORY: Yeah. So there's a, the hosted version, like a developer plan on the, on the SaaS product, which is one we run. And then we also produce an open source version of the main server components. So if you want to run it yourself, you can. Yeah. Those are the two ways we give it up for free. 

DAN_SHAPPIR: And the client side part, the thing that runs in the browser or in the mobile device, is that part of both? 

MARK_STORY: Yeah. The SDKs, we call them SDKs. They're the same across both the self-hosted and the, the, the, the sentry hosted versions and all of that code is released under like an MIT license. 

DAN_SHAPPIR: Cool. And which part of your application did you actually transform into TypeScript? 

PRISCILA_OLIVEIRA: Everything. 

DAN_SHAPPIR: So both the client and the server? I just don't... Or let's put it differently. What was originally written in JavaScript that you transformed into TypeScript? Or do you also have parts of your application stack that are written in some other programming language that you didn't touch? 

PRISCILA_OLIVEIRA: So we converted our client side to TypeScript. 

MARK_STORY: The JavaScript SDK had been migrated to TypeScript before. And so we use that kind of experience to build on and like migrate the front end of the product as well. So 

DAN_SHAPPIR: I think it might be worthwhile to start with the why. I mean, you had a working JavaScript implementation, I assume it was working. And there's a famous developer saying that if it ain't broke, don't fix it. And yet you decided to fix it. So my primary question then to begin with is given that you had the working JavaScript implementation, why did you feel the need to rewrite it effectively in TypeScript? 

PRISCILA_OLIVEIRA: Because TypeScript would bring a lot of benefits to Sentry. For instance, several classes of bugs could be detected and eliminated during compilation. We could improve the developer experience through editor integration, such as IntelliSense faster code navigation and inline compiler feedback. We could reduce the need for API documentation as type notations help produce self-describing code. TypeScript has also an active community. Another benefit would be the libraries we already use, already have type definitions available. And we could adopt TypeScript incrementally. So we could take our time. 

DAN_SHAPPIR: So about that, putting it in incrementally, or actually before that, if we go back to the motivation, can I ask how large your team is, the team that's working on this front end part? 

MARK_STORY: Yeah, sure. There's about 10 developers, around 10, that are focused on front end. And then there's a larger, broader team of like, Developers are more like full stack and do occasional front end contributions. Um, but it's the bulk of the TypeScript conversion work was done by the, like the, the 10 front end engineers. I don't know if it's 10, maybe it's seven or eight. 

DAN_SHAPPIR: And suppose rather than eight, let's say it was only four. If, you know, if it were a smaller project or three, would you, do you think it would have still been worthwhile or is it like related to the fact that it it's a larger team of developers. 

MARK_STORY: I think some of the wins come from a larger team. I would probably still do the conversion if it was a smaller team. If the code base was equally smaller. So we're like a seven or eight person team and like around 95 to 125,000 lines of code for the front end. But if it was like half that team and half that code, I would probably still do it. Like Priscilla mentioned earlier, like being able to detect and eliminate a whole bunch of bugs just through compiler checking was a huge benefit. We were having those bugs come up quite a bit and causing customer-facing outages due to front-end bugs that could have been caught by a compiler. So it seemed really like very straightforward for us. It was an easy sell to say these bugs could have been prevented if we had type checking. And since we've kind of adopted TypeScript, those kinds of bugs haven't happened. So it's not just the tiger fence where if you put up a fence, tigers won't come to your house. There were tigers.

AJ: Are there any alternatives to TypeScript that you're aware of or that you considered for adding more safety to JavaScript? 

MARK_STORY: Yeah, there's a couple other options. There's a flow out of Facebook. And then if you want to go like way off the beaten path, you can actually write front-end code in Rust and then compile the Rust into into Wasm. But that's, that was a, that was a much bigger lift for a team of our size.

AJ: I don't know. That sounds, that sounds attractive to me. 

STEVE_EDWARDS: I know that would sound attractive to you, AJ. You're a back-up guy anyway. 

DAN_SHAPPIR: But the integrations with the JavaScript part, I think would have also been, uh, much more complicated. I mean, you would have had to implement various bridges to integrate with the various DOM APIs that I assume that you use within your library. 

AJ: Do you use DOM APIs? 

MARK_STORY: Uh, a little tiny bit. You have to, a little tiny bit. Like you have to use like local storage and you have to use some like basic event handlers just to get the React app kind of set up. We also, it's essentially a fairly old application in terms of like... 

AJ: Wait, React app? 

MARK_STORY: Yeah, it's essentially a React app. 

AJ: Holy moly. Yeah. I thought it was like a little logging facility. 

MARK_STORY: Yeah, little. It has a fairly big front end so the front end is the piece that we move so that's like your issues view and like your timelines and lots of charts. 

AJ: Oh, so you're not talking about the code that you insert into the browser to capture the browser logs. 

MARK_STORY: No. 

AJ: You're talking about the application that's the back office, well, not back office, the front office, the side office for the person that's viewing. So this is not what's being delivered to customers. This is what a customer views to see results from what's been delivered to customers.I totally missed that. So it probably said it. 

MARK_STORY: It's not the SDK. So we call that the SDK is the piece we give to our customers and they integrate it into their application. And then when their application breaks, it sends data to Sentry. We were focused on like this conversion project was for the front end of Sentry. So that's like the admin panels and all the like dashboards and reporting and all the error. 

AJ: Okay. 

MARK_STORY: All that kind of stuff. 

AJ: Okay. Okay. Yeah. Cause I was looking at your blog post. And it's got like the graph starts at a thousand JavaScript files and goes down and it's zero typescript files and goes up to 2000 and I'm like, what in the world does a logging utility need 2000 files for? 

MARK_STORY: No, no, it's just a React application. 

DAN_SHAPPIR: Well, it can be really small files, you know, AJ, if you, if you bundle them together, 

AJ: five gigabytes of NPM, all F path. Yeah. 

MARK_STORY: Is even just do that 10,000 times.

AIMEE_KNIGHT: One question I have. So when you guys decided to do this, I'm curious because I hear a lot of people kind of like they don't have a lot of test coverage. And so they think that this is going to be really helpful with that. So I'm curious like what your unit test coverage is and kind of what your end to end test coverage is before you decided to do this. 

MARK_STORY: The test coverage is hard to quantify. Javascript is not great at giving coverage numbers. And the coverage tool... 

AIMEE_KNIGHT: What a...I'm sorry, I kind of interrupted there. So you have like, you can't even quantify like your unit test coverage or are you just doing end to end tests? 

MARK_STORY: So we do do like JavaScript unit tests, but we don't track the coverage numbers over a long period of time. 

AIMEE_KNIGHT: Okay. 

MARK_STORY: And then we do also do acceptance tests like the browser automation tests, but we primarily use that for visual regression and like very light amounts of like interaction testing.

AIMEE_KNIGHT: So I guess like the question that I'm trying to get at is like, do you think that this was a like replacement for that in any way, shape or form or not necessarily? 

MARK_STORY: No, I think it would be fairly reckless to replace your test coverage with TypeScript. 

AIMEE_KNIGHT: Good, that makes me feel better. 

MARK_STORY: To assume that the compiler can replace all of your testing is a reckless decision. 

AIMEE_KNIGHT: Yes, thank you. Thank you. 

STEVE_EDWARDS: Dang, we were talking about TypeScript and I was hoping to get rid of writing tests. 

MARK_STORY: No, I don't think you... So much for that idea. You still need to write tests for like, does the application work? The compiler will tell you that you have not divided like any strings by the number two or like you haven't added a string to an object making a nonsense string. But what the compiler can't tell you is if it does the right thing. All it can tell you is like you didn't, you know, add a string to a number anywhere where you would get a result that doesn't make sense.

DAN_SHAPPIR: So I'm curious about that. I mean, like in reality, like how many additions of strings and objects that you actually have in your code? Or let's put it this way. You said that it eliminated a whole class of user facing errors. And while I get static typing, I am wondering what kind of errors in particular you saw that were eliminated. 

PRISCILA_OLIVEIRA: For example, you, maybe you, you try to access a property of an object, but the object is undefined. So TypeScript will yell at you and you will see that it's an error and you have to fix it. 

MARK_STORY: I think it becomes most valuable when you're dealing with optional properties or optional objects, like things that haven't been loaded. So you're waiting for a request to resolve and you just assume it's, it, you could make the error that it assume that it's already loaded or that the property is always defined. And like Priscilla said, like it could be undefined and TypeScript forces you to handle all of those scenarios first. 

DAN_SHAPPIR: By the way, besides React itself, are you also using some sort of store or were you just, or were you primarily using React itself, you know, like hooks or stuff like that?

PRISCILA_OLIVEIRA: We started using hooks now after the conversion, finally, but we do. We have some state management libraries in our code bases, such as Redux. Please correct me, Mark, if I'm wrong. 

MARK_STORY: Reflex, the awkwardly named sibling to Redux. 

PRISCILA_OLIVEIRA: Reflex. Yes. I think we also have MobX. We do. 

DAN_SHAPPIR: Oh, both of them. That's interesting. 

PRISCILA_OLIVEIRA: Yeah, 

MARK_STORY: why not? 

DAN_SHAPPIR: Let's do all, let's do all the state managements. Why not? And. And how did you find that these state management solutions worked with TypeScript? I mean, I know that React has pretty good TypeScript support built in, but how about the various state management solutions that you were using? 

MARK_STORY: Uh, reflux was okay. The types that came with the version of reflux we're using aren't perfect. So we kind of had to hack around them a little bit. Mobex was fine.

DAN_SHAPPIR: And another question that I have like a similar vein is sometimes when I see projects that are transitioning to TypeScript, especially if it's not rewrite, but rather refactoring an existing project, then in JavaScript, especially if you're working with JSON data, which is a lot of, in a lot of cases, that's kind of the data that you're retrieving from the server. It's kind of this, this sort of a property bag where certain properties sometimes exist and sometimes they don't. And then I'm kind of wondering about the value of trying to add type annotations to this stuff. Like when you have an object where literally, like it's all you can literally say about it is that it's a collection of key, of string keys and general values. Then, then what are you actually gaining in that type of a scenario? 

MARK_STORY: You're talking about like the bridge between like an API response comes in and it's a, it's a bag of stuff. And then how do you turn that into a type annotation?

DAN_SHAPPIR: Exactly. Because otherwise, otherwise you all you can literally say about it is that it's an object with properties. And that's not a lot of type information. 

AJ: Well, that's a hash. Yeah, it's a different use case. It's not it's not an object in the classical sense of an object. It's a it's a collection. 

DAN_SHAPPIR: Yeah, I totally which is why I refer to it as a quote unquote JSON object. It's just that these sort of things are really common in JavaScript, especially when you've got the front end communicating with the back end, retrieving data from it. And what I see is sometimes when you're looking at the type information or the type declarations for stuff like that, you either see some interface where everything is specified as being optional, or you see some sort of an interface that's literally just defining it as the string keys and object values. In either case, you're potentially not getting a lot of value. So I'm kind of curious about how you dealt with scenarios, if you actually encountered scenarios like that, and when you did, how you handled them. 

MARK_STORY: So RAPI has a lot of string bags, I guess is kind of the thing you're describing, like string keys and then string values. We also have some structured data where things are known to be numbers or...a classic one is the event kind of interface we have. It has a whole bunch of optional structured fields. So that could be, you know, exception. It could be a stack trace. It could be, it could have threads. Those threads have registers in them. And then all of that kind of data is quasi-structured. There's a lot of optionality in it, but there, it does have structure and it does have types. So for us, it was, it was pretty helpful to have all of that data kind of typed out. There is, of course, the weakest link is where you accept the API response and then cast it into, it is this shape. And at that point, TypeScript just trusts that you know what you're doing. So I would say that's one of the weak points is like, if you mess up that type definition between the API, between the server and the client, you're going to have a bad time. But if you get it right or like close to right, it can be, it can be pretty useful. Like you'll, you'll get down to like numbers, you get down to like object types and we do a lot of like object traversal because we have a lot of tested is like the event, the stack trace in your object is just this really deep nested object. 

DAN_SHAPPIR: Or you can try to do it in GraphQL. 

PRISCILA_OLIVEIRA: Yes, we really would love to introduce GraphQL, but it seems unrealistic for us at the moment. 

MARK_STORY: It's a big, big lift, like way bigger than getting to TypeScript was. 

DAN_SHAPPIR: So I guess if I'm understanding you correctly, what you kind of try to do, unless it's your JavaScript was maybe already shaped that way, is that you kind of try to push the parts where there are, let's call them kind of unstructured in terms of type definitions to the edges, and then like get them into organized structures as early as possible. And from that point on, everything is well organized and properly typed. 

PRISCILA_OLIVEIRA: Yes. 

MARK_STORY: Yeah, exactly. So a lot of the internal state will stay typed and is easy to type. And then, yeah, like you said start at the edges of the network boundary where the untyped data comes from and then cast it into types. And then from there in, it's mostly all typed. 

STEVE_EDWARDS: It's all turtles, turtles all the way down from there? 

MARK_STORY: Turtles all the way down. 

STEVE_EDWARDS: That's right, okay. 

DAN_SHAPPIR: Which brings me to my next question, which is how much of a re-architecting or rewriting was this? I mean, did you more or less just add types on type of the existing code structure? Or did this kind of force you into rethinking your architecture, like, like we just said about moving those parts that are less type consistent to the edges and which is potentially different than the original JavaScript architecture that you were using. 

MARK_STORY: I think we tried to focus on just the type annotations and like fixing the logic where we had potential type bugs. So I don't think we did a ton of like rewriting and rearchitecting, it was mostly just add the types, fix up any bugs that would have been caused by the TypeScript has revealed, and then go to the next component. 

PRISCILA_OLIVEIRA: Yeah. I took the opportunity to refactor many components during the conversion. 

DAN_SHAPPIR: Yeah, show me a developer who doesn't like a good refactor. 

MARK_STORY: Yeah, there's definitely some of it that happened. And I think it was also helpful to kind of expose a bunch of developers to products, parts of the product they hadn't worked in before. Then we were able to find like components that were the same. Like we did a conversion of a select list and we found another select list that was the same. We could just use the other one. So it was good for overall code hygiene as well. 

STEVE_EDWARDS: So I come from the, I live mostly in the view world as compared to React, which is obviously what you guys are using. Is React already built to interact pretty well with TypeScript? The reason I ask is that for instance, with Vue 2, it was pretty difficult. You really had to add an additional library that allowed for integration with TypeScript and so on, and just writing components looked ugly. I went just reading some of the examples. Now with Vue 3, Vue 3 Core was written in TypeScript and has, you know, is designed specifically to be much easier work, you use TypeScript. I haven't been able to do that too much yet, but hopefully we're going to do that soon. So my question is from a React standpoint, was that capability already existing in React to easily use TypeScript in your, in your components? 

PRISCILA_OLIVEIRA: Yes, React plays very well with TypeScript. It provides types and we didn't have any issue as far as I know. 

MARK_STORY: You just have to install that types library. There's a React types library. And so that type stubs gives you all the type information. 

AJ: So why not use Flow?

PRISCILA_OLIVEIRA: Good question. 

AJ: Why use Google Microsoft's tool for a Facebook problem? 

DAN_SHAPPIR: Isn't Flow kind of dead or dying or something? And I apologize to the Flow team if I'm completely off base here, but I think that TypeScript kind of won this war. 

MARK_STORY: That was our feeling as well. 

PRISCILA_OLIVEIRA: Yes, I have the same feeling. 

MARK_STORY: Maybe not that Flow is dead, but that TypeScript was getting a lot more momentum behind it. 

DAN_SHAPPIR: Yeah, that's my feeling as well. I'm familiar with a lot of TypeScript projects and TypeScript conversions, and I'm hard pressed to think of even a single Flow one. 

STEVE_EDWARDS: So much for going with the Flow, huh? So I have a question here regarding education in your blog post, and this is something I would be considering in really diving into TypeScript and learning it. It says you recognize that most of your team at Century would need additional resources and materials to learn it to get it to speed to be able to use it is you use the list of introductory articles and resources for configuring various editors. So it sounds to me as if there's quite a supply of readily available and free tutorials and courses on TypeScript out there that you don't need to like sign up for some paid course or something like that. 

MARK_STORY: Yeah, I would agree with that. 

STEVE_EDWARDS: Any chance you have a compiled list of all your resources that you publish or people want to put out? 

MARK_STORY: I don't have it on hand. 

STEVE_EDWARDS: What about off the top of your head? No, I'm kidding. 

MARK_STORY: No. 

STEVE_EDWARDS: But you just add a list that said, okay, here's a good list of resources. Walk through these and this will give you a good start to, uh, to learning TypeScript. 

MARK_STORY: Yep. And I think the thing we did was like help people get their editors set up. And that was a big win for people to see the value that they were getting out of that they could get out of TypeScript was being able to get the auto completion, being able to get like the compiler warnings in line. That was a, that was a really good piece of leverage to get people on board because.NWe never mandated that people had to write TypeScript. We just kind of gently showed everyone, here's all the good stuff you get with TypeScript, and here's how to write it. And then during code review, we would go back and help people who needed help, or they could drop into the front-end channel in Slack, and then ask for help that way, and we would do pairing sessions. 

STEVE_EDWARDS: So more the carrot than the stick approach, what it sounds like. 

MARK_STORY: Big time, yeah. 

STEVE_EDWARDS: So I'm gonna take a wild guess that everyone, one, did you standardize on one editor?

MARK_STORY: No. 

STEVE_EDWARDS: Okay. So people could use VS code or WebStorm or whatever they choose to use. 

AJ: Vim. 

STEVE_EDWARDS: We don't even talk about Vim or Emacs or any of that. 

AJ: Well, there's no reason to talk about Emacs. 

STEVE_EDWARDS: Oh, okay. Sorry. 

DAN_SHAPPIR: Notepad++. 

STEVE_EDWARDS: There you go. 

AJ: No, but seriously, do you have some good resources for getting the editor set up? Because I imagine VS code, it's like you click the button. Did you want to install TypeScript for this? Yeah. Okay. Right. Is there anything else you do? But what about the other, I mean, or... Do you have some resources like this is how to get rid of all the annoying things. Like it's terrible when auto-complete completes, when you meant to hit enter to end the line and then it's like, boom, complete. Stuff like that is just, ah. It's one of the reasons I don't use a lot of the auto-complete tools is they complete at exactly the wrong time, which happens a lot. 

STEVE_EDWARDS: So they're too complete of a tool. Is that it, what you're saying? 

AJ: Yeah. Well, and I used tab nine for a bit too and I found the same thing. It's like, yes. It saved me headache on some really repetitive tasks, but then it caused headache on non-repetitive tasks. 

DAN_SHAPPIR: And now we have the GitHub one. What's it called? 

PRISCILA_OLIVEIRA: Yes, GitHub Copilot. Exactly. I am having the exactly same issue at the moment. I add it all the time, suggest some wrong stuff and it's really annoying. 

DAN_SHAPPIR: It's like having an automatic paste out of Stack Overflow, isn't it? 

PRISCILA_OLIVEIRA: Yes, exactly.

MARK_STORY: Yeah, going back to your question around like editor setup, the VS code setup was fairly straightforward. We did some changes in the TypeScript config to work with people's editors to make that straightforward. And then for the, for the Vim users, we kind of just shared Vim configs. I'm one of the Vim users. So like I would just share my configuration with the other folks on the team. Like they're a Vim user. We all know each other. So 

AJ: could, could you put up a blog post or share that config, because what I find is that Vim, one of the reasons Vim is scary is because of the Vim elitist, because they're like, I'm gonna give you a plugin, but I'm not gonna turn any of the options on, but I am gonna give you a 30 page document that tells you about the options in the most excruciating and non-colloquial detail. And so at the end, it's like, oh, okay, all I needed was these three options, and then I could have been happy, and I could have told other people, and they could have been happy. But it ends up being that the...I don't want to call it elitism because I don't think the people are elitists. I think that they're just in their own bubble and it's weird, but I'm not one of those people in case you can't tell like I'm the stupidest VIM user you'll ever meet. And I love it. 

MARK_STORY: So I'm basically for my, for my VIM files. That's the VIM config I use. That's like my personal configuration. 

AJ: We'll put this in the show notes here. 

MARK_STORY: Yeah. The other folks on the, on the team, they all have their VIM configuration listed online. Like I can find links to those two if you, if you want to see what other century VIM users look like. But yeah we just kind of share things around. I would say the, like the magic one for getting all the TypeScript goodness out is the CoC plugin for, for Vim. Um, and that one does the, that one does the, the, a lot of the heavy lifting. 

AJ: The CoC, is that the Python library that does the autocomplete? 

MARK_STORY: So the CoC is the, it's an atrocious stack of technologies. It uses all the VS code plugins and it allows you to bridge into them through the LSP connection. So through the language server protocol, it talks to that. So Vim talks to the language server protocol that CoC runs and then CoC just uses all the VS Code plugins. 

AJ: Okay. 

DAN_SHAPPIR: I understood some of what you said and it sounded really atrocious. I think it works. 

AJ: This is how things generally work though. Every language has a language server and so it actually makes sense to put more of the plugins in the language server and less of the plugins in the editor because then you can have more specific tooling for the language and the editor can get more benefit with less mucking around.

MARK_STORY: I think it's also beneficial for like code sharing between VS code and Vim. So the people who are building language, like language support only have to program up to the language server protocol. Um, they don't have to worry about like how it integrates with them or VS code or PyStorm or all of those other things. 

AJ: I don't know. Maybe that's atrocious, but it doesn't sound that atrocious. Anyway, it's not the thing I was thinking it was. There's something where it's, it's like a big Python bundle. Anyway, I also included my, well, most of what my Vim config is there. If you want to check it out, but it will not hold a candle to anything you do because it's the most vanilla basic settings to just have stuff work without any trickery or magic or having to learn deeply. 

 

When I went freelance, I was still only a few years into my development career. My first contract was paid 60 bucks an hour due to feedback from my friends. I raised it to 120 bucks an hour on the next contract. And due to the podcast I was involved in and the screencasts I had made in the past, I started getting calls from people I'd never even heard of who wanted me to do development work for them because I had done that kind of work or talked about or demonstrated that kind of work in the videos and podcasts that I was making. Within a year, I was able to more than double my freelancing rates and I had more work than I could handle. If you're thinking about freelancing or have a profitable but not busy or fulfilling freelance practice, let me show you how to do it in my DevHeroes Accelerator. DevHeroes aren't just people who devs admire, they're also people who deliver for clients who know, like, and trust them. Let me help you double your income and fill your slowdowns. You can learn more at devheroesaccelerator.com. 

 

DAN_SHAPPIR: So with apologies to the multitude of Vim programmers out there and users, I'd like to pull us back to the process of your migration. Did, how did, you know, what was your process like? Like, I assume that one of the first things that you probably did was to get the type definition files for React itself and Mobix and all the libraries that you were using. And then from that point on, I assume you moved on to your own code. How did you go about it? It like, did you make essentially make everything any, and then gradually work your way down? Or did you like work on a specific file and just transform it to TypeScript? What was your process like? 

PRISCILA_OLIVEIRA: So we converted our files incrementally. And we had a strategy. First, we work it on education, towards education. Second, we had to stop adding JSX files. Otherwise the conversion will take longer and potentially would never finish. And third, the conversion. So in this phase, all the new work and features was already written in TypeScript. And we would only need to convert a certain number of files, so the rest of the files to TypeScript. But I would say that the education was the key here. 

DAN_SHAPPIR: So essentially, you kind of put a halt on adding new features and functionality for the duration of the conversion process? 

MARK_STORY: No, no, that's why it took us so long. 

DAN_SHAPPIR: But you just said that you were not adding new files into the project.

MARK_STORY: No, we weren't adding new JSX files. So once we got people kind of, there was a period where there was a mixed of like new files being written in TypeScript and new files written in JavaScript and for us to be able to like finish, we knew that we had to stop writing new JavaScript files because eventually we would just keep pushing, pushing the bar, the completion bar farther and farther away. So one of the first, like once we got the rough education in and had done some conversion and got people kind of mostly convinced was chasing people down and suggesting they rewrite the code they've written in TypeScript or just, you know, do another follow-up request where you convert this to TypeScript and we'll help you if you need help. And so, yeah, like Priscilla said, we did one file at a time. We didn't do the any approach that you mentioned because we felt that that was going to leave more work for us at the end. We'd rather just leave it in JavaScript and then we would know like what's done and what's not done. So we intentionally didn't go around and add any, anywhere unless we really had to.

DAN_SHAPPIR: So if I'm understanding correctly, what you're saying essentially is that you would take a particular JavaScript file and then I don't know, create a branch or something completely convert that file into TypeScript so that it was fully typed, strictly typed, and then put it back into the project as, as a whole. And not leaving any, any is hanging around.

MARK_STORY: I do we know any, no any stuff. 

PRISCILA_OLIVEIRA: Yes. Eventually we had to use any in a couple of places, but we were trying to do the right thing and the right correct types. 

DAN_SHAPPIR: Which brings me to another point. If you're writing your code to begin with in TypeScript, then you tend to use paradigms and approaches which work well with type specifications and type annotations but JavaScript in and of itself is notoriously dynamic with regard to the data structures that it uses. So if you're, and I've seen situations where people take a simple piece of JavaScript code and then have a really difficult time trying to come up with the appropriate type annotations for it. And that's kind of like the reason that TypeScript keeps getting new features in order to describe some of these. But like you can call them convoluted scenarios, but in JavaScript, they're actually totally reasonable. It's just that when you're trying to associate, uh, static types of them, that they become really difficult to describe. So how did you deal with these scenarios? Are these the cases where you just left it as any, or did you re-architect the implementation to be more type friendly? Let's call it or what was your general approach in such cases? Or maybe you didn't even encounter such cases. I don't know. 

MARK_STORY: I would say we did a bit of both, like both being re-engineering things so that they were easier to type. And then also we did, we have a few like very large unions where TypeScript has this nice feature where if you have a field that can decide with what the subtype is, you can kind of list that field and give it a fixed value and then give all the permutations of that, of that field. And then they have different subtypes. So if you have like a vehicle that has a type and maybe it's a motorcycle or a car or a monster truck, and those three vehicles all have different properties, you can type them based on like a discriminator field. And then we had a lot of that. So we have a lot of like really big unions that use a field to decide what kind of, what shape it is. But we didn't have a ton of highly dynamic code, like React lends itself very well to like an immutable data structure flow. So all your setup, all your state updates, all of the, like your props that come into your components are immutable. And then your state changes, you're supposed to copy objects versus like mutate them in place. So React lends itself well to be fully typed, which is nice. 

DAN_SHAPPIR: And was there like a certain point in time where you, so that you've told people from this point on, you're not allowed to write any new JavaScript files from this point on, you're just allowed to write TypeScript files? 

MARK_STORY: We never formally said that. 

PRISCILA_OLIVEIRA: We never said that. 

STEVE_EDWARDS: It was more of an implied threat. I mean, suggestion. Is that it? 

MARK_STORY: But everyone wanted to see it happen. 

PRISCILA_OLIVEIRA: Yes, it was a natural choice as they started seeing the benefits of TypeScript. Everybody loved using TypeScript. Yeah, still today. Until today.

DAN_SHAPPIR: And how long did this entire transition require? How long did it take place? 

MARK_STORY: 18 months. 

DAN_SHAPPIR: 18 months. Wow. What was again, the size of the project more or less? 

MARK_STORY: It's around a hundred thousand lines of code. 

STEVE_EDWARDS: Yeah. So you say 1100 plus files. 

MARK_STORY: Yeah. But we've never, so one of the other constraints we had given to us from VPs and stuff was we weren't allowed to stop delivering features. So we weren't allowed to stop project work. We weren't allowed to stop product work. We just had to keep going. And so this conversion process, one of the reasons it took so long is we didn't use any very often and then we also kept delivering new features the whole time through. 

DAN_SHAPPIR: Look, obviously, or let's put it this way, assuming, given that it seems that you're really happy with the results, to the extent that you're willing to talk about it, I assume that at the end of the day, the contribution to dev velocity was a very positive one. But undoubtedly during the transition process, there was a significant overhead. I mean, in addition to the development of new features, to fixing bugs and whatever, you also had this overhead of working and translating your code from, from JavaScript to TypeScript. How, how are you able to maintain that rate of releases and feature development? Or were you given some sort of a grace period from management saying, okay, you know, you need to continue delivering features but we accept for a certain period of time, I don't know, a 30% reduction in dev velocity or something like that. Was there this sort of an actual or maybe implied agreement? 

MARK_STORY: I don't think we ever had a specific number, but I think it was kind of an implied agreement that there would be some overhead and was up to the individual teams to kind of minimize that or like balance it with their product requirements. So I can speak for myself, like there were periods of time where I did a lot of TypeScript conversion because my product work was, you know, I was able to get it done fairly efficiently. And there were periods of time when I had a deadline coming up where I couldn't dedicate any time to doing TypeScript conversion. And the same was true for other folks on the team at Short Priscilla, similar. 

PRISCILA_OLIVEIRA: Yeah, the same for me. But in my case, I remember asking my manager if I could have the Friday just to convert files to TypeScript. So he agreed it. So Friday was my TypeScript conversion day. 

STEVE_EDWARDS: Yeah, that sounds like a nice way to do it just to have a set block of time says, okay, this is all I got to focus on where I don't have to try to balance feature work versus TypeScript work. Yeah, I like to sit down and focus. So just to clarify from an integration standpoint, so as you're going along, you basically sort of got two flows going, right? Here's your TypeScript conversion and you're adding new features at the same time. Now I assume...And you know what they say about assuming that as you're adding new features, you're using TypeScript. Is that correct? 

MARK_STORY: That was the goal. Initially that wasn't the case, but over time as the education kind of got through to all of the front end folks and all the occasional contributors, that's what happened. Yeah. 

STEVE_EDWARDS: So then as you're doing features and converting older stuff, existing code to TypeScript, are you merging those in together into your your master branch and deploying as compared to here's all my TypeScript conversion. Now let's dump it all in at once with the features. Yeah, that could have been ugly. 

MARK_STORY: It was, it was a very mixed state. So you would have data going between TypeScript and JavaScript files. One of the clunky things of that is when it goes, when data goes into a JavaScript file, it loses all its types. But because of the way you have to type everything and react, once it came back into the TypeScript land, it would get typed again. So there was definitely some like some awkward phases throughout that conversion process. 

AJ: So what happens in the compiled code? If you had something typed and then you end up getting the wrong type, is it just ignoring it? Cause it's compiled at that point and TypeScript is just for tooling or does it actually put a bunch of extra code in to try it to like basically upgrade and lots of try catches. And what does that end up being? 

MARK_STORY: So the TypeScript, the output of the TypeScript compiler is basic JavaScript. So it kind of strips all the type annotations out. So the compiler will check the existing type annotations and give you warnings if any of them have been violated. But the output of the TypeScript compiler is vanilla JavaScript, which then gets integrated with all the other JavaScript we have and then bundled and turned into things we deliver. 

AJ: So basically- 

DAN_SHAPPIR: In other words, no runtime type checking. All the type checking is done at compile time. 

AJ: Well, that's awesome. So basically you're enhancing your linter, but you're not complicating or slowing down the code that goes into the browser? 

MARK_STORY: Not any more than doing like exhaustive type checks requires you. So if you have like an object thing, it can be null, undefined, or one of many different types, and you wanna see if it's a number or do math with it, then you have to check like, is this actually a number before I do the math on it? Those kind of like type of checks, or if you do like a type guard expression in TypeScript, which allows you to kind of disambiguate a union. So say you have like a cat or a dog and you wanna turn it into a cat, you have to use what's called a type guard which allows you to say like, because it's got a very long tail, it's a cat. So that becomes runtime code and the compiler also can use it as a, as a type check. So some of your type guards and type checks will be left behind because they are runtime code, but all of the compiler and type annotations get stripped out. 

DAN_SHAPPIR: And I could also theoretically argue that in a certain, to a certain extent, it can actually make your code faster. Well, at the end of the day, obviously it's JavaScript. And so saying that the JavaScript is faster than some other JavaScript is always problematic, but the point is that you're more likely to write type consistent code. And type consistent code is easier for the JavaScript optimizer to actually optimize. So you're likely to end up with code that's easier for the JavaScript engine to optimize if you're working in TypeScript. So now that the project is effectively complete, are you happy? 

PRISCILA_OLIVEIRA: Yes, we are happy. 

DAN_SHAPPIR: Silence. 

STEVE_EDWARDS: Yeah, I can see Mark thinking about it. Am I really happy? 

PRISCILA_OLIVEIRA: I mean, we still need to replace all the any types and also we, I would like, we are now planning to convert also our, our tests to TypeScript and replace enzyme with Reactive Testing Library. So yes, we are happy, but there are still some stuff we'd like to do. 

DAN_SHAPPIR: Well, you have to find something to do on Fridays. 

PRISCILA_OLIVEIRA: Yes. 

MARK_STORY: Yeah. I guess, like for me, am I happy with TypeScript? Yeah, it's, it's worked really well. It's helped catch a lot of bugs. I find the editor integration really helpful. So I've, I think I've realized the value of TypeScript from the conversion work and I'm happy we did it, but yeah, we still have a lot to do. Like the work's not done. 

DAN_SHAPPIR: So what, for example, aside from the converting the tests to TypeScript as well. What else do you think needs to be done? 

MARK_STORY: So we talked very much earlier about the multiple state management libraries. I would like to get that fixed. So maybe we don't have to say that we have three. That would be nice to pair that down. 

PRISCILA_OLIVEIRA: That would be nice. 

DAN_SHAPPIR: So basically you're saying now that we're TypeSafe and I feel much more secure about the structure of my application, now I can try to maybe change the architecture a bit to make it better. 

MARK_STORY: Yeah, we also kind of like an internal moratorium on refactoring, like large scale refactorings while we were doing the TypeScript conversion, because we didn't want to have like multiple in-flight projects and then never finish any of them. 

STEVE_EDWARDS: He's take away all the developers fund. What's up with that? 

MARK_STORY: Yeah. Well, we need to get one thing finished. So like now there are people who are converting class-based components to function-based components and using hooks a lot more. So that's another opportunity for Cleanup and simplification. So yeah, that kind of work is happening now. 

DAN_SHAPPIR: I've seen projects where the transition to TypeScript was actually done as a part of a rewrite where effectively the, you know, for some reason, the application needed to be rewritten or re-architected. And then they basically said, okay, if you're going to be rewriting it or re-architecting it, we might as well do it in TypeScript. But your approach was the incremental one. Which do you think is more conductive for success? 

MARK_STORY: I've done a big rewrite before and they are very hard. Like really, really hard. Because you have so much product already built, right? And then you're just rebuilding it and customers still want new things to come out and they still need bugs fixed. So you're going to be maintaining two systems for a really long time. Yeah, I don't like big rewrites. I've done a couple of them and I don't like them. 

DAN_SHAPPIR: You don't like fun.

MARK_STORY: It's not so I 

DAN_SHAPPIR: no no I'm kidding. I don't know what you're saying we love rewrites and with the false assumption that we can throw the old stuff away which always ends up to be much more difficult than we anticipated 

MARK_STORY: I think a lot of times people think that they can the reason the code is ugly is before like hard to maintain is because of bad technical decisions. And a lot of times, the product is just inconsistent and strange. And all of those weird warts in the code are actually features and bug fixes that have accumulated over time. And so when you go down that rewrite, you try and peel off all that scar tissue, your very clean thing doesn't work. And it doesn't have all this... It's not bug compatible. It doesn't have all the specific behaviors that it used to have. So all those warts slowly migrate their way back in. You end up in a sin place.

DAN_SHAPPIR: Yeah, the essential complexity versus the accidental complexity for those of us who are familiar with the No Silver Bullet. Yeah, you find that you need to migrate all the essential complexity and often there's quite a bit of it. Any final tips and suggestions to anybody who's considering a similar project? 

MARK_STORY: I would suggest doing an incremental approach, figure out how to straddle both the TypeScript and JavaScript worlds, and then do it piece by piece. There are better tools now as well. Like there are some tools that can read JS doc comments and turn them into types. So if you were in a position where you can leverage those tools, like try them out. They weren't around when we started. 

DAN_SHAPPIR: We actually had a few episodes back. We actually had a Guilte Jarre talking about the possibility of using JS doc effectively, even as a bit of a replacement for TypeScript by specifying type information inside JS doc comments. Motivation being primarily for backend code to avoid the need for a build step or a compilation step. For front-end code, you kind of need it anyway for the bundling stuff and then things like that. But for the backend stuff where you know that you're just targeting a specific version of note, for example, and you don't need bundling, then forgoing the need for a compilation step can be really attractive. So that's worth mentioning. How about you, Priscila? Do you have any final comments and suggestions for anybody who is considering implementing a similar type of a project? 

PRISCILA_OLIVEIRA: So I would also go for the incremental approach. I think it's more, it takes longer, but it's worth it. Because in the end, you have better types in your application. And yeah. 

DAN_SHAPPIR: Cool. Okay, so anybody have any final questions or thoughts or suggestions before I push us to PIX? Okay then, let's go with PIX. 

 

Hey folks, if you love this podcast and would like to support the show, or if you wish you could listen without the sponsorship messages, then you're in luck. We're setting up new premium podcast feeds where you can get all of the episodes released after Christmas 2020 without the ads. Signing up will help us pay for editing and production. And you can go sign up at devchat.tv slash premium. 

 

DAN_SHAPPIR: Amy, would you like to start with pics? 

AIMEE_KNIGHT: I would try to think off the top of my head. So a while back, an old coworker bought me the book inner engineering. And I hadn't really like picked it up, but I found the audio book and started listening to that last night and it was really good. So that is going to be my pick. 

DAN_SHAPPIR: Cool. How about you, AJ? 

AJ: Give me just a second here to get the old VS code picks page warmed up and ready. So the first thing that I'm gonna pick is the design pattern of await catch, because what I see in most code is try await, and try await results in code that reads from left to right to top. And ideally we want code that reads from top to bottom with very little left to right, and certainly not bottom to top, meaning a code block should not require you to read back upwards to then read downwards, which is what try a weight ends up doing. But if you use a weight catch, meaning that you understand the promise aspect, which is all of what async await is built on, then you can write code that is very slim and digestible, easy to read, easy to reason about, and less likely to result in errors. post, it's currently a gist and I'll link to the gist, but I'll probably update it to be a, an actual blog post showing the differences between the try a weight approach and the await catch approach. And I just hope that people who are writing JavaScript will take a look at that so that they have code that is easier for themselves and others to reason about above and beyond that. Let's see. I actually didn't come up with other picks this week. So I will just say if you're interested in following my video code tips, you can do so on Beyond Code, which I'm giving the links to Facebook, YouTube, and Twitter. And if you follow the YouTube channel, there's actually two channels, one where I just do live streams and the other one where I do edited, which gets posted to less often, but I'm wanting to ultimately ramp up. And that will be my picks for today.

DAN_SHAPPIR: How about you, Steve? 

STEVE_EDWARDS: Sorry. I wasn't ready. I'm not used to AJ's picks taking less than 10 minutes, but I think I can jump in here. So first pick, I actually have a pick and then I'll get to the high point of the show, which are my dad jokes as always. This is a podcast episode and it's actually from a couple of DevChat alums, the web rush podcast with John Papa and Morville and down while lean. And I was listening to this driving home from vacation the other day and it's episode 142. It's an episode with a guy named David Neal. And he goes by the name Reverend Geek. And it's all about how he uses art for illustrating his presentations, his slides and stuff like that. And he talks about how he started out basically being able to draw stick figures and that was about it. And that explains, that illustrates the current extent of my artistic capabilities as well. But as he went and practiced and got a lot better, he started being able to draw better and better as anybody would. But he really talks about the feedback that he got from people on how just having a little bit of art really made his presentations. He was doing a lot of traveling around and making presentations at conferences. And the feedback that he got was just phenomenal, how much it really caused the audience to be more engaged in what he was doing. And so it was just really fascinating podcast to listen to. But one of the things that really piqued my attention was that at his Twitter feed, he does a dad joke a day. And I was like, All right, I really like this guy. So I tweeted him. And now I will say this, that the drawing on his dad joke a day on his Twitter feed is are really good. The jokes are a little lame. They're not quite up to my standards of excellence but I'll give him an A plus for effort for sure. And he says- 

DAN_SHAPPIR: Nobody can match your standards of excellence. 

STEVE_EDWARDS: I know, I know. It's hard to sink that low. And so he, but anyway, he puts up one a day. He's done like 200, I think he said in a recent tweet. So anyway, the episode is 142 of Web Rush and I'll put the link into the show notes so you can go listen to it. But it's really a fun episode to listen to. And then from my own dad jokes of the day that I wrote myself, of course, being left-handed this one, particularly was appropriate for me. It says, why should you never brush your teeth with your left hand regardless of what hand you are? Because a toothbrush works better. And then the second joke, 

AJ: wait, I didn't get that one. I didn't get that one. I brush my teeth with my left hand.I use a toothbrush. I don't use my left hand because it doesn't quite get the teeth clean. 

STEVE_EDWARDS: Okay. Thank you. Usually people just sit there and groan or stay on mute. So I appreciate that. 

AJ: No, that one was good. That one was good. It's just I think you got to work on the delivery just a touch. 

STEVE_EDWARDS: Oh, I'm going for the Stephen Wright dry humor approach, but I'll work on that. 

AJ: I think there's something off with the pausing or phrasing or maybe it's your accent, but just you can reach it, Steve. I've got that in you. 

STEVE_EDWARDS: I know. Like I said, I'm working on it. I'm not at a professional level yet, but I'm working to get there. And then the other day I had a pet lizard and I took him back to the pet store because he wouldn't stop telling dad jokes. And the court, well, that's not a lizard. That's a standup chameleon. So that would explain why he wouldn't stop telling bad jokes. 

DAN_SHAPPIR: The good thing I am you did so that I can grow. 

STEVE_EDWARDS: Yes. Thank you. Well, the grown, the groans add ambience to the telling of the, of the story. So I appreciate that Dan. Anyway, those are my picks and jokes for the day. 

AJ: Can I add one thing since I didn't take enough time before Steve? 

DAN_SHAPPIR: Oh, for sure. Go for it. 

AJ: One of the most underrated repos on GitHub sitting at 21 stars presently is Markdown Slides. This is amazing. I don't know how not everyone knows about this. 

STEVE_EDWARDS: I think I do, that sounds familiar. 

AJ: But this lets you write a presentation in a Markdown file and it has nice transitions and everything. Like all the nice features are turned on by default, which most, like all the ones that have 20,000 stars don't have this stuff. So you write it in Markdown and then it does a little bit of magic to transpile it to HTML with some of the special tags for Reveal JS and gives you a real Reveal JS folder. So I'm going to link to that and you can see right in the readme just how cool it is. It even lets you do code highlighting line by line. So if you want to if you want to have it go from lines one through three or lit up and then lines four and five or lit up, it lets you do that. So this is just amazing. Anybody who's doing a presentation at least check it out. It's super easy to use. And I just, if there's something else out there that I'm missing that's better than this, my search results weren't turning it up. So please, by all means, educate me. 

DAN_SHAPPIR: So the benefits of using that over, let's say Google slides is the ability to embed code and stuff like that. 

AJ: Oh, you can embed everything. Like you have got full control over it because you can even put down in HTML if you want. So you just write your slides and mark down. You know, it's just really simple. You want a bulleted list, it's just a mark down bulleted list. Like, so it's, It's ridiculously simple. If you are somebody who is a coder and you don't know Markdown, well, there's your first problem. And if you think Google slides is better than maybe it is for whatever your presentation style is. But I mean, I just, I just can't imagine Google slides being this easy. I don't do fancy stuff and then you don't have to do fancy stuff with this. The fancy stuff is just automatic. Like you just tell it what background color or image you want. 

DAN_SHAPPIR: No, it's, it's mostly the question of, uh, do you. You know, if most of your slides are laid out the same and they should be, then, uh, just providing the content is usually what you want. And like you said, the markdown really makes it really easy and straightforward to provide the content and the basic styling that you need for the content. Like this is code, this is a bulleted list, et cetera. Google slides is more about I want to drag and drop it around. I will want to move my text block like five pixels to the right or something like that. 

AJ: Yeah, I probably wouldn't do that for this. I'd say this is suited for slides where you have code. It's it. I wouldn't necessarily suggest it for a business presentation, although since it's HTML and markdown and LaTex, you could, of course, do whatever you want with it. But yeah, I would say it's it's suited for for code presentations and why would I use it above Google Slides for anything, even if it's not a code presentation? Because when I hit the right arrow, the slide goes to the right rather than being a flash on the page, it's a smooth transition. And I think that right there is just one of those things where having that on by default just makes sense. Anyway, I didn't mean to take 10 minutes on just this, but it's awesome. 

DAN_SHAPPIR: It's definitely sounds like something that's worth looking at, and that's the whole point of picks. So I actually, even though I threatened everybody at the beginning of, you know, before we started recording that they have absolutely no picks, happily during your picks, I remembered too, that I would like to mention. So Steve kind of also inspired me to pick a podcast. And the one that I'm going to pick is called The Fall of Civilizations by Paul Cooper. I'm something of a history buff and this is a really interesting one. It talks in detail about the collapse of ancient civilizations So he has an episode about the Assyrians. He has an episode about the Han Chinese Etc. It's you know being like I said being a history buff. This is really interesting and you always kind of have this nagging fear that maybe we are also living in a falling civilization and we didn't actually notice it. You know, the Roman civilization took several hundreds of years to actually complete its fall. So it could be that we're slowly falling and we're not even aware of it, which is kind of disconcerting. It's a really excellent podcast. The production value is amazing. The episodes are long. They can, you know, they are up to three hours, sometimes even more, but you can listen to it in segments. He has voice actors on there and like in the one on the Chinese, the Han Chinese, he actually brought Chinese speakers to read out various Chinese, bits of Chinese poetry. I found it to be really, really interesting and I highly, and I really recommend it. It's a, I think it's a great podcast. And the other thing that I found interesting that's currently going on is this whole thing about, I don't know if you heard about it, about this company. It's actually an Israeli company called NSO and the Pegasus project, or basically it's spyware. They sell software that makes it possible for you to hack into people's smartphones, be it an iPhone or an Android, and then spy on them get their contacts, get their calls, get their texts, whatever. And it turns out that various governments have been using, using this to spy on, you know, journalists, their opposition, etc. Which, you know, if you come to think about it, it's really not surprising. And, and, and I find it kind of amusing that people are really shocked about it. And it kind of reminded me of this episode on this old sitcom, which is excellent and highly recommended. It's a British sitcom called Yes Minister, where they talk about arms sales, about how British arms, it takes place in the British government. So how British arms find their way into the hands of Italian terrorists. And the minister there expresses shock and dismay that something like that could happen. And his secretary basically tells them, well, look, you know, when you sell arms, then people who have money will probably get them. And so it's totally not surprising that when you're selling software on the market for government that can enable governments to spy on people, that governments will actually use the software to spy on people. So, so yeah, so it's It's interesting to see the shock and dismay of something that's wholly expected. 

AJ: But the problem there is that whichever side of the aisle you're on, the other side of the aisle is going to say it's a conspiracy theory, especially because some of the stuff is so outlandish and so on. The truth is more difficult to believe than fiction. 

DAN_SHAPPIR: Well, I don't know if it, you know, the reality is that almost any government would be able to justify spying on somebody. That guy's a terrorist. We need to spy on them. And then the lines get blurry. And for some governments, the definition of who's a good guy and who's the bad guy doesn't necessarily match yours. And let's put it this way, I wouldn't work at this sort of a company, but I'm kind of surprised over the shock and dismay that a lot of people are expressing. Let's put it this way. Anyway that would be my second pick. And now moving on to our guests. Priscilla, do you have any picks for us? 

PRISCILA_OLIVEIRA: Yes, I'd like to recommend a very nice library called DNDKit. Recently, we had to introduce DragonDrop in two places in our application at Sentry. And this library is amazing. It's very light. It's very easy to use, to customize, and they have an amazing documentation.

DAN_SHAPPIR: Cool, that sounds really interesting. How about you, Mark? Do you have record? 

MARK_STORY: Yeah, I got two quick things. One is a book by Edward Tuft. I don't know if I'm saying his last name right, but it's called Beautiful Evidence. It's a book I bought. I haven't read it yet, but I read his other books on, they're all on designing data visualizations and he's fantastic. And then the other one is the code completion for Vim. Yeah, so I'll share that. Cause that's, I guess if you're a Vim user and want to have code completion like the ES code folks have. This is a good way to do it. 

DAN_SHAPPIR: Cool. Maybe AJ will start using code completion again. 

AJ: But you just got to tell me how do I make it so that it only code completes when I hit a button that I wouldn't normally hit like tab or enter. 

MARK_STORY: There is a way to do that. You just have to keep finding. 

DAN_SHAPPIR: Anyway, if anybody wants to get in touch with you guys, either to talk about TypeScript or Sentry or whatever, what would be the best way to go about it?

PRISCILA_OLIVEIRA: Oh, anyone can contact me on Twitter anytime. 

DAN_SHAPPIR: What's your handle? 

PRISCILA_OLIVEIRA: So my Twitter it's a brasilowebdev. 

DAN_SHAPPIR: Cool. 

PRISCILA_OLIVEIRA: I can write it here. We can post. 

DAN_SHAPPIR: No, we will put it in the show notes. So please just type it in, but think most of our listeners will be able to figure it out. How about you, Mark? What would be the best way to contact you? 

MARK_STORY: Twitter's a good way. And I'm Mark underscore story on Twitter. 

DAN_SHAPPIR: Cool. So thank you guys for coming on our show. I think this was really interesting and also very informative. I think that there are a lot of companies out there that are either thinking about a transition to TypeScript or actually started that transition to TypeScript. Maybe they've tried and failed and maybe thinking about it again. So I think that any information about how to do it successfully, which apparently you have, is really cool and useful. So thank you for coming on the show and sharing it with us. 

PRISCILA_OLIVEIRA: Thanks for having us.

DAN_SHAPPIR: Okay then, in that case, thank you to all our listeners and that's the wrap. 

STEVE_EDWARDS: Adios. 

PRISCILA_OLIVEIRA: Bye. 

AJ: Adios. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit c-a-c-h-e-f-l-y.com to learn more.