This episode is a continuation of Javascript Jabber 512, so head over there before tuning into this one! In this Part 2, the Jabberers and Dan Shappir discuss THE difference between Svelte vs. virtual DOM and React, the most noticeable pros and cons of React when a DOM’s around, and how “partial rendering” is changing the game. Per usual, Steve’s dad jokes are 100% funny.

_“This separation that the VDom creates between the representation of the UI and the actual UI is a really powerful one.”

In This Episode

The BIGGEST difference between Svelte and virtual DOM + React (and when to use one or the other)
 React’s noticeable pros and cons when a DOM gets involved (and how much they’ll affect your workflow in 2022)
 What to watch out for in case you get locked into a vendor (and which vendors to consider)
 How “partial rendering” is changing the game (and created a whole new model where React is the “middleman”)

Sponsors

Picks

Sponsored By:

 

From a unique waterfall in the airport to the vibrant street food scene in Chinatown, Singapore offers a blend of tradition and innovation like no other. And now, with Singapore Rewards, you can experience Singapore's hidden gems for free! Discover Jewell Changi Airport or join the hidden gem walking tours, all for free! Find out more at SingaporeRewards.VisitSingapore.com What are you waiting for? A better way to holiday awaits you.

 

STEVE_EDWARDS: Hello everybody and welcome to yet another exciting episode of JavaScript Jabber. I am Steve Edwards, the host with the Facebook radio and the voice for being a mime, but I am still your host with me today on our panel, we have three amazing people. First of all, the lovely Amy Knight.

AMY_KNIGHT: Hey, hey from Nashville.

STEVE_EDWARDS: The always confrontational AJ O'Neill, and informational, I must say.

AJ: Yo, yo, yo, coming into life. I'm so excited that Amy joined again. Woo-hoo!

STEVE_EDWARDS: Been a while. And today, our panelist, actually he's more of our guest, shall we say, Dan Shapir.

DAN_SHAPPIR: Hi everybody from Tel Aviv, where it's finally decided to be winter almost the end of the year, I guess it's time.

STEVE_EDWARDS: Getting all the way down to 55 degrees Fahrenheit. For those of us who are waking up to 30s, that seems very warm, but it's all relative, I suppose.

DAN_SHAPPIR: Yeah, yeah. At least it's raining, and there's a bit of thunder storm outside and something. So that's our definition of winter.

STEVE_EDWARDS: I see, I see.

 

Tired of explaining your absurdly high big tech cloud bills to your boss? Let me tell you about this cloud infrastructure company that's the talk of the tech world. The name is Volter, that's VULTR. They pack high performance cloud compute at a price that AWS and the other big clouds can't compete with. So reap the benefits of advanced networking features, managed Kubernetes, developer friendly API in 20 global locations, offering elastically scalable computing power. Over a million users have deployed on Volter in 60 seconds or less across 12 pre-selected operating systems with their own ISO. With pricing starting as low as $2.50 per month for Volter Cloud Compute, they offer plans for developers and businesses of all sizes. You can try Volter for free today by visiting Volter.com slash Jabber, and you'll receive a $100 credit. That's V-U-L-T-R.com slash Jabber.

 

STEVE_EDWARDS: Okay, so today is our continuation of a previous episode. Episode number 512 was Virtual Dom in the Rackway part one. This is going to be part two, considering one plus one equals two, and that whole thing. So Dan, start us down the road. Where are we going next on this topic?

DAN_SHAPPIR: Yeah, for sure. So as Ezekarek said, this is a continuation of that previous episode. And in fact, I highly recommend that whoever is listening to us, before proceeding with this episode, make sure to listen to that one because I build on the stuff that we talked about in that episode. But just to provide a quick reminder or recap of the stuff that we talked about. In that episode, I explained that the core concept of React is the desire to model the UI layer as closely as possible as a pure function, a function that takes the current application state as an input parameter or argument, and then provides the resulting UI as its return value. So essentially it's application state in, UI state out. And that this is very much unlike the actual browser DOM, the real DOM as it were, which is a global object that is updated using mutations and essentially just using side effects. That if you want to update the browser DOM directly, then you get the window dot something dot something dot something, and you do some operations. So it's all side effects on this globally accessible object and all the downside that are associated with this type of implementation. And React, as I said, aims to solve that by implementing UI updates in a functional manner. And we talked about the fact that doing this, doing it in this way, easier to reason about because with pure functions and avoiding side effects, it's easier, at least I think it is, to figure out how the algorithm works and what it actually performs. You're also less likely to get into trouble because of various parts of the application stepping on each other's feet. And it's also much easier to test because you don't have to mock any sort of a global object. You don't have to simulate the DOM in order to unit test your code. You just provide various input values and check that the generated virtual DOM matches your expectation because the virtual DOM is just a collection of JavaScript objects. And that's the other thing that we talked about. We talked about the fact that VDOM enables this mode of operation because you can't actually generate the DOM itself in those pure functions, because that would require you to replace the entire DOM, as it were, on every update. That would be really not performant, and it would also invalidate a lot of local state. And the other possibility was to use HTML strings. That's... AJ, for example, brought this approach up. It's much easier now than it ever was, but it still has the downside of effectively putting code inside of strings, HTML code, but it's still code. Also, there are performance issues and state issues with that approach as well, even though it's much better in terms of performance than you might expect. But still, it's problematic. And Virtual DOM solves this, because you just construct the UI that you want as a tree or collection of simple JavaScript objects. For example, if you want to represent a div, let's say that has certain children and attributes, you just create a JavaScript object that has a certain fields that contains the name, the tag name, that's the fact that it's a div. You have a key value map or collection of the various attributes. And then an area of children, which are also themselves again, just simple JavaScript objects. Once you've created that virtual DOM, you hand it over to React, and React reconciles that, which basically means that it compares that to its previous known state, sees what has changed, figures out the smallest or the most efficient changes to get you from the previous state to this current new state, and then just applies those changes. So it's the burden of actually implementing the mutations shifts from your code into React, where it's taken care of by, you know, the great developers that work at Facebook implementing React. And it's no longer your burden, as it were. And that's more or less what we covered a previous time, but again, in much more detail. And we also got into a lot of the issues surrounding this approach. So again, I highly recommend that our listeners check out that episode if they haven't listened to it already. Any comments or thoughts or suggestions so far?

STEVE_EDWARDS: So yeah, maybe this might be getting off the beaten path, but I know, you know, Vue uses, at least in Vue 3 they use proxies, but they're still using a virtual DOM. And then you have something that comes along like Svelte that doesn't use a DOM at all because, you know, performance issues it handles seeing it at compile time and so on. So are you very familiar with Svelte and how that works, and maybe as a comparison between that and virtual DOM and React?

DAN_SHAPPIR: So, yeah, I actually brought that up. So first of all, I am familiar with Svelte, but I would certainly not consider myself to be a Svelte expert. I've created some small-scale toy projects. I haven't actually implemented a real production system using Svelte, and until I do, I wouldn't actually consider myself to be a Svelte expert.

STEVE_EDWARDS: I don't know, looking at the video, you look pretty Svelte to me, but maybe that's something different.

DAN_SHAPPIR: Yeah, I think the core. Yeah, thank you. Thank you. The core difference here is the fact that Svelte does use mutations to update the DOM. So where React tries to avoid mutations, you have, as I said, these pure functions that have state in UI out. That's not the way in which Svelte works. Svelte does use mutations, but it encapsulates these mutations inside of its components. So only a component can mutate its own UI. And then you don't get that problem that I previously mentioned where, because the actual browser DOM is global, so that any code can access any part of the DOM. Well, these days we also have web components as part of the browser DOM itself, so you can overcome this with Shadow DOM, but effectively most developers don't quite use that or don't use that at all. So Svelte really avoids this problem by encapsulating the mutations inside of its components, and then because it does use mutations, it doesn't actually need the virtual DOM. And in fact, Rich Harris, the creator and the main author of Svelte, has called the virtual DOM pure overhead. So obviously, we know his opinion about it. But for sure, if you don't use this approach of treating the UI or UI transformations via this functional approach, then apparently you really don't need the virtual DOM. Anyway, getting back to where we were. So one more important thing that I think needs to be said about React's approach and use of the virtual DOM and the fact that it does use this functional approach or method for constructing the UI is that this is also the foundation for its own component model. So we talked about, you know, the Svelte component model or we touched on it a little bit, but the way that React implements components, at least these days,is essentially just using functions. So if you've got this root function that's supposed to generate the VDOM for the entire page, inside of it, it can actually call sub-functions to generate different parts of that UI and then combine those as branches under a common root. And in this way, you kind of deconstruct the virtual DOM into parts, each part being handled

 

by a different function. And each such function effectively is a React component. So a React component is just this, again, a pure function that, or you'll see later on, some cases where it's not exactly pure thanks to things like books. But again, let's stick to the ideal model for now. So it's a sort of pure function that takes a portion of the application state.

 

12:24

and then returns a portion of the UI, and those portions are then combined to create the complete virtual DOM for the entire UI. And especially, you know, obviously as you reuse functions, you reuse them as components, so the same function can be used with the different state input in different parts of the user interface. For example, let's say, You have a blog post that you generate using React, and you have a component that generates a paragraph. So each paragraph, the input would be different. The input would be the content of that particular paragraph. But the function that generates the VDOM from that input would be the same function. So that's how React does reuse and componentization. So, yeah. And the JSX which we also spoke about in the previous episode, makes this component model very easy to use and work with because when you specify a DOM node using JSX, let's say open bracket, widget, close bracket, it effectively simply becomes a function called, to a function called widget. And that, the output of that function gets swapped into the VDOM at that point where in the JSX as it were. Hopefully that's clear enough. I'm waving my hands all over the place here. So really what this means is that in JSX there are really two types of nodes. There are nodes which are simple, which are placeholders for simple VDOM elements such let's say as a div or an input and these are just true would be then just directly into the matching real DOM element. And there are nodes which are just placeholders for invoking functions. And then the output of these functions, that gets injected into the VDOM. And when all the functions have been called so that the tree only contains simple VDOM elements, that's when React can actually reconcile it and use it to update the real DOM. And I really hope that this is clear. And you're waving your head.

AJ: Well, it's as clear as it can be without code examples, right? Cause there's only so much you can explain with the audio.

DAN_SHAPPIR: Yeah.

AJ: But yeah,

DAN_SHAPPIR: but there, there are a ton of examples out there. So, you know, and, and by the way, one of the great things about react is that the documentation on, on its site is really excellent when there are a lot of examples there and obviously there are a lot of courses from people like Kenzie dogs or West Boston, so yeah. If my audio hand-waving isn't clear enough, we should definitely check out one of those. Now, so I talked about React and its component model all implemented using pure functions, and that would be it in an ideal world. But obviously, as we all know, we aren't living in an ideal world, and reality is more complicated, and consequently so is React. And there are several problems that React needs to contend with. And I'll just go over them one by one and we'll see how far we'll get. And, you know, if we need a third episode in this series. So the first problem, let's start with the beginning. So the first problem has to do with the initial state. As I previously explained, reconciliation is the process of getting the current VDOM, which expresses what we want the UI to be, and then diffing it with the previous VDOM, which represents what the current UI is, finding the differences, and then using those differences to fix the actual DOM. But what about the initial VDOM, when you don't have a previous VDOM to compare with? So the obvious approach is to say, well then, just generate the entire DOM. Because if I don't have a VDOM, I probably also don't have a DOM. And that's exactly how client-side rendering in React works. So in React, if you're just doing client-side rendering, you download React, you get all the data that you need, and then you generate the initial VDOM, and from that, you construct the initial DOM. Usually, what you would have before then is an empty body, so, you know, or an empty div. So all these web pages that are just an empty body or an empty div, and then use JavaScript to actually build the UI on the client side. That's essentially how they work in React. But the problem with that is that it can have really poor performance because before you can see anything, then first of all, you need to download that empty HTML just so that it causes the JavaScript, both React and your code, to start to download. And the empty HTML doesn't actually show anything. It's just a blank page. Then you need to download and parse all that JavaScript, start executing it, which would usually generate some Ajax calls to actually get some data. Only when those Ajax calls finish, you can finally generate the initial VDOM. And then from that initial VDOM, you need to create the entire DOM, because like I said, there's no previous DOM to diff with. And obviously, all these operations take a long time certainly a lot longer than if you simply just had an HTML page with some content in it. And especially problematic for, if you recall our episodes on Core Web Vitals, it's problematic for the largest content for paint because it takes a long time until something's actually painted. So obviously until the largest thing is painted. And also it's problematic in terms of the time to interact interactive, because until you finish rendering all this user interface, there's really nothing for the user to interact with. So the time to interact doesn't actually end until all this operation finishes. And so obviously it's very desirable to use a somewhat different method of operation so that performance doesn't well suck. And the approach that React uses in order to overcome this challenge is the concept of server-side rendering. And interestingly, it's the VDOM itself that also enables server-side rendering, which is also known as SSR. And by the way, we've also had episodes about that in the past as well. I think one of the first episodes that I actually participated on the show as a guest was about server-side rendering. So if you're interested in more details on that, look back approximately three years or so, time sure flies. Anyway, so why why did I say that VDOM itself enables server-side rendering? Well, obviously, you can't do actual DOM operations on the server because there is no DOM on the server. DOM is a browser thing. It's not a JavaScript thing. It's a browser thing. But VDOM, as I explained, is just simple JavaScript objects and those you can create on Node server just as well as you can create them in the browser. In fact, in a lot of testing scenarios that I see for unit tests, the unit tests actually run in using Node exactly because you're just creating a virtual DOM and then you're checking that the virtual DOM is correct. You don't actually ever apply it into a new DOM in unit tests. You would if you're doing end-to-end. So with the virtual DOM, you create it on the server side in Node, because React code, the part of it that helps you create the virtual DOM, doesn't use the browser DOM in any way. So again, it can run it in Node, and you create that virtual DOM on the server side. But okay, now what do you do with it? I mean, you can't, obviously, you can't reconcile it into the actual browser DOM, because that doesn't exist there. So what you do instead when you hand it over to React, React instead, what it does with it is actually serialize it into a string, a string containing HTML, because it has all the information that it needs to generate that HTML. And then it simply sends down that HTML over the HTTP connection to the browser. So when the request comes into the Node server, to the web server, which is a Node server, it runs the React code. It runs your code to generate the VDOM. You hand over the VDOM to React. React serializes it into an HTML string, sends that string down to the browser. The browser can render that string immediately as part of the HTML response without having to download or run any JavaScript or React or whatever before just displaying this HTML. Is that clear?

STEVE_EDWARDS: Yeah, that actually made sense. Moving or not? I wondered how that worked.

DAN_SHAPPIR: Now, modern infrastructures take it like Next.js, take it even a step further using an approach called static site generation, which basically just means that you perform exactly this operation in Node, but instead of doing it at runtime, you do it at build time. So you execute again, exactly the same react code, it does the whatever operations it needs to do in order to get the data, it generates the HTML, but then instead of sending that HTML down to a browser, it pushes that HTML, it caches that HTML in a CDN. And then when requests come in from a client, it just gets that HTML from the CDN instead of having to generate it in real-time. And this way you save even more time because you get a much faster response from the backend. And that's all there is about static site generation. And it works great, assuming that the data that you have at build time would also be accurate for up-to-date at runtime. Now, as I said, when the browser gets that HTML, you know, it's the same HTML that it would get from a backend that would be, I don't know, PHP or whatever, it doesn't really know or care, it just sees HTML it can render it immediately, doesn't need to wait for any JavaScript in order to do so. And, for example, that can really improve the LCP time, because you would actually have, let's say, the image tag in that HTML response that would actually download the image and the browser would just, you know, display that image. Again, doesn't need JavaScript at all. But we still have a problem. While we do have the initial HTML in the browser, we don't have, on the browser side, the VDOM that generated that tree of JavaScript objects that was used to create that serialized HTML that only exists on the server. If you later want to update the DOM on the browser side and we want to do the diffing, you know, how can we diff with something that the browser doesn't have? As I said, again, it just exists on the server. So how do we actually get a copy of that VDOM down to the client, again, talking about that initial VDOM after SSR or SSG. One possible approach, which some frameworks use, is to actually serialize that VDOM into the HTML in some way. For example, just create JSON from all those JavaScript objects and stick it into the HTML response. And then on the client side, you would deserialize it to create the initial VDOM, and off you go. But for one thing, that would really inflate the HTML because effectively you're putting all your content into the HTML twice. Once as actual HTML and then again as JSON. There are other methods that I've seen this being done, but again, I won't go into the details about it for the simple reason that that is not how React works. That's not what React does. What React does is that instead it expects you to generate the exact same VDOM on the client side before anything else. So you generated that VDOM on the server either at runtime or build time. You serialize the HTML, you send it down to the client, you display that HTML, but before you can actually get the ball rolling in terms of interactivity and responding to user interactions by updating the display, you first need to generate that VDOM again on the client side. And this is something that I think confuses a lot of React developers when they are first introduced to the concept of server-side rendering. And I hope you're less confused same VDOM and we said that the VDOM is the result of a quote-unquote pure function that takes an application state and maps that into the VDOM. Well, it stands to reason that it would need to get the exact same application state on the client side that it used on the server side. So one approach is to just make the same Ajax calls that you made on the server side and let's say and hope that the microservices that you're connecting to would provide the same output. And if that happens, then everything's great. Except for the fact that in order to build that VDOM, you effectively make all your AJAX requests twice. Once from the client side and once from the server side, or actually the reverse, one first from the server side and then from the client side and obviously, there's a risk that one of those microservices, for some reason, would provide a somewhat different response, which would result in a somewhat, potentially a somewhat different VDOM and would get you into all sorts of problems, because then the VDOM wouldn't exactly match the DOM. And that's a problem for React. But, you know, that's one way you can do it. Another way that you can do it is you can actually serialize the data that you use to create the state into the HTML response, so that the server, it performs the data retrieval operations, let's say from a database, from whatever, gets the results, uses it to generate the HTML using React, but then also puts that data into the HTML response as well. Again, that would inflate the HTML, at least a bit. But on the positive side, first of all, it would guarantee that you're using the same data on the client as on the server. And also, it also avoids the hitting all those microservices a second time and also the round trip time from the browser to the backend and back again. I've seen other implementations that use a somewhat kind of a different approach where it's not embedded in the HTML, but the microservices also cache the responses, so even in a CDN, so that again, it's another request, but at least it happens really, really quickly because there's no computation going on. It comes from a CDN, and again, it could be the same data that the server had. But undoubtedly, this is something that we need to think about, consider, and get it right, because if you do. As I said, if you don't do it properly, then you get a different VDOM on the client side than the VDOM that you had on the server, which would mean that your initial VDOM wouldn't actually match the DOM that you have. And then when React starts doing conciliation, it just does the wrong thing because the DOM doesn't match its expectations. Now obviously all this mechanism that I described adds a lot of complexity into React. You know, being required to be able to render the React, to run the React code, both on the server and on the, in the browser, being able to generate both actual DOM nodes from it and being able to generate HTML strings from it, all this operation of, of attaching the new VDOM to the existing DOM, the process which is called hydration. All of these things are extra heavy lifting that React needs to do. And also that you as a React user needs to take into account. At least on the second count, there's assistance in the form of frameworks such as Next.js, which I previously mentioned, because they kind of do a lot of the heavy lifting in this context for you. So you don't need to think about it. We just need to buy into certain best practices, APIs, conventions, whatnot. And of course, also accept a certain vendor lock-in because once you bought into Next, that's more than just React. So if you decide to switch later on from Next to some other framework that also uses React, that would probably still require effort. So you know, again, certain vendor lock-in when you opt to leverage the benefits that such frameworks provide to you and the fact that you don't need to think about a lot of the details that are associated with this whole process of, of SSR or SSG and whatnot. Are we clear so far? Any thoughts or comments? Ajay, you're surprisingly quiet. Are you shell shocked?

AJ: I also have a two-year-old that I'm dealing with right now. Yes, I'm just trying to mentally track with everything you're saying. So that precludes any questions coming out of my mouth because my brain is working too hard.

DAN_SHAPPIR: I don't know if that's a good thing or a bad thing.

AJ: You're just overwhelming with intelligence. Let's just look at it that way.

DAN_SHAPPIR: By the way, the fact that the VDOM can be rendered not just into the browser DOM, but into other targets as well. Like I said, HTML strings was leveraged in order to target other form factors as it works. So that's kind of what enables React Native. Instead of reconciling the VDOM into the browser DOM, they created a native quote unquote DOM, and then they use the VDOM to reconcile that. So this separation that the VDOM creates between the representation of the UI and the actual UI is a really powerful one. Another example that was given in the past is the idea that you could build your own, let's say, DOM over, let's say, WebGL and Canvas, and use that instead of the browser DOM to actually render the UI. You would still be using the exact same mechanism of the virtual DOM just with different nodes.

STEVE_EDWARDS: In other words, if I'm understanding you correctly, is this your packaging the same data in different formats depending on where it's going? depending on what's going to be using it on the, on, on the end. Is that correct?

DAN_SHAPPIR: It's a collection of JavaScript objects that have a field that specifies a tag name.

STEVE_EDWARDS: Well, okay. Think of a different, a different wrapper than the same objects in a different wrapper, HTML strings versus.

DAN_SHAPPIR: No, it's the same object and the same wrapper and everything. You just handing them to different functions. So one react function would use them to reconcile the DOM, a different react function them to generate an HTML string. A third React function would use them to reconcile native representation of the UI. So the difference is not in the objects, but rather you hand them over to. Now obviously the tag names in for React Native would be different than the tag names used with the browser DOM, but those are just strings. Yeah. So, so the fact that a JavaScript object is used to represent a div, it just means that it has, let's say a field called tag name and the value of that field is the string div. That's it. So in the case of React Native, it would be something else instead of div. Unfortunately, I'm not a, I haven't done a lot of React Nativeing, so I don't remember the tag names off the top of my head.

STEVE_EDWARDS: What about offhand? Just kidding. I always check both places.

DAN_SHAPPIR: Yeah.

STEVE_EDWARDS: But so, so you're saying that whichever framework is receiving the data then manipulates it to whatever the purpose is native versus a browser?

DAN_SHAPPIR: Exactly. It's the separation of concerns between the creation of the VDOM of the UI as VDOM and the actual application of that VDOM into the actual UI.

STEVE_EDWARDS: Got it.

DAN_SHAPPIR: Okay, then. So we dealt with one sticking point for React, which was the initial VDOM state, whether or not you're happy with the result is really up to you. By the way, before we move on, I do have to say that somebody like Alex Russell is still very critical of this whole React approach and the initial performance. And the numbers kind of prove him right because at the end of the day, you are running React effectively twice when you're using this approach once on the server side and once on the client side. Now you might be able to use SSG to push that server side execution from runtime to build time, but the client side you still have to execute at runtime. So you really haven't gotten away from that. And that does impact things like time to interactive and can potentially even impact visibility because of resource contention, because you do need to download and execute all that JavaScript. So anyway So that's thorny problem number one. Now let's talk about another thorny problem. So the way that I've been describing React so far is as this pure function that takes the entire applicative state and then generates the entire VDOM. And again, internally it's broken into components that handle sections, but they just get a certain subset of that global application state. You might notice that we kind of are still having to deal with that same problem of globally accessible mutable object, just that instead of it being the UI, it's now the applicative state. Every change that you need to do, you need to put into that global state, and any part of your JavaScript code can read and, you know, potentially write to that global state. Now suppose that I want to have state that is really specific to a particular component. I don't know. Let's say it's a display, a checkbox that determines what to display in a form can be different between in the U S or Canada or whatever. And so I, I know it's in the U S it's one value. And if it's it's in Canada at some other UI, putting that in a global state feels wrong, because it really exposes it to all other parts of the application. Any other part of the application can see it, can read it, and also potentially can write to it. So we've totally broken encapsulation. And that's really bad, because my experience is, with developers, unfortunately, is that when encapsulation is broken, developers take advantage of it. You know, there's like this convention in JavaScript that let's say you prefix private fields and objects with an underscore. I can't tell you the number of times that I've seen code break that encapsulation and access underscore some, you know, something like an underscore value property on some object that doesn't belong to it because that was the most expedient way to solve some bug under pressure. And then obviously down the line, when that object changes, a whole lot of code is going to break.

AJ: So it's funny you mentioned that because I use that all the time and people ask me all the time, what's the underscore for? So I think a lot of people really don't get that it is, hey, don't touch this. Cause I explain that to people all the time.

DAN_SHAPPIR: Well, at least now. I know that you don't like the object oriented approach anyway, and try to avoid this as much as you can. But if you decide to use a...

AJ: Whoa, whoa, whoa. Let's, let's draw a distinction between object oriented and thisness and class classes. I don't like classes.

DAN_SHAPPIR: You're absolutely correct. But yeah, you're absolutely correct.

AJ: I like object oriented. Just not not. I don't like abusing. I don't like it again. I'm just going to say it. I don't like shoving C sharp into JavaScript and pretending like that's the way the JavaScript is supposed to be. And that somehow it's useful. I like using JavaScript the way the JavaScript was designed.

STEVE_EDWARDS: So is it safe to say then that you have no class?

AJ: Sorry, man. That's the obvious joke. It wasn't funny because it's the obvious joke. I mean,

STEVE_EDWARDS: I had to go there.

AJ: No, every, every time I talk about classless JavaScript, that's the first thing people say in it. It's

DAN_SHAPPIR: anyway, if you do elect to ever use classes in your code which I highly doubt, but suppose that you do. These days, instead of using underscore, you can use hash, and then these fields are truly private and cannot be accessed from the outside. So yeah.

AJ: So did that happen? Sorry? When did that happen?

DAN_SHAPPIR: I don't remember the exact ES standard version that it happened on, but it's supported in all browsers. So you can use a class with this called private fields. You just prefix the field name with a hash. Just do empty and private field and you find the documentation about it.

AJ: That's interesting syntax sugar for a closure.

DAN_SHAPPIR: Yeah, effectively it exactly is. They use the, there are even reasons why they use the pound sign, specifically because it's not a legal character as part of a-

AJ: Identifier.

DAN_SHAPPIR: Yeah, exactly.

AJ: And also that's typically, traditionally in at least Ruby documentation which none of the people on the JavaScript committee come from a JavaScript background, they're either Ruby or C sharp. And I think C sharp might be that way too, is that the pound is indicative of an instance property or something like that. I've seen that notation and documentation quite often.

 

Hey folks, this is Charles Maxwood 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. And you can actually hear a little bit more about my story about why I'm doing what I'm doing with topendevs, why I changed it from devchat.tv to topendevs. 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 topendevs because I want to give you the resources that are gonna help you to build the career that you want right? So whether you want to be an influencer in tech, whether you want to go and just max out your salary and then go live a lifestyle with your family, your friends, or just traveling the world or whatever, I want to give you the resources that are going to help you do that. We're going to have career and leadership resources in there and we're going to 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.

 

DAN_SHAPPIR: Well, on the positive side, people who are using classes in JavaScript probably do come from those other languages. So, you know, it pays to be as familiar to those other languages as possible, I guess. Anyway, we kind of strayed away from React and the VDOM. So, pulling us back to React, I was explaining that putting everything in the global state kind of feels wrong. But in fact, the reality is that a lot of React applications actually do work this way. So people who are using React with a state management solution like Redux sometimes go all the way of putting all the state of everything inside Redux and completely avoid putting any state in React components. But React did not want to be dependent on something like that. And in fact, they did want to enable the concept of private or component level state that's encapsulated within that component. Their initial approach to implementing that was to implement such components, components that need state, using classes. So once you have a class, obviously you have the concept of fields you can keep your private, your component level data in the field. What they said is that you on that component, you would need to have a special method called render, which is that method, which is, will be invoked in order to get the, the VDOM for that component. But you can now keep other things on the this and refer to them from within that render method. And this way you can have your own private state. But here's the thing, when your private state changes, the component needs to re-render to reflect that change. So if initially we said that the idea was that your code is just this function that you put the global state in, get the VDOM out for the entire page hand it over to React and React just reconciles it. Now we have this concept of private states within certain components. And when that private state changes, that components needs to re-render, generate the VDOM and invoke the reconciliation without you going to that global function and calling it explicitly. And that's kind of a complicated concept. So hopefully I've made it clear. Quiet, that's worrying. Do I need to explain this again?

AMY_KNIGHT: I'm quiet, but I'm tracking.

STEVE_EDWARDS: Yeah, me too, sorry. I couldn't find the unmute button there for a minute, Dan, but we're tracking.

DAN_SHAPPIR: Okay, cool. So what React, what they did initially in that class-based approach is they introduced this method called setState on the component. And when you invoked said state, you were telling React explicitly that, hey, this component wants to update its state in a certain way. Please do that and then invoke the render method for that component, not for the entire tree, for that component, get that data and just reconcile that part. So when they introduced the concept of component level state, the React designers also introduced the concept of partial rendering, not rendering the entire UI, but only a subset of it rooted at components whose private state has changed. So they enabled the concept of partial rendering. Now this really introduced a lot of complexity into the model because if previously, like in the simplest model, it's your function that just builds the VDOM and calls your sub, your own sub-functions directly, now React needs to wrap everything because it needs to be able to invoke some of these sub-functions directly. So in fact, we've now transitioned to a model where you don't invoke your sub-functions directly, you ask React to invoke them for you, and React is kind of a middleman between all your different layers of components within the generation of the VDOM. And this, but this again enables React to invoke a certain sub-function directly without having to rely on your code to do it. So now instead of just your code building the VDOM and then handing it over to React, it's a combination of your code with React generating the VDOM and then handing it over to, and then also React handing that VDOM update to itself.

STEVE_EDWARDS: So what does that do for overhead and performance? Anything, or is it negligible?

DAN_SHAPPIR: Well, ideally it can actually reduce overhead because now we have the ability to just generate parts of the VDOM rather than the entire VDOM. If you recall from, again, from the previous episode, I said that even though generating VDOM is cheap compared to generating actual DOM, there's still effort involved. First of all, even the VDOM is not free. And second, there are all the computations in your own code. You're generating, you're looking at your code looks at the state and decides what UI to generate from it, that requires computational effort. And sometimes that computational effort isn't cheap. So generating the entire VDOM for the entire page on every little change in state can still be too expensive even with VDOM. Now that React has the ability to decide to invoke just certain parts of that VDOM generation tree, it can, you know, you're generating just subsets of the VDOM, not the entire VDOM, then it's cheaper for, because it's less VDOM to generate, it's less of your code to run, and also less of a reconciliation effort for React.

STEVE_EDWARDS: So in other words, that performance enhancement sort of overshadows any additional code that React has to run to keep track of everything? Well... From a component level?

DAN_SHAPPIR: Yes, but it obviously introduced a lot of complexity. That simple model of just your function generating a tree of simple JavaScript objects is now a whole lot more complicated because you've got your code being invoked by React when React decides that your code needs to be invoked. And if we initially, I described React as a library rather than a framework. And my distinction between libraries and frameworks is basically who's in the driver's seat. When it's mostly, when it's your code that's deciding what needs to run when, that's a library. You, for example, in the case of Lodash, you invoke a Lodash function to do some. That LODASH function might invoke some of your code as callbacks, but still, it's your code that is the instigator. With React, once this happened, this is no longer the case. You know, we kind of kickstarted React, but from that point on, React can decide on its own to invoke your code because some local state change. And, you know, frameworks are by definition more complicated than libraries in terms of their architecture.

AJ: So wait, is your argument that it is or isn't a framework?

DAN_SHAPPIR: I consider React to be a framework like.

AJ: Okay, I agree with that because it's very, it's not something that you use as a tool, it's something that you build with inside of that. That would be the layer of encapsulation is what would do it for me. So a framework is something where you write your code inside of the framework and the framework handles it like you're saying versus a library is something where you during your own thing and you're pulling it in and then using it as needed.

DAN_SHAPPIR: Exactly. So as I mentioned, initially this was implemented using classes and using this mechanism called setState, but then people, the designers of React decided to come up with this new invention called books and deprecate classes, and now this local state is managed using books. We've got the simplest one, which is useState, all the hooks begin with the word use. So we've got the simplest one called useState, but we also have more sophisticated ones like useReducer, for example. But the purpose is still the same, and that is to encapsulate local state within a component. Now, given that now a component is with hooks, components become functions again. So instead of having to implement components that don't need their own state as functions, but using classes for components that do need their own state. And then, you know, when you change your architecture and something suddenly needs to have state or doesn't need to have state anymore, you kind of need to re-implement your component. Now, thanks to Hooks, it's all functions, just whether or not those functions use Hooks which makes transitioning between these two modes of operation much easier. The cost, of course, was that in order to achieve that, the React developers needed to invent this entire whole new concept, which developers really weren't familiar with before. But it seems that they've been able to sell a lot of the developers on it. So, you know, apparently they've succeeded. But the concept of hooks is that even though it seems to be implemented as a pure function, and in fact it is a function, it's not really pure anymore. It has side effects, kind of like a function that has its closure, and it can keep value between invocations in that closure, and then a specific invocation is not pure. It's just a sequence of invocations from day one that's aggregated as you might call it. The total aggregate is kind of pure because if you always provide the same parameters in the exact same order, you would get the exact same results. It's just that instead of you keeping your private values in your closure, React keeps them for you using hooks. Is that clear?

STEVE_EDWARDS: Yeah, I think so. I've always had the, I guess I haven't since I've actually haven't used React just the concept of hooks are defined in React as compared to hooks, how I would normally think of hooks. But no, that makes somewhat sense.

DAN_SHAPPIR: Yeah, the term hooks that the React people chose turned out to be kind of a double-edged sword, because the term hooks was used by other, you know, framework systems, whatever, for a totally different purpose. There was a similarity, and I can explain it now, explain in a minute why they use the term hooks but it does create a lot of confusion for people that are coming from, you know, different backgrounds. So the reason that they call it hook is that you're hooking into the React itself. So as I said, when the, when React introduced that implemented, that component, that ability for components to have their own state, which required React to kind of sit in between the invocation of React components, it means that React can keep track of where it is in the VDOM generation. So it has context about where it is. And consequently, it knows that now I'm invoking this component in order to generate this part of the VDOM. I can save data for that inside of my own data structures and I can give you access to my internal data structures using hooks so that you can put your own stuff in there. So effectively, you're hooking into React. That's why it's called hooks.

STEVE_EDWARDS: Right. OK. That makes sense. I mean, that's fairly close to what I would normally consider a hook, you know, or some process is running. Hey, anybody want to jump in here and do something? Great. Come right on in.

DAN_SHAPPIR: So I won't go into the details of the various types of hooks. First of all, we're basically running out of time and also this justifies the whole episode just on its own. But I'll just give a really simple example of the simplest hook, which is UState. So with UState, you basically just give it a value that you want React to keep for you. And then you can up that. So that would be the initial value of that state that you want that you want to preserve. And what you get, so you invoke a function provided by React called useState. You give it just one parameter, which is the initial state value. And you get back an array, which contains two things. And it does it because it's usually used with destructuring. So usually you will just get, you would destruct the first thing out of that array and the second thing. The first thing is just a variable containing the current value. And by the way, AJ, in the past, I've heard you discussing hooks in React, and you refer to what the useState returns as a getter and a setter, and that's not accurate because it's not a getter. It's just a simple React, it's just a simple JavaScript identifier containing the current value. That's it. It's not a getter. Yeah. I'm absolutely sure.

AJ: But that doesn't make, that's not possible. That would require transcoding because that value changes when you call set. And so if that value changes,

DAN_SHAPPIR: it does. And that's a key point of understanding about react that we probably don't have time for today and will probably require another episode, which is discussing the react life cycle when things change, because when you use the center, you don't actually change the current value. You change the value for the next time.

AJ: Hold on. Wait a second. So, so all of those functions that represent components are torn down and then rebuilt back up again with a new component. So nothing that's in a closure in any of them would actually persist across.

DAN_SHAPPIR: I think you're overthinking it.

AJ: I cannot be overthinking. It's got to be one or the other man. They either, either the value. We don't have pointers in JavaScript. So if the value is not being updated, it means that the whole component has to be redone.

DAN_SHAPPIR: Yeah. So you're correct. You're correct. Yeah. When you put it like that, now I understand what you mean. And the answer is yes.

AJ: Okay. I mean, not to say that I don't ever overthink anything, but this is, this has been my problem with react is that it's sold as look how simple this is, but it's not, it uses JavaScript to create a separate language that does not behave intuitively the way that JavaScript behaves, but behaves the way that if you know the back doors and the dark alleyways, you can coerce JavaScript to behave. But no one who's familiar with JavaScript would look at React and say, oh yeah, this makes sense. I get how they're doing that.

DAN_SHAPPIR: Yeah. I think one of the issues here, and I said it from, I would say that to React developers from the, back from the days of the set of setState.classes and it's still true today with useState and the other books is that the name setState or setWhatever is a misnomer because it's not really set. It's please update this value in the future and notify me after it's updated would be the proper name for this for such a method. Yeah.I, and it's not surprising that the JavaScript developers decided not to use, uh, the actually the appropriate, accurate name because it's kind of long and confusing, but that's essentially what it does.

AJ: Yeah. I just, yeah. I mean, I'm generally in disagreement with appropriating technical terms to mean something that is antithetical to what the term has historically meant. So I realized that occasionally we have to do that with nuance differences, but yeah.

DAN_SHAPPIR: Yeah. So let's say, and I'm going to do a really bad thing and literally just read out code. Let's say we have something like a call that like the canonical use state example, which is cost, const open square brackets, count, comma, set count, close square bracket equals use state of zero. That's kind of the canonical example. So the first-

AJ: And right off the bat, we're appropriating const to mean variable because these are variables, not constants, but let's go on.

DAN_SHAPPIR: No, they are constant. Count is, uh, is, is contains the value zero. And because it's, it's constant, it can't be changed because if you'd use net, you could change counts the variable because it's just a variable containing the value zero.

AJ: Okay. So I would know I'm sold a literal number can be a const. Okay, if you put it all caps so it's clear it's actually intended to be a constant, but it's not. Because every single time it runs, it's intended to be different, which means it's not a constant. It is a variable.

DAN_SHAPPIR: It's, well, you know, again...

AJ: This is the difference between mutable and constant. It is not, it is immutable. So if you did immute, if you wanted to say, immute equals, which still wouldn't be true, because then, for example, anyway, this is... I'll let that one go.

DAN_SHAPPIR: It's immutable in the context of the particular invocation of the function, which is what you always do with const in JavaScript. This specifically is not particular to React. I use const throughout my code. I try to make all my variables const, and we can discuss this in another, some separate episode. It doesn't make them global constants that retain the exact same values throughout the entire execution of the application. It means that there are constant, you know, in the, in the context of the particular invocation of that function in which they exist.

AJ: Uh, I won't, I won't bother, but it's, it, if you want to call it in mute, that's still a lie, but that's closer to the truth. Calling it cons just is.

DAN_SHAPPIR: Yeah. But, but there is no mute keyword in JavaScript.

AJ: Right. But this, so I just, I don't, I get it. We're, we're a JavaScript podcast, but traditionally has had a meeting in programming languages. It's like if I decided, oh, you know what? We're just gonna call, you know, in JavaScript, we've decided that the object keyword is what we're gonna use to declare a function. So I'm just gonna declare objects, open brackets, da da da da da, like, okay, yes. And now in JavaScript, the keyword object means function, but that, Why? No, just no.

AMY_KNIGHT: You're not the only one who I've had this conversation with. Well, no,

AJ: tons of tons of people have. And who was it? Ryan Florence actually made a little snarky comment about this during one of his talks. I don't remember which one it was, but yeah, lots, lots of people. And I run into people at meetups and they're like, yeah, I just quit using let and cause because it's too confusing. And the rules aren't consistent. It's just C-sharp developers trying to bring in something that they want into the language, being on the standards.

DAN_SHAPPIR: I hear, I kind of disagree. My approach these days is I const all things and with few exceptions, if something cannot be const, usually it means that my code needs to be refactored.

AJ: Hopefully that refactoring doesn't include introducing ternary operators.

DAN_SHAPPIR: No, usually. Well. That's the bad approach. My approach is usually to create another function. And have the return value for that function being assigned into that cost. But again, we are totally straying off the React and discussions.

AJ: Let me say one more thing though. Just to finish out my thought here. If you're saying the refactoring is to create another function, then you should have just stuck with var. Because when var when you're doing something where VAR doesn't behave in a sane way, or, or you're doing something where you're coercing VAR to be unintuitive, that is letting you know, oh, this should be in another function, my stuff's getting too long and complicated. So I, I just.

DAN_SHAPPIR: Yeah. But VAR doesn't protect you. Uh, my, my, my attitude with developers, including myself, is that we do bad and stupid things and the programming language should protect us from it. You know, you kind of brought up that talk, React to the Future, uh, with, uh, and, and which he, which is a really, like you said, is a patent switch when he actually is trying to sell us on, on Reason. Uh, and languages like Reason, their default attitude is that everything is const or immutable, whatever you decide to call it. And you, if you need something to be immutable, you need to be very explicit about it and, and, you know, and immediately it smells.

AJ: And, and well, this is how Rust is. And I think it works really well in Rust.

DAN_SHAPPIR: And there's no reason why I can't adopt this ability to significant extent in JavaScript or TypeScript as well.

AJ: I bet it sure. It's just, it's the appropriation that bothers me. If we wanted to call it whatever it is, which I don't know what you would call something where the only thing that it does for you is make sure that you don't reuse the name as another declaration. Cause let already does that. So I don't even know. But again, down the rabbit hole, I just think that whole thing is stupid. And, and that's that. And I don't see any upshot to it. I only see people, I only see people get confused because they don't understand what they're doing in the first place. And then you're throwing bad terminology on top of it, making, uh, you know, pouring salt in the wound, except salt in the wound would actually help the wound heal if I'm not mistaken, and this is not the case.

DAN_SHAPPIR: What I can say is that you and Kyle Simpson seem to be in agreement. So, you know, like. You know, and I look, and I, so you know, you're agreeing with really smart people here. So aside from yourself being smart, you know, you will too. Anyway, it is what it is.

AJ: Ironically, Crockford disagrees, which I found that to be quite interesting. Well, I think what he wanted...He wanted actual constants in JavaScript, real constants, which he already got with object.freeze. If you want a constant, object.freeze will give you a constant. That's how you get a constant in JavaScript.

DAN_SHAPPIR: Okay, you're kind of conflating the constants of the identifier versus the immutability of the object that it's referring to. Pulse basically just says that your identifier cannot change. It cannot, for example, reference a different object. But the

AJ: only in JavaScript in any other same language a constant is a mother flipping constant

DAN_SHAPPIR: Oh, no, that's not the case if you look at languages like Java or C++ or C sharp They actually behave in this regard like JavaScript.

AJ: Oh C-sharp. Hmm go figure No, that's fair, that's fair. No, that's fair, but yeah,

STEVE_EDWARDS: okay so with all that exciting talk about Constance, I'm going to wrap this up since we're a little over time. Uh, it sounds like Dan, you've got enough material. Maybe we'll do an episode three down the road.

DAN_SHAPPIR: Maybe, although we'll be getting really into the weeds of, uh, of, uh, books. And I don't, and I need to consider whether or not that's something that can be done in a podcast. We'll see. I'll think about it.

STEVE_EDWARDS: Alrighty. Well, with that, we will wrap up our topic for the day and move on to picks.

 

Hi, this is Charles Maxwood from Top End Devs. And 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 and 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.

 

STEVE_EDWARDS: So let's start with Amy today. Amy, do you got any picks for us?

AMY_KNIGHT: Shoot, come back to me, sorry. Okay.

STEVE_EDWARDS: Let's start with AJ. AJ always has pics. What do you got for us today, AJ?

AJ: So I am holding in my hand right now the original iPhone. At least I think it's the iPhone. I don't think this is even a 3G iPhone. I think this is the original iPhone.

STEVE_EDWARDS: Like the very first one or one of the very first ones?

AJ: Well, it's not the one that Steve Jobs demoed on stage.

STEVE_EDWARDS: Oh, okay, okay. Just wanted to clarify that.

AJ: Yeah, thank you for clarifying that. I don't want...I don't want our listeners to think that I have Steve Jobs iPhone. Right.

DAN_SHAPPIR: If you had that, I would ask you to send me an NFT for it.

AJ: Oh gosh. Yeah. I'll make it a const. I'll const NFT that on the quote unquote decentralized blockchain for you where the three people in the oligarchy running the system can vet all the transactions.

STEVE_EDWARDS: Easy now. Easy.

AJ: Anyway, I'm just holding this thing in my hand right now. And it's so gosh darn beautiful. It just looks so good. And the thing that they just nailed that they just absolutely nailed. And I don't know if it was iOS five or iOS six is the maps app. You know how when you're driving and the primary purpose of using a maps app, all your driving is to get somewhere and people in San Francisco wouldn't know anything about this because they don't have cars because they take public transit for everything and you have to walk to anything's within a mile of you. You know, but the Maps app works well for driving. And there's just so many other things that we've lost in terms of user experience and UI, things that we used to know back in the Steve Jobs era, and that somehow we forgot when Steve Jobs died. Just simple little nuance niceties of the way that things work and feel. And yeah, so I don't know. I just think, gosh, the Steve Jobs iOS, I guess that's what I'm picking. It was so...Well done. And I, I, man, it just, I, I, it came out of the closet.

DAN_SHAPPIR: I do have to interject that if you remember that episode on Silicon Valley, where they, where they asked how bad something is and he asked, is it Zoom bad? And then they say it's the ultimate, the ultimate this was that it's an Apple Maps bad. Because if you If you recall, they had this thing where they use where they had bugs in the maps themselves, not the maps.

AJ: Yeah, yeah, yeah.

DAN_SHAPPIR: And they actually sent some people into the desert to die because the maps were inaccurate.

AJ: So there's actually inaccuracies in maps on purpose so that this is probably not that case, but so that when map companies copy each other, they have litigation, they can claim, well, we know that you copied our database somehow because you have these fictional places that cannot exist. No, the, the maps app was, was bad in the terms of being able to, to reliably get to destinations that hadn't already existed for five years, but it was really good in terms of if I'm in a car and I want to get somewhere and I don't actually want to peruse the maps app as this wonderful experience of exploring reviews of places near me. If I just want to see, okay, I'm on this road, I'm headed in this direction, and I want to get to the nearest McDonald's that is along the route, it drops pins along your route and you can tap it. And then you just hit, there's only three taps, which I think is two taps or yeah, one tap too many, which is you tap.

DAN_SHAPPIR: I have to agree that with current maps sometimes when I'm driving and I say, Hey, I need it. I don't want to change where I'm going, but I do need to find a gas station or something, and it can be a lot more complicated than you would expect. And then it should.

AJ: Well, yeah, it lists, it lists everything by distance, but that distance could be in front of you or behind you or beside you. Whereas on the, the iPhone maps app from the original iPhone, it would drop pins. And then you tap a pin and it would give you a car icon. And if you tap the car icon, it would give you the route. It would actually show you the route. So if you did not start navigation within two taps, you can get the information that you need in a way that is functional and workable. And then if you tap the start icon, then it would actually start giving you the directions step by step. But if you didn't tap the start icon, and it was a small enough distance. You could see every turn that you needed to take. So it is exactly what a maps app should be first. But, but here's the thing with the caveat that for people who drive, which the people that design these apps, typically speaking, they don't drive. They get an Uber or they take a bus or, you know, they don't, maybe they put it into their Tesla and have the Tesla drive.

DAN_SHAPPIR: You know, again, taking this, uh, attention to be I'm always amused that all the social networks that we totally rely upon in our day, in our modern day-to-day lives, were designed by people that had the worst social experiences growing up.

AJ: Yeah.

STEVE_EDWARDS: Well, AJ, I can give you a little better application of that other than what you're talking about. For our, at least for our fire department, we have apps on our phone that, you know, will indicate when we have a call and need to go somewhere, and it can hook into an apps map on your maps app, excuse me, on your phone. And so I was doing some playing arounds in our app, it's called Active 911. And the most recent updates let you choose which app to use. But I did some comparisons between Google Maps and Apple Maps on an iPhone, just in terms of the data that was available for a specific place, our mobile home park, whatever. And I found that the Apple Maps were more complete and actually had better data at least in my experience, than the Google Maps. I actually started using those instead. So there's that aspect as well.

AJ: That's interesting. I typically use Waze nowadays when I want, when I need the best possible information, I'll end up using Waze cause it'll actually redirect you if there's a traffic jam.

STEVE_EDWARDS: Right. Yeah. Doesn't necessarily get you there. Some of those redirections aren't,

AJ: yeah, they're okay. It doesn't necessarily get you there faster, but it. It evens out the traffic. So it does get you there faster from the perspective that people who stay the main course and people who go the ways way will arrive there at the same time, but they'll both arrive faster because ways is redirecting people through alternate routes so that, and you can see who else is a ways user, because when you start going through cutting through a neighborhood to get back on the main road, you know, like nobody knew that you could cut through that neighborhood to get to that main road. So they've got to be using Waze as well.

DAN_SHAPPIR: Yeah. But I'm sure the neighbors love it. Yeah, that's exactly the thing. A lot of neighborhoods got really upset because all of a sudden they were getting a lot of traffic going through all these side streets in these quiet neighborhoods because Waze was redirecting them, you know, there. And I just wanted to mention by the way that Waze is an Israeli company that got bought by Google and as far as I recall, the development still is.

AJ: That's awesome. Yeah, hold all these cool things in Israel. I didn't know about so let me let me let me finish up here So we had the iOS also. I just did a talk on classless JavaScript If you want to join in for that it was a live thing just very casual Just hanging out with people here in Utah at our local Utah node meetup and we talked about classes JavaScript We also talked about some other things. I learned about the null coalescing operator, which I think Amy had mentioned a while back But I didn't realize was usable in the language and by usable, I mean every browser supports it. The most recent LTS versions of Node support it. So that's what I, when something is stable enough that you can rely on it and not have people cuss you out because you created something that broke stuff, that's when I say it's usable. So it is at a usable state. It is not some fringe feature that's on a maybe standards track. It actually landed and has been implemented and has been implemented long enough that, you know, 95% plus of people on evergreen browsers. I think that that's a low estimate. You'd have to try really hard to have an evergreen browser and not have support for it. So that, but anyway, there's a, the classless JavaScript talk, talk of you on checking on that. And I'm still going to tell you I'm loving these Dell S 2721 QS's. I just bought another one. So I am switching all of my monitors now or becoming these Dell S2721QSs. They are basically the best monitor money can buy except that they're only 330 bucks. You can get them directly from Dell. And then if you, they're not color calibrated, which is part of the reason you're not paying that 700 or $1,200 premium. So you color calibrate them yourself. You have to put them side by side and then fidget with the RGB a little bit. And I bought a calibrator to do an ICC profile to get the nuance response curve differences between the colors set up in an ICC profile. But you think about all the money you'd be saving going with one of these, you buy an X-ray calibrator and then boom, you know, you're set for life. Anytime you ever buy another monitor, you've got a calibrator. You'd never have to pay that factory calibration premium again. So, and they're good monitors. There is a tiny bit of vignetting on the edges. The Apple screens are perfect that way. They don't have any, there's, I didn't notice until somebody pointed it out, but there's just an average, just a little tiny, tiny bit of darkening at the very, very edges of the screen. But I think that seriously, if you paid $1,500 for a factory calibrated screen, and the other thing you're paying hefty bucks for in one of those $1,500 screens is the, Thunderbolt port being integrated in the screen, rather than just paying, you know, one or $200 for a Thunderbolt hub to sit on your desk. I don't think that you're necessarily getting better screen or picture quality out of those crazy, more expensive monitors. This is just, so I'm sold on it. If you want one, get one. And then for the rest of it, webinstall.dev for tools for devs. Feel free to contribute something if any of your daily drivers aren't there. Creeds at Craftsmanship.com for updated list of talks and presentations and whatnot of things that I find to be just the best top notch software engineering resources and then the live streams and all that stuff. So the end.

STEVE_EDWARDS: Right on. All right, Amy, you ready?

AMY_KNIGHT: Yep, I am. Okay. So I'm going to give a programming pick and then a non-programming pick programming one now that I'm doing a lot more DevOps. I'm working with a lot more developers and it scares me when we're screen sharing and they're manipulating Kubernetes clusters and they don't always know the cluster they're on. It's absolutely terrifying.

AJ: I've heard about that. You can run the command in one terminal, be operating on one cluster and then go run the command in the other terminal and your bash or your shell is going to show you the previous one that you were just on because it hasn't updated yet.

AMY_KNIGHT: Well, it would depend probably depend on what you're using, but I'm talking about specifically using kubectl. And that does persist, at least with what I'm using, I use iTurn2. But it's terrifying that sometimes, and it's because, you know, as a developer, you're not necessarily focused on this stuff, but so I have a tool to help you. And that is, so most people are probably familiar with just setting up like their, a get prompt, so you can tell what branch you're on. I'll drop a link to a tool that I use. That's super simple to set up so that I can see my cube context in my dash prompt. So it's right there screaming in your face what cluster you're working on. So you're not accidentally running anything in prod that you meant to run in depth. And then the other thing I'm going to pick, and so people that are more close to me know, like, I don't know, as of September, October have been completely nerding out and falling in love with investing and financial literacy and all this stuff. So as we're getting close to the new year, I'm going to encourage people, if it sounds interesting, to just up their financial literacy. I think people in my generation desperately need to learn about this stuff. It's not really taught in schools. It's not always the most, I find it exciting. Not everyone finds it exciting, but there's various reasons for this. But at least in the United States, the inflation rate was at 8.6%. As of two Fridays ago, that's the highest in 40 years. So if your money is just sitting in a savings account, it's now worth 8.6% less than it was last year. And that's in large part because of COVID relief that was needed and stuff like that. So it's just really important to understand that, understand the tax implications of how much you can, maxing out your 401k, maxing out your Roth IRA is very different than just the company match. So I'm just gonna encourage people to learn all about that stuff. And that's it for me.

DAN_SHAPPIR: Hey Amy, I should really put you in touch with my wife. She's studying up to be a certified investment advisor, based in Israel.

AMY_KNIGHT: Awesome.

DAN_SHAPPIR: So I should definitely get you two together if you're really interested in that and she's really into it right now.

AMY_KNIGHT: Yeah, I'd love to hear the perspective of other countries. I know we have a lot of international people listening to this. And it's my understanding that just because COVID was a worldwide thing that the inflation rate's pretty high across the world.

DAN_SHAPPIR: Actually, it's still really low in Israel.

AMY_KNIGHT: That's good.

DAN_SHAPPIR: In Israel specifically, as I recall, it's less than 2%.

AMY_KNIGHT: That's good.

DAN_SHAPPIR: And the other thing is that it's all global markets now in India. So, you know, when you invest...

AMY_KNIGHT: Well, yes and no. I mean, I'm specifically... I have various different investments and only certain investments that I have are international, but I specifically my brokerage account, I only have that invested in US stocks.

DAN_SHAPPIR: Yeah, but a lot of people from other countries invest in US stocks as well.

AMY_KNIGHT: Correct. Yes. So yeah, I just, and if people have questions, feel free to reach out to me on Twitter or Instagram or anything like that. Like I'm not a financial advisor. I could be telling you wrong things, but definitely.

STEVE_EDWARDS: But you just play one on TV.

AMY_KNIGHT: I'm definitely very passionate about educating people on this stuff because I'm learning a lot that I wish I would have learned much sooner in life, but better late than never.

STEVE_EDWARDS: All right Dan and what do you have for us?

DAN_SHAPPIR: Okay. I have two picks today. The first has to do with the fact that this week I started working at a new place, the company is called Next Insurance. So yes, I now work at an insurance company. I kid that I'm an insurance agent. Oh, but seriously, I'm, I mostly do the same stuff that I kind of did before, except that my role is now expanded in the past. I dealt only with. Mostly with performance on the front end. And in my new role, I'll be dealing with performance on front end and back end as well. So for example, I'm brushing up on my Kotlin because that's the programming language that we use on the back end. And maybe I should talk to Chuck about starting a podcast about that. And I have to say that it's such an exciting experience for me, it's kind of scary when you're starting at a new place, especially after working for a long time at the previous place. I worked at Wix for seven and a half years, but it's also really exciting. It's about meeting new people and finding new challenges and the ability to impact in new places, especially given that Next is a much younger company than Wix is, even though it's a unicorn. And by the way, AJ, another thing about Israel is that Israel, I think, has the largest concentration of unicorns outside of Silicon Valley. I think in Israel, there's something like 50 unicorns, something like that. And by unicorn, I mean a company that has not yet gone public and is worth more than a billion dollars, you know, based on investments. And Next Insurance is exactly such a company. And just to finish up that telling you a little bit about that company, what it does is sell insurance online to small businesses. So if you're a small business and you need insurance and you don't want to have to deal with the insurance agents, you just want to go to some websites where you can get your policy and also later if need be make claims, then the next just might be the solution for you. So that would be my first pick. And my second pick is this really funny story. We kind of mentioned NFTs during the episode. So there's actually two related stories about that. So somebody is selling NFTs of these drawings of monkeys. I don't recall how many monkeys there were, but each one was selling for around $300,000. I have to say that they're nice looking monkeys. It's a nice cartoon. But anyway, somebody was planning to sell his for something like, to sell his, and instead of typing in $300,000 he accidentally typed in $3,000 and before he could retract that it was immediately bought and You know because of the way that the blockchain works once it's done. It's done So wait,

AJ: what did he pay for?

DAN_SHAPPIR: So he wanted to sell one of those monkeys and monkey NFTs Oh the going price was three hundred thousand dollars and he accidentally sold it for three thousand dollars

AJ: Oh,

DAN_SHAPPIR: and again, it was immediately bought and once it's, you know, and it's, you know, one with, with blockchain, once it's done, it's done. There's no backseat. So yeah. So that's one funny story about NFTs. The other funny story was about the same monkeys, which is how they related that this person, Molly White, I actually saw this on Twitter. It seems like she has an interesting account of Twitter as well. She started this website kind of giving news about Web3 and kind of mocking it mostly and showing how nuts it is. And she's actually using a part of the picture of one of those monkeys in the banner on her website. So this guy actually sent her a message where he said, hello Molly, hope you're doing fine. I believe you're using my app, my ape, on your website without my permission. Can you please prove you own this ape, as I believe there is only one looking like this and it is mine. This is really funny because it means that this guy really doesn't get what NFTs mean, if he thinks that NFTs and DRMs are the same thing.

AJ: Yeah, I mean, it's, uh…

DAN_SHAPPIR: The fact that you own the NFT to the ape does not preclude anybody else from using that ape picture any way they see fit maybe from selling another NFT to the same age.

STEVE_EDWARDS: Sounds like everybody's really monkeying around with those things.

AJ: Yeah.

STEVE_EDWARDS: All right, so is that your last pick Dan?

DAN_SHAPPIR: Yes, that's it for me.

STEVE_EDWARDS: Okay, so my picks, a couple of interesting blog posts. One is any developer worth their salt will tell you that when they run into problems, something you don't know how to do or how to remember a function or something like that, you usually start searching for it, you usually start Googling it. I know, I have heard Some well-known developers say that they feel weird live coding on something like Twitch because users are going to see how much they just actually Google. So I found this blog post on Hacker News from a developer who documented in a blog post everything they Googled in a week as a professional software engineer. The developer's name is Sophie Koonin, K-O-O-N-I-N. LocalGHOST.dev is the name of the website. I'll put the link in there. But it's just really interesting. It just lists with the day-by-day breakout, all the things that they Googled during the day, that she Googled during the day. One of the funnier ones was she was Googling something on Chores, C-O-R-S. And while she was doing that, she started Googling on the Chores, which was an Irish band. They had some popular stuff back in early 2000s. I still have some of their music, actually. I made a meme that combines programming Chores with the Chores band. Pretty funny. Second, non-technical post is has to do with lightning. And it's a blog post from Quantum Magazine that talks about how they got some really cool detailed footage of what triggers lightning. It's one of those things that we know what it does and don't always have the fine details of how it gets started. And it's a whole article about how this big telescope array was used. It's LOFAR, low frequency array thousands of small radio telescopes and how they document and attract what causes lightning to be initiated within a cloud and then eventually be released. So really sort of fascinating article. I particularly love that kind of stuff just because it shows the amazing design that there is in nature. And then finally, what everybody's been waiting for is my dad jokes of the week. I can feel the anticipation building. Just do two of them today. So my first one and I'll get to use some voice stuff in here. What did Yoda say the first time that he saw himself in 4K on TV? HDMI. Thank you. Thank you. And then the second joke.

AJ: I'm unmuting so I can I can chuckle or snortle as the case may be. Right.

STEVE_EDWARDS: Well, you missed your chance to chuckle there.

AJ: I did. I did. That's that's why I'm gearing up this time.

STEVE_EDWARDS: OK, this one might not be as good. But December 19th, which was two days ago as a recording of this, was oatmeal muffin day. And so two muffins are in an oven. One muffin turns to the other and says, wow, it's really hot in here. The other muffin screams, oh my gosh, a talking muffin. Thank you. Thank you. So those are my picks for the week. And with that, we will wrap up this episode. Oh, I'm sorry.

DAN_SHAPPIR: Somebody tweeted that if he could go back in time and tell himself, you know, his younger self one thing, it would probably be how to build a tiny ship.

STEVE_EDWARDS: We'll give that a rim shot right there. Very good. Thank you for adding to the list and I appreciate that. So with that, we will wrap up this long episode of JavaScript Jabber and we'll talk at you on the next episode. Adios.

DAN_SHAPPIR: Bye.

 

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.