STEVE_EDWARDS: Hello from a very rainy Portland.
CHARLES MAX_WOOD: Dan Shapir.
DAN_SHAPPIR: Hi from a warm and sunny Tel Aviv where it's in the high seventies all the time.
STEVE_EDWARDS: Oh, I'm so jealous.
CHARLES MAX_WOOD: AJ O'Neill.
AJ_O’NEAL: Yo, yo, yo. Coming at you live from sad. That's seasonal affective disorder by the way.
CHARLES MAX_WOOD: Oh yeah. It's cold here. I'm Charles Max Wood from Top End Devs. And yeah, Dan, you scheduled this. I guess you got tired of us complaining about React.
DAN_SHAPPIR: Yeah, exactly. I kept hearing you guys talking about how React is kind of weird and strange and not understandable and really complicated and how you guys miss the browser DOM. And I thought that maybe it has to do with the fact that we're not doing it in the same with a certain lack of understanding of some of React's core principles. And in particular, how the core philosophy of React, you might say, and how it's enabled by virtual DOM, which is obviously different from the real DOM because it's virtual. So yeah, that's what I wanna talk about today.
Hey folks, this is Charles Max Wood from Top End Devs. And lately I've been working on actually building out Top End Devs. If you're interested, you can go to topendevs.com slash podcast a little bit more about my story about why I'm doing what I'm doing with Top End Devs, why I changed it from DevChat.TV to Top End Devs. But what I really want to get into is that I have decided that I'm going to build the platform that I always wished I had with DevChat.TV and I renamed it to Top End Devs because I want to give you the resources that are going to help you to build the career that you want. So whether you want to be an influencer in tech, whether you want to go and just max to go live a lifestyle with your family, your friends, or just traveling the world or whatever, I wanna give you the resources that are gonna help you do that. We're gonna have career and leadership resources in there, and we're gonna be giving you content on a regular basis to help you level up and max out your career. So go check it out at topendevs.com. If you sign up before my birthday, that's December 14th, if you sign up before my birthday, you can get 50% off the lifetime of your subscription. Once again, that's topendevs.com.
CHARLES MAX_WOOD: I just think that the front end frameworks are mostly overkill, but.
DAN_SHAPPIR: Oh yeah. For a lot of use cases that definitely are. I mean, if you're building a mostly static website, then all you really need is just HTML and CSS and have at it. But if you're building something that's more applicative, an actual web app, let's say, something that needs to be a single page application, which is a whole discussion in and of itself, I guess.
STEVE_EDWARDS: Yes, it is.
DAN_SHAPPIR: Then something like a, then a framework is really often the way to go because it just does a whole lot of heavy lifting for you.
AJ_O’NEAL: I do agree that if you don't use one, you'll build one yourself. And I do agree that most people don't document their code. So you'll be left with something that's worse than any alternative.
DAN_SHAPPIR: Oh yeah, for sure.
CHARLES MAX_WOOD: My take on it is mostly that if you're building like an interactive experience, then yeah, the frameworks make a lot of sense. If you're building an interface that's relatively simple, that yeah, is mostly static.
AJ_O’NEAL: A contact form, a static web page with marketing material and a contact form.
CHARLES MAX_WOOD: Right. For sure.
CHARLES MAX_WOOD: anyway. But I'm, I'm, I am curious because, you know, I mean, I've talked to plenty of people about React. I've built some React native apps. There are definitely some things that I like about React. It's just that, yeah, when I'm reaching for, hey, I've got to build this out, typically I'm not building the kind of experience where I really need the kind of interactivity that React, Angular, and Vue tend to, I think, would push me to use one of those. But Dan, let's dive into this, because I really do want to talk about, okay, what is the React philosophy? I mean, what are we talking about here with how React works, how React thinks about the web and things like that, because a lot of people are using it. A lot of people like it. And though I disagree that they need to use it in every instance that they use it, there are reasons that people are using it. And so I think that's the value of diving into this. And I think there might be some pushback as far as, hey, that makes sense, but then it doesn't add up to using it here. But I think in other cases, it's going to also be I hadn't thought of that before, so maybe I would reach for it in this instance where I wouldn't have before. And so I'm kind of curious just to have the conversation and see where we wind up, right? Because I'm betting that, yeah, you're going to dive into some stuff that I wasn't aware of. I hope so.
AJ_O’NEAL: So with the, with the virtual DOM, my understanding is might be totally off base, but basically virtual DOM is a legacy of back from the jQuery days when the DOM wasn't efficient and we didn't have methods like insert adjacent HTML that were extremely performant and we didn't have request animation frame and we didn't have all of the performance tools baked into the DOM that now exist.
DAN_SHAPPIR: Well, I, that's not exactly the case in my opinion, at least. From my perspective, there are a couple of problems with direct DOM manipulation, and performance, past or present, is only one of them. So other issues with direct DOM manipulation, historically it has been browser compatibility. That one can be said to be effectively solved, especially now that everybody's dropping IE support. For example, I just learned that Lego announced that they're no longer supporting IE. Wix, by the way, treats...
AJ_O’NEAL: Lego, as in...
DAN_SHAPPIR: Yeah, the toy that you buy, Lego, they have a website, apparently a really cool one, and they used to support IE, and now they don't anymore. So hooray for them.
AJ_O’NEAL: I'm glad that they realized that people that work at banks and government facilities aren't their target customer.
STEVE_EDWARDS: When you said that Dan, I thought for a minute they weren't shipping it as part of their Lego toys the little computers
DAN_SHAPPIR: Yeah, and by the way wicks also we also treat Legos a legacy browser so if it kind of happens to work and great, but we actually put in a notification that we don't officially support it anymore
AJ_O’NEAL: Wait, Lego.
CHARLES MAX_WOOD: I think you just yeah, you just misspoke and said we don't support Oh, legacy browser, which is hilarious, but we all know what you meant.
DAN_SHAPPIR: Yeah. Yeah, I met I but historically, one reason for frameworks has been browser compatibility. And like I said, that one is gone. So what's left?
CHARLES MAX_WOOD: Well, that was initially the issue that jQuery was built to solve.
DAN_SHAPPIR: Oh yeah, for sure.
CHARLES MAX_WOOD: It was, well, we don't know if we call this, if it even exists, right? Cause Microsoft made their own APIs and then we're just going to wang it out there and hope that it works. And so jQuery made it consistent, which was so helpful.
CHARLES MAX_WOOD: Got you. Everyone but Steve will have this problem. Steve's code is perfect, but the rest of us.
DAN_SHAPPIR: Yeah, exactly. Also, the DOM tends to be complex. It's highly imperative. You end up with really verbose code to do some things that seem to be really simple. You create a DOM element and then you need to set the properties one by one and then append it.
AJ_O’NEAL: False information. Fake news. Fake news. You do not need to do that. That is how it's commonly done. But you do not need to do that because you can just construct a string and use insert adjacent. What is it? Insert adjacent HTML, insert adjacent element HTML. I forget what it is.
DAN_SHAPPIR: Yeah, I'll get to that in a bit. But yeah, that's, you know, kind of quote unquote cheating in that effectively you're treating an HTML string as a piece of code. It's a legitimate thing to do, but it also has its own risks and downsides.
AJ_O’NEAL: Wait, have you ever heard of React? I just want to point out the hypocrisy while we're here.
DAN_SHAPPIR: Okay. We'll get there. And another issue that I wanted to mention about direct DOM manipulation is that it's, it's really problematic to test, or at least it can be because you usually end up doing a whole lot of mocking in order to simulate the DOM so that you can modify that simulated DOM in order to, to test your code. And mocking is just not a lot of fun.
AJ_O’NEAL: Do you find, cause I just assume that the only way to test front end code in any...any way that brings real value is to use something like cyclists. I had, I had never considered that it would be desirable to try to test. Well, I mean, I, I don't really use react, but I'd never considered it to be desirable to try to test DOM manipulations without testing how the browser actually behaves because, well, because it's so likely to do something you didn't expect.
DAN_SHAPPIR: Well, again, if you do, if you properly break down your code into components and certain components are really small and you can actually implement it is something like pure functions that receive a state value and emit HTML in a way that you can check that HTML that the function provides as a return value, then why isn't that testable?
AJ_O’NEAL: Because as soon as you put that on the page, there's some other component that overlaps with it by a padding of 30 pixels and you can't click the X button or get rid of the ad or even subscribe to the news.
CHARLES MAX_WOOD: I still like that way of doing things, to be honest.
DAN_SHAPPIR: Well, that way is great. It's great when it works, but there are obviously some problems with it. I mean, if your network isn't great, or sometimes even if it's pretty good, it still can be relatively slow because of the network round trip. For some interactions, it's not a problem, but for other interactions, having that network round trip, you want to create some sort of interactive form that does things whenever you click or type something, for example, something like the Google smart search box. You won't do that by reloading the page on every button press. It just doesn't make sense. And another big issue with this approach is that you lose local state whenever you reload the entire page. So even if you load the page that looks exactly like the page that you left, all the forms would be cleared. You lose whatever state you had locally within the page when the new page loads. So there are reasons why in some cases an SPA is better than an MPA, at least in portions of the web application.
CHARLES MAX_WOOD: Did you just say MPA?
DAN_SHAPPIR: Multi-page application.
CHARLES MAX_WOOD: I know. I just thought it was funny. I've never heard it before.
DAN_SHAPPIR: Oh, yeah?
CHARLES MAX_WOOD: Well, I've never heard the term before. Yeah.
AJ_O’NEAL: I'm not sure about this but I would assume that if you do the operation in a request animation frame, you would get some benefit because then the browser knows that you don't expect it to cut its other processes to try to repaint. Cause the reason that doing the manipulations has traditionally been so bad, my understanding is that because the browser, every time you manipulate a node, the browser will repaint. Whereas if you use the string, the browser doesn't repaint until it's completed the entire node all on its own.
DAN_SHAPPIR: No, that's not correct.
Hi, this is Charles Max Wood from Top End Devs. Lately, I've been coaching some people on starting some podcasts, and in some cases, just taking their career to the next level. Whether you're beginner going to intermediate, intermediate going to advanced, whether you're trying to get noticed in the community or go freelance, I've been helping these folks figure out how to get in front of people, how to build relationships, and how to build their careers and max out and just go to the next level. So if you're interested in talking to me and having me help you go to the next level, go to topendevs.com slash coaching. I will give you a one hour free session where we can figure out what you're trying to do, where you're trying to go, and figure out what the next steps are. And then from there, we can figure out how to get you to the place you wanna go. So once again, that's topendevs.com slash coaching.
AJ_O’NEAL: I'm sold on the basic idea of the virtual DOM, more or less. I...I think a lot of times when people have complained about, okay, so with AG Grid, for example, they do weird stuff that cannot be accomplished with direct DOM manipulation. We had them on the show, they talked about it, that makes sense. It seems to me that, and this is kind of, this is definitely a tangent from the main conversation, but just the argument about the virtual DOM. I get it, but I also question if the need for the virtual DOM...doesn't suggest that something else in your process has gone really wrong. So for example, in Angular, if you wanted to fill a list dynamically with, say, as you type, you want an autocomplete to fill. The reason that this was ridiculously slow in Angular was that it would regenerate the entire list on every single keystroke, right? And in the naive implementations. And so if you just used a little bit of smarts to make sure that you were generating your list and then filtering it down, then you would get the advantages that you need and it wouldn't be ridiculously slow necessarily. And when I think about most web applications, typically you're just dropping in a component, something new. You're adding a pop-up. You're making one or two small changes to the page. You're not making hundreds or thousands of pages or changes unless you're doing something like a like a virtual Table and virtual scrolling and all of that in which case but again,
DAN_SHAPPIR: But again AJ you're looking at it from the perspective of performance And the perspective that i'm trying to take to is to take you to is a perspective of updating The ui as through pure functions State in dom out and think about it this way when you're working with Angular, one of the complaints about Angular back in the day was that something changed and it was really difficult to determine what actually in your code actually changed it. What was the cause of that change? And because things could be changed from all over and the state itself of the UI was mutable, you kept you taking the state and if you made a wrong decision somewhere along the way, then you would end up with an incorrect UI state and it's like ten steps down the line it would be really difficult to determine how you got there. Whereas with React you just take the current state generate the fresh UI as if you're like I said as if you're you went to the server and got the whole page back. You don't have to think or worry about what the previous page looked like. The only thing that React does with this virtual DOM is that it tries to make this actually doable by reducing the cost of replacing the previous DOM, updating the browser DOM from the previous situation to the new one. So you don't look at it as mutable. You just look at it as state in, DOM out, and React converts that into a series of mutations and because it's React and created by really great developers, you can assume that they wrote the code correctly. Okay, so that's the basic idea.
AJ_O’NEAL: I get that. I get that. So let me repeat what I think I'm understanding. So let's say that we have some terrible add widget on the page and it has a bad selector and it goes and edits something that it shouldn't edit. With React, once the user clicks a button again, it's going to re-render from its object of what the state is what the state should be. And so the fact that you had an ad widget or an analytics widget or whatever that screwed up your page in some way that you didn't expect and would be a nightmare to debug, that bug is only gonna persist for a short time and then it's gonna-
DAN_SHAPPIR: Again, actually not exactly true. Okay, not really. Like I said, yeah, because again, like I said, if you actually modify the browser DOM behind React's back, React is not aware of it. React just writes to the DOM. It doesn't read from the DOM, from the browser DOM. Unless you... So if you have a widget that went behind React's back and actually modified a part of the browser DOM that it shouldn't touch, that page could persist unless React happens to write to that same place as well.
AJ_O’NEAL: Well, that's what I'm saying, is that React is gonna rewrite that thing because you're gonna do something on the page and it's gonna rewrite the form or it's gonna rewrite the list or...So if something is buggy, it's less, if something outside of the React is acting on the page, outside of the code flow that you understand is acting on the page, then that is going to be less of a problem.
DAN_SHAPPIR: I prefer to think about it slightly differently. Think about the fact that your UI can be in a whole bunch of states and in the angular type of an approach or direct dom manipulation you can get from any state to any state directly. You just supposedly mutate your state to get from state A to state B. And then you mutate your state to get from state B to state C and so forth. And if you made any mistake along the way, then instead of going from A to B, you get to B prime, which is almost like B, but not exactly. And then when you move from B to C, because you're not from B, you're from B prime, you get to a state that's not exactly C either. And the errors kind of accumulate and pretty soon you're, you're seeing something really weird on the screen and it's really difficult to figure out that you got there. With React, whenever you, you, you don't go from A to B, you always get back to that virgin state and because you're giving, you're taking your existing current state and generating the entire VDOM from it, you know, at least in the naive approach. So you're always starting from fresh, as it were. Like I said, think about it sort of like what they were looking at is how the browsers used to work when they would hit the server and get back the HTML. Whatever you screwed up in the previous page, that was gone. And again, I'm not looking at some third party component that you don't have any control over. I'm talking about your own code.
AJ_O’NEAL: But wait if I wrote buggy code wouldn't it still be buggy though?
DAN_SHAPPIR: Yeah, but again, it's much easier to think about going from fresh to state instead of having to Think about and and measure and monitor all the possible states that might exist in your application It's you know every state transition that you implement is something that you potentially need to think about to test To to make sure that it works correctly if you have like 10 possible states and you can get from any state to any state, those are what? 10 to the power of 10, those are a hundred different types of transitions that you need to to figure out to implement.
AJ_O’NEAL: I think you made a quadrillion.
DAN_SHAPPIR: Well, well no, it's not 10 to the power of 10, it's 10 times 10 because you can get from any everyone to anyone, you're correct. But on the other hand with the React approach, there are only 10 possible transitions. You always go from the fresh state to one of those target states. So it would be 10 transitions. Now, obviously in a real application, there are not 10 possible states. There are, I don't know, 10,000 possible states. Now, obviously you can't get from every state to every state, so it's not 10,000 times 10,000, it's just 10,000 times, I don't know, times 100. So it's a million different state transitions that you would need to validate. Whereas with React, it's just those 10,000, because you always start from fresh. That's the key. So don't think about it from the perspective of performance. Because look, at the end of the day, anything that you can do with React, or with any framework for that matter, you can just do with the plain old DOM. Because at the end of the day, all these frameworks are just built on top of the DOM. So DOM manipulation can be done as efficiently, if not more efficiently than any framework. It's just the frameworks make it easier for you to potentially write you know, correct code.
AJ_O’NEAL: OK, so essentially it gives you a sandbox to operate in and the constraints define the art. Therefore, if you have certain constraints that you operated within, you only have a certain way that you can write the code and you limit yourself to ways of writing the code that are more functional and therefore easier to test and debug.
DAN_SHAPPIR: And to also reason about.
AJ_O’NEAL: Well, so this is where I have a hard.
DAN_SHAPPIR: State in HTMLO. I would argue that function that pure functional code is always easier to think about and understand then code that is based on mutating a global object a shared global object
AJ_O’NEAL: So if you're pitting against the extreme then yes
DAN_SHAPPIR: Well, obviously
DAN_SHAPPIR: oh, yeah
CHARLES MAX_WOOD: I'm going to...Interrupt you here for a second, Dan. We're already at an hour recording. I have a hard stop in 20 minutes. So how much longer are we going to go?
DAN_SHAPPIR: Yeah, probably another episode, I think.
CHARLES MAX_WOOD: Probably. All right. So we'll just kind of put a pin in this here. We'll schedule a follow-up episode, do a part two. And yeah, this is really fascinating. I mean, a lot of this stuff I'm aware of, but anyway, I really, really enjoy just kind of seeing where you're coming from on this, Dan. And yeah, some of the stuff makes sense. Some of the stuff, it's like, okay, again, I would use this in certain circumstances and not others, but I'm really enjoying it.
AJ_O’NEAL: But tomato potato, because the React code that I've seen is a big mess where it's a bunch of people just use and I get the argument, well, you're not really coding React if you're using Redux or whatever. I get that, right? But people just throw in these extra state management tools, and then they throw the state everywhere, and then everything is entrapped with the drippings of the state, and I don't see how that's any better. Then you need to be a disciplined coder. React isn't going to solve that problem.
DAN_SHAPPIR: I totally agree. I agree with everything you said, AJ. And yeah, React is no silver bullet. And if you write the messy code, then you can definitely write messy code in React. And my issue...and the one exactly that I'm most trying to express in this, in our conversation is that if you understand the React approach, the React philosophy, and try to write your code accordingly, work with React, instead of just writing on top of React, then you would probably end up with much better and cleaner code.
AJ_O’NEAL: I agree with that. I think the same applies for the DOM. But I agree.
DAN_SHAPPIR: Fair enough. I
AJ_O’NEAL: I'd much rather people get good React training and write good React code then not get good React training and write bad DOM code.
DAN_SHAPPIR: Fair enough.
CHARLES MAX_WOOD: All right, well, I'm gonna push this into PIX just in the interest of time. And yeah, we'll definitely revisit this in a future episode.
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.
CHARLES MAX_WOOD: Steve, why don't you start us off with picks?
STEVE_EDWARDS: All righty then. So I came across a site that's right up my alley. It is a phrase generator, a catchy headline generator. And it says, the description says it generates random clickmate titles for your blog or magazine articles. And then it has different categories like academic quotes. It even has Bible quotes, which is sort of funny, financial advice, headlines, and there's just random button and you push and you get a new headline. So like five jaw-dropping secrets that make supervisors stronger. There's political rhetoric says, I refuse to support an America where corrupt labor unions and greedy insurance companies can undermine our big box retail stores or the Bible quotes is great. Uh, they that praise the Lord that God shall cast out less than vice. They shall vanish wickedness. You know, just quotes that you won't find anywhere, but it's, it can come up with some really funny ones. So it's at a phrase generator.com. And then for my highly anticipated jokes that I provide every episode. Question, what is the difference between a cat and a complex sentence? A cat has claws at the end of its paws and a complex sentence has a pause at the end of its claws. Thank you. Thank you very much.
AJ_O’NEAL: Been muted in time.
CHARLES MAX_WOOD: And then That was actually pretty good.
AJ_O’NEAL: Why do birds fly to warmer climates in the winter? Because it's easier than walking. And then finally last one. Went to my Doctor the other day, I wasn't feeling well. And I said, doctor, man, I got a bad case. I have a case of diarrhea. What should I do? He said, buy a new case. Thank you. So those are my picks for the day.
CHARLES MAX_WOOD: All right, AJ, what are your picks?
AJ_O’NEAL: So first I will pick the react to the future talk. I was wrong. It is not by Abramov. It is by Jordan Walk. Is that the person that actually created react?
CHARLES MAX_WOOD: Yes.
CHARLES MAX_WOOD: All right, Dan, what are your picks?
DAN_SHAPPIR: I only have just the one pick so one of my colleagues at Wix is this awesome guy called Galsch-Lezinger. He's into a lot of really cool stuff into WebAssembly and Rust. I really need to get him to come on the show sometime. One of the things he likes to play with is TypeScript and he takes TypeScript to the extreme. Because you know, when you're throwing generics and stuff like that into the type system, the type system itself becomes its own programming language. And so he wrote this post called typing the technical interview in TypeScript in which he uses TypeScript's own type system to implement the old FizzBuzz problem. So he implements a solution for FizzBuzz using just the TypeScript type system. Really interesting. Really amusing article. Highly enjoyable. At least I found it so. And like I said, I definitely need to get him on our show and this would be my one and only pick for today.
AJ_O’NEAL: Wait a second. Even even better than using forget the name of it.
CHARLES MAX_WOOD: What's device.
AJ_O’NEAL: Yeah. Device.
CHARLES MAX_WOOD: So device is easy. The problem is, is getting all those other types of sign ins. I want, I want people to be able to sign in with whatever they want.
AJ_O’NEAL: Oh, device doesn't have plugins for the other sign-ins.
CHARLES MAX_WOOD:It does, but you have to go and maintain that stuff. I'd rather just let off zero do that. So anyway, that's pretty much it. I'm looking forward to hearing from you. Also, if you want just direct coaching on any of that stuff, topendevs.com slash coaching. And yeah, we'll wrap it up here. Thanks for coming. This was terrific, Dan.
DAN_SHAPPIR: Thank you very much. I enjoyed it myself. And I get the pleasure of having a follow-up. So, you know, double win. Ha ha ha.
CHARLES MAX_WOOD: Right? All right, folks, till next time. Max out.
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 dot com to learn more.