Aiden: developers they don't care about performance. If it's free performance, I'll take it, right? Like, or like very cheap performance. But once it's like very hard then I don't wanna switch, right?
I want to explore building really, really developer friendly tools like milloin that either automatically optimize it or some sort of like very DX focused, uh, things that allow you to get free performance.
Andrew: Hey, before we get started with this week's episode, we'd like to announce that we've started a newsletter. If you head over to mail.devtools.fm. Justin will be running the newsletter and he'll be curating, a set of interesting. links about dev tools news that happened throughout the week.
Each newsletter will also contain a breakdown of the episode that we released that week with some of our post show thoughts as well. So, if you're interested, we'd love for you to join us.
hello, welcome to the Dev tools FM podcast. This is a podcast about developer tools and the people who make 'em. I'm Andrew, and this is my co-host Justin.
Justin: Hey everyone. Uh, we're really excited to have Aiden by with us today. Uh, Aiden has, uh, created a library called Million Js, uh, which makes React render faster. Uh, we're really, really excited to talk about that more today. But before we dig in, Aiden, would you like to tell our listeners a little bit more about yourself?
[00:01:17] Aiden's Background
Aiden: Yeah. Hey, thanks for having me on. Um, as, as Justin and Andrew introduced, I work at Million Js, which is a, um, a virtual DOM replacement for React. That makes it much faster. I'm currently 18. I live in Portland, Oregon, but I'm heading up to University of Washington in the. In like a week. So excited for that.
Andrew: Yeah, I think you win the award for the youngest person ever on DevTools fm. So congratulations for that. Uh, what made you like get into React and web development and led you towards Million js?
Aiden: I started coding in fifth grade. Um, not because I wanted to start coding, it was because I like playing cool math games, um, on my school computer. And, you know, like I was like, I was hard grinding like papa's pizzeria, and so I was like obsessed with that game. But when my school district blocked, like games, like flash games on their, uh, computers, I was devastated.
I was like, there's some way to bypass this, right? Turns out there is, um, the, the thing about, um, The, the, the blocking system was it, it only looked at like the u r L on your website, and so I could have like an I frame embedded on like my own website and then it would literally, I would be able to play cool math games on there.
And so from there I just kind of dove into web development. I mean, I learned H T M L. I know people say that's not a programming language, but it is a programming language. Um, and kind of delve in from there.
Justin: I'm, I'm curious. Uh, so I remember when I started trying to learn programming, I, I didn't start with web development. I, I tried to learn C and C++ plus plus virtual, which is a mistake, uh, for me anyway. I didn't have a lot of great resources. But How was the learning path for you? Do, did you, I. Did you find it that you had like plenty of resources and getting started, there was like enough material or was it still kind of sparse and sort of hard to get started with?
Aiden: definitely better than like, maybe like 20 years ago, but, um, I, I feel like I have a very weird learning path or non-traditional. I think what most developers do is they either go through like a bootcamp where they go through school or they learn. Or at least in bootcamps, you, you know, you learn react, you learn tools, or in school you learn the fundamentals first.
Where people like are just interested in getting like an O'Reilly, C plus plus book and they learn, um, like game dev or something. Um, but I kind of learned everything backwards when I was talking to other pro programmers. They were using Git and I didn't even know how to commit and get, but I knew how to make a, you know, a website or library using JavaScript.
Um, And so that was a definitely weird experience for me. I felt like I was learning everything backwards.
[00:03:53] Getting into Frameworks
Andrew: yeah, I, I find it really cool that like your first delve into programming was hacking around your, your school's firewall with iframes excellent use of iframes. I don't know about other uses of iframes, but that's definitely a good one. Um, so what led, what led you to react? Uh, did you, uh, try out other frameworks?
Uh, how, how'd you end up there?
Aiden: I was like big on not using frameworks, um, because I thought they were too complicated, and so I. I, I got into vue by building my own vue. So I like built vue and then I learned how to use vue like correctly. Um, and so I just kind of like played around there. Um, uh, and then one day I, I found out about this thing called the virtual dom and I was like super hooked on it.
Um, so from there I literally rebuilt React, kind of learn, react. And from there just now, now I do react dev. Um, I, I found it interesting because it was really hard to wrap my head around the complexities of React, and the only way for me to really understand it was to kind of rebuild it myself.
Andrew: I find that true with a lot of coding things. You really have to get like down and into the code to really understand. Uh, so you said you were excited by the virtual dom. I don't think many people, uh, probably think that to themselves often. Uh, how did you, how did you get to that excitement? Were you finding like performance pitfalls in your, your home bake framework, or did you just like the idea of, of what it entails?
Aiden: Yeah, for sure. I, I was using like inter H T M L calls and if you know anything about that, like doing big H T M L changes is like a terrible idea. And so that's where I, like I was looking at virtual dom and that was like a thing where I could actually. I mean, number one, I could take huge swaths of H T M L and diff it against something and have it perform okay.
and also it was just a really interesting concept, learning about like how to traverse a tree, um, how to build a tree, how to, you know, do efficient ding and that, uh, things of the sort.
Justin: Yeah, it is a pretty fun concept. I remember I, I came, I think I came to react mostly from jQuery, so it was like similar sort of thing, but different, right. You know, you're like editing a bunch of dom noes and then you're like, okay, how do we do this faster? Uh, This kind of gets us into, uh, thinking about millions.
So, so you'd sort of rebuilt your own version of React to sort of learn the internals and, and started using React, and were excited about the virtual dom. Uh, what started making you think, Hmm, this isn't exactly very performant. Uh, or, or there could be more optimizations to how this happens.
Aiden: Yeah, I've always been pretty frustrated about how websites are built today. Um, I grew up a computer and so I, and then the first computer I got was like, Insanely, like it couldn't load Wikipedia in, you know, in a good time. And so I've always been on the, the side of the, of computing where it's like everything is really slow, everything, you know, doesn't, it's not state of the art.
My grandma even owns a 2015 iPad. Whenever I send her a TikTok, it doesn't load. And so I've always been frustrated with like, the way we build websites now. I mean, um, most developers have like an M 1 MacBook and that's great for them, but obviously, you know, for. Users like me and a lot of users around the world, it kind of sucks.
And so I was like, okay, what if we built a better virtual dom? Like what if we could make react, but also make it many, many times faster? Um, and the way I approached this was I, I already saw a lot of frameworks that try to replace React and also tute at performance. Like svelte, right? Like everyone knows svelte, it's like way faster and also it's easier to use.
Um, But I think the way I didn't, I didn't, I liked how it's svelte was introduced a new concept, but I don't think it could make meaningful change without, um, trying to get the current, like React ecosystem to adopt something faster. Right? And so my approach with Million was, okay, what if we can make something really, really fast, but also allow current React users to use it?
And so transitioning, you know, the status quo to something faster.
Andrew:
[00:07:59] Ad
Andrew: We'd like to thank Raycast for sponsoring the podcast. Raycast is an app for Mac that's like spotlight. But actually useful. Besides just quickly opening files, URL, or any app on your computer. It provides cool features like clipboard history, window management. You can even view your calendar. One of the real cool things about it though, is its extension API. It's built on react and creating extensions that feel like native controls is super easy. And then they have a store where you can distribute your extensions to all your friends.
Raycast is pack was so many cool little features that you'll just discover over time as you use it. One that may not be the most workflow changing feature, but it's still a good one. Is the emoji picker. I have never been able to remember the keyboard shortcut to bring up the apple system native one. I always seem to get it when I don't want to. The Ray cast one is built so much better. It remembers my top emojis. And it filters them super easily fitting into any of my workflows.
You should also check out. Raycast pro. With pro you can take advantage of Raycast, AI and Raycast AI can do a whole bunch of things. You can use it to translate text on any page summarize pages or like use it for what I do is when I'm developing things. I use it as a coding buddy to help introduce me to new concepts. I typically visit a Raycast window before I visit Google now.
To learn more about Raycast. Is it Raycast.com or head over to episode 38, where we talked to the CEO Thomas about the product and why they built it.
Do you want to advertise with dev tools fm head over to dev tools fm slash sponsor and you can advertise on dev tools fm just like this
Want to skip the ads and get straight to the content. Become a paid subscriber on other platforms we support. We'd love to have you.
so what, what, what are these performance, uh, improvements? Uh, you said that the virtual dom could be faster. How, how did you make it faster?
Aiden: Right. Um, the, the, the main thing I really focused on was reconciliation. Um, not because it's the most important necessarily, it's just something that was really accessible, uh, for me to build. Um, the way it does it is through something called a block virtual dom. so for context, A virtual dom is something that allows like a framework like react to update the dom or like to update UI.
And so every time you make a component update like a state change, that state change can be translated to real user interface changes. Um, the issue with the virtual dom is it has to do something called a treat like a diff right? And so, Uh, a diff essentially comparing two trees of different ui. So like you just imagine like a, you have your dominoes in a tree and you compare two different, like, states of it.
Like maybe like one has the old content, one has the new content, and that's okay. But once your tree gets really big, it kind of sucks. Like, imagine your app being o of N where n is a number of nodes in the tree. The blocker dom takes a different approach. Instead of treating the tree as something to diff against it, treat treats the tree as like a template or like a, like a blueprint.
And so it can figure out where the dynamic part to the tree are. Like in your component, you don't have everything as dynamic stuff, right? It's there can, you can have like a static diviv and a static id. Um, but. What happens when there is end dynamic stuff? And so the block virtual DOM figures out where all the dynamic stuff are skips the static content.
And so it's like a direct update from your state to UI.
Justin: Right. So where traditional, uh, react would like diff every node, regardless, it's just gonna go through and diff everything you've added an optimization to skip some nodes in this process and just like go directly to. You've changed this. This is dynamic and I'll, I'll directly update that. The node that's associated with that,
Aiden: E. Exactly.
Andrew: so how, like, how, how has this process been like trying to swap out the virtual dom implementation for React? That seems like there's gonna be lots of pitfalls and lots of things that are kind of just hard to contend with since React wasn't built for this.
Aiden: Yeah. Uh, frankly, It's a pain in the ass. react makes it really, uh, absurdly hard to, you know, work like actually plug into internals. Like even any other library, like, I don't even know, like solid or svelte you could literally do what Million does much easier. Even like, it's almost like React is purposely preventing like outside people to, to do things with it.
But, um, it's been definitely a journey. Um, Frankly, we have, we, we have a solution that works. Um, it's not the best solution, but it's definitely not like super hacky.
does, does it, does it like, like what, what are the limitations to it? So like, uh, You, you have both the concept of like wrap my whole app in as millions and then wrap just Sub trees of my app as millions. Like what's gonna make me choose one or the other?Right. Um, the intended process, if you're using like our manual, a p i, is to wrap certain components you believe are slow or you measure are slow in terms of reconciliation. Um, there are pitfalls, uh, in terms of our implementation. For example, if we encounter like a conditional render, like, um, We expect components or blocks to be deterministic, meaning they return very stable J S X structures.
So let's say you have an early return, like if you're, the easiest example is like if you have like a query library, like react query. If your data isn't loaded, return null or like a loading state or else returns your ui, um, that won't work with us because that has like two branches, right? It could return two different types of ui.
A lot of our other limitations are, are fixed now since May of 2023. and we now recommend using automatic mode, which automatically determines how like when to use blocks and also, um, sometimes can, you know, optimize and allow you to optimize conditional components.
Justin: That's cool. So what is the recommended approach? Do you, I mean, do you recommend people just use the automatic mode where it's just like you're kind of wrapping your whole app or, or should they use manual? When do they choose, you know, which
version
Aiden: Yeah. For, for 99% of applications, it's, um, the intended use of million is to provide free performance. Right. Um, Although, like in certain applications it doesn't matter, like it probably won't make a significant difference. Um, it's our intention is to all allow, you know, you might as well use it, right? If it doesn't do anything, then it doesn't do anything.
Um, for the 5% use case where you have like, your, your application is like solely focused on performance. Like you're building a, like you're at, I don't know, some stock trading company, you're building a very fast trading view. You're building. For some reason you have 10,000 divs on the page. Or like those types of applications require some sort of manual intervention.
Um, ours are pretty simple for that. Like, you'll know when to use manual mode. Like, okay, my thing is slow. I need to customize this like granularly. Um, then you can use the thing. It's, um, we have a pretty good documentation in terms of how to use it and when to use it. Um, and so it shouldn't be too hard.
Andrew: So in those cases when you should use it, it's, do I have to like be very like specific of like, okay, I have this like long list. It has a bunch of items in the list, they all return like. Uh, a some H T M L with a stable root, uh, that's like, okay, they're starting to become like a millions thing that that millions could
solve.
Aiden: Yeah, exactly. Um, once you know, like let's say you're on like low end device, That. And then you see some like lag and it doesn't work. And at that case it, it's a good idea to use million.
Andrew: So does this replace the need for virtualization or are you still, do you still recommend people virtualize even if they're using something
like millions?
Aiden: It works contentionally with virtualization. Um, it's, I mean it's, I think if you're not using virtualization, that's a problem. So the idea is like if you have virtualization, it is slow also, and. I think you should put million in because, um, yeah, that at that point it's a, like a dom issue.
Andrew: the way you can't conditionally return reminds me of solid, like with solid, it's like the same thing where you have like, it, it looks like a re a react component, but if you do an early return, that's an error.
Aiden: Right. And, and it is funny because, um, I was on Ryan Carnados, which is Creative Solid Stream. Uh, we were just talking about the similarities of million and solids approach, and it's actually really interesting. Um, I, I think the best way to think of it is million is like solid, but without the signals part.
Um, like everything else is conceptually the same thing.
Justin: That's really interesting. I wonder if under, yeah, I wonder if under the hood a lot of the performance impacts that that solid has, which, you know, has been touted. It's a very performant framework. If it is like indeed, you know, done for the exact same reasons. It's like, This, especially this like early return, not allowing that or, or make requiring deterministic components.
Aiden: Right. Yeah. There's always some limitations, unfortunately. Um, I do have some ideas around how to do it. It is just, it's a matter of time.
[00:17:10] Growing up with your Community
Andrew: speaking of time, since we're on the topic, uh, and you mentioned it earlier, you are in a very transitionary phase of your life. You're going from high school to college. Uh, I I assume in high school you had endless amounts of time to work on this side project. The same's not gonna be true once you go to college.
So what, what's the plan for millions js uh, as you transition into this new phase of your life?
Aiden: I hope to continue working on it. Um, my goal is to. Try to make the project more autonomous, just be able to have it as, uh, my goal is like, if I don't work on it for like a week at least there would be some updates like going out. Right? Um, so some of the ways I'm trying to do that is through bounties and so like putting bounty, like if you do some feature, you get 30 bucks or something like that.
And also setting up a core team that's able to, um, keep the project alive, make sure, you know, things get done and that type of thing. Um, Uh, my experience is really, is a little bit different from, I think, uh, my high school experience was, I think going, is going to be more busy than my college experience.
Um, uh, as a, you know, as an Asian American, like, you know, my parents pushed me hard and, you know, for the high school things. And so I, I literally took like. Seven AP classes in s uh, junior, senior year. Um, so it's, yeah, I'm very, I'm actually very excited for college. It's a lot of freedom. I get to, I get to do things I want to, and, you know, not have to take seven aps.
Justin: Yeah. High school was not, I, I did not have more time in high school than I had college by any means. Um, So we, we touched on another point. So, you know, we are talking about your, uh, your sort of learning journey earlier, but you're maintaining an open source library. Um, and, you know, it comes with all the challenges of doing anything.
Open source, you know, communication. You're talking about like maintenance, like building a team. Uh, very different skills than, you know, learning how to program. So what was your sort of introduction into open source and, and how do you feel? Um, I don't know. How do you feel like that's going? Uh, do you feel like there's still things to learn?
Do you feel like, uh, there's areas that you want to improve on?
Aiden: Yeah, that's a good question. I, I got into open source because it was a way for me to share my work with the world. Um, be able to basically build something and see the impact of it and be validated about that. and so like one of the first thing I open sourced was, my, you know, the first like vue clone I made and it was really cool to see people, um, not, not only using it in their websites, like that's a really cool part, right?
Like change, you know, refactoring the website to use the library, but also, um, see people who create issues, you know, contribute to it. Um, for, it felt really cool to see that I had, you know, everywhere in my life I didn't have much control. This is at least one place where I can actually see people. I. You know, I can do something that people find meaningful.
Um, and I think that's why open source is really cool, right? Like, um, I mean, aside from the stars and whatever, the hype and whatever, it's fundamentally just cool to see people be able to benefit from people, you know, what people are excited about. but as you said, like on the flip side, open source is hard, especially. I mean, it's really interesting. I was, I almost like think like the first two years of me working on million was just basically like, cosplaying an open source maintainer, like, like maybe there'd be like every two weeks I would have like an issue. But, um, frankly it wasn't much activity. Um, and then like, like there was like, there's two week transitioning period where I went from like 10 issues to like, A hundred issues, and it suddenly became like all that cosplaying, wait, wait a minute.
I just got shot into the anime, or like shot into the, and so I was like, I was, I was very overwhelmed in terms of like, you know, um, handling these things. Um, and so it's, you know, I, I learned, I, at that point, I learned why open source is hard. I mean, it's not just, it's not just like, Um, you know, pushing, committing to and, main and hoping for the best.
Andrew: But it's a lot of like talking to people, right? Building that community, maintaining that community, finding funding, you know, um, just so much stuff to think about. ,Yeah, I, I, I, I like the, the cosplay analogy. I've definitely felt that too. It's like you're, you're coding in public, you're technically doing open source, but like still in your head you're like, ah, if it blows up, my life will be better and I'll have this amazing project that I'm at the helm of. And it's like, that happens and you're like, oh, shit.
There's like actual real responsibility here and like, These are other people on the end. They're not just NPCs. So you gotta, you gotta treat it as such. Uh, your view on uh, like community is key, is definitely something we've found through talking to people. Like one, one of the most success, the two most successful people I'd say I've seen in open source are Anthony Fu and Sindre Sorhous.
Uh, those two people, uh, They have thousands of projects, but they don't have millions of hours to do it. So like they are like excellent at setting up a community and getting community interest to push a project forward, especially Anthony Fu. So like going down that direction is definitely, uh, the healthiest, long-term vision of millions rather than you just like as the star developer at the helm pushing everything to Maine.
Aiden: Exactly. Actually, Anthony Fu is a monster. Like I don't even know how he doesn.
Justin: Yeah. No, he, he's great. This is, this is such an important point though, because it's like, I think when people start projecting their expectations of what your project should be onto you, you know, like, oh, will you implement this feature or fix this bug that's really important to me, but you're like, uh, you know, it changes your relationship with the project.
Now it becomes like you're, you're sort of meeting people's expectations, whereas before you're just like working on something that was fun, uh, and you know, I've found, and I think Andrew can, can relay this, it's like, it's a really good recipe for like burnout if you're not careful. So it's like you have to be, you know, definitely getting people involved.
Definitely. Like setting boundaries, like getting good at saying no or saying I'll accept a peer a, a pull request, you know, and just like deferring things. Um, yeah, it's, that's a real challenge. That's hard.
Aiden: Yeah, setting expectations is something I'm still learning. Um, Just last week I spent like 80 hours just on one issue. And so it's like a very, and it's like, okay, so the issue with million is like, it'd be so nice if it was just like easy, like it was something that's more application. Like, I just had to make this like, like, you know, something that nobody is like, it is like crazy ass virtual dom.
Like, and also think about all these things. I just had to do this. But like, um, so it's, it's a, yeah, it's. It'd be nice. It'd be nicer if it was simpler. Um, but yeah, I have to learn how to set expectations, um, how to handle responsibility. I've never done that in my life. Um, doing all that, those things are, yeah, something still have to learn.
Yeah. The responsibilities and saying no are hard things. Like you're, especially at the start of a big open source project, you're like, oh, people wanna add things. Yeah, go ahead and add things. I love adding things. And then it's like, you then have to deal with those additions and it's like, oh, sh, sh should I, uh, have done that in the end?
Andrew: But I think you've done actually, like looking through the docs. You've done a pretty good job at like not making the a p I balloon into like. Dozens of, dozens of things you really have like block and then two other things. Uh, I'd like to touch on those two other things, but, uh, definitely a, a good way to go forward is keep it slim, keep it minimal.
Um, so let's, let's just dive into those two blocks. So, or those two other things. Uh, one kind of makes sense to me. The other one I don't really see how it does. Uh, so why is there a four component and, uh, why is that necessary to use with millions js.
Aiden: the four components actually optional now. Um, essentially it's, it's allows. Uh, the developer to, you know, efficiently vendor a list with blocks in it. Um, and so imagine it as like a rep, effectively as a replacement for map. Um, yeah, that, that's pretty much it.
Andrew: So not all that necessary anymore. And I guess while, while we're here, uh, macro, macro seems like a, it seems like a babble feature rather than like a my react re reconcile or replacement feature. So, uh, why, why is
that in the a p I.
Aiden: that's, that's definitely feature creep. I was like really bored. Uh, I was like, you know what? I, I have this evaluator internally. I might as well like write two lines of code. And then there's my feature. Um, frankly, I don't think anyone uses it, but it's, it's there if you want to.
Andrew: The opposite approach of the React developers, where all internal things are a closely guarded secret.
Aiden: No, exactly
Justin: Yeah, that's always a fun thing. And then somebody does use it and then you wanna remove it later, and then people complain and you're like, wait, what you, this is just a fun thing. Why are you, and then you do like react team, and it's like have a variables, like if you use this, you'll be fired. You know, like whatever.
[00:26:34] Wrestling with React
Andrew: so you, you just mentioned that you spent the 80 hours in the past week working on one issue. That's a lot of hours on one issue. So what was it and why was it
hard?
Aiden: so I was trying to solve, uh, like, okay, this is kind of conflicted. It is like nested hydration. And so one thing you can do with million is um, you can. You have a React component, and inside that React component you have a million block, and inside that million block you have a React component. Um, but the, the the, you know, the nested one isn't always hydrated efficiently.
And so I was working on that, making that like hydrate. And the thing is it, um, so I was using like a next JS setup, right? I had like million on the side and next JS on the side, and I had like an R S C setup and whatever. Um, but like the thing is, Next Js makes it just so hard to develop libraries in, and maybe it's 'cause I don't have a good setup, but also I had like, at some point I had like 91 hydration errors, like could not find the, the span inside the div, whatever, you know?
And so developing with that is really hard. Um, and honestly, I, I, I do this all the time, like, A lot of these issues come down to working with server, like server-side rendering or some sort of hydration bug or some sort of compilation bug. And, um, it's, it is, yeah, that's, that's my process.
Andrew: So for these nested react, uh, millions things, uh, I saw that the, the issue that was linked to in the thread in the end was, Uh, apparently React doesn't hydrate portals. The reason React doesn't hydrate portals is because portals don't actually exist on the server. So like to hydrate something that doesn't exist on the server doesn't make much sense.
So why do they exist for you? Is it that when you're doing this, like nested rendering, that like the nest rendering is actually done via a React portal so that like React
can still do its thing?
Aiden: exactly. Um, react doesn't actually know about millions, um, stuff. And so it's just, I mean, it's still all elements in the thing, so, Um, it basically, you know, shoves itself into the million block and doesn't know anything about it. Um, but obviously that sucks for hydration, right? Like, how the hell do you handle that?
Um, I, okay, but sneak peek. I do have something in, in store, react three fiber, which is like a, you know, a big project. Um, one of the. Developers on it, created a project called It's Fine. And if you know that meme where it's like the, the cartoon dog with the fire around it? Yeah, it is. That project's banner is literally that.
And so I'm looking into how, we can use that sort of thing to, to bypass some of the restrictions of portals.
Andrew: That'll be a, that'll be a really interesting experiment. I, I like sort of poked around that library before and it's just like, I don't know. It, it's pretty crazy. Um, I, I am curious. Uh, so while we're on the topic, uh, you know, you said, I mean, of course React doesn't know anything about what Million is doing.
Justin: Uh, makes sense. Uh, have you talked to the React team at all? And, you know, I'm just curious if they've, like, if you've engaged with them, if they've given you any feedback, if you know there's any conversation that's happened
there.
Aiden: no, I don't know why, um, uh, I, I'm not saying I push too hard, but I've tried to try to talk to them about it. but I don't think they're very interested, unfortunately.
Justin: Yeah. Well, I mean, it goes, it's one of these things where I'm sure that they're, you know, busy or whatever else, but, uh, it would be, it would be interesting because, you know, I feel like there's probably a lot that you could learn just from, you know, Even just figuring out why they made some of the decisions they made.
Um, I, I'm sure that would be very educational. If you talk to 'em about it, you should record it.
Aiden: for what's worth, I think, I think Reacts decision making is. Isn't like, you know, it's not nonsensical, like it makes sense. Um, this, I, from what I understand, uh, uh, Dominic, I forgot his last name, from the Inferno Network works on Spel five. Um, he actually made a prototype of this back in 2018, like not million specifically, but the same implementation as Mill.
And you know, he's been working on Inferno and like all these like super fast React libraries for a long time. Um, and so this is kind of like, this is kind of like what Dominic could have introduced through React team maybe a couple years ago or five years, you know, four years ago. But instead it react, of course, went with like it's concurrent mode with React 16 and like time slicing and whatever, right?
Um, obviously there's, there's trade offs decision, but this is another approach of how to make react faster.
Andrew: Yeah, it's uh, it's been cool to watch the support you've gotten through Twitter while you've been doing this. Like you, like I often seen the sentiment of like, everybody knows what you're trying to do is like a very, very hard thing to do and it's just like old people going, yeah, I've tried that in the past.
Didn't really work. Good luck kid. Like a, a few of those. So, uh, yeah, it's just been been really cool to see. And yeah, Dominic is, Is a force. Uh, and that's interesting that you say that he had a similar thing a few years ago and like, it was probably like a, should we do concurrent or should we do this thing?
And they chose concurrent. Uh, does that mean that like millions js doesn't really work in con concurrent
mode?
Aiden: It should work. Uh, from what I understand, concurrent mode optimizes the render phase of react, not reconciliation. And so
from what I understand, the way it works is it like, it like, you know, does this whole thing, it's like makes, doesn't execute everything at once. And then in terms of rendering and so like on a component by component basis or a hook thing, um, and then it just commits all those dom changes at once.
Um, so I. I've tested with react fiber. It seems to work, um, but I don't know if it makes like a huge difference or not.
Andrew: Hmm.
Justin: Yeah, that's, this is all, this is all so fascinating. I, I just thinking about like the implications of a lot of, of this work and it does seem like deep hard work. Um, I. I, I'm curious like where you're at on your journey with this. Is this sort of the, was it like you started this and you're like, oh yeah, I just wanna do an optimization and, and then it like, sort of took over and all your other projects kind of fell off?
Or is this just like one of a few things you're working on? Um, do you have a point where you wanna like, you know, get this just rolling and then like focus on the original thing that you're trying to do or, or whatever? I'm just curious like where you're at on this journey.
Aiden: I've been focusing on million for. I've been doing this for like two years now. Like, um, I've, I've had side projects, um, but like they were mostly, 'cause I was bored and so I built it with million. And so, um, during the school year I created like a, like a trivia website for our, you know, trivia club things.
Um, uh, also, you know, like I. Like, or like my club websites I would make with million. But like mostly this has been my focus for the past two years, um, which is why I really suck at creating websites. Like if I, if you gimme Tailwind and H T M L, it's gonna take me like 10 hours to create like a decently looking website.
But I can work on dev tools, that's, or tooling type things.
Justin: I feel that so much. This is, this is often, this is the thing is like I'll have like family or friends. It's like, oh, will you build me a website? And I'm just like, uh, that you don't know what you're asking. That's so much work, but it's like, you wanna build me this little compiler tool? I was like, yeah, yeah, totally.
Aiden: No, I feel that.
Andrew: Yeah, and not many people asking for the compiler tool though,
unfortunately.
Justin: No, unfortunately.
[00:34:19] Caring more about Perf
Andrew: You have something that kind of works right now. Uh, you're working towards making it work more of the time. What's the future? Uh, do you want, is there more after this you want to accomplish?
Uh, do you wanna fork it into its own, uh, front end framework? Because react just can't do too many things. Uh, what, what do you plan to
do?
Aiden: Definitely not in the framework. I don't that that then, then, you know, developer's gonna complain. It's too much. Um, but I think what, through building this project, what was really interesting learning for me is developers don't want, I mean, they don't care about performance. Um, and I don't mean that they don't care.
I mean, obviously if it's free performance, I'll take it, right? Like, or like very cheap performance. Um, But once it's like very hard, like if it's not bun then I don't wanna switch to Deno, right? Like, um, so there, there's obviously some trade offs there. Um, and so I want to explore building really, really developer friendly tools like milloin that either automatically optimize it or some sort of like very DX focused, uh, things that allow you to get free performance.
Um, a lot of companies spend a lot of money on. Uh, you know, tools like Sentry or Datadog or performance consultants that, you know, rack up thousands if not millions of dollars. Um, but none of them really solve the root problems of performance. Like the site is so slow for some users, and so I wanna focus million, not focus.
I want to broaden million more onto, you know, Thinking not only about reconciliation and like DOM stuff, but also, you know, network or frontend infrastructure or backend infrastructure. You know, there's a lot of so much things to explore in performance that, um, I think are really interesting and should be explored.
Justin: Yeah. That, that take is, is is real. So I know in the Twitter circles it can. Feel kind of closed because like a lot of people talk about performance and like, uh, choosing performance tools and stuff. But sort of the reality is, is like when you get in a company, especially, and you've got a lot of people contributing to a product, they're just like building components and like building ui.
And most of the time that's all they're thinking about. You know, and they'll use the tools that are available to them to do the job. And performance usually doesn't go down like drastically with like one PR. It's usually like you have, you know, a thousand PRS over a quarter or whatever, and now like the, the site is really slow and people are like, well, why is it slow?
And it's just like, there's a lot of things. So I think there is something to this of like, I mean, I, I would go say like, developers are kind of fundamentally lazy. They don't wanna work on things outside of the thing that's important to them. Well, lazy is probably the wrong word. They're, they like are, are very honed in on solving the problem at hand, which is good.
Uh, so I definitely think that this, this focus of like thinking about tools that just like broaden, you know, improve performance holistically are really good. They're also really hard. They're really hard. And I think that's why like other frameworks like, uh, solid or selt, uh, view, you know, thinking about like other means of, um, rendering or, you know, can we do without a virtual dom or whatever.
I think of like quick to with, its like interesting hydration method. It's just like, you know, we have to. Take some, some really broad steps to kind of raise that performance, uh, threshold. So I'm, I'm really interested to see sort of where you take it next and, you know, whether you're building on million or you sort of like move on to different projects.
Uh, I, I do definitely think that the ecosystem needs more sort of holistic performance thinking though, for sure.
I definitely like the angle of thinking about it as if I don't care because like that's the best way to code is that you don't care about performance and it just, Comes naturally. That's why some, some of the React projects that are coming down the line, I'm really excited about and I really hope that they don't get dropped, like, react, forget if I never have to write a used memo or a used callback again, uh, my, my wrist would at least be saved.
Andrew: And then, uh, the react offscreen stuff, uh, if we could get that stuff going, like. Once, well tho those features really fall kind of in line with what I see millions doing is that it's like it's making performance better, but you don't have to think about it. And I really wish we could get there. 'cause it is, as you said, it's not simple like, uh, adding virtualization to an accessible part of my app is a lot
of
work.
Aiden: Yep, for sure. Yeah.
Justin: And so you, you, your, your sort of take is like, developers don't care about performance is really interesting. Do you have any other like spicy dev ticks that you think, uh, that you sort of like noticed?
Aiden: Yeah. I think, um, I guess in like the realm of DOM stuff, like, I think a lot of like benchmarks are overrated. I think, you know, most people don't care about benchmarks and that's okay. Like, um, I guess like outside of this, like something I've been really frustrated about is like chat G P T and like devrel and documentation.
Uh, it sucks. Like it really sucks. Like, um, I'm getting like issue, like issue and PRS that are literally generated by chat G P T and oh my gosh, I know it's supposed to, I know it's supposed to help like. You program, it does help me program. It's just, it's just, there's so much spam that's created out of it in the past year.
It's just, it's terrible.
Andrew: Yeah, I don't think that's too spicy of a deck dev take, but I, I definitely agree. Uh, the benchmarking, uh, point brought up a thing for me with performance. Uh, the hard part about performance for me. Working on, uh, an enormous React application is knowing when it goes wrong. Like we don't really have any good tools that say, Hey, you rendering this long list in your app.
It went from taking 10 seconds to taking 20 seconds. If I could just have that tool, that would be a powerful tool. So may, may maybe a little, uh, millions feature that you can cook
up.
Aiden: Yeah, that's actually exactly what we're working on, um,
in the future. Yeah. Um, being able to, um, obviously you can use dev tools for this probably, but like, um, being able to monitor paints and, you know, More granular stuff other than just rendering.
Andrew: That's exciting. Uh, I, I look forward to seeing you release that. Um, okay, so last question. We usually ask like a future facing dev
question. Uh, But I, since you're like a newer programmer or like a younger programmer, at least you've been doing it since you were in fifth grade, that's a pretty long time. Uh, what do you view as like the most exciting things going on in, uh, the front end JavaScript world?
And if you see something even more exciting outside the front end JavaScript world feel, feel free to say that.
Aiden: Yeah. Um, it's definitely the return toils, I think in a purging TypeScript from all our code bases is definitely the way of, no, I'm kidding. Um,
Andrew: Oh.
Aiden: I think what's really interesting is. Projects like bun that, you know, reduce dx, um, or make DX better. Um, I mean the net, the network effects are crazy, right?
Like, um, if you really think about it, um, maybe on your end one MacBook, it might be like couple seconds faster, but like on someone else's, you know, I. Uh, like, like what? I have like, like a shitty Chromebook. Shitty Chromebook. Like, it, it doesn't work. Um, like what M t M would take, you know, hundreds of seconds, BUN might take tens of seconds.
Um, and fundamentally, I think these tools that are coming out, whether it's million, whether it's bun, whether it's quick, whether it's whatever, and makes things more accessible for people, um, Information is, you know, is critical. Like being able to access these websites is critical. Um, people like me or my grandma or like whatever, um, whether you're in the gym with low service or you know, on a subway train, these things matter.
Like we need to build tools that are thinking out performance. Um, so I'm really excited about the front end world right now. Really excited about bun. Really excited about performance.
Andrew: Yeah, uh, BUN is definitely exciting. We talked to Jared around a year ago now, and. Like the performance we're, we're experiencing right now isn't even, like his end goal really. Like his end goal is something that hasn't even been released yet that's enabled by all of this insanely quick JavaScript execution.
So yeah, I'm, I'm, I'm very excited to see where that project goes. Uh, it's been cool this last week to see it blow up and everybody give it a whole bunch of love.
Aiden: Yeah.
Justin: this is go back, goes back to your earlier point, uh, just having these, like broad stroke performance, uh, improvements, you know, Just like, it's great. And both bun and Deno, I think are pushing Node in positive directions because it's like, there'll be something that happens in Deno, something that happens in Vine, and then people are like, oh, well, like we could do that.
Or, um, you know, we had heard that from the grapevine that, uh, you know, originally Deno didn't support. N P m, uh, compatibility and then BUN was like coming on the scene is like, oh yeah, well we're gonna be compatible with N P M. And then Deno was like, well, you know, like we can do that too. And you know, it's just interesting how all these tools like push each other to make, you know, the whole ecosystem improve.
So competition is good, or, or, you know, not competition necessarily, but collaboration across the ecosystem.
Aiden: A little bit of coffee shit.
Justin: A little bit of competition. Yeah.
[00:43:41] Tooltips
Andrew: Okay. Uh, with that, let's transition into Tooltips. so the first thing I'm sharing, this popped up on my GitHub Activity viewer app that I use to find things. Uh, this is espresso from the moon repo team. Moon repo is like a mono repo tool that I haven't really all. Checked out all that much, but they're creating a bunch of other packages in the ecosystem.
One is, uh, espresso, which is a new package registry. Uh, but what's interesting about it is, uh, you publish source to the package registry and then as a consumer of the registry, you say, I want it in this format. So, uh, You can say, oh, I wanna install all of this as, uh, e s 2016. So it all has import export, uh, this is, I, I don't know if this'll work.
I don't know if it's a good idea, but I like seeing people acknowledge that the C J S E S M transition and known node has been like just a world of pain and hurt for like everybody involved, basically. And it might take a new tool like this. To get us outta that. So I'm, I'm excited to see where the project goes.
Justin: Yeah, that'll be really cool.
Andrew: next up we have obsidian, L S P.
Justin: So, uh, we've talked about it, uh, before on the podcast. Uh, I use obsidian for note taking. Um, And if you've not heard of LSPs, their language servers, uh, that's what you know. Microsoft built for VS. Code to give you like TypeScript auto completion and stuff. Um, LSPs are really fascinating. It's a protocol, uh, it's a language server protocol.
It's, it's a really, really fascinating protocol. I should definitely look into it. Uh, but someone, uh, wrote an l S P for obsidian. So obsidian uses markdown files. Um, but it has like some special syntax, right? It's got this like backlinking syntax, so this L s P, uh, you can do a backlink and it will give you auto complete options for your backlinks and stuff.
So you could ostensibly use obsidian in anything that support, or like obsidian style, markdown files in anything that supports L S P. So like, You could have Vim integration or emax or whatever, you know, and this is really cool because it just makes, um, it makes the obsidian style notes, the obsidian style markdown even more like capable.
Uh, so you can use more than just obsidian. So it's like if you need to, you know, pop it open and vs code, then like you have this option. Uh, and still getting like good experience of linking and stuff.
Andrew: That looks pretty cool. It's, it's also been cool to see like the obsidian love grow over the past year. It's become a quite a mu bigger tool. All my open source obsidian packages get far more stars than all my other stuff, and I only used it for about a week.
Justin: Yeah, their new c e o is killing it. He's doing a really great job and the obsidian team, they've, uh, been a small and mighty team for a long time, so they just do excellent work.
Andrew: next up we have the web components, Dom, part A p I.
Aiden: I've been following this a p i for real, uh, a little bit now. Um, I. Google is introducing this as an experimental feature in the recent version. Um, basically it allows you, or it allows frameworks to, um, like efficiently update nodes.
And so like, this is like basically how Million works internally. It basically how solid works internally. It, it's kind of how, um, it's kind of how svelte works internally and it can reduce a lot of framework code. Um, and it can work at a, like a. Um, you know, uh, native level.
Justin: Always love it when the platform adds APIs that mean frameworks have to do less work. This is always nice.
Andrew: Hopefully it just get adopted someday.
Justin: Yeah.
Andrew: Okay. Uh, my last tool tip for the week is a, uh, An express replacement for bun. Uh, so this is just a node server built for bun and it's really, really fast. Who would've guess? Uh, it's a, a lot faster than other BUN based frameworks too. It's faster than a HNO and bow. Uh, and it has like built in end-to-end type safety, even though you don't like, uh, types yet.
Aiden, uh, they're nice to have. Uh, and this makes it really easy to do so. Uh, I just love. C end, end type safety. 'cause it makes development so much easier. And you can integrate stuff like swagger docs really easily. So if you're looking for a really fast JavaScript based server and you wanna try out bun, I'd probably check out Alicia.
Justin: Yeah, that's really awesome. I love the the open i p I generation. That's slick.
Aiden: Have you guys checked out the, the Beth Stack, like by. Um, Ethan Nier. There's a, there's a whole video on it where it's like Alicia Bun, uh, H T M X. It's a crazy concoction.
Oh, B E T H?
Andrew: I don't, I don't,
think it's this, but this is also called not the o Open source, uh, alcohol stack. Next up we have the murder engine,
uh, ominous.
Justin: Well, uh, I, whenever this recording is released, uh, today or yesterday, A was the day when, um, uh, unity announced that they were gonna start charging for game installs. So they're gonna charge the developers of the game every time a user installs their game, which is not. Great. Uh, and the community, obviously all these game developers are pretty upset.
Um, so I've been looking at game engines. Uh, I've always been really interested in them and I esp, I particularly love like two D Pixel art based games. 'cause it reminds me of my childhood. I. And this, uh, is a game engine that I encountered today on Twitter. It's called Murder. Um, but yeah, it's, it's specifically designed for doing like 2 D pixel base games.
Uh, and it's, it's a gorgeous framework. It's got good documentation. It's only like, it's, there's only like two people that are, are, that are maintaining it or whatever. So, you know, it's just like pretty small. Um, but. I don't know. It's nice. And I love these like little indie engines or whatever. So, uh, I was just, you know, looking for alternatives of things.
Uh, there are a lot of really great game engines out there. Like go.is a, is a, or got it, I guess is a really popular open source one. But, um, you know, there's a lot of really fun indie engines out there too.
Andrew: They're charging for installs.
That that's, that seems crazy.
Justin: They're charging for installs. Yeah. And that's on top of like, you know, already having like developer license. Uh, so yeah, it just,
that
seems like,
Andrew: it's gonna kill like all indie game dev
on Unity probably.
Right?
Justin: basically, basically,
And, and the other thing is like, it infects like streaming games and web-based games too. And the question is like, what does it mean to install? So like for a web-based game, technically you install it every time you play it, right? So it's like,
Andrew: Yeah.
Justin: you know, I don't know. It just, uh, that seems, it seems, like a really poor business decision
on their part.
It does.
Andrew: Okay. Last up we got
quick boot js.
Aiden: So, um, I was just on Twitter scrolling and some, some guy put out, um, this, this crazy library. So basically from, from what I understand, it runs like your app and then it figures out which parts of the, parts of the, um, code don't run. And then it just like re like, removes them or effectively removes them.
And this is kind of crazy. Like we're normally, we, what we understand a tree shaking as is, it just sees if these things are dependent on each other. And obviously like things will be dependent on each other, but they might not be used. And so this is a really interesting way to approach that. Um, I, it reminds me of things like quick, um, that, that try to defer things as much as possible.
Justin: Uh, Andrew, you beat me to it.
Yeah. Yeah.
Andrew: Yeah.
Uh, reminds me of pre-pack, which, uh,
was a, a project
from Facebook that tried to do the same thing, and then they just ended up
throwing it all out.
Aiden: Yeah, that this has made me really sad. I remember building a library back in the day and just wanting to use this to make my code smaller.
Andrew: Yeah. J JavaScript free shaking is, is hard. Like espe, like you, you think it's simple. It's like maybe even just that import export stuff? No, there's things like, uh, what are they called? Like you have to mark things as pure I. That they don't actually have side effects. And like sometimes some things won't get marked as pure and like randomly your bundle blows up.
That's something I wish we could solve in JavaScript is like just make it so that I can actually tree shake my code rather than having to run four different tools that all kind of do it a little bit and then hopefully it actually works in the end. 'cause that's what the current state of tooling is today.
Just like four tools that half work and in the end they
kind of work 'cause you put em all together.
Aiden: Exactly. Yeah.
Welcome to JavaScript.
Andrew: we pay for the speed and the choice of tools with, uh, the, the lack of intense tooling sometimes that can
do, do cool
stuff like that.
Okay. That wraps it up for tool tips. Uh, thanks for coming on, Aiden. This was a, a fun talk both from your perspective of trying to make react faster and as a person that's like so
early in their career and
has kinda like fresh eyes for the things that we've been looking
at for over a
decade at this point.
So thanks for coming
Aiden: Yeah, I'm super happy to be on. Uh, honestly, this is probably one of my favorite podcast episodes, so thank you so much for making it fun. So fun.
Andrew: Awesome.
Justin: Yeah, it was great to have you and just, you know, I just wanna say props for diving into such a hard problem. I know high school in particular is, can be really stressful getting to into high school and, you know, having worked on this for a few years, it's a huge accomplishment and definitely props for that.
You should feel very proud of what you've done.