How Svelte and RSCs are Changing Web Development with Rich Harris, Creator of Svelte

everything everything about it is is is better it's more robust it's more reliable it's smaller it's faster um it's more flexible it's more composable um it's it's just easy like you will end up writing less code with spel 5 than you did with spel 4 um and it's just going to feel nicer Rich Harris creator of spelt Tracy Lee Adam rakis and Ben Le is discuss the state of spelt and how react server components are revolutionizing web development hey everybody welcome to this episode of Modern web I'm so excited to be here today my name is Tracy you can follow me on Twitter at lady El or on LinkedIn at Tracy sley I'm here with Adam rakis who you cannot find on LinkedIn well you can but you know he's not on there really truly on there um I got Nest from like a week ago that I only now responded to and I felt bad but yeah find me on you responded to somebody on LinkedIn it seemed legit they they claimed to be a classmate of mine from the Air Force Academy wanting info on Spotify so was yeah I'll reply sorry it's been a week since I hey I mean that's pretty good timing I didn't know I didn't know you that like if I I'm going to message you on LinkedIn today that's what I'm gonna do I'll reply in a week um so you can follow Adam Rus on Twitter Adam Rus and then today we have rich Rich Harris who we all know and love do we all love you rich everyone love you controversial statement you can't not love someone with such a buttery smooth English accent as that you know what I got a message from LinkedIn the other day congratulating me on seven years at the New York Times which tells you how much I use LinkedIn oh my goodness well you're also a cheese fan according to your profile so do you have a favorite cheese the favorite cheese is whatever cheese is closest to hand I am a very unfussy uh non-discriminating cheeser okay like so all the fancy cheeses you also like oh yeah I like I like fancy cheeses but I'll I'll slum it with the I'll eat the cheese of the Common Man yeah what is the cheese of the common man cuz you know you're not well I mean you're not from the US but you're in the US so like is the cheese of the Common Man cheddar maybe get through a lot of cheddar yeah and is that in the is is that like also in the UK like cheddar oh yeah I mean the the the cheddar that we get is I think we normally get like Irish cheddar yeah okay okay they the Irish they they know that they know that cheese my favorite is um like a mimolet you know what mimolet is I don't think I'm familiar yeah it's kind of it looks like a cantaloupe so there's a rind and then it's orange and then there's like salt granules inside of it oh so yeah it's pretty delicious but there's also this one called AAS have you heard of AAS like really wow my I got to level up my cheesec game apparently there it's like really liquidy and it basically tastes like um you know dirty socks I suppose but H you had me until that but well if you're a cheese lover you know you're gonna love it but all right anyways we love your opinions about cheese but we also love your opinions about drum roll what react server components tell us about yourself though by the way like we haven't even introduced you cuz we just assume everybody knows you uh uh God I hate this part I'm um I am the perhaps most relevant to the current audience I am the creator of a UI framework called spelt um which is the the thing like react or view it allows you to write your applications out declarative components been working on that for about seven years for the last two and a bit of those years been doing it full-time at Vel um who employ three of us to work on on spelt um we have a application framework that goes with it called spel kit um aside from that what can I tell you uh I I live in New York my my background is in the news business and I just kind of been doing open source as a way to keep myself amused for the last few years I love that well again we all know and love you so um and yeah I'm just I mean Adam was it was actually Adam's idea to invite you on so I mean Adam only has good ideas so it's true you can just check his Twitter handle and that was rer stamped your Twitter I think people were saying some negative things about RSC and I said we got to get rich on here he's got to get in on this although I'm not sure that'll go over well with all your co-workers so what have I done to you I'm sorry yeah you're putting me in a in a tough spot here because I I do have opinions about rsc's um not like bad opinions I actually think they're pretty phenomenal but I do work with the people who are building the uh preeminent RSC framework um so yeah I'm G to try and be honest and forthright and and and and share my my deeply held views without pissing off the people that I hang around with in the slack Channel all right dive in um I mean start me off somewhere ask ask me a ask me a question so if we were to say the top level like design goal so for a long long time if you're building a web app Javascript kind of matured and blew up and we had all these Frameworks that let you build reactive uis but they all lived on the client and that was great and it was good enough most of the time but there's a lot of benefits of doing more things on the server so that you don't have all those extra round trips before you start requesting data and so RSC was certainly not the first but it was a big uh Improvement in react itself to sort of bridge that Gap and let you start moving more things to the server and stream them down to the client while keeping the same sort of component model and I think that's a good starting point and if you want to take it from there and talk about what the tradeoffs are and what the difficulties are and maybe that'll lead us to a good discussion of how you solve some of those problems differently in spell kit yeah I mean there is really is so much to un unpack there for me the the big appeal of react server components is that it is The Logical next step of this journey that we've been taking over the last decade or so to collocate all of us all of our stuff together basically you know back in the day we had this absurd notion that you should separate your concerns which meant like having your HTML over here and your JavaScript over here and your CSS over there and gradually largely thanks to react but it was a like a a broad-based movement people came to accept that that was a very very bad idea indeed and that actually if you have some CSS that relates to a specific piece of markup in your application and you have some JavaScript that relates to that same markup then it all belongs together and so we started collocating stuff um and I think spel is is was at least for a while um uh one of the the more aggressive adherance of that philosophy because not only do we have our behaviors alongside our markup but we actually have styles right there inside the component file um so everything is like this this nice little self-contained thing but there was a piece missing from that which is the data that your component needs to render um the Assumption was that you were going to have that that data passed into the component or maybe you know when the component initializes in the browser it's going to like set up send off a netork request and fetch some data and then it's going to update some internal State and it and that works but there's obviously a bunch of drawbacks to that and one of those drawbacks is like you really don't want to be doing that that stuff over the network if you can help it because you're going to have to have loading Spinners and like probably have all sorts of waterfalls and and grubby stuff like that um but the the real problem is that you need to have that data fetching code if you're going to pass it into the component in some other location than the component itself and that is basically how Frameworks worked up until RSC at least the like the client side JavaScript Centric Frameworks worked like next prior to the app rout had things like get server side props um spel kit had a load function it's predecessor had a thing called a pre-load function which did did the same sort of thing um remix came along they have a a loader function and these are all solving the data fection problem at the root level so you get your data at the root level and then you pass it down to your components as as props Works reasonably but if you delete a component that is using some of that data you you might still be fetching it and not realize like you have no idea that you've deleted the code that needs the data but not the data itself and conversely if you add a a component deep in your tree somewhere then you might need to update your data loading function which is quite remote and might even be overseen by like a different team and you just have this really nasty coordination problem and one of the things not the only thing but one of the things that react server components solves really elegantly is the code for getting the data that belongs with the component exists in the component itself so that is just like The Logical conclusion of this trajectory that we've been on of just getting all of the stuff together because then guess what if you no longer need that component you can delete it and you're no longer going to fetch the data for that that component um so that is a really nice elegant thing that I don't think I've seen anyone solve as well as rsc's have soed sounds too good to be true what's the uh what's the catch so I think the the biggest catch with rsc's in in in my view is that you're essentially creating these two separate worlds like you have components on the server and you have components on the client but they're not the same kind of thing and there's there's obviously good reasons for that like the server is this stateless environment so it doesn't make sense to have state full hooks um your client components it doesn't make sense that they should able to access the database directly so stuff like that like there's obvious reasons for the behavioral differences between server components and client components but I think what we've kind of seen is that that difference is just really confusing for people like I I've seen people really struggle with the concept of components that that work this way like people just I don't know don't fully understand how how they work and and I get it I I sympathize with that like I I want to just have the same mental model throughout my application to the extent possible I I don't want to be thinking like oh what what are the what are the rules again on how I can combine these different components and like what data can be serialized all of that stuff it it just confuses me and it confuses a lot of people and so I I think like that is is the the main the main sticking point is that it's difficult this is one of those places where being old is a huge Advantage because there's been so many times when I just have to think about things and it comes back to I get memories of asp.net MVC from 10 years ago and just thinking about how servers work and any web devb who was raised in Thea era they've got a lot of learning to do and it's going to be ugly at times especially since react makes it everything look so similar sure the RSC can have the async keyword and the client components cannot for now but the difference is are so deep seated and deep rooted that it's going to be it's it's a tough learning uh Challenge and teaching challenge for react I think hello Ben sorry we're talking about RSC right now I think you'll get caught up pretty quick oh yeah what I think is funny Adam though all the time now before we get back to our conversation we wanted to say thank you to this. laabs who is the sponsor of today's show if you need help with a project that has failed to deliver on time or in need of a team that feels true ownership over your engineering projects definitely hit up this. laabs they specialize in helping Business Leaders ensure their strategic digital initiatives stay on track trusted by companies like PlayStation Capital 1 Herman Miller PayPal and T-Mobile you can find them at this do. that's thd.co now let's return to our Show with Adam uh see Adam I think maybe maybe it's my cop mechanism but I'm like I know you're opinioned about things but I never remember what what you're Pro and what you're not pro on I just remember that Adam has strong opinions about like something so Pro talking well this will get segue to the second thing we were looking to talk so everything are so rich just gave a beautiful sort of explanation of RSC and that's actually built into to react It's Like A Primitive but you need a framework to come along and actually implement it and there's any number of design decisions that that framework can make and so the first one that to ever exist for now is next and it's kind of the only one there there's this thing called waku which is a like a minor micro framework but remix is working on it and tan stack is working on it but next was the first one out of the gate they were the first implementation and they made some what I think is interesting and I mean I'll be honest a little bit disappointing decisions uh Rich what I mean I know this is your employer so feel free to punt if you want but do you have any thoughts on how next implemented RSC as the first one out of the gate uh I I don't have um opinions based on actually using um the app rer but I I I do have opinions on like framework development generally and one of the things that I think people don't give the next team enough credit for is that this thing has been around for what almost 10 years if if not if not more and like all of the old stuff still works and so like this entirely new paradigm has been built alongside an existing very mature framework that is powering millions of of applications um and and so I I think like any critique of the framework needs to be done in the context that like that is a hard hard thing to do I do not envy the task one bit um I think it's pretty exciting that that this thing exists right because we have people working on the react core team who are also heavily involved in next development and so what next in the at router essentially is is like it is the vision for what using react is supposed to be like like it is it is as pure a distillation of the concept of react Ser components as as I think you'll find and you know it's being battle tested with a lot of large production apps today um some of the like you mentioned that you've had some frustrations with some of the design decisions and like that's what happens if you're the first mover and you're learning in the open um so you know I I give the team a huge amount of credit for what they've accomplished and the things that people don't like they'll get fixed over time I think it's more interesting to talk about like the the very concept of RSC is like at a fundamental level is it the right direction for the web to be going in and I have like pretty mixed mixed opinions about that whole topic what are your opinions so you know I felt's thing is let's try and take as much work out of the browser as possible um you know we we were kind of the first framework to popularize this idea that you can do work as part of your bill step and then you don't need to do it like for every user in the browser um and and that happens because like bundle time we run this compiler over your code and it generates this like optimized JavaScript representation um which is all well and good but what RSC are doing is kind of in a similar vein in a very different way doing the work on the server so that it doesn't need to happen in the browser um and that is like a really cool and smart idea if you can get it to work effectively um as I mentioned the the data collocation is also really cool and a side effect of doing the data fetching on the server is when you inevitably have waterfalls between your components by which I mean you know a child component can't be rendered until some parent component is rendered and it can't find out what its data dependences are until that has happened like if you're doing that work on the server right next to your database then the effect of those waterfalls is going to be severely mitigated so like all of these things point to like a pretty revolutionary architecture that's a really key point that I think is not stressed enough a lot like any discussion of rs's you see people are always freaking out like oh it's easy to create waterfalls but what they leave out is that these are waterfalls on the server which are very likely to be substantially cheaper than browser to server waterfalls which is what we had prior to RSC don't waterfall tracing it's it's true up to a point because you know you're you're you might be relying on an external API which might not be in the same location like it might be half around the world and so if if you're sort of relying on this euristic that oh I'm doing the work in a server component therefore I don't need to worry about waterfalls well candidly you might come unstuck like a lot of the time that is true but it's not always going to be true um and so yeah it is definitely consideration but it's not like you don't get a free pass you're not freed from thinking about that stuff just because you're You're Now using rsc's for sure I didn't mean to imply that you were but yeah that that's a good clarification yeah I feel like um at an architectural level though um react is going to be hindered a little bit by virtual Dom uh where like other Frameworks like a like a spelt or a angular or a quick or whatever um they're not like while I think the virtual D Paradigm does make certain like reasoning about certain things easier in a lot of naive senses like the problem that I see as someone that worked on some of these things and brainstormed with some pretty smart folks on these things is that um when you've got a template um for whatever it is whatever Dom or view you're going to rent you can use a compiler to do things like in in theory in theory uh you could take a templated framework and literally generate H an HTML file that had JavaScript in it like you could do that and be like I'm just going to put this on a static host and it's done right like you could actually do that but with virtual Dom it becomes a little bit more difficult because you can't always deterministically St statically analyze everything that virtual D do right like so it's it there's there's some weird problems there because you have this touring complete templating language and not like a a refined set of things that you say oh this is all it can do um so it's funny like I feel like um react success is mostly because of react success at this point um it's it's great but like and it's really easy to to Rich's Point earlier too where it's like really easy to on Frameworks that have been around for a while because they've been keeping backwards compatibility and they can't just pivot and like react one is stupid yeah well guess what you use 12 years ago Dude like it was the best back then right so it's it's kind of one of those things where it's really easy to to say those things even even for me I on stuff all the time but um the truth of the matter is that you know they're phenomenal for what they do for for serving so many people for so long I just think that long term I worry about any framework that has leaned so hard on the virtual Dom thing as as react has even for like they have to kind of lean a little bit more into rscs to get performance than you could maybe get out of just totally client side rendering things if your compiler could literally just be like all right so here's your HTML and here's your JavaScript and you know here's a couple backend pieces that you hit or whatever um yeah I mean for for context spelt does some of the sort of things that you're talking about like it spel 5 in particular you can look at the compiled output um in our playground um and you'll see that if you have a static blob of HTML inside your component that doesn't get turned into any kind of virtual Dom that just gets turned into um into a template which is cloned using like the the Clone node API and then it's it's just there it's and on the server we're just generating HTML we're just concatenating strings and so like it's absolutely true that if you have have a templating language and you have a compiler you can optimize things a lot more aggressively than than if you're using virtual Dom and I don't think we've really fully explored what can be done in that world yet I think react compiler is by far the most sophisticated compiler of any front end framework but the ceiling on what it's going to be able to achieve I think is lower than the ceiling on what um template based Frameworks are are going to be able to achieve um and it's really on us to to to make that case like we haven't we haven't done enough of it yet in fact we were talking about it among the team just today the opportunities that we have for doing sort of cross component compilation and understanding how the different parts of your outfit together in a way that allows you to generate super optimal code um and yeah I I agree that is that is that a part of spel five is that like or is that like a spel six it's uh maybe like a like a five pointx we don't we don't know at this point like we're we're just we're just spitballing um I I guess it's a longwind way of saying that that Ben's right like if if you are using virtual Dom then you get a ton of benefits from that like virtual Dom is this actually pretty phenomenal idea that you UI is just a value that you can pass around like anything else in JavaScript like that is a a deep profound idea and it's what makes rsc's possible but it also has some some significant real world drawbacks yeah it's and honestly like one of the things that um a lot of people are fighting against too that are working on the templated B the template based Frameworks that if kind of kept them behind is like the backwards compatibility thing right like um I know that mishko was tremendously frustrated by the things he wanted to do with with angular but could not do because you know you'd break thousands and thousands of things of Google alone like if he was just to be like okay we're going to change this but like you know quick is more like all right well if I have this template and I have this code I can look at it and I can deterministically say okay the HTML is looks like this and these Dom elements have are dependent on this state which is dependent on this state you get this whole dependency graph of everything and you can literally publish like here's the HML file and here's the minimal JavaScript required to see the first thing in the page and as you scroll in we can you know asynchronously load the other stuff because you can get a dependency graph of everything what you're rendering why you're rendering it whether it's static you know what the data sources are from it like what like all of that stuff and you that's where that resum ababil quick stuff comes in and and I don't know that quick is really the answer I just know it's the first one I've seen that had the opportunity to try to leverage that as hard as possible because everybody else that was working in template land is evolving but has to do you know backwards compatibility and that's that's a rough thing when you've got millions of users it's a rough thing when you've got less than millions of users like we have the hardest parts of building spelt 5 has been preserving spelt for compatibility if I'm honest because there is some behavior in there that is like to replicate with an entirely new code base it's a ground up rewrite where the internal mechanics are very different like it's tough and I think we've pulled it off I think people are going to be pleasantly surprised at how easy it is to upgrade but like it's not it's not a task that I would wish on anyone yeah that was that was the angular compiler thing too it was a ground up rewrite but you had to have backwards compatibility with the other the old angular angular compiler and it would have took years for them to get that done so I don't want to let us leave before Rich tell us so let's say for the folks out there who have used spelt 4 and love it um why should be excited about SP five like what are you guys improving everything everything about it is is is better it's more robust it's more reliable it's smaller it's faster um it's more flexible it's more composable um it's it's just easy like you will end up writing less code with spel five than you did with spel four and it's just going to feel nicer it's gonna I don't know um it's got fine grained Universal reactivity spelt is no longer restricted to your your spelt components you can declare reactive State inside. JS andelt dots modules which is super cool um all of the things that people liked about spel 3 and four um are still there like all of the the motion Primitives like transitions scope CSS super fast server side rendering like we have an application framework that du Tails really elegantly with the component framework like all of these things continue to be true but it's just a better version of what I had before and for the people who looked at the compiler output of spel in the past and said this looks really confusing and wonky and also if I have a lot of these components it's going to end up being a larger bundle than if I just used a bigger framework in the first place that's no longer true because the compiled output is so much leaner oh so on every Dimension it's just it's just better did you ship your op code RFC or is this just different optimizations no no no so um we we started um rebuilding spel at the peak of the signals hype and um we're we're very happy that we did because it's it means that the code that the compiler generates is like really easy to read and we don't need to generate a lot of code at all um because signals give you so much for free and our implementation of signals is um is is pretty it's very efficient it's very memory efficient it's very performant um because we're as a compiler we're able to make design choices that are difficult for other Frameworks to make um and so no the thing that you're referring to is it it was sort of an internal design document that we battered around for a little while before we really settled on signals as being the Primitive to use for spels reactivity if it was not public I'm sorry if I shouldn't have said that we can edit it out no no it's it's fine it's um it was an interesting idea that I think would have not been as successful as uh as signals well I I I I can't remember actually when like how did people take to single you know we we we're talking about how kind of vercel and or the framework generally right next as the framework is is kind of like leading the way for RSC or or this like new way of thinking as suppose and you know you're you're saying Rich that you have a lot of Sympathy for the team because you know to innovate you kind of need to put things out there and you know be the first to do it and you know be the first to kind of have a shift in mindset I suppose right in terms of you know pushing an industry forward but signals did we have those complaints too because I feel like I just blinked one day and it was like o signals and then all of a sudden everything signals and then like you know that I I don't remember who like this this slide has been talked about so much where you know everybody has signals except for react like kind of a joke right but like with signals and you're like you know you're you you kind of did the same thing in my opinion when you started to use that but like what was the I guess like why or how did that kind of come about or you know why do you feel like that was kind of the way to go and I mean that really I feel like pushed everyone else forward yeah I mean so that they're not like they're not a new idea they've been around for at least since knockout was around which was what 2008 I think yeah they they called them observables then they they called them observables yeah and it was that was the first framework that I saw that had this idea of implicit dependency tracking where if you run a function and you read an observable inside that function then there a link is created between those two things so that when the observable changes the function executes again um super nice idea but like the ergonomics weren't so great like because knockout was in a different era we didn't have the technology that we have at our disposal now and so even though it had this super elegant implementation the actual ergonomics weren't quite so nice and so I think that and that sort of era in general of you know observable backbone models with like Pub sub and all of that stuff people just got a little bit wary of that whole like design space and then react came along and all of a sudden like you're you're just dealing with normal JavaScript values and you're just re-rendering everything to work around the fact that you're just dealing with normal normal JavaScript values and people just preferred the ergonomics of that and so I think the idea of signals took a little bit of a back seat Vue had had this idea um when V3 came out like signals were they didn't call it that but um signals were were were part of how view3 came about and then it was really Ryan carado on the solid team who did the the necessary evangelism to say to people hey this is this is actually the way that we should be doing this stuff and here's why and did a lot of work to explain all of the the details of how you implement this stuff all of the pitfalls like the the performance characteristics of of different approaches and I think that was the the impetus for a lot of framework teams to be like actually you know what maybe maybe that makes sense and we were one of the later Frameworks to do it because we hadn't yet seen a way that we could use signals but get the ergonomics that we wanted because we have some opinions about what it should feel like to write components and it wasn't until you know middle of last year that we really started to to to see a vision for what like the marriage of spelts ergonomics and the flexib ility and performance that you get with signals could look like um and and now I think I think we've pretty much figured it out and we're super happy with where we landed but it just just took a long time for these ideas to to start to come into Focus yeah it's so funny because perception is everything right like it's like yeah spelt is always at the Forefront of everything so they were yeah they were one of the first to implement signals it's kind of you know memory in my opinion right like it's just what you believe you know yeah we we're actually one of the more conservative Frameworks honestly um we have a reputation for being like this sort of innovative Scrappy thing but we're we're definitely one of the slower moving Frameworks when it comes to design not because like we we don't have development velocity but just because we we're very picky about what we build and so it's taken us a long time to to together I have this uh I have this prediction about signals which do do you remember remember when um hooks came out everybody's really excited and then like a year later there was this big backlash with for for react hooks where people are like oh my God use effect is this horrifying thing and every single time you see it you should do it you can to remove it because people are doing bad things with it I have this is my prediction my prediction is in the next couple years you're going to see people doing that with computed signals like you're GNA be there's gonna be all these talks of like don't do side effects in this thing like here's this pattern that we see all the time or like or like yeah this is you did this computed thing that you could have calculated in the event and it was just adding numbers but now you're you know you're incurring all this extra logic and dependency graph crap because you just wanted to add two numbers together like there's going to be I don't know that's my my prediction is that um because there's such a there's there's fortunately a very small um a very small API space or surface area for people to use um anything in my experience as thek anything where you hand a user the ability to like pass a function they're going to be like I can do whatever because it's a function and um if they don't understand things underneath it which they won't bother to learn they won't bother to learn about dependency graphs or whether or not it's memorizing things or how it's diffing the the changes like they won't bother to learn any of that they'll just be like this is a pattern I saw and and I don't this my my prediction is there's going to be not as big as it was with use effect but there's going to be a bunch of talks at conferences about like try not to use computed properties unless you have to this is this is a a great opportunity for me to talk about some of the design decisions in spel five because we've thought about this a lot as you might imagine um so for context the way that you declare a piece of reactive state in Sal five is with a thing called a rune um so you you know might have a a count which is just a number you count equals and then you call Dollar state with your initial value so count let count equals dollar state zero and then you might have a piece of derived state or a computed um depending on the terminology that you prefer and as as you say like typically the way that you would do that in a signal based framework is you call a function like create computed or something like that and then you pass in a function which Returns the the derived value and we don't do that we do uh we have a a derived Rune in which you just pass the expression directly so if you had you know if you wanted to double that count you do let double equals dollar derived and then inside the parentheses you just do count times two you're not doing open parentheses Arrow count times two you're not passing a function and you're just passing in the expression and the motivation for that apart from the ergonomics just being a little bit nicer is that there's no place to do side effects there if it's just an expression obviously you could call a function which could have those side effects but if it's just an expression then you are discouraged from from doing that and the other nice thing that we can do is because we're not calling a function like create computed we're actually just giving the compiler the information that oh this is a thing that should be recalculated when these things change the compiler can look at that and in some some cases say you know what it wouldn't make sense for us to actually create a derived out of this we can just transplant that expression to wherever it's being used inside this component and then you're not adding anything to the dity graph you're not doing that extra work you're not creating any extra memory usage you're just using it as a hint to the compiler for the compiler to do the right thing do you have um do you have like a a DSL for dealing with lists or nested lists of things in in those kind of in those derived State scenarios because I know that's the one of the more difficult things or one of the reasons would even lean on a computed property is if I had some big list that I'm like oh crap did this change I have to do some calculations over it and either reduce it down to something or you know make a new list um and that's always that's been a difficult thing for a long time for people developing things like mobex and you know whatever that do these same sorts of paradigms it like if you've if you're not allowing functions in there um I would just be curious how you're G to you're going to handle that those scenarios well we we have so in addition to the dollar derived Rune we have a dollar dot dollar derived. bu Rune which is the variant where you can pass in a function um but that is sort of positioned as an advanced thing for people who have advanced use cases the default is you just use an expression what do you call it uh it so if you go to sp-5 preview. the.app um you can see all of the documentation about the new stuff um there's a page on there detailing the runes the one that we're talking about is derived um so the way that you use it is dollar derived and then put the expression inside the parentheses so it look the alternate version that takes a function what do you call that one that is uh Dollar derived. by ah okay so it's a helper on the derived yeah yeah I feel like the the use cases for computed signals are usually like the best use case is probably like oh I need to create an object because I'm doing some referential check on it later and I want to make sure it doesn't change if the inputs to it don't change like that's one um and then the other one is the oh like I just got a huge list of crap and I need to calculate a bunch of stuff off of it um and or I need to make another list and those those things are um like I if I was reviewing code and someone was like adding two numbers what you do and stop it like computers are very good at adding numbers you didn't need to memorize that one but pretty sure this is public I've heard people talk about using classes with spelt 5 but I love the way that the API wound up for the exactly the fine grain reactivity that you said then I forget the details but if you just slam an object literal into these into whatever Rune it is everything is reactive but you can get property level fine grain reactivity by using a class and annotating it somehow I forget the details but it's a really elegant like escape hatch where you can do a little more work and get property level fine grain reactivity like we used to have with mobx yeah that's great that's great yeah we really like classes I think classes get an unnecessarily bad rap in JavaScript it's so dumb yeah it's weird there was like it was fashionable a few years ago for you know the thought leader RTI to talk about classes as as being a thing that you should avoid in your code base and it's absolute bollocks classes are great that's so funny I remember when J Phelps I I went over to his house one day and he like here's how you do functional compos and this was like before it was introduced into react and it was like you do this and this and this and this is why it's better and I was like why does anybody need classes then and so it was always my opinion that like classes are awful because you know Jay Phelps told me that that was the way classes are fine they're fine I I do I do wish there was like a sealed keyword because like my one of the experien I had when I was working at the angular team is like all of their components are class-based and what people ended up doing even inside of Google they would be like all right here's a component that's a class and by the way I'm gonna subass this and do some other stuff and then I'm gonna subass that and do some other stuff decorators on properties that like you the mental math around like writing the compiler to figure out what this thing cared about because now there's a dependency graph between these these uh components that you you compiled that are from different classes and different files it was not amazing it was not my favorite thing in the world so yeah but like okay so rich when do we um I we're we're at time I'm sorry I'm sorry I cut you off Ben U but we're at time so when do we find out more about like when spelt 5 coming out what do we I'm not going to announce a release date we're we're not there yet um we're on the Glide path like we we're starting to work on the documentation and all those sorts of things um but as for stable release I can't I can't commit to a date but you can use it today like people are even using it in production it's on mpm spel at next and the documentation for the the new stuff is on the site that I mentioned before sp-5 preview. Vel app people can play around with it and get a feel for it um it works in salt kit our application framework um it's that one of the options when you create a new spel kit app is to use spel five um so yeah give it a try cool okay dessert I decided what dessert is going to be what is your favorite pairing with cheese more cheese I'll take that as an answer what about you Adam do you eat cheese I love cheese uh nuts I think nuts okay okay Ben I'm still chuckling because uh rich with his accent sounded a little bit like [Laughter] Wallace yeah yeah that's that's pretty good Wallace and grommet yeah I love Wallace and grommet I love it too it's fantastic um and you know what I like to eat with with cheese honestly is like grapes or or apples um usually so yeah yeah I like grapes too grapes pretz but like the flat pretzels pretzel crisp I've been eating a lot of that lately I've been eating the what did you call it rich the common man's cheese cheddar eating a lot of cheddar yeah gasex that's a good thing to pair with cheese another ice cream you could you put pair some you could do cheese ice cream that'd be kind of delicious philippin people they make cheese bread and they put sugar and cheese on top that be a piece of bread yeah yeah so anyways well thank you so much for coming and hanging out with us rich uh we really appreciate it and um you know you can follow rich on Twitter Rich Harris and um you can follow Ben on Ben Ben on Ben follow Ben on Ben Ben lash um you can follow me on Twitter at lady Le and of course Adam on Twitter at Adam Rus so thanks every for listening and we'll see you next time sometimes it's hard to bridge the gap between business objectives and Tech implementation and it can get messy this do is trusted by top names like meta Google and T-Mobile and they love helping Business Leaders fulfill their strategic digital initiatives check them out at this do. one more time that's th do.

Channel: This Dot Media

Views: 3,208

Keywords:

Id: QTJtR8IUsQM

Length: 45min 15sec (2715 seconds)

Published: Wed Jun 19 2024