DAN_SHAPPIR: Hello everybody and welcome to another episode of JavaScript Java. Today on our panel, we have AJ O'Neill.
AJ_O’NEAL: Yo, yo, yo. Coming at you live from pleasant, pleasant Rome.
DAN_SHAPPIR: We've got Steve Edwards.
STEVE_EDWARDS: Howdy from Portland.
DAN_SHAPPIR: Myself, Dan Shapir coming from Tel Aviv where it's still hot, but the days are getting shorter, so I guess it's starting to be fall. And also from Tel Aviv, our guest, Astaf Karinca? Is that how you pronounce your name? I forgot to ask you before we started.
ASSAF_KRINTZA: Almost. Karinca. That's the pronunciation. Karinca.
DAN_SHAPPIR: Cool, cool. So hi, Asaf, and welcome to our show. And today I think we're going to be talking about... Yeah, I need to give you a chance to speak. So today we're going to be talking about state management, right?
ASSAF_KRINTZA: Yeah, we're going to talk about state management, specifically in React applications.
DAN_SHAPPIR: Cool, cool. But before we go there, can you tell us a little bit about yourself?
ASSAF_KRINTZA: Sure.
Have you ever really been happy with your project management tool? Most are either too simple for a growing engineering team to manage everything, or too complex for anyone to want to use them without constant prodding. Shortcut is project management built specifically for software teams and their fast, intuitive, flexible, powerful, and so many other nice positive adjectives. Let's look at some of their highlights. Team-based workflows. Individual teams can use Shortcut's default workflows or customize them to match the way they work. Org-wide goals and roadmaps. The work in these workflows is automatically tied into larger company goals. Click to move from a roadmap to a team's work to individual updates and vice versa. Tight VCS integrations, whether you use GitHub, GitLab or Bitbucket, shortcut ties directly into them so you can update progress from the command line. Keyboard-friendly interface. The rest of Shortcut is just as keyboard-friendly as their power bar, allowing you to do virtually anything without touching your mouse. Throw that thing in the trash. Iterations planning. Set weekly priorities and then let Shortcut run the schedule for you with accompanying burn-down charts and other reporting. Give it a try at shortcut.com slash dev chat and get two months free. Again, that's Shortcut.com slash Dev Chat. Shortcut, because you shouldn't have to project manage your project management.
ASSAF_KRINTZA: So I'm Asaf from Tel Aviv, like Dan, and I've been a programmer for the last 10 years or so professionally, but always since I was a little kid interested in computers and programming. And I've been working on several major companies such as Microsoft and Check Point. And in the last few years, I was more focused as a programmer in front end development. So I got really familiar with various state management applications. And recently in the last year, I've been working on a new company, which I founded together with my two very good friends called LiveCycle, which is a startup that creates live ephemeral environments directly from code like a CI tool. So whenever a new code is pushed, we build and deploy new environments. And those environments are used to provide a way for stakeholders who are not developers, like designers or product managers, to provide feedback at the earliest stage possible in the development stage. So essentially bringing other people into the code review phase using live environments.
DAN_SHAPPIR: So it's kind of like a CD without actually pushing to production.
ASSAF_KRINTZA: Right. It creates for every like a CD, but instead of pushing it to one singleton environment or two or three, it creates an entirely new isolated environment for every commit. And yeah, we also provide collaboration tools on top of that to help folks provide feedback. For example, we have a built-in screenshot tool or a CSS tool in which you can annotate the live environment and provide useful information for the developers to work on it.
DAN_SHAPPIR: Very cool. I assume every such live environment has its own unique URL or something like that.
ASSAF_KRINTZA: Yeah, that's right. Every single one has its unique URL, which you can send to whomever you'd like to go ahead and look at it. We're currently designing it for PMs and designers, but it can be for anyone really. A QA, even management. Although it's not always a good idea and every person in the team sales.
DAN_SHAPPIR: Yeah. My experience with management is that when you send them a mock, they tell you, oh, cool, let's ship it.
ASSAF_KRINTZA: Yeah, exactly.
DAN_SHAPPIR: Yeah. And then by the time you explain that it's just a mock, they've already sold a thousand licenses. And they're there Dilbert cartoon strips about stuff like that. But anyway, getting back to the topic at hand. So we're going to be talking about state management. So, you know, I guess the, the basic question is what is state management?
ASSAF_KRINTZA: Right. So what is state management? So what is, I guess a question that's good to ask before that is what is state? Like a brief description of it. I'm sure everyone knows, but it's helpful to define, to define stuff sometimes. So I can describe status like a piece of information that is used to describe how an application looks and behave at a certain point of time. And the application is derived from the state. Like we can think of many examples like computer games. In a computer game, the state might be where the characters are and what the current actions they perform are, the environment, the camera position, and so on. And in web applications State can be like if there is a model window open, which tab is open, if you have an input field, what input is inside, which toggle button is toggled, and so on. So state management are tools and methodologies and architectures that help us manage this state and control it, because it can be quite complex in very large applications to manage the state.
DAN_SHAPPIR: So yeah, when I think about state, I like to think about it like some sort of a snapshot of my perspective on reality. Like this is how the world is as I perceive it, anything that can impact me and that I can directly impact anything that's totally outside my, you know, my set part of the world that's totally irrelevant. Things in the past are interesting, but it's really the current situation. Now, obviously I might interact with other people and they have, might have a different view of the state, which obviously introduces a lot of issues. And, but, but yeah, that's more or less how I look at it. And, and I guess that it's also pretty true for applications as well.
ASSAF_KRINTZA: Yeah, that's right. Like if you can pause an application at a certain point of time, it's the information that describes what you see on the screen, the stuff that changes. Like for example, there are applications that are stateless. Like if we think about the old internet days in which everything was static, basically text and images, it had no state. Everyone saw the exact same thing. You had nothing to press a click on or drag or just reading articles, basically. But as we moved on and the way became more complex application became more complex and that required a state and that required state management. And
DAN_SHAPPIR: yeah, so initially all the state was preserved in the backend and the front end was just a thin layer, which, you know, you, you, you got the data or you posted data back and now JavaScript, single page applications and whatnot. We need to have at least a portion of the state on the front end so that the application can properly function.
ASSAF_KRINTZA: Yeah, so it can give you the smooth behavior of single page application where the page is not being loaded every time something changes.
STEVE_EDWARDS: So one thing I want to clarify about state is data versus stage, I think. So I want to clarify what it is you're talking about. So we've had somebody on here to talk about XState and I've heard some other recent podcasts with XState and the difference is I understood it was, you know, when I think of state, when I think of state management in Vue, for instance, which I use, you have Vue X, React, you have all these different tools that I'm sure we'll talk about. It's more like holding information, you know? So a common pattern that I would use is if I have a separate backend server that I'm connecting via REST API or GraphQL endpoint, whatever. You know, I pull some information there and put it in state in my browsers so that I can access it easily perform two way data binding on it, update it and see the changes right away on my screen. So that's one version of state. The other version of state is something like the XState library, which seems to be gaining some popularity where it's not about holding data in a place that accessible. It's about maintaining this. I think of it more of as a stage where, okay, I'm about to do this. Okay, I just did this. I'm doing this. I'm in this state of transition between this stage and this stage. So hopefully that makes sense clarifying that as I see the different versions of state. So when we're talking about state management in React, are we gonna be talking about data, maintaining data that's accessible to the front end that might be in the backend, or are we talking about managing at what point in a given process your app is at?
ASSAF_KRINTZA: Yeah, so I think we can probably insert those two different things you mentioned into into one thing, like the entire state. For example, the current stage you mentioned can be like just another key inside a dictionary, which can be like the current action or current. Is the model window open or not? And together alongside it, you can also hold data. For example, if you have like a to-do app and the data might be an array of the to-do items you need to do. And they're status if they're completed or not. So this is like the data state, but you can also have another field for the UI state, which might be maybe the theme is dark or light. So if I understand you correctly, those two things they can, and usually they, they do live alongside each other. You might separate them using different keys in this, inside the state dictionary.
DAN_SHAPPIR: The way that I look at it is that it's ultimately it's about it's about holding the data. At the end of the day, you could theoretically have a state management solution, which is just like a global object or even a couple of global objects containing JSON data or whatever, and just read and write to that stuff. And you know, that can work as state management at the end of the day. Usually what we end up doing is we end up adding rules and limitations on who and how and what can modify the data and in which way, because otherwise we just tend to get into a mess. So when you're looking at solutions like you mentioned, it's more about restricting how you manage that state and what the implications are of changes made to that state, whether or not you get tooling that can automatically perform actions in response to changes in the state and how to validate, for example, state correctness. Because again, if the state is just some global object with data in it, then you can manipulate it any which way you like and put it in some sort of an invalid state, invalid situation or invalid state, which is obviously something that you prefer to avoid.
AJ_O’NEAL: So I like the way that React Hooks handles this problem the general concept of how it, in that it has a dependency tree and it is a little not so JavaScripty. It looks a little unfamiliar and a little weird, but it is somewhat of an elegant solution to just be able to say, give me a state pair and you get the function that is the getter and the function that is the setter. And then anytime you need to change one a state in one area, you use the setter function. And then since states have this hierarchical aspect due to the way that the components are structured and the use state methodology works. If you affect a state that affects another state, you get this nice ripple down effect. And I think that at the component level, that makes a lot of sense. But where I'm not clear on how to manage state effectively is things that are the global state. So for example, is the user signed in? Is it dark mode? These things that don't really necessarily have to do with the, the data of the application, but it really is more of a, you know, there is to, in my mind, a state versus data, because everything is state, but the data stuff is, does it render correctly? And the state stuff is, does the app provide the correct capabilities and respond correctly to events?
ASSAF_KRINTZA: So in regards to the hooks you mentioned in your app useState or useReducer, which is another version of useState. You're right in the sense that the global stuff is kind of awkward to use. For example, if you want to use a theme, and we have a dark and light theme, and we want to provide that theme to a component which is buried very down the tree. So what we'd have to do in order to do that if we want to use useState is to drill down the state using the properties of the different components. So it's a very cumbersome and inconvenient process to pass it down, each level of components until it gets to the right component. It's also very inefficient performance wise, because it would make a whole bunch of components which doesn't need to be rendered to be rendered every time we change that global state. So React actually has introduced a way to solve that using a thing called context, which allows you to bring down states without having to pass it through the entire middle section of the tree. You can just define it at the very top of the tree or at the, let's say in the most, if you have the components, so their least common ancestor. So that would be like the most efficient way to do that. And then entire rest of the part of the tree doesn't have to know about that, but it also has some limitations to it. For example, in use context, you need to create a new context for every type of state you'd like. So if you only have a theme, that's fine. But if you have lots of global state and even sometimes you want dynamic global state, you want to create during runtime more state that you wouldn't, you don't know about in compile time.So
DAN_SHAPPIR: I think there's another issue here that it's not just about the drill down aspect. It's also the fact that if you put as you yourself indicated, AJ, when you use use state as a means to manage state in the components themselves, you're essentially modeling the data based on the UI or on the view. So the view actually specifies how the model looks like. And that can be appropriate in some cases. For example, if it's component specific state, then sure. Obviously it's relevant to that component, so why not? But if you have state that's like, as we said, quote unquote global, that's supposed to be shared between multiple components. For example, I don't know, let's say you've got a user entity in the system and you've got all sorts of data about that user, like their avatar, their username, the contact information, whatnot. And different components in the page need to display different aspects of that user entity. Then you can get really into a mess if the component model dictates how your state is that state distinct from the component tree structure and be able to access it from the component tree structure. Now you can put it inside context and then access it from anywhere you want, but then effectively you've gone back to just having like a global, you know, you might as well just put it in a global and you know, it's JavaScript access it this way. So So the question is, and this from my perspective, is where all these state management solutions come in, is where you want to create that MVC type structure and decouple the model from the view and have this sort of a component, controller middle layer that determines who can see what and who can change what.
ASSAF_KRINTZA: Yeah, I agree. Also with regards to the MVC structure, so that's interesting because when reading about the flux architecture, which is maybe the first like library, it's not exactly, it's both a library and an architecture that Facebook came up with because they came across many problems with the MVC approach, which you have a model of viewing the controller. One of the big issues where they called it a cascading, I think a cascading effect where a model, a view can update the model. And then the model can update another model and then it can update another view. And then it cascades into a whole ripple of effects that is when your application is large enough is essentially uncontrollable anymore. You don't control what's going on and everything gets messy. So they came up with that approach of a single direction data flow in which you update using a thing called an action. You dispatch it. And then various stores subscribe to that and views are getting updated whenever the data updates. So it all goes in a single direction instead of going up then sideways then down. And that I think was like one of the first solutions to that complexity problem with state management.
AJ_O’NEAL: So when is it appropriate to just have multiple apps on the same page rather than trying to shove everything into the same app? Or I guess maybe multiple pages because it seems that sometimes people are trying to fit their analytics tool and their dashboard and the everything all into one app. And maybe those really just ought to be five different apps rather than trying to shove everything together.
ASSAF_KRINTZA: Yeah, it is possible.
DAN_SHAPPIR: Well, sometimes, yeah, go for it. You keep on, I keep on talking. I think there's a delay. I guess this is in there. Yeah. Yeah, we have got a delay and also I think this is a topic we're both passionate about. So I need to control myself. Go for it, please. You're the guest.
ASSAF_KRINTZA: Okay. We talked about multiple, multiple apps. Yeah. So in React, it's actually possible to do that. You can separate multiple apps and I think it is appropriate in many cases. Like the case you talked about where there, there is no, essentially there is no common state between different components in the app. It might be reasonable to do that, but also you don't have to do that. I mean, it doesn't always bring you any benefit because there are state solutions which allow you to conveniently separate between components and without having to worry about separating the entire root of the tree of the application. And for example, recoil, which is a kind of new solution. One of the problems they try to solve is it's a team from Facebook and they actually worked on some kind of an analytics tool. So, and one of the issues they had is using a solution like Redux, which is a global state store, which is very coupled into the application. They couldn't bring in to create plugins like this analytics tool or plugins to the analytics tool, because the state is very coupled to the app. They couldn't just import a new entire subsystem of components. So recoil actually helped to solve that problem.
DAN_SHAPPIR: But as you said, recoil is a really new solution. So let's go back to the beginning. So you mentioned Flux as an architecture that Facebook promoted for managing state in the context of the then very new React view library. Did they actually release a Flux implementation or was it just an architecture? Do you remember?
ASSAF_KRINTZA: Yeah, they had a library which contained only part of the architecture, I think, the dispatcher. So the dispatcher is a part of the architecture that dispatches those changes. And so they had their own implementation for that. But you to use that, you actually should like read the article on their documentation website and understand the methodology of it instead of just importing it and start using the entire thing. It was a combination of a library, like a very small part of Lux and the philosophy behind that. And I think it's since then been...
DAN_SHAPPIR: And then along came Dana Bramov and created Redux for a conference talk he was supposed to give. And here we are.
ASSAF_KRINTZA: Yeah. I think he did that for React Conf Iceland in 2014, if I'm not mistaken. And he wanted to do a talk about hot module reloading with React. And he noticed since the state was combined with the components in the same file, whenever that file was invalidated, the state would not be, would be resetted between hot module, between, between module reloading essentially. So he wanted to have a development experience in which he changes code, saves the file and the state doesn't change and it couldn't happen with Flux. So I started thinking about how he separates that state into another, another place. So the components are not also containing and managing the state themselves. It happens in a single, in a single component called Redux that managed the entire state of the application. And it has many different, it has many new ideas and concepts. For example, the idea of immutable state. In Redux, you have to have your state immutable so that you can efficiently calculate whether the state has changed or not. Because if the state is immutable, by immutable I mean the data itself can change, the check to check whether the state has changed is very easy just compared to objects, very fast. Otherwise, if the state is immutable, you have to do like a deep comparison which you need to take an object and compare every property. And if that property is an object, you need to compare its properties and values and so on. And also the immutable state can give you very nice things like snapshots. Since each version of the state is an entire new object, you can just save those as an array of object, and you can just travel in time because now we have array of the state of the system at every given point on time, you can load them back into the system and look at how your application looked like a few versions ago, which is a very nice thing to have.
DAN_SHAPPIR: One thing I really like about the Redux approach is this concept of having stateful state managed as a series of pure functioning vocations. That it's kind of this kind of a magic trick of using a stateless approach to manage state, which I find to be really cool. That you have this concept of reducer function or functions that you invoke with like two parameters. One is the current state and the other is the action that you want to apply to that state. And then it basically just generates a whole new state using these two values. And since it's a pure function, it will always generate the same result given the same state argument and the same action. And then it returns this new state and that becomes the current state. So you're transitioning from state to state by applying that action via reducer, but you're never modifying the current state. You're just creating a whole new copy, which in a lot of ways is really nice. And in some ways it's like, you know, if you think about it applied to the real world, it's like, you know, you want to hang a picture on the wall then instead of just driving a nail into the wall, you create a whole new copy of the entire world with the nail in the wall, which is kind of amusing in a way. But yeah, for sure. It has a lot of benefits, like you just mentioned. If I keep the sequence of previous states because they're never changed, then I can basically kind of go back in time to whatever previous point was in the application by just going to that particular state and rolling back undoing effectively all these actions that happened since then.
ASSAF_KRINTZA: Yeah, exactly.
DAN_SHAPPIR: And if I look at the success of Redux though, I think that the main reason that it was so successful aside from the fact that it just happened to come along at exactly the right time and provide these benefits of hot module reloads and the ability to do sort of a time machine sort of a thing was also the fact that it integrated really well into React. The fact that it was really easy to just, you know, add Redux to your application or use Redux as part of a new React application at least and have all the boilerplate more or less done for you automatically.
ASSAF_KRINTZA: Yeah, that's certainly part of it. By the way, Redux itself as a library is decoupled from React but you have another library, Redux React, which integrates into the React. But it's interesting that you're saying that because on one hand, it's very, very true that, I mean, it was built around React and keeping in mind, I think most of its users, if not like the vast majority are React users, but also one of the biggest complaints it gets is the boilerplate and the fact that you like need to change three files to to change something in the state and the immutability, it gets tiresome because you need to generate the entire object of state every time in the reducer, which can be quite annoying if you have a very big nested object of a state. But in the last versions of Redux, it came bundled with a thing called Redux Toolkit which addresses all of those issues and make the development experience really, really nice. For example, it uses a library called emir, which is done by the same guy who did MobX and MobX state tree. And this allows you to use JavaScript's own API to change the state without actually changing the state. So you would take an object like with the dot notation, object dot something equals value and it wouldn't actually change the object, it would create a new object from that using a thing called the proxy in JavaScript. It's one way to implement that. Or getter and setters in ES5, it's another way to implement that as well. So it used to be very cumbersome, but today I think it's very, very nice and they worked on that to provide really good dev experience.
Did you work your tail off to get that senior developer gig just to realize that senior dev doesn't actually mean dream job? I've been there too. My first senior developer job was at a place where all of our triumphs were the bosses and all the failures were ours. The second one was a great place to continue to learn and grow only for it to go under due to poor management. And now I get job offers from great places to work all the time. Not only that, but the last job interview I actually sat in was a discussion about how much my podcast had helped the people interviewing me. If you're looking for a way to get into your dream job, then join our Dev Heroes Accelerator. Not only will we help you get the kind of exposure that makes you attractive to your dream employer, but you'll be able to ask them for top dollar as well. Check it out at devheroesaccelerator.com.
DAN_SHAPPIR: Yeah, that's an interesting thing about JavaScript is the fact that you know it's a JavaScript is a multi-paradigm programming language and you can use it as a functional programming language, which functional languages like immutable stuff. But JavaScript, it's not really a pure functional programming language, so it's not really immutable. And you sometimes really need to jump through hoops to get this immutability. And like you said, without magic libraries and magic tools like proxy, it can get annoying when you start having to clone, deep clone entire objects just in order to modify a single value three levels deep. So, for sure, if you can use something like a proxy to magic that away, that certainly makes life a whole lot easier. But it seems to me though that despite all of this, Redux use is kind of on the decline, it seems to me.
ASSAF_KRINTZA: I think I looked at recently the number of NPM download it gets and it's still like 80 or 90% the largest state management library in React. So maybe it's on decline. I don't have a graph that shows that percentage over time, but currently it's the biggest solution still, even though we have newer and more complicated solutions.
STEVE_EDWARDS: So I'm not very familiar with Redux not being a Redux React developer myself, but I'm just curious, you had mentioned just a little bit ago that Redux is a standalone, it's separate, and then there's a, I believe another library Redux React, he said that integrates the two. So is, does that mean then that Redux could be used with another framework? A Svelte, a Vue, an Angular, an Ember, something like that, or is it specifically designed to be used with React?
ASSAF_KRINTZA: So yeah, it can be used independent of React. I'm not sure if there are bindings for Vue or other libraries you mentioned, but you can just use it in vanilla JavaScript, you can use it anywhere you'd like. So the parts of, the React parts of it are the parts that connects it into the components and trigger renders. So you can, a big part of state management is the ability that whenever a state changes, the Vue should react to that and change accordingly. So we want to provide a way that components can subscribe into a certain state. And the state management solution should make sure that each time that part of the state that the component subscribes to changes, it gets notified so it can redraw itself.
STEVE_EDWARDS: Right. Okay. Yeah. So that makes sense. In Vue, we use what's called map getters, map actions, map state, stuff like that. Or you can basically create a two-way data binding with the variable inside your component that is mapped to a piece of state so that when you change it in your component, it automatically updates state and vice versa. So, okay.
DAN_SHAPPIR: The thing is that obviously Redux had a huge influence on the React community, and it was definitely the king of the hill for a long time. And in a way, parts of Redux have made their way into React itself. Like now you have useReducer as a hook within a React, but it does seem to me that I seem to recall even Dana Bramov saying something about the fact that you may not need to use Redux anymore, maybe even shouldn't be using Redux anymore. You know, I don't want to misquote him or misrepresent his opinion, but it does seem to me as though the React community, at least in the way that it's being guided to an extent by Facebook, is moving away from Redux slowly. You know, like you said, it's in such wide use and so many developers are familiar with it. It's undoubtedly here to stay, but does seem that with new projects, it's starting to decline. It seems to me.
ASSAF_KRINTZA: Yeah, perhaps that's true. I mean, in lifecycle, we chose to use a different library also by Facebook, which is called Recoil. And in my last company, Saludo, which is a small Israeli company acquired by a huge American corporate called the shurian we used a library called MobX, which is developed by I'm not sure how to pronounce his name, Michelle something, which also created email, which is the add-on tool I mentioned for Redux. And he created a library called MobX, which is interesting because it allowed you to have state management, which is unlike Redux, very unopinionated and didn't tell you how you should do stuff. It just gave you an ability. And that ability is you can create a state, which is essentially just a regular JavaScript object. And each time you change that object, components are reacting to it because they can subscribe to it. And you don't need to use any fancy API for that because it uses the same kind of magic that Imr uses using JavaScript object or getter or setters in ES5 which essentially is a way to make objects behave in a specific way where you change their values. So imagine you have an object, which is the state, and all you have to do in order to use that state is wrap your component in an observer function, which is a high-order component. And then everything you do inside using a mobic state is automatically subscribed is automatically subscribing to that state. So you don't need to use hooks or anything. It just happens automatically, which is really nice dev experience. But on the other hand, it's really unstructured. So it's up to the developers to keep it organized and make sure stuff are happening without any problems. And in Redux, it's a little bit easier to do that because it forces you to do that. So I think...The trade off is you gain freedom, but you lose structure.
DAN_SHAPPIR: Yeah, that's one of the things that, you know, it's kind of with Mobix, it's not kind of to an extent, I sometimes think of it as like the inverse of Redux because with the Redux, it's all about the state being immutable and generating new state and with Mobix, it's all about the state being wholly mutable. And you mutating the state and then the components react or respond to that mutation of the state. So and again, with Redux, the data flow is very straightforward. You call the reducer and you pass the action into it. And here, you know, the way that you mutate the state is very straightforward. But you know what? what changes in result can is almost magical. I think that the way that it's the model that they use and the way that they kind of explain it is it's like a spreadsheet where you can have a cell and then other cells that are dependent on the value of that cell and additional cells that are dependent, you know, second layer and a third layer and so forth. And you can get values from here and there and perform all sorts of operations on them. And it's all very, it's great because you can like change a single value somewhere and all, and everything recalculates and it's wonderful. But sometimes it's really difficult to follow where exactly the data is flowing in order to, to generate the results that you're ultimately getting. It's sometimes not so easy to track.
ASSAF_KRINTZA: Yeah, exactly. I like the spreadsheet example of reactive programming that that's essentially the magic. You change things and think other things react to it behind the scenes. But you mentioned some of its issues, which are very true. I think Mobix, I look at it more as a capability than a whole state management solution. It provides you a way to react to data changes. And I think also a big part of the community side like that. So a new library from the same author called MobXTaitree created to address those problems or to create a whole very opinionated library that uses the capability of MobX. So it gives you like a single store like Redux, also gives you immutable snapshots like Redux, but the way you change the data is the same as MobX. So that's like, it's like the best of both world, I think. It's a very nice library and I enjoyed very much using it.
DAN_SHAPPIR: So between the two Redux and Mobix, which one do you like more?
ASSAF_KRINTZA: I don't have like, I think it depends on the scenario. I like Redux probably when working with a team and everything needs to be managed tightly and communication across other people is important. So the structure of the code is very important and because it forces you to do stuff in a certain way. That's very nice. It's worth the hassle and the overhead of the boilerplate you need to provide in order to make it work properly. But if I'm doing maybe a smaller project or working with people more used to Mobix, I think I'd prepare that because it's a nicer developer experience. I essentially write less code, which is, and gets the same thing done, which is nice.
DAN_SHAPPIR: Oh, I agree with that. Mobics, like I said, it's almost magical. Challenges that I have found with Mobics is that some, at least for me, it was sometimes kind of difficult to debug or follow the flow of the application to understand exactly what's affecting what. And you do need to be careful from cyclical references. And that can be, at least in the beginning, that can be a hassle. For those of you who are not familiar with what I'm referring to, you know, like if you've got a value that's derived from another value, and then that derived value modifies the, tries to modify in the computation, tries to modify the original value, you kind of get yourself in a loop and Mobix protects you from that, but it's not always trivial to understand exactly how you got yourself into this mess and what you actually need to do to get out of it. Because usually the state changes, we do something in response, we show something, and then we want to update the state accordingly. And we can get into these accidental loops if we're not careful. Now you mentioned a new state library that you're currently using instead of both of these. Can you tell us about it?
ASSAF_KRINTZA: Yeah, so it's a library called Recoil, also done by Facebook. And there are a number of things that are interesting and nice about that library. So first of all, let me start by saying that Recoil, as opposed to Mobix and Redux, is very tightly coupled with React. You can't use it without React. So you need to choose whether you're using React and go by that. But one of the things, one of its advantages is that it's tightly coupled with React from the get-go. For example, it supports React features like the concurrent mode of React, which is the future of React. And it rose up in React 18 and it just comes bundled with it, as opposed to other libraries that might have to do a lot of work to start supporting that. Also, it uses a very familiar API. So, like, if you know React and you know useState, you can start using Recall very, very fast. Instead of useState, the API is useRecallState, and it returns the same kind of value, which is an array of state and setState. And also, the ideas over there are very simple. You have a thing called an atom and a thing called selector. Basically an atom is an atomic piece of data and a selector is a derived piece of data from that. So to give an example for that, let's say you're in Israel and you measure degrees using Celsius and you want to present the Fahrenheit degrees for the same, the same weather. So instead of keeping two different states which you'd have to sync between and manage those which can be problematic and cause bugs, you want to derive one of the data from the other. So you have a single source of truth. So a selector provides you a way of deriving data from atoms. So it's essentially a function that gets an atom and returns a computation out of it. Another nice thing about recoil is that the state is decoupled from the tree. So if you compare that to something like context, React context, the context itself is, the state itself is coupled to the top of the tree where the context is being provided. In recoil, it's separated. So it can provide a way to import plugins from an external source or an external team inside your own company without having to change the structure of your own application. Also, another nice thing about Recoil is that it supports asynchronous data fetching natively. So in Redux, you'd have to use an external tool like a func or something else, maybe saga to support that. In Recoil, it's just natively support that scenario. So by async data fetching, meaning you want to fetch data from the server and update the state using its answer and you don't want to block the system while you're doing that. So it's asynchronous. So a state has a pending state. So Recall gives you a solution for that as well.
DAN_SHAPPIR: So basically you're saying that if I'm going to be building a React application today a new one and I need global state management, not something that's tightly coupled to the various components, then you would recommend Recore.
ASSAF_KRINTZA: Yeah, I mean, I've been using it for the past few months and I enjoy it very much. And I also use it in a production environment. And I find that new members of the team are getting used to it really fast. You don't need to spend a few days learning the state management library, like maybe other solutions. And it's very intuitive. And it also, it has solutions to all of the state management problems and it does it in a very elegant way. So yeah, I would definitely recommend to check it out. And also if looking ahead at the future of React, I think the concurrent mode is a very important feature. And since recall is supporting that natively, it's a very good idea to use it.
DAN_SHAPPIR: Cool. We like opinionated in this podcast. So, uh, with that, I think I'm going to push us to pick soon. So before we go there, is there anything else you would like to tell us about, uh, state management? Anything that we should have mentioned, but haven't?
ASSAF_KRINTZA: Nope. I think, uh, recovered.
DAN_SHAPPIR: Cool. That's, that's very good. If we covered all the bases, that's a good thing. So if people want to get in touch with you either, you know, about this, this topic or any other topic, how? What's the best way to get in touch with you?
ASSAF_KRINTZA: I can find me on email or Twitter, or LinkedIn. I can provide the tags.
DAN_SHAPPIR: No. So just, you know, what's your, what's your tweet? Yeah, just what's your Twitter handle? I think that's the best thing.
ASSAF_KRINTZA: All right. So I think it's hard to it's a, actually I don't remember it by heart. Let me check. I'm not a happy.
STEVE_EDWARDS: You must use a lot.
DAN_SHAPPIR: Okay. So you're saying Twitter is not the best place to get in touch with you. In that case, what is the best place to get in touch with you?
ASSAF_KRINTZA: Let's say an email. Email would be good. The email is asaf, asaf, which is double S, A-S-S-A-F at lifecycle.io.
DAN_SHAPPIR: Now everybody knows, now you can get lots of spam. So, and with that, I'll push us to picks.
Hey folks, it's Charles Maxwood. And I just wanted to jump in here and let you know about something that I'm doing. It's free it's out there just to help you get answers to your questions about the things that you're running into with your career. So if you have questions about how to get further ahead in your career, how to start a podcast, how to get a better job, how to get a raise, how to deal with a situation at work with your boss, or just maybe you're stuck and you don't know where to go next. You know, how do I get from junior to senior, senior to whatever's next? How do I become a speaker? How do I get to the next level. That's what I'm out here to do. So every Wednesday at 12 o'clock mountain time, I'm gonna be doing a call and it's gonna be free, totally free. Go to devchat.tv slash level up and you can register for the call. It's using Zoom's webinar software. So it's pretty straightforward. And what we're gonna be doing is I'll do 10 minutes and I'll just show you how I do some form of how I level up. And then we'll just answer questions. And it's not gonna be a question and answer like, hey, what's your favorite flavor of ice cream? And then I say, rocky road or whatever, right? Instead, what we're looking for is more along the lines of, yeah, I have this situation, how do I handle it? I'm trying to figure this thing out, how do I figure it out? I'm trying to stay current, how do I stay current? And if you have any of those kinds of questions, I'll bring you on the call, we'll ask some deeper questions, we'll make sure we get you a solid answer. And I'm really looking forward to helping some people out. There will be no sales, no selling, no nothing on these calls. It is literally just 10 minutes of training and then Q&A. So you can go check it out at devchat.tv slash level up.
DAN_SHAPPIR: So Steve, why don't you go first?
STEVE_EDWARDS: Alrighty. So one of my subjects that I like to read about has to do with archaeology in terms of, and how I see it validating the historical act of the Bible. There's many different cases I can list, like list off the one I want to talk about to is a very recent one. It was a study that was published in the journal Nature and it's titled a Tunguska-sized airburst destroyed Tal El Hamam. Sorry if I mutilated that damn. A middle Bronze Age city in the Jordan Valley near the Dead Sea. So the gist of the study is related to the biblical story in Genesis 19 of the destruction of the city of Sodom and there's a group of scientists that have been studying for about 16 years, I think this site that's near the Dead Sea in the Jordan Valley. So I think it's north of Israel. And it talks about how what they have found there fits with the destruction that would be wrought by an air burst, similar to one that happened over Siberia and Russia in 1908 and the destruction that it wrought just in term. And some of the things they found, artifacts they found were earth that looked like glazed glass similar to what is found in the nuclear testing sites in New Mexico and the United States. So it's a very long study, a lot of really great detail. And I'll put that in the show notes. And then of course, the high point of every podcast of ours is my dad jokes. So in the past, I've always talked about some of the jobs that have been fired from for different reasons, like fired from the calendar factory for taking a day off, that type of stuff. So I just started to start a new company Chuck would appreciate this if he was here. It's a flight company that's exclusively for bald people. It's called receding airlines. Thank you. And then my second joke.
DAN_SHAPPIR: I actually laughed. I just was, I wasn't you. That's a good one.
STEVE_EDWARDS: I thought I heard a snicker there. And then a little while ago, I was talking to my doctor for a medical procedure that I had to have. And it doesn't really matter what the procedure was. But I asked him, how often do people die during this procedure? And he said, just once. And so Yeah. Finally, I discovered a guy who's a developer. I saw my Twitter, his name's Elijah Manor, and he has a GitHub repo called DevCon. And it's puns that are for developers. And it actually has an API that you can hit and get like random jokes, or you can get specific jokes. You can get a React joke. I think most of them will react, but it's github.com Elijah Manor, DevCon. I'll put the link in the show notes. And that's all I got.
DAN_SHAPPIR: So with that, let's move over to AJ. How about you? Do you have any picks for us? Or is this like a redundant question?
AJ_O’NEAL: No, it's never a redundant question. There are times when I don't have picks. Well, so I'm going to pick, first of all, having kids because I honestly, truly believe that if you do not pursue the path of having a family, which might mean different things for different people, you're missing out on three quarters of life. I, uh, I think, uh, I don't think there's any way to explain it for anybody that, you know, it's, it's one of those things you can, it can only be learned. It cannot be done, but I'm, I'm so glad to have my, my second child and, uh, he's a happy, healthy boy. Well, actually he's not very happy yet. He's grumpy. I think it takes six weeks or so before they learn to smile. But, uh, so I'm, I'm just happy all over again about that and so glad that he is an easy baby. Whereas our last one, she just, we called her the iron lung and we had the cry song and we use it mainly to soothe our own sanities and go cry with the cry song. We just repeat that while we're holding it up for half an hour, 45 minutes, just to not throw her out the window, which by the way. For anybody who's doubting their parenting skills, if you've managed to not throw your children out the window, I think that you are a winner. And I think that anybody who says otherwise.
DAN_SHAPPIR: Well, that's kind of the proof of evolution. I mean, if we would throw babies out the window, that would be it for the human race. So we evolved to love them and withstand them.
AJ_O’NEAL: Yes.
DAN_SHAPPIR: Anyway. Yeah, just to say that for those of you who don't know why AJ did not participate in last week's episode, well now you do.
AJ_O’NEAL: That's right. I was in the hospital. Other one engaged. Yeah. All right. So that aside, there's a couple of book picks I've got. I'm going to pick Killers of the Flower Moon, which is about the murder of the Osage Indians and the birth of the FBI, because those two things have some overlap. And well, Osage Native Americans, to be clear, not Indians, but, you know, we often colloquially use the term wrong. Anyway, it's a very interesting story. And it's so dark and depressing that it gives me a lot of hope. Because if the government and people, humans in general, have been so corrupt for so long, and there's been so many atrocious genocides and murders over the course of history, maybe we'll survive yet another hundred years. You know, if we've managed to recover from it before, maybe we will again. And so that's Killers of the Moon, of the Flower Moon, Killers of the Flower Moon. Very interesting book and very, like I said, dark depressing, but enlightening. And it brought me hope. But then again, dark things often bring me hope because I think, hey, also, I'm going to have to pick, of course, the Stormlight Archives. I got a couple of book picks today. I guess a few to be more grammatically correct. So the Stormlight Archives is one of the Brandon Sanderson sagas, and it is where the name of my son comes from. And I'll be interested to see how many other boys end up with his name over the next decade. We will see. I'm hoping he's not the only one in the next US census. But anyway, just a great fantasy. And if you're not familiar with Brandon Sanderson he's referred to as our Lord and savior Brando Sando by people in the fantasy community, and that is because he has defined magic systems so that you don't end up with something in the realm of Harry Potter where anytime magic is needed, it is magically available, but the magics are only available according to particular criteria. And if the criteria are met, then the magic doesn't work. It's not just the belief you have in your heart. It's also It's kind of a scientific approach to magic. And so I really enjoy the Stormlight Archives. Although I wouldn't necessarily recommend if you haven't done any Brando Sando, I wouldn't recommend that as your first run in, because you've got to have a lot of faith that he knows where he's going because there's a lot of loose threads. And if you've read his other stuff, you know that he knows the end from the beginning and he will tie it together. But if you just run into it blindly, it might be very hard to believe this book is going anywhere.
STEVE_EDWARDS: Sort of the pulp fiction approach. Is that how it works?
AJ_O’NEAL: I'm not really familiar with the pulp fiction approach.
STEVE_EDWARDS: Oh, just multiple threads that are all tied together at the end.
AJ_O’NEAL: Yeah. So the first chapter of the book is not understandable until the fourth book. At the first chapter of the book, you get through the first whole book and you think what in the world was that prelude about, because there was nothing in this entire book that was related to that prelude. And then when you get to the fourth book, it suddenly makes perfect sense. And then the fifth will conclude it's going to be 10 books, but they're going to be in five five and five so that one set of five is a complete story arc and the other set of five is a complete story arc. So the next one should come out a year or two. Anyway, moving on from Stormlight, I also have to recommend that Lightbringer, although it is not as family friendly, it's not something that you can really maybe put on in the living room with the kids or maybe you can, but it drops some f-bombs. It's got some spicy scenes in it. It's not the type of thing. Well, it's just so darn good. Well, it's such a good story. It's hard to not recommend it, but I think it's a little sad in that he does such a good job in exploring the language of the characters and their universe, but then falls back to our language for the swear words, which is something I really appreciate about Brandon Sanderson is that he creates not only the language of the universe, but he also creates their own swear words. And so you have colorful words that aren't harsh on the ears. Whereas Brent Weeks is not so polite, but anyway, those, those books are what I recommend for my picks this week. And I just, I think they're, they're all really good ones, especially if you're not into fantasy, then you need to, you need to at least give Brandon Sanderson a try cause he's the fantasy author for people who are not into fantasy. He, he, he makes it possible to bridge the world of fantasy into almost the world of sci-fi. And then with that If you want to follow my live streams, I've got links to that as well as the higher quality content that I put out on the Beyond Code channel. And that is my long, long, long rave for this week. No JavaScript picks, unfortunately.
DAN_SHAPPIR: Cool. Okay. So now it's my turn. Since you picked so many books and fantasy books at that, I will as well. But what I will do is I will go way, way back in time because you tend to pick the latest and greatest and I tend to pick the oldies but goodies. One advantage, by the way, of picking the old books is that if it's more than one book, usually they're all written. One of the problems that I have with Brandon Sanderson is I read the first three books of the Stormlight Archive and then the fourth book just took its time. I think it was the fourth. Maybe it was the f... I, I, I, somewhere I got lost in the middle.
AJ_O’NEAL: The fourth came out last year.
DAN_SHAPPIR: Yeah. And the problem with that is that I know that if I tried to read the fourth book now, I probably won't remember anything. So I effectively would need to reread the entire three books first. And I don't know if I'm up to that because it's kind of like this situation where I have to remember it. So I won't be actually surprised by anything on the one hand, but on the other end, if I don't read it, I'm afraid I'll be lost. So one of the advantages of the old books is that they're written. And the books that I specifically want to pick this time are written by one of my favorite fantasy and science fiction author of all time, who is Roger Zelazny, which unfortunately is not as well known these days as I think he should be. He's written one of my favorite fantasy slash science fiction book of all time which is Lord of Light, which I highly recommend, but that's not actually going to be my pick this time. My pick this time is actually going to be something else, which is comprised of two books. The first is called Dilvish the Damned, which is actually a collection of short stories. Apparently he was inspired by the Conan stories by Robert Howard, and over a period of something like 15 or 20 years wrote a series of short stories for various fantasy magazines that used to abound back then From 65 until 81 and then all these stories about the same Character within the same world all of these stories were then collected into this single book, which is called Dilvish the damned Highly recommended. I'll post a link to it in the show notes and and then he wrote like a second book just to kind of finish the story and wrap it up. So the second book is just, you know, one, I won't call it big because by Brandon Sanderson standards, it's really tiny, but it's a whole book about the same characters just wrapping up that story that evolved as a sequence of short stories beforehand. I think you would like his books a lot, AJ. I would give it a chance either, you know, Lord of Light is, if you talk about not being able to understand the first chapter, even though it's just a single book, you know, it definitely has that going for it from your perspective. But, you know, almost any Zilazni book is a good book and, you know, so this week I picked the Dilvish books. My other pick is more technical. I've raised, this is a topic I've raised on a couple of episodes in the picks section and that's Apple's browser ban. That's the fact that on iOS devices being, you know, either be it iPhone or an iPad, you think you have browser choice because it seems that in addition to the built-in Safari, you can download Chrome or Firefox from the app store. But the reality is that it's a lie. It's a big fat lie because on the inside, these browsers are actually Safari or even a limited version of Safari with a Chrome or Firefox wrapper around that Safari core because the engine is the WebKit engine inside of it. Because Apple doesn't allow any other browser engines on iOS except its own. And a friend of mine who was also Alex Russell wrote an excellent post about this called Hobson's Browser because it's really Hobson's choice that you have in terms of picking the browser on iOS. And he explains the situation and why it's really, really, really bad for the web and why we should find ways of trying to get Apple to somehow change their behavior in this regard. I think it can only come via regulators, so maybe the governments will act, we will have to wait and see. So those will be my picks for today, and you can find all the links in the show notes. And now I'll hand it over to you, Asaf. Do you have any picks for us?
ASSAF_KRINTZA: Yeah, so actually I came across this really, really cool website called Shader Toy, and what it is is a playground for writing shader which is for those who are not familiar, shaders are the way you write code inside the GPU. And you can write only code. You can't provide it any like 3D data. So you need to draw everything using mathematics. And from them, from there, one of the top contributors to that site is called Inigo Quiles, I hope I pronounced his name right. And he has a YouTube channel in which he explains how he draws these amazingly complex scenes, like with human characters and animations, facial animations and lightning, and backgrounds and everything is doing at, is running at render time using shader code, only using mathematics. And he breaks down every single thing he does and it's fascinating. I, I saw it and it was like magic to me. So that's it for me.
DAN_SHAPPIR: Very nice. Mathematics are cool. So with that, we wrap up another episode of JavaScript Jabber. Thank you all for listening in. I hope you enjoyed it and goodbye from us.
STEVE_EDWARDS: Adios.
ASSAF_KRINTZA: Bye. Thank you for having me.
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.