Podcast appearances and mentions of dan abramov

React Core team member Dan Abramov joins us to explore "JSX over the wire" and the evolving architecture of React Server Components. We dive into the shift from traditional REST APIs to screen-specific data shaping, the concept of Backend for Frontend (BFF), and why centering UI around the user experience—not server/client boundaries—matters more than ever. Links https://danabra.mov https://github.com/gaearon https://bsky.app/profile/danabra.mov https://overreacted.io https://www.youtube.com/@danabramov Resources JSX Over The Wire: https://overreacted.io/jsx-over-the-wire/ Impossible Components: https://overreacted.io/impossible-components/ What Does "use client" Do?: https://overreacted.io/what-does-use-client-do/ Our Journey With Caching: https://nextjs.org/blog/our-journey-with-caching https://parceljs.org https://nextjs.org/docs/app We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Dan Abramov.

If you're in SF: Join us for the Claude Plays Pokemon hackathon this Sunday!If you're not: Fill out the 2025 State of AI Eng survey for $250 in Amazon cards!We are SO excited to share our conversation with Dharmesh Shah, co-founder of HubSpot and creator of Agent.ai.A particularly compelling concept we discussed is the idea of "hybrid teams" - the next evolution in workplace organization where human workers collaborate with AI agents as team members. Just as we previously saw hybrid teams emerge in terms of full-time vs. contract workers, or in-office vs. remote workers, Dharmesh predicts that the next frontier will be teams composed of both human and AI members. This raises interesting questions about team dynamics, trust, and how to effectively delegate tasks between human and AI team members.The discussion of business models in AI reveals an important distinction between Work as a Service (WaaS) and Results as a Service (RaaS), something Dharmesh has written extensively about. While RaaS has gained popularity, particularly in customer support applications where outcomes are easily measurable, Dharmesh argues that this model may be over-indexed. Not all AI applications have clearly definable outcomes or consistent economic value per transaction, making WaaS more appropriate in many cases. This insight is particularly relevant for businesses considering how to monetize AI capabilities.The technical challenges of implementing effective agent systems are also explored, particularly around memory and authentication. Shah emphasizes the importance of cross-agent memory sharing and the need for more granular control over data access. He envisions a future where users can selectively share parts of their data with different agents, similar to how OAuth works but with much finer control. This points to significant opportunities in developing infrastructure for secure and efficient agent-to-agent communication and data sharing.Other highlights from our conversation* The Evolution of AI-Powered Agents – Exploring how AI agents have evolved from simple chatbots to sophisticated multi-agent systems, and the role of MCPs in enabling that.* Hybrid Digital Teams and the Future of Work – How AI agents are becoming teammates rather than just tools, and what this means for business operations and knowledge work.* Memory in AI Agents – The importance of persistent memory in AI systems and how shared memory across agents could enhance collaboration and efficiency.* Business Models for AI Agents – Exploring the shift from software as a service (SaaS) to work as a service (WaaS) and results as a service (RaaS), and what this means for monetization.* The Role of Standards Like MCP – Why MCP has been widely adopted and how it enables agent collaboration, tool use, and discovery.* The Future of AI Code Generation and Software Engineering – How AI-assisted coding is changing the role of software engineers and what skills will matter most in the future.* Domain Investing and Efficient Markets – Dharmesh's approach to domain investing and how inefficiencies in digital asset markets create business opportunities.* The Philosophy of Saying No – Lessons from "Sorry, You Must Pass" and how prioritization leads to greater productivity and focus.Timestamps* 00:00 Introduction and Guest Welcome* 02:29 Dharmesh Shah's Journey into AI* 05:22 Defining AI Agents* 06:45 The Evolution and Future of AI Agents* 13:53 Graph Theory and Knowledge Representation* 20:02 Engineering Practices and Overengineering* 25:57 The Role of Junior Engineers in the AI Era* 28:20 Multi-Agent Systems and MCP Standards* 35:55 LinkedIn's Legal Battles and Data Scraping* 37:32 The Future of AI and Hybrid Teams* 39:19 Building Agent AI: A Professional Network for Agents* 40:43 Challenges and Innovations in Agent AI* 45:02 The Evolution of UI in AI Systems* 01:00:25 Business Models: Work as a Service vs. Results as a Service* 01:09:17 The Future Value of Engineers* 01:09:51 Exploring the Role of Agents* 01:10:28 The Importance of Memory in AI* 01:11:02 Challenges and Opportunities in AI Memory* 01:12:41 Selective Memory and Privacy Concerns* 01:13:27 The Evolution of AI Tools and Platforms* 01:18:23 Domain Names and AI Projects* 01:32:08 Balancing Work and Personal Life* 01:35:52 Final Thoughts and ReflectionsTranscriptAlessio [00:00:04]: Hey everyone, welcome back to the Latent Space podcast. This is Alessio, partner and CTO at Decibel Partners, and I'm joined by my co-host Swyx, founder of Small AI.swyx [00:00:12]: Hello, and today we're super excited to have Dharmesh Shah to join us. I guess your relevant title here is founder of Agent AI.Dharmesh [00:00:20]: Yeah, that's true for this. Yeah, creator of Agent.ai and co-founder of HubSpot.swyx [00:00:25]: Co-founder of HubSpot, which I followed for many years, I think 18 years now, gonna be 19 soon. And you caught, you know, people can catch up on your HubSpot story elsewhere. I should also thank Sean Puri, who I've chatted with back and forth, who's been, I guess, getting me in touch with your people. But also, I think like, just giving us a lot of context, because obviously, My First Million joined you guys, and they've been chatting with you guys a lot. So for the business side, we can talk about that, but I kind of wanted to engage your CTO, agent, engineer side of things. So how did you get agent religion?Dharmesh [00:01:00]: Let's see. So I've been working, I'll take like a half step back, a decade or so ago, even though actually more than that. So even before HubSpot, the company I was contemplating that I had named for was called Ingenisoft. And the idea behind Ingenisoft was a natural language interface to business software. Now realize this is 20 years ago, so that was a hard thing to do. But the actual use case that I had in mind was, you know, we had data sitting in business systems like a CRM or something like that. And my kind of what I thought clever at the time. Oh, what if we used email as the kind of interface to get to business software? And the motivation for using email is that it automatically works when you're offline. So imagine I'm getting on a plane or I'm on a plane. There was no internet on planes back then. It's like, oh, I'm going through business cards from an event I went to. I can just type things into an email just to have them all in the backlog. When it reconnects, it sends those emails to a processor that basically kind of parses effectively the commands and updates the software, sends you the file, whatever it is. And there was a handful of commands. I was a little bit ahead of the times in terms of what was actually possible. And I reattempted this natural language thing with a product called ChatSpot that I did back 20...swyx [00:02:12]: Yeah, this is your first post-ChatGPT project.Dharmesh [00:02:14]: I saw it come out. Yeah. And so I've always been kind of fascinated by this natural language interface to software. Because, you know, as software developers, myself included, we've always said, oh, we build intuitive, easy-to-use applications. And it's not intuitive at all, right? Because what we're doing is... We're taking the mental model that's in our head of what we're trying to accomplish with said piece of software and translating that into a series of touches and swipes and clicks and things like that. And there's nothing natural or intuitive about it. And so natural language interfaces, for the first time, you know, whatever the thought is you have in your head and expressed in whatever language that you normally use to talk to yourself in your head, you can just sort of emit that and have software do something. And I thought that was kind of a breakthrough, which it has been. And it's gone. So that's where I first started getting into the journey. I started because now it actually works, right? So once we got ChatGPT and you can take, even with a few-shot example, convert something into structured, even back in the ChatGP 3.5 days, it did a decent job in a few-shot example, convert something to structured text if you knew what kinds of intents you were going to have. And so that happened. And that ultimately became a HubSpot project. But then agents intrigued me because I'm like, okay, well, that's the next step here. So chat's great. Love Chat UX. But if we want to do something even more meaningful, it felt like the next kind of advancement is not this kind of, I'm chatting with some software in a kind of a synchronous back and forth model, is that software is going to do things for me in kind of a multi-step way to try and accomplish some goals. So, yeah, that's when I first got started. It's like, okay, what would that look like? Yeah. And I've been obsessed ever since, by the way.Alessio [00:03:55]: Which goes back to your first experience with it, which is like you're offline. Yeah. And you want to do a task. You don't need to do it right now. You just want to queue it up for somebody to do it for you. Yes. As you think about agents, like, let's start at the easy question, which is like, how do you define an agent? Maybe. You mean the hardest question in the universe? Is that what you mean?Dharmesh [00:04:12]: You said you have an irritating take. I do have an irritating take. I think, well, some number of people have been irritated, including within my own team. So I have a very broad definition for agents, which is it's AI-powered software that accomplishes a goal. Period. That's it. And what irritates people about it is like, well, that's so broad as to be completely non-useful. And I understand that. I understand the criticism. But in my mind, if you kind of fast forward months, I guess, in AI years, the implementation of it, and we're already starting to see this, and we'll talk about this, different kinds of agents, right? So I think in addition to having a usable definition, and I like yours, by the way, and we should talk more about that, that you just came out with, the classification of agents actually is also useful, which is, is it autonomous or non-autonomous? Does it have a deterministic workflow? Does it have a non-deterministic workflow? Is it working synchronously? Is it working asynchronously? Then you have the different kind of interaction modes. Is it a chat agent, kind of like a customer support agent would be? You're having this kind of back and forth. Is it a workflow agent that just does a discrete number of steps? So there's all these different flavors of agents. So if I were to draw it in a Venn diagram, I would draw a big circle that says, this is agents, and then I have a bunch of circles, some overlapping, because they're not mutually exclusive. And so I think that's what's interesting, and we're seeing development along a bunch of different paths, right? So if you look at the first implementation of agent frameworks, you look at Baby AGI and AutoGBT, I think it was, not Autogen, that's the Microsoft one. They were way ahead of their time because they assumed this level of reasoning and execution and planning capability that just did not exist, right? So it was an interesting thought experiment, which is what it was. Even the guy that, I'm an investor in Yohei's fund that did Baby AGI. It wasn't ready, but it was a sign of what was to come. And so the question then is, when is it ready? And so lots of people talk about the state of the art when it comes to agents. I'm a pragmatist, so I think of the state of the practical. It's like, okay, well, what can I actually build that has commercial value or solves actually some discrete problem with some baseline of repeatability or verifiability?swyx [00:06:22]: There was a lot, and very, very interesting. I'm not irritated by it at all. Okay. As you know, I take a... There's a lot of anthropological view or linguistics view. And in linguistics, you don't want to be prescriptive. You want to be descriptive. Yeah. So you're a goals guy. That's the key word in your thing. And other people have other definitions that might involve like delegated trust or non-deterministic work, LLM in the loop, all that stuff. The other thing I was thinking about, just the comment on Baby AGI, LGBT. Yeah. In that piece that you just read, I was able to go through our backlog and just kind of track the winter of agents and then the summer now. Yeah. And it's... We can tell the whole story as an oral history, just following that thread. And it's really just like, I think, I tried to explain the why now, right? Like I had, there's better models, of course. There's better tool use with like, they're just more reliable. Yep. Better tools with MCP and all that stuff. And I'm sure you have opinions on that too. Business model shift, which you like a lot. I just heard you talk about RAS with MFM guys. Yep. Cost is dropping a lot. Yep. Inference is getting faster. There's more model diversity. Yep. Yep. I think it's a subtle point. It means that like, you have different models with different perspectives. You don't get stuck in the basin of performance of a single model. Sure. You can just get out of it by just switching models. Yep. Multi-agent research and RL fine tuning. So I just wanted to let you respond to like any of that.Dharmesh [00:07:44]: Yeah. A couple of things. Connecting the dots on the kind of the definition side of it. So we'll get the irritation out of the way completely. I have one more, even more irritating leap on the agent definition thing. So here's the way I think about it. By the way, the kind of word agent, I looked it up, like the English dictionary definition. The old school agent, yeah. Is when you have someone or something that does something on your behalf, like a travel agent or a real estate agent acts on your behalf. It's like proxy, which is a nice kind of general definition. So the other direction I'm sort of headed, and it's going to tie back to tool calling and MCP and things like that, is if you, and I'm not a biologist by any stretch of the imagination, but we have these single-celled organisms, right? Like the simplest possible form of what one would call life. But it's still life. It just happens to be single-celled. And then you can combine cells and then cells become specialized over time. And you have much more sophisticated organisms, you know, kind of further down the spectrum. In my mind, at the most fundamental level, you can almost think of having atomic agents. What is the simplest possible thing that's an agent that can still be called an agent? What is the equivalent of a kind of single-celled organism? And the reason I think that's useful is right now we're headed down the road, which I think is very exciting around tool use, right? That says, okay, the LLMs now can be provided a set of tools that it calls to accomplish whatever it needs to accomplish in the kind of furtherance of whatever goal it's trying to get done. And I'm not overly bothered by it, but if you think about it, if you just squint a little bit and say, well, what if everything was an agent? And what if tools were actually just atomic agents? Because then it's turtles all the way down, right? Then it's like, oh, well, all that's really happening with tool use is that we have a network of agents that know about each other through something like an MMCP and can kind of decompose a particular problem and say, oh, I'm going to delegate this to this set of agents. And why do we need to draw this distinction between tools, which are functions most of the time? And an actual agent. And so I'm going to write this irritating LinkedIn post, you know, proposing this. It's like, okay. And I'm not suggesting we should call even functions, you know, call them agents. But there is a certain amount of elegance that happens when you say, oh, we can just reduce it down to one primitive, which is an agent that you can combine in complicated ways to kind of raise the level of abstraction and accomplish higher order goals. Anyway, that's my answer. I'd say that's a success. Thank you for coming to my TED Talk on agent definitions.Alessio [00:09:54]: How do you define the minimum viable agent? Do you already have a definition for, like, where you draw the line between a cell and an atom? Yeah.Dharmesh [00:10:02]: So in my mind, it has to, at some level, use AI in order for it to—otherwise, it's just software. It's like, you know, we don't need another word for that. And so that's probably where I draw the line. So then the question, you know, the counterargument would be, well, if that's true, then lots of tools themselves are actually not agents because they're just doing a database call or a REST API call or whatever it is they're doing. And that does not necessarily qualify them, which is a fair counterargument. And I accept that. It's like a good argument. I still like to think about—because we'll talk about multi-agent systems, because I think—so we've accepted, which I think is true, lots of people have said it, and you've hopefully combined some of those clips of really smart people saying this is the year of agents, and I completely agree, it is the year of agents. But then shortly after that, it's going to be the year of multi-agent systems or multi-agent networks. I think that's where it's going to be headed next year. Yeah.swyx [00:10:54]: Opening eyes already on that. Yeah. My quick philosophical engagement with you on this. I often think about kind of the other spectrum, the other end of the cell spectrum. So single cell is life, multi-cell is life, and you clump a bunch of cells together in a more complex organism, they become organs, like an eye and a liver or whatever. And then obviously we consider ourselves one life form. There's not like a lot of lives within me. I'm just one life. And now, obviously, I don't think people don't really like to anthropomorphize agents and AI. Yeah. But we are extending our consciousness and our brain and our functionality out into machines. I just saw you were a Bee. Yeah. Which is, you know, it's nice. I have a limitless pendant in my pocket.Dharmesh [00:11:37]: I got one of these boys. Yeah.swyx [00:11:39]: I'm testing it all out. You know, got to be early adopters. But like, we want to extend our personal memory into these things so that we can be good at the things that we're good at. And, you know, machines are good at it. Machines are there. So like, my definition of life is kind of like going outside of my own body now. I don't know if you've ever had like reflections on that. Like how yours. How our self is like actually being distributed outside of you. Yeah.Dharmesh [00:12:01]: I don't fancy myself a philosopher. But you went there. So yeah, I did go there. I'm fascinated by kind of graphs and graph theory and networks and have been for a long, long time. And to me, we're sort of all nodes in this kind of larger thing. It just so happens that we're looking at individual kind of life forms as they exist right now. But so the idea is when you put a podcast out there, there's these little kind of nodes you're putting out there of like, you know, conceptual ideas. Once again, you have varying kind of forms of those little nodes that are up there and are connected in varying and sundry ways. And so I just think of myself as being a node in a massive, massive network. And I'm producing more nodes as I put content or ideas. And, you know, you spend some portion of your life collecting dots, experiences, people, and some portion of your life then connecting dots from the ones that you've collected over time. And I found that really interesting things happen and you really can't know in advance how those dots are necessarily going to connect in the future. And that's, yeah. So that's my philosophical take. That's the, yes, exactly. Coming back.Alessio [00:13:04]: Yep. Do you like graph as an agent? Abstraction? That's been one of the hot topics with LandGraph and Pydantic and all that.Dharmesh [00:13:11]: I do. The thing I'm more interested in terms of use of graphs, and there's lots of work happening on that now, is graph data stores as an alternative in terms of knowledge stores and knowledge graphs. Yeah. Because, you know, so I've been in software now 30 plus years, right? So it's not 10,000 hours. It's like 100,000 hours that I've spent doing this stuff. And so I've grew up with, so back in the day, you know, I started on mainframes. There was a product called IMS from IBM, which is basically an index database, what we'd call like a key value store today. Then we've had relational databases, right? We have tables and columns and foreign key relationships. We all know that. We have document databases like MongoDB, which is sort of a nested structure keyed by a specific index. We have vector stores, vector embedding database. And graphs are interesting for a couple of reasons. One is, so it's not classically structured in a relational way. When you say structured database, to most people, they're thinking tables and columns and in relational database and set theory and all that. Graphs still have structure, but it's not the tables and columns structure. And you could wonder, and people have made this case, that they are a better representation of knowledge for LLMs and for AI generally than other things. So that's kind of thing number one conceptually, and that might be true, I think is possibly true. And the other thing that I really like about that in the context of, you know, I've been in the context of data stores for RAG is, you know, RAG, you say, oh, I have a million documents, I'm going to build the vector embeddings, I'm going to come back with the top X based on the semantic match, and that's fine. All that's very, very useful. But the reality is something gets lost in the chunking process and the, okay, well, those tend, you know, like, you don't really get the whole picture, so to speak, and maybe not even the right set of dimensions on the kind of broader picture. And it makes intuitive sense to me that if we did capture it properly in a graph form, that maybe that feeding into a RAG pipeline will actually yield better results for some use cases, I don't know, but yeah.Alessio [00:15:03]: And do you feel like at the core of it, there's this difference between imperative and declarative programs? Because if you think about HubSpot, it's like, you know, people and graph kind of goes hand in hand, you know, but I think maybe the software before was more like primary foreign key based relationship, versus now the models can traverse through the graph more easily.Dharmesh [00:15:22]: Yes. So I like that representation. There's something. It's just conceptually elegant about graphs and just from the representation of it, they're much more discoverable, you can kind of see it, there's observability to it, versus kind of embeddings, which you can't really do much with as a human. You know, once they're in there, you can't pull stuff back out. But yeah, I like that kind of idea of it. And the other thing that's kind of, because I love graphs, I've been long obsessed with PageRank from back in the early days. And, you know, one of the kind of simplest algorithms in terms of coming up, you know, with a phone, everyone's been exposed to PageRank. And the idea is that, and so I had this other idea for a project, not a company, and I have hundreds of these, called NodeRank, is to be able to take the idea of PageRank and apply it to an arbitrary graph that says, okay, I'm going to define what authority looks like and say, okay, well, that's interesting to me, because then if you say, I'm going to take my knowledge store, and maybe this person that contributed some number of chunks to the graph data store has more authority on this particular use case or prompt that's being submitted than this other one that may, or maybe this one was more. popular, or maybe this one has, whatever it is, there should be a way for us to kind of rank nodes in a graph and sort them in some, some useful way. Yeah.swyx [00:16:34]: So I think that's generally useful for, for anything. I think the, the problem, like, so even though at my conferences, GraphRag is super popular and people are getting knowledge, graph religion, and I will say like, it's getting space, getting traction in two areas, conversation memory, and then also just rag in general, like the, the, the document data. Yeah. It's like a source. Most ML practitioners would say that knowledge graph is kind of like a dirty word. The graph database, people get graph religion, everything's a graph, and then they, they go really hard into it and then they get a, they get a graph that is too complex to navigate. Yes. And so like the, the, the simple way to put it is like you at running HubSpot, you know, the power of graphs, the way that Google has pitched them for many years, but I don't suspect that HubSpot itself uses a knowledge graph. No. Yeah.Dharmesh [00:17:26]: So when is it over engineering? Basically? It's a great question. I don't know. So the question now, like in AI land, right, is the, do we necessarily need to understand? So right now, LLMs for, for the most part are somewhat black boxes, right? We sort of understand how the, you know, the algorithm itself works, but we really don't know what's going on in there and, and how things come out. So if a graph data store is able to produce the outcomes we want, it's like, here's a set of queries I want to be able to submit and then it comes out with useful content. Maybe the underlying data store is as opaque as a vector embeddings or something like that, but maybe it's fine. Maybe we don't necessarily need to understand it to get utility out of it. And so maybe if it's messy, that's okay. Um, that's, it's just another form of lossy compression. Uh, it's just lossy in a way that we just don't completely understand in terms of, because it's going to grow organically. Uh, and it's not structured. It's like, ah, we're just gonna throw a bunch of stuff in there. Let the, the equivalent of the embedding algorithm, whatever they called in graph land. Um, so the one with the best results wins. I think so. Yeah.swyx [00:18:26]: Or is this the practical side of me is like, yeah, it's, if it's useful, we don't necessarilyDharmesh [00:18:30]: need to understand it.swyx [00:18:30]: I have, I mean, I'm happy to push back as long as you want. Uh, it's not practical to evaluate like the 10 different options out there because it takes time. It takes people, it takes, you know, resources, right? Set. That's the first thing. Second thing is your evals are typically on small things and some things only work at scale. Yup. Like graphs. Yup.Dharmesh [00:18:46]: Yup. That's, yeah, no, that's fair. And I think this is one of the challenges in terms of implementation of graph databases is that the most common approach that I've seen developers do, I've done it myself, is that, oh, I've got a Postgres database or a MySQL or whatever. I can represent a graph with a very set of tables with a parent child thing or whatever. And that sort of gives me the ability, uh, why would I need anything more than that? And the answer is, well, if you don't need anything more than that, you don't need anything more than that. But there's a high chance that you're sort of missing out on the actual value that, uh, the graph representation gives you. Which is the ability to traverse the graph, uh, efficiently in ways that kind of going through the, uh, traversal in a relational database form, even though structurally you have the data, practically you're not gonna be able to pull it out in, in useful ways. Uh, so you wouldn't like represent a social graph, uh, in, in using that kind of relational table model. It just wouldn't scale. It wouldn't work.swyx [00:19:36]: Uh, yeah. Uh, I think we want to move on to MCP. Yeah. But I just want to, like, just engineering advice. Yeah. Uh, obviously you've, you've, you've run, uh, you've, you've had to do a lot of projects and run a lot of teams. Do you have a general rule for over-engineering or, you know, engineering ahead of time? You know, like, because people, we know premature engineering is the root of all evil. Yep. But also sometimes you just have to. Yep. When do you do it? Yes.Dharmesh [00:19:59]: It's a great question. This is, uh, a question as old as time almost, which is what's the right and wrong levels of abstraction. That's effectively what, uh, we're answering when we're trying to do engineering. I tend to be a pragmatist, right? So here's the thing. Um, lots of times doing something the right way. Yeah. It's like a marginal increased cost in those cases. Just do it the right way. And this is what makes a, uh, a great engineer or a good engineer better than, uh, a not so great one. It's like, okay, all things being equal. If it's going to take you, you know, roughly close to constant time anyway, might as well do it the right way. Like, so do things well, then the question is, okay, well, am I building a framework as the reusable library? To what degree, uh, what am I anticipating in terms of what's going to need to change in this thing? Uh, you know, along what dimension? And then I think like a business person in some ways, like what's the return on calories, right? So, uh, and you look at, um, energy, the expected value of it's like, okay, here are the five possible things that could happen, uh, try to assign probabilities like, okay, well, if there's a 50% chance that we're going to go down this particular path at some day, like, or one of these five things is going to happen and it costs you 10% more to engineer for that. It's basically, it's something that yields a kind of interest compounding value. Um, as you get closer to the time of, of needing that versus having to take on debt, which is when you under engineer it, you're taking on debt. You're going to have to pay off when you do get to that eventuality where something happens. One thing as a pragmatist, uh, so I would rather under engineer something than over engineer it. If I were going to err on the side of something, and here's the reason is that when you under engineer it, uh, yes, you take on tech debt, uh, but the interest rate is relatively known and payoff is very, very possible, right? Which is, oh, I took a shortcut here as a result of which now this thing that should have taken me a week is now going to take me four weeks. Fine. But if that particular thing that you thought might happen, never actually, you never have that use case transpire or just doesn't, it's like, well, you just save yourself time, right? And that has value because you were able to do other things instead of, uh, kind of slightly over-engineering it away, over-engineering it. But there's no perfect answers in art form in terms of, uh, and yeah, we'll, we'll bring kind of this layers of abstraction back on the code generation conversation, which we'll, uh, I think I have later on, butAlessio [00:22:05]: I was going to ask, we can just jump ahead quickly. Yeah. Like, as you think about vibe coding and all that, how does the. Yeah. Percentage of potential usefulness change when I feel like we over-engineering a lot of times it's like the investment in syntax, it's less about the investment in like arc exacting. Yep. Yeah. How does that change your calculus?Dharmesh [00:22:22]: A couple of things, right? One is, um, so, you know, going back to that kind of ROI or a return on calories, kind of calculus or heuristic you think through, it's like, okay, well, what is it going to cost me to put this layer of abstraction above the code that I'm writing now, uh, in anticipating kind of future needs. If the cost of fixing, uh, or doing under engineering right now. Uh, we'll trend towards zero that says, okay, well, I don't have to get it right right now because even if I get it wrong, I'll run the thing for six hours instead of 60 minutes or whatever. It doesn't really matter, right? Like, because that's going to trend towards zero to be able, the ability to refactor a code. Um, and because we're going to not that long from now, we're going to have, you know, large code bases be able to exist, uh, you know, as, as context, uh, for a code generation or a code refactoring, uh, model. So I think it's going to make it, uh, make the case for under engineering, uh, even stronger. Which is why I take on that cost. You just pay the interest when you get there, it's not, um, just go on with your life vibe coded and, uh, come back when you need to. Yeah.Alessio [00:23:18]: Sometimes I feel like there's no decision-making in some things like, uh, today I built a autosave for like our internal notes platform and I literally just ask them cursor. Can you add autosave? Yeah. I don't know if it's over under engineer. Yep. I just vibe coded it. Yep. And I feel like at some point we're going to get to the point where the models kindDharmesh [00:23:36]: of decide where the right line is, but this is where the, like the, in my mind, the danger is, right? So there's two sides to this. One is the cost of kind of development and coding and things like that stuff that, you know, we talk about. But then like in your example, you know, one of the risks that we have is that because adding a feature, uh, like a save or whatever the feature might be to a product as that price tends towards zero, are we going to be less discriminant about what features we add as a result of making more product products more complicated, which has a negative impact on the user and navigate negative impact on the business. Um, and so that's the thing I worry about if it starts to become too easy, are we going to be. Too promiscuous in our, uh, kind of extension, adding product extensions and things like that. It's like, ah, why not add X, Y, Z or whatever back then it was like, oh, we only have so many engineering hours or story points or however you measure things. Uh, that least kept us in check a little bit. Yeah.Alessio [00:24:22]: And then over engineering, you're like, yeah, it's kind of like you're putting that on yourself. Yeah. Like now it's like the models don't understand that if they add too much complexity, it's going to come back to bite them later. Yep. So they just do whatever they want to do. Yeah. And I'm curious where in the workflow that's going to be, where it's like, Hey, this is like the amount of complexity and over-engineering you can do before you got to ask me if we should actually do it versus like do something else.Dharmesh [00:24:45]: So you know, we've already, let's like, we're leaving this, uh, in the code generation world, this kind of compressed, um, cycle time. Right. It's like, okay, we went from auto-complete, uh, in the GitHub co-pilot to like, oh, finish this particular thing and hit tab to a, oh, I sort of know your file or whatever. I can write out a full function to you to now I can like hold a bunch of the context in my head. Uh, so we can do app generation, which we have now with lovable and bolt and repletage. Yeah. Association and other things. So then the question is, okay, well, where does it naturally go from here? So we're going to generate products. Make sense. We might be able to generate platforms as though I want a platform for ERP that does this, whatever. And that includes the API's includes the product and the UI, and all the things that make for a platform. There's no nothing that says we would stop like, okay, can you generate an entire software company someday? Right. Uh, with the platform and the monetization and the go-to-market and the whatever. And you know, that that's interesting to me in terms of, uh, you know, what, when you take it to almost ludicrous levels. of abstract.swyx [00:25:39]: It's like, okay, turn it to 11. You mentioned vibe coding, so I have to, this is a blog post I haven't written, but I'm kind of exploring it. Is the junior engineer dead?Dharmesh [00:25:49]: I don't think so. I think what will happen is that the junior engineer will be able to, if all they're bringing to the table is the fact that they are a junior engineer, then yes, they're likely dead. But hopefully if they can communicate with carbon-based life forms, they can interact with product, if they're willing to talk to customers, they can take their kind of basic understanding of engineering and how kind of software works. I think that has value. So I have a 14-year-old right now who's taking Python programming class, and some people ask me, it's like, why is he learning coding? And my answer is, is because it's not about the syntax, it's not about the coding. What he's learning is like the fundamental thing of like how things work. And there's value in that. I think there's going to be timeless value in systems thinking and abstractions and what that means. And whether functions manifested as math, which he's going to get exposed to regardless, or there are some core primitives to the universe, I think, that the more you understand them, those are what I would kind of think of as like really large dots in your life that will have a higher gravitational pull and value to them that you'll then be able to. So I want him to collect those dots, and he's not resisting. So it's like, okay, while he's still listening to me, I'm going to have him do things that I think will be useful.swyx [00:26:59]: You know, part of one of the pitches that I evaluated for AI engineer is a term. And the term is that maybe the traditional interview path or career path of software engineer goes away, which is because what's the point of lead code? Yeah. And, you know, it actually matters more that you know how to work with AI and to implement the things that you want. Yep.Dharmesh [00:27:16]: That's one of the like interesting things that's happened with generative AI. You know, you go from machine learning and the models and just that underlying form, which is like true engineering, right? Like the actual, what I call real engineering. I don't think of myself as a real engineer, actually. I'm a developer. But now with generative AI. We call it AI and it's obviously got its roots in machine learning, but it just feels like fundamentally different to me. Like you have the vibe. It's like, okay, well, this is just a whole different approach to software development to so many different things. And so I'm wondering now, it's like an AI engineer is like, if you were like to draw the Venn diagram, it's interesting because the cross between like AI things, generative AI and what the tools are capable of, what the models do, and this whole new kind of body of knowledge that we're still building out, it's still very young, intersected with kind of classic engineering, software engineering. Yeah.swyx [00:28:04]: I just described the overlap as it separates out eventually until it's its own thing, but it's starting out as a software. Yeah.Alessio [00:28:11]: That makes sense. So to close the vibe coding loop, the other big hype now is MCPs. Obviously, I would say Cloud Desktop and Cursor are like the two main drivers of MCP usage. I would say my favorite is the Sentry MCP. I can pull in errors and then you can just put the context in Cursor. How do you think about that abstraction layer? Does it feel... Does it feel almost too magical in a way? Do you think it's like you get enough? Because you don't really see how the server itself is then kind of like repackaging theDharmesh [00:28:41]: information for you? I think MCP as a standard is one of the better things that's happened in the world of AI because a standard needed to exist and absent a standard, there was a set of things that just weren't possible. Now, we can argue whether it's the best possible manifestation of a standard or not. Does it do too much? Does it do too little? I get that, but it's just simple enough to both be useful and unobtrusive. It's understandable and adoptable by mere mortals, right? It's not overly complicated. You know, a reasonable engineer can put a stand up an MCP server relatively easily. The thing that has me excited about it is like, so I'm a big believer in multi-agent systems. And so that's going back to our kind of this idea of an atomic agent. So imagine the MCP server, like obviously it calls tools, but the way I think about it, so I'm working on my current passion project is agent.ai. And we'll talk more about that in a little bit. More about the, I think we should, because I think it's interesting not to promote the project at all, but there's some interesting ideas in there. One of which is around, we're going to need a mechanism for, if agents are going to collaborate and be able to delegate, there's going to need to be some form of discovery and we're going to need some standard way. It's like, okay, well, I just need to know what this thing over here is capable of. We're going to need a registry, which Anthropic's working on. I'm sure others will and have been doing directories of, and there's going to be a standard around that too. How do you build out a directory of MCP servers? I think that's going to unlock so many things just because, and we're already starting to see it. So I think MCP or something like it is going to be the next major unlock because it allows systems that don't know about each other, don't need to, it's that kind of decoupling of like Sentry and whatever tools someone else was building. And it's not just about, you know, Cloud Desktop or things like, even on the client side, I think we're going to see very interesting consumers of MCP, MCP clients versus just the chat body kind of things. Like, you know, Cloud Desktop and Cursor and things like that. But yeah, I'm very excited about MCP in that general direction.swyx [00:30:39]: I think the typical cynical developer take, it's like, we have OpenAPI. Yeah. What's the new thing? I don't know if you have a, do you have a quick MCP versus everything else? Yeah.Dharmesh [00:30:49]: So it's, so I like OpenAPI, right? So just a descriptive thing. It's OpenAPI. OpenAPI. Yes, that's what I meant. So it's basically a self-documenting thing. We can do machine-generated, lots of things from that output. It's a structured definition of an API. I get that, love it. But MCPs sort of are kind of use case specific. They're perfect for exactly what we're trying to use them for around LLMs in terms of discovery. It's like, okay, I don't necessarily need to know kind of all this detail. And so right now we have, we'll talk more about like MCP server implementations, but We will? I think, I don't know. Maybe we won't. At least it's in my head. It's like a back processor. But I do think MCP adds value above OpenAPI. It's, yeah, just because it solves this particular thing. And if we had come to the world, which we have, like, it's like, hey, we already have OpenAPI. It's like, if that were good enough for the universe, the universe would have adopted it already. There's a reason why MCP is taking office because marginally adds something that was missing before and doesn't go too far. And so that's why the kind of rate of adoption, you folks have written about this and talked about it. Yeah, why MCP won. Yeah. And it won because the universe decided that this was useful and maybe it gets supplanted by something else. Yeah. And maybe we discover, oh, maybe OpenAPI was good enough the whole time. I doubt that.swyx [00:32:09]: The meta lesson, this is, I mean, he's an investor in DevTools companies. I work in developer experience at DevRel in DevTools companies. Yep. Everyone wants to own the standard. Yeah. I'm sure you guys have tried to launch your own standards. Actually, it's Houseplant known for a standard, you know, obviously inbound marketing. But is there a standard or protocol that you ever tried to push? No.Dharmesh [00:32:30]: And there's a reason for this. Yeah. Is that? And I don't mean, need to mean, speak for the people of HubSpot, but I personally. You kind of do. I'm not smart enough. That's not the, like, I think I have a. You're smart. Not enough for that. I'm much better off understanding the standards that are out there. And I'm more on the composability side. Let's, like, take the pieces of technology that exist out there, combine them in creative, unique ways. And I like to consume standards. I don't like to, and that's not that I don't like to create them. I just don't think I have the, both the raw wattage or the credibility. It's like, okay, well, who the heck is Dharmesh, and why should we adopt a standard he created?swyx [00:33:07]: Yeah, I mean, there are people who don't monetize standards, like OpenTelemetry is a big standard, and LightStep never capitalized on that.Dharmesh [00:33:15]: So, okay, so if I were to do a standard, there's two things that have been in my head in the past. I was one around, a very, very basic one around, I don't even have the domain, I have a domain for everything, for open marketing. Because the issue we had in HubSpot grew up in the marketing space. There we go. There was no standard around data formats and things like that. It doesn't go anywhere. But the other one, and I did not mean to go here, but I'm going to go here. It's called OpenGraph. I know the term was already taken, but it hasn't been used for like 15 years now for its original purpose. But what I think should exist in the world is right now, our information, all of us, nodes are in the social graph at Meta or the professional graph at LinkedIn. Both of which are actually relatively closed in actually very annoying ways. Like very, very closed, right? Especially LinkedIn. Especially LinkedIn. I personally believe that if it's my data, and if I would get utility out of it being open, I should be able to make my data open or publish it in whatever forms that I choose, as long as I have control over it as opt-in. So the idea is around OpenGraph that says, here's a standard, here's a way to publish it. I should be able to go to OpenGraph.org slash Dharmesh dot JSON and get it back. And it's like, here's your stuff, right? And I can choose along the way and people can write to it and I can prove. And there can be an entire system. And if I were to do that, I would do it as a... Like a public benefit, non-profit-y kind of thing, as this is a contribution to society. I wouldn't try to commercialize that. Have you looked at AdProto? What's that? AdProto.swyx [00:34:43]: It's the protocol behind Blue Sky. Okay. My good friend, Dan Abramov, who was the face of React for many, many years, now works there. And he actually did a talk that I can send you, which basically kind of tries to articulate what you just said. But he does, he loves doing these like really great analogies, which I think you'll like. Like, you know, a lot of our data is behind a handle, behind a domain. Yep. So he's like, all right, what if we flip that? What if it was like our handle and then the domain? Yep. So, and that's really like your data should belong to you. Yep. And I should not have to wait 30 days for my Twitter data to export. Yep.Dharmesh [00:35:19]: you should be able to at least be able to automate it or do like, yes, I should be able to plug it into an agentic thing. Yeah. Yes. I think we're... Because so much of our data is... Locked up. I think the trick here isn't that standard. It is getting the normies to care.swyx [00:35:37]: Yeah. Because normies don't care.Dharmesh [00:35:38]: That's true. But building on that, normies don't care. So, you know, privacy is a really hot topic and an easy word to use, but it's not a binary thing. Like there are use cases where, and we make these choices all the time, that I will trade, not all privacy, but I will trade some privacy for some productivity gain or some benefit to me that says, oh, I don't care about that particular data being online if it gives me this in return, or I don't mind sharing this information with this company.Alessio [00:36:02]: If I'm getting, you know, this in return, but that sort of should be my option. I think now with computer use, you can actually automate some of the exports. Yes. Like something we've been doing internally is like everybody exports their LinkedIn connections. Yep. And then internally, we kind of merge them together to see how we can connect our companies to customers or things like that.Dharmesh [00:36:21]: And not to pick on LinkedIn, but since we're talking about it, but they feel strongly enough on the, you know, do not take LinkedIn data that they will block even browser use kind of things or whatever. They go to great, great lengths, even to see patterns of usage. And it says, oh, there's no way you could have, you know, gotten that particular thing or whatever without, and it's, so it's, there's...swyx [00:36:42]: Wasn't there a Supreme Court case that they lost? Yeah.Dharmesh [00:36:45]: So the one they lost was around someone that was scraping public data that was on the public internet. And that particular company had not signed any terms of service or whatever. It's like, oh, I'm just taking data that's on, there was no, and so that's why they won. But now, you know, the question is around, can LinkedIn... I think they can. Like, when you use, as a user, you use LinkedIn, you are signing up for their terms of service. And if they say, well, this kind of use of your LinkedIn account that violates our terms of service, they can shut your account down, right? They can. And they, yeah, so, you know, we don't need to make this a discussion. By the way, I love the company, don't get me wrong. I'm an avid user of the product. You know, I've got... Yeah, I mean, you've got over a million followers on LinkedIn, I think. Yeah, I do. And I've known people there for a long, long time, right? And I have lots of respect. And I understand even where the mindset originally came from of this kind of members-first approach to, you know, a privacy-first. I sort of get that. But sometimes you sort of have to wonder, it's like, okay, well, that was 15, 20 years ago. There's likely some controlled ways to expose some data on some member's behalf and not just completely be a binary. It's like, no, thou shalt not have the data.swyx [00:37:54]: Well, just pay for sales navigator.Alessio [00:37:57]: Before we move to the next layer of instruction, anything else on MCP you mentioned? Let's move back and then I'll tie it back to MCPs.Dharmesh [00:38:05]: So I think the... Open this with agent. Okay, so I'll start with... Here's my kind of running thesis, is that as AI and agents evolve, which they're doing very, very quickly, we're going to look at them more and more. I don't like to anthropomorphize. We'll talk about why this is not that. Less as just like raw tools and more like teammates. They'll still be software. They should self-disclose as being software. I'm totally cool with that. But I think what's going to happen is that in the same way you might collaborate with a team member on Slack or Teams or whatever you use, you can imagine a series of agents that do specific things just like a team member might do, that you can delegate things to. You can collaborate. You can say, hey, can you take a look at this? Can you proofread that? Can you try this? You can... Whatever it happens to be. So I think it is... I will go so far as to say it's inevitable that we're going to have hybrid teams someday. And what I mean by hybrid teams... So back in the day, hybrid teams were, oh, well, you have some full-time employees and some contractors. Then it was like hybrid teams are some people that are in the office and some that are remote. That's the kind of form of hybrid. The next form of hybrid is like the carbon-based life forms and agents and AI and some form of software. So let's say we temporarily stipulate that I'm right about that over some time horizon that eventually we're going to have these kind of digitally hybrid teams. So if that's true, then the question you sort of ask yourself is that then what needs to exist in order for us to get the full value of that new model? It's like, okay, well... You sort of need to... It's like, okay, well, how do I... If I'm building a digital team, like, how do I... Just in the same way, if I'm interviewing for an engineer or a designer or a PM, whatever, it's like, well, that's why we have professional networks, right? It's like, oh, they have a presence on likely LinkedIn. I can go through that semi-structured, structured form, and I can see the experience of whatever, you know, self-disclosed. But, okay, well, agents are going to need that someday. And so I'm like, okay, well, this seems like a thread that's worth pulling on. That says, okay. So I... So agent.ai is out there. And it's LinkedIn for agents. It's LinkedIn for agents. It's a professional network for agents. And the more I pull on that thread, it's like, okay, well, if that's true, like, what happens, right? It's like, oh, well, they have a profile just like anyone else, just like a human would. It's going to be a graph underneath, just like a professional network would be. It's just that... And you can have its, you know, connections and follows, and agents should be able to post. That's maybe how they do release notes. Like, oh, I have this new version. Whatever they decide to post, it should just be able to... Behave as a node on the network of a professional network. As it turns out, the more I think about that and pull on that thread, the more and more things, like, start to make sense to me. So it may be more than just a pure professional network. So my original thought was, okay, well, it's a professional network and agents as they exist out there, which I think there's going to be more and more of, will kind of exist on this network and have the profile. But then, and this is always dangerous, I'm like, okay, I want to see a world where thousands of agents are out there in order for the... Because those digital employees, the digital workers don't exist yet in any meaningful way. And so then I'm like, oh, can I make that easier for, like... And so I have, as one does, it's like, oh, I'll build a low-code platform for building agents. How hard could that be, right? Like, very hard, as it turns out. But it's been fun. So now, agent.ai has 1.3 million users. 3,000 people have actually, you know, built some variation of an agent, sometimes just for their own personal productivity. About 1,000 of which have been published. And the reason this comes back to MCP for me, so imagine that and other networks, since I know agent.ai. So right now, we have an MCP server for agent.ai that exposes all the internally built agents that we have that do, like, super useful things. Like, you know, I have access to a Twitter API that I can subsidize the cost. And I can say, you know, if you're looking to build something for social media, these kinds of things, with a single API key, and it's all completely free right now, I'm funding it. That's a useful way for it to work. And then we have a developer to say, oh, I have this idea. I don't have to worry about open AI. I don't have to worry about, now, you know, this particular model is better. It has access to all the models with one key. And we proxy it kind of behind the scenes. And then expose it. So then we get this kind of community effect, right? That says, oh, well, someone else may have built an agent to do X. Like, I have an agent right now that I built for myself to do domain valuation for website domains because I'm obsessed with domains, right? And, like, there's no efficient market for domains. There's no Zillow for domains right now that tells you, oh, here are what houses in your neighborhood sold for. It's like, well, why doesn't that exist? We should be able to solve that problem. And, yes, you're still guessing. Fine. There should be some simple heuristic. So I built that. It's like, okay, well, let me go look for past transactions. You say, okay, I'm going to type in agent.ai, agent.com, whatever domain. What's it actually worth? I'm looking at buying it. It can go and say, oh, which is what it does. It's like, I'm going to go look at are there any published domain transactions recently that are similar, either use the same word, same top-level domain, whatever it is. And it comes back with an approximate value, and it comes back with its kind of rationale for why it picked the value and comparable transactions. Oh, by the way, this domain sold for published. Okay. So that agent now, let's say, existed on the web, on agent.ai. Then imagine someone else says, oh, you know, I want to build a brand-building agent for startups and entrepreneurs to come up with names for their startup. Like a common problem, every startup is like, ah, I don't know what to call it. And so they type in five random words that kind of define whatever their startup is. And you can do all manner of things, one of which is like, oh, well, I need to find the domain for it. What are possible choices? Now it's like, okay, well, it would be nice to know if there's an aftermarket price for it, if it's listed for sale. Awesome. Then imagine calling this valuation agent. It's like, okay, well, I want to find where the arbitrage is, where the agent valuation tool says this thing is worth $25,000. It's listed on GoDaddy for $5,000. It's close enough. Let's go do that. Right? And that's a kind of composition use case that in my future state. Thousands of agents on the network, all discoverable through something like MCP. And then you as a developer of agents have access to all these kind of Lego building blocks based on what you're trying to solve. Then you blend in orchestration, which is getting better and better with the reasoning models now. Just describe the problem that you have. Now, the next layer that we're all contending with is that how many tools can you actually give an LLM before the LLM breaks? That number used to be like 15 or 20 before you kind of started to vary dramatically. And so that's the thing I'm thinking about now. It's like, okay, if I want to... If I want to expose 1,000 of these agents to a given LLM, obviously I can't give it all 1,000. Is there some intermediate layer that says, based on your prompt, I'm going to make a best guess at which agents might be able to be helpful for this particular thing? Yeah.Alessio [00:44:37]: Yeah, like RAG for tools. Yep. I did build the Latent Space Researcher on agent.ai. Okay. Nice. Yeah, that seems like, you know, then there's going to be a Latent Space Scheduler. And then once I schedule a research, you know, and you build all of these things. By the way, my apologies for the user experience. You realize I'm an engineer. It's pretty good.swyx [00:44:56]: I think it's a normie-friendly thing. Yeah. That's your magic. HubSpot does the same thing.Alessio [00:45:01]: Yeah, just to like quickly run through it. You can basically create all these different steps. And these steps are like, you know, static versus like variable-driven things. How did you decide between this kind of like low-code-ish versus doing, you know, low-code with code backend versus like not exposing that at all? Any fun design decisions? Yeah. And this is, I think...Dharmesh [00:45:22]: I think lots of people are likely sitting in exactly my position right now, coming through the choosing between deterministic. Like if you're like in a business or building, you know, some sort of agentic thing, do you decide to do a deterministic thing? Or do you go non-deterministic and just let the alum handle it, right, with the reasoning models? The original idea and the reason I took the low-code stepwise, a very deterministic approach. A, the reasoning models did not exist at that time. That's thing number one. Thing number two is if you can get... If you know in your head... If you know in your head what the actual steps are to accomplish whatever goal, why would you leave that to chance? There's no upside. There's literally no upside. Just tell me, like, what steps do you need executed? So right now what I'm playing with... So one thing we haven't talked about yet, and people don't talk about UI and agents. Right now, the primary interaction model... Or they don't talk enough about it. I know some people have. But it's like, okay, so we're used to the chatbot back and forth. Fine. I get that. But I think we're going to move to a blend of... Some of those things are going to be synchronous as they are now. But some are going to be... Some are going to be async. It's just going to put it in a queue, just like... And this goes back to my... Man, I talk fast. But I have this... I only have one other speed. It's even faster. So imagine it's like if you're working... So back to my, oh, we're going to have these hybrid digital teams. Like, you would not go to a co-worker and say, I'm going to ask you to do this thing, and then sit there and wait for them to go do it. Like, that's not how the world works. So it's nice to be able to just, like, hand something off to someone. It's like, okay, well, maybe I expect a response in an hour or a day or something like that.Dharmesh [00:46:52]: In terms of when things need to happen. So the UI around agents. So if you look at the output of agent.ai agents right now, they are the simplest possible manifestation of a UI, right? That says, oh, we have inputs of, like, four different types. Like, we've got a dropdown, we've got multi-select, all the things. It's like back in HTML, the original HTML 1.0 days, right? Like, you're the smallest possible set of primitives for a UI. And it just says, okay, because we need to collect some information from the user, and then we go do steps and do things. And generate some output in HTML or markup are the two primary examples. So the thing I've been asking myself, if I keep going down that path. So people ask me, I get requests all the time. It's like, oh, can you make the UI sort of boring? I need to be able to do this, right? And if I keep pulling on that, it's like, okay, well, now I've built an entire UI builder thing. Where does this end? And so I think the right answer, and this is what I'm going to be backcoding once I get done here, is around injecting a code generation UI generation into, the agent.ai flow, right? As a builder, you're like, okay, I'm going to describe the thing that I want, much like you would do in a vibe coding world. But instead of generating the entire app, it's going to generate the UI that exists at some point in either that deterministic flow or something like that. It says, oh, here's the thing I'm trying to do. Go generate the UI for me. And I can go through some iterations. And what I think of it as a, so it's like, I'm going to generate the code, generate the code, tweak it, go through this kind of prompt style, like we do with vibe coding now. And at some point, I'm going to be happy with it. And I'm going to hit save. And that's going to become the action in that particular step. It's like a caching of the generated code that I can then, like incur any inference time costs. It's just the actual code at that point.Alessio [00:48:29]: Yeah, I invested in a company called E2B, which does code sandbox. And they powered the LM arena web arena. So it's basically the, just like you do LMS, like text to text, they do the same for like UI generation. So if you're asking a model, how do you do it? But yeah, I think that's kind of where.Dharmesh [00:48:45]: That's the thing I'm really fascinated by. So the early LLM, you know, we're understandably, but laughably bad at simple arithmetic, right? That's the thing like my wife, Normies would ask us, like, you call this AI, like it can't, my son would be like, it's just stupid. It can't even do like simple arithmetic. And then like we've discovered over time that, and there's a reason for this, right? It's like, it's a large, there's, you know, the word language is in there for a reason in terms of what it's been trained on. It's not meant to do math, but now it's like, okay, well, the fact that it has access to a Python interpreter that I can actually call at runtime, that solves an entire body of problems that it wasn't trained to do. And it's basically a form of delegation. And so the thought that's kind of rattling around in my head is that that's great. So it's, it's like took the arithmetic problem and took it first. Now, like anything that's solvable through a relatively concrete Python program, it's able to do a bunch of things that I couldn't do before. Can we get to the same place with UI? I don't know what the future of UI looks like in a agentic AI world, but maybe let the LLM handle it, but not in the classic sense. Maybe it generates it on the fly, or maybe we go through some iterations and hit cache or something like that. So it's a little bit more predictable. Uh, I don't know, but yeah.Alessio [00:49:48]: And especially when is the human supposed to intervene? So, especially if you're composing them, most of them should not have a UI because then they're just web hooking to somewhere else. I just want to touch back. I don't know if you have more comments on this.swyx [00:50:01]: I was just going to ask when you, you said you got, you're going to go back to code. What

Dan Abramov discusses how innovative platform BlueSky reimagines user data control and customization with its unique app protocol, and the potential it brings for the future of social media. Links https://atproto.com https://bsky.app/profile/atproto.com https://bsky.app/profile/danabra.mov https://overreacted.io https://danabra.mov https://github.com/gaearon https://justjavascript.com We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Dan Abramov.

Dan Abramov chats with us about getting hired at Meta, making the move to Bluesky, centralized vs decentralized, product work vs framework work, Bluesky's development and future, and how mean Dax is on the internet.Want to carry on the conversation? Join us in Discord.dan abramovdan (@danabra.mov) — Blueskydan 2 (@dan_abramov2) / Xoverreacted — A blog by Dan Abramovgaearon (dan)ExpoAaron FrancisTopics:(00:00) - So called "entertainers" (00:45) - Hi Dan (02:11) - Hiring on a global scale (05:02) - What's the process like for getting hired by Meta? (09:09) - How has it been at Bluesky? (19:06) - How do you feel about centralized vs decentralized? (23:46) - How do you enjoy product work vs framework work? (27:53) - What's the next milestone for Bluesky? (34:19) - Using Expo (43:11) - How does Facebook think about React? (50:19) - Is the internet too mean?

Meet  Rachel Lee Nabors

We welcome on The React Guy, Dan Abramov, to talk about his time working on the React core team, demystifying React Server Components, how React has evolved, and more! Links https://danabra.mov https://twitter.com/danabramov2 https://bsky.app/profile/danabra.mov https://twitter.com/danabramov https://overreacted.io https://www.youtube.com/channel/UCVhEjiCLn2v4MEt3Q4T2iaA We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guest: Dan Abramov.

This week we have Dan Abramov, a core team member of React. We talk about his latest work on Bluesky, a decentralized social network. We also go into many react topics, including the history of server components, the new React compiler, and the future of React. https://twitter.com/dan_abramov2 https://danabra.mov/ https://overreacted.io/ https://bsky.app/ Episode sponsored By CodeCrafters (https://codecrafters.io/devtoolsfm) 40% Discount! Become a paid subscriber our patreon, spotify, or apple podcasts for the full episode. https://www.patreon.com/devtoolsfm https://podcasters.spotify.com/pod/show/devtoolsfm/subscribe https://podcasts.apple.com/us/podcast/devtools-fm/id1566647758 https://www.youtube.com/@devtoolsfm/membership

The week Amal & guest co-host Eric Clemmons talk to Dan Abramov all about React Server Components. We learn about why they were created, what problems they solve & how they work to improve application performance. We also dive into the rollout and current support status, the origin story, the community response & walk through the 10+ years of React history which have forever shifted the world of web development.

The week Amal & guest co-host Eric Clemmons talk to Dan Abramov all about React Server Components. We learn about why they were created, what problems they solve & how they work to improve application performance. We also dive into the rollout and current support status, the origin story, the community response & walk through the 10+ years of React history which have forever shifted the world of web development.

We welcome on The React Guy, Dan Abramov, to talk about his time working on the React core team, demystifying React Server Components, how React has evolved, and more! Links https://danabra.mov https://twitter.com/danabramov2 https://bsky.app/profile/danabra.mov https://twitter.com/danabramov https://overreacted.io https://www.youtube.com/channel/UCVhEjiCLn2v4MEt3Q4T2iaA We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guest: Dan Abramov.

### Tematy 0:00 Intro 0:53 Typescript 5.2 - https://devblogs.microsoft.com/typescript/announcing-typescript-5-2/ 6:34 NextUI 2.1 - https://nextui.org/blog/v2.1.0 8:27 Prisma 5.2 - https://github.com/prisma/prisma/releases/tag/5.2.0 10:19 Tamagui 1.57.3 - https://github.com/tamagui/tamagui/releases 13:00 Nuxt 3.7 - https://github.com/nuxt/nuxt/releases/tag/v3.7.0 15:49 react-native-bootsplash 5.0.2 - https://github.com/zoontek/react-native-bootsplash/releases 18:21 editor.js 2.28 - https://github.com/codex-team/editor.js/releases/tag/v2.28.0 19:23 Gatsby 5.12 - https://github.com/gatsbyjs/gatsby/releases/tag/gatsby%405.12.0 21:30 Dan Abramov w bluesky - https://twitter.com/dan_abramov/status/1695566446007386214 23:14 You don't need Lodash / Underscore 6.13 - https://github.com/you-dont-need/You-Dont-Need-Lodash-Underscore/tree/v6.13.0 25:05 Ideal viewport doesn't exist - https://viewports.fyi/ 27:39 Outro

In questo episodio speciale, faccio un recap dei talk che ho seguito al WeAreDevelopers di Berlino, luglio 2023. Ci troverete Tim Berners-Lee, John Romero, Erick Wendel, Matt Butcher, Lorenzo Pieri, Anuradha Kumari, Brenda Romero, Stefan Baumgartner, Giorgio Boa e Dan Abramov. È molto più lungo dei normali buongiornissimi, non contiene tech news, è un formato nuovo che sperimento, fatemi sapere se piace! #wearedevs #opensource #conference #developers === Podcast Anchor - https://anchor.fm/edodusi Spotify - https://open.spotify.com/show/4B2I1RTHTS5YkbCYfLCveU Apple Podcasts - https://podcasts.apple.com/us/podcast/buongiorno-da-edo/id1641061765 Google Podcasts - https://podcasts.google.com/feed/aHR0cHM6Ly9hbmNob3IuZm0vcy9iMWJmNDhhMC9wb2RjYXN0L3Jzcw Amazon Music - https://music.amazon.it/podcasts/5f724c1e-f318-4c40-9c1b-34abfe2c9911/buongiorno-da-edo = RSS - https://anchor.fm/s/b1bf48a0/podcast/rss --- Send in a voice message: https://podcasters.spotify.com/pod/show/edodusi/message

### Tematy * Zmiany organizacyjne i start nowego sezonu * Dan Abramov opuszcza Meta - https://twitter.com/dan_abramov/status/1682029195843739649 * Astro 2.9 - https://astro.build/blog/astro-290/ * Bun 0.7 - https://bun.sh/blog/bun-v0.7.0 * Yoga 2.0 - https://github.com/facebook/yoga/releases/tag/v2.0.0 * Remix 1.19 - https://github.com/remix-run/remix/releases/tag/remix@1.19.0 * Solito 4.0 - https://solito.dev/v4 * Node 20.5.0 - https://nodejs.org/en/blog/release/v20.5.0 * Storybook 7.1 - https://storybook.js.org/blog/storybook-7-1/ * Valibot - https://www.builder.io/blog/introducing-valibot * Typechat - https://microsoft.github.io/TypeChat/blog/introducing-typechat/

News:Paige: Dan Abramov is leaving Meta: https://twitter.com/dan_abramov/status/1682029195843739649 Jack:  GitHub Copilot Chat is now available for enterprise dev teams: https://github.blog/2023-07-20-github-copilot-chat-beta-now-available-for-every-organization/ TJ: Zero-JavaScript page transitions coming to Astro https://twitter.com/astrodotbuild/status/1683514985115426817, https://docs.astro.build/en/guides/view-transitions/ What Makes Me Happy this Week:Paige - The Witcher Season 3 on Netflix https://www.netflix.com/title/80189685 Jack - Star Trek Strange New Worlds on Paramount+ https://www.imdb.com/title/tt12327578/ TJ - Pokemon Sleep https://www.pokemon.com/us/app/pokemon-sleep/ Join Us:Blue Collar Coder on YouTube: https://www.youtube.com/channel/UC6vRUjYqDuoUsYsku86LrswBlue Collar Coder on Discord: https://discord.com/invite/ddMZFtTDa5

Kyle Simpson is a Human-Centric Technologist, Author of "You Don't Know JS". He joins the show to talk about "Socket Supply", building "local first" web apps, and what his employer in Socket Supply is doing in this space. They also talk about building native desktop & mobile apps. SponsorsChuck's Resume TemplateDeveloper Book Club Become a Top 1% Dev with a Top End Devs MembershipLinksSocket Supplysocket prerelease demoSocialsKyle SimpsonGitHub: Kyle Simpson LinkedIn: Kyle (getify) Simpson PicksAJ - Tears of the KingdomAJ - LMNT (Citrus)AJ - BNNACharles - Ark Nova | Board GameCharles - I Am Not a Serial Killer (John Cleaver, #1) by Dan WellsCharles - Seven Languages in Seven WeeksDan - "React from Another Dimension" by Dan Abramov at #RemixConf 2023Kyle - Natalie PriceKyle - City of Kyle, Texas - Official WebsiteSupport this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacy

In diesem CTO-Special reden wir mit Andre Biel, CTO und Co-Founder der Agentur Nice Outside. Er gibt uns spannende Einblicke in seinen Werdegang und die Projekte seiner Agentur, die ihrem Kunden Mill dabei hilft, die Welt ein bisschen besser zu machen. Wir erfahren außerdem, wie das kleine Team es ermöglicht, sich neben der engen Zusammenarbeit mit seinen Kund:innen auch auf die Entwicklung eigener Produkte zu konzentrieren.Fabi platziert mit dem Talk "React from Another Dimension" von Dan Abramov ausnahmsweise einen Pick of the Day in dieser CTO-Folge.Schreibt uns! Schickt uns eure Themenwünsche und euer Feedback: podcast@programmier.barFolgt uns! Bleibt auf dem Laufenden über zukünftige Folgen und virtuelle Meetups und beteiligt euch an Community-Diskussionen. TwitterInstagramFacebookMeetupYouTubeMusik: Hanimo

Dan Abramov is a Front-end developer at Facebook and Joe Savona is a User Interface engineer at Facebook. They join the show to talk about React Server Components. They begin by explaining what it is, how it's implemented, the services it offers to the clients, and many more. On YouTubeReact Server Components: Part 2- JSJ 583SponsorsChuck's Resume Template Developer Book ClubBecome a Top 1% Dev with a Top End Devs MembershipSocialsDan Abramov GitHub: gaearonTwitter: @dan_abramovJoe SavonaLinkedIn: Joseph Savona josephsavona.comTwitter: @en_JSPicksCharles - Iberian Gauge Dan Abramov - Watch BEEF | Netflix Official SiteDan Abramov - The White LotusDan Shappir - Go speak at conferencesJoe - Diagonals Tejas - Watch BEEF | Netflix Official SiteTejas - BlueskyTejas - The Molecule of MoreSupport this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacy

Hello, Kent! My name is Petar and I'm from Bulgaria. I'd like to ask your opinion on this question: Do you think that the "Epic Stack" is relevant for people who are relatively new to web development? Here's some information about me: my interest in web development started about a year ago. Currently, I feel really confident in HTML, CSS, JavaScript, React, and TypeScript. I have read a lot of books and completed numerous courses on these topics, including the HTML course on web.dev, the CSS course by Josh Comeau, the books by Nicholas Zakas on JavaScript, the JS course by Dan Abramov, Epic React, and the "Learning TypeScript" book by Josh Goldberg. I also purchased your testing course but haven't had the chance to complete it yet. Currently, I don't have a job, but I'm planning to land one soon.My question to you, again, is whether you think sticking with the Epic Stack would be beneficial for me, or if it's better to focus on already established technologies in the market such as Redux, Next.js, etc. I just want to hear your honest opinion, even if it may be (or become) wrong. The Epic Stack (blog post) The Epic Stack (announcement talk) epicweb-dev/epic-stack (github) Is Epic Stack beneficial for new developers?

Dan Abramov is a Front-end developer at Facebook and Joe Savona is a User Interface engineer at Facebook. They join the show to talk about React Server Components. They begin by explaining what it is, how it's implemented, the services it offers to the clients, and many more. On YouTubeReact Server Components: Part 1 - JSJ 582SponsorsChuck's Resume Template Raygun - Application Monitoring For Web & Mobile AppsBecome a Top 1% Dev with a Top End Devs MembershipSocialsDan Abramov GitHub: gaearonTwitter: @dan_abramovJoe SavonaLinkedIn: Joseph Savona josephsavona.comTwitter: @en_JSSupport this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacy

Dan Abramov & Joe Savona from the React Team join Jerod & Nick for a wide-ranging discussion about React's place in the frontend ecosystem. We cover everything from React competing with React, their responses to SPA fatigue and recent criticisms, to Server Components and the future of the framework.

Dan Abramov & Joe Savona from the React Team join Jerod & Nick for a wide-ranging discussion about React's place in the frontend ecosystem. We cover everything from React competing with React, their responses to SPA fatigue and recent criticisms, to Server Components and the future of the framework.

Resources for this episode:Go to teamsimmer.com and use the coupon code "DEVIATE" for 10% off of any individual course purchases.Javascript course by Dan Abramov: https://justjavascript.com/Connect with Doug Hall Follow Doug Hall on TwitterDoug Hall's medium (his articles are top-notch)Connect with Julien CoquetFollow Julien Coquet on TwitterJulien Coquet's blog

Welcome to The Nonlinear Library, where we use Text-to-Speech software to convert the best writing from the Rationalist and EA communities into audio. This is: Rationality-related things I don't know as of 2023, published by Adam Zerner on February 11, 2023 on LessWrong. One of the blog posts I'm most fond of is Things I Don't Know as of 2018. It's by Dan Abramov, one of the more prominent people in the world of front-end web development. He goes through a bunch of relatively basic programming-related things that he doesn't understand, like unix commands and low-level languages. I'd like to do something similar, but for rationality-related things. Why? For fun. To normalize the idea that no one's perfect. It'll make it easier to address these knowledge gaps. Or maybe just more likely that I actualy do so. Here's the list:[1] Simulcra. I spend some time going through the posts and it's one of those things that just never manages to click with me. Blockchain. I guess the thing that I don't understand here is the hype. I get that it's a basically a database that can't be editted and I've read through articles talking about the use cases, but it's been around for a while now and doesn't seem to have been that game changing. Yet there are smart people who are super excited about it and I suspect that there are things I am failing to appreciate, regardless of whether their excitement is justified. Morality. To me it seems like rationality can tell you how to achieve your goals but not what (terminal) goals to pick. Arguments that try to tell you what terminal goals to pick have just never made sense to me. Maybe there's something I'm missing though. Quantum physics. I skipped/lightly skimmed the sequence posts on this. Seemed high effort and not particularly important. Well, it is cool to understand how reality works at the most fundamental level. Hm. I would be interested in a going through some sort of lower effort bigger picture material on quantum physics. I spent some time messing around with that sort of stuff like 13 years ago but all that stuck is some vague notion that reality is (fundamentally?) probabilistic and weird. Evolution. I get that at a micro-level, if something makes an organism more likely to reproduce it will in fact, err, spread the genes. And then that happens again and again and again. And since mutations are a thing organisms basically get to try new stuff out and the stuff that works sticks. I guess that's probably the big idea but I don't know much beyond it and remember being confused when I initially skimmed through the The Simple Math of Evolution sequence. Evolutionary psychology. I hear people make arguments like "X was important to our hunter-gatherer ancestors and so we still find ourselves motivated by it/to do it today because evolution is slow". X might be consuming calories when available, for example. There's gotta be more to evolutionary psychology than that sort of reasoning, but I don't know what the "more" is. Bayes math. I actually think I have a pretty good understanding of the big picture ideas. I wouldn't be able crunch numbers or do things that they teach you in a stats course though.[2] Nor do I understand the stuff about log odds and bits of evidence. I'd have to really sit down, think hard about it, and spend some time practicing using it. Solomonoff induction. I never took the time to understand it or related ideas. Occam's razor. Is it saying anything other than P(A) >= P(A & B)?[3] Moloch. I enjoyed Meditations on Moloch and found it to be thought provoking. I'm not sure that I really understand what Moloch actually is/represents though. I struggle a little with the abstractness of it. Double crux. This is another one of those "maybe I actually understand it but it feels like there's something I'm missing" things. I get that a crux is something that would change your mind. And yeah, if you're arguing with someone and you find a crux that would make you agree with them if vic...

In this episode of the React Native Show, Łukasz Chludziński (https://twitter.com/loginlukasza) and Ola Desmurs-Linczewska (https://twitter.com/p_syche_) discuss state management in React Native apps. As there's no magical formula for handling it, don't expect straightforward direction or easy answers from this episode. Instead, get ready for: - an overview of state management in React Native & React apps - a deep-dive into state management libraries based on different philosophies, including Redux, MobX, XState, Jotai, and React Query - an insight into how Ola compared these libraries when writing “Simplifying State Management in React Native” - a few words of the book-writing process as seen by Ola You can find Ola's book on Amazon (https://www.amazon.com/Simplifying-State-Management-React-Native/dp/1803235039) and GitHub (https://github.com/PacktPublishing/Simplifying-State-Management-in-React-Native). New state management libraries keep appearing, so choosing the one that best suits your project and taste may be challenging. We hope to help you make this decision and get a broader perspective on state management in React Native by having Ola and Łukasz discuss the following aspects of a few libraries: - the people behind them - the category they belong, e.g. flux vs. proxy vs. atom, mutable vs. immutable, battle-tested vs. experimental - how they work and what it means to the developer Resources that Ola and Łukasz mentioned in this episode: ➡️ Dan Abramov's Fundamentals of Redux Course https://egghead.io/courses/fundamentals-of-redux-course-from-dan-abramov-bd5cc867 ➡️ Michel Weststrate's courses on Mobx https://egghead.io/courses/manage-complex-state-in-react-apps-with-mobx, https://egghead.io/courses/manage-application-state-with-mobx-state-tree ➡️ State explosion https://statecharts.dev/state-machine-state-explosion.html ➡️ Daishi Kato's course on Mobx https://egghead.io/courses/manage-application-state-with-jotai-atoms-2c3a29f0 ➡️ Dominik Dorfmeister's blog about React Query https://tkdodo.eu/blog/practical-react-query Enjoy the episode, and don't forget to subscribe to our channel for more content like this! How about boosting performance of your React Native app with the help of our ultimate guide? https://www.callstack.com/campaigns/download-the-ultimate-guide-to-react-native-optimization?utm_campaign=RN_Performance&utm_source=youtube&utm_medium=social&utm_content=State_Management_podcast If you feel like learning more about state management with Redux, check out our training: https://www.callstack.com/training/state-management-with-redux?utm_campaign=Podcast&utm_source=youtube&utm_medium=social&utm_content=State_Management_podcast_promo_1 Need help with your React Native project? Give us a shout! https://www.callstack.com/services?utm_campaign=Podcast&utm_source=youtube&utm_medium=social&utm_content=State_Management_podcast_promo_1 Check out other episodes of our podcast: https://www.callstack.com/podcast-react-native-show?utm_campaign=Podcast&utm_source=youtube&utm_medium=social&utm_content=State_Management_podcast_promo_1 Do you want to work with us? We're looking for Senior React Native developers! Check out the details and apply here: https://www.callstack.com/senior-react-native-developer?utm_campaign=Podcast&utm_source=youtube&utm_medium=social&utm_content=State_Management_podcast_promo_1 Follow us on Twitter to stay up to date with upcoming episodes: https://twitter.com/callstackio

What did we talk about In this episode, we're talking about “The Wrong Abstraction" by Sandi Metz. We go against years of programming best practices and propose copy-pasting code….sometimes. Along the way, we mention "AHA Programming" by Kent Dodds and "The Wet Codebase" by Dan Abramov, and generally rail against speculative generality. If you listen long enough, you'll hear Joe mouth-coding something called a “bloom filter” and Evan makes an offer you can't refuse.

Listen to Keycuts: https://www.thekeycuts.com/dear-analyst-50-walking-through-a-vba-script-for-trading-billions-of-dollars-worth-of-derivatives-with-shawn-wang/This little podcast/newsletter started as a little experiment last year. I never thought I would make it to episode number 50, but here we are! Thank you to the few of you out there who listen/read my ramblings about spreadsheets.I decided to give you all a break and invite my first guest to the podcast: Shawn Wang (aka @swyx). Shawn currently works in developer experience at AWS, but has a really diverse background (check out his site to learn more). I've mentioned Shawn in previous episodes (25 and 49) and was honored he agreed to be the first guest on Dear Analyst. We dig into a variety of topics including negotiating your salary, Javascript frameworks, creating, and whatever else tickled my fancy.Becoming a JediI was particularly interested in a 4,000-line Excel VBA script he wrote while working as a trader in a previous job. You can learn a lot about someone from looking at their code, and that's exactly what we did during this episode. Shawn was kind enough to share a VBA script he built back in 2012 for his team to price billions dollars worth of derivatives. I honestly don't understand 90% of this script, but Shawn walked through a lot of the derivative concepts he had to translate into this VBA script. You can see some of his thoughts about this script in the Tweet thread below:https://twitter.com/swyx/status/1327041894853922816?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1327041894853922816%7Ctwgr%5Ef93cc6228794ba7b8cdb0018993df1a13c16d4e9%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fwww.thekeycuts.com%2Fdear-analyst-50-walking-through-a-vba-script-for-trading-billions-of-dollars-worth-of-derivatives-with-shawn-wang%2FI think it's amazing that his bank relied on traders using this homegrown script to price everything from interest rates to mortgages.One of the main takeaways from our walkthrough of this script is that the code isn't pretty. Shawn had a problem that he needed to solve, picked up the tool that could solve that problem, and started hacking away at the solution. Shawn shared a story from his senior trader at the time on building tools for yourself:One of the rights of passage for becoming a Jedi is building a light saber. Once you have the light saber, you just use it, and stop building it.—Shawn WangFor the benefit of other traders out there, Shawn also believes in learning in public. Releasing this script is just one example of that. By producing content and acknowledging gaps in your knowledge, you'll learn faster than being a “lurker,” as Shawn puts it.No-code is a lieWe talked a bit about an article he wrote called No code is a lie, and how programmers sometimes need to get over themselves. Programmers may get caught up in the style of their code, but the end-user just cares about whether the thing works and solves their problem.After finance, Shawn moved from Excel and VBA scripts to Haskell, Python, and Javascript. He still has a soft spot for Excel, however. With Excel, you have your database and user interface right in front of you. This not only gives people an easy way to create, but makes creation more inclusive.Excel is creation over code. I don't define myself as coding, I define myself creating.—Shawn WangTaming the Javascript communityShawn got really involved with the ReactJS community and eventually became one of the moderators of the subreddit after Dan Abramov asked him to help with the community.Shawn recently stepped down from moderating the community as he started coding with Svelte, another Javascript framework. In terms of moving from community to community, Shawn made an interesting point on encouraging renewal in communities. Mods, leaders, managers, and political figures should have limited terms to encourage innovation and different perspectives. Plus, I think when you are new to a community, you get a chance to learn from the ground up from others who are more experienced. Once you're at the top, it's time to find a new place and rinse, lather, and repeat.Getting $50,000 added to his salaryWe both talked about our interests in Haseeb Qureshi's blog posts on salary negotiation. If you were a developer 4-5 years ago, you most likely came across Haseeb's posts because it shows step-by-step how Haseeb went from finishing a coding bootcamp to getting a 6-figure salary at Airbnb.Shawn also cited Patrick McKenzie's post and Josh Doody's guide on salary negotiation as good resources. I remember when I was interviewing, I relied on Haseeb's concepts to get me through the negotiation process. Long story short? You should always negotiate.The fallacy of measuring developer advocacy programsI've read various blog posts and listened to podcasts about this subject, so figured I'd ask Shawn what he thinks about measuring developer advocacy efforts since he works at one of the largest companies on the planet. Rest assured! His team has not come up with the perfect formula either. Guess where they keep track of all their speaking engagements and content? You guessed it: in a spreadsheet.Shawn mentioned one startup called Orbit that is trying to crack this nut. They dub themselves as the “operating system of vibrant developer communities.” Their orbit model is a bit cheesy but does attempt to quantify someone's engagement in a community: Love is a member's level of engagement and activity in the community. Reach is a measure of a community member's sphere of influence. Gravity is the attractive force of a community that acts to retain existing members and attract new ones. Orbit levels are a practical tool for member segmentation and used to design different programs for each level of the community. I'm currently working on a similar program and commend them on tackling this problem :).Other projectsShawn finally shared what he's working on these days: Wrote a book called Coding Career Handbook and maintaining a community for that Growing the Svelte society on Twitter Angel investing Scouting for a VC fund Writing on his blog He talked about being disappointed in his writing and I completely agree with that sentiment. Writing these posts definitely take time but I always feel like more time can be put into the writing to make it more clear, structured, and precise. Having said that, I'll take a page out of Shawn's notebook and #LearnInPublic !

Fredrik chats with Chris Ferdinandi about vanilla Javascript, the pros and cons of libraries, the state of web components, and a lot more. Chris tells us about how and why he became the vanilla Javascript guy, and why he dislikes vanilla-js.com. We talk about why we as web developers pick up so many libraries, and why we often seem to use really large tools on really small problems. We wonder if different types of developers should think in different ways about libraries. Chris also talks about how different groups attending his courses approach the subject of vanilla Javascript in different ways, and of course a bit about where he hopes and thinks web development might be heading in the next few years. Thank you Cloudnet for sponsoring our VPS! Comments, questions or tips? We are @kodsnack, @tobiashieta, @oferlund and @bjoreman on Twitter, have a page on Facebook and can be emailed at info@kodsnack.se if you want to write longer. We read everything we receive. If you enjoy Kodsnack we would love a review in iTunes! You can also support the podcast by buying us a coffee (or two!) through Ko-fi. Links Chris Ferdinandi Vanilla Javascript Vanilla JS podcast - Chris' podcast Chris' newsletter gomakethings.com Jquery vanilla-js.com - a joke which may not have stood the test of time Library or framework? ES 5 Post from Dave Rupert about ripping Jquery out of Wordpress Chris' e-books vanillajsguides.com Chris' workshops DOM diffing Dan Abramov Redux Dan Abramov’s course on Redux Vue Svelte Astro The stage 3 API for passing in a string of HTML and sanitizing it JSX Details and summary elements ARIA Web components Chris' course on web components Shadow DOM Constructable stylesheets Titles I help people learn vanilla Javascript Largely because of Jquery The vanilla JS guy The phrase “at scale” gets thrown in there Trying to hang a painting on your wall with a sledgehammer Perfect for a very narrow and specific set of use cases Just throwing one more of them in The pain of their own tech choices Teaching engineers how to find their next job I didn’t realize you could do so much without a library Underneath your library Without punishing the user Mostly HTML and a little bit of Javascript Waiting for the build to compile You never have to feel bored

Dan Abramov has an updated Beta React Effects Guide. In this episode we go through and see what the designers of React think about effects and how to correctly use them in React 18 and we take a look at user reactions.Beta React Effects GuideTwitter React Show

In this Coffee Talk Aleksandra Desmurs-Linczewska (https://www.callstack.com/team/aleksandra-desmurs-linczewska) and Łukasz Chludziński (https://www.callstack.com/team/lukasz-chludzinski) provide a lot of ideas for staying up to date with the community news. They discuss the most valuable resources such as newsletters, top Twitter accounts, blogs, podcasts, conferences, GitHub and release notes: Newsletters: The React Native Newsletter, Tyler's (ui.dev) newsletter, JavaScript Weekly, Cassidy Williams's newsletter Twitter accounts: official React and React Native accounts Callstack, Remix, Next, Vercel accounts of people who are well-known in the community: Angie Jones (@techgirl1908), Sara Vieira (@NikkitaFTW), Kadi Kraman (@kadikraman), Evan Bacon (@Baconbrix), Dan Abramov (@dan_abramov), Lorenzo Sciandra (@Kelset), Rick Hanloni (@rickhanlonii), Ryan Cavanaugh (@SeaRyanC), Cassidy Williams (@cassidoo), Michal Pierzchala (@thymikee), Wes Bos (@wesbos), Jamon Holmgren (@jamonholmgren), Kent C Dodds (@kentcdodds), Michael Jackson (@mjackson), Ryan Florence (@ryanflorence), Sebastien Lorber (@sebastienlorber) Conferences: React Native EU https://hubs.li/Q01bt5WQ0 React Summit https://reactsummit.com/ Chain React https://cr.infinite.red/ Podcasts: The React Native Show https://hubs.li/Q01bt7gK0 React Native Radio https://reactnativeradio.com/ DevSpresso JS News https://bit.ly/3LnLYmC YouTube channels: Ben Awad https://www.youtube.com/c/BenAwad97 William Candilion https://www.youtube.com/c/wcandillon Fireship.io https://www.youtube.com/c/Fireship The overview of resources will come in handy for every React Native developer regardless of whether you have much experience or you are new to the React Native world.

Sam and Ryan talk about the new useEvent RFC, and how useEvent lets you extract event logic from your side effects. They also read and discuss Dan Abramov's recent Twitter thread on how useEvent addresses the problems people are encountering with React 18's Strict Mode behavior around running effects twice on mount.Topics include:0:00 - Intro0:34 - How useEvent relates to the changes to Strict Mode in React 1812:04 - Dan Abramov's thread on how useEvent relates to “fixing” useEffect37:37 - What's the correct mental model for useEvent53:55 - How useEvent is different from useCallbackLinks:useEvent RFCS in the React repoDan Abramov's thread on how useEvent relates to “fixing” useEffectDan's RFC comment on why useEvent is not just a “nicer” useCallback

Eric Anderson (@ericmander) has a conversation with Yury Selivanov (@1st1), the co-founder of EdgeDB. EdgeDB is the world's first “graph-relational database.” It's a term coined specifically for this new type of database, designed to ease the pain of dealing with the usual relational and NoSQL models. And no, EdgeDB is NOT a graph database! In this episode we discuss: A glitch at EdgeDB's Matrix-inspired launch event Origin of the term and design philosophy, “graph-relational” What to know about becoming a Python core developer How EdgeDB's next-gen query language compares to GraphQL and SQL Links: EdgeDB magicstack uvloop People mentioned: Elvis Pranskevichus (@elprans) Colin McDonnell (@colinhacks) Victor Petrovykh (Github: @vpetrovykh) Dan Abramov (@dan_abramov) Brett Cannon (@brettsky) Daniel Levine (@daniel_levine) Other episodes: Hasura with Tanmai Gopal Dgraph with Manish Jain

Happy New Year! Sam and Ryan are back from the holidays, talking about transitive dependencies in node and the browser in the context of Ryan's next-s3-upload library. They also discuss a SuspenseAfterInitialRender component, speed vs. testability in services and monoliths, and a thought-provoking tweet from Dan Abramov on tests vs. source code.Topics include:0:00 - Would you want tests or source code11:20 - Suspense, SuspenseAfterInitialRender, unstable_avoidThisFallback19:05 - Value of having a reproducible test suite for a dynamic app22:12 - Speed vs. testability of services vs. monolith26:24 - How to import different versions of dependencies in libraries. Module resolution in node vs. browser.Links:Dan Abramov's tweet on tests vs. source codeA Quick Intro to Suspense in React 18React PR for unstable_avoidThisFallbackHow Serverless Saved Money on My Heating Billnext-s3-upload, Ryan's Next.js package for uploading images

This podcast involves two live demos, you can catch up on the YouTube verison here: https://youtu.be/T3K_DrgLPXMLinks Builder.io https://www.builder.io/ PartyTown https://github.com/BuilderIO/partytown Qwik https://github.com/builderio/qwik https://dev.to/mhevery/a-first-look-at-qwik-the-html-first-framework-af Timestamps [00:01:53] Misko Intro  [00:03:50] Builder.io  [00:08:31] PartyTown  [00:11:41] Web Workers vs Service Workers vs Atomics  [00:15:02] PartyTown Demo  [00:21:46] Qwik and Resumable vs Replayable Frameworks  [00:25:40] Qwik vs React - the curse of Closures  [00:27:32] Qwik Demo  [00:42:40] Qwik Compiler Optimizations  [00:53:00] Qwik Questions  [01:00:05] Qwik vs Islands Architecture  [01:02:59] Qwik Event Pooling  [01:05:57] Qwik Conclusions  [01:13:40] Qwik vs Angular Ivy  [01:16:58] TED Talk: Metabolic Health  Transcript [00:00:00] Misko Hevery: So the thing that I've learned from Angular.js days is make it really palatable, right. And solve a problem that nobody else has. Doing yet another framework in this state of our world would be complete suicide cause like it's just a different syntax for the same thing, right? So you need to be solving a problem that the other ones cannot solve. [00:00:22] swyx: The following is my conversation with Misko Hevery, former creator of Angular.js, and now CTO of Builder.io and creator of the Qwik framework. I often find that people with this level of seniority and accomplishment become jaded and imagine themselves above getting their hands dirty in code.  [00:00:39] Misko is the furthest you could possibly get, having left Google and immediately starting work on the biggest problem he sees with the state of web development today, which is that most apps or most sites don't get a hundred out of a hundred on their lighthouse scores. We talked about how Builder.io gives users far more flexibility than any other headless CMS and then we go into the two main ways that Misko wants to change web performance forever: offloading third-party scripts with PartyTown, and then creating a resumable framework with Qwik. Finally, we close off with a Ted Talk from Mishko on metabolic health. Overall I'm incredibly inspired by Misko's mission, where he wants to see a world with lighter websites and lighter bodies. [00:01:23] I hope you enjoy these long form conversations. I'm trying to produce with amazing developers. I don't have a name for it, and I don't know what the plan is. I just know that I really enjoy it. And the feedback has been really great. I'm still figuring out the production process and trying to balance it with my other commitments so any tips are welcome. If you liked this, share it with a friend. If you have requests for other guests, pack them on social media. I'd like to basically make this a space where passionate builders and doers can talk about their craft and where things are going. So here's the interview.  [00:01:53] Misko Intro  [00:01:53] swyx: Basically I try to start cold, [00:01:55] assuming that people already know who you are. Essentially you and I met at Zadar and, I've heard of you for the longest time. I've heard you on a couple of podcasts, but I haven't been in the Angular world. And now you're no longer in the Angular world.  [00:02:11] Misko Hevery: The child has graduated out of college. It's at a time.  [00:02:15] swyx: My favorite discovery about you actually is that you have non-stop dad jokes. Um, we were walking home from like one of the dinners and that you're just like going, oh, that's amazing. [00:02:27] Yes. Yeah.  [00:02:28] Misko Hevery: Yes. Um, most people cringe. I find it that it helps break that. It does and you know, the Dad jokes, so they're completely innocent. So you don't have to worry. I also have a good collection of, uh, computer jokes that only computer programmers get.  [00:02:47] swyx: Okay. Hit me with one.  [00:02:48] Misko Hevery: Um, "How do you measure functions?" [00:02:51] swyx: How do I measure functions? And the boring answer is arity,  [00:02:55] Misko Hevery: and that's a good one! "In Para-Meters." Uh, [00:03:03] swyx: yeah. So for anyone listening like our entire journey back was like that it just like the whole group just groaning. No, that's really good. Okay. Well, it's really good to connect. I'm interested in what you're doing at Builder. You left Google to be CTO of Builder. I assumed that I knew what it was, from the name, it actually is a headless CMS and we can talk about that because I used to work at Netlify and we used to be very good friends with all the headless CMSes. And then we can talk about Qwik. How's that ? [00:03:34] Misko Hevery: I can jump into that. Sorry. My voice is a little raspy. I just got over a regular cold, like the regular cold ceilings  [00:03:42] swyx: conference call, right. I dunno, I, I had it for a week and I only just got over it. [00:03:46] Misko Hevery: It was from the conference. Maybe it wasn't from the other trip I made anyways.  [00:03:50] Builder.io  [00:03:50] Misko Hevery: So let's talk about Builder. So Builder is what we call a headless visual CMS. Uh, I did not know any of that stuff. Would've meant. So I'm going to break it down because I assume that the audience might not know either. [00:04:01] So CMS means it's a content management system. What it means is that non-developers, uh, like typically a marketing department think like Gap. Gap needs to update .... If you're showing stuff on the screen, you can go to Everlane. Everlane is one of our customers. Okay. And so in Everlane case, the marketing department wants to change the content all the time. [00:04:22] Right? They want to change the sales, what things are on the top, what product that they want to feature, et cetera. And, um, this is typically done through a content management system. And the way this is typically done is that it's like a glorified spreadsheet where the engineering department makes a content. [00:04:39] And then it gives essentially key value pairs to the marketing. So the marketing person can change the text, maybe the image, but if the developer didn't think that the marketing person might want to change the color or font size, then there is no hook for it, and the marketing person can't do that. [00:04:54] Certainly marketing person won't be able to add new columns, decide that this is better shown in three columns versus two column mode or show a button or add additional text. None of that stuff is really possible in traditional content management systems. So, this is where the visual part comes in. So Builder.io is fully visual, right? [00:05:13] Drag and drop. You can add it, whatever you want in the page. And the last bit is headless, meaning that it's running on the customer's infrastructure and we don't host the website. If you are, if we are hosted CMS, then it's relatively easy to make a drag and drop editor. [00:05:28] But because we don't host it, it's not on our infrastructure. It's actually quite a head-scratcher. And the way we do this, which I think is pretty cool, is, we have this open source technology called Mitosis, which allows us to give one input to Mitosis and it can produced any output in terms of like, whether you use Angular, React, Vue, Svelte, Solid, it doesn't matter what you use on the backend. [00:05:50] We will generate a component for you. And because we're generating an actual component, it drops into the customer's backend infrastructure, right. And everything just works there. Server-side rendering works. Everything that, that the customer might have on a backend, it just worked because it's a full-on regular component, whether it's Angular, React, or whatever the company might use. [00:06:13] So that's the unique bit that nobody knows how to do. And it's also the bit that attracted me to Builder.io and joining them. And the reason for that is because it is really easy for them to create new technology. So one of the things we're going to talk about later is this thing called Qwik. [00:06:30] What's super easy with Builder.io is that they can easily produce new output. So if you have a customer that already has their content, let's say on react or Angular, and they decided they want to move over to something different, like Qwik, and I will talk about why that might be a reason, it is super easy because with a push of a button, because we generate the content, we can generate the components in a different framework. [00:06:55] swyx: Got it. It's interesting. Have you seen Tailwind?  [00:06:57] Misko Hevery: So Tailwind is more of a CSS framework with my understanding is correct for  [00:07:01] swyx: building, but they had to build something for doing this essentially like having different outputs, uh, we have one central template format that outputs all these different  [00:07:11] Misko Hevery: things.  [00:07:12] So this is what Mitosis would do. Right. But Mitosis can do this across all of them, not just Vue and React, right? Every single one. Like, I don't even know what the list is, but there's a huge list of possible outputs that uh, Mitosis  [00:07:25] swyx: can do. Yeah. You have, Liquid and JSON.  [00:07:30] Misko Hevery: There's more, I mean, this for ones that you see over here. [00:07:33] Yeah. You can see pretty much everything's analyst here. We can import from Figma, given some constraints. Cause it's not a one-to-one thing kind of a thing, but we can import from Figma. So the idea is that people can design their site in Figma provided that they follow a certain set of guidelines. [00:07:49] We can actually import them and to turn it into HTML and then serve it up, whether it's React or whatever. One of the things is that's actually important. For example, for us is Liquid, right? Liquid is a templating system on Shopify. But it's a server side templating system and it cannot be done on the client side. [00:08:05] So if you pre-render on Liquid, how do you get a component to bind to it on the client? Because you would need to have the same component. Right? One of the things we can do is we can present it on a liquid and then produce an, a equivalent react component on the client and they automatically bind to it on a client. [00:08:21] Right. So we can do these kinds of tricks which are normally quite difficult.  [00:08:25] swyx: So you went from building one framework to building all the frameworks.  [00:08:29] Misko Hevery: You can think of it that way.  [00:08:31] PartyTown  [00:08:31] Misko Hevery: But my real thing, the real passion is that I want to get all sides to be 100/100. Yeah. Okay. Uh, on mobile, not on this stop, you know, a lot of people claim on desktop that they can do 100 out of a hundred mobile, that's the bar. [00:08:46] So I want to figure out how to do this. And in order to do that, you really have to get super, super good at rendering these things. And it turns out that if you just make a blank page and blank, white page with nothing on it, and you add a Google tag manager, that alone puts you essentially on the cusp of a hundred, out of a hundred on mobile. [00:09:08] So that alone, that, that act alone, right, he's kind of uses up all your time that you have for rendering. And so the question becomes like, how do we make this as fast as possible? So you can get a hundred out of a hundred on mobile. And it's very little processing time that you get to have and still get to have a hundred. [00:09:25] And so we do two things. One is be introducing a new framework called Qwik. little later. But the other thing we're talking about is introducing this thing called PartyTown okay. And I absolutely love PartyTown. So the person behind PartyTown is Adam Bradley, who you might know him from, making the Ionic framework.  [00:09:43] The guy is absolutely genius. And this is a perfect example of the cleverness of it. All right? So you have, something like a Google tag manager that you want to install on your website. And that thing alone is going to eat up all of your CPU time. So you really would like to put it on a WebWorker, but the problem is you can't because the WebWorker doesn't have DOM API. [00:10:02] It doesn't have a URL bar. It doesn't have just about everything that the Google tag manager wants to do. Right? Google tag manager wants to insert a tracking pixel on your screen. It wants to register a listener to the, to the, uh, URL changes. It wants to set up listeners for your mouse movements, for the clicks, all kinds of stuff. [00:10:21] So running it on a Web Worker becomes a problem. And so the clever bit of geniuses that Adam came up with is that, well, what you really want is you want to proxy the APIs on the main thread into the web worker thread, and you can proxy them through, you know, we have these, these objects called proxies. [00:10:39] The problem is that the code on a Web Worker expects everything to be synchronous. And our communication channel between the main thread and the web worker thread is async. And so the question becomes like, well, how do you solve this particular problem? And it turns out there is a solution to this problem. [00:10:56] And the solution is that you can make a XML HTTP request, which is synchronous, on a Web worker. And then you can intercept that the request using a service worker and then service worker can talk to the main thread. Figure out what exactly did you want to do? So for example, let's say you want to set up a, uh, you want to know the bounding rectangles of some div, the Web Worker thread can make that request, encode that request inside of a XML HTTP request, which goes to the service worker. Service worker calls the main thread, the main thread figures out what the rectangle boxes, and then sends the information back to the web worker thread, which then doesn't notice anything special. As far as it's concerned, it's just executing stuff, synchronously. It's like, you're laughing, right? Because this is hilarious. [00:11:41] Web Workers vs Service Workers vs Atomics  [00:11:41] swyx: So I'm one of those. Okay. You're, you're a little bit ahead of me now. I'm one of those people I've never used web workers or service workers. Right. Um, can we talk a little about, a little bit about the difference and like, are they supposed to be used like that? Like,  [00:11:54] Misko Hevery: uh, so we did these two because they are supported under the most browsers. [00:11:59] There's a different way of making synchronous call and that is through something called Atomics, but Atomics is not available on all browsers yet.  [00:12:07] So web worker is basically just another thread that you have in the browser. [00:12:12] However, that thread doesn't have access to the DOM. So all DOM APIs are kind of gone from there. So you can do a lot of CPU intensive things over there, but, , with limited abilities and this is what PartyTown solves is it proxies all of the API from the main thread into the Web Worker thread. Yeah.  [00:12:32] Now service worker is kind of a safe thing, but the difference is that a service worker can watch HTTP requests go by and it can intercept them. And so think of it as almost like a mini web server in your browser. And so what the service worker does over here is intercepts the request that the web worker makes, because that's the only way we know how to make it blocking call. [00:12:56] swyx: Uh, this is the one that we use for caching and Create React App and stuff like that. [00:13:00] Misko Hevery: Yeah. And then, because we can make a blocking call out of a web worker, the service worker who can use the blockiness of it to make an asynchronous call to the main thread and get all the information that you need.  [00:13:12] swyx: that's pretty smart. Is there any relation to, uh, I know that I think either Jason Miller or Surma did a worker library that was supposed to make it easier to integrate, um, are you aware of, I think  [00:13:25] Misko Hevery: all of these worker rivalries are in heart they're asynchronous, right. And that's what prevents us from using it, right. [00:13:31] Because the code as written assumes full asynchronicity, and that is the bit that's. Different. Right. That's the thing that allows us to take code as is, and just execute it in a, Web Worker. And so by doing that, we can take all of these expensive APIs, whether it's, Google tag manager, Analytics, Service Hub, I think that mispronouncing it, I think, all of these libraries can now go to the main thread and they have zero impact on your Google page speed score. And we actually talked to Chrome and we said like, Hey, we can do this. Do you think this is cheating? Right? Like, do you think that somehow we're just gaming the system and the message was no, no, because this actually makes the experience better for the user, right? [00:14:17] Like the user will come to the website. And because now the main thread is the thing that is running faster and none of this stuff is blocking. You actually have a better experience for the user. The other thing we can do is we can actually throttle how fast the Web Worker will run because when the Web Worker makes a request back to the main thread to say, like, I want the bounding box, or I'm going to set up a tracking pixel or anything like that, we don't have to process it immediately. [00:14:43] We can just say, well, process this at the next idle time. And so the end result is that you get a really high priority for the main thread and then the analytics loads when there's nothing else to do. Which is exactly what you want, right? You want these secondary things to load at a low priority and only be done when there's nothing else to do on the main thread. [00:15:02] PartyTown Demo  [00:15:02] swyx: That's amazing. Okay. All right. We have some demos here if we want to  [00:15:05] Misko Hevery: So if you, let's pick out the simple one, the element, right. And what you see in the console log is this is just a simple test, which performs, uh, synchronous operations. But what you see on the console log is that all of these operations are intercepted by the service worker. [00:15:22] Right. And we can see what particular API on the web worker is trying to do and what the result is, what the return code is, you know, how do we respond and so on and so forth. And so through this,you can kind of observe what your third party code does. By the way. The nice thing about this is also that, because you can observe, you can see is ECP. [00:15:43] If you're a third-party code, because we essentially trust them, right. Fully trust this third party code on your website and who knows what this third party code is doing. Right? So with this, you can see it and you can sandbox it and you can, for example, say like, yeah, I know you're trying to read the cookie, but I'm not going to let you, I'm just going to return an empty cookie because I don't think it's your business to do that. [00:16:04] You know, or any of those things we can do. So you can create a security sandbox around your third party code. That is kind of, as of right now is just implicitly trusted and you can, you have a better control over it.  [00:16:18] swyx: I could filter for it, I'm basically, I need HTTP calls and then I need any cookies. [00:16:23] Right. So,  [00:16:25] Misko Hevery: yeah. So in this case, there will be nothing because this is just showing off element API, but I think you go to previous page  [00:16:33] swyx: Before we go there. is there anything significant and? It says startup 254 milliseconds?  [00:16:38] Misko Hevery: Yeah. So the thing to understand is that it is slower, right? We are making the Google tag manager slower to start up. [00:16:46] Right. So it's definitely not going to be as fast as if it was on a main thread, but it's a, trade-off, we're doing intention. To say like, Hey, we want to give the CPU time to a user so that the user has a better experience rather than eagerly try to load analytics at the very, very beginning and then ruining it for the user. [00:17:04] So while in theory, you could run a react application and the web worker, I wouldn't be recommended because it will be running significantly slower. Okay. Um, because you know, all of these HTP requests, all these calls across the boundary, uh, would slow down. So it is a trade-off.  [00:17:23] swyx: So this is really for the kind of people who are working on, sites that are, have a lot of third-party scripts for,  [00:17:30] Misko Hevery: well, all the sides have third party scripts, right? [00:17:32] Like any kind of a site will have some kind of third-party whether it's analytics ads or just something that keeps track of what kind of exceptions happen on the client and send them back to the server, right. Standard standard things that people have on a website. And instead of the standard things that are making, preventing you from getting a hundred out of a hundred on your score. [00:17:52] Right. Okay, amazing. So this is a way of unloading stuff from the main thread Got  [00:17:58] swyx: What's the API? I haven't seen the actual code that, Party Town. Okay. There's a, there's a adapter thingy and then  [00:18:05] Misko Hevery: you stick it. So we, those are just for react components. There is also vanilla. Just go a little over. [00:18:14] So do   [00:18:16] swyx: you see how we have to prioritize, React above Vanilla? [00:18:20] Misko Hevery: Even lower? This just shows you how you get the PartyTown going. Oh, here we go. Text to pay. We go right there. [00:18:25] You're looking at it right there. So notice what. We asked you to take your third party script, which, you know, if you go to Google on an exit, it tells you like, oh, take this script tag and just drop it inside of your head. Right. Or something like that. So what we do is we say like, do the same exact thing, except change the type to text/partytown. [00:18:43] And that basically tells the browser don't execute it. Instead, PartyTown will come later, read the stuff, ship it over to the web worker and then do it over there.  [00:18:54] swyx: So the only API is you, you just change this, that's it? Yes. Yes.  [00:18:58] Misko Hevery: So you drop a party down script into, uh, into, which is about six kilobytes. And then you go to all of the third-party places and just add, type text/partytown, and that ships them off to the other place. [00:19:10] swyx: So, um, it feels like Chrome should just build this in like script, script type third party. Right. And then just do it.  [00:19:20] Misko Hevery: Yeah. I mean, we're having chats with them. You never know. Maybe if this shows up to be very useful technique. It might be something that Chrome could consider. Well, certainly we need a better way of making synchronous calls from the web worker thread to the main thread, not from the main ones of the web, right. [00:19:37] That's clearly a bad idea, but from the web worker, the main, it would be really nice to have a proper way of doing synchronous calls.  [00:19:44] Atomics  [00:19:44] Misko Hevery: Atomics might be the answer. And so it might be just as simple as getting all the browsers to adopt Atomics because the standard already exists.  [00:19:51] swyx: And I see what, what is this thing I've never heard of it? [00:19:55] Misko Hevery: Atomics is basically a shared memory array buffer between two threads and you can do, atomic operations like locking and incrementing and things of that sort on it. And they can be done in a blocking way. So you can, for example, say, increment this to one and wait until whatever result is three or something like that. [00:20:14] So then you're giving a chance for the other thread to do its work. I  [00:20:18] swyx: mean, this is like, so I'm writing assembly, like,  [00:20:22] Misko Hevery: It's not assembly it's more, you know, semaphore synchronization.  [00:20:26] swyx: Um, okay. Yeah. I see the, I see the locks and stuff, but this is, I can't just like throw in a third party script here. [00:20:33] Misko Hevery: No, no, no. This is something that the PartyTown would use to get synchronous messaging across. Right. Because currently it is kind of a hack that we create an XML HTTP request that is blocking that stuff with a service worker. Like this is craziness, right. So Atomics would definitely be a nicer way to do this. [00:20:51] swyx: I think the goal is definitely very worthwhile that the underlying, how you do it is a bit ugly, but who cares?  [00:20:57] Misko Hevery: Yeah. So the goal is very simple, right? The goal is, for us, we think we can have the best CMS, if we can produce websites that are a hundred out of a hundred on mobile, right? [00:21:07] That's the goal. And if you look at the current state of the world, and if you go to e-commerce websites, it's pretty dismal. Like everybody gets like 20 something on their scores for their sites, right? Even Amazon that has all the resources to spend, will only get 60 out of a hundred on their score. [00:21:24] Even Google website themselves gets it only about 70, out of a hundred. Right? So the state of the world is not very good. And I feel like we are in this cold war in a sense that like everybody's website is equally bad, so nobody cares. Right. But I'm hoping that if you can build a couple of websites that are just amazingly fast, then the world's going to be like, well, now I have to care. [00:21:46] Qwik and Resumable vs Replayable Frameworks  [00:21:46] Misko Hevery: Right? Because now it is different. And so now we're getting into the discussion of Qwik. So what is clicking and why do we need this? So, um, the basic idea behind Qwik, or rather than, let me back up a second of why existing websites are slow.  [00:22:04] And so there's two reasons, right? One is third party scripts, and we just discussed how we can solve this through PartyTown right? I mean, we can move all of their party scripts off.  [00:22:12] However, even if you move all the third party scripts off, your problem is still going to be that, uh, the startup time of your website is going to be pretty slow. And the reason for that is because all websites ship everything twice. First it's a server side rendered HTML, right. [00:22:30] And the page comes up quickly and then it's static. So we need to register listeners. Well, how do we adjust your listeners? Well, we download the whole site again, this time they came to in a form of TypeScript or JavaScript, and then we execute the whole site again, which is by the way, the server just did that. [00:22:49] Right? Yup. Yup. And then we know where to put up listeners and, that causes, you know, this is a perfect graphic for it, right. That causes double loading of everything. So we, we download everything once as HTML and then we load everything again, as JavaScript and then the execute the whole thing again. [00:23:07] So really we're doing everything twice. So what I'm saying is that the current set of framework are replayable, meaning that in order for them to have the bootstrap on the client, they have to replay everything that the server, literally just did, not even a second ago. And so Qwik is different in a sense, because it is resumable. [00:23:27] The big difference with Qwik is that the Qwik can send HTML across, and that's all. That's all it needs to send across. There's a little tiny bootstrapper, which is about one kilobyte and about one millisecond run, which just sets up a global listener and alert for the system. And no other code needs to be downloaded and it can resume exactly where the server left off. [00:23:48] So you need to have some formal way of serializing, the state, getting the state to the client, having a way of deserializing the state. More importantly, there's an importance to be able to render components independently from each other, right? And this is a problem with a lot of frameworks, which is - even if you could delay the startup time of a, uh, of an application, the moment you click on something react has to rerender the whole world right now, not rerender, that might be the wrong term, but it has to re execute its diffing algorithm from the root, right. It has to build up the vDOM. It has to reconcile the vDOM, has to do all these things, starting at the root. [00:24:26] There's no real way to not make it from the root. And so that means that it has to download all the code. And so the big thing about Qwik is, how can we have individual components be woken up individually from each other in any order? Right? I mean, people tend to talk about this in form of micro components or microservices on the client, right? [00:24:46] This is what we want, but at like the ultimate scale, where every component can act independently from everybody else.  [00:24:54] swyx: Yeah. Yeah. I think, we should talk a little bit about that because basically every single component is its own module and separately downloaded. So you're really using the multiplexing or whatever you call it of HTTP/2, right? [00:25:05] Like you can parallelize all those downloading. Right. The main joke I made, because I saw this opportunity and I was like, immediately, like, I know this will be the most controversial part, which is essentially. Uh, the way you serialize is you put everything in HTML, right? Like, like that. [00:25:23] So, so I, I immediately feel that, and it will stir up some controversy, but like also, like, I think the, the interesting, I mean, we should talk a bit about this. Like, obviously this is not handwritten by, by, by people. So people should not be that worried. Um, but also like there are some legitimate concerns, right. [00:25:40] Qwik vs React - the curse of Closures  [00:25:40] swyx: About how I think basically Dan Abramov was, was also the, the, you, you responded to Dan. Um, so Dan said something like this, okay. So it wasn't a direct response to Qwik but Qwik serializes all state in HTML, and that's something that we considered for React Suspense. And he says, basically the question was, have you considered allowing server components to have serializable state using equivalent? [00:26:03] it's been proposed somewhere earlier. This doesn't work generally state is in reaction arbitrary. Payloads would get huge essentially, like, "does it scale?" Is the question. Uh, and he said that this was done before and I went and looked it up and he was like, yeah. And it's actually what we used to do for ASP .NET WebForms. Right.  [00:26:18] Misko Hevery: So if you will look at react the way to React does things. And so I want to pull this up on one of the dev, uh, dogs. I actually talk about it and it might be useful to kind of pull it out. Yeah, the one you are on right now, the answer adoptable fine-grained lazy loaded. The point is that if you have a react component, react components take heavily, closures, right? Closure is the bread and butter of react components and they rely on closures everywhere and it's beautiful. I it's absolutely nice. I really like the mental model. However, it doesn't serialize, right? [00:26:50] You can't take a closure and serialize it into HTML. So what Qwik is trying to do is it's trying to break this up into individual functions. Clearly functions cannot be serialized, but functions can get a URL , a globally known URL, uh, which can load this. So if you scroll a little lower, you will see a, uh, Qwik component , and the difference is, in a Qwik component, we'll have these declaration template, which is which points to a location to where this particular thing can be loaded, if you scroll even further, it talks about how this particular thing can be served up in pieces to the client, if you do this thing. Right. So while it's maybe true that like, oh, it's been tried before and we didn't do it right. [00:27:32] Qwik Demo  [00:27:32] Misko Hevery: Have people really tried to solve every single one of these problems. Right. And there's a huge myriad of them that Qwik is trying to solve and kind of get over. And so maybe I can show it to you as a demo of what I kind of have a to-do app working. So let's let me, let's talk about this. [00:27:50] One of the things. So by the way, the screenshot you have on your Twitter account, that is the old version of Qwik, I've been chatting with you and bunch of other people at the conference, I really got inspired by lots of cool things. And this is a kind of a new version I'm working on, which has many of the issues fixed up and improved. So the thing I'm going to show you is standard todo example, right? I mean, you've seen this millions of times before. [00:28:15] swyx: By the way. I did not know that, uh, I think Addy Osmani made this original to do yes, he did. He did. And it's like the classic example. That was a classic example,  [00:28:24] Misko Hevery: right?  [00:28:27] So remember the goal for us is to serialize everything and send to the client in a form that the client can resume where the silver left off. Right. And then everything can be downloaded in pieces. So there's a lot of things to talk about. So let's start with, with how this works first, and then we can talk about how different pieces actually fit together. [00:28:46] So, you know, first thing you need to do, is, standard, define your interface for an item and define your interface for Todos, which is the collection of items, which contains , number of items completed in the current filter state, and just a list of items like so far, nothing. [00:29:02] Now the special thing comes in that when you declaring a object that you want to serialize, you will run it through this special function called Q object. And it's a marker function and does a couple of things to an object. But you're just basically passing all the stuff in and notice the individual items on Q objects as well. [00:29:20] The reason I did it this way is because I want to serialize individual line items separately, because I know that I'm going to be passing the individual items into separate components individually. Right? So what this basically says to the system is like, there is a top level object. Which is this guy right here and it can have rich state, but remember it has to be JSON serializable. [00:29:43] Therefore it cannot have cyclical things inside of it. It has to be a tree, but inside of it, it can have other objects and those can form cyclical things. So using the combination of those two, you can actually get cyclical graphs going inside of your application. But individually, each Q objects doesn't have that. [00:30:02] So that's a bit of a magic. If I scroll over to the actual running application, what you will notice is these Q objects get serialized like right here. So for example, this one has some ID and you notice it says completed zero and the inside of it has individual items. And notice these items are actually IDs to other locations. [00:30:22] So this ID ending in Zab is actually pointing to this object right here, which has other things. So the whole thing gets serialized. And unlike the demo I showed in Zadar, I have moved all the serialized content at the end, because I don't want to slow down the rendering of the top part. And so if you go, let's go back to our application. [00:30:41] So if you have Todo app, the Todo app is declared in a slightly more verbose way than the way the one would be declared in React. But if we do it this way, then we can serialize the closures, right? The closures don't have the issue with non serialized. By the way, the regular React way of doing things still works here and you can do that is just, they become permanently bound to their parents. [00:31:05] They cannot be lazy loaded. So you can think of it as having two mental models here. You can have lightweight components, which are essentially the same as react components, or you could have Q components, which are slightly more heavyweight, but they get the benefit of having the whole thing, be composable and get lazy a little bit so on and so forth. [00:31:24] So in this particular case, we're saying that there is a Todo app component and the QRL is this magical marker function that tells the system that this content here needs to be lazy. Or rather let me phrase it differently, it says the content here can be lazy loaded. The beauty of Qwik is that it allows you to put a lazy load of boundaries all throughout the system. [00:31:48] And then an optimization phase later decides whether or not we should take advantage of these lazy loaded motor boundaries, right in normal world, the developer has to put dynamic imports and that imports that asynchronous and a pain in the butt to work with, it's not simple. Right? So instead, what Qwik wants to do is say like, no, let's put dynamic imports everywhere, but do it in a way where the developer doesn't have to worry about it and then let the tooling figure out later whether or not we should actually have a dynamic import at this location or not. [00:32:18] Yeah. So even though this file, this there's two applications is in a single file in the tooling. We'll be able to break this file up into lots of small files and then decide in which order the things should be shipped to the client in order to get the best experience. You know, if there's a piece of code that never runs in the client will then put it at the bottom of the, of the chunks, right? [00:32:38] If there's a piece of code that is going to be most likely, you're going to click on it and put it up to the top. So, anyway, so that's kind of a diatribe here with a little bit of an off the rails here, but what this produces is a to-do and it turns the code, right? This QRL function, it says on render, it gets turned into a URL. [00:32:58] And this is what allows the build system to rearrange the code. And so this URL basically says, if you determine that Todo needs to be re re rendered, uh, then you can go download this piece of code. And that will tell you how do we render the Todo, right.  [00:33:14] You know, you're using a header and we're using main, notice we're binding Todos in there. So it looks like a regular binding, but the system has to do more work. So in this particular case, the main has to see if it has Todos, it has to refer to a object. So notice this, this ID here matches the ID here. And this is basically how the system knows that this component here, because if you look over here, the main and foot are, both of them want to know that you do this right? [00:33:42] So both of these components need to have the same object. And so, yeah, exactly. So this main here, as well as the footer, they both have a same ID passed in here. And that's how the system knows like, all right, if I wake you up, I have to make sure to provide you with the same exact ID. Now, not only that there is also this particular thing, which is just a copy of it, but, but in this particular. [00:34:08] What it does is, is the list, all of the objects that could potentially affect the state of this component. And when you go and you modify one of these, state objects, the state, these objects actually keep track of each other and they know which components need to be woken up and affected. So I think there's an example of it somewhere here later, uh, like right here, right in here, it says, Hey, if you, uh, you know, do a key up on the input right here, if I type here over here, something, then the key up runs and then eat, enter runs, you know, add a new item, which is just the function that the function right here, which just pushes an item and new item into the list. [00:34:54] And it sets my current state to text me. And so the system knows that in this political case, in a header, this input right here, Has its own state right here. So let me refresh this again. Um, this header has its own state one eight, whatever, right? Which if you look over here is right here. It's text blank, right? [00:35:16] So we find typing here. I'm going to change the state over here. And then if I set the state to blank, then the system knows, oh, that's object 1 8, 7 1, or whatever. I can run a query. I can run document DOM, querySelectorAll. And I can say, give me, uh, all the queue objects, remember how the selector for this start something like this. [00:35:44] Anyways, there's a way to run a selector that will allow me to whatever, whatever the code is, right? I'll run the selector and this selector will then return this header back to me saying this is the object or rather, this is the component that is, has interests registered into this object, which means. [00:36:04] Because I've selected this thing. I have to find the Q render message and send the Q render message to download its template and we render the object. And so what this allows you to do is have a completely distributed set of components that can be awoken only when a relative, you know, appropriate data is changed rather than having this world of like, well, the state has changed and I don't know who has a reference to what? [00:36:30] So the only thing I can do is we learn that the whole page. Well, that's kind of a, it doesn't help you, right? Cause if you run the, the whole page, then there's the whole, the code has to come in here. Right. So that's not helpful. We want to make sure that we only download the code is actually needed. And so you need to have some mechanism by which, you know, like if I change this piece of code, if I change this object, which component needs to be awoken, right. [00:36:54] And normally like if you have Svelte, Svelte does through subscription, this particular trick, the problem is subscriptions cannot be serialized into the DOM. And so we need a mechanism where the subscription information is actually DOM serializable, right? And this is what the Q object is, or the subscriptions that the individual components have to undo to other things. [00:37:18] And so the other thing I kinda want to point out is that we can then bind a complex object. Like in this case, it's a complicated state that'd be assigned to reduce yet. It turned into a binding that's serializable into the bottom, right? So if I go back here, see I'm jumping around. So we have our footer. [00:37:38] If we have our main, the main is declared over here, you know, standard, uh, JSX in here where you, you want to iterate over a bunch of items. There's a host. Okay. So one of the things we need to do is, um, in react, when you have a component, the component is essentially hostless, or I would say it's life component in the sense that it doesn't have a parent, right. [00:38:02] Uh, and that is wonderful in many, many situations, but sometimes it isn't. The problem we have is that we need to have a component. We need to have a DOM element for each component that can be queried using querySelectorAll so that we can determine if there is a listener on it, or if there is a subscription on a particular object or a single back. [00:38:24] So we have this concept of a host element, and this is one way in which the Qwik Q component is more heavyweight than the react component. You can still use react components if you want, you just don't get the benefits we talked about. And, and so a host element is, is a way of referring to the, the host element and adding an attribute to it. [00:38:47] Right. And saying like, oh, I want the host, I'm going to have a classmate. And so if you go into, let's see Maine, uh, right. So it's supposed to be a classmate, right. So it's the component that, that adamant. So normally, uh, the way you do this normally in react is that the main would be a object that the JSX of the re. [00:39:07] The child react component, right? In this particular case for a variety of reasons, we need to eagerly create this particular thing. So then it's a placeholder for other things to go in. And so we need to do an eagerly and then we need a way of like referring to it. So that's what host is, sorry for the, uh, diatribe anyways, but this is how you create your items, right? [00:39:31] And notice the way you got your items is you just got it from your prompts and you can iterate over them. Right? You can reiterate and run the map and produce individual items. And for each item you will pass. And the key. So if you look at the item here, it's prompt says like, I am going to get an item in here. [00:39:50] And my internal state is whether an I am not, I am an editable state. So these are you, basically your props. And this is the components state in here. And, uh, you know, on mound, we create a component states that we're not, we're not an editable state. And then when the rendering runs, uh, it has both the information about the item as well as about whether or not you are currently editing. [00:40:13] Uh, and if you look at the UL, so here's our, one of our items that got generated, notice that the item that passed in as a ID here, right? So if you go to the script at the bottom and see this one ends in PT six, so we should be able to find, here we go, this is what actually is being passed in to that particular component. [00:40:34] But notice there's a second object. Not only is there a, um, a PT six objects, there's also the secondary option. That's the state of the components. So if the state of the component, we're basically saying here is like, if this object changes or this object changes, I want to know about it and I need to be. [00:40:52] So these objects form a graph, right? The presents, the state of your system. And then the Qwik provides a mechanism to serialize all this information into the DOM in such a way that we know which component is to be woken at what time. So if I start typing in one of the things you're going to see is that on the first interaction, this script that will disappear, because what actually happens is that when you interact with the system, it says like "I need to rehydrate myself". Right? And so it goes to the script tag and, uh, reads it. Let me give it back over here, read it leads to the script tag and figures out. You know, these utilizes all these objects because takes this object, puts them inside of this object to build up the graph and then goes back into the DOM tree and say like, okay, so I need to put this one over here. [00:41:40] I need to put this one over here, this one over here and so on and so forth and puts all these objects back. What are they supposed to be? And now you are, your state is back in a, in these components, but the components aren't present yet. They're not awoken, right? Because none of their, uh, Mount or their render functions actually got called. [00:41:59] And because the functions didn't get called, uh, the code didn't have to get downloaded. So everything is super lazy. Right. So when I go and I hit a key over here, the state gets de-centralized, but the only piece of code that gets downloaded is right. It is, it is right. This thing right here. [00:42:18] Nothing else.  [00:42:19] swyx: Can we show that the network actually, ah,  [00:42:22] Misko Hevery: I would love to, but that part is mocked out right now in the old demo, in the demo that I have, that I did for the conference, that one actually had it properly working. But the feedback was that the D as a developer, there was a lot of things I had to do. [00:42:40] Qwik Compiler Optimizations  [00:42:40] Misko Hevery: And so I wanted to simplify it. So one of the things I did is I figured out a way, or rather I spoke with Adam, uh, the same Adam that did PartyTown. And we figured out how to make it, make the tooling smarter so that the developer doesn't have to do this. So what actually happens is that when you have the QRO over here, what actually happens is you, the, the code automatically gets refactored. [00:43:06] And you will get a new function with factor like this. The system will put an expert on it. And what gets placed in this location is a string that says something like, you know, ABC. Uh, hash you local, right. Or something like that. Right? So by doing this transformation and that piece of code is not working in this transformation, um, the, uh, the system can then, uh, lazy load, just the spirit physical code, nothing else. [00:43:39] But in order to do this transformation, we have to make sure that this code here doesn't have any closures. Right? I cannot, it cannot close over something and keep that variable because if it does the whole thing doesn't work. And so the nice thing is that we can still write it in a natural form, but one of the constraints here here is that you can't close over any variables. [00:44:01] Now there's no variables to close over them. The system is designed in such a way that it doesn't need it. Instead of things like props and state are explicitly passed into you, as well as to the thing of the child, whether they're halo as well. So you don't have a needs to create these kinds of closures, but it is a constraint. [00:44:19] And this is what allows the optimizer to go in and rearrange your code base in a way where we can then determine what things are used. So, so in this particular case, we can, for example, determined that you're likely to go and interact with the input box, but you are very unlikely to actually call this on render, because this is the kind of the Chrome, the shell of the application, and wants to show them the applications loaded you will never, ever interacted. [00:44:46] Right? So what you can do is you can take all these imports and you can sort them not alphabetically. You can sort them by the probability of usage. And then once you haven't sorted by the probability of usage, you can tell the optimizer like, okay, take the first N ones so that I have a chunk that's about 20 kilobytes because we think 20 kilobyte chunks. [00:45:08] And then the system can be like, okay, let me add a whole bunch of them until I have 20 kilobytes. Let me add a nice chunk, then underline about 20 clubs. And I kind of do these chunking all the way on the end. And then the last chunk we'll probably end up with a bunch of stuff that never ever gets loaded. [00:45:22] Right. But the problem is the current way we design applications. You can't do that. You just can't right. And so we have this mentality of like, we have frameworks that have amazing developer experience, but they set up the overall experience down the path of monolithic code base and any kind of, um, lazy loading that the Builder can add after the fact. [00:45:50] It's just like kind of a kloogey workaround. Right? And that's the thing that the Qwik solves it says like, no, no, no, let me help you design an application that has still nice developer experience, but let me structure things in a way so that I can later rearrange things, right? Let me keep you on this guide rails of like, make sure you do it in these ways. [00:46:12] And so everything is in the quickest set up in a way where it keeps you in this guide rails. And the result is, is a piece of code that the optimizer, then the Qwik can rearrange, right? It can go and pull out this function. It can pull out this function. It can pull out all of these functions and turn them into a top level functions that are exportable. [00:46:31] And it can then, um, tree shake the stuff that's not needed and produce chunks that can then be lazy loaded into your application.  [00:46:41] swyx: Like four or five years ago, I think there was some, uh, I think even at the Chrome dev summit or something like that, there was a effort to use Guess.js to basically use Google analytics, to optimize all this, intelligent pre-loading or loading predictions. [00:46:58] Um, is that how I think I missed the part about how, like, how you pull in the statistics for, for optimizing.  [00:47:05] Misko Hevery: So the first thing to talk about, I think is important to understand is that unless you can take your application and break it up into lots and lots and lots of chunks, I do that. Yeah. There's nothing to talk about. [00:47:15] Right? If your application is one big chunk, there's nothing to talk about. You would have to load the chunk end of discussion.  [00:47:21] swyx: Well, so the chunk goes page level, and now you're doing component level, right? So they were, they were saying we split it by page and we can predict the next page. So,  [00:47:30] Misko Hevery: so look at Amazon, right? [00:47:34] Most of this stuff, you will, I mean, you can click on stuff and there's a menu system up here and let's pick a random component here. How do I, let me just go to something. Oh, come on. Just give me a detail view of something every day. Uh, you know, most things here never have to be rendered. Like, for example, there's a component here. [00:47:52] This component never, ever changes. Nothing here. We're render nothing. We'll run it there, here. Uh, yes, these are components and I can click on them and they update the UI over here. But if I'm interacting here, why am I downloading the menu system? Right. And so the point is, if you have a page like this, there is huge number of components in here, but most of them either never update, or in my current path of interaction, I just don't need to update them. Right. If I'm using the menu system, then I don't need to download this thing here. And if I'm interacting with my item then I don't need the menu system, and I'm not, unless they put something out to car, do I have to worry about my shopping cart? [00:48:33] Right? And, and this is the problem is that we currently bundle the whole thing up as one giant monolithic chunk. And yes, there are ways to break this out, but they are not easy. And everybody knows how to do route level break up. But like even on rough level, it's, it's not, it's not fine grain enough. [00:48:53] Right. And so the magic of Qwik is the magic of writing the code in this particular style. Is that for a typical size application, I can break up the application in literally thousands of chunks. Now that's too much. We've gone way too far. I do. These, these chunks are too small and we don't want that. [00:49:13] Right. But when I can break things up, it's easy for me to assemble bigger chunks out of it. But the opposite isn't true, right? If I have a big chunk and I want to break it, well, good luck. You know, no amount of tooling is going to do this. As a matter of fact, the best AI system we have, which is right here in our brains. [00:49:31] Right. Even if you give it to the developer and say, go break this thing up, it's a head-scratcher that takes like weeks of work. Right? And so we are in this upside down world of like build a humongous thing and then have this attitude of like, somehow tooling will solve it. Tooling can solve this problem. [00:49:52] Right. You have to do it the other way around. You have to design a system which breaks into thousands of little chunks. And then the tooling can say, yeah, but that's too much. It's too fine-grained. And let me glue things together and put them together into bigger chunks because. Through experience. We know that an optimal chunk size is about 20 kilobytes, right? [00:50:11] And so now the thing you want is to get a list, the order of which the chunks are used, and that's easy, right? If you're running your application, you can just keep statistics on what, how users interact with your application and that's that the sticks can be sent back to the server. And so once you can get back on a server is just a ordered list of the probability by which you're going to need individual chunks. [00:50:35] And that sort of lists that sorted list is all you need to tell the optimizer, like start at the top of the list, keep adding items until you get to a correct chunk size, they'll start a new job, right. And you keep doing this over and over. Okay. Now the reason I get excited about this, the reason I talk about it is because we completely ignored this problem. [00:50:57] Right. We, we have these amazing frameworks, whether it's Angular, React, Svelte or whatever that allow you to build these amazing sites. But on the end of the day, we all have horrible page speed scores, because we're not thinking about it from the correct way. And the attitude for the longest time has been, the tooling will solve it later. [00:51:18] And my argument here is no, the tooling will not solve it later. If you make a mess of this code base, there's nothing that tooling can do. Yeah.  [00:51:27] swyx: Um, there's so many directions. I could take that in. So first of all, uh, the React term for this is a sufficiently smart compiler, which has been in the docs for like four or five years. [00:51:36] Yeah. That's an exhibit,  [00:51:39] Misko Hevery: but that's my point. Like you cannot make a sufficiently smart compiler [00:51:43] swyx: so is, I mean, is there a compile step for this because of the QRL section.  [00:51:47] Misko Hevery: So right now it's actually running without compilation whatsoever. So one of the things I want to make sure that it runs both in a compiled and uncompiled state, and that's why it comes up with these bogus things like mock modules, et cetera. [00:52:01] Uh, and I think if you go to the network stab, it loads the mock module, and it just re-exports it. I can't really show you, but basically all of these things are kind of just in there. So currently this thing runs as a single monolithic application, but the, the way this thing would work is that as I pointed out everything, every place that you see QRL is a hint to the compiler to go and extract this. [00:52:26] The compiler, literally, we would just think. Ctrl+Shift+R extract here and then gives it a name which will be a header pull on a key up. Right. And then it repeats the same exact thing over here. So Ctrl+Shift+R extract. This is a header onMount. I mistyped it. It's okay. I get it right. And the same thing here, controls have to go Ctrl+Shift+R [00:53:00] Qwik Questions  [00:53:00] swyx: what if I need to do like conditional loading because the competitor doesn't know which branch I need to go down.  [00:53:09] Misko Hevery: So I'll answer the question in a second, did you want to point out, so notice what ends up here? The header is super, super lightweight. There's nothing in here. Cause these things, these two things will get converted into these URLs, right? Yeah. And because of that, this header is permanently bound to the onRender of the to-do app. [00:53:28] Right? If you load a to-do app you're also loading the header and of Main and a footer, but the thing we've done over here is we made this super lightweight, and this is what allows the lazy loading to happen.  [00:53:41] Now you're asking what about other components? Uh, easy. I mean, uh, if you want it to conditionally include the header, you know, standard stuff. [00:53:51] Uh, true. Right now the, the header itself will always be permanently bound into the, on render of the to-do app. Right. However, because we did the trick when we extracted everything out of it had already super, super lightweight. It doesn't contain anything. Right? So the only thing the header really contains if you go in here is the what to do on this URL was the only thing that's in there and also this vendor, right? [00:54:18] So these two URLs are the only thing that is contained inside of the header by itself. Okay. It's only when we decide to render the header, do we go into the header? And we say, okay, we're doing a rendering. So what's your URL. And we look at this URL right here, we download the code. And so now the rendering pipeline has to be a synchronous. [00:54:38] We download the code and then we go and execute the content. And we basically fill in the content the better now in the process, we also realize, oh, we also have to download this piece of code. And this is where statistics would come together. And we basically tell us that this URL and this URL always get downloaded together. [00:54:57] And therefore the optimizer will be smart enough to always put them together in the same file in the same chunk. And, uh, you know, we rented the content. Got it.  [00:55:09] swyx: Okay. So, uh, one small piece of, uh, API feedback slash questions. Uh, yeah, you have, the tag name is optional there. I guess that's a hint to what to store, right. [00:55:18] Misko Hevery: So right now it says to-do right here. If I have a  [00:55:22] swyx: out,   [00:55:24] Misko Hevery: it becomes, uh, just the div. Um, so the system doesn't care. What the thing is, it means eight element. Um, it could be any element they will do just fine. It's easier to kind of on the eyes if it actually says to do right. So that's the only reason for okay. [00:55:42] Got it.  [00:55:43] swyx: the bigger piece is okay. It's like a lot of HTTP requests. Every time I basically, like every time I make a request, every time I interact with the app, I essentially need to do a whole new handshake, a whole new network transfer. There's some baseline weight for that. [00:56:00] Right. Chunking links that helps, um, is there a preload essentially? Is there a less programmatically say like, okay. And by the way, uh, this is important for offline capable apps. So I like, let's say like, I'm going offline. Like it's five things. I know I don't need it right now, but like as an app developer and  [00:56:18] Misko Hevery: I know.  [00:56:19] Yes. So, uh, we can totally do that. Um, we, uh, there is a level worker that will be set up and the web worker will get a list of all the chunks in the woodwork who will try to go and download them and set up the caching for you, uh, in these chunks of time. So that Y when you interact, the only thing that the browser has to do is execute the code now, because these chunks are small, the execution code, if we don't, we're not worried about it, right. [00:56:46] In the case of like on typical framework, that's replaceable. The problem is that the first time you interact with this thing, you have this huge amount of code to download parts and execute. But this isn't the case here because every interaction really only brings in the code that's strictly necessary for this interaction. [00:57:04] So again, we go to like Amazon, right? If I hover over here over these things, and it changes the image on the right side, the only code that gets downloaded and executed is the code for this. Now it's already pre downloaded because their web worker would go and pre fetch it for you. So the only thing that the browser has to do is parse the code and execute the code for the on hover, a callback that goes and updates this components URL. [00:57:27] Right. That's it? No other code needs to be downloaded in a presence. Yep.  [00:57:31] swyx: Got it. anything else that we should cover real Qwik?  [00:57:35] Misko Hevery: I feel like I have talked your ear off and you have been such a good and gracious host. Uh, happy to answer questions. I don't want to overwhelm people, but I am super excited as you can talk. [00:57:46] I'm super excited about this. I think it's a fundamental shift about how you think about a framework. So like, if you look at all the existing frameworks, they're all arguing about, like, I have a better index, I can do this better or that better and et cetera. Right. But fundamentally they're not the same, like essentially the same buckets they can all do about the same thing Qwik. [00:58:05] I think it's a whole new ballgame because the Qwik thing is not about like, oh, I can render a component just like, you know, 50 other frameworks can do as well. The thing that Qwik has is I can do it. I can give you microservices for free. I can give you this micro component architecture for free and I can produce a bundling. I am the sufficiently advanced compiler. Okay. Let's put it this way. This thing that you thought you could have and solve for you, doesn't exist unless you have the current guidelines. Right? So the thing with Qwik is that it is the thing that allows you to have a sufficiently smart compiler to give you this amazing times to interactivity, right? [00:58:48] At the end of the day, is the, there's nothing faster than downloading HTML for your website. I mean, that's the cake, right? Yep. So the reason why Qwik is fast is not because Qwik is clever in the way it runs JavaScript or anything like that. So no Qwik as fast because they don't have to do anything. [00:59:04] Right. When you, when you come to a Qwik website, there is literally nothing to do, right. We're fast because we don't do anything. And that's  [00:59:13] swyx: your baseline is like a one kilobyte bike loader, right?  [00:59:16] Misko Hevery: One come on loader with all the loader, does it sets up a global list? Right. So let me, let me go back. Sorry, let me share one more thing. [00:59:22] So here's your input, right? So if you go to a header, here's the input, right? The reason we know how to do something on it is because we serialize this thing called on:keyup, and there is a URL, right? So when this thing is first executed, nothing is done. Like this content shows up and it said we're done. [00:59:41] And the only reason why we know to do something next is because when I do a key up here, the event, bubbl

About LaurieLaurie is a Senior Software Engineer at Netflix. You can also find her creating content and educating the technology industry as an egghead instructor, member of the TC39 Educators committee, and technical blogger.Links: Twitter: https://twitter.com/laurieontech Netflix: https://www.netflix.com Egghead: https://egghead.io The Art of the Subtle Subtweet: https://laurieontech.com/book-launch/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: You could build you go ahead and build your own coding and mapping notification system, but it takes time, and it sucks! Alternately, consider Courier, who is sponsoring this episode. They make it easy. You can call a single send API for all of your notifications and channels. You can control the complexity around routing, retries, and deliverability and simplify your notification sequences with automation rules. Visit courier.com today and get started for free. If you wind up talking to them, tell them I sent you and watch them wince—because everyone does when you bring up my name. Thats the glorious part of being me. Once again, you could build your own notification system but why on god's flat earth would you do that?Corey: This episode is sponsored in part by our friends at VMware. Let's be honest—the past year has been far from easy. Due to, well, everything. It caused us to rush cloud migrations and digital transformation, which of course means long hours refactoring your apps, surprises on your cloud bill, misconfigurations and headache for everyone trying manage disparate and fractured cloud environments. VMware has an answer for this. With VMware multi-cloud solutions, organizations have the choice, speed, and control to migrate and optimizeapplications seamlessly without recoding, take the fastest path to modern infrastructure, and operate consistently across the data center, the edge, and any cloud. I urge to take a look at vmware.com/go/multicloud. You know my opinions on multi cloud by now, but there's a lot of stuff in here that works on any cloud. But don't take it from me thats: VMware.com/go/multicloud and my thanks to them again for sponsoring my ridiculous nonsense.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Laurie Barth, but no one really knows that's her last name. In fact, @laurieontech is how most people think of her. She's a senior software engineer at a company called Netflix, which primarily streams movies and gives conference talks—in the before times—about how you're doing it wrong.She also creates a lot of content and educates the technology industry as an instructor at Egghead. She's a member of the TC39 Educator's Committee, and of course, is a technical blogger. Laurie, thank you for suffering the slings and arrows I'm no doubt going to be hurtling your way.Laurie: This is the most fun I've had all week. [laugh].Corey: Well, it's a pandemic on, so presumably that isn't that high of a bar for the pony to stumble over.Laurie: Yeah, unfortunately not. I think that's maybe the problem.Corey: So, you're someone that I have been aware of for an awfully long time. You're always sort of omnipresent in conversations. You are someone who has a lot of great opinions that present well; you talk about an awful lot of things that are germane to my interests, educating the next generation of engineers, for example. And of course, you recently started at Netflix, at which point, well, if you're not familiar with what Netflix is doing in the cloud, have you ever even talked to an AWS employee for more than 35 seconds because they'll go reference Netflix for a variety of wonderful reasons, both based on technical excellence, as well as because AWS is so bad at telling the story of what you can build out of their popsicle stick service collection that they just punt to companies like Netflix to demonstrate what you could do. So, you're sort of this omnipresent force on Twitter, but we've never really had a conversation before, so it was long past time to rectify this.Laurie: I mean, you sent me two cents. So… I think that was pretty—[laugh].Corey: That's what the Tip Jar is for. You just wind up hurling very small amounts of money at people along with insulting comments, and it's a new form of social media. That is the micro-transaction way.Laurie: I quite enjoyed that. So, for context, I was one of the first people to be part of the A/B testing for Tip Jar on Twitter and Corey was the first person to send me money with, of course, a very on-brand Corey message, which there's a screenshot of on Twitter somewhere. And a couple of people followed, but it was great fun. And I think that's the first time we had ever directly interacted in a message or something, other than obviously, in threads and that sort of thing.Corey: Yeah, that's an interesting point to lead into here because I'm also in the A/B test for Tip Jar and I've largely turned it off, except for when I'm doing something very small and very focused, usually aimed at some sort of charitable benefit or whatnot, and even then, it's not the right way to do it. And it's weird, there was a time I absolutely would have turned it on, but it doesn't seem right for me to do it now and that's partially due to the fact that—first, I don't need tips from the audience in order to sustain myself. I'm not that kind of creator. I have a company that solves very expensive problems for large companies and that works out really well for, you know, keeping the lights on here.I'm not trying to disparage creators in any way, folks who are in a position of needing that to cover their lifestyle a variety of different ways. And even if they're well beyond that, I don't begrudge that to them at all. I mean, from a very selfish capitalist perspective, I don't want you to feel that you've paid your debt to me for entertaining you by sending me $5. I want you to repay that debt by signing a five-figure consulting agreement.Laurie: Yeah, those aren't really the same thing, are they?Corey: No, no. Turns out signing authority caps out at different places for different folks.Laurie: [laugh].Corey: Who knew? But it was a fun experiment. I'm glad that they're doing it. I'm glad to see Twitter coming out of its stasis for a long time and trying new things, even if we don't like some of them.Laurie: Well, they have this whole Super Follows thing now, and I got waitlisted for it the other day because they said they accepted too many people, whatever that means. I think—Corey: Same here.Laurie: Yeah, I think a bunch of us got that. And I'm interested, my sense is it's sort of like a Patreon hosted in Twitter sort of thing. And I've never had a Patreon; I have a mailing list that I made based on an April Fool's joke this past year where I made an entire signup workflow for the pre-order of my new book, The Art of the Subtle Subtweet. I was very pleased with this joke.This was, like, very elaborate: I had a whole website, I had a signup flow, and I now have a mailing list which I've done nothing with. So, I have all of these things, but that's not really been my—there's too many things to do as a content creator, and so I've sort of not explored most of those other avenues. And so, Super Follows, I was like, “This could be interesting. I could try doing it,” but, you know, alas, they don't want me to. So, [laugh] I don't know that it matters.Corey: It's an interesting problem, too, because at the start of the pandemic, I had a third of the Twitter followers that I do as of the time of this recording, which is something like 63,000. When I started what I do, five years ago, and I had just left a company which was highly regulated, so, “Don't tweet,” was basically their social media policy, it was a, okay, I had something like 2000 followers at the time. I was—it had taken me seven years to get there, let's be very clear here. And since then, my following has exploded, and yours has as well. You have, I think the last time we checked, was it something like 30,000 and change?Laurie: Yeah, something like that.Corey: And it changes the way that people interact with you. This is one of those things that there aren't that many people that we can have this kind of honest conversation with because let's be very clear here, for folks who have not established an audience like that it sounds absolutely like it's either a humblebrag—which I'm not intending that to come across that way—or it's one of those, “Wish I had those problems.” And in some ways, yeah, it's a weird problem to have, and it's also not a sympathetic problem to have, but something that has been very clear to me has been that the way that people perceive me and the way that they interact with me has shifted significantly as my Twitter notoriety has increased.Laurie: Yeah.Corey: I'm curious about how you have experienced that?Laurie: Yeah, so I'm half your size and especially in the front-end universe, there's plenty of people with between 100,000 to, you know, I think Dan Abramov is at, like, 400,000 at this point. Like—Corey: Oh yeah, my Twitter following would explode if I either knew JavaScript or was funny. Either one would just absolutely kick me into the stratosphere, but we work with what we've got.Laurie: I either don't know JavaScript or I'm not funny or maybe both because apparently not. But yeah, there's these huge, huge, huge, huge scales, and I'm sure by many people's judgment, pretty, pretty large. But comparing to other people in my ecosystem, maybe not so much. And I didn't understand it until I was living it. I actually had the opportunity to meet Emily Freeman at a conference in DC, probably… three years ago now, when I had less than a thousand followers. And I thought getting my first hundred was a big deal; I thought getting my first 500—and it is. Don't get me wrong. Those things are very cool milestones. And I [crosstalk 00:07:18]—Corey: I still celebrate the milestones, but I do it less publicly now.Laurie: Yeah, exactly. And I had a whole conversation with her and she gave me some really, really helpful advice: sort of, don't look at your follower count as it goes back and forth, five people, six people you'll think people are unfollowing you; they're probably not. It doesn't matter. And recognize that the larger you get, the more careful you have to be, and try to keep me sane before I was ever there. And it's all sort of come true.There's two things that have stuck out to me, I think, during the pandemic, especially. One is I can write the most nonsensical, silly tweet and people will like it because they think it says something insightful whether it does or it doesn't. They're projecting onto the tweet something funnier, or more relevant than the reason I wrote it in the first place. Which, okay, that's cool. I'm not as smart as you're giving me credit for, but sure.The other thing which is the downside to that is, everyone assumes that if they're having a conversation with me, they're having a conversation with me. So one-on-one, back and forth. That's not untrue, but I'm having a similar conversation in parallel with—if it's a popular tweet—a hundred other people at the same time. And what that means is, if you're being a little bit of a jerk, and a little bit troll-y, you're not being a little bit troll-y, you're being a little bit troll-y times the a hundred other little bit troll-y people. And so my reaction to you is not going to be necessarily equivalent to what you say, and that can get me in trouble. But there's no mental, emotional spectrum that was designed to work with the scale of social media.Corey: Oh, absolutely not. In fact, let's do an experiment now, while we're having this conversation. I am making a tweet as we speak. “Some mornings, it's just not worth chewing through the leather straps.” It's not particularly insightful.It's not particularly deep, and before the end of this episode, we will check and see what that does in terms of engagement just because you can say anything, and there's some folks who will wind up automatically engaging. And again, that's fine; everyone engages with Twitter in a bunch of different ways. For me, what's been very odd is I have talked to a couple of very large companies who I talk about on Twitter from time to time, and it turns out that they are reluctant to engage with me directly on Twitter or promote anything that I do or do retweets of me, not because of me, but because of an element of the audience, in some cases, of what people will chime in and say because it doesn't align with corporate brands and a bunch of different perspectives. Which, again, I have some sympathy for this; it's hard to deal with folks who are now suddenly given a soapbox and a platform that rewards clever insults better than it does meaningful heartfelt content, and that is something that I think everyone is still struggling with. Let's also be very clear here. I'm a white dude in tech; my failure mode is a board seat and a book deal.Laurie: [laugh].Corey: When I post something about Git, for example—which I did a few days ago—and someone responds explaining the joke back to me, my response to them was, “Thank you for explaining Git to me.” And that was all I said, and it's led to a mini-pile-on of this person because it's like—Laurie: Oh, yeah.Corey: “Don't you know who Corey is?” Yet I have seen the same dynamic happen with women tweeting about these things and it's not just one response that explains Git; it's all of them. And when people say—like, Abby Fuller, for example—Laurie: Yep.Corey: —will tweet about password manager challenges and how annoying some of them are, and it leads to a cavalcade of people suggesting password managers to her. That is not why she's tweeting it, and she explicitly says, “I do not want you to recommend password managers to me.” And people continue to do it. And I don't for the life of me understand what goes on in some people's heads.Laurie: Yeah. I mean, I've watched that happen countless times. I think the frustration—there's a point at which no matter how big of a following you have, you just want to be yourself. I think most people who get to that amount of interaction have been theirself most of the way, along the way. Or they're just being totally fake for the sense of growth hacking, in which case, okay, you do you.But most people, I think, are being themselves because it's exhausting to spend that much time on a platform and pretend to be someone else or be fake the whole time. So, I'm pretty much myself. And that means that sometimes when someone's being a total jerk, I really want to treat them and be like, “Yeah, you suck.” But the problem is when I say that, I'm siccing 30,000 other people on them to defend me. And I can't do that.So instead, I've become sort of famous for subtweeting. And I will wait a couple of days to do it, or I will totally change the framing of the situation so I can get out my same sort of frustration, and annoyance, and just needing to blow off steam, or venting, or whatever it is and not point at the person. Because if I point at the person, I discovered very, very quickly that there's a whole crowd of people willing to take them down. If they're being blatantly terrible, I will do it. There is a line here.Someone recommending that I use a different tool because I decided to bitch about TypeScript, for example, or telling me I don't understand TypeScript, okay, fine. Someone's saying, “You only have followers because you're a pretty girl.” Yeah, you're an asshole. No, I'm not protecting you. Also, by the way, I tweeted two minutes ago, do all tweets deserve a ‘like,' question mark, and we'll see how much that—Corey: Yeah.Laurie: —interaction gets. [laugh].Corey: I'm looking forward to seeing how that plays out. It's a responsibility, which sounds odd, but if I complain about a company, what I'm fundamentally doing is I have the potential to be calling out an airstrike on top of them. And not every customer service failure deserves that. I deleted all of my tweets prior to 2015 a while back. And the reason most people delete tweets, or the reason we hear about most people deleting tweets, there was nothing especially problematic in my tweets other than jokes that were mean in different ways and punching down in ways that I didn't realize were at the time.It was not full of slurs; it was just things that weren't particularly great. But that wasn't the real reason I did it. The honest reason was is that I looked at my early tweets and they were cringy beyond belief. I was shilling for the company I worked for in many respects, and there were swaths which I didn't engage with Twitter, and the only time I really did is I was out there complaining about various customer service failures, so it's just this neverending stream of complaints about different companies that had wronged me in trivial ways.Laurie: [laugh].Corey: And, I don't know at some point if somebody is going to build something where it's easy to explore early tweets of a particular account. I don't want them to do that and then figure out that this is how you get started being me. It's like, I succeeded in spite of that nonsense, not because of it. And it's not something good that I want to put out into the world.Laurie: Yeah. So, I have, I think, only once added a company when I was having a customer service issue on a weekend, and we were in really dire straits. And I was just like, “Okay, it's a weekend. I'm going to at.” And I've never gotten a response so fast.And my husband looked at me and he was like, “Wait, what?” And I'd done this with an ol—I have this really ancient Twitter account that I got rid of because I was mostly just screaming about politics [laugh] and I didn't want—I think I got @laurieontech in like, 2016, 2017—and I'd done that before. I'd been like, “Hey, you know”—I'm making something up—“At Spirit Airlines”—they seem like an easy one to—I've never flown Spirit, so—but I mean, I never got a response. And so there—realizing that you have power from a brand perspective is really weird.But I almost want to go back to your point when you were talking about when you worked for a company and you had your account and, you know, they don't want you to tweet, basically. Or companies are not going to tweet at you now, in your current state. I think it's really hard to be a company on the internet in tech because you're either going to make a joke that lands well, or everyone's going to think that you're shilling for yourself. There's no in-between and so—this is a hot take and I might get in trouble for that—companies have realized that the best way to get around that is to hire people who have their own personal names and get your company name associated with them. And all of a sudden, it looks less disingenuous.Corey: And even that's a problem because I've talked to companies who are hiring folks with large followings for DevRel style jobs, and—I've interviewed for a few of those, once upon a time, about midway through when I was debating do I shut this consulting thing down and get a real job again because that's always how I sort of assumed it would be for the first couple years. And then, “No, I'm going to get serious about it.” And I took on a business partner and got very serious, and here we are. But talking to folks, my question was, in the interview process, I would talk to my prospective manager and ask questions of the form, “So, what is your plan for when we eventually part ways? How are you structuring that?”And they looked at me like that was a bizarre question. It's, understand that, done right, my personal brand will, in some areas and some corners, eclipse that of the company, so as soon as I leave for whatever reason, the question is going to be, “Were you mistreated? Did someone wrong you there? We'll drag them just preemptively on the off chance.” And you need to have a plan in place to mitigate some of that and have a structured exit for what that is going to look like. And they looked at me like I was coming from a different planet. But I still think I'm right.Laurie: You are right. And, oh goodness, I've seen this in a lot of different places. I mean, I have left companies in the past and I have had to decide how I was going to position that publicly. And how much I was going to say or not say, how complimentary I was going to be or not because the thing is, when you leave a place, you're not just leaving the company, you're also leaving your colleagues. And what does that mean for their experience?You're gone. You don't want to be saying, “Hey, this place is horrible, while your really close friends you were working with on Friday are still there.” At the same time, companies don't think about this from the DevRel perspective and, I want to be very clear, I have friends who work in DevRel who are themselves brands. They are all fantastic people; they work incredibly hard; this is not a knock on them in any way—Corey: It looks easy from the outside. I want to be very clear on that.Laurie: [laugh]. It's not easy. All this stuff is great, but part of the reason I decided to go to a place like Netflix is because I knew my brand had no bearing on them and so I could be myself and just do my own thing and they weren't going to try and leverage me, or there was no hit to them based on who I was. Granted, did I go after someone the other day, sort of, in deep in a thread for being a jerk and did they try and at Netflix engineering and say, “Is this the kind of person you want representing your brand?” And at egghead.io, “Is this the kind of person wanting your brand?” Yeah, they did.So, that part's still a problem, but that's a problem for me rather than being a problem for my company, if I decide that, you know, I don't always want to—like, no one cares if I talk about the new Marvel show. No one cares. I like Marvel; I'm allowed to like Marvel. I also love the stuff on Netflix, right, but when you're at a company that isn't like that, honestly, when I was at Gatsby, I couldn't be tweeting about Next or Nuxt, or even Vue for that matter, because it just doesn't look right. Because my brand had more of an impact in that smaller pond than it does now.Corey: People have said, “Oh, well, what if AWS acquires you so you can work on their behalf?” Or, “What if Google acquires you?” Or something like that, and it's—what people don't get is that my persona—again, to be clear, I am genuine on Twitter. I emphasize aspects of my personality, but I don't get up there and say things I don't necessarily believe. We'll get back to that in a minute.But what I do as a small company, making fun of trillion-dollar publicly traded entities is funny and it works, but if suddenly I work at a different publicly-traded company, it just looks like I work for my employer, bagging on a competitor. And even if I'm speaking in ‘an opinions my own' sense, which is apparently Amazon's corporate motto, based on how often I see it in their employee's Twitter bios—Laurie: Oh, yeah. [laugh].Corey: —is going to be perceived as me smacking at a competitor regardless. Further, I will not be the person that craps on my own employer on Twitter because that sends terrible signal in many respects. I won't even crap on previous employers who frankly kind of deserve it because when you do that, it does not look good to people who are not familiar with the situation, and no one's as familiar with it as you are. It just looks like sour grapes, regardless of how legitimate your grievance was. To be very clear, I'm not saying don't call out abuse when you encounter it—Laurie: Yeah.Corey: —that's fine. I'm not going down that path—Laurie: Yeah, yeah, yeah, yeah.Corey: —let's clear here. But, “Yeah, they have a terrible management culture, and they don't promote internally, and I hate those people,” it just makes you look bad, and it doesn't help anything.Laurie: Yeah. I had always made a commitment to never talk about a former employer in any way that was easily identifiable. I've changed that policy a little bit. There's a story I shared a couple of times where my CEO didn't want to give me a pay raise because he thought it was my parents' and boyfriend at the time's job to take care of me financially. Like, that kind of stuff, I will say publicly.No one's going to know who it is; you'd have to go back and figure it out and, like, you don't have enough context so how would you know? But it's stuff like that, that I'm like, okay. I don't want to hide stories like that because that's not protecting anybody.Corey: No, I'm not talking about covering up for misbehavior. I'm talking run-of-the-mill just bad management, poor company culture, terrible technical decisions, et cetera. Yeah, if it's like, yeah, they sexually harassed every woman on the team, out. Yeah, tell that story. I—thank you, I should absolutely clarify my stance. Heaven forbid I get letters.Laurie: But yeah, it's the problem is that you can't—and everyone has a slightly different experience with this, but from what I've seen, it doesn't matter if you say their management is shitty and they didn't promote versus there was a ton of sexual harassment. If you're one person saying it—if it's the Blizzard situation where there's tons of receipts and it's made it into national media, then that's a little bit different. But if you're one person saying it about one company, people are going to think it's sour grapes. And unfortunately, it doesn't reflect on the company; it reflects on you. So, unless there's a sort of like, where there's smoke, there's fire situation where a bunch of people are doing it at once, you have to weigh stuff really carefully.Especially because your next employer doesn't want you out there talking about your previous employer because then their fear is what are you going to say about them when you leave? There's lots of nuance and it gets—if you are screaming into the void—we're screaming into the cloud here—Corey: Ahhhh. Yes.Laurie: Ahhhh. [laugh]. If you're screaming into the void, it doesn't matter if you're you. And I mean… [sigh] I hate saying, “If you're me,” right? That's such an obnoxious statement to make, but at 30,000, they probably care.Corey: There are inflection points. I started seeing—around 40,000 is when I started seeing a couple of brands reaching out to me to, “Hey, you want to promote some nonsense.” And I've never sold any social media promotion for anything. I sell sponsorships for newsletters, this podcast, I do webinars stuff, I do paid speaking engagements. My Twitter account is mine.It is not the company's and that is by design. It's me; that's what it comes down to. That does lead to challenges in some arenas because I talk to companies about their AWS bill and these companies do not have much of a sense of humor about spending tens of millions of dollars, in some cases a month, on a cloud provider. These are serious problems and they're a little worried, in some cases, the first time we have conversations that they're dealing with some kind of internet clown.Laurie: [laugh].Corey: And often with talking to folks to convince them to come on this podcast, it's, “Look, this is not me dragging you and making you look awful because if I do that, I'll never get another guest again.” And if I do it in the context of a consulting project it's, “That was a hilarious entertaining intro here. Get out and never come back.” It is not useful. People have generally taken a risk personally on bringing the Duckbill Group in.If we can't deliver and cannot present professionally, then they have some serious damage control to do, for a variety of excellent reasons. And we've never put someone in that position and we won't. I talked to brands who sponsor all of these things, and the ones that are the best sponsors intrinsically understand it, that [unintelligible 00:23:56] once I start getting after some serious maleficence style stuff—no one is going to not do business with you because I make fun of your company on Twitter—Laurie: Yeah.Corey: —but an awful lot of people are going to hear about you for the first time and advertising in the newsletter and having fun with that, or I talk about you in the podcast ads, it winds up being engaging in many cases depending how far I can stretch it. And it works. I did a tour at re:Invent last year—virtual re:Invent—where I led a Twitch tour for an hour around the virtual expo hall into a bunch of different sponsored virtual booths and made fun of them all, and I got thank you notes from the sponsors because that led to a bunch of leads because people cared about the—oh, people paying attention because Amazon did a crap job of advertising the Sponsor Expo. And it was something that people could grasp, and have fun with, and get attention for. It's top-of-funnel work and that's fine, but I just don't do it with the boring stodgy stuff. I like to have fun with it. Bring a personality or don't bother.Laurie: Yeah. And you can't take yourself too seriously. I'm not the stand-up comedian that you are. I like to fashion myself as a little bit funny but not that funny. I'm not a stand-up comedian and I don't have a consultancy to represent anymore.There was a time where I did; I was not the owner of it but I worked there. So, now it's sort of, I represent me, which is good in the way that you say it. Like, it's clearly you. It's not Duckbill Group; it's your account. But at the same time, it freaks me out when in real life people know that it's me.So, in my brain, Twitter is the internet and I have my actual real day-to-day life, and never the two shall cross. [laugh]. And my—one of my—I had this popular tweet where I talked about all the companies I'd been rejected from, and it turned into a bit of a retweet situation with everyone sharing all these companies that they'd been rejected from. And the screenshots made it onto LinkedIn and made it into my cousin's feed, and she sent me a text message with a screenshot. And she's like, “You're on my LinkedIn.”And I was like, “No, no, this is not okay. This is not”—I have my little circle of the world and it should not expand beyond that. I go to a conference, even a tech conference, and someone's like, “Oh, you're blue shirt, crossed arms.” I'm like, “No, this is not okay.” Like, [laugh] I only exist on the internet.Corey: This episode is sponsored by our friends at Oracle HeatWave is a new high-performance accelerator for the Oracle MySQL Database Service. Although I insist on calling it “my squirrel.” While MySQL has long been the worlds most popular open source database, shifting from transacting to analytics required way too much overhead and, ya know, work. With HeatWave you can run your OLTP and OLAP, don't ask me to ever say those acronyms again, workloads directly from your MySQL database and eliminate the time consuming data movement and integration work, while also performing 1100X faster than Amazon Aurora, and 2.5X faster than Amazon Redshift, at a third of the cost. My thanks again to Oracle Cloud for sponsoring this ridiculous nonsense.Corey: My business partner was, a week or so ago, at a cafe and someone came by and saw his Last Week in AWS sticker on his laptop. It's like, “Oh, you read that, too? I love Corey's work.” Turns out the guy works at IBM Cloud. And yes, you should hear the air quotes around the word, ‘cloud' in there. But still.Laurie: [laugh].Corey: It's—I haven't been out in the world since I really started focusing on this, and now it's—like, I wear a mask so it's fine, but I'm starting to wonder, am I going to get stopped on the street when I go back into the universe out there? And it's weird because you can't really unring that bell?Laurie: No.Corey: It's a weird transition, and on some level, it's constraining in some ways. Like, at some point of celebrity—I don't know if I'm there yet or not—there's going to become a day where I can't just unload on a waiter for crappy service at a restaurant—not that that's how I—Laurie: I mean, you shouldn't do that anyway. [laugh].Corey: —operate anyway—without it potentially going viral, and, “Oh, he's a jerk when you actually get to know him.” And everyone has this idea of you and this impression of who you are, based upon the curated selection of what it is you put out into the world. I've tried to be as true to life as I can on this. In conversations, I generally don't drop nothing but one-liners, but I think I'm pretty true to life as far as how I present on the internet versus how I present in person.Laurie: More than I expected, to be honest.Corey: Yeah. That also does surprise people. Like, they think there's some sort of writing team behind me. And it's, if you look at the timing of some of my tweets where I will respond with a witty, snarky thing in less than a minute, it's, I wish I had a writing team with that kind of latency. I think that'd be terrific.Laurie: I always assumed it was you, but I figured there was like a persona that you turn on and turn off and I realize now that it's an always on sort of thing. [laugh].Corey: One thing I did experiment with for a little bit was having my team write tweets for my approval to promote episodes of this podcast, for example, because I am not the sort of person going to sit there and build the thing out correctly and schedule at the right time. And I have people who can do things like that, but it's the sort of thing that led to a situation of never getting much engagement and those tweets never did very well, so why even bother? We have a dedicated Twitter feed for that stuff and everyone's happier. Especially since I don't have to share access to this thing through anyone. Speaking of, let's see her tweets did.Laurie: Oh, yeah. Okay, hold on. How'd we do? All right. So, I have, “Do all tweets deserve a like?” Was posted 19 minutes ago. It has 12 comments, 1 retweet, and 22 likes.Corey: My, “Some mornings, it's just not worth chewing through the leather straps.” Was posted at a similar timeframe has 10 likes and 3 replies. Someone said that, “Organic, eh? Probably better than nylon.” Someone said, “Is this an NDA subtweet?” And someone said—with a GIF of Leonardo DiCaprio, saying, “You had my curiosity. Now, you have my attention.” That's it. So yeah, not exactly a smash-it-out-of-the-park success.Laurie: Yeah, but I got to say, “Do all tweets deserve a like?” Is pretty mundane. For that amount of response.Corey: You included a question mark, which is an open invitation—Laurie: Oh, right.Corey: —to the internet randos to engage, so there is—Laurie: Oh, yeah.Corey: —a potential there.Laurie: I going to have to retweet this and say that I'm not grifting and it was done for this podcast [laugh] and they should all listen to it. [laugh].Corey: Oh, of course. By all means. I am thrilled in any point to wind up helping people learn more things about the environment.Laurie: [laugh].Corey: I want to thank you so much for taking the time to speak with me. I have to honestly say that I wasn't quite sure what was coming, but of all the things you could have asked me to predict about this episode, not talking about how Netflix works in cloud was absolutely not one of them. So wow, are you sure you work at Netflix? That's one of those odd moment things.Laurie: Yeah, I got to say I'm pretty abstracted from the cloud these days, so that—maybe that means that I don't know enough to talk about it intelligently.Corey: I would argue that extends to lots of folks. To be clear, Netflix has a lot of really neat thing.Laurie: That never stopped anyone before? Bu-dum-shh.Corey: Oh, yeah. It's like, I like to get up there, sometimes I'll talk about how we do things at Netflix, periodically, on conference stages even though I've never worked there, but people don't correct me because why not? I'm a white man in tech. And I say something, of course, it's right. It's just—if you don't want them to get right, you just don't have enough context. That's the rule.Laurie: Corey, I'm going to need you to take the last minute or so of this episode, and please explain your feelings on how to optimize your use of JavaScript on the front-end, please.Corey: Oh, wonderful; you pay smart people who know what they're doing to look deep into the JavaScript side of it—Laurie: [laugh].Corey: —because honestly, every time I've tried to get into JavaScript, I go back at it and I feel even more foolish than when I started. Async stuff just completely blows my mind, especially by default. How in God's flat earth is that supposed to work? And—Laurie: You work in cloud. [laugh].Corey: It doesn't make sense to me, in a clear sense. At least with Python, which is the—I would say it's the language I know best, but it's not. Crappy Python is. And I can at least do things top to bottom and it works about like I would expect unless explicitly instructed otherwise. But the JavaScript world is just a big question mark and doesn't work the way that I would expect to. To be clear, the failure here is entirely mine.Laurie: ‘JavaScript is a big question mark and doesn't work the way I would expect it to' should be JavaScript's tagline.Corey: That's fair because I have this ridiculous belief from the Dark Ages—because I spent 20 years as a systems admin—that computer behavior should be deterministic and if there's one thing that we learned about the internet, it's not.Laurie: Yeah, no. There's that whole user thing, and then that whole browser thing, and then that whole device thing. It's a whole bunch of non-deterministic behaviors. Just stick to the cloud, and there's one consumer and one producer, and you're good.Corey: One thing I will say—in the moment of pure seriousness here—is that if I were looking at getting into tech today, the first language I would learn would be JavaScript. It is clearly the way of the future. It is a first-class citizen on every platform out there. It is the lingua franca of, effectively, everyone coming out of a boot camp. And it is going to be the way that computers are built.I say this not from a position of being an advocate for JavaScript. I don't know it; I can't stand it personally, but it is clear as day to me that is the direction the world is moving in, so if you're debating what language to pick up, you'd be hard-pressed to convince me not to recommend JavaScript as the first one.Laurie: And do you want me to be my serious self, and you're going to laugh at what I'm about to say?Corey: Hit me with it.Laurie: If you're looking to get into technology because of boot camps and some other things, we have an oversaturation of newbie front-end developers and they're all way more talented than I was at that point in my career, and yet there aren't nearly the front-door opportunities for being a—I hate the term junior, but newbie. And where there is the opportunity, it's cloud. And security.Corey: I will absolutely point out further that I understand this runs the risk of being ‘boomer gives career advice'—Laurie: Yeah, right? [laugh].Corey: —but let's be clear here. I think that if you are going to enter the front-end space—and this does speak to cloud and it speaks to security as well—distinguish slash differentiate yourself by having another discipline or area of intense interest that you can bring into it as well because when you have a company that's looking to hire from a sea of new boot camp grads that generally tend to look more or less identical from a resume perspective, the one that will stand out is the one that can bring in another discipline and especially if that niche winds up aligning with a company's business, or at least an intense interest in something that is directly germane to the company, that will distinguish you. And everyone has something like that; no one is one-dimensional. So, find the thing that is the in-between space, and focus on finding jobs in companies that do those things. And if you're a mid-career switcher, let me be very clear here.It is not a go back to entry-level roles-style story. I've never understood that philosophy. I do have steps from thing I'm doing now toward thing I want to go to. Well, is there a job I can find to do next that blends the two of them together in different ways, and then once I'm there, then make a further transition. And of course, find someone who's—in any career, in any path you're on, find someone who is five years ahead of you, and ask them for their advice.“What would you do in my shoes?” If the answer is, “Go to a boot camp,” okay. Talk to a few people who've done this and make sure it validates it. If it's, “Get a degree,” okay, but make sure you're not doing it because you think that's what you're supposed to do. You'll very rarely find me recommending six figures of debt in order to advance your career, but there are occasions.By and large, they'll find someone who's been there before who knows what's going on, you can have a conversation with and give them context appropriate to your situation and then see what's right. We turned this into last-minute career advice and I'm not even—I don't even [unintelligible 00:34:45] have a problem with that.Laurie: Well, I was about to say that it's 2020. 21 2020—wow, I—you knew what I meant—it's 2021, and I guess I need to start taking my half-steps towards becoming a Lego master before I retire. [laugh].Corey: Oh, yes, the Lego world is vast and deep, and they have gotten no worse since I was a child at separating parents from money to buy LEGO sets. My daughter's four and his way into them already. So, it's great. It's something that we can bond over.Laurie: If I ever have kids, we're going to need separate sets because they're not touching mine. [laugh].Corey: Yeah, I'm looking at stuff like, oh, well, I'd love to buy that awesome big Star Destroyer—wait, it's how much money? And it turns into this—yeah. It's wow, on some level, I never ever thought I would find a hobby that was more expensive than my mechanical keyboards hobby, but here we are.Laurie: Oh, yeah, I blame Cassidy Williams for getting me into that one, too. I have a shiny one beneath me. And that's my first.Corey: She is a treasure and a delight.Laurie: She's a treasure, a delight, and dangerous if you want to save money because she will draw you into the mechanical keyboards, and there's just, there's no resisting. I tried for a very long time. I failed, ultimately.Corey: One of these days, she and I are going to have a keyboard-off at some point, once it's no longer a deadly risk to do so. It'll be fun.Laurie: Do it.Corey: I'm looking forward to it. Thank you so much for taking the time to speak with me. I really appreciate it.Laurie: Absolutely. Thanks for having me.Corey: Of course. Laurie Barth, senior software engineer at Netflix, also instructor at Egghead, also a member of the TC39 Educator Committee, and prolific blogger. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with a horrifying comment explaining anything we just talked about, back to us.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

Listen to the Future of Coding Podcast: https://futureofcoding.org/episodes/011 (30ish mins in)3 Lessons Learned: Features over Benefits- original was a tutorial - second time: here's why react is different. Focus on the implementation rather than how to use it- Sophie Alpert, Dan Abramov, Cheng Lou Support everybody: IRC, Stackoverflow, RedditInfluencers - David NolenBigger conferences, F8, ReactConfPublic user WikiHaters - view every hater comment was your fault Table stakesDocumentationInclusive communicationThree single sentences to communicate why your project is different and worthy of someone's attention - real reasons with tradeoffs, not "faster, smaller, lightweight" Transcript [00:00:00] swyx: Hey everyone. I'm coming to you today from the Infoship shift conference where I just gave a talk on the third is your JavaScript. And it's got me in a mood to look back a little bit on the history of some of the JavaScript frameworks and what better history to cover it, then react, which is something I know. [00:00:17] Well, but I think the history of react is not that well-documented and people. Should hear it from people who are there. The central question, which occupies a lot of my waking thought is how to get developer tools adopted. And there's no better case study than most, no more successful case study than react and how it overcame its initial difficulty. [00:00:38] Here's original reactive team member, Pete hunt on the future of coding podcast.  [00:00:43] Pete Hunt: It took a lot of time to figure out how to message this. Because he can't just come in and say like, everybody's wrong and we're right. Blah, blah, blah, blah, blah, blah. That's not that's not really, you did that a little bit. [00:00:55] Which, which talk. So there was the original JS coffee us talk where we came in and we said, Hey, this is how we build user interfaces. At the time. And it was just like a tutorial. And then there's another way, which was the second top, which was the one that I did, which was basically like, Hey, here's why react is different. [00:01:15] The argument that we were trying to make is that, Hey, this is these are the problems that we had. Here's the solution we came up with and here's what makes our solution. And we had a lot of caveats in there that said, Hey, this might not work for you. There are these certain edge cases where it's actually slower than what you're doing today, but what we found was this was a better set of trade-offs and really what we focused on was. [00:01:40] Educating people on how to use react or how to build their next application with it. It was more about this is what makes it unique and interesting. And what that did was it disarmed people. They were like, oh, this is actually really interesting. We focus much more on the implementation in that than the, how to use it. [00:01:56] And people appreciated that. And the second thing it did was it recruited people into the community that were really passionate about what it does differently. And so you see. These big shots in the react community now like Sophie Albert, and Dan Abramov and Cheng Lou and all these, these people they originally recruited because I think they found the internals of react to the interesting or at least some of the ideas around it to be really interesting rather than, oh, I built my, my application and, three less days than it otherwise would have taken. [00:02:25] Steve Krause: From my perspective it seemed like react was inevitable and it just happened magically, but you were more on the ground floor making it grow. And it seemed like, like you find around the conferences telling people about evangelizing it. [00:02:38] So could you talk through like how it became adopted how, how that felt. Like w what were like some of the key milestones or like key the key things that happened that like made it like moved along.  [00:02:50] Pete Hunt: Yeah. So there was JS con you asked, which was the original announcement. Everybody hated it. Then there was JS con EU which got some more people excited about it. [00:03:00] We wanted to support everybody a lot. So we were in IRC, like almost 24, 7. People would come in and ask a question and we would answer it. Some people would, would camp on stack overflow and answer those questions. But basically like the, the idea was we wanted to recruit and, and basically keep those people engaged in the community because hopefully they could help out. [00:03:20] And that ended up working out nicely. So the number one thing was like just supporting the hell out of people that  [00:03:26] the second big milestone that happened was when David Nolan got involved. And brought in the closure script community. And they, he wrote this blog post called the future of JavaScript MVCs and he was kind of like, Hey, this reacting solves a missing piece that we've had in the closure script community for a long time. [00:03:44] And it's got a programming model that I really like. So that was a big noticeable uptick in the use of reaction. So again, what we're doing right now is, is recruiting. Passionate early adopters and started to slowly turn into some real production usage of react outside of the Facebook companies. [00:04:06] And then fast forward, maybe a year we are so flux is introduced and that solves a problem that the community had. We started talking at kind of bigger, more corporate-y conferences like Facebook's FAA, and then eventually put on a react. For all of the users and then that sort of to inspire a lot of confidence in people to use react. [00:04:28] And so then all these big companies started actually using react. And once you've got some PR real-world production usage, we had this Wiki page where people could add a link to their, their service and where they were using react and Redux. And we would point people to that when they're like, Hey, my boss doesn't know if I should use this new technology. [00:04:48] We said, well, did you know that Facebook is using an Instagram is using it Airbnb and the New York times and all these other, other well-known brands. So that was, that was helpful to then, we just started to see this big explosion in, in the usage of the, of react throughout the community. [00:05:05] The snowball was, was rolling down the hill at that point. React native was another big milestone in, in reacts kind of adoption because that opened up the world mobile developers.  [00:05:14] So I I found react because of David Nolan's article that you mentioned. And I was immediately convinced after reading that article and then watching your rethink, rethinking best practices talk, which, which I think he links to in the, yeah. [00:05:26] In that essay. So I can definitely see how that was a big milestone. I didn't realize how big of a milestone that was in your mind, but, but that's, that's how you got me.  [00:05:34] So makes sense. Yeah. That wasn't an accident either. So like there's a lot of, I was going to conferences and I was connecting with people on Twitter and stuff like that. [00:05:44] And the way that got put together was. There's this guy, Brandon bloom, who's a game programmer who you guys should all follow on Twitter cause he's he's really smart. And he sent me a message or tweeted at me or something and he was like, Hey, I saw your talk. Did you know that this is how like all game engines are implemented? [00:06:05] And I was like, what? I don't know very much about graphics and, and he taught me through it and explained it to me. And he's like, He was in New York and I was like, oh, I'm flying to New York. We should meet up. So we met up over a cup of coffee and he's like, I'm going to bring my friend David Nolan. [00:06:20] And he's going to, he's going to come sit in on our conversation. And so us, the three of us were just at a coffee shop somewhere in New York talking about react. And then he pops into the IRC channel, has a bunch of questions as he's building his first version of his react bindings. [00:06:35] Kind of, again, continuing this, this level of support that we had and that blog post pops out and changed the game for, for react. So that was, that wasn't like, oh, I stumbled upon this technology. And I was struck by how awesome it is. It's like none of this stuff, I'm like, yeah, things go viral, but they go viral after a lot of boots on the ground effort. [00:06:56] Steve Krause: Ah, I'm so glad that that's But that's how it actually happened. Cause it that's so empowering that like, it isn't just random. What goes down on what doesn't, if you work really hard and do the work, it'll eventually work out. So I'm really glad that that's how it happened in reality. And that I have it on this podcast. [00:07:12] That's really inspiring.  [00:07:14] Pete Hunt: Yeah. Yeah. I mean, there are things you got to get, right? Like you gotta write documentation and you got to build a community that you need to foster community that that is inclusive and gets everybody excited about working on this. And you need to also communicate your project really well. [00:07:28] So you need to say, Hey, this is why you should pay attention to our project. And it's got, you get like three bullet points, three single sentences to communicate why your project is different and worthy of someone's attention. And like it's faster and it's smaller and it's lightweight. Real reasons like you got to sacrifice something, right? [00:07:50] Cause otherwise react would be smaller, lighter weight. Right. So what are you sacrificing?  [00:07:54] Steve Krause: Totally. So one thing I saw on the internet that caught my attention when I was preparing for this interview is that there was a quote where you talked about how you replied to every hater comment on Twitter. [00:08:04] And is that, is that something that you thought was effective? Do you still do that now?  [00:08:09] Pete Hunt: Tell me more about that. Oh yeah. That was actually Reddit. So we would post it to Reddit and there would just be like, all of these salty programmers would just reply and trash on like, oh my God, you're putting HTML in your JavaScript. [00:08:22] That's so bad. Or like who is Facebook to tell us how to build applications when we have this thing from Google and Google's wait, got way nicer products than Facebook whatever it is. And our, to every single one of those. Yeah. You know what, like some of these people had legitimate concerns. There's, I've actually found in my personal experience, there's very few real trolls that are just trying to troll and just trying to piss you off. [00:08:50] There's a lot of arrogant people and there's a lot of people that have strong opinions and don't do a great job of expressing them in a respectful way. But their goal is not to piss you off. They actually have legitimate concern. And the way that I thought about it was I, I viewed every single one of those concerns as my fault, because either the technology didn't do what it needed to do, or they, as in, they had a legitimate technical concern or they didn't have a legitimate technical concern and we failed communicating that to them. [00:09:21] And so if you just say. Hey, all of these complaints on Reddit are actually legitimate or have a kernel of truth to them. And they're all my fault. You start to do a lot of self-improvement really quickly. And so that's why I think the messaging around react got to be I thought very, very crisp within the first nine months. [00:09:41] Yeah. Of it being open sourced and that that messaging like branding it, the virtual Dom that now gets a lot of flack and criticism, but I stand by it, it's not a hundred percent accurate, but if you've got someone's attention for five minutes and you want to explain how react works, a virtual time is like a great way to do that. [00:10:00] swyx: Okay. So there were a bunch of very important lessons here. So just to recap, the first is to talk about features over benefits. This is the exact opposite from traditional marketing, where you talk about benefits over features. When reacts was initially introduced, they were trying to introduce them as a tutorial. Like we can do this. This is how you use react.  [00:10:21] And you can code, uh, so-and-so faster than you would normally code. And people really reacted against that. But the second time they introduced react, they focused on why react is different focused on the implementation rather than how to use it. And that actually successfully nerds sniped, the second generation of react core team members like Sophie, opport, Danny Mamava.  [00:10:40] VIN Chang Lu. The second tip after the features of a benefits thing is to support everybody. And they really mean everybody. So camping out in IRC stack overflow and Reddit. Supporting influencers like David Nolan. Supporting haters. Bye Andre. On Reddit by viewing every hater comment as if it was your fault.  [00:10:59] And then building more social. Social momentum. With bigger conferences like Facebook, F eight, and then throwing their own react con. And then also publishing a public user Wiki so they can see. Other companies like them using react. Finally, you have to have your table-stakes. So the table stakes that were mentioned were documentation.  [00:11:20] Inclusive community. And three single sentences to communicate why your project is different and worthy of someone's attention. Real reasons with trade-offs not just, we are we're pleasing faster, smaller, or lightweight, actual reasons. So I thought this was very jam packed with. Really good lessons. 

Kimmo Brunfeldt a software developer and an entrepreneur joins Ari Koponen on the Frontend Greatness podcast to talk about "Automated Visual Testing." In this episode: - Common challenges with visual testing - Tools for visual testing - Discussion on if visual testing worth all the trouble --- Episode Notes Social - Kimmo on Twitter: https://twitter.com/kimmobrunfeldt - Ari on Twitter: https://twitter.com/apkoponen Show Notes - Swarmia: https://www.swarmia.com/ - PhantomJS: https://phantomjs.org/ - CasperJS: https://github.com/casperjs/casperjs - SlimerJS: https://github.com/laurentj/slimerjs - Puppeteer: https://github.com/puppeteer/puppeteer - Playwright: https://github.com/microsoft/playwright - Squint: https://github.com/kimmobrunfeldt/squint - Cypress: https://www.cypress.io/ - Percy: https://percy.io/ - Chromatic: https://www.chromatic.com/ Kimmo's Recommendations - Frontend Focus: https://frontendfoc.us/ - Dan Abramov's blog: https://overreacted.io/

[קישור לקובץ mp3] שלום רב וברוכים הבאים לפרק מספר 416 של רברסים עם פלטפורמה - התאריך היום הוא ה-27 ביולי 2021, ואנחנו נפגשנו ביוקנעם באולפן הבייתי יחד עם יונתן ואסף - היי חבר'ה, מה נשמע? - יונתן, מה שלומך? מתאושש מהג'ט לג הקטן? - (יונתן) כן, הבאתי לך טובלרונים לאחרי . . . (רן) איזה כיף זה הטופי הזה שנתקע בין השיניים . . . - אז אסף - ברוך הבא! (אסף) תודה רבה(רן) היום אנחנו נדבר על נושא Frontend-י - אנחנו לא מדברים הרבה על נושאים Frontend-ים, אבל היום אנחנו נקדיש את כל הערב הזה ל-Frontend - ובעיקר, באופן ספציפי - ל-State Management ב-Frontend.אז עם זה אסף מגיע אלינו - אז אסף, בוא נכיר אותך: מאיפה אתה בא? מה אתה עושה? ספר לנו קצת עליך וקצת על החברה שלך.(אסף) אז אסף קרינצה, אני בא מתל אביב עד לפה ליוקנעם . . .אני מתכנת - התחלתי לתכנת מקצועית בערך לפני עשר שניםהתחלתי את הקריירה ב-CheckPoint, הייתי שם בהתחלה בתחום שהוא יותר Security, אחרי זה עברתי להיות מתכנת ואז ראש צוותאחרי זה עבדתי ב-Microsoft וב-Soluto [עדיין טרי - 413 GitOps with Yaron from Soluto]לאורך השנים עבדתי גם ב-Backend וגם ב-Frontend - וב-Frontend יצא לי להתעסק בהרבה State Management Solutions: לחוות אותם ב-Production, לעבוד איתם בצוות - וגם בפרוייקטים בבית התנסיתי בכל מיני.אחרי Soluto - בעצם בספטמבר האחרון - עזבתי את העבודה, אני ועוד שני חברים טובים שהם גם שותפים, אחד מהם עבד איתי ב-Soluto ואת השני פגשתי עוד ב-CheckPoint - והקמנו חברה בשם livecycle.כש-livecycle זו חברה שעוסקת במוצר עבור צוותי פיתוח - אנחנו מרימים סביבות - Preview Environments - מתוך ה-Source Code של הלקוחות שלנובעצם, הרעיון הוא שעבור כל Change, כל Commit - אנחנו עושים תהליך שהוא דומה לתהליך CI, של לבנות - לעשות Build - למוצר, ואנחנו גם עושים לו Running, בענן.בעצם, יש “סביבה חיה ובועטת” של כל גרסא של המוצר - בענן - שאפשר לשתף אותה.מעבר לזה, On top that - אנחנו שמים כלי קולברציה (Collaboration Tools)לדוגמא, אפשר לדמיין שיש מעצבת בצוות, ומתכנתתהמתכנתת עשתה שינוי בקוד - ושולחת למעצבת, שאולי עיצבה את הפיצ'ר הזה - לינק.המעצבת תוכל להיכנס ללינק, לראות גרסא חיה שלו - ממש גרסא של המוצר, לא איזה Mock - וגם תוכל להגיב שם, עם הכלי קולבורציה שלנוהיא תוכל לשנות CSS - נגיד “ה-Margin לא מספיק טוב”היא תוכל לעשות Screenshot ישירות, בלי Tooling חיצונילהקליט וידאוכל הדברים האלה באים “בחינם” - בלחיצה של לינק . . . וכל זה רץ לו על הדפדפן.(רן) אז אתה אומר - יצרת Pull Request או Merge Request, תלוי באיזו פלטפורמה אתה משתמש - ואז באופן אוטומטי נוצר לך איזשהו Preview link שאותו אתה יכול לשלוח, עוד לפני שעשית Merge, זאת אומרת - אתה לא צריך ללכת ועשות Deploy כדי שהסיפור הזה יעבוד, ופה חוסך זמן ומייעל את ה-Cycle . . .(אסף) נכון . . .(רן) בסדר . . . אצלכם, דרך אגב, יונתן - יש פתרונות בסגנון הזה?(יונתן) Preview כזה אין לנו . . . יש לנו סביבות Pre-Production, שלשם אנחנו מעלים גרסאבאמת בדרך כלל אחרי Merge, כמו שאתה תיארת.(רן) כן, אוקייאנחנו בעצם נפגשנו פה כדי לדבר על State Management ב-Frontend.עכשיו, אני מניח שכל מי שמפתח Frontend בעשור האחרון מבין על מה מדובר, אבל בוא נחבר גם את מי שהוא לא מפתח Frontend, זאת אומרת - למה צריך State Management?יש לי CSS, יש JavaScript, יש HTML . . . על איזה State בדיוק אנחנו מדברים פה? למה צריך State Management?(אסף) אחלה . . . אז אפשר באמת להתחיל מלהגיד מה זה State, ומה זה בעצם עושה באופן כללי, וספציפית באפליקצית Web.אז אפשר להגיד ש-State זו איזושהי “פיסת אינפורמציה”, שמגדירה איך נראית האפליקציה בכל רגע נתוןאיך היא נראית ואיך היא מתנהגתלדוגמא - זו הדוגמא הקלאסית, כשמדברים על State Management, יש כזה את ה-”Hello World” שזה ה-To-Do Applications - כשיש לך רשימת To-Do's כזאת, ה-State יכול להיות האינפורמציה, Array של To-Do's, כשכל אחד מה-Item-ים ברשימה יכול להיות אובייקט - שיהיה לו Title ויהיה לו “?Is Completed”, האם המשימה בוצעה או לא.זה ה-State.עכשיו, יש לנו את האפלקיציה - היא לוקחת את ה-State הזה, ומרנדרת (Rendering) איזשהו View.אפשר להסתכל על זה כמו איזושהי Pure Function, שעבור כל State תייצר אפליקציה אחרת, ועבור אותו ה-State תייצר בדיוק את אותה אפליקציה.הרעיון של ה-State Management זה איזה-שהם כלים וקונספטים שעוזרים לנו לנהל את הדבר הזה.(רן) הזכרת מקודם View - אז יש את המודל הקלאסי, ואולי קצת ישן ומאוס, של Model-View-Controller - אז באלגוריה הזאת, ה-State הוא למעשה ה-Model?(אסף) נכון - ה-ה-State הוא למעשה ה-Model, ה-View זה יכול להיות . . . אם זה נגיד, MVC שמתרדנר (Rendered) בשרת, כמו Ruby-on-Rails או PHP או Laravel או כאלה דברים, ה-View הוא HTML, שהשרת מחזיר ללקוח - והדפדפן “מצייר” מזה אתר.(יונתן) אני חושב שפעם, בעצם . . . יש מעיין Shift כזה ל-Frontend . . . פעם, ה-Database באמת היה ה-Database, ה-Server היה עושה את הלוגיקה, מרנדר אפילו JSP וכל מיני כאלה - וה-Browser היה רק מציג.עכשיו, יש Shift כזה שמאלה ל-Frontend, ששם כבר הלוגיקה - ולכן חסר שם איזה משהו . . .(רן) כן, אני מסכים - ככל שיותר לוגיקה עברה ל-Frontend, ככה נדרש יותר תחכום, ולכן גם נדרש איזשהו State Management - וכנראה שעוד הרבה דברים אחרים. לא רק זה, אבל זה לגמרי אחד מהם.עכשיו - State Management גם מגיע עם רכיבי View בדרך כלל, נכון? יש איזשהו קשר הדוק - אני מניח, למשל, שכל מי שכתב אי-פעם ב-React, כנראה גם מכיר את Redux ואולי גם עוד כמה חבילות.למה . . . נשאל את השאלה הזאת ככה: האם באמת “הצימוד” הזה הכרחי? מה המוטיבציה לצימוד הזה? מה אנחנו מרוויחים מהצימוד הזה? או לחילופין - האם אפשר להפריד ביניהם, לצורך העניין - להשתמש ב-Redux עם Angular או Whatever, והאם אפשר להרוויח מזה משהו פה?(אסף) אחלה - אז כמו שאמרתי, יש פה שני דברים שונים: אחד - זה האם כשאתה משתמש ב-React, צריך להוסיף לזה, On top of that, גם Redux?; והשני זה “האם Redux עובד גם עם דברים אחרים?”.אז אם אני אענה על השאלה השנייה קודם - Redux הוא לא Coupled ל-React: זו ספרייה שיכולה לעבוד עם כל מיני ספריות, והיא יותר High-Level.יש Binding מ-Redux ל-React - זה נקרא React Redux, שזה מצמד את React ל-Redux, אבל באופן די גורף - לרוב ישתמשו ב-Redux עם React, וזו גם הספרייה פופולארית ביותר.אני הסתכלתי לא מזמן ב-npm, ב-Weekly Downloads, ו-Redux הוא 90% בערך מהנפח של הספריות שהסתכלתי עליהן.אני לא יודע כמה קורלציה יש לזה לשימוש אמיתי, אבל אם זה אומר משהו, אז Redux היא סופר-סופר פופולארית.(רן) כן - ואני חושב, דרך אגב, ש . . . מי שמפתח Frontend בודאי מכיר, אני אתרגם רק למי שאינו מפתח Frontend כנראה - אחד הדברים שהכי קוסמים ב-Redux זה הפשטות שלהזו ספרייה שהיא (א) מאוד מאוד קטנה ו-(ב) יש המון המון Tutorials על איך לכתוב Redux בשביל עצמך - מתוך מטרה שהמפתחים יבינו באיזה כלי הם משתמשים.אז לא כל ספריות ה-JavaScript פשוטות, אבל Redux זו שפה פשוטה - אבל אלגנטית, וזה היופי שלה.אבל Redux זה חדשות של לפני . . . כמה? 6-7 שנים?(אסף) 2014 זה היה, אם אני לא טועה [2013?] . . . זה היה ההרצאה של Dan Abramov, שבה הוא הכריז על הספרייה.(רן) כן, אז 7 שנים, אולי יותר - ומאז הרבה מאוד דברים קרו - אז בוא נדבר על מה קורה היום . . .ביום-יום - מה אתה עושה? אתה הולך ופותח פרויקט ו . . . ? דבר ראשון אתה מביא Redux? איך זה נראה?(אסף) אז זו שאלה מצויינת, ובאמת זה תלוי מאוד בצרכים שלך, של האפליקציה עצמהצריך לשאול מה עושה האפלקיציה? מה המורכבות שלה? האם בכלל צריך State Management?אפשר אפילו לקחת קודם צעד אחורה - ולשאול האם בכלל יש State? לא לכל אפליקציה יש State, כמו שיונתן ציין.פעם, אם אנחנו הולכים ממש אחורה, ל”תחילת האינטרנט” - אז אתרים זה היה משהו מאוד פשוט: זה היה הטקסט, התמונות, מדי פעם היה איזה Form . . . אבל זה מה שקרה.וככל שעבר הזמן, הדפדפן ניהיה דבר מאוד מורכב, מעיין “מפלצת” - זה היום חזק כמו מערכת הפעלה שלמה כמעט, אפילו דפדפנים יכולים היום להריץ Server-ים . . . אני ראיתי ש-StackBlitz מריצים את Node בתוך הדפדפן - אתה יכול להריץ Node Server שמרים לך Web Server, וחושף IP שאתה יכול, דרך הדפדפן שלך, להיכנס ל-IP שהדפדפן מרים . . . זה די Mind-blowing.(רן) רקורסיה . . . זו הכותרת.(אסף) בדיוק . . . אז דפדפן זה משהו מאוד חזק, ואפשר לעשות איתו דברים מטורפים.אבל קודם כל, השאלה שצריך לשאול, בכלל לפני ששואלים איזו בספרייה משתמשים, זה האם צריך ספרייה כזאת?אם החלטנו שאנחנו משתמשים ב-React, כספרייה - כי גם את זה אנחנו לא חייבים - אז גם React, לכשלעצמה, יש לה פתרונות לניהול State.כי React באה עם כמה APIs נוחים לניהול State - אני מדבר ספציפית על . . . אפשר לעשות את זה בכמה דרכיםאו בצורה הישנה, שזה דרך ה-Classאו דרך Hooks, שזה משהו קצת יותר חדש.אני אדבר על ה-Hooks, כי זה קצת יותר נוח, אבל אותם עקרונות בדיוק אפשר לעשות גם ב-Classes . . .(רן) נעשה פה רגע איזו עצירה - יונתן, דיברנו קודם זה שלפחות היסטורית, רוב ה-State היה נשאר בצד של השרת והיה מוחזק ב-Database-ים, והייתה איזושהי שכבת Rendering - שגם היא הייתה נמצאת הרבה פעם בצד של השרת.ואז הזכרת - אסף - שהדפדפנים היום הם דווקא די חזקים, ושאפשר לעשות בהם כמעט הכל - ובין השאר, יש בהם גם Database-ים.ועכשיו, נשאלת השאלה - האם יש קשר בין ה-State, שעליו אנחנו מדברים, לבין ה-Database-ים שקיימים היום בדפדפנים? לצורך העניין - האם הם שומרים ב-Database-ים המקומיים שלהם את ה-State, או שזה State שהוא מתדנדר (Rendered)? זאת אומרת - ברגע שאתה עושה Refresh לדף, הכל נעלם ומתחילים מחדש?(אסף) ה-State שאני אוהב וה-State-ים שאני מדבר עליהם - הם לרוב נשמרים ב-RAM, בזכרון, וזה אומר שזה יתנדף ברגע שירפרשו (Refresh) את העמוד.כמובן שאפשר את כל ה-State הזה להעביר אל ה-Local Storage או עם פתרונות Database-יים מקומיים שיעשו את זה Persistent over time.זה במיוחד יהיה יותר קל ויותר נעים עם ספריות כמו Redux, ששומרים הכל במקום אחד - אתה עושה לו פשוט Dump וטוען אותו בחזרה.בדרכים אחרות, אם אתה שומר את ה-State שלך בצורה קצת יותר מבולגנת ב-RAM זה אולי יהיה קצת יותר קשה, אבל אם אנחנו הולכים, נגיד, על משהו כמו Redux, או Recoil, שגם לו יש Snapshot ו-Store שמסדר הכל במקום אחד - או MobX-State-Tree, שזה גם פתרון כזה - יהיה מאוד קל לעשות Dump של הזיכרון הזה אל ה-Local Storage, לדוגמא, שזה Persistent Storage, כמו Database - ולטעון את זה בחזרה כשטוענים את האפליקציה.(רן) “מאוד קל” במובן הזה שזה פשוט String JSON, ואתה יכול לכתוב ולקרוא אותו לעשות Serialization או De-Serialization?(אסף) כן - בגלל שכל ה-State נמצא בעצם באובייקט אחד, אני יכול לעשות לה סריאליזציה (Serialization) ל-JSON, לשמור אותו כ-String ב-Local Storage, לטעון אותו, לעשות לו דה-סריאלזיציה (De-Serialization) - ולהשתמש בו שוב.(יונתן) אם אני, נניח, מתחיל לכתוב אפליקציה חדשה, ואני עוד לא יודע כמה היא תסתבך, כמה גדול זה יהיה . . . - האם היית ממליץ לי, מההתחלה, להשתמש ב-State Management, או לחכות שזה ממש “יצעק”?(רן) זה לא כמו השאלה על Unit Testing? . . . “אני מתחיל משהו קטן, איזשהו פרויקט-צד קטן, לא נראה לי שזה הולך להיות מסובך, אני לא כותב טסטים” . . . מפה לשם - אחרי שנה אתה לא מוצא את הידיים ואת הרגליים . . . (אסף) כן, לגמרי . . . אז זה עניין של גישה.אני, כשאני מתחיל משהו חדש, אני אוהב להתחיל את זה עם כמה שפחות Boilerplate וכמה שפחות דברים, הכי נקי שיש, וכשאני צריך עוד ועוד דברים - אני עושהאני אבין בעתיד, כנראה, גם מה הצרכים שלי, ואני אדע לבחור איזה מהפתרונות State Management . . . כי שוב - זה לא סטנדרט . . . אין סטנדרטיזציה בנושא, אז יש כל כך הרבה ספריות וכל כך הרבה דעות, וזה מסוג הדברים שמתכנתים אוהבים להיות מאוד דעתניים כלפיו.(יונתן) אז המיגרציה (Migration) הזאת, מלהיות בלי State Management לעם - למשהו ש . . . זה מסובך לעשות את זה? זה re-factor ש”ישכיב” את הצוות או שזה “מכה קלה בכנף”?(אסף) אז אני חושב שזה תלוי מאוד ב- State Management solution שאתה בוחר בולדוגמא, MobX זו אחת הספריות הפופולאריות - כנראה השנייה-הכי-פופולארית אחרי Redux - זה מאפשר לך לעשות את ה-Transition הזה בצורה די נוחה, כי זה משתמש באיזשהו “קסם” שמאפשר לך לעטוף אובייקטים רגילים של JavaScript ולהפוך אותם ל-”React-ביים”.מה זאת אומרת -”React-ביים” [חוץ ממשהו שממש קשה להעביר לטקסט ככה?] - זאת אומרת שאם ה-State הזה מעודכן, אז ה-View שלנו גם יתעדכןזאת אומרת ששינינו . . . נגיד בדוגמא של ה-To-Do List, שינינו את ה-Data, את ה-Array הזה של ה-To-Dos? - והקומפוננטות (Components), ה--ים האלה, שמציירות את זה על המסך, תתעדכנה גם כן.ובגלל שזה משתמש באיזשהו “קסם”, שנקרא Proxy Object של JavaScript או Getter ו-Setter של ES5 - אלו שתי דרכים לעשות את זהזה בעצם “דורס התנהגות” של מה שאנחנו עושים, De-reference לאובייקט, כשאנחנו ניגשים אליו.אז מאחורי הקלעים, אתה משתמש בזה כמו אובייקט רגיל, אתה עושה State.ToDos[7].Title - ועורך את זה.ומאחורי הקלעים, MobX עשתה לך Subscription כשהשתמשת בזה עבור הקומפוננטה (Component) שמשתמשת בזה, והיא תדע לעדכן את הקומפוננטה בכל פעם שעדכנת את ה-State.אז זה יהיה מאוד מאוד נוח . . . יכול להיות שכתבת את הדבר הזה כאובייקט JavaScript רגיל, ואתה רק מוסיף MobX ועוטף את זה בכמה פונקציות שהספרייה מביאה לך - ואתה די מסודר, יש לך State Manager . . . בספריות אחרות, נגיד Redux, זה משהו שהוא הרבה יותר opinionated, והוא קצת יותר מורכב.אתה צריך לנסות הרבה יותר דבריםוזו גם אחת הביקורות הכי גדולות שיש על הספרייה הזאת - זה שצריך ללמוד הרבה, ושאתה צריך לכתוב הרבה קוד בשביל להשתמש בזה.(רן) בוא נחזור רגע ל”קסם” - כי קסם זה כיף: אז יש Attribute - אתה אומר נגיד, ToDos[1].Value = “לאסוף כביסה”, ואז, בעצם, אתה אומר שיש איזשהו רכיב שעשה איזשהו Subscription ל-Setter הזה, והוא עושה “Hijacking” לקריאה הזאת או עם Proxy או טכנולוגיה אחרת שהזכרת את שמה, והוא בעצם “תופס” את הקריאה הזו, ואולי הוא עושה Set ל-Value - אבל הוא גם מפעיל איזושהי שרשרת של קריאות, שבסופו של דבר מפעילה את ה-UI.עכשיו, זה נחמד ברמת השימושיות . . . השאלה, אם אתה מכיר את הקונספט הזה, מה שנקרא The Fallacies of distributed systems - שבעצם זה בא ואומר שכאילו אתה מפעיל איזושהי קריאה, ואתה לא יודע שהקריאה הזאת רצה על איזשהו שרת מרוחק, ולכן אתה גם לא יודע מה כל הדברים הרעים שיכולים לקרות בדרך . . . אז אתה לא מטפל נכון בשגיאות, אתה לא יודע כמה זמן זה יקח, אתה . . . זאת אומרת - זה נראה קל, אבל אתה בעצם “מחביא” מאחורי זה הרבה מאוד דברים שגם יכולים להשתבש, ואם אתה לא מבין שזה מה שיקרה, אתה יכול לטעות, זאת אומרת - יהיה לך UI שהוא Sluggish ועוד כל מיני כאלה תופעות . . . אולי לא תטפל נכון בשגיאות וכו'.אז איך . . . יש פה איזשהו Trade-off בין פשטות השימוש לבין היכולת שלך לשלוט בהתנהגות בצורה שהיא Fine-grained . . . (אסף) נכון מאוד . . . MobX, כספרייה, זה משהו שהוא יותר Tool, שהוא נורא לא Opinionated.הוא מאפשר לך איזושהי יכולת, שנותנת לך לעשות Subscription ו-Reactiveness ל-State, בלי לעשות הרבה Boilerplate - אבל זה לא אומר שאתה חייב להשתמש בזה בצורה הכי פשוטה.אתה יכול לעטוף את זה בדברים שיעזרו לך לפתור את הבעיות שציינת - של Observability ושל Debugging יותר נוח.האמת שהיוצר של MobX כתב עוד ספרייה, שקוראים לה MobX-State-Tree, שהיא כן Opinionated, ומשתמשת ב-MobX בתור כלי, מאחורי הקלעים, לעשות את הפעולות היותר . . . של ה-Reactivness.אבל היא מאוד Opinionated - יש שם Store, ל-Store יש Type-ים שאתה רושם אותם, איזשהו מודל . . . אתה רואה בכל פעם לאן כל דבר הולך ואתה יכול ליצור, מתוך זה, Snapshots - בדומה ל-Reduxזאת אומרת - זה משלב, באיזשהו מקום, את הכיפיות והקסם של MobX, אבל את ה-Rigidness וה”נוקשות” הזאת של -Redux, שגורמת לך גם לדבג (Debug) קוד בצורה יותר נוחה וגם להבין מה קורה כשדברים משתבשים.(רן) כשדיברנו בטלפון, בשיחה המקדימה, דיברנו על ספרייה שנקראית Recoil, שהזכרת את שמה מקודם - מה מעניין בה? מה מיוחד בה? מתי אני ארצה להשתמש בה ולא באחרות?(אסף) אחלה, אז Recoil . . . אולי לפני שנדבר על Recoil, נדבר טיפה על קונטקסט, כי הרבה מהדברים שם הם סוג של פותרים דברים שהיה בעייתי עם קונטקסט, עם New State.אז אם מסתכלים רגע על ה-API ש-Redux מביא איתו Built-in, בלי להתקין שום ספרייה חיצונית, אז יש לנו שני דברים עיקרייםיש לנו useState, או useReducer, שזה תחליף ל-useStateויש לנו את Context.עכשיו - useState ו-Context עושים שני דברים קצת שונים - useState מאפשר לכל קומפוננטה (Component) לשמור State לוקאלי עבורה, שהוא Persistent בין Render Callsזאת אומרת שאם אני אקרא ל-Render עוד פעם, יהיה לי את אותו State.ובנוסף, זה נותן לי את ה-Reactiveness הזה, כמו שדיברנו - זה מרכיב חשוב בכל State Management.ברגע שעדכנתי את ה-State, עם פונקציה שה-Hook הזה מחזיר לי - ה-setState - אז React ידע לקרוא לי ל-Rendering - אם ה-State המחודשזאת אומרת שברגע שאני מעדכן את ה-State - אני יודע שה-View יהיה “טרי”, הוא יצייר לי את מה שאני רוצה עם ה-State “הטרי” והחדש.(רן) זאת אומרת - כאילו יש את המצב הראשוני, ואחר כך, על כל שינוי, יקראו לך ותעשה Rendering מחדש.(אסף) בדיוק - אני יכול . . . React מבטיח לי את זה, שזה אחלה, זה מעולה.הבעיה עם useState זה שדברים . . . שאפליקציה, כשהעץ-קומפוננטות של React מתחיל לגדול ולגדול, אני רוצה לפעמים להתחיל לשתף State בקומפוננטות שלפעמים הן גם במיקום רחוק בעץ . . . שני עלים שיש להם אב-קדמון משותף, נמוך ביותר, שהוא כמה רמות מעל.ואז זה אומר . . . .(רן) אוקיי - אז אני מסתכל על רשימת ה-To-Do - אז אתה רוצה, נגיד, להציג איזשהו View אחד גדול עם ה-To-Dos, ואולי מימין-מלמעלה גם איזשהו תקציר של הרשימה, נגיד כמה אייטמים נשארו un-checked . . . (אסף) בדיוק - כמה אייטמים נשארו un-checked, ואולי עוד סטטיסטיקות . . . מעיין כזה Dashboard, זו דוגמא מעולה.ובאמת, כדי ששתי הקומפוננטות הללו תכירנה את אותו State - כי אנחנו לא רוצים לשכפל את ה-State, אנחנו יכולים, תיאורטית, לשכפל את ה-State, אבל אז נוצר מצב שבו אני צריך לטפל בעדכון של שני State-ים שונים, וזה יכול ליצור באגים וזה קשה להבין . . . (רן) מה הבעיה? תיקח ספרייה, בטח יש אחת כזאת שעושה את זה, לא? . . .(אסף) יש ספרייה . . . ב-JavaScript יש ספרייה לכל דבר, לכל שורה של קוד יש ספרייה . . . (רן) ראיתי לא מזמן איזשהו API שנקרא is-odd - שמחזיר לך אם המספר זוגי או אי-זוגי . . .(אסף) יש את הסיפור המפורסם של left-pad, שזו ספרייה שהקריסה את כל npm, הקריסה מלא עבודה של מלא אנשים בכל העולם, בגלל שהשתלטו עליה ועשו שם כל מיני דברים . . [היה לא מזמן ב-398 with Danny Grander from Snyk](רן) בסדר - אז אתה לא רוצה לשכפל את ה-State וזה, אני חושב, ברור - אבל אתה אומר שיש פה בעיה עם ה-Set . . .(אסף) כן, ומה הבעיה? יש פה שתי בעיות - אחת זה שאם אני רוצה ששתי קומפוננטות, שנמצאות במיקום מרוחק בעץ, ישתפו את אותו State, אני צריך להתחיל להעביר את ה-State הזה ממקום למקום - זה נקרא Props Drilling, “קדיחת Properties” . . . זה לא נוח, זה אומר שבכל פעם שאני רוצה להוסיף State אני צריך להוסיף את זה בעוד “מיליון מקומות”, קשה לעקוב אחרי זה, מאיפה זה בא . . .(רן) כן, אתה צריך לקודד . . . למעשה, אתה צריך . . .עכשיו כשאתה אומר, אני נזכר שעשיתי את זה, וזה היה מה-זה מעצבן . . . בכל מקום אתה צריך ללכת ולעשות . . . “לפעפע” את ה-Attribute הזה למטה ולמטה ולמטה . . . .ממש עבודה ידנית מעצבנת . . . (יונתן) וזו בעיה גם לפעמים בקוד של ה-Server, נכון? כשאתה מאתחל איזשהו Bin, או איזשהו אובייקט, ורק למטה למטה אתה צריך להעביר אותו . . .(אסף) נכון, Dependency Injection כזה . . .(יונתן) ואם אתה “מתפתה”, אז אתה שם איזשהו משתנה גלובאלי או Database או משהו כזה, ואז אתה . . (רן) זה כשאתה מתכנן להתפטר . . . וכשאתה מתפטר אז אתה לא מגלה . . .(יונתן) אז מה האלטרטיבה ל-Props Drilling הזה? . . . (אסף) אז רק אני אגיד שבנוסף להעברה הזאת, זה גם עניין של Performance, זה בעייתי - כי איך ש-React עובד, ברגע ש-Props משתנה, הוא קורא ל-Render מחדש . . .הוא קורא ל-Render כש-Props משתנה וכ-State משתנה.וכשכל תת-העץ הזה, שבכלל לא משתמש ב-State - כל מה שהוא עושה זה להעביר את זה מפה לשם כשמתרדנר (Renders) - זה פשוט בזבוז של חישוביות . . .אבל באמת כדי לפתור את זה יש איזשהו API שנקרא Context - ו-Context מאפשר להגדיר איזשהו State . . .(רן) הנה המשתנה הגלובאלי שחיפשת, יונתן . . . (אסף) בדיוק . . . אז זה משתנה גלובאלי, שבעצם פותר את העניין של ה-Drilling, כי אני יכול להגדיר את זה ב”אב הקדמון” המשותף הזה, אני יכול להגדיר שם את ה-Context, וזה אומר שכל חלק בתת-עץ, שהוא צאצא של האב הקדמון המשותף הזה, יכול להשתמש ב-Value של ה-Context.וזה מאפשר לי לפתור את ה-Props Drilling - וגם עם זה יש קצת בעיות . . . אחת - גם פה יש קצת עניין של Performance, כי אם אני, נגיד . . . לרוב, מה שעושים זה שעושים Provider כזה, ובתוך ה-Provider הזה זו קומפוננטת React רגילה - שהיא בעצמה משתמשת ב-useState שדיברנו עליואז כדי לעדכן את ה-Value, אני מעדכן את ה-Value איפה שאני שם את ה-Provider, והוא ירדנדר (Render) את כל תת העץ.הוא עדיין ירנדר אותו - כי ככה זה עובד: כי ברגע שהתרנדר אב-קדמון, הוא מרנדר את כל התת-עץ.אפשר לפתור את זה בדרכים שונות, כמו נגיד עם React.memo שהופך קומפוננטות, שמשווה באופן Shallow את ה-Properties, ומרנדר את זה רק אם הם שווים - אבל זה מעצבן, כי אני עכשיו חייב לעשות את זה, גם יש בזה Overhead . . . יכול להיות שזה לא כזה מעניין, ברוב המקרים, תכל'ס, זה לא מעניין - כי זה לא שווה את ההתעסקות, כי זה לא משנה באמת את חוויית המשתמש, האופטימיזציות האלה.אבל כשיש אפליקציות ענקיות, ש-Rendering הוא מאוד יקר, והדברים האלה מתחילים להציק - אז זה מתחיל להיות בעיה, ואז מתחילים לחשוב מה לעשות.(רן) אבל זה כן משנה את חוויית המפתח, זאת אומרת - או שתצטרך לעשות Props Drilling, או שתצטרך להשתמש ב-Context, שזה - בוא, בינינו - זה משתנה גלובאלי, עם כל המעמסה שבאה עליו.אז כן - למפתח זה אומר איזשהו נטל תחזוקתי(אסף) כן, לגמרי . . . (רן) אז זו הבעיה . . . הבנו - האקדח מהמערכה הראשונה . . . . בסדר.אז Recoil היא זו שתיקנה את הבעיה הזו?(אסף) Recoil תיקנה חלק מהבעיות האלה, כן . . . ב-Recoil, זה התחיל מהרצאה שהייתה ב-ReactEurope, שזו אותו כנס ש-Dan Abramov עשה בו את ההרצאה המפורסמת על Reduxאז זה בחור מ-Facebook, שסיפר שיש להם כלי ב-Facebook, שהם עושים כל מיני סטטיסטיקות על user-ים.הוא סיפר שם על כל מיני דרישות שהיו להם מהמוצר הזה - והוא רצה להשתמש ב-State וב-Context אבל נתקל בכל מיני בעיות - אחת מהבעיות הייתה . . . עוד בעיה שלא הזכרנו בנוגע ל-Context זה שאם אנחנו רוצים שה-User ייצור באופן דינאמי State - בוא נדמיין לדוגמא שזו הדוגמא שהוא מביא - אז לדוגמא, יש לי אפליקציה שאני יכול לצייר בה צורות - אני יכול לצייר בה עיגול, אני יכול לצייר בה מרובע, וה-User יכול פשוט להכניס עוד צורההוא יכול גם לעשות לזה Drag, או לשנות לזה את ה-Size . . . אפשר לדמיין מעיין Photoshop כזה . . . עכשיו - לכל אחד כזה הוא רצה ליצור State משלו - והסיבה שהוא לא רצה את זה ב-State משותף זה בשביל Performance, דיברנו על זהכי אם יש State משותף אז זה ירדנדר את כולם, וכשאתה מתחיל לעשות דברים כמו Dragging, וזה קורה 60 פעמים בשנייה, אז זה כבר מתחיל לכאוב . . . אתה כבר לא יכול, אתה צריך להתחיל לשחק פה עם Performance Optimizations.אבל הוא אמר “אולי נשתמש ב-Context, ועדיין העניין ב-Context הוא שזה סטאטי, ואתה חייב לדעת מראש כמה Context-ים את צריך ליצור . . . אתה לא יכול ליצור Context באופן דינאמי מתוך קוד.וזו בעיה ל-Use Case שכזה . . . זו אחת הבעיות . . . וכמובן יש את כל הבעיות שדיברנו עליהן מקודם.אז מה שהם עשו ב-Recoil . . . הם עשו כמה דברים מאוד מעניינים - אחד - בניגוד לספריות אחרות, ברוב הספריות - זו ספרייה שהיא מאוד Coupled עם React - אתה לא יכול להשתמש ב-Recoil ללא Reactבניגוד, נגיד ל-Redux או ל-MobXויש לזה כמה יתרונות נחמדים, כי ה-API של זה מאוד מאוד פשוט, והוא מאוד דומה ל-API של React, אז במקום useState, אתה תשתמש ב-useRecoilState, וזה יחזיר לך את אותו הדבר - יחזיר לך State ו-setState - וזה מאוד Familiar למי שמכיר את React, אתה לא צריך ללמוד הרבה, בניגוד ל-Redux וגם ל-MobX, שצריך ללמוד דברים.והקונספטים מאוד פשוטים - יש בעצם את ה-State הכי פשוט, שנתנו לזה שם די טוב - קוראים לזה- Atom, כי זה משהו אטומי . . . ובו אתה מגדיר State.עכשיו, אתה מגדיר את זה באופן נפרד, במודול אחר, שהוא לא יושב בתוך הקומפוננטה שלך, ולכן אתה יכול לשתף אותו עם קומפוננטות אחרותפשוט עושים לו Import . . . אתה לא צריך לעשות איזשהו Provider שיושב בעץ-למעלה.כל אחד מהם יכול לעשות לזה Import בנפרד, מבלי שיש את התלות הזאת בעץ.(רן) אוקיי . . . אבל זה דווקא . . . זה לא משהו שיכול לקרות ב-Run-time - ה-Import קורה בזמן הפיתוח, נכון? אתה לא יכול להחליט Ad-hoc ש . . . אתה יודע, בזמן ריצה, לעשות Import למשהו, נכון? זה קצת מזכיר את הבעיה שהייתה עם ה-Context . . . (אסף) נכון - בגלל זה יש משהו אחר שקיים ב-Recoil ונקרא atomFamily - זו “משפחה של אטומים” . . .אתה מגדיר atomFamily, והוא מייצר לך Atom-ים באופן דינאמי . . . אתה נותן לו ID, והוא יביא לך את ה-Atom המתאים ל-ID, וככה אתה יכול, ב-Run-time, בלי לדעת מראש, אתה יכול ליצור עוד ועוד Atom-ים ולשתף אותם.(רן) אז למעשה, הוא נותן ל-JavaScript לפתור את הבעיה . . . הוא אומר “תעשה Import, אני לא רוצה לנהל לך את המצב” - תעשה Import, ואם יש לך State משותף, תעשה לו Import משני קבצים שונים או משני רכיבים שונים - ובכלל שעשית Import לאותו רכיב, אז ה-State ישמר . . . זה הקונספט.אוקיי, JavaScript . . . אני שואל את עצמי האם יש פה סכנה ל-Race Conditions למיניהם . . . אם שני אובייקטים מחזיקים . . . טוב, זה כנראה לא קורה ב-JavaScript כי זה רץ בסביבה נפרדת, אז יש לנו פה Event Loop וזה לא יכול לקרות.(אסף) כן . . . גם בנוסף, בדומה ל-Redux, האובייקטים האלה הם Immutable - הם לא יכולים להשתנות לעולם, מרגע שהם נוצרו.(רן) אז איך אתה מעדכן State, אם זה Immutable?(אסף) אתה יוצר חדש . . . בכל פעם שאתה מעדכן State אתה לא משנה אותו - אתה יוצר אובייקט חדש, למעשה.(יונתן) תזכור ש-State is Evil . . . אז . . .(רן) כן, אבל דיברנו על . . . . אז בוא רגע נחזור לדוגמא שבה יש לנו רשימת To-Dos . . . יש לנו בחלק המרכזי של הדף את הרשימה המלאה עם ה-Check-box-ים לידה, ולמעלה מצד ימין אני רוצה להחזיק רק את מספר האייטמים שעדיין לא סיימתי, אוקיי? אז אני כן רוצה לעדכן פה איזשהו State, נכון? אני רוצה שלשניהם יהיה single source of truth - אבל אתה אומר שזה Immutable, אז מה אני עושה? איך אני מעדכן?(אסף) מעולה, אז בוא נלך על הדוגמא שאמרת - אם אנחנו משתמשים בפתרון שהוא mutable, כמו נגיד -Redux או Recoil, אז יש פה שני דברים - א - יש פה את ה-Counter הזה, של כמה אובייקטים הם Completed - זה מה שנקרא Derived Data: זה Data שאמרנו שאנחנו לא רוצים להחזיק אותו פעמיים, אז אנחנו רוצים לחשב אותו, אנחנו רוצים לחשב אותו מתוך ה-Data האמיתי, שזה ה-Array הזה של ה-To-Do List.גם פה יש עניין של “אנחנו לא רוצים לחשב את זה יותר מדי פעמים, אנחנו רוצים לחשב את זה רק כשדברים ישתנו”, כי זה יקר לחשב דברים, אבל אם נחזור לשאלה הזו, רגע, של “איך אנחנו מעדכנים את זה?”, אז בעצם כדי לעדכן את . . . כדי להוסיף To-Do חדש, אני צריך להוסיף Array חדש, כי אחרת ה-State לא השתנה . . . עכשיו, למה זה חשוב ב-Redux? כי ב-Redux, הוא משתמש בעניין הזה של mutability בשביל ליצור Reactiveness . . . דיברנו על Reactiveness, שזה מתי . . . איך אני יודע שכשה-State משתנה, אני צריך להודיע על הקומפוננטות שמשתמשות בו.אז -Redux משתמש ב-mutability כדי לעשות Shallow comparison - הוא לוקח את ה-Reference של האובייקט, ומשווה את זה - כי זו השוואה מאוד מאוד זולה, זה להשוות שני מספרים - הוא לא צריך לעשות Deep Comparison, ולעבור אובייקט-אובייקט ולראות שזה בדיוק אותו Value, הוא רק משווה את ה-Reference.ולכן, אם אתה עושה את זה Immutable, זה מאוד פשוט ליצור את ה-Reactiveness הזה.כשאתה רוצה לשנות את ה-State, אתה צריך ליצור אובייקט חדש.עכשיו, הדבר הזה הוא נושא ב-Redux, שהוא קצת שנוי במחלוקת . . .כי שוב, דיברנו על Boilerplate - בכל פעם ליצור אובייקט חדש זה יכול להיות מאוד מעצבן, וזה גם יכול ליצור באגים, כי יכול להיות שבטעות שינית את ה-State, כי JavaScript היא שפה שהיא Stateful, אתה יכול לשנות State, הוא נותן לך את זה ואתה יכול לעשות את זה בטעות - ואז זה ייצור באגים, כי בטעות עדכנת את ה-State במקום לעשות State חדש . . . ואז ה-Comparison לא יעבוד, ואז תקבל View שהוא לא Fresh, הוא Stale, וזה לא יעבוד לך ואתה לא תבין למה, ואז אתה תחפש בקוד ועד שתמצא את זה . . . זה נורא מעצבן.(יונתן) זאת אומרת שהייתי יכול לקחת את המערך של ה-To-Dos, ולהוסיף עוד איבר ברשימה - וזה לא היה מרנדר את הקומפוננטות כי React לא היה מודע לזה . . .(אסף) בדיוק, לא היית רואה את זה - והיית שובר את הראש “למה זה קרה לי?”.(רן) דרך אגב, בניגוד למה שאמרת קודם על MobX, שבו אם היית משנה משהו, אז בסופו של דבר כן ה-UI היה עושה לזה רפלקציה (Reflection).(אסף) נכון - ב-MobX, הוא משתמש ב-mutability, והוא בעצם משתמש בהתנהגות הזאת כדי ליצור את ה-Reactiveness.(רן) וב-Redux או ב-Recoil זה למעשה Anti-Pattern - אם אתה מפתח שעובר מ-MobX לאחד מאלה, הולכים להיות לך כמה חודשים קשים בהתחלה . . . (אסף) נכון . . . אבל יש חדשות טובות! אותו בחור שעשה את MobX ואת MobX-State-Tree - הוא עשה גם ספרייה שנקראית Immer, שהיום היא באה בתוך Redux -בגלל ש-Redux . . . אחת מהביקורות הכי גדולות זה כל ה-Boilerplate וכל העבודה שצריך לעשות, Redux עבדו קשה בשביל להוסיף לתוך הספרייה כל מיני כלי-עזר שיעזרו לך עם זה.אחד מהם זה Immer - שמשתמש באותו “קסם” שמשתמשים ב-MobXזה גם אותו בנאדם שהשתמש בקסם הזה ב-MobX . . . כדי לעשות Immutable state - אבל בצורה שנוח יותר לאנשים לעשות את בצורה של mutable . . . מה זה אומר? זה אומר שאתה יכול להשתמש ב-API המוכר של JavaScript, של לעשות State.משהו.משהו = . . . לשנות את האובייקט הקייםבדוגמא שנתנו מקודם - להוסיף איבר למערךאבל מאחורי הקלעים, באמצעות אותם קסמים שדורסים את ההתנהגות של האובייקט, הוא ייצור לך אובייקט חדש, עם רפרנס חדש, וה-Shallow Reference Comparison יעבוד והכל יהיה כיף!אתה לא צריך ליצור Spread . . . מה שקורה הרבה פעמים זה שאתה יוצר Spread-Operator כדי לעשות Spread לאובייקט הקודם מתוך אובייקט חדש - וזה גם, פעם לא היה את זה, זה חדש, קיים רק כמה שנים, פעם היה צריך לעבוד עוד יותר קשה . . . אז זה עושה API ממש ממש כייפיהיום, Redux זו חווייה הרבה יותר כייפית ממה שהיה כשאני השתמשתי בזה . . . כשהתכוננתי לפודקאסט, ראיתי שהם עשו שם המון המון עבודה כדי לטפל בבעיות האלה.(רן) אני כבר מצליח לדמיין את הפרסומות - “להרגיש Stateful ולהיות Stateless!”, אבל טוב . . . [יש מצב . . . פרסומות הרבה פחות מוצלחות מזה כבר רצות היום על איילון]מעולה, מגניב - אז בוא נעשה רגע סיכום: בגדול, דיברנו על מה זה State Management, ולמה בכלל צריך את זה בצד של ה-Clientדיברנו על זה שלוגיקה עברה לצד של ה-Client, ולכן זה . . . הדברים מתחילים להיות מסובכים וצריך איזושהי דרך, ככה “לסדר את הקוד”, זה לא יכול להיות הכל ספגטי - jQuery Spaghetti, למי שיצא התענוג . . .אז קשה מאוד לנהל קוד כזה, ולכן נולדו ספריות של State Managementדיברנו קצת על React, דיברנו על MobX, שיש להן גישות שונות ובסופו של דבר על Recoilאז תודה רבה! כמה מילות סיכום?(אסף) היה לי ממש כיף, אפשר להמשיך לדבר על הנושא הזה עוד המון-המון-המון - זה נושא מאוד Debatable . . . יש המון פתרונות, כל הזמן קמות ספריות חדשות, זהו . . . תודה רבה!תודה לך אסף, ושהיה בהצלחה ב-livecycle. להתראות! האזנה נעימה ותודה רבה לעופר פורר על התמלול!

After this podcast recording, I wrote Technical Community Builder is the Hottest New Job in Tech which went into further detail on my thoughts on Community! Audio source: https://www.heavybit.com/library/podcasts/developer-love/ep-15-learning-in-public-with-shawn-swyx-wangSHOW NOTES Geoffrey Moore's Crossing the Chasm /r/ReactJS Taming the Meta Language by Cheng Lou Avis is No. 2. We Try Harder Metcalfe's Law Reed's Law Clubhouse CMX Udemy The Community Fund Working in Public by Nadia Eghbal Hacking Communities by Laís de Oliveira Prettier Transistor.fm Stripe TRANSCRIPTPatrick Woods: Awesome. Swyx, thanks so much for coming on the show today.I'm really excited to have this conversation.I'm sure lots of folks are aware of who you are and probably follow you on Twitter, but for those that don't, would you mind giving us a little bit of an overview about who you are and what you're working on?Shawn "Swyx" Wang: Sure. Thanks for having me on.Been enjoying the podcast, and this is my second Heavybit podcast alongside JAMstack radio.So I'm Shawn, I also go by Swyx, that's my English and Chinese initials.It's a complicated history, but I was at Netlify, passed through AWS and most recently just left AWS to join Temporal.And have been primarily active in the front-end/ serverless space.And I've been very interested in this whole idea of developer experience.I did not know to call it developer love until I came across Orbit.And I think Orbit's model is fascinating and really nails it.But to me, the way I've been breaking down developer experience is developer tooling and developer communities.So kind of straddling both.I was a moderator of r/ReactJS subreddit, going from about 40,000 members to over 200,000.Recently stepped down from that to help run the Svelte society, which is the community organization for the Svelte framework. And I think it's just a magical thing to be able to enable a community around a certain technical topic. Patrick: Yeah. Thanks for the overview.So you mentioned developer experience as a concept and a practice that you're very interested in.What do you think led to that point for you?Swyx: Honestly, it was Netlify branding their developer relations people as developer experience engineers, which I was pretty skeptical about, because if you are devrel, just say your devrel, don't try to put some unique spin on it.But then I think they really envisioned something bigger than traditional devrel, which was building our integrations and also working on community building, which is not like me talking to everyone, but also enabling others to talk to everyone else.And so I think many to many is a really noble goal.It's very challenging obviously, because you have to influence without any formal authority, but it's also a very appealing goal economically, because then you don't have to scale their number of employees linearly with your number of users, which I think makes a lot of sense.Patrick: So you mentioned developer experience for you is really comprised of tooling and communities.Can you talk a little bit about the relationship between those two pillars?Swyx: I don't know if I have a formal relationship in my head.The framework that I come from is actually from Cheng Lou, who used to be on the React Core team.I think he's on the Reason or ReScript core team now. And he gave a talk at Facebook's internal conference called Taming The Meta Language, and the argument of that--And it's a very good talk. I recommend people check it out.The argument on that talk was essentially that every programming language or every framework has a core and a periphery, and the more developed it gets, the core which is kind of like the code that runs, is a smaller and smaller part of it.And really the middle language starts to go around it, which involves tutorials, docs, workshops, community, jobs, third party libraries, yada yada.And so in his original slides, he had a long list of these things that are wrapping around a very popular framework, which for him was reacts, but you can extend this to basically anything.But for me, I think it essentially just breaks down to, okay, the code that is not core but makes all the developer experience much better, so that's the developer tooling, and then developer communities, which is all the people around the code, which isn't core to the code, but makes using that code a lot better.So it's just code and people.Patrick: Yeah. I love that.So as a project or a framework grows the core, maybe it becomes smaller as a percentage of the overall footprint with the periphery, the middle language increasing.What's that tipping point look like, do you think, when it switches from code to community being the bigger part?Swyx: Yeah. This is something you can tie in to Geoffrey Moore's idea of Crossing the Chasm.So for people who haven't heard about this, it's like a five stage adoption process going from 0% of the total population to 100% of the total population.And then it's a bell curve from 0% to a 100%.So the early stage is kind of the hobbyists, like super early adopter types.The only thing that they care about is this is cool.I can hack on this in the weekends, and this is technically better on some basis, right?Like in theory, I really want this thing to exist. I look at all the existing solutions out there and none of them fit me, because I have very specific needs.And they don't need a lot of documentation.They don't look for other people like, is this used in production by some big company that I recognize.They don't think about stuff like that. They're just like, does this fit a very specific need that I have?That's it. If it does, good. That's enough for them.But the majority of people don't work like that. Right?They do want to see documentation. They want to see a thriving job market.They want to see that like whatever, Netflix has used this in production.All that stuff that's not core to the code, but does provide some measure of faith that this is tested at scale, that this is reliable and dependable and a good technical bet. As you go from early adopters, you cross the chasm into the early majority and the late majority. The requirements of the early adopters versus the majority are very different. The earlier adopters require a lot less essentially handholding. I'm not trying to demean the people in the majority.They just have different needs for that specific domain.And the people in the majority are more conservative, probably as a good measure of technological conservatism.You don't bet early on everything because you're going to get burned.So I think it just makes sense to bet early on some things where it really, really counts, and then just be conservative, use boring technology on everything else.But it does make a lot of sense that the crossover is a very challenging thing.Because when you start a framework, when you start a programming language, you're just like one person or like a small team just hacking away, right?You just care about the code and making it run fast or more securely, or have special features that nothing else in the world has.That's great. And then suddenly a community grows around you and then they're asking for things like, "Can you make better docs? Can you integrate with my thing? This doesn't work well with my existing worlds."And you're like, "Okay, sure. I want you to be happy."But that takes you further and further away from just working on the thing itself.So I think as a project grows in importance and adoption by the majority of the community, you start to embrace different parts of the population with different needs.And I think that that's the crossover point. I don't have a number for you, but people typically peg it at--I don't know, 5% or 10% of the population where it really starts just crossing over already.Because there are a lot of people in the middle.Patrick: Thinking about your experience with the React subreddit, what were some of the learnings or observations you had as that community scaled through those different phases?Swyx: It's a challenging one because Reddit is a constraint format.It's essentially a link aggregator with a voting and some comments.So, JavaScript is the largest programming language and React is the largest framework within JavaScript.Arguably there's some other measures.But when you have such a large community like this in a constraint format where basically only one link or one question can be in the top position when you sort by up votes, then there's a matter of what target audience do we want to target?Because there are a lot more beginners than there are advanced people, but people come for engaging events, knowledgeable conversations.So there's always this tension between, there's a lot of beginners who don't know any better and we should be welcoming to them, of course.But at the same time, if we make it too beginner-focus, the events will go away, and it will lose its quality.So there's a very challenging tension.One of the ways in which we solve that is to basically contain the beginning of questions to a dedicated thread.And that's something that I did when I was starting out.Basically the promise you make is that you will answer every single question that goes in there, which is a step up from stack overflow, where you can ask a question and it just gets crickets.Patrick: All right.Swyx: And so that contains the beginner questions and allows other types of contents to come up, which can be more advanced.And you try to make the two extremes happy, even though you can never really do a fantastic job.So there are other ways, for example, you can forge the community and create as specifically beginner focused one.But then you get what you get, which is that there won't be that many experienced people frequenting that subreddit, therefore the answers may not be as good, or you just have a glut of people asking questions and nobody's around to answer them.Patrick: Yeah. In terms of tactics, were you the one answering the questions in the beginner thread or were there other moderators that jumped in or did the community help out?Swyx: I started doing that. So there were some months where it was like 500 pushes and answers, and the vast majority of them were me.Patrick: Wow.Swyx: And it's not so bad, once you find repeats, then you can just copy and paste.But I think when you're leading the community, you do have to lead by example, and then people who see what you're doing in the service of the community, start to jump in and help out.That's where I recruited a couple of my other fellow moderators, because I saw that they took the initiative and joined in with no expectation of any personal benefit.They're just serving the community.I think there is some personal benefit in the sense of, you get to answer all these questions and you strengthen your own knowledge, which is really good.And you also understand the pain points.So you can go write blog posts and articles and even libraries to solve those pain points.So having a very close ear to the ground for what people are facing helps you just be relevant to everyone else.So I think there's a lot of benefits for doing that.But yeah, it's actually a pretty good recruiting ground.Basically, if you want to be a leader of the community, just act like it and people will see what you're doing, and then they'll formally give you that position.Patrick: You mentioned that by being heavily involved with these beginner questions, things like that, it leads to inspiration for blog posts, tutorials code, things like that.We think a lot about the second order of effects of an active community.And one of those is content like that, where if you have a thriving community, one second order effect is you probably have ideas for blog posts, guides, tutorials, things like that.And I'm not sure everyone realizes the sort of power of that type of output.Swyx: Oh yeah. We have people who teach React for a living.They actually go through the Reddit to browse for people's pain points so that they can write articles. It's pretty effective.Patrick: Yeah. That's awesome. So you're working today with Svelte Society.Can you tell us a little bit about what you're working on there, and the nature of the community that's around that?Swyx: Yeah. So, Svelte Society started off as a meetup in New York, because I was friends with Rich Harris, who created Svelte.And I had basically ignored him for a full year because I was so deep into React, that I was just like, I don't need a new framework in my life.And I think we were both speaking at a conference and he gave a really convincing talk where I reached a point where I was just like, "Okay, I got to try this thing out."And of course I was impressed.Of course it solves major pain points that I had with React.And I just ignored him for a year, because I'm one of those not early adopter types.So there was a meetup that was going to happen in London, which is going to be this first Svelte meetup in the world.And I was like, "We can't have that. We're in New York. We have Rich Harris in New York. We need to meet up as well."So I just decided to tweet that. I wanted to launch a meetup. I had no speakers, no guest list, no venue. I just set a date, that was it. And then people got together and within a week we actually organized a met up with 50 people, someone from Microsoft stepped up and offered their location.And we did the very first Svelte meet up just scooping London, and eventually Stockholm also did one.So eventually the three of us got together when COVID hit.The three organizers from New York, London and Stockholm got together, and then we created Svelte Society as a global online community. We've done two conferences, we're about to have our third in April. And a few thousand developers, I think we're at 7,000 and something. And it's a small, tiny community, but it's actually a lot of fun growing something from scratch, rather than taking over something halfway and growing into something already huge. So I'm enjoying that difference in vibe. I think that developer communities where you are not the default, so everyone comes to you as the second framework or the second tooling, is a very nice position to be in because you get people who know what they're coming to you for.For example, when people choose React, they just choose React because they're told to do it, right?They don't actually know the difference between JavaScript and React, or they don't know anything else apart from React.And so some of their questions might be very off topic or just kind of not discerning.They don't actually know what they want.I kind of call this second framework syndrome, which is just actually like a positive.So I need a different word than syndrome.But essentially, once you've picked one tool in some domain, and you've gone onto the second tool, you're much more discerning and you're less likely to identify so strongly with one tool, because if you've left a tool before, you're never going to say like, "Okay, this is the solution for everything."Because you might leave the tool for something else again.Whereas I think people who are first time to a framework or to a tool might be too loyal to it and try to solve everything with it. And that's a recipe for pain.Patrick: It reminds me of the classic advertising campaign from Avis.They were number two in the market.And so this is like 1950s, 1960s mad men era, and their whole campaign was, "Hey, we're number two. So we'll try harder for your business."Swyx: Yeah. This is great. Acknowledge that you don't have the top spot, but there are things that you can still bring that people still really value.And if you just say that, I think people recognize it and respect that.I do a lot of marketing types in my line of work, and I don't like marketing that just denies reality.I think it's way better to just accept it head on, call it out.The other famous example is Domino's, right?They're just like, "Hey everyone, we know our pizza sucks. We revamped it. Come try us out." And it worked.Patrick: Big time. Yeah. Well this reminds me of a tweet you shared recently of talking about the advice, to talk about benefits versus features, but your view is that the opposite is true for developers.Swyx: For developers.Patrick: Yeah. Can you talk a little bit about features and benefits when it comes to communicating with developers?Swyx: Yeah.This is one they struggle with back and forth, and specifically the tweet is about me relearning it.So the advice in traditional marketing is to sell benefits over features, right?Sell people on the vision of what they will be with you rather than without you.Instead of, you're specific how you get there.And that's why, I guess when people sell perfume or clothes or whatever they show you someone in a fancy dress or some dude with a fancy watch on a yard or something.It's association and that's how you do marketing in a traditional sense.But I think developers have been lied to too much, where we just stopped believing in people in marketing.So if you tell me your library's blazing fast, I don't know what that means.So tell me why it's fast, show me why it's fast, don't just tell me that it's fast. Because, sure, that's a benefit.Obviously that's an improvement to my workflow.But if I don't know why it's fast, then I'm not going to accept it on faith, because I've been burned too much or I'm not going to be able to explain it to the rest of my team or my boss when I try to adopt it at work.You have to have a logical reason, because there's also going to be a trade-off right?There are some free lunches, but usually there's no free lunch.You have to be able to answer the question of like, "What am I giving up in order to get this benefit?"And usually, marketing you only talk about the benefits, and you don't talk about the sacrifices.And I think that the most concise way to do all of that is to tell you how it works.Show you under hood and give you the logical explanation for, okay, all these alternative solutions that you're used to, they all use this legacy format, and we use a different format that is just way optimized without those legacy assumptions.In exchange for all these benefits, it will not be compatible with some legacy features that you now no longer care about.And you're like, "Ah, okay, that is me and I'm sold."But if you skip all of that and just go like, "This will be faster." I can't get behind that.So I think that's my insight on developer marketing that we want to know how it works.And I think that's which is partially why open source is something that's so appealing as well. We are able to see the code.Patrick: Yeah. Do you think that the continuum from features to benefits, do you think where the messaging lands at the timeline maps to where a potential user is on the chasm?Maybe early adopters care more about how it works and late majority we're about?Swyx: Exactly.Patrick: Yeah.Swyx: Yeah. So I got some pushback on my tweet saying people don't understand how React works, and it's a black box to most people.And that's true, but because React has already crossed the chasm, it doesn't have to.So I definitely am focused more towards early adopters, because I guess I work on earlier stage companies.If you're IBM, nobody knows how Watson fricking-- What is Watson?I don't know, but it does Jeopardy.I don't talk to the type of developers that buy IBM.And no shade on them, it's just really, I think when you're dealing on cutting edge stuff you really have to open the hood.Patrick: Yeah. Agreed. Shifting gears a bit, you champion the idea of learning in public.And you described your writing on this topic as your most impactful essay.So I'm really curious, how did the concept of learning in public become so central for you and your work?Swyx: I think that it was a reflection of when you look back on your work for the past year, for me, it was like the past six months, and try to understand what parts of my work was the most impactful, and what parts of my work didn't matter at all.I realized that it was the stuff that I did in public.And sometimes got wrong in public that contributed most to my learning.And I think this idea, there's a name for it. I actually got from Kelsey Hightower, who is sort of Mr. Kubernetes now.But he's very much someone who learns in public.Something that he just learned, he'll share it because it's was valuable to him from three to six months ago.Therefore it will probably be valuable to a lot of other people. It may not be the most insightful thing in the world.He's not presenting himself as the expert in something, but that's not going to stop him from sharing something fundamental that he learned, which is useful.And if you do that, you'll not only learn faster, because you get feedback from other people.Both from people who know more than you, and also people who are with you in your journey.But also you get to demonstrate your interests, which is very good for your career. It's a two-way street.It turns your network from outbound network, you reach out whenever you need a job, to an inbound network, people understand what you're into and they reach out to you for stuff that you are interested in.And I think that's a fundamentally different way mode of operation that most developers are used to.And they don't even realize that this is possible.They're like, "Oh, you got to be internet famous to do this."And surely you can get internet famous by doing this.But to me, that's not the goal. The goal is to just have a record of what you learned.Because when we do interviews, for example, we try to have this really lossy compression algorithm.We compress all that we are, all that we can do and that we've done, into one piece of paper and hope that the other side has the right decompression algorithm to unpack that.And then we complain about how broken the hiring processes, because we stick to this completely useless thing.It's much better to have a, let's say like a site or a GitHub that just shows that I've been interested in this.I've been hacking on this for three years and here's all the things I've done. It's instantly verifiable.It's like a cryptographic proof of work. And you don't need some massive following for that.All you need to do is actually do good work.Patrick: What's a tangible example of learning in public?What does that look like in practice?Swyx: So one of my talks was about how React Hooks work under the hood, because Hooks were a major feature of React that were launched.And those launched in 2018, and a lot of people were talking about it and not trusting it, because it was a little bit magical.So I thought about this question and then I tried to make a small clone of it.And it was just a very simple, like 29 line proof of concept. And I tweeted it out. This is a career hack as well. Whenever you tweet about a company's products or a framework's features, probably the people who wrote that feature will see it. Especially if there's a company involved, they will have a Slack channel hooked up to their company's Twitter account. That's how it works, right? And so, Dan Abramov and the React core team actually saw it.And it was like almost there. There's some flaws.So he actually gave me suggestions to correct it, and I just went and did it.And then that actually got a lot of traction.So that actually led to a blog post, then actually led to a workshop that was conducted with egghead.io.And then eventually a conference talk at GS conf, that was my biggest talk to date.And all that just because I tweeted out a tiny thing that I was trying to work on myself.And I could not have got there without help, without feedback from other people.And the other thing is I would never have thought that this was something that I could do, like do a completely live coded presentation on stage without all this validation and support and help.And it's one of those things where you don't know what you have until people sometimes pull it out of you when you share it.It just wouldn't have happened if I didn't share it.Patrick: Have you seen this concept work for non-technical people as well?Swyx: I think so. So I used to be in finance and I still follow a lot of investing people in the investing sphere.So, Patrick O'Shaughnessy is, I guess, a well-known investor by now.His approach is very much in the learning public phrase as well.So he also uses that term. But he uses it to just talk about the industries that he invest in, right?He can be much more in-depth in, let's say, minerals or energy, but let's say if he wants to learn about tech or consumer retail or shipping, he can just invite a guest to go on his podcast and he'll talk about it.And that's a form of learning in public as well.You're putting a beacon out there and having real conversations.You're never presenting yourself as an expert, but you become an expert if you do it this enough.And the rate of learning is way faster than if you just did everything in private.So the argument is very much like you're not putting everything in public, but if you put it just a little bit, you actually get a lot of benefits, because there's such a great network effect to learning in public.Patrick: Yeah. It's interesting to think about the gradient of self editing that has to happen when you're deciding what to put in public versus what not to share.Swyx: Yeah. And some people, especially women, have to do more editing, just because they get attacked more.And that's really unfortunate, but it happens.And I think you have to have a thick skin, actually my preferred way of saying that you should have a thick skin is that you should divorce your identity from your work. When people criticize your work, they're not criticizing you, they're criticizing the work that was produced by some past version of you. And if you're growing at all, you should look back on your work like a year from now, and just say, that was totally horrible.So you should agree with the people who are criticizing you.And in fact, if you build a reputation of someone who takes criticism well, then they'll criticize you more and you'll learn more.And if you just don't take it personally, and as long as they don't make personal attacks at you, of course that's not acceptable, but if you don't take it personally, then yeah, you're totally fine. So the way I phrased it is that you can learn so much on the internet for the low, low price of your ego, and just get you out of the way. Are you here to be good or are you here to feel good?Patrick: That's a pretty fundamental distinction that not many people may draw.So you've mentioned before the idea of learning in public and the phrase you use is building a habit of critical learning exhaust, which I think is very poetic.What do you think the relationship is between learning in public and the communities you're a part of?How do those two aspects interplay for you, do you think?Swyx: So there's a selfish reason. And then there's a selfless reason.The selfless reason is that I think we need to make it easier for people to learn in public, to create receptive and welcoming communities that recognize that you're just trying to improve yourself just like everyone else is improving themselves.And sometimes we don't have a space for that. And when we don't have a space for that we just clam up and just not try.So if we just foster a community of people who are all improving and working on things, I think that's just a better net positive for the world and net positive for everyone in that community.The selfish reason for that is that there's a scaling law that scales beyond me.So the way I think about this is that, there are few scaling laws.Some people are very familiar with Metcalfe's law in tech, which is that, the value of a network scales according to a square of its number of nodes.And that's analogous to me having a very big "Rolodex" which is like, my friend's list is very long, then I can call upon these as experts or friends or mentors whenever I want.That's really good. But it could be better, which is what's better than Metcalfe's law?Metcalfe's law is great. But what's really explosive is Reed's law.So Reed's law is sort of an exponential growth of the number of nodes.Because each of the number of nodes can form subgroups independently of the central node, which is the reason why Facebook, when it grows, the value of Facebook grows not as number of the members, it also grows by the number of interest groups within Facebook, right?That's why Facebook groups is so powerful as a value added to Facebook, to the point where most people would just use Facebook today for Facebook groups.And Facebook just doesn't care. Doesn't have to know.And you can be in a thousand different groups and it doesn't matter.But they're all valuable to you. Okay. How does that tie back to the community?A community is a many to many ongoing sustaining relationship between all of them, and me being able to grow them.I grow at that accelerated pace faster than Metcalfe's law, because Metcalfe's law is limited by Dunbar's number like--Sorry, I'm pulling in so many concepts, but there's a limit to the number of people that I could possibly know.But if I enable each of them to talk to each other and collaborate with each other, then I benefit as well, partially because I help to be a central member of that community.But then also when I find them, they will be innovating without me there.And that's a benefit to me as well, whether I've realized it or not.Patrick: Yeah. The distinction between Reed's and Metcalfe's law is really quite fascinating.Swyx: That's community. It really is, Metcalfe's law scales, but it's so much effort to add each node, because you have this central dependency, right?Which is, let's say the company or the core team of a framework, but once you have a community, then they're just all interacting on their own basis.And you don't really have a say, which is a little bit worrying, because it's out of your control.It's adding value to your network, whether you've realized it or not.Patrick: So a lot of Orbit's customers and folks in our own community have this question where they're early on their journey.Many of their early community members are just users of their product--t he early adopters, we would call that, or the Orbit one.And they're starting to ask this question of, what's the tipping point when a community goes from mostly people talking to the company about the product or the project to talking to each other about the project, about ideas and their job and broader concepts.Can you talk a little bit about when you've seen that occur, and if there are any tools or tactics or frameworks that the project maintainers or the company founders can implement to accelerate that tipping point.Swyx: Yeah. I think I definitely am not the authority on this, because I haven't seen this occur too much.I've seen instances of it. And I just don't know if I have the authoritative story.If said like, this is the general theory of how to make networks, I think I'd be a millionaire.That's a very valuable information. But I'm actively researching this.So with all that said, I think that what can be very helpful is that you make the identities and the interest graphs of your members of your network discoverable to each other.So a lot of the times when you hire a community manager, their job is to know the community members very well, and they typically store it in their heads.But if you have a listing of them, where people can actually independently search and discover, then you really find that independent connections start taking shape.But you as someone who manages that community needs to make that happen.Because that's not going to happen in any organized fashion on its own.So one of the ways in which I do see it happening very effectively for a company or a framework is sort of an official partner designation.So you do have the ability to bless some people as the recognized experts.So at AWS, we have AWS Heroes, like we'll anoint like external parties as serverless heroes or data heroes or machine learning heroes.These will be recognized experts. I just saw that Webflow actually, and Vercel have Webflow experts or like a Vercel partners program, where these are sort of the key system integrators, I think they're called, or like agencies or whatever you call it, that are very keen on working with Webflow.So then they get a lot of benefit from associating themselves with you as experts, or just as long as they derive significant value from hiring or finding business off of you, then they're a very engaged community members, and they're very incentivized to contribute to the value of your community.And it's just like a reinforcing loop, because as you build that then more people know to come to your community to find these people.And because more people come to find these people then more people on the supply side sign up and it's like a demand and supply side marketplace type of thing. So I do think that a marketplace is like the ultimate business model. I am a huge fan of marketplaces, but it can be hard to start. And sometimes you have to bootstrap one side versus the other. But essentially what you're doing is a marketplace, where you set the rules, you make it easy for people to transact and you establish reputation systems, you establish trust, you establish like this conflict or dispute resolution mechanisms.These are all traditional forms of a marketplace, but you can actually bring all those lessons, all of it, to communities.Patrick: I love marketplace as a metaphor for community.Swyx: The other thing that you can do as well is to organize events.Because I think we as humans, we like-- Okay, most of the time we like async, we like to do things on our own.We like to build our own networks independently, but every few months we love special occasions to announce some things and to gather to celebrate something you, like a woodstock, or I don't know, basically a conference.But the definition of a conference is changing in the COVID world.And another thing that you can do is definitely organize events where people would just get together.And sometimes it can just be a small dinner, let's say we can all meet up again in person.You can just have a day when everyone just gets together and just talks, and you as a community organizer, that's a minimum viable market place, which is just like, "Hey everyone, we're all going to get to get together in this room at this time and day."Which is what I did for my meetup, right?There's no economic transaction, you're not taking a fee or anything, but you're just making it possible for people to find each other.That's a marketplace.Patrick: Thinking more broadly about communities in general.What are some trends that you've been seeing in the way communities are being built or platforms are using or methods you're seeing as we go into 2021, and what are some of the community building concepts that you're excited about?Swyx: Oh, I'm so into this. Yeah.To a point where I do have an ongoing research collection about dev communities and people who are innovating in community space.I always thought that things were sort of going online, things are going asynchronous, and then Clubhouse changed everything for me.I realized that people actually like real-time connection and the ability to ask questions and participate in chat, and sometimes video and anti-feature, which is another interesting concept, right?Because Zoom was the darling, and now Clubhouse is. A nd Clubhouse is like Zoom, but worse.So yeah. I think people are realizing that connection is real.Having events like a clear before and after is a real thing, which I think is a reversal of some of the trends that we were seeing.We were moving towards more async online chat-based communities.And I think now we're seeing some revival in live events and live ongoing discussions in spontaneity and imperfection.Beyond that, I'm not really sure I have-- Okay, so the other thing that's also happening is cohorts, right?Which Wes Kao and Gagan Biyani from Udemy are championing.Which is basically communities gated by when people join. So most communities they're just open at all times.So you just come on in whenever, and whenever someone says hi, they're just like, "Okay, it's another person it's not something special."But when you make something into a cohort, suddenly groups have identities like, Oh, I'm sort of class of spring 2019.That's Y Combinator, right? But that's also college, and that's also a cohort of communities.And those cohorts are prebuilt, it's an event.Everyone is new and everyone knows that there's a group that's going through the same experience as they are.But then there's also broader group with more experience than they are. And they can access that as well.I think cohorts are an interesting twist on how people run communities.None of this is new, right? But we're just taking lessons from maybe other domains and applying it to online communities that may not have been applied before.And I wish I could go back in time and tell myself from three years ago all this stuff, because I didn't know any of this, but now it's obvious.It's obvious to me because I watch all these people closely, maybe people who are listening, if it's not obvious to you sit up and listen, because this is real.This is very valuable. And this is happening at a very, very fast pace.Patrick: Where would you suggest people tune in or the resources or people that you follow that are particularly insightful when it comes to these topics?Swyx: Yeah. Wes Kao is pretty much leading the core based course league.Rosie Sherry, from Indie Hackers is definitely collating a lot of community news.There's also Greg Eisenberg, he runs a consultancy that starts communities for people.The only problem I have with him is that he thinks of himself very highly.So he rubs people the wrong way, I think. But he does have valuable insights, which is very frustrating.Sometimes arrogant people are worth it.Patrick: Yeah. I think it's complete opposite of someone like Rosie, who is such an intellectual heavy hitter, but also so humble.Swyx: Yeah. I got more resources for you.So by the way I collect all this in my circle community.So, codingcareer.circle.so is where I collect all this information.So there's Get Together, which is a book and podcast for people who form communities.There is CMX Hub, which is, David Spinks, who has been doing this awhile as well.There's a bunch of people in this community space.Oh, Lolita Taub is a VC who just launched the community fund.So they're specifically a venture capital firm that is focused on companies building communities and companies building tools for companies building communities there's a whole circle of that.Patrick: Yeah.Swyx: There's a lot of stuff. And then there's also a couple of books that people really like.So Nadia Eghbal, Working in Public has some sense of community building in her stadiums and whatever and village metaphors.And Laís de Oliveira, has a book on hacking communities, which I haven't read, but I've definitely singled that out for reading up.Anyway that's just my resource dump.And I'm keeping this list because I think it's a growing knowledge base of what it means to run a community, and what are all the different ideas that people are bringing to their communities.Patrick: Awesome. Thanks for sharing that.So zooming out a bit to a question that I ask pretty much every guest on the show, what do you think is the secret to building things developers love?Swyx: So in that tweet about development marketing, I actually also mentioned another concept, which is a wow moment, right?And I actually expanded upon that by saying a wow moment should be something that inspires you to talk to your friends, tell your friends about it.It makes your jaw literally dropped. And it makes you never want to go back to the old way of doing things again.It creates a clear before and after. There was you before seeing this demo or seeing this tool, and then there's you after. And it creates a gap, because it makes everything that you used to do before the old way, you didn't even use to call it the old way. It just became the old way once you saw this new thing. And I think developers love something that takes away some pain that they might feel at their core, but maybe sometimes they don't even know that they have it.So I'll give you one example, which is Prettier in the JavaScript ecosystem.Anyone could have built Prettier in any of JavaScript's 25 years of existence, but nobody did.Until it was some-- It's Christopher Chedeau, but someone just went like, "Hey, Go has this really nice formatting tool. What if we just had that in JavaScript? And what if it was just standard."And he built it, and now it is standard in the span of two to three years in JavaScript, which is massive.And people love Prettier for what it does. Which is pretty funny.The thing is you'll never make everyone happy.There's a very strong band of people in JavaScript who don't like Prettier for their own reasons.But you make a lot of people happy and they do say that they love Prettier.So I think that's one of those examples where, there was an old way, which is you manually formatted your code and you had code review stand up meetings, where you argued over the spacing.I've been in those meetings, okay?And then there's an after, with this tool, where you no longer spend any time on that, because you just have a standardized tool that just does all that for you.So I like that. And I think that's one example of making things that developers love.Patrick: Aside from beautiful code.I always ask people, what's one thing you're loving right now?Swyx: I'm loving Transistor.fm for hosting my podcasts.I do run a couple of small podcasts, nothing like yours.But it makes it very easy to host stuff and generates a website for you.And it just takes away all the pain for me that I don't want to do.So I will pick Transistor.I guess I also pick Stripe, because it's such an easy--I wrote a book and I run the entire fulfillment from beginning to end, and Stripe checkout was so such an easy thing to integrate that I happily paid them their 3% or whatever it is.Patrick: Yeah.Swyx: Not a very non-consensus pick. I have to pick Stripe. But I do have to give them credit.Patrick: Well, you've been super generous with your time today.We've covered a lot of really fascinating topics.If people want to learn more about you and what you're working on, where online would you send them to go do that?Swyx: Yeah. Thanks for having me. My Twitter is where I'm most active.So twitter.com/swyx. And you can find my blog at swyx.io to get all my talks and book and whatever else you want to find out about these ideas.Patrick: Awesome. Well, thanks so much for coming on the show.Swyx: Thanks for having me.

Season 3, 1st edition of 2021 of the FINOS Open Source in Fintech Podcast: Dan Abramov of React Core Team Interview. So… welcome to 2021. We’re looking forward to a better year overall, even with some “interesting” beginnings. To start you out this year, while we’re working on our 2021 meetups and interviews, we want to highlight a few great discussions we’ve had within the community over the past couple of months. Our first of the year is an interview / fireside chat between Dan Abramov and James McLeod, recorded at the Open Source Strategy Forum (which is FINOS’s annual open source in financial services conference). Dan is a software engineer at Facebook, member of the React Core team, co-author of Create React App - and well regarded in the javascript community. James is our Director of Community for FINOS, and host for many of our Open Source in Fintech Podcasts and Meetups. During this interview we learn whether a project like React would work without backing from a large company like Facebook, whether Hacktoberfest raised issues for the React Core team, and how Facebook promotes InnerSource projects to open source, and more. So please enjoy this interview, check out our previous episodes, and subscribe to the podcast for some great upcoming discussions on open source, financial services, fintech, and how they all fit together. Dan Abramov's Bio Facebook Software Engineer, Member of the React Core Team, and Co-author of Create React App Dan Abramov is a software engineer at Facebook, member of the React Core team and co-author of Create React App. Prior to joining Facebook, Dan co-authored Redux, a predictable state container for JavaScript applications, which catapulted Dan as an influential conference speaker and successful Twitter commentator. Follow Dan on Twitter -=-=-=-=- About the Open Source in Fintech Podcast The FINOS Open Source in Fintech Podcast celebrates open source projects and interesting topics at the cross section of financial services and open source. So far, our industry experts have discussed practical applications of and their real-world experiences with a range of open source projects including desktop interoperability, low code platforms, synthetic data, and data modeling. They’ve also discussed best practices for inner source, common myths about open source and why commercial companies choose to introduce open source offerings. Tune in and subscribe to hear what comes next. ►►Visit here for more FINOS Meetups ►►Visit the FINOS website - and Get Involved ►►Join us for the FINOS & Linux Foundation Open Source Strategy Forum (OSSF).

Sergey Bekharsky, the founder of "HTML Shit" and a Senior JavaScript developer from Supermetrics joins A-P Koponen on the Frontend Greatness podcast to talk about "Folder Structure" --- Video version: https://www.youtube.com/watch?v=v7dsfjXD7Dw --- Episode Notes Social - Sergey's Twitter account: https://twitter.com/bekharsky - Sergey's "HTML Shit" Telegram (in Russian): https://t.me/htmlshit - A-P's Twitter: https://twitter.com/apkoponen Show Notes - "React Folder Structure in 5 Steps" by Robin Wieruch: https://www.robinwieruch.de/react-folder-structure - "move files around until it feels right" by Dan Abramov https://react-file-structure.surge.sh/ - Feature slices: https://sova.dev/application-structure/ - Atomic Design by Brad Frost: https://atomicdesign.bradfrost.com/ Sergey's Recommendations - Lea Verou's site: https://lea.verou.me/ - Web.dev: https://web.dev/ - Kent C. Dodds site: https://kentcdodds.com/

Originally published May 16, 2019 React is a set of open source tools for building user interfaces. React was open sourced by Facebook, and includes libraries for creating interfaces on the web (ReactJS) and on mobile devices (React Native). React was released during a time when there was not a dominant frontend JavaScript library. Backbone, The post Facebook React with Dan Abramov (Repeat) appeared first on Software Engineering Daily.

Rocket developers Brandon Aaskov, Dave Oelfke, Simon Ingeson, and Matt Merrill dive into the topic of clean code. When is it worth it? When is it unnecessary? Will it get you in trouble with your teammates? We also share some practical tips for walking the line between "You ain't gonna need it" and when it's worth it to spend that extra 20 minutes cleaning up code.  This podcast was inspired by the article "Goodbye Clean Code" by Dan Abramov which ignited a lot of talk in the Rocket Insights engineering slack channels! Detailed Notes: 00:00 - Intros 03:20 - Human readability is the most important thing. Are there any hard and fast rules? Cyclomatic complexity is a fancy word that's discussed 06:00 - It's hard to break out of a bad abstraction. It's hard to predict the future 11:00 - There's nothing more permanent than temporary 12:15 - Spreading out your code over lots of folders is probably not a great idea 14:30 - Flexing your muscles... Unnecessarily? 15:26 - A word from our sponsor 16:30 - Wait for the pain 19:30 - Give yourself flexibility for the future, but don't implement it right away 20:40 - How did we get to this point? A little history. Memory management wasn't always done for us 27:00 - There are no hard and fast rules. Be an adult 29:45 - The golden hour rule. Readme's are important 37:45 - Back to what makes code readable 41:00 - Testability. Using tests to learn about existing codebases 45:00 - File driven development 46:30 - Why refactor? 51:15 - The good samaritan rule 51:50 - Picks: Matt - HBO Silicon Valley Season Six Simon - 1917 (the movie)  Dave - Nest.js Brandon - Master Class 

In episode 3, host Brandon Aaskov talks with Rocket Insights Software Developers Dave Oelfke and Ian Pirro about State Management on the UI.  They go deep on Redux, alternatives to Redux, and where these tools should and should not be used.  As always, we end with our picks (totally unrelated to State Management) for you to follow up on! Topics: 0:00 - Intros and a brief history of Redux.  Opinions abound! Scott O'Brien - The Rocket Insights dev who (used to) troll Dan Abramov (creator of Redux) on Twitter 2:30 - What is Redux? 3:30 - GraphQL and Apollo as an alternative (or compliment) to Redux. 5:00 - When does using Redux make sense? 8:45 - Redux vs. MobX. 14:15 - Angular 1.3 two way binding, oh no! 16:45 - When should you reach for Redux? When are your components too complicated? 17:30 - Should you use React's Context instead? 18:03 - Will React Hooks do away with Redux? Note: This episode was recorded when Hooks weren't yet available for GA release. 25:14 - Back to Apollo - Subscriptions. 26:45 - Hot takes! Don't use Redux. Use Mobx, or Vue and VueX instead. 31:30 - Hot takes! Mutability is ok. 34:45 - I just want to use things that work, not the newest fanciest thing.  37:15 - Redux on the server!? 39:45 - You can write your app in jQuery and Redux (!?) 40:45 - Picks! Brandon - The Night Of on HBO. Dave - Subscribe to Pewdiepie on Youtube! Ian - WeWantPlates subreddit.

Sunil Pai is a Software Engineer at Facebook, React team member, and the creator of Glamor. He joins us on The Undefined to talk about the state of the web, the past, present, and future of text editors and IDEs, how he learned to code, and how our community needs to evolve to survive.FeaturingSunil Pai – Twitter, GitHubKen Wheeler – Twitter, GitHub, WebsiteJared Palmer – Twitter, GitHub, WebsiteLinksStop writing code - Sunil's talk at React Europe 2018The “Something” Statements - Sunil's talk at React Rally 2018Visual BasicNeopetsAdobe FlashAtom EditorVisual Studio CodeList of mergers and acquisitions by MicrosoftTypeScriptPrettier - Opinionated Code FormatterVSCode IntelliCode Extension - AI-assisted productivity features for Python, TypeScript/JavaScript and Java developersVSCode Color Picker Extension (aka "Fady Gradient "F**ker)Framer XGlamor - Sunil's CSS-in-JS library for react et alJSSAtlaskit by Atlassian - Atlassian's official component librarySalesforce's Commerce Cloud (formerly Demandware)Sketch SymbolsGlamor's CSS selectors (e.g. ":hover")JSX specVue-loader Scoped CSSReact Hooks - They let you use state and other React features without writing a class."My Coding Journey" - Revel Carlberg West @ ReactNYCReact createClassCreate React App - Set up a modern React web app by running one command.Codesandbox.io - CodeSandbox is an online editor that helps you create web applications, from prototype to deployment.AWS Cloud9 - A cloud IDE for writing, running, and debugging codeWeb Audio APIAndroid Studio/SDKService Worker APIWeb Components API"Tumblr will ban all adult content on December 17th" by Shannon Liao, The Verge, Dec 3, 2018Codepen.io - A front end web development playground.Sunil's Gist on CSS-in-JS: "How does writing CSS in JS make it any more maintainable?" - (Hacker News Thread, Original Tweet)Addy Osmani, Sarah Drasner, and Dan Abramov (blessed be he)Mozilla Firebug Editor Extension for Firefox"What is a JavaBean exactly?" - Stack OverflowArray.prototype API on MDNKen Wheeler on Spotifykenwheeler/cash - Ken's absurdly small jQuery alternative for modern browsersFormidableLabs/react-music - Make beats with React!Rust Programming Language TutorialPicksTical by Method ManTile appCalifornia by Blink 182birkir/prime - Open Source GraphQL CMS

On this episode of The Diff, Joel talks React and React Native with Dan Abramov and Tom Occhino. Find out how React grew to become one of the most popular projects at Facebook and on GitHub, and how we manage such a growing and vibrant community. Learn what drove the development of React Native from the React architecture. And how Redux started out as a project developed outside of Facebook only to now be used in core projects within the company.

Guests: Brandon Hays: @tehviking | Blog Chris Freeman: @15lettermax In this episode, former Fronsiders, Brandon Hays and Chris Freeman join Charles and Taras to talk about the difference between a framework and a library, whether or not React + Redux a framework in itself, red flags to signal that you're actually building a framework, attributes of a good framework, how can you tell if you created a bad framework, and how you can make a bad framework better. Resources: Test Sizes by Simon Stewart This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. ** Transcript:** CHARLES: Hello everybody and welcome to The Frontside Podcast. My name is Charles. I'm a developer here at Frontside and today, we're going to be talking about the things that go into making a JavaScript framework. Because, hey, there's not enough of those in the world today, so we're going to talk about that and with me is Taras. TARAS: Hello, hello. CHARLES: And we've got two very special guests, who have a lot of experience with this topic. Mr Chris Freeman and Brandon Hays. Hey, guys. CHRIS: Hi, there. BRANDON: Hi, there. We're talking about the poofberry framework, right? CHARLES: What's a poofberry? BRANDON: There's a tweet that's going around right now that one of them says, "I don't know what I should be doing," and the next person says, "Oh, just use poofberry." What is that? It's like fluffnuts but the [inaudible]. Hey, dot, dot, dot. Then, it integrates with log bungler. CHARLES: There's a reason that I'm dying laughing. BRANDON: It's so true. CHARLES: It's so true, laugh, cry, laugh, cry. Let's start with kind of a very basic assessment here. Because there's a lot of different things that you can use to compose the applications that you build but for some reason, some of these things are grouped and considered as libraries and some of them are considered frameworks. I don't know that the boundary is very clear like I'll know it when I see it type thing. Maybe, we can start with what is the difference between a framework and a library? CHRIS: I have some thoughts of these. I feel like this is one of those questions that could easily just turn into an infinite bike-shed but I remember reading something a while ago that stuck with me for a long time. I'm pretty sure it's related to Java but that makes sense because if anyone is going to talking about frameworks, it's Java developers. But it was saying that the difference between a library and a framework is inversion of control and the idea is a thing that's a library is a thing where you are in control. You bring the library code into your code and it's up to you what you do with it. In a framework, the framework code calls you as I think what it said. It's like, you call the library code, the framework code calls you and -- CHARLES: In Soviet framework. CHRIS: Yeah, exactly. A framework says, "Here are a bunch of open spaces for you to put your code in and I will take care of the rest," versus a library is just like... I don't know, "Here's some things that you can use. It's up to you. What do you want to do with them?" CHARLES: Right, so in kind of like [inaudible], that would be basically, a framework would be the thing that's got the main method. I think the same thing in JavaScript and when you call it, does it actually implement the main method. In JavaScript, it'll probably like in node. Under that definition, it would be like, "Are you the main scripts when you invoke node? Do you control the main script?" If you were doing your own command line parsing, for example, you're looking at the process.rb and pulling off the command lines and doing all the things but even if you're using something like Yargs or option parser in Ruby, that's more of like a framework. I guess Yargs is a library because you're still implementing the script. You're instantiating the Yargs thing. TARAS: React calls render to figure out what to convert to DOM. Does that make React the framework? CHARLES: I think React as a library. That's a good question. What's the equivalent of the main method on the web? CHRIS: I think there's a very clear distinction, especially if you look at React versus something like Ember and I'm sure Angular does this as well. In React, by default, to build a React thing, you're going to pull in React, you may write some components, you may import them elsewhere but the main method is that you have an index.html with some div in it and you are the one that has to call ReactDOM.render and you pass it like document.query selector or whatever and then, your top level component and that can be as simple as complicated as you like or you can have a webpack plugin do it or whatever else. But the onus is on you to actually take that React app and get it starting up on the page versus Ember, it's like, "There's an index.html. It's fully wired up." There is one point where you sit down and say, "Start my program here," like Ember abstracted all that away. To me, that's the main method for a frontend application. CHARLES: Right and if you actually look at something that Ember generates, then look at index.html, they generate a script tag for you that instantiate your application and mounts it on an element. If you want to change that element, that's actually a configuration option that you can change but it still a configuration option that's consumed by the framework. In that sense, there is that inversion of control. I see what you mean like in React, you're the one who flicks off the first domino, like who's the prime mover. Is it you or is it the framework that knocks over the first domino? BRANDON: I like Chris's explanation and I think it's elegant to say because I was thinking in terms of structure. If it imposes a structure on you but really, the structure is there, it's like one of those Ikea shelf systems for you to put stuff into. If you're trying to solve a problem, here's a shelving system for you to put stuff into, whereas a library is just the tool that you might get out to put something together. Something that's multi-purpose but doesn't impose any structure on you or a ton of structure on you. My question is what's the usefulness of distinguishing between the two? TARAS: I think what's interesting and I had experienced this in a last couple of projects is that people, especially React when they kind of assume, because a lot of people entering to React not understanding the context within which React emerged and so, they're getting into React assuming that it has everything you need to build application that you need to build. A lot of them haven't necessarily built a single page application from scratch before and so, the jump into building something with React and then, it takes about a year for them to realize the full scope of all of the features that their application actually has and then, they kind of take a retroactive look and look like, "Okay, what do I have now?" and what emerges is that they've actually over the last year, they may be creating a framework without realizing that this is actually happening. CHARLES: They've imposed the structure of saying, "Here's the shelving system. Books about geography go here. Books on English literature go there and so on and so forth." BRANDON: But when you rolled your own framework, that's not how it goes. It's like, "You have to launch this balloon into the stratosphere to put a book on the shelf from geology." Taras, to your point, it sounds like the importance is setting expectations properly for people, so that they know what they're in for because kind of calling back to Ryan Florence's post a few years ago, you can't not have a framework. At some point, you will have a framework in order to ship something. I would actually take it one step further. My friend, Kyle talks about this that library is the smallest unit that you're working within a framework but that still doesn't take your code to production and put it in a debugable state. You need a platform. It's arguable, if you're handling deployment tasks and debugging tasks and operating software in production, you now have a platform and it's fair to say that Rails crossed that threshold at one point. It's fair to say that Ember has probably crossed that threshold, if you combine Ember with CLI deploy and the CLI tooling and all of that stuff. This almost like acts as a platform if you're owning and maintaining the software in production. CHARLES: Now, can I play devil's advocate here and say, the platform, is that necessarily predicated on a framework? Is there a pyramid where it goes library, framework, platform and one is built on top of the other? Why couldn't I have a library? Because what I'm hearing is the scope of concerns is just rendering HTML based on a state is a very small chunk. The actual scope of things that you need to do to get that code in production and have it be reliable and do all of the features that you want to do is just massive but why is that predicated on a framework? For example, one thing you have is a bunch of libraries out there, like routing for managing the title tag, managing all these things that you have to do for managing deployment, for building your application, for compressing it. There's all these different libraries out there. What if there was one massive library that just picked a bunch of other libraries but I was still in control? TARAS: I've actually seen this happen in the last of the projects. When people jump into building, they will eventually realize that they're building a platform but what happens before that is that they take user's requirements and they break those up by sections and then they assign them to a bunch of development teams who go and actually start to build. On one platform, they end up building five or six or 10 of siloed, packaged applications that have, in some cases, have their own dependencies, they have similar architecture, might not have similar architecture. Each team kind of implements thing differently and there's an expectation that once you package these things as npm and then you install them into one package, to one application when you run build, it's just going to work together. That's where I think, with the framework, it does create a foundation for these verticals to be implemented using kind of common foundation. This is what a lot of times that as if you don't realize that what you're trying to set out to build, the way that the projects get managed quite often, especially for big applications, for big platforms is that, it creates this period of about two years, where there's a lot of confusion and there's a lot of duplication and then, you end up seeing code that it's hard to put in production. CHARLES: Yeah, I agree. I'm curious then, because we'd started out talking about library and framework and talked about it takes two years to recognize that you're building a framework or you're building not a framework but a platform. Brandon, you said something very interesting. Rails for example, crossed the threshold of being more than a framework and actually, being a platform. What are the concerns of a platform that are beyond a framework? We talked about and using the kind of loose definition of a framework as being something where the framework create spaces for your code, to run your code so you can just take little dollops of code and they have one concern but the framework manages the coordination of the concerns but what's the next level? BRANDON: For the purposes of this conversation, I may have muddied the waters a little bit because I think it's more interesting to talk about the transition and the level of which you've crossed the threshold from being a library or using libraries or collecting libraries, into maintaining a framework because it's where you're going to experience more pain more than likely, than to me, the idea from works on my machine, to deployed and supported across a lot of users, it sounds like it's more interesting but it's not where we experience most of our pain actually. From my experience, maintaining frontend single page applications most of the pain is actually getting the damn thing to work on your machine and getting the libraries to collectively work together and then, getting that to production, it kind of enters back into an area of more known unknowns. I think that's a surprisingly a more mature ecosystem, still getting from this thing works on my machine to getting it out the door. That wasn't true when Rails was invented and so, Rails had to invent a lot of its own ecosystem around this stuff. Like I said, I don't want to muddy the waters too much. I think to me, the interesting question is how do you know you've crossed this threshold? What pain points are exposed when you start crossing that threshold or when you're pushing the boundaries of that threshold? Because you should not be using a framework if you're using React to do a select dropdown. I think of it as, if you're using it the way to replace something you might do with a jQuery plugin five or 10 years ago, you're using React like it's a library. One of the questions that you brought up was is the combination of React and Redux is a framework and I would argue that it is but I kind of want to throw that out -- CHRIS: Oh, interesting. CHARLES: I would say, it's two libraries stuck together to make a bigger library. It's like a monolithic library. BRANDON: But by the time you're actually using that to do anything, maybe the third thing in there is like transitioning states when you transition routes. At what point is that threshold crossed? I didn't build most of the software that led me to some of the opinions that I have about this. This was actually Chris Freeman's, though. I may defer to you on this. CHRIS: I think React + Redux constitutes if you look at what it does. You have like this view layer and this state layer. There's a set of opinions on there that is useful and there is the foundation for doing quite a bit but in my experience, you've already kind of alluded to this a little bit. I don't think it's a framework because as soon as you start using those two things, suddenly the next thing you hit is, "Wait. How do I handle asynchronous things?" There's a lot of different options for that. "Oh, now, I need to do routing. How do I incorporate routing into my React app but also in a way, that is amenable to state transitions in Redux but also, that is aware of the async stuff that I'm doing, that is going to possibly be triggered by my routes and by my Redux actions or by some other side of things?" Suddenly, you are very quickly pulling out a bunch of other libraries but also, probably starting to build abstractions on top of them because you're already finding a lot of common patterns that you're repeating over and over as you incorporate more and more pieces of the stack and then, you're writing a lot of glue code. I think that's the point where suddenly, you look back and behind you is the footsteps of this framework that's been walking alongside you the whole time. BRANDON: That is where I carried you, then dropped you, then sort of drowned you. CHRIS: Yeah. CHARLES: And then, kicked your core. TARAS: I'd like to suggest a way to think about this. As you guys are talking about, it kind of occurred to me is that it seems to me that libraries concentrate on how and frameworks focus on the 'what.' CHRIS: Oh, I love that. TARAS: Because if you think about for example, React is how geostack efficiently update DOM, then Redux is how do you wire together state across multiple components that might be in different parts of state tree and if you look at, for example, a React router or a kind of a routing component is how do you choose which components you want to render when you navigates specific URL. Because those things by themselves are not a complete solution but when you combine them together, what you get is you have a way of saying, "When I navigate to specific URL, I'm going to load specific data, provide that data to components and then, I would have a way to navigate through a different URL when you click on a link." From that, I think what happens when you get to the framework level is you actually have a kind of a bigger umbrella and under that umbrella, you have ways to address problems that you did not have previously. I think that's what framework does it is over time, it's a way of addressing concerns that cannot be addressed with a solution. They have to address with a collection of solutions and then, they provide a specific solution. I don't know if that's -- CHARLES: That actually sparked off a train of thought in my mind that perhaps what you really want to do is say, "I'm going to go a little bit like Lisp on you all," in the sense of every code at some point is data, that maybe every library, at some point is a framework. It's just that you can look and say, "What is the scope of the 'what' that I'm tackling." For some point, you can say like React is a framework. It creates this space where I can put my JSx, AKA the render function and I'm basically inverting control and so, what it is, it is a framework for efficiently rendering HTML or efficiently mapping an object to a fragment of DOM and then the DOM that gets generated from your render function, patching that into the HTML. You don't have to worry about that. There's that inversion of control. It creates that space but that's the only space that it creates. From that perspective, React is a framework for generating HTML but that's all it is but it is a library for constructing applications. Does that make any sense? I think as you layer on concerns, your framework create spaces for you. You use your library code to put stuff in and so, in the same way, I think one of the key realizations, I'm going to call up like BigTest and I'm not going to take credit for this, which is actually a blog post that I read at Google. I can't remember what it is but we'll link to it in the show notes where he said, "There are no such thing as unit tests. There are no such thing as acceptance tests. There are just tests of varying scope." They're all acceptance tests. To use that one thing, they're all experiments. It's just what is the scope of the test that you're trying to accomplish and his argument was we want to make that scope as big as possible by default and then, where appropriate, you narrow down. Maybe, the framework library distinction is a little bit constructed, kind of a construction of our own minds and what really is there, there's just frameworks of varying scope. BRANDON: Agreeing on a shared scope is actually probably the most important part of this conversation. We're referring to building end-to-end an application from data access to rendering to testing -- CHARLES: To deployment to routing. BRANDON: Yeah. CHARLES: To one day accessibility. BRANDON: Yeah. Adding that into the discussion is like a baseline of what constitutes an application. It's the percentage of people that are able to actually use it, the people that are locked out from using it by ability. That's a very useful frame for the discussion. Let's agree on the scope of what an application is and then, coming back to what Taras was saying is basically, when you're talking about the 'how,' that's a decision point. You hear a lot of people talk about decision fatigue in JavaScript and it's almost a played out trope at this point but it hasn't gone away as a problem, so what frameworks are doing is they're making a series of decisions for you that allow you to basically connect the pieces from end to end. Basically, somebody threw a rope bridge across the canyon and it doesn't have to be the best solution to get end to end but we have to solve the problem end to end. If we agree on the places end to end and the problem is when you're building your own series of libraries, you're like, "I'm going to choose best in class of A, best in class of B, best in class of C," and that sounds really good but if you're trying to build a bridge across a canyon and you're building in 10 best of class sections, for the type of connection we're trying to make here in the middle, we're going to use the best in class here. The weak point is in the connections, so you had better be the world's foremost engineer if you're going to be the person connecting all these disparate pieces that are each best in class, in order to bridge this canyon. That's the thing that's interesting to me and it's not even agreed in our industry that JavaScript-based web applications are a good thing or that the browser is web application runtime, those are things that are up for debate. But I think if we make that assumption, this is sort of the founding principle of where Ember came from and it executed to the best of its ability at the time and that philosophy is, I think you can prove it out in terms of results based on if you have two different applications, one of them is built by somebody trying to jam together best in class components and the other person is starting with an end to end solution with a community of people rallied around that solution. It's been interesting to watch those approaches play out over time. I know Chris has a very specific hands-on experience of having done both of these. I'm curious to get your hot take. CHRIS: There's actually a concept that I think about a lot in relation to this question. It's something that I actually heard come up again recently so the timing was great but it's called hypocognition. The idea is hypocognition is when you either just like can't see or can't understand some kind of cognitive representation of something because you don't have the words for it. An example is in Western cultures, especially like in English speaking cultures, there are not that many words for the color blue but in a lot of other cultures, they have many, many words for the color blue. After doing a big study they found that these English speakers actually have a harder time recognizing different shades of blue, like more of them just look the same versus other cultures where their brains are actually wired to see all this variety because they actually have the linguistic representations for these ideas already. When you were talking about maybe a library is a framework at some point, I think that's right on. I think one of the things that I think about a lot when talking about frameworks and seeing these debates happen on the internet about, "What is a framework?" but also like, "Do you even need a framework?" is obviously, there's a lot of people who absolutely... Like Ryan Florence. Ryan Florence clearly knows what a framework is. He knows what it takes to build a web application and he does not lack the words to define a framework versus a library. He's just made that choice and it's a very informed choice but I wonder if there's also a lot of people who are getting into web development for the first time and they look at something like a framework and it seems just absurd to anyone would want all of the things that like in Ember or in Angular is talking about, when they can make a basic UI with React and it's easy and fun and really cool. But then this two-year path happens and they look back and they've learned a whole bunch and now it's like, "Ooh, you couldn't even have explained this to me before," because all of the words would have fallen on deaf ears but now suddenly, it makes a staggering amount of sense. CHARLES: Right. I love that. BRANDON: You have to make a bad one. CHARLES: Just so that you can inherit the vocabulary to understand why you made a bad one. Now, you guys actually have some experience with this. Brandon, you gave a talk about it, which I think you should give more widely because it's fantastic but for those folks who may or may not be aware that they are walking this to your path, I want to talk first about what are the signs that you're walking along this path and then two, what are the consequences in terms of the cost you're paying for walking this path. Let's start with that first thing. What are the signs? How can you tell that I am building a framework? CHRIS: I think one of the telltale signs and one of the biggest red flags that caused me and Brandon to have a very serious heart to heart about our own personal framework was when we hit the point where you could look at a set of tickets for features and all you saw was 'framework features' that you needed to write before you could build the feature itself. You know like, "Oh, we have basic routing setting and we have it set up so that if you have a route transition and you would like a data request to happen when a certain route transition happens, that will happen," but then someone would like infinite scroll and we want to use a query param. When a query param changes, I want to update the query and fetch more records, except that the glue code that we wrote to tie our router to our redux async stuff is not aware of query params. It has no concept of what a query param is or what to do when it changes. Also, it has no concept of refetching the data without a full route transition, so what do we do, this person wants infinite scroll but I first have to implement several layers of framework code before I build the UI feature that you want? CHARLES: The basic heuristic there is ratio of direct feature code to code that supports the direct feature code and code that supports the code that supports direct feature code. It's anytime you're anywhere above that first layer on the stack. CHRIS: Yeah, I think Taras nailed it like what's the 'what' versus the 'how.' If you're asked a question that is concerned with the 'what' and you spend more time focused on the 'how,' then you might have a framework. BRANDON: I think people will think of building an application like a recipe. If you think of it in those terms, people think of frameworks as very restrictive but I'm a big fan of Blue Apron, a sponsor of this podcast. Thank you. They pre-select the ingredients and they give you the instructions and you know what to do, you still have to do the effort but you know if you connect these pieces together properly that you're going to wind up having a good experience and then, it gives you a lot of freedom to experiment and be creative beyond that, should you choose to. I think one of the signs that you've done a crummy job is that you're staring down, like Chris Freeman said, you actually starting to restrict your choices like, "I can't actually build you that feature because we don't have time to take on the amount of work necessary to build the support structure, to build you that feature," or if you find yourself writing a test framework. CHRIS: Oh, yeah we did that too. BRANDON: You know, we were real deep in this. There are developers that are like, "I really want to feel like I'm walking into a grocery store and selecting all the things necessary for my recipe," and so it really depends on what the problem actually is. If you're working at a giant megacorp and you have a two-year timeline to deliver something and their goals are not about delivering stuff on a tight turnaround, that's usually a recipe for a software failure anyway but let's say, that you're in the 5% of those types of projects that's going to succeed, that might be a good place where you can say, "What we're trying to do here is so custom and we have such a long lead time and a long leash and such a high level of internal expertise here that we should be shopping in the grocery store and we should be selecting all these things and we should be solving these problems." Basically, when is it time to use a framework? Well, when you don't have 10 times the time you think you do, when you don't have the ability to spend 80% to 90% of your time in the first three to four months of your project, maybe six months, debugging you're glue code in between the different libraries that you're gluing together and then coming back and realizing that you've painted yourself into a corner and you have to re-architect your whole framework, then you could be so proud of this baby, 18 months to two years from now, when you actually have delivered both a framework that took about 70% of your time and an application that took 25% or 30% of your time. CHARLES: Yeah. I think it's important to realize that people think we'll do it and we'll build it as we go but I want to call out right there, you will be spending 80% of your time and you have to be upfront about it. Of this two years, 18 months of it is going to be spent building this framework and six months of it is going to be spent actually writing the feature code and you have to be 75% of your tickets or your issues, whoever track the work, 75% of that has to be dedicated to the framework. BRANDON: If you're going to bake in that kind of overhead purely for the satisfaction of a single or one or two developers that like inventing things, that is literally the worst possible reason you could do that. That is almost like a guaranteed recipe for failure. It has to be for some other business reason like, "We want to be the company that owns this." There has to be business value attached in making that kind of investment. If you can't justify that at the outset, then you should probably just go ahead and lean on an existing framework and join a community of people. CHARLES: Yeah and I think one good litmus test for that is, "Is this a 'what' for which there is currently no 'how?' One of the reasons we're writing BigTest is because for the general JavaScript community, there are a number of acceptance test frameworks out there but the market is very, very limited. When we look to actually acceptance tests, our React application, this thing does not exist. Now, we had experience with something that was very like Ember specific and so, we kind of knew what the 'what' was, we experienced the 'what' but there was no 'how' for our current situation. That's like a place where you might be called upon where makes business sense to actually invest in a framework. I'll tell you another thing too is if you have made the decision to kind of follow the beaten path on the other areas, then when a framework is called for, you have the bandwidth. You've allowed for the buffer, for the margin, for you to write in with that framework, whereas if you're already just by default, maintaining all the glue code in every single thing, then if some unique 'what' comes along, for which there is no 'how,' you're not going to have a bandwidth to tackle it. BRANDON: Yeah. That's a real bad situation to be in. TARAS: There's something else that I find interesting is because there's a certain point, like this two-year mark where everyone's like, "We want to fix this now." I think what is interesting what comes next which is the three years of undoing all the stuff that you made because the biggest challenge, especially in really big projects. When your projects has to borderline into platforms and a platform threshold is when you have a multiple teams working separately to write separate modules that run, maybe in a separate Git repo and maybe, packaged in separate npm package and assembled together. Then what happens at that point, the question arises like how do you actually make this changes in this environment. Answering that question is actually really difficult. I think if you look at frameworks like Ember, Ember has made it their business to figure out exactly how to make this happen and I think they've done it really well but it's a really challenging endeavor, especially in incorporate environments where they don't have an update. You have like upgrades are like a curse. It's like a thing that you don't really want to ever do and because most quite often, they don't have the right testing habits in place to be able to support the change if necessary. I think what a lot of times happens is that the team that made the framework in the first place, they end up trying to maintain a fort but you won't have like 10 people and they only have machetes, you know? All you can do is run around and try to chop down little twigs but at the end of day, the trees is still going to keep growing. I think that's the really challenging part of being two years into a project, where you realize that you actually need something much more comprehensive than initially thought you needed. CHARLES: On that, assuming that you have decided that you are going to make a framework, it's a good business decision for you. Based on the criteria of this discussion, how can you assess whether it's good? Chris, you talked about needing to integrate query params with routing and asynchronous data loading and making sure all of that coordination happened and worked together easily. What's the difference between your framework just missing features kind of having holes in it that can be filled in, versus something that's not good and it's going to cost you lots of money down the road. CHRIS: Yeah. TARAS: One thing, if you look at what makes a good library of any kind, it tends to be like how effectively and how much words to take the address the use cases that you need. The problem is that to build a good framework, you need to understand the use cases. This is what usually happens over time. Two years in, you've actually understood the use cases and now, it's time to change and so, I think if you want to build a good framework, you actually need to understand those use cases quite early on or account for understanding use cases over time and that's a big question -- how do you figure out how to know what you don't know. CHRIS: Yeah, I think that's exactly right. I think about what you were just saying Charles and Taras like one of the things that I think has a big impact on and what this process looks like is the completeness of vision for what's your project actually is. If you have a very, very clear idea of what the entire product you're building is going to be or, at least what the key money-making feature is going to be and you can understand the ins and outs of that, then I think that's the point where you can look at what you have and say, "Have I created a good or bad framework? Does this framework have the ability to solve this one very important thing that I have to be able to do? If the framework doesn't do it, then I need to build my own but I now know what very important features I need to front load my framework with." I kind of think of it as imagine that you're like Jeremiah Johnson, the Reverend Jeremiah Johnson and you're going to go trekking through the woods for some unknown amount of time and you have no idea yet. You don't actually know where you're going. You don't know what you're going to see. You don't even know what's out there because you haven't done the research or whatever and you need to be prepared for anything, so you bring just a hodgepodge of stuff. If that's you at the beginning of your company or the beginning of your product and yours is kind of like... I don't know, we got to get product market fit and that means that we may have to kind of pivot once or twice or we need to be very flexible, then I would think long and hard before you commit to writing your own framework because you don't even know what framework to build and you might as well take a broad array of tools and use what you need. There will be times where that's frustrating and there won't be exactly the right tool for the job but 80% of the time, it's going to do just fine but if you know you have to do this one very special thing and you know that a framework is going to give you a lot of stuff that you won't need and it doesn't really excel at the one thing you do need, then don't force the framework. There may be time to build your own but just know that you need to go in with a very clear idea of what you're doing before you start building the abstractions that constitute a framework, rather than just like a constellation of libraries. CHARLES: I have a question on that then. Going back to one of the things we were talking about like React plus Redux. Your opinion, Chris that it is not a framework, so the question is does a framework actually exist for React? CHRIS: My guess is that many frameworks exist for React. CHARLES: Is there a public framework? TARAS: There is one called Fusion but it's [inaudible] what you would have imagine. It is essentially Redux and React together conventionalized. They addressed a bunch of concerns around service rendering and such but it does exist. CHRIS: How about Next? Next.js? TARAS: I'm not familiar with its features from a single page application perspective. CHARLES: I think it does have a router. It does bundle with Redux and this is one of the things that when you first started using Redux, it's like, "How do I even get my store to my components?" Yes, I can connect them but there's actually a lot of stuff that you have to do. First, you have to say, "I'm going to put my reducers here and then when I create my store, I'm going to fold all my reducers. If I've got a whole bunch of reducers in my application, I've got to fold them all together. I've got to pass them off to the store. When I create the store, I have to inject the middleware and then, everybody else just imports my store and then, I have to put in a provider and then, I can connect my components." That's actually a lot of stuff that you have to do and I think that, for example, Fusion just says, "Put your reducers here and we'll take care of all that process," and so it makes that decision for you, right? It says, "For state management, you're going to use Redux. For your reducers, they're going to go here. For your actions, they're going to go here." I don't know exactly how it's laid out but I remember reading the ReadMe, it was basically layering conventions over that. That's definitely going into framework territory but that's the only one that I know of, which is really, really odd. TARAS: There's something interesting that's happening also and this goes to what Brandon was saying earlier is that choosing the best in class, there's this 10 things but then, what if one of the best in class stops being the best in class. The fact that the creators of Redux was essentially saying that we needed to basically provide a way to do Flux that was better than 10 different options that were available, so here's Redux. We've created Redux but we don't really think it's ultimately the solution. We need to have something else in React that provides a foundation for us to be able to deliver a better state management than what Redux is, so what happens when one of the best in class is no longer the best in class? The bridge is already standing. There's people walking across the bridge already. How do you replace one of the chains in it? CHRIS: Over the course of six months while you figure out the differences in API between Flux and Redux and all the custom route transition data loading stuff you did with your Ajax library in your state management software that you put in a case statement inside there that you now have to change over. It's easy. It's no big deal. Don't worry about it. BRANDON: Just a simple matter of programming. TARAS: At least 25 years of collective frontend development experience is laughing like hyenas about the simplicity of building a -- BRANDON: Yeah, I'm actually looking at some of the old code that Chris wrote for trying to glue together, Redux Saga. I've been out of the game long enough to not know whether that's been superseded by some new or best in class piece of technology and even then, it was really challenging. This is true for frameworks too, is they don't really optimize for best in class. They optimize, hopefully for best fit for purpose but the world has moved on since Ember launched obviously. A lot of things have changed and it's, at least as difficult to try to keep that up to date with evolving trends and technologies and updates for a core team at a framework level as it is for you, as an engineer on the team. The difference is you get to outsource that work to a core team for a framework. Ember has not done a fantastic job in keeping up with. They've done a good job and they've tried their best but if there were more people working on it or if there was more effort applied to it or if it was a higher priority, you would see Ember being a more up-to-date framework using more modern tools. As a framework author, if you stay too close to the bleeding edge, all you're going to do is change out your build system. You're going to replace a Broccoli with webpack, with Rollup, whatever's after that. What's new in Packer? CHRIS: Parcel? CHARLES: Parcel. BRANDON: Parcel. You should immediately go build your framework with that and have fun. I am excited by the new and interesting stuff that's happening in these ecosystems and I think it's important not to get lulled into the siren song if your goal is to actually ship a piece of software on a timetable or a budget. TARAS: One thing, if it's a red flag, if you think this is easy, if you think your decisions can be made in this isolation without talking to somebody else and actually kind of flashing it out, then you're probably doing something wrong because a lot of these things are not trivial. There's a lot of thought, there's a lot of considerations used to go into decisions that you make, especially when you're creating something that is going to be used by more than a few people. I think that's really one of those things where it's hard to know what you don't know but if you think you know and you haven't done this before, you haven't done this a few times before, you're probably missing some pieces. BRANDON: Yeah, I agree with that. CHRIS: I think one of the things that's really enticing about React and Taras, you just hit on it but I've never felt as clever as when I was writing a React app. If I'm clever, I mean, clever in the same way that I felt really clever when I wrote some unbelievably convoluted Scala one-liner that six months later, neither me nor anyone else could decipher what it meant but at that time, I felt like a god of programming. That's how it felt like, "Well, a lot of the React stuff is addicting." It felt so much fun. It was so much fun until I really had to do something and it mattered for my job and there was a deadline and people were depending on me and I've realized that the clever thing I had done a month later was not the right clever thing but I can see how, if you're like what Taras was saying, where you are at the point where these decisions are easy. These decisions make sense. We're going to be fine and you haven't done it enough to kind of like know where all of the pitfalls are. That cleverness that you feel is fantastic and I can see why it takes two years before you look back and if the cleverness was finally worn off and then, you're just mortified at what you've done. CHARLES: Pride cometh before the fall. CHRIS: Yeah. BRANDON: It's like being a dungeon master in Dungeons and Dragons, where you're like, "Oh, look at this fiendish world." All right, cool. Now, you actually live there though. I have to move into an apartment on Mordor. TARAS: You know what's the funny flipside to that is that coming from Ember world where it's so normal to leverage the work of other clever people, like really smart people who've invested a lot of time to solve a particular problem, is that there's no stronger sense of being dumb than having to write it from scratch in React. That first feeling of like, "I've actually never had to implement this from scratch," and I feel like a bunch of applications before but because I've leaned on for accessibility, I've leaned on something that someone else has done and it worked really well for me and it was perfect. But now, I need to implement autocomplete from scratch in React and I have no support. I'm basically learning as I'm going on this and it's that sense of discomfort that you get from having to do it from scratch and then, comes the euphoria of having to figure it out. But if you figured it out, you figured it out in the last month. You've written it for the first time in the last month and you now understand what all the things that the Ember implementation does for you. It's an interesting psychology of doing this -- CHARLES: Yeah, it gives you a lot of perspective but you have to ask as a business owner, who may or may not be technical and this is the hardest thing for technical people who are business owners is to be able to not see things through a tactical lens. Is what you really want to pay for is to basically give your programmers this kind of a-ha moment of their own shortcomings because that what you want to be buying. BRANDON: Yeah, you want to maximize leverage. Your goal with technology is to maximize leverage. It's like being hired as a chef and you walk in and then you're like, "I'm a terrific chef. I worked in these fancy kitchens in New York and I'm known as a great chef," and they're like, "Okay, cool. Here's some flint and steel and a spear." CHARLES: Go hunt. BRANDON: You're like, "Wait, what?" Yeah, yeah, yeah. Show me what you can do. TARAS: We had a conversation in one of the previous podcast with Michael Jackson and we asked him, "What is the one thing you wish like React community would do more of?" and he's like, "I really wish React community have more conventions." All of this is to kind of say as like, there is a place for frameworks in React world. There's a very strong place for it. The question is how and what it said and how do you actually build it and when do you --? BRANDON: So we need a framework for making framework. TARAS: Getting really meta here. BRANDON: I totally agree with that and that's a great observation and that was actually the point of my talk as well, which is if I could convince people just to use Ember and improve Ember, that would be great because I think it's a really great starting point. But the React community is much larger because it had such a great adoption story. The adoption of Ember was very difficult and the adoption of React was very easy and it expanded to include the scope of full end to end applications in terms of what people thought the problem spaces they were thinking of with React. Ember was built to solve that but it was hard to get into. React was really easy to get into but it's actually hard to build applications with. I would love to see a dedicated subset of the React community, except the idea of shared solutions and the philosophies that made Ember into sort of a powerhouse of value delivery but built out of tools that satisfy the React community and a little more modular and a little more available for people to customize and built in that ecosystem. I'd really love to see that that included all of the main components of what we accept as, "This is an application framework. It handles testing. It handles accessibility. It handles data loading," and it doesn't have to be best in class in every scenario but it does have to be a reasonable bridge across that chasm and have a group of people look at this the same way. I would love to see a collective subset of the React community dedicate themselves to this idea. I don't know if that's too culturally opposed or even orthogonal to what the value system inside the React community. I haven't been able to fish that out but I would really love to see that emerge. this is something I would love to push for and I'd love to see other people jump in and push for as like, "What if 20 of us got together and decided we're all building our applications in similar ways, instead of one person saying, 'I'm going to use --'" Even create React app is kind of a Band-Aid on that, it isn't useful past a certain stage of life. I would love to see a group of people, though, get together that are sort of like-minded like that, the Michael Jacksons and maybe even Dan Abramov or a group of people that shared that set of values or came into React from the Ember community. That's actually one piece of advice I would give to people. You said, "How do you convince this engineer that they've built a bad framework?" Use a decent one. That's the biggest guide. Use a decent one. Build something in Ember and ship it to production and go, "Oh, I get it." If you've used a good framework, you can't go back to rolling a crappy one. Your standards have been ratcheted up. CHRIS: I wholeheartedly agree that you should try something else and Ember is a great option but I don't want to dismiss just like, "React is cool as hell," and there's a lot of stuff in React that's really, really awesome and things that I wish that will show up in Ember and they are starting to show up in Ember but they're taking a while and it'll be nice in there but who knows when that will be but I would encourage even more so is both sides, like Ember folks who are listening to this podcast, if you have never messed around with React because you feel some kind of tribal affiliation that you can't betray, please set that aside and go do something in React because you will learn a lot about why Ember does what it does and you will see a lot of really interesting things that will probably jostle some ideas loose in your brain. The same thing goes for React developers. You, 100% should spend a weekend building something in Ember and nothing about that means that you have to switch or it's going to change the path that you're going on at work but I guarantee you, you will go back to your React application with some new and fair useful perspective that you didn't have before and that's okay. That's great. There's no identity crisis that will come about as a result of that. CHARLES: That is a fantastic advice, Chris. It will only stretch you. CHRIS: Yeah. BRANDON: I think developers have been sold this idea of a competitive landscape by authors of these frameworks because it helps sell the framework. You can build and strengthen a community by leaning into the tribalism that can surround the usage of a tool. The older I've gotten as a person who was deeply tribalistic about Ruby on Rails when I got into it and Ember when I got into it, because I love tribes, I think tribes are awesome and it's a way to make friends but when you really lean into that, the costs are too high and experimenting with other technologies and noticing flaws in your own technology is not only not a betrayal, it's actually critical to your growth as a developer. The more people that do that, like Chris was saying, the better both of those ecosystems will get. CHARLES: Absolutely because having spent as much time in React as I have, I really appreciate the precious things about Ember. It will make you appreciate the things that you hold dear. It will make you appreciate the really, really, really special things about the tool that you're using and at the same time, it will highlight the weaknesses which you can immediately use to feedback and make your tool better. It really is a win-win situation. TARAS: I just want to do a little plug before we close up. I think the feels of working with Ember is actually gone into microstates and we're still getting our things together to make microstates look accessible and usable by everyone but that feeling of pleasure that you get from working with Ember and just things just being there for you, like we really want to reproduce that and make that available in React community and the stuff that we do in microstates is actually really designed for that. CHRIS: Yeah, I see that in BigTest too as well. That's definitely another place where it's like, "These people definitely used to spend time in Ember and they're now in React-land." It's cool to see that stuff getting ported over. CHARLES: Absolutely because it fundamentally changes your taste. Working with an application that doesn't have like a bolted on testing framework is like eating water soup. You just can't enjoy your life. It really is flavored everything that we do. On that note, we can go ahead and wrap up. There actually is some pretty exciting news. We're actually going to be launching a BigTest launcher. Up until this point, you kind of had to roll your own using BigTest for your assertions but using something like Karma to actually launch the browsers and we're actually launching our own launcher. I guess we've written our own launcher and we're going to be pushing it to NDM, not to overload the word launch. You can look for that in the next couple of weeks. There's going to be a CLI that ships with BigTest to help you do even more set up, to make it so that you can just drop BigTest right into your application, whether it's jQuery, React, Ember, you name it. That should be really, really fun. Be looking for that and with that, if anybody has any other remarks... BRANDON: If people are coming through RubyConf this year, I'll be there talking about management stuff. That's my only near-future conference stuff coming up. Hope to see some of the more Ruby-flavored folks out there. CHARLES: All right-y. Definitely, go to every single talk that Brandon ever gives. You won't regret it. I can base that on very dear personal experience. You won't be disappointed. You know, not to put the pressure on or anything like that but you could never put any more pressure on Brandon than he puts on himself. With that, we will say good bye. Bye Chris, bye Brandon. Thank you so much. This is a great conversation. It certainly clarified a lot in my mind -- TARAS: Yes, same here. CHARLES: -- About these problems. With that, we will say goodbye. Thank you for listening The Frontside Podcast. Please get in touch with us at @TheFrontside on Twitter or contact at Frontside.io on email. We do a range of custom services from full stack project development to JavaScript mentoring, to as you go JavaScript help desks kind of stuff. If you need to reach out to an expert, please get in touch. Our podcast as always is produced by the inimitable, Mandy Moore. Thank you very much and we'll see you all next time.

We are joined by Ives Hoorne, a developer at Catawiki and creator of code sandbox. Today he talks about how he began writing code, how Minecraft modding made him love it, his interest in the company Catawiki and how he taught himself web development to work there, and finally the future for his projects.Ives began coding at 11 years old. He was fascinated by secret languages, so he and his friend made a program in Visual Basic that would jumble text and another that would decipher the text. They would send these to each other as public facebook messages. It fell off after this project for awhile. After a few years, Ives got back into it when Minecraft came around, and he started writing mods for it.The success and popularity of Code Sandbox made Ives happy. He enjoys how it became popular and how some of the bigger names such as Dan Abramov started talking about it. Though Ives discussions about how this positive feedback caused him to attach his self-worth to the project, and how he had to let that go so he wouldn't be hurt by snarky feedback and other forms of negativity related to his project.There were a couple of surprises in the development of Code Sandbox. Code Sandbox stores all files and directories in their Postgres database. When they fork Code Sandbox, they copy all the files, directories, and sandboxes over. Ives thought this wouldn't scale but somehow they now have 400k sandboxes, and the database is only four gigabytes! One of the negative surprises was when there was an error in the sandbox when someone tries to share their sandbox, the preview service would try over and over again to take a snapshot. The following month their hosting bill was a dozen times the price as it usually was!Ives' first experience speaking at a conference was much better than he expected. When he was presenting, he noticed that he was talking with a bunch of people who were willing to listen to him. It was such a cool experience for him that he now loves speaking at conferences for him. Ives says he wants to start talking about things besides Code Sandbox, such as UI driven development for example. He says that it can be greatly improved, npm installing is still manually typing npm install package-name. He says that this can be made much better by being able to search for dependencies and directly add them with a single click.Finally, Ives talks about his plans for Code Sandbox. He plans on adding a dashboard because currently, it's very cumbersome to navigate to your sandbox. The dashboard will give you the ability to put sandboxes in directories organizing them that way. They are also managing offline support. Finally, they are adding team support so multiple people can all work on a sandbox at once.Transcript"Ives Van Hoorne, creator of CodeSandbox" TranscriptResources:Code SandboxcatawikiIves Van Hoorne:GithubWebsiteTwitterJohn Lindquist:TwitterWebsite

We are joined by Brian Vaughn. Brian is on Facebook's Core React Team. He also contributes to a lot of open source products in the javascript space.While Brian went to college to study Graphic Design, he ended up transitioning into programming. During college, he did a lot of graphic design consulting work, as a way to pay his way through school. Eventually, he agreed to create a website for a client and found that programming was a much better fit.Brian built react-virtualized during his time he spent at Treasure Data. The company is really into open source, and many of his team members had projects out there. When they were writing the console, they used Facebook's fixed data table.However, it did not have the features that they wanted. So Brian volunteered and built what would be the first version of react-virtualized.The exposure he got from sharing react-virtualized with the community is what landed him the job on the React Core Team. A developer's success tends to come from sharing the cool thing they built. Share your work everyone!Brian talks about React's goals with 17. Dan Abramov and Dominique have been working on creating an optimizing compiler for react components. The idea is that the compiler can read your components and optimize them. You will be able to keep writing React components in ways that make sense to you, and it will compile them and optimize at runtime. The team is also working on making functional components more powerful, so you do not have to reach out to class methods. It will be interesting to see what will shake out of their work when using async and the compiler.Transcript"Brian Vaughn, React Core Team" TranscriptResources:react-virtualizedPrepackBrian Vaughn:WebsiteTwitterGithubJohn LindquistTwitteregghead.ioGithubWebsite

Joel Hooks co-founder of egghead.io, interviews Dan Abramov, co-author of Redux. They discuss the "Redux phenomenon" and the notion of improving the developer experience.Dan's Redux course has been the most popular course on egghead.io for years. What caused Redux to blow up as it did? Dan is here today to talk about the problems he faced that inspired him to write this framework, and all the experiences he had that led to it.Joel and Dan talk about how quickly functional programming concepts pushed their way into the mainstream. When they were younger object oriented was how you programmed, Gang of Four was like their bible. However, Dan talks about the problems he was facing and how they inspired him to create Redux.Dan's belief that user experience starts with the developer also inspired Redux. The notion that a developer should suffer is silly. Having a tool that is a joy to use and allows a programmer just to create things is invaluable.The frustration of getting started with React was enormous. You had to deal with Webpack and install packages manually and hope that you didn't mess up. All this was hugely daunting for beginners especially. create-react-app was the solution for that. Allowing an easy way to get React going with a dev server and all, it let you just get in there and start building components.Finally, Joel and Dan leave us with a note to those seeking to learn to program well. Read GitHub like it's a blog. Read the commits, the issues, the PR's, all of it. You might not understand what is going on now, but you will build fluency and eventually you'll understand well enough that you can start to answer questions and contribute.Transcript"Dan Abramov, co-author of Redux" TranscriptResourcesGetting Started with ReduxBuilding React Applications with Idiomatic ReduxGang of FourGame Programming PatternsDan AbramovTwitterGithubBlogJoel HooksTwitterWebsite

Toran Billups @toranb | GitHub | Blog Show Notes: 02:23 - Ember 2.0; Data Down, Actions Up 08:28 - redux and State 16:39 - Dispatching Actions/Patterns 24:00 - Components and Routing 31:00 - ember-redux and Cloning the react-redux API 35:22 - Hot Reloading 41:22 - Audience 47:02 - Motivation 50:25 - Building Component Trees Resources: Toran Billups: Test-Driven Development By Example @ EmberConf 2015 Dan Abramov: Live React: Hot Reloading with Time Travel @ react-europe 2015 react-redux Charles Lowell: Immutability is for UI, You and I @ EmberConf 2016 redux-thunk Ryan Toronto: Safety of the herd EmberMap: Component side effects Functional Programming Browserify More Toran Billups Talks Transcript: CHARLES: Hello everybody. Welcome to The Frontside Podcast. This is Episode 55. We're broadcasting and everybody's here in Austin, although we're still remote. I am here with a really special panel today. There's me, which makes it special by default. My name is Charles Lowell. I'm a developer here at The Frontside. I'm also here with Robert De Luca, who also develops JavaScript codes at The Frontside and we have today [drum roll sound] -- I'm really, really going to work that drumroll -- Toran Billups. What's up, man? TORAN: Hey, man. Thanks for having me. I'm really excited to be here. CHARLES: Toran is with us today and he's going to be talking about a lot of things. He's going to be talking about today mostly about Redux and his efforts to meld Redux and make it useful within the Ember community. But first, if you have not heard of Toran, I think the first time we'd interacted over email, Slack briefly but then when I really, really saw you for the first time was at EmberConf, I think in 2015 and he just gave the most amazing talk on Test Driven Development and really kind of the focus on you can set up your acceptance tests from the outside into really define that behavior and set out that firm shell and then actually build your application from the outside in. You've really kind of been talking about that message. We like to have people on here who all about walking the walk. That's certainly the first thing that I've noticed that you were doing in the community but then more recently, you've been playing with Redux. Not playing with Redux, actually making a concerted effort to bring this kind of pattern into Ember. I just wanted to start out, how did you jump onto that track? TORAN: Some months after EmberConf in 2015, as you mentioned that talk was not only, probably the most well-rehearsed talk I've ever given but definitely the most well-received. I got a lot of people excited and really gave me a lot of opportunities that weren't there before that was also believe in that keynote in 2015 as when Ember 2.0 was announced. The interesting part of Ember 2.0, of course was we were using it, and it was called Ember 1.13, which actually made it really great. At the time, I was very much excited about the stability that offered. Other folks were not as much as interested in that idea or those values, in the JavaScript community so it's really exciting. Yet at the same time, there was this new mantra that was being talked about more that I knew nothing about. It was this 'data down, actions up' idea. I still remember as much as the stability was awesome, I also started to doubt not Ember core in particular but the ideas that were being espoused by other folks around the Ember core team because I didn't really understand the value. For instance, if I had the tree of components back then in early Ember 1.13 or 2.0 days and I had an Ember model or some kind of Ember object at the bottom of this tree, why would I not just do Ember.set. I remember, actually you may recall conversations you had with people at EmberConf around that time but there was actually varying definitions of what 'data down, actions up' meant to different people and actually never met the same thing to anyone. It was funny enough. Because of that, it sort of drove this fear in me that I didn't know what I was talking about. I was consulting at the time so I wanted to sound like I knew what I was talking about as you probably should. You guys are in that business so you know what I mean. Because of that doubt, eventually I sort of become apathetic to really trying to understand better what 'data down, actions up' meant or how components should be constructed and really what the wider impacts of Ember 2.0 meant. Because of that, I just found myself, not really loving learning. I felt like everything else in learning was a hyped up thing that would never happen or a hyped up thing that I didn't really understand or didn't make sense in the context of Ember at that time so I just kind of floated by. Everybody has their ebb and flows in the journey of excitement or not. For me, this was just the down moment. One of the things, like an analogy to this is when you lose your hunger in real life, you'd be very much like losing your hunger for learning. There's this interesting hormone that your body produces when you're actually physically hungry that kind of gives you the physical symptoms like your stomach cramps that tells your brain probably should eat somewhere. When those things aren't happening or that hormones not being produced, it's often because you've quit eating yourself. If you've ever gone on a fast or something weird like that on day three, your body quits secreting this hormone so you just sort of or not hungry at all, which is kind of weird. The same sort of thing was happening to me. If you ask a doctor or a physician, "What's the first thing I should do? I'm not hungry anymore." They'll tell you, "You just start eating." But I'm not hungry now so the same thing applied in my life and I think the first step really is just eat anyway. In this case, it was just learn something anyway even if you're not in love with learning right now. Eventually, your body will start producing this hormone, in the hunger example and for me, I just sort of got back in the flow and what came from this was a routine, which is really the second part of how you get your hunger back, not just eating once a day. I was eating three meals a day or more, especially if you haven't been eating. For me, I just set aside an hour a day, in addition to consulting work and things that would get me interested in loving learning again. The third component to this was trying something different. At the time, of course I was just doing Ember, I pretty much had done Ember since 2012 like some of you guys and I feel like there wasn't a lot of new. There was patterns and ideas but there was anything really challenging me. That's when I sort of looked around at the React community and I had done some React in the early days when I was super hyped up but I still feel vaguely different. Not that it's jQuery or any way but I didn't feel like this fully encompass single page out framework. The reasons I got into Ember very early on were that I wanted to build rich single page apps. If you guys remember from the early React days, that also wasn't really the messaging with React and maybe today with View. In fact, that's kind of one of the benefits or they speak to in those communities about why you use React because you don't have to use it for your whole app. You could kind of piecemeal it in, which totally cool. You got to see it out with Ember too. But in my mind, I just wanted to build a rich JavaScript lines that could compete with the iPhone or the iPhone apps that were popular in that day. Through this process, I started looking at React and really just kind of get back into it again, get going again. I wasn't really in love with it but I needed to try something outside of the realm I was used to. As part of that, I noticed there was this talk by Dan Abramov, I think he works for Facebook now, big in the React community, of course and he gave this talk at a conference in Europe that introduced Redux. What's funny, if you find out or dive deeper into that story is he actually pitched the talk, not really having built any of this and just thought, "This sounds like a great idea," and then of course the talk was accepted. Like most, he delivered on that promise and made a great talk. There are definitely courage folks to check out and I should link it to you here. We can show noted that, I'm sure. That talk make me excited mostly because there was a lot of whiz-bang. If you guys remember any great talk you've ever seen, the talk even that I gave at EmberConf that you mentioned, Charles the thing that blew people away was this very end moment that, of course I had produced to be a great moment. In the same way, Dan during this talk introduced some new ideas or new to the JavaScript community. One of those was the tooling that can change when the state doesn't change in your application. That got me sort of piqued my interest, in part because I was actually big test driven guy and I thought, "I won't use any of this stuff. It just seems cool. It's a gimmick. Tester development is how you really build app." If anything I thought to disprove it by getting involved and learning a little bit more but what I instantly found was the simplicity of data changes rerender. That sounds very high level, of course but it was almost just that simple, instead of being like how does this change to an object in my array, bubble out through notifications on the Ember side and notify the Ember change detection to rerender. Well, I'm not entirely sure so when I was start debugging that, I noticed a lot of framework code between me and the rerender. It's that's how Ember is, right? When I boiled that down in jQuery with vanilla Redux, not even using React at all, I was like, "Wow, there's just a call back. I wonder why I haven't been doing this." CHARLES: As a single callback for a global state? TORAN: Correct. CHARLES: So there's no call back for every single path in your tree. You just used that one call back? TORAN: I'll fill in for Rob here. I know he's jumping at it. You should probably define a Redux is. He's really good at asking that question. Redux in this case, for me is just a global JavaScript object to use to hydrate your templates. They'll give you some big spiel about state container, if you go check out the website. But for me and in this context of being on an Ember-centric sort of podcast, we already use this idea in Ember today. If you're just feeding your templates from some high level service, it's a very similar idea in that Redux is just a single service. In the Ember case, especially you can talk about the add-on, I maintain later, but really it's just a service with a single object that will help you populate all of your components. ROBERT: Yeah, I love Redux. I actually sort of coming into the Redux world, probably to about six to eight months ago and it was around the same thing like exploring React stuff. I share similar opinions to you as nobody really can define 'data down, actions up'. I also think that 'data down, actions up' cannot just live in the component. In a lot of the Ember apps I worked on, there's times where I'll be looking up to get a new state and it comes in from the side and something's mutating, something that I have no idea why and where it was mutated and Redux does a really good job at helping you manage what changes and why it changed. CHARLES: I have a question too. When you're actually using Redux, you said you got a single tree that you used to hydrate your templates. In the context of Ember, where do you maintain that single object? I assume you have one store, one instance of your Redux state per application? TORAN: Correct. There's just a service like you imagine in the Ember data service and that holds on to really just an identity map or a single graph object that will let you pass or pull that in by injecting the service into your components if you want to do that or your route then just asking for that state. CHARLES: Because I think that for a lot of people in the Ember community certainly, when I was kind of grappling with these ideas, the idea of having a single global object as your state seems so counterintuitive, so going to go against everything that we learned, that you have to decompose a problem into its component parts. Obviously, Redux has an answer for that so how does that work? How do you decompose that state into saying, "I'm just interested in this kind of local state." How does local state work in Redux? TORAN: I should define local state is state specific to the component. It doesn't need to bleed up and has no value at the global level. CHARLES: Usually, I got two components. Let's say, I want to store both of their states in the Redux store. Obviously, component one is not interested in seeing any state that's not related to it so it's only interested in its own state and it's not interested in any of the surrounding context. How does that work? How do you connect a single component or connect a route to the store? TORAN: There's really just a simple method on Redux -- the Redux store itself, which it says, "Give me the state." What may not sound great at first is that it say, "I will give you all the state and that is your job to pull from that or map three attributes from that whole tree into my component." Then by side effect if you're using our add-on or if you don't React-Redux, you actually subscribe then to call backs on any of those changes so if something were to be bumped, then your component is given the opportunity to rerender during that call back. CHARLES: Now, in terms of Ember-Redux, that kind plumbing is hidden from you. You don't actually have to explicitly map that state. You can say, "I want to connect this component into the Redux store," and you're just off to the races. ROBERT: Is there a mapStateToProps or... I don't know what that would be called in Ember-land. TORAN: That brings about interesting point. I literally copied this API that you guys are probably looked at from the readme from this very popular project in React called React-Redux. The word that you're using, Charles is this word connect. Actually, I like that word because that's how I think about it. I want to connect the components to the single source of truth and then respond by rerendering when something changes. The API is actually very similar on what you said, Rob. In fact, the set of mapStateToProps is just map states to computed, which is very much the same idea so instead of really defining the component like you might normally, this is where it gets a little weird for your classic Ember developer, you actually just write two functions and really only one is require. The first one is what you're hinting at Charles, which is I want to pull from the state a set of properties and as you mentioned, the plumbing is sort of hidden, magically those are actually created as CPs or Computed Properties on your component so you can go to your HPS file, your handlebars template and say, "Oh, I took number from the global state and I'm just going to map it in this function and now I can go to my handlebars template and number," and there it is. Every time you bump number up or down, you'll get a rerun in your callback and the HPS will update. The other function, as sort of glossed over is really just for your closure actions. If you would like to ask the store to do something and saying, "I would actually like to increment the number," then you can fire an action and the second block just does also additional magic, which just maps a closure action by letting you get this dispatched keyword. Dispatch in a Redux context is just, "I'm going to send an action," and you can think of it almost in vanilla JavaScript terms as, "I have an event. Someone will handle this event and I'm just going to throw it up." ROBERT: It makes its way to reducer then from there, right? TORAN: Correct. We haven't talked too much about that process. The reducer really says, "I'm going to be given a state or the initial state, if you haven't done this yet," which would be maybe in the number scenario. I'm going to start with zero as a sensible default and then I'm going to have an action, whether that's add or subtract in this simple example and in add, I'm just going to take the state coming in, even if it starts out at zero and then do something, transform it to a new state. Actually the important word here is that -- I know you guys are big in the functional world, functional programming and that's the word actually got me interested and really excited about programming again as well, in the most perfect sense -- a pure function, which just means that there are no side effects. There's no mutation or changing of the state that comes in when you do it correctly. In this case, actually instead of mutating something I'm actually returning to number two or to number one and you're like, "Now, we have both zero and one in kind of a timeline." If you think about this almost as the realistic stories, we're just kind of kicking a pointer to a new block of state. Every single time you come to reducer, we still have the old state and we can still walk backwards, which is how the time travel debugging works as we just flip the pointer back in time. As you guys have talked about and I think, Charles you mentioned last year in EmberConf, the immutability story has of course a whole slew of great properties that come with it and those we haven't even obviously talked about. But hopefully I gave people a broad overview of what the reducer does. In its most simplest form, state comes and action returns a new state. ROBERT: Yeah, in Charles's talk and his research, I got to sit next to him and watched him do that actually kind of shaped a lot of my thinking and hunger, if we want to keep that going towards doing like something that's immutable and state management in Ember. I would like to thank you, Toran for building that add-on and spearheading Redux because Redux is pretty awesome for state management. CHARLES: By the way, you did in that call out the analogy for hunger. I really, really, really like that. It's an important tidbit not to miss is that when you are feeling those kind of doldrums of development. I know I was actually ironically feeling that about the same time in 2015, feeling of in a funk because I feel like there was a lot of stuff coming down the pipe like with 'data down, actions up' but no good examples of where we've actually seen this in practice. I think Redux is an actual implementation of 'data down, actions up' so I think it's fantastic that you were able to go and seek inspiration there like, "We've got this message of the way things that ought to be doing with the applications ought to be built." But we don't actually have any concrete examples that we can look to. I think the Redux actually is almost the most pure version of that 'data down, actions up'. I guess my next question is given that you've got this global store, you've got a way to connect components. I assume there are other ways to dispatch actions from within your Ember application like what are the patterns that you're seeing emerge around this? We've talked about how you would use them in components. Suppose my tree of components gets pretty complex, how do I manage that to kind of the passing of data down? Do parent components play any role in the data that their subcomponents see? Is each component connecting directly to the store? I'm just kind of curious where that balance lies and how things are kind of playing out? TORAN: There's really two points in your bigger question. One that I was going to try out of you but then you kept going. That was really around side effects. How do you actually dispatch or make changes, requests changes and see the flow and we could talk about that really starts out briefly with a Promise based approach. With Redux, most people don't know but it's basically like asynchronous flow. Dispatch would normally be like asynchronous action where you're sort of blocking and then doing, transform and getting it back. In the simplest ways, you see there is this tool or this add-on, Redux-thunk, which you can use Promises now and async will still work as if it were synchronous essentially by firing dispatch up and letting your reducer do the work. I think that is a great introductory because especially as Ember developers, we've got a lot of experience with Promises so this is just the same thing. In most of the demos I've done and if you check out the read me, there's like a full Yelp Clone example. It's using this approach because it's a little bit more familiar to most folks. CHARLES: Just to clarify what would happen there is you're essentially getting a new state transition when every Promise resolves or rejects. If it's rejects, that's a state transition. If it resolves, that's a state transition. The next Promise that resolves is another state transition. Is that fair to say? TORAN: Assuming you want to alter and use that top level state, of course you could reject or resolve and just not even bother with the top level store. We kind of skipped over some of the benefits and we could just roll back to that briefly. Why would you use top level stores at all? You mentioned earlier and it kind of seems counterintuitive. This is basic global variable. That's what we're talking about. In the Ember example, I think it's actually sort of not weird because if you guys, your Ember data in its earlier form or even today, it really very much is that. We have this one cache of objects related or otherwise and we pass those around. They are a global object or almost like a global variable. The downside of that in my experience has been that is truly mutable and actually everything is driven by mutating those and then having callbacks or denotify property change drive your template updates. That is not the process with Redux, of course. It feels more explicit, where I can actually go look up kind of a tree or look up table of actions and see exactly what's going to happen. Then also to your second half of the question, which is like how was the components wired up? How do they map? I actually uses an interesting pattern which isn't specific to Ember-Redux or Redux, which is to create a seam in my components now where I have truly HTML CSS components. Separating those from the components and know about the data and the closure action story. Forgetting Redux for a moment and all of this actually made my regular Ember much better because I started to produce this component that would connect to a Ember data store, provide closure actions to send up in the most pure 'data down, actions up' sense and then I would connect it using the yield block, which credits to you and other folks at EmberConf that you, Charles kind of talked me into this because I was a espousing this idea but I didn't really understand that I would actually nest within this parent, the HTML component that would just be handed the properties to render. When we do this, again it still is I think a better pattern even if you're not using Redux but when we did it and I when I started with Redux, the only thing that really gets me in hot water is when people see this and they're like, "Oh, so this is the first thing that comes down from the routed controllers template. Then there's always this brief moment of like, "I'm not sure what to say. I don't want to predict the future and I'm not trying to be Mr Routable Components here." But for me, most of my controller templates are just a landing page for the component tree to begin. Again, that's not me trying to hacking the route or anything to say, "I want to use this controller as a routed to component. I think eventually when that RFC lands, this will look different, anyway so I'm not trying to have people do things really outside of the Ember ecosystem or outside of the norm." But from there, I feel like still just landing into a component, allows you this composition which is supposed is the real value of the components structure. They are too primitive to build pages and then eventually full apps. ROBERT: So if we want to drop parallel, it's container versus presentation components, right? TORAN: Yes and that of course, again stolen from, not me probably stolen from someone else in the 70s. But you know, Dan Abramov is accredited to bringing that idea about in React. Actually I like the idea because let's pretend I had done this pattern in 2013. Now, it's using Ember data or simple store or Erik Bryn's Ember model, something like that. Then eventually, the community start shifting to something else. It could be MobX, it could be Redux and whatever the case, I could just very easily swap out those connected components that have no HTML CSS. The data source changes and all the presentation components do not know. They do not change. There is actually an iterable story to refactor through, an update like that normally is kind of a [inaudible]. If you have ever done PHP in the early days or at least my PHP experience in 1999 -- no offense to PHP today -- was that everything was so stuck together or so couple that I could never refactor anything out of it. Of course, you probably do this in a consulting space as I have, where he first thing on a messy project is actually making those scenes in the application anyway to allow you to upgrade incrementally. This process is just more of an upfront thought and I don't think it's really taken hold than it needs to in the Ember community. It's just something I was experimenting with and I'm finding a lot of value because I think the connection of the data source is a different activity than HTML. ROBERT: I think it also holds a lot of value. CHARLES: I think it holds a lot of value. I think there's a dawning awareness of this. In your comment, I actually thought of two blog posts for EmberMap, which I was just reading this morning. One was talking about kind of the safety of the herd and don't worry so much about controllers versus radical components like use your controllers, use your components. Don't worry about it too much. It'll get sorted out. I definitely agree with that. Although, you definitely want to experiment when you're experiencing particular pain around something. But then, the next thing which I think came out yesterday was talking about basically components for managing side effects, which I think is an unfortunate name because I think side effects is a tainted word. But basically, the idea is having presentation components and container components and the container components are responsible for managing the state. I think that idea is valuable in of itself and I hope that it takes root. I think that's something that you're doing, something that we're doing and as people kind of realize it, it does take root, just kind of by virtue of its own value. Let me summarize if I understand it correctly. As part of these job, you've got these container components and their job is, I like the term that you used, creating a seam. Their job in the Redux world is to take a slice of that global state. You have these components whose responsibility is taking a slice of that global state and presenting that global state to HTML CSS aka presentation components that lie underneath them. Is that a fair assessment? Then if that's so, I've got a second part to that. I just want to make sure I'm understanding it correctly. For components that are further downstream on that tree, do you ever switch back to data containers like you switch between data components and presentation components and then back to data components and then to presentation components and kind of back and forth and back and forth on down the tree? Or do you mostly see it as one-kind of container component on top and then presentation components all the way down? TORAN: It's a great question. I think that still needs a fair bit of experience in the Ember community because the patterns I pulled from the source code I read a lot is mostly from the React ecosystem. Because of that, there's a very split view or a different view in that community on routing. We may share some of those views in Ember but I think for the most part, we assume routing actually and that's one of the tricky part to answer your question. This is a broad statement so I'm likely wrong in every context but I don't love to be creating these data components that don't get routed to if I can help it. I'm sure there are situations that have been really complex, places where you just have to make, no route here because I don't want change the URL for instance and I'm just going to make this thing like a routed to component with no URL to get me here. But for the most part, I treat the entry point to this route and when I land on this route at this time, it's appropriate to ask for the data likely coming from the model hook in the route. In fact, all that's still the same. That's also where it's a little weird. If you've ever seen a full component tree in a React app, they may not have a router at all. In that situation I think, Redux was in particular even better because you don't have to pass from the top app component, the same props or the same data all the way down that tree. In fact, if you read documentation about why Redux in the React ecosystem they'll say, "It gives you this place where we can create a little shim and then ask for the data down here in the [inaudible] mode. You don't have to pass it from the app to that, to that." I see those benefits but in Ember we don't really get as much from that. In fact, they still tell people who challenged the global state idea that not everything maybe should be a global state but you give up some things by doing that. The first one I would say, which I think is the most valuable for anyone doing vanilla Ember with Ember data or someone experimenting with React or Redux. Or the case I'm most interested in, the audience I'm after which is Redux in Ember, which is do you actually need to have that state in one place. The prime example of this that is the greatest use case is master detail. What I mean by that is you have a list of things and when someone drills into one of those, you can also see that at the same time. There's really two choices you can make here. One is I'm going to have two separate data sources to feed two separate components so the list will go get its data and then the detail won't even use that data at all. Just go get its own data. In that case, you may up against a problem where you need to synchronize at some point and here's the tradeoff. Either synchronize the two separate states or you have a single source of truth. That's a real benefit I think of Redux for the most part. It's like the broad, "Do I want deterministic rendering?" We've all heard the joke about the Facebook nav bar that's like, "You have one message," and you're like, "No, I just answered it down here." Well, that's a different component so the joke is like, "Oh, Redux must be working. We have one up here but I've already read the message." You know? Someone obviously is in charge of synchronizing in those sort of examples. Maybe not just doing it well or they run up against an issue synchronizing that. My experience doing back end development, colors this for me. What I rather have three databases and they kind of synchronize the state across them or I rather have the one postgres or SQL server database that is the source of truth so that when I render something to a customer, I can guarantee that it's not in a transition to be synchronized. It is the source of truth. CHARLES: Right, I really like that and I think the point that I take from that is that, and again this speaks to people who might be internally reacting to this idea of a global state is that you actually do have a global state always in your UI, whether you acknowledge it or not. It's composed of all the other distributed states that are sprinkled around your application so if you take an approach like Redux, you're kind of acknowledging that upfront that at any given time, I do in fact have a global state. I might as well deal with that explicitly. That's kind of a key innovation. I also like what you said too about kind of treating the router in Ember really leaning on the router as a good way to partition your data or drill down into a sub-piece of that global state. Inside Ember-Redux, are there explicit hooks for dealing with the Redux store inside your routes? TORAN: Yeah, that's that one that gets me the most trouble. When I see a blog post and memes that are all about the herd lately, can't help but feel like they're pointed directly at me because of some of these new ideas. CHARLES: Toran, I'm just telling you. This is a safe space. We believe in innovation here. You're okay. TORAN: Yeah. CHARLES: Let me add-on that. I didn't mean that as a knock to you. I do think they call this out of the end of the blog post. I think acting in concert with the community for the most part, actually fosters innovations and an innovative journeys like the one on which you're currently embarked because you don't have to worry about CLI tools and you don't have to worry about this. You can focus on the problem of like how does an Ember application work with a global atom as its state. TORAN: That is the idea. I mean the route is interesting. I have a little helper to your point, Charles if you've seen some of the docs or any of the examples. There is a little helper for routes and all it really does is provide dispatch as an argument. For instance, a lot of times I just want a model to be a regular function and dispatch to be an argument so I can return a Promise or do some Generator stuff as a side effect. In that way, I sort of create a shorthand which is just really simple. It allows me to say [inaudible] model and then have dispatch as an argument and run my code then just providing that to this special little helper. It's a functional type helper called route and what it does behind the scenes is it injects the Redux service for me, which is again something you can do by hand. If you really just don't like that or you want to be more in the herd, you can just have a regular route, inject the service and then get dispatched from that service and use it. ROBERT: It looks like you just dropped the version 2.0, like three hours ago. I would like to ask, we heard about your journey like you were feeling like you weren't hungry for learning. I want to know more about where you actually sat down and wanted to write this add-on on and why you chose to clone the React-Redux API and what took you on that path? TORAN: Yeah, that's a good question. Back to benefits or the reasons I got excited about, of course I mentioned during the talk that Dan Abramov did. There was some interesting dev tools. First of which was this thing Time Travel Debugging which it allows you to sort of move backwards in time and pretend as if actions and mutations or what looked like mutations that never occurred. That was very interesting. I wasn't really sure of the value, especially at the time. I told you guys around 2015, I was consulting which lucky me, I was doing Greenfield. Thankfully, I was working with a really great team and some great people, built an amazing product. I don't really understand the pain of this. For the most part Ember-set was doing its job and I didn't really have a lot of interest in learning this. But as I got more into it, also started a full time job last year, I pretty much just fix bugs for a year. Anyone who's been on one side of the fence or the other knows that the bug fixing side will sort of expose, maybe the weaknesses of the application or patterns or choices made. For me, that was really mutation or shared mutable stake aka the root of all evil. If you've ever looked at your Elm ClojureScript, Elm next is the same vein where immutability is very much there. Charles, of course gave his talk on immutability and trying to get people interested in that or more interested in the Ember community. That was really all I wanted to do to your point, Rob was provide really an outlet for people to use this and I wanted to keep the messaging away from the things I didn't like, which I think was actually something I screwed up to be fair early on. I think I was very vocal in the microcosm that I would talk to people about like, "These are the things I don't like about Ember," or I would use the word 'Ember the good parts' plus 'Ember the bad parts' and I was told not to say that anymore on the Slack channel. Once I started getting too much needed feedback -- I don't want to be negative about it -- I changed my messaging and as part of that, you mentioned Rob I basically cargo-culted or copied this API from React-Redux called connect and excluding the brief route helper that I mentioned, Charles a minute ago, the real idea here is you just call disconnect function with two other functions: mapping state and closure actions. Everything else becomes then vanilla JavaScript in this reducer function we talked about briefly where I have state coming in and I need to transform it into a new state. One interesting benefit of that -- I wasn't overly critical about until I really saw the difference is that -- I'm no longer using the Ember object. I'm not doing Ember.get and set, which immediately start to open the door some time last year for TypeScripts interest. I'm actually not a super type friendly person. I sort of left Objective C and C# and Java in my background and have like this Vietnam experience when people ask me about types. But I do understand one very critical fact that I can't dispute about types is that there are more information for the next programmer than you have without them. Again, my experience this last 12 months has been, as a maintenance programmer, I need more information. Tests are great when they're there but they also don't provide the interface or all the information about those and certainly the compiler may help as well. I don't know yet. I'm not doing any TypeScript. What I started notice is also more functional programming and maybe just not in our core yet but also things I wanted to steal from other ecosystems because I also found is very interesting. I started to study functional programming. I know like nothing about it, of course. I don't think anyone does because I can't describe a monad without getting in trouble or being wrong. For me, the real value is the separation of the data structure and the function. I'm preaching to the choir here but that was so much like an interesting idea to me and actually spurred on some of the further patterns or adoption of those in my work in Ember-Redux because this presentation and container component idea was really that I was separating the data structure from the function of the view. I think you mentioned this in your talk at EmberConf where the actual HTMLbars template is really just a function that has data in, HTML out. I started to internalize that and think about that and what were the properties I got from that, as well as I enjoyed functional programming. Some other great benefits that we've already touched on briefly are just how much more of this I felt explicit, not that Ember-set is inherently implicit but when you do a Ember-set for mutation to chase down every single place in a complex system to determine why they something render this way? It does feel a little more implicit than something like React-Redux with this connect function where I was like, "Wow," when I was doing React. Especially, I was like, "I bet I could just put a breakpoint at every connection so when that callback happens, I can know exactly what action spurred on this new callback to rerender," and that was something that was very new and interesting. Then of course, falling out of all this was another hyped tooling thing that I thought was really cool, not explicit to Redux, again but it got me interested because that's hot reloading. All hot reloading of CSS and Ember CLI, which I've never done design work which I'm not good at. But I do write some CSS or hack-on it when friends show me what to write. Then writing HTML was a separate experience. Once you wrote the CSS, you would hot reload in that course, what do you do every time you change CSS, you also change HTML, which would incur a full-page reload with a live reload tool, if you're familiar with that in Ember CLI. This tooling allowed the Redux store itself because it's stored the state, allow me to really throw the component away in the page without refreshing it and then providing a new one and just go rerender because the state was instantly mapped in and then rerendered. I actually did a demo sometime last year and like, "I'm going to build a star rating component and here it is with live reload. Here it is with hot reload. I'm not going to make a decision about which one is better. You decide," and overwhelmingly people were like, "This is a much nicer feedback loop to make HTML and CSS changes in real time." ROBERT: Agreed. Let's pedal back the hot module reloading because that is pure awesomeness. But that has a little bit of setup they have to do and changing your application. I remember we were talking about this. When you did that demo, I remember this. But there's a little bit they have to do to make your components stateless. They have to come down from the Redux store. TORAN: Correct and this actually still applies if you are, I think using Ember data as well, as you just can't pull the state to reload it anything local, which may go against what you're trying to do with your component. ROBERT: Right. That's cool but I do want to highlight a little bit something that was cool about the Redux dev tools as with all the state that you have since it's in a centrally managed place, you can take your state and then play it back over the top of something like if it did live reload and it'll just pop you right back down to where you were when you were debugging. When that page refresh happens, if you're not doing hot module reloading, you still won't lose all your state which is really cool. You just play it right back down on top and you're exactly where you were before. It's almost like you would throw a specific test that puts you into that state that you're trying to debug. TORAN: Yes, it's like git rebase. It lets me pull off my state, replay the new component function and then drop my changes on top of it and see it all viewed together. ROBERT: Yeah, I think that's massively powerful. CHARLES: Yeah, it is fantastic and that's where you get into that power. I can get on my immutability soapbox. But it turns out that as programmers, we deal in information and not throwing information away, not just flushing it down the toilet is hugely powerful. I think the thing that's so fantastic is that Redux takes this concept and then all of the tools to leverage it are there for you. I think that it is something that is missing from the Ember development story and people don't realize that it's missing, that we have all these wonderful tools, we have this conventional way of building our applications, of deploying our applications, of rendering our applications, of marshalling the data in our applications in the form of routes. But what we're lacking is this unified atomically based state management solution. I think that, Toran it's been fantastic that you have pioneered this and trying to bring what I see as a glaring gap in the developer experience to the community. I'm curious then to ask you what do you see as the future. You know, 2.0 just dropped and there's this need. I feel very strongly that Ember 3.0, 4.0 or Ember 'dot future' at some point should have a unified state management solution. How do you see the road that you're on intersecting with that future if it does in fact exist? ROBERT: Also how can I help or how can we help? TORAN: Just real brief before I dive into some of those questions. I just want to mention that 2.0, as awesome as that sounds, of course I dropped that this morning just so we could say that on podcast, really. We've had a beta in the works for Ember. The only change really, if you're like, "I just got into an Ember-Redux last week. Is it all garbage?" No, this isn't Ryan Florence 2.0 -- it was a joke for any [inaudible] router folks in here. Actually, just us removing Browserify because if you are familiar with Browserify in the Ember ecosystem, talk to Robert Jackson or Stef Penner, folks familiar with that in Broccoli, they'll tell you that one of the harder things to optimize and although, it created a great entry point to how do I use Redux? Boom! Ember Browserify, install Redux, I'm done. If you've ever seen an [inaudible] in Ember that has 'npm:', you're using Ember Browserify to pull in, either a common JS module or some kind of node module and use that in the Ember ecosystem without an additional shim. Now, what we found or learned was that bigger teams that are using this, paid a little bit of a cost and not just cold rebuilds. I'm talking hot rebuilds because Browserify just isn't friendly to get those to be optimized, I guess is the word, so we removed it completely or just use some smaller simpler shims. You actually get the performance improvements hopefully -- ROBERT: That is awesome. TORAN: -- Which is big win. Back to your question, Charles. The audience that's intended, of course is a little different than most people like me to talk about. In fact, the API itself, I think was a bit rejected. You're sort of asking like, "What does this mean in the future?" I don't really feel that the traditional Ember audience has picked up around with it because of something that's missing. You said the 'C word' earlier so convention is certainly still missing from this and even in the React ecosystem, they're just barely thinking about, "Look at all this great stuff we can do with one-way data flow and immutability and functional programming," but guess what we're giving up. No one's really come around with this perfect pattern and conventionalized it as Ember did in its early days so there's a lot of churn, I wouldn't say overly so much that you're not going to getting work done but more than the average Ember developer is aware of. My audience is actually not the average Ember developer, which may be bad for what you're asking about, Charles. Instead, it's actually the person who maybe has done React and maybe Redux or Backbone in the last two years. They love some of those patterns. They're not in love with the Ember-object because of getting set. Maybe they love TypeScript and they say, "I want to use this in Ember." They joined a new company that's a little larger than the startup they'd been on the last two years and they are using Ember. They love a lot of Ember but they would also like to use some of the predictable state patterns that you get with Redux. As well as maybe the dev tooling, things like that so they have adopted this. I feel like that really is the new audience that I aim to please or I'm falling in line with, which is a little bit outside. I feel like there's room for some fragmentation and a good beat up on me for that because when the realities of this herd conversation that we're kind of talking around a little bit is that the herd is great until something innovative needs to happen. Innovation, obviously takes some risk and I feel like that's sort of what I did last year and said, "Here's some interesting ideas. I have not shipped Facebook with it yet so let's just check this out." Of course, Ember add-ons are a great way to enable someone to try a new idea. But I think most people got into it, saw this funky connect thing and they're like, "What the heck is this?" It's a function and returns a component. All right, that's not doing that so most people bailed out. But I do hope people still and I know great folks at LinkedIn, Chris [inaudible], of course. We chat occasionally. Mostly he just tells me what I'm doing wrong. Shout out for Chris. But he knows a lot more about some of the stuff than I do and I think he is fully aware of the values that are in Redux that are great and then working hard, of course during his full time gig to apply these to Ember data and hopefully these do make their way in naturally. I just wanted to be a bit more radical. I don't want to wait around and I wasn't really involved in the Ember data project. My own fault there but I think if nothing else, the ideas will come out of it because the developers want this. Whether you're the audience I'm talking about, which is a React developer from two years ago, you're in Ember, you're eventually going to really understand and want this and then those 'data down, action up' ideas that were pretty unclear to me in 2015, will be very clear. In fact, if anyone seen or heard of this Project MobX, which is like an alternative in a way, popularity-wise to React ecosystem. It kind of looks like Ember in a way where you get sort of some more magic and what I found quickly in playing around MobX is that you can very much fall into the shared mutable state problems. The interesting part about MobX is you can opt into a strict 'data down, actions up' approach. But if you don't have the Ember battle scars like we do, you're just going to come in and say, "What's less work?" Just like in Ember when I can do a set in the [inaudible] node, why would I do 'data down, actions up' and that's the transition I want to see folks make. Hopefully they learn something from that. CHARLES: Right, I agree with you. Although, I think the time has definitely come, I think the term 'herd-mentality' is an unfortunate one. I prefer to think of it as like a pack. If you travel as a pack, you can bring down moose that are bigger than you are individually. But every once in a while, like a gigantic moose with laser horns shows up and then what are you going to do? If you're hunting as a pack, you have to introduce new things because I like that analogy a little bit better than a herd because the job of the herd is just to not get eaten, where is the pack has this idea of these entities that have to stick together. They're hunting and they're tackling different problems as they come but sharing in the benefits. But I think that there has to be room for innovation inside that herd/pack-mentality, whatever you choose. I do think this idea needs to be introduced so what I would say is that if you're listening to this podcast, you should actually go and you should try and use Toran's add-on and you should try and build something with it so that if you have opinions about how it should fit into Ember, then we can hear them. It sounds like you're taking a minimalist approach, you're emulating patterns that are proven to work in the React community so kind of enabling that seed cross-pollination right there. I would say go build something with it, experience what it's like to have your state as a single atom, experience what it's like to have incredible development tools that come along with that. I think that if you're in the Ember community today, you need to go build something with React, you need to go build something with Redux and you actually have made it one step easier to do. You don't even have to leave Ember to do that. You can build something of node with production quality code using Redux and you can experience what it's like. That's my challenge, I think to the Ember community. Go try it, go experience it because you'll come back, I think like I did. You'll come back with superpowers just from having tried that. ROBERT: Managing state becomes so easy. TORAN: Yes. I want to jump in briefly and just cover one point that we haven't talked about that's very controversial so why not drop it at the end here. I think, Rob you might have asked about it earlier and I just didn't feel brave enough to talk about it at that time. But you guys keep going back to this idea and I have to talk about a little bit too. One of the motivations is I live in Iowa. I work in Texas. Thankfully, this great company, Q2 employs me and I don't know why I'm being paid. I'm lucky to be writing JavaScript for money, probably we all are. But in the Ember local community that I'm in, a very little folks writing Ember and that was even years ago. I was like the only voice in the middle of the Midwest screaming and then folks in Minnesota would tell me that wasn't true so I went up there and did a conference as well. But for the most part, I looked around the job market too and thought, "It be really great if I understand some of the more JavaScript-centric parts of building web apps today," and when I looked at Redux functional programming, the way the reducer worked and structured, the way to React-Redux project was structured and thought, "I bet I could emulate that an Ember," such that I could actually and I believe this is to be true, that if you were in a React-Redux project or even an Angular like ‘ngRedux', which is a very similar connect binding, you could copy a whole directory of your reducer code, which is all vanilla JavaScript. If you're doing generators, which we didn't talk about but if you're doing you know any additional side effects, you copy all that vanilla JavaScript, drop it into your Ember app and it all works because it doesn't matter if it's in React or Ember or even Angular, even View if View has some connect API like this. We all share this common API that is just give me the functions that enumerate over the data and return new states of the data and call back to rerender. There's something really powerful about that but the tradeoff being there are not a lot of strong conventions, Charles that I have adopted. That's kind of what I'm cautioning here a little bit is that I'm still also just watching the other communities to see what eventually turns out not. This is going to be am Ember add-on and I don't care what everyone else is doing. This is my vision because really my vision was to make a drop in for anyone already doing Redux on any platform. CHARLES: You know, to the point, there's a pack that extends beyond the Ember community and it sounds like you're also leveraging and being a part of that. TORAN: There's an interesting idea about the hunger thing, which just tied us in and there's where the fourth thing that a doctor will tell you to get your hunger back is go experience eating with other people. There's actually a statistic that when you sit down to eat with someone else or many people, you're likely going to eat 44% more food than you did on your own. That's just, I guess a statistic that's true. I just made it up for this podcast. No, I think it's true. If that is the case, then I think that very much translates to programming as well where when I'm developing code with other folks and I'm on like the React channel and we're just talking about vanilla JavaScript, it doesn't have to be me being an Ember developer anymore, which has been a large part of what's blocked me from being, I think an asset in my local community in the broader JavaScript community. At large is every time I get a conversation it's like, "I have to do it the Ember way," and that's changing actually. The Ember has credit a lot of deprecation if you guys have seen or follow the RCs and other just Ember upgrade deprecation. We're kind of getting away from being Ember and writing just more JavaScript and even maybe sometime this year beginning ES6 classes, instead of Ember object extend. I think Ember is heading in that direction. I just went there, rather rapidly because I also was again experiencing vanilla JavaScript with other communities, View and React. ROBERT: I think we're walking on this very similar path. I'm following your footsteps right now, it sounds like. TORAN: My last point which was that third bullet about building component trees, it didn't sound like either of you guys really contest that and I'm friends with, obviously Chris Freeman, formerly The Frontside and Chris tells me, "You're trying to build full component trees once you're injected at the route level and you're not doing like a ton of HTML in your controller HPS files." Is that true? CHARLES: We treat our controller basically as a component. Sometimes, we'll be like, "This is the controller and if we ever use it in more than one place, we'll take out its component." We're not super dogmatic but we definitely see the clear separation of the route is for maintaining the data and everything else is just one tree of components just below that. ROBERT: The more I think about it though, I'm so conflicted because I really like routes in Ember and they do a lot for you. I like having the data be maintained in one spot but I don't know a single store with Redux maintaining that and using like Redux-thunk or Redux-saga. I got some exploring to do. CHARLES: I don't think those are mutually exclusive propositions. That's what you were saying at the beginning, right Toran? You still do all of your data munching in the route. There's two kind of subjects that I wanted to broach briefly, although I don't think brief is possible with them is actions, like how we talked about data down, we talked about where you draw the seams in your application, where you're loading your data, where you're mapping it to your components and having that separation into your presentation components. We didn't get to talk about reducers so much and how you map. You touched on it like the mechanics but suppose I have a to-do list and I want to delete an item and I've got some button to delete an item, that's down my component tree. How do I map that action back up to the store? I don't know if we actually have time to cover that because it is meaty-meaty subject. ROBERT: Redux part two? TORAN: Yeah, we have to follow up because really that is a little bit more of an advanced segment not that folks shouldn't hear about it. But one thing that's a radical shift, Charles that we would have to go into and talk about, which is controversial as well as most folks want to operate in one structure, one dictionary not in the array. Then immediately, everything flips to being a Lodash operation. I didn't really use Lodash at all until I got into this. You guys probably actually are smart folks to do. But for me, this store is not in array now. When I'm doing array operations like remove or filter, I'm actually operating with Lodash on an object to produce those new states and most of it is just learning the Lodash operators because I didn't actually know them so the Yelp Clone that I have out there is a very simplistic look at using Lodash with Ember. But it accomplishes some of that. Then also, the secondary piece that would also consume a ton of time that we should go into but maybe not today is switching from Thunk to Generators with Saga and then maybe even observables with RxJS, which seems like possibly the future. Those all sounds cool but I think they're going to blow the heck out of scope on this thing. CHARLES: All right. Well, thank you so much for coming by Toran. As always, our conversations are too big to fit into a single podcast. I really want to have you on again. There are so many things that we haven't even touched on. We haven't touched on the subtleties of how action dispatching works. We haven't touched on using Ember-data -- I'm just [inaudible] out there and say it. With Redux, we haven't open that can of worms and who doesn't want to just sift through a can of worms on a podcast? We are going to have you on again. I am positive of that. ROBERT: We're going to paint that bike shed. CHARLES: Yeah, we're going to paint that bike shed. It's a bike shed that needs to be painted. It's something that the community, I think needs to face head on. Thank you so much for coming by and talking with us about Ember-Redux. Everybody, go and check it out. Toran, you've got some talks coming up, if you want to mention those real quick. TORAN: Yeah, I just wanted to plug. There's possibly going to be a talk, we're still lining up the official date with the Washington DC Ember Meetup sometime in April. I planning out to fly out there actually and give this talk on Ember-Redux. I want to thank just publicly the RSA team for kind of helping sponsor me to fly out and check it out. As well as give a more in-depth talk on Ember-Redux in the Meetup setting. CHARLES: Fantastic. If you're in the area, be sure to go check that out. If not, watch it on video and then unrelated Ember-Redux, if you haven't watched Toran's EmberConf talk on Outside-In development. TORAN: That's out actually global Ember Meetup, I think. CHARLES: Okay, that one. Actually, just go watch all Toran's talks. The thing that I didn't mention at the beginning of the podcast is that you do a lot of live coding, which is just makes my bowels freeze when I think about doing it. You just pull it off so effortlessly so it's definitely, definitely worth a watch. With that we, will take it out. We'll see you guys later. That's it from The Frontside. Remember to get in touch with us at Frontside.io. If you're interested in UI, that's engineered to make UX dreams come true.