Speaker 1: How'd you like to listen to dot net rocks with
Speaker 1: no ads? Easy? Become a patron for just five dollars
Speaker 1: a month. You get access to a private RSS feed
Speaker 1: where all the shows have no ads. Twenty dollars a month.
Speaker 1: We'll get you that and a special dot net Rocks
Speaker 1: patron mug. Sign up now at Patreon dot dot NetRocks
Speaker 1: dot com. Hey guess what, it's dot net rocks all
Speaker 1: over again. I'm Carl Franklin at Amateur Campbell and H Richard.
Speaker 1: You're still in Canada? A, yeah, yeah, it's nice here.
Speaker 1: Yeah cool. That's all I'm gonna say about that. We
Speaker 1: love Canada.
Speaker 2: Well.
Speaker 1: Before we get into better no framework, let's just talk
Speaker 1: a little bit about nineteen forty. Kind of an important year.
Speaker 1: Episode nineteen forty, Episode nineteen forty. So the year nineteen
Speaker 1: forty saw the beginning of World War two's escalation anyway,
Speaker 1: the signing of the Selective Training and Service Act, which
Speaker 1: established the first peacetime draft in the US, and the
Speaker 1: release of Disney's animated film Fantasia Nice. Additionally, the US
Speaker 1: made agreements to transfer destroyers to Great Britain in exchange
Speaker 1: for military base leases. As you do you have anything
Speaker 1: to add? I mean, a lot of stuff happened in
Speaker 1: nineteen forty A lot.
Speaker 2: Of stuff happened. But you know, my personal favorite would
Speaker 2: be the Jeep. Oh yeah, Yeah. The US realized it
Speaker 2: needed a lightweight, recon vehicle, something they could be all terrain,
Speaker 2: and they put out or bids basically to car companies
Speaker 2: in the US. Everybody scrambled around. It's a crazy story
Speaker 2: that this little car company called the Bantam Car, a
Speaker 2: motor car company in Pennsylvania, hired a guy from Detroit
Speaker 2: named Carl Probst who in a week basically designed that
Speaker 2: the prototype of the Jeep.
Speaker 1: That's longer than it took them to create JavaScript, which
Speaker 1: I believe wasn't a week.
Speaker 2: This was a car anyway. Yeah, at the beginning of
Speaker 2: the Jeep comes with a part of the World War Two.
Speaker 1: And you know, I know this little factoid about Jeep.
Speaker 1: I don't remember the character's name, but there was a
Speaker 1: character on the cartoon Popeye, right that's related to the Jeep.
Speaker 1: And it was a character. All right, I'm gonna have
Speaker 1: to since you got Eugene the Jeep, Yeah, that's it,
Speaker 1: Eugene the Jeep. And it was all right, I don't
Speaker 1: know as much.
Speaker 2: As you said. Jeep jeep.
Speaker 1: Yeah, he used to say jeep, jeep jeep.
Speaker 2: Yeah. Yeah, yellow weird yellow critter.
Speaker 1: I'm one of them. Started the other like it might
Speaker 1: have been that critter that named the jeep, or it
Speaker 1: might have been the jeep that inspired the cartoon character.
Speaker 1: I can't remember which it is.
Speaker 2: But yeah, jeep. It was a perversion of an acronym
Speaker 2: for a general purpose vehicle.
Speaker 1: Okay, so it comes through with the facts. Yeah, okay,
Speaker 1: Well let's get into better no framework, this is a
Speaker 1: good one. Roll the music, what you got. It's an
Speaker 1: article in the Verge. There's lots of articles around it.
Speaker 1: But this is where I learned about a new way
Speaker 1: of capturing three D content called Gauschian splatting.
Speaker 2: Because we always trust a technology called plastic slatting.
Speaker 1: Yes, so the the whole idea between Gauchian splatting is
Speaker 1: rather than let me see if I can just sort
Speaker 1: of you know, nail it down the ideas instead of
Speaker 1: doing sort of vectorizing and turning things into triangles, and
Speaker 1: the more triangles you have, the better resolution you have.
Speaker 1: This sort of of creates well, you know, a Gaussian
Speaker 1: blurring is right. Yeah, so it creates these sort of
Speaker 1: blurry things that compound on top of each other and
Speaker 1: make up a more realistic looking three D image. But
Speaker 1: here's the cool part about splatting is that you can
Speaker 1: do it in real time. It can render in real
Speaker 1: time at one hundred frames a second.
Speaker 2: Computationally efficient would be a way to say it, as
Speaker 2: well as being small.
Speaker 1: Very computationally efficient. Yeah, so I can see this coming
Speaker 1: to all the major tools. There are tools that you
Speaker 1: can use now, but they're sort of add ins, and
Speaker 1: it'll become more mainstream. But I think it's really really cool.
Speaker 1: It's going to make for some amazing games and some
Speaker 1: amazing three D experiences. Just the whole idea of going
Speaker 1: out with a camera, taking some video or taking pictures
Speaker 1: and then stitching them together and creating a three D
Speaker 1: model of that. Now that can be pretty much in
Speaker 1: real time.
Speaker 2: Yeah, it's interesting, very cool. We're getting to you know,
Speaker 2: what's cool is what we've been able to do. This
Speaker 2: is just computationally intensive. This is clever tricks to reduce
Speaker 2: the number of bits that need to be hauled around
Speaker 2: to get the same similar results.
Speaker 1: Anyway, maybe not exactly, so I think it's a kind
Speaker 1: of a breakthrough. So that's what I got. Who's talking
Speaker 1: to us today? Richard grabbed a comment of a show
Speaker 1: nineteen thirty five. Just a few weeks ago, we talked
Speaker 1: to Nathan Westfall about his app that he might the
Speaker 1: mobile app he was working on that migrated from Reforms
Speaker 1: to Blazer. This comment for Rob King, I thought was
Speaker 1: relevant to what we were talking about today, where I
Speaker 1: said where he says, I've been doing small stuff in
Speaker 1: Blazer since not at five and late twenty twenty three,
Speaker 1: we had the opportunity to build a greenfield app with
Speaker 1: a tight deadline. While Nathan's app sounds a bit more
Speaker 1: complex than ours, a lot of his reasons and decisions
Speaker 1: around Blazer resonated with our thoughts and considerations. I build
Speaker 1: Blazer using all the hosting models, but I still to
Speaker 1: fall to WASM for its clean separation of client server responsibilities.
Speaker 1: If I can do everything in the browser that reacted
Speaker 1: anger can do, but can write it the same language
Speaker 1: as a back end, why would it choose anything else?
Speaker 1: Why would you?
Speaker 2: Well? And the argumator for a reactor course is if
Speaker 2: I can write everything in JavaScript front end and back end.
Speaker 2: Why wouldn't choose anything else?
Speaker 1: Absolutely? I guess it all depends on what your skill
Speaker 1: set is. And yeah, you know what's your language of choice?
Speaker 2: Too sweet? How are you happy? Absolutely so, Rob, Thank
Speaker 2: you so much for your comment. And the copy of
Speaker 2: music coby is on its way to you. And if
Speaker 2: you'd like a copy of music Cobey, I write a
Speaker 2: comment on the website attrocks dot com or on the facebooks.
Speaker 2: We publish every show there and if you comment there
Speaker 2: and I read in the show, we'll send you a
Speaker 2: copy of music Cope.
Speaker 1: Music to Code Buy has a new episode track. I
Speaker 1: guess we call them let me say that again, Yeah,
Speaker 1: the tracks all right, Music code by has a new
Speaker 1: track track number twenty two. You can go get it
Speaker 1: or download the whole thing as MP three's waves or
Speaker 1: flax and that is it music to code dot net
Speaker 1: flat awesome not half flat flat flag. So yeah, And
Speaker 1: you can also find us on the social media's which
Speaker 1: include ex Twitter, Mastadon and Blue Sky and where some
Speaker 1: you know some version of at Carl Franklin, at Rich Campbell.
Speaker 2: Okay, yep, across the wall.
Speaker 1: So let's bring back Aurora Aurora Sharf She was Aurora
Speaker 1: Wohlberg last time we talked. She's a software developer and
Speaker 1: Microsoft MVP from Norway. Aurora began her career at a
Speaker 1: financial technology startup and now serves as consultant at Crayon Consulting.
Speaker 1: She focuses on web development and has extensive expertise in
Speaker 1: React and next dot JS and active use of React
Speaker 1: server components. She shares her knowledge through workshops, technical blog posts,
Speaker 1: social media, demo apps, and supporting fellow developers, and she
Speaker 1: regularly presents internationally at recognized conferences to contribute to the
Speaker 1: global developer community. Welcome back, Aurora, Hi.
Speaker 3: Thank you for having me back. Get to see you guys, singin.
Speaker 2: That's normally where we hang up is at the various
Speaker 2: conferences we both here in.
Speaker 1: It was so much fun last time, and you've got
Speaker 1: some new stuff to talk about, so why not.
Speaker 3: Yeah, last time I was NBC Portal and it's it's
Speaker 3: different now we're doing it online, but it's fun. Yeah
Speaker 3: this way as well.
Speaker 1: And amazingly everything's working today. Don't chinx it oh far.
Speaker 1: I know lately Riverside has been kind of hostile towards
Speaker 1: people who want to use it as in you can't
Speaker 1: use your microphone or your camera. What are you crazy?
Speaker 2: Yeah, so it's funny how this stuff that works suddenly
Speaker 2: gets cranked here. Yeah, so what's up with React these days?
Speaker 3: There are lots When I was with you guys last
Speaker 3: year year or it was actually was it, yeah, twenty
Speaker 3: three us, the whole cervic component thing was pretty new.
Speaker 3: But since then it's i mean, React nineteen is released.
Speaker 3: We have lots of progression and frameworks that are using
Speaker 3: server components. So yeah, it's a lot more stable and
Speaker 3: developed now. Definitely nice.
Speaker 2: Yeah, so it's grown up a bit. Yeah, we're on
Speaker 2: the nineteenth version of React. That was quick.
Speaker 3: Yep, yep was it? I think it's been four years
Speaker 3: since the eighteen if I'm not mistaken with hooks. Okay, well,
Speaker 3: actually it's been a very long time.
Speaker 2: Well, and I like when you're getting that mature, it
Speaker 2: should slow down, right, Like, I've been kind of disturbed
Speaker 2: at how quickly Angular has been creaking out A version
Speaker 2: or two a year just seems like a bit much
Speaker 2: if you're living in that.
Speaker 1: Ecosystem, especially if they're breaking changes. Yeah, I've what I
Speaker 1: I did take a look at reacts for a while
Speaker 1: and what I liked about it was this sort of
Speaker 1: the fluent composition of it, and it seemed pretty simple
Speaker 1: to create React components, you know, if you do know
Speaker 1: anything about JavaScript, it felt very comfortable. Definitely, What are
Speaker 1: some of your favorite features?
Speaker 3: I love JSX I think just it feels like you're
Speaker 3: just flowing through the development process and creating components that
Speaker 3: you can use across each each other, inside each other,
Speaker 3: past props. I don't know. It feels like a very
Speaker 3: natural model to me from building maintainable apps.
Speaker 2: So what's JSX.
Speaker 3: It's the templating language that is used in React. So
Speaker 3: that's what lets you like do your conditional rendering like
Speaker 3: straight inside your HTML.
Speaker 2: Interesting.
Speaker 1: Yeah, and you can basically create markup like you would
Speaker 1: create a JavaScript variable, right yeah.
Speaker 3: Yeah, it's great, It's really great. And JSX, I mean
Speaker 3: that's been kind of used as a template for a
Speaker 3: lot of other frameworks, like for example, Astro, which is
Speaker 3: a different framework, is using their own sort of JS
Speaker 3: So clearly people like this, right well.
Speaker 1: People have always really liked being able to blend markup
Speaker 1: and code together in easy ways, you know, and sometimes
Speaker 1: not so easy way. It's like I remember I don't
Speaker 1: know if you remember the first ASP active server pages
Speaker 1: where it was yeah, you could have mostly mark up
Speaker 1: with a little code. You could have mostly code with
Speaker 1: a little markup. You could mix and match, and you know,
Speaker 1: it was a big messa.
Speaker 2: Yeah, it always felt like right only stuff like this.
Speaker 2: Stuff's easy to crank out, but boy, it's tough to debug.
Speaker 1: Or consolutely horrible to debug. Yeah, So what's the debugging
Speaker 1: situation with reacting? What tools do you use to do that?
Speaker 3: I mean it's always console log for me, I don't know.
Speaker 3: I think this is like a very It varies from
Speaker 3: person to person.
Speaker 2: But for me, you're so old school.
Speaker 3: Also, long is great, and there's some.
Speaker 1: How many times have you written console log? Got here?
Speaker 3: That's usually log something that's not explaining enough, and then
Speaker 3: I have to go and add it later. So that's
Speaker 3: my problem.
Speaker 2: Yeah, God, here's one thing should never get here is enough?
Speaker 2: Never can't Why are you here? You can't be here?
Speaker 3: But yeah, with typescript, I mean you don't really debug
Speaker 3: that much. I guess it was different before when you're
Speaker 3: using just yeah, yes, but types you don't really end
Speaker 3: up in those where what is happening?
Speaker 1: You know as much in Typescript and JSX play well together,
Speaker 1: do they?
Speaker 3: Yeah? Yeah, I don't know if I could ever code pack.
Speaker 2: Oh wow, but you know, it's an interesting part of
Speaker 2: the tooling is to think in terms of I will
Speaker 2: only do this with these tools together.
Speaker 3: Oh yeah, true.
Speaker 2: So is GSX really part of reactor? It seems like
Speaker 2: a more generalized, you know, way of describing.
Speaker 3: Ah in writing, I'm pretty sure JSX is a reacting Yeah.
Speaker 1: Is a reacting but yeah, it's defined it react dot org.
Speaker 1: Yeah yeah, but.
Speaker 2: It does seem like folks really like it, like it's
Speaker 2: kind of.
Speaker 3: Everywhere looking around for Yeah, yeah.
Speaker 2: Certainly specifically mentioned in the typescript docs too. Is you know,
Speaker 2: do it this way? M hmm, okay, so we uh
Speaker 2: we we're happy with this? Is there is there particular
Speaker 2: features and React nineteen that are important because it been
Speaker 2: this many years, Like what were they holding back on?
Speaker 3: Well? React nineteen is kind of split into this improvement section,
Speaker 3: which is more for upgrading into and whatever it's going
Speaker 3: to help you with your client side apps that you
Speaker 3: already have, and then it's the new features that are
Speaker 3: primarily for the service side of things or integrating the
Speaker 3: server and the client in smooth ways. So that's kind
Speaker 3: of the trend of nineteen. I guess you have improvements
Speaker 3: and then you have new features that work really well
Speaker 3: or are for the service side.
Speaker 2: So it seems to me that nineteen is really the
Speaker 2: version where server components grows up, Like it was an
Speaker 2: add on in eighteen and now it's like, no, this
Speaker 2: is a corporal to what we're doing. You want to
Speaker 2: do service side rendering, you use server components.
Speaker 1: Yeah, and according to the React blog, the biggest feature
Speaker 1: of React nineteen is that it's now stable. Yeah, so
Speaker 1: that's really good.
Speaker 3: Yeah, it took a while, it had a bit of
Speaker 3: it was I mean React coff was in May twenty
Speaker 3: twenty four, which is like the release it was the
Speaker 3: RS well it was the RC, but then it took
Speaker 3: until I think December twenty twenty four before it was
Speaker 3: actually released because of some suspense behavior changing drama that
Speaker 3: they were able to fix in collaboration with the community.
Speaker 1: So yeah, right, what is suspense?
Speaker 2: In some ways, you only know when you get it
Speaker 2: out into the world and different devs beat on it
Speaker 2: and do things too, and you're like, huh, didn't think
Speaker 2: of that.
Speaker 1: So suspense is a feature of components. So you can
Speaker 1: suspend a component, is that it?
Speaker 2: Ah?
Speaker 3: Yeah, so it's you're going to suspend. I don't know
Speaker 3: the exact definition, but you typically to suspend something that's
Speaker 3: not ready yet. So it could be for lazy loading
Speaker 3: or with server components, it would be a servi component
Speaker 3: that's not ready yet.
Speaker 1: Right, so instead of littering your code with boolean flags
Speaker 1: you know, loaded loaded now no really loaded?
Speaker 3: Yeah, suspenses. And the reason suspense is so great is
Speaker 3: because it lets you define this fallback property so that
Speaker 3: you can easily define your skeleton, your eye, all of that.
Speaker 3: And yeah, it's a great pattern.
Speaker 1: Yeah, that's pretty cool. And so I guess it was
Speaker 1: really improved in nineteen.
Speaker 3: Well, it works with server components. It really completes the
Speaker 3: server component model.
Speaker 2: Nice. Yeah, well, what's the fallback position if the server
Speaker 2: component doesn't show up? Like this sounds like a pretty
Speaker 2: tricky problem.
Speaker 3: So, I mean, we didn't really talk about server components
Speaker 3: that much yet. But yeah, when you're waiting, I mean
Speaker 3: don't know, I don't know if you want to go
Speaker 3: back a little bit, sure, Yeah, Well, server components can
Speaker 3: be async, so when they're not ready, when they're still
Speaker 3: running on the server, you can't show them, right, and
Speaker 3: if you don't deal with that, you would be it
Speaker 3: will be like this NPA behavior where you can't go
Speaker 3: to the next page. So what you do is you
Speaker 3: actually suspend or you wrap them with suspense, and then
Speaker 3: you use streaming to stream in that those pieces of
Speaker 3: the tree with that component with a fallback you.
Speaker 1: I so is there a concept of pre rendering?
Speaker 3: Oh? I mean it depends. I mean in a way,
Speaker 3: server components are pre rendered because they're run on the server, right,
Speaker 3: So it's kind of like SSR also, which is also
Speaker 3: surrendering in that sense.
Speaker 1: So while it's rendering, you can't access it, so it's suspended.
Speaker 1: While it's rendering.
Speaker 3: You would want to suspend it, yeah, so that you
Speaker 3: can see something and the user would not be blocked
Speaker 3: from going to your page.
Speaker 1: Well okay, so so you the fallback is what you're
Speaker 1: talking about, like a placeholder placeholder?
Speaker 3: Yeah, placeholder?
Speaker 2: Yeah, right, while you why at least show something while
Speaker 2: you wait to load, or at least say hey, this
Speaker 2: isn't isn't or what if it isn't coming like.
Speaker 1: Right, nope, there's no button yet, or the button is disabled.
Speaker 1: You gotta wait.
Speaker 3: And if you've been on like any any good modern app,
Speaker 3: you'll see lots of skeletons right all over. But if
Speaker 3: they're good, you don't think about them that much. Right,
Speaker 3: it just feels like, Okay, I'm just waiting for this.
Speaker 3: So that's the goal, right. You want it to feel
Speaker 3: like it's.
Speaker 2: It's like a div tag. It's a block that's sort
Speaker 2: of pulsing because it's waiting for something to load, Like
Speaker 2: it gives you a visual indicator that something will happen here,
Speaker 2: it's just not happened yet.
Speaker 3: Okay, so that's definitely there.
Speaker 2: Yeah, we're definitely playing this game of ACYNC all the
Speaker 2: things so that you're not waiting lineally for each piece
Speaker 2: and bits can load as needed. Like it is clever
Speaker 2: that the trick is writing manageable code for that. Like
Speaker 2: that to me is we want all this a Synchristess.
Speaker 2: What we don't want is the debug nightmare of why
Speaker 2: is this not behaving correctly? What happens when it comes
Speaker 2: in a different order, and not having to own any
Speaker 2: of that problem. Okay. So, and when we talked last time,
Speaker 2: server components was brand new, and you did have some
Speaker 2: warnings and stuff for us, so things are generally better. Like,
Speaker 2: what do you see in server components at this point?
Speaker 3: Well, when I started using them, server components were ready
Speaker 3: in that sense, they've been actually, they've been stable since
Speaker 3: I was on the show last time. However, all of
Speaker 3: the APIs that make them more manageable and make them
Speaker 3: work well in apps weren't because those kind of came
Speaker 3: with nineteen, right, So that's what's changed. So now you
Speaker 3: can actually build apps that feel good, not just you know,
Speaker 3: Yankees server components, which was a little bit of the
Speaker 3: vibe you got before because he didn't really know what
Speaker 3: to do with them, how to handle them, how you
Speaker 3: made performance apps, all of these things.
Speaker 2: So it's really the UI side needed to catch up
Speaker 2: with what server components could do for you.
Speaker 3: I think. So. Yeah, And for sure the reacting was
Speaker 3: planning this, but it wasn't really something. The docs weren't ready,
Speaker 3: all of them. You didn't really know what you were
Speaker 3: supposed to do.
Speaker 2: So what are you supposed to do? How do I
Speaker 2: refactor an existing React app to really take advantage of this?
Speaker 2: Like the said, a lot of change.
Speaker 3: It depends on what you mean by this. If you
Speaker 3: mean server components, that's not really an easy thing to do.
Speaker 3: But you can use React nineteen. That's all good. But
Speaker 3: if you want to use server components, you need some
Speaker 3: sort of framework for that.
Speaker 1: Okay, so that's what the async UI and the streaming
Speaker 1: comes in. Does that whole process of suspending rendering does
Speaker 1: that all happen by default? Or do you have to say, hey,
Speaker 1: I want this component, but I want it to be suspended,
Speaker 1: and then say when it's not suspended, like, does it
Speaker 1: just work?
Speaker 3: You have to define it and it's a little bit
Speaker 3: easy to mess it up if you don't know what
Speaker 3: to do yet. I would say yeah. For example, in
Speaker 3: next GS, which is like the most stable cervice component framework,
Speaker 3: you're not really told when something is being awaited and
Speaker 3: you don't have a fallback the way it is right now.
Speaker 3: So you need to kind of learn to look for
Speaker 3: where you're putting your ACYNC code and then define your
Speaker 3: suspense boundaries yourself.
Speaker 1: Is there a good reason for that? It seems like
Speaker 1: plumbing code, but maybe because it doesn't always happen in
Speaker 1: the same way.
Speaker 3: I think it's because, I mean, there's you could say
Speaker 3: that there's use cases where you don't want to have
Speaker 3: a fallback, you want to block the UI before you
Speaker 3: see something. But what next GS is doing right now
Speaker 3: is innovating a lot on this actually, So they have
Speaker 3: this new modes that will give you airs when you're
Speaker 3: not providing fallbacks. So yeah, there's a lot of innovation
Speaker 3: happening on how to make this developer experience also logical better.
Speaker 1: Yeah, falling into the pit of success is a good thing. Yeah,
Speaker 1: so so I guess, yeah, we've got to watch out
Speaker 1: for that. But I'm sure the documentation since it's been
Speaker 1: redone is a lot better about explaining how that works.
Speaker 3: M M.
Speaker 2: Definitely at least helping you with trying to do the
Speaker 2: right things. But it also sounds like you don't just
Speaker 2: retrofit React components server components in You've got to think
Speaker 2: through the way your site works.
Speaker 3: Yeah, and you would migrate to a framework if you're
Speaker 3: not on one. So if you're in a create rect app,
Speaker 3: speaking of create recD app is deprecated now, by the way,
Speaker 3: so you shouldn't be using it before. You should definitely
Speaker 3: not be using it now.
Speaker 1: Can you say what it is? Again?
Speaker 3: So create rerect app was.
Speaker 1: Create rerect apprep.
Speaker 3: It's the probably if you've built a React up that's
Speaker 3: what you've used for like the past years, unless you've
Speaker 3: been following along and you've been using it in the
Speaker 3: in the time, it was like the first what do you.
Speaker 1: Say, like template generator something.
Speaker 3: Template generator, Yeah, for React as a framework, and it
Speaker 3: hasn't been maintained for a long time. And then finally,
Speaker 3: now that React nineteen was released, the community was like,
Speaker 3: we need you guys to deprecate this because new devs
Speaker 3: are still going to fall into this trap of using
Speaker 3: it and it doesn't even work anymore, you know.
Speaker 2: Okay, that's because the whole point we create React app
Speaker 2: was like, it's your instant Hello world. Right, it's really
Speaker 2: boo boo. Here you go running now, tweak it from here.
Speaker 1: Like a visual studio template would mm hmmm. Yeah, So
Speaker 1: is there an alternative one of those or yes?
Speaker 3: So for a long time already you can you would
Speaker 3: use vit, which is like the VIT next generation VI
Speaker 3: the ite Okay, it's not an intuitive pronunciation.
Speaker 1: Okay, VIT dev Yeah, like VITE, only different French for quick.
Speaker 3: I think it's front yep, correct, that's what it is.
Speaker 2: Nice, is it or is it VAT?
Speaker 1: I'm just glancing at the documentation here. Yeah, scaffolding your
Speaker 1: first VITT project or VAT maybe v maybe VAT.
Speaker 3: Yeah, I don't think. Maybe some people know the proper pronunciation, but.
Speaker 2: None of us are French, and being Canadian doesn't count.
Speaker 2: It says on the docks that it's on the docks.
Speaker 2: It says it's pronounced like VAT.
Speaker 3: Okay, okay, then my bad.
Speaker 1: But it looks I mean it's you use NPM and uh,
Speaker 1: it looks pretty simple. And then there's some community templates too.
Speaker 3: Yeah, it's a really great Bungler build tool and it's
Speaker 3: created by the viegis community. I think I might be
Speaker 3: saying some wrong thing. Sorry, that's not are already, that's
Speaker 3: not entirely correct here. But it's been like ever since
Speaker 3: maybe twenty twenty already, it's been like the default way
Speaker 3: you should be creating a react at, but it hasn't
Speaker 3: been communicated that clearly that this is the way we
Speaker 3: do it now.
Speaker 2: Nice. Yeah, it seems the relations between invite and views
Speaker 2: or VAT and view is also VAT and react, which
Speaker 2: is interesting. You keep wanting to paint these different stacks
Speaker 2: as rivals and then they go and collaborate on tooling
Speaker 2: and using the same thing. It's like, listen, not that
Speaker 2: big of a rival really, So wait, you can use
Speaker 2: VAT with view.
Speaker 3: Yeah, and actually it can be used with like a
Speaker 3: lot of things. And actually many of the newer generation
Speaker 3: meta frameworks, like like Reactor out of v seven has
Speaker 3: migrated to VEAT, So it's it's already like very big
Speaker 3: in the framework world.
Speaker 1: Wow.
Speaker 2: Interesting, Yeah, it works with Angular, works with Yeah. It
Speaker 2: seems like a front end to a build system, right,
Speaker 2: whatever you want to build. That's really interesting, very cool.
Speaker 2: I'll make I'll make your life easier. Here you go.
Speaker 1: So this seems like a good time for a break.
Speaker 1: We'll be right back after these very important messages. Stick around.
Speaker 1: You know. Dot net six has officially reached the end
Speaker 1: of support and now is the time to upgrade. Dot
Speaker 1: Net eight is well supported on aws. Learn more at
Speaker 1: aws dot Amazon dot com, slash dot net. And we're back.
Speaker 1: It's dot net rocks. I'm Carl Franklin. That's Richard Campbell. Hey,
Speaker 1: we're talking to our friend or Sharf about React and
Speaker 1: React server components and next JS. So what's the difference
Speaker 1: between NEXTJS and other frameworks. Major difference in terms of
Speaker 1: how you use them.
Speaker 3: So next gs is, I mean server components were developed
Speaker 3: together with NEXTGS and nextgs is. Implementation of them is
Speaker 3: sort of reacts idea of how they're supposed to be used, okay,
Speaker 3: architecture Okay, but that's not the only way you can
Speaker 3: use them. But in server components next you as server
Speaker 3: components are everything is default server. So it's like server first, right,
Speaker 3: which is why it's also like this entirely new mental
Speaker 3: model for React developers.
Speaker 1: Server first, meaning before you do any UI, you create
Speaker 1: your server and you build out your UI from that.
Speaker 3: Yeah, you're starting on the server, and you opt in
Speaker 3: to the client whenever you need client features, okay.
Speaker 2: Because who wants clients?
Speaker 1: Honestly, Well, I guess what I'm getting at is I
Speaker 1: can see like the server first being analogous to like
Speaker 1: Blazer server, where you have your markup and your code
Speaker 1: and it all just sort of munges together and goes
Speaker 1: down to the client. Whereas you know, the traditional model
Speaker 1: is you build an HTML file and you have some JavaScript,
Speaker 1: You call the JavaScript to go to the server to
Speaker 1: get some data, and then you bring it back into
Speaker 1: the client. So with the next server first approach, you're
Speaker 1: basically doing everything from the server. You're not building an
Speaker 1: HTML file on the client and then going and making
Speaker 1: calls to a server, right, yeah, the service the server
Speaker 1: supplies the markup.
Speaker 3: Everything starts from the server, and you will also be
Speaker 3: fetching your data on the server and then you rather
Speaker 3: pass it down if it needs to be available inside
Speaker 3: something we call client components, right, which is and that's.
Speaker 1: Also safe, Yeah, safer, because why are you exposing APIs
Speaker 1: that require authorisation to a client browser.
Speaker 3: Don't do that.
Speaker 1: Yeah, don't do that. That's not good.
Speaker 2: It's not that. Stop that.
Speaker 1: Stop that. But that's how it was done for the
Speaker 1: longest time, right, Oh yeah, for.
Speaker 3: The longest time, you would always have some sort of
Speaker 3: API in between your your client site React up because
Speaker 3: you had to write.
Speaker 2: Yeah right, yeah, what was the typical React back end
Speaker 2: piece you would use before we got the server components?
Speaker 3: Well, for well, I work at a consultancy and we're
Speaker 3: still like some a lot of projects are still using
Speaker 3: this old stack. You could say it's still relevant, but
Speaker 3: that would be like React SPA with EAT and then
Speaker 3: maybe done it WEBPI is something like that. That's like
Speaker 3: the typical I.
Speaker 2: Was thinking of remix or.
Speaker 3: Well remix is also a meta framework, so they can
Speaker 3: also do their own data fetching if they want to.
Speaker 2: Right Like, it's just like next is the latest version.
Speaker 2: But there were other solutions to the SPA approach of React.
Speaker 2: This seems less spash, like you're basically asking the server
Speaker 2: to send you mark out.
Speaker 3: Yeah, and that's why it's a big mental shift because
Speaker 3: it is way less spish, it's more it's more Yeah,
Speaker 3: it's it's serve first. It's not really a SPA until
Speaker 3: you make it a SPA.
Speaker 1: Right to me, it's analogous to Blazer server, you know,
Speaker 1: where the server just generates everything, the markup, the data, everything.
Speaker 1: So there's no you know, code that needs to run
Speaker 1: in the browser per se, unless there's something specific that
Speaker 1: you have to run.
Speaker 2: Because one of the things we liked about spas was
Speaker 2: then you could have pieces of the page being reloaded
Speaker 2: instead of a DIP and so forth. And I presume
Speaker 2: you can still do that. It's just the original spot
Speaker 2: says I'm going to download a bunch of UI, go
Speaker 2: to the client that then has the code to call
Speaker 2: to different APIs to populate bits on the page. Now
Speaker 2: you're saying just fetch it from the server. Server will
Speaker 2: render what give it what we need to render with,
Speaker 2: and that might include asynchronous pieces to be loaded as well.
Speaker 1: Yep, yep, yeah, that seems really cool.
Speaker 2: I mean I come at this from a scaling perspective,
Speaker 2: so I'm trying to figure out what's more resource intensive
Speaker 2: to the server, you know, recognizing you know, what's the
Speaker 2: server capable of. Although it's a cloud world now, like
Speaker 2: that almost means that, you know, scaling means a different
Speaker 2: thing today.
Speaker 1: It's a button to push a slider.
Speaker 2: It's a slider.
Speaker 3: So when you're doing it on the server at least,
Speaker 3: I mean, you don't have to, as you're saying, download
Speaker 3: the code to fetch the API and get go all
Speaker 3: the way back to you know, communicate with API, give
Speaker 3: it back. You're skipping this like this long travel, I
Speaker 3: guess because you're already just started.
Speaker 2: Yeah, the first page load on a SPA socks. Yeah, right,
Speaker 2: Like that's always the battle the later ones, because you've
Speaker 2: got stuff cash get better. But we got to a
Speaker 2: point where some of our sites where we're literally doing
Speaker 2: a flat rendered page that then backloaded the SPA in
Speaker 2: just so that your first page.
Speaker 3: Was quick oh yeah, but.
Speaker 2: It was literally an orphan page, like it was completely
Speaker 2: different than everything else on the site because it was
Speaker 2: all about get that landing page loaded fast so people
Speaker 2: have a good experience.
Speaker 1: It's the pre rendering thing.
Speaker 2: It's a very convoluted way of thinking. But yeah, you
Speaker 2: could see the I guide me. My brain is immediately
Speaker 2: going to what's that going to mean for server resources?
Speaker 2: It doesn't matter. I can just light up more functions.
Speaker 1: So do you know how much memory per client is
Speaker 1: used in reacts server components about?
Speaker 3: I don't know that, but I do know that when
Speaker 3: you're using the server, Actually it doesn't have to be
Speaker 3: like the server that you're doing your dynamic stuff. It
Speaker 3: can also be in the build So whatever resources you
Speaker 3: that you're talking about here would be for your dynamic data. Right,
Speaker 3: So if you have some sort of static stuff that
Speaker 3: you don't need, so the things that make it a
Speaker 3: dynamic will be like request headers or params or cookies,
Speaker 3: all of that stuff. If a component doesn't use it,
Speaker 3: it doesn't need to be rendered on the serve. It
Speaker 3: can be in the build data.
Speaker 1: That's you know, based on who the client is, right,
Speaker 1: you know.
Speaker 3: Yeah, correct, exactly?
Speaker 1: Yeah, what would call state stateful stuff user state Yeah
Speaker 1: sounds good.
Speaker 2: Yeah, what does this deploy like?
Speaker 1: Like?
Speaker 2: How what am I setting up on the back end here?
Speaker 2: Is this a set of functions in Azure or is
Speaker 2: it a ask to come out in container sets?
Speaker 3: Like?
Speaker 2: What's this the back end? The deploy look like.
Speaker 3: If you have I mean previously I try it with
Speaker 3: app service, but right now our deployment is just no
Speaker 3: j is dockra image and then containerize the application. That
Speaker 3: works great. I think any anything, pretty much anything. And
Speaker 3: it's actually a misconception that a lot of people think
Speaker 3: that you have to use for sell and you don't
Speaker 3: and the Libra robins you have to use Versell, which
Speaker 3: is the versall the creator of NEXTJS right right, Oh, I.
Speaker 1: See, so you can run it and Amazon, you can
Speaker 1: run it in containers and run anywhere.
Speaker 2: Yep, yep, yeah, yeah, there's no reason an the end,
Speaker 2: you just need something that can run node right in
Speaker 2: terms out just about everything and run node.
Speaker 3: Yeah.
Speaker 2: So yeah, you could easily easily rite in a container.
Speaker 1: Is that the only misconception people might have about React
Speaker 1: nineteen and React service components.
Speaker 3: It's definitely a big one. Usually when I'm talking to
Speaker 3: people sometimes they would say, like, what, you're deploying next
Speaker 3: JS on Azure, How are you doing that? I don't.
Speaker 3: I didn't think that's possible. So that's a big one.
Speaker 3: And maybe another big one is about the compiler. So
Speaker 3: it's been like a big thing that React compiler, which
Speaker 3: is a whole other thing, is in React nineteen.
Speaker 1: It's not beta, so there was no compiler before nineteen.
Speaker 3: No compiler is new because it's a server thing. It's
Speaker 3: an Zephyr project. It's not actually it's a client thing.
Speaker 1: Really.
Speaker 3: Yeah, it's like this whole other thing that has not
Speaker 3: really that much to do with server components.
Speaker 1: Interesting, So this is separate from the JavaScript engine in
Speaker 1: the browser. What do we need a compiler on the
Speaker 1: client for?
Speaker 3: So in React, right, you're doing a lot of rerenders
Speaker 3: and React doesn't use signals like some of the other
Speaker 3: frameworks like Angler's got signals now right and solid JS.
Speaker 3: So you're doing necessary rerenders and the compiler is kind
Speaker 3: of here to fix that for you, so that your
Speaker 3: code is memoirs automatically.
Speaker 1: Okay, So is it analogous to just taking messages that
Speaker 1: are like, you know, upload this div with this content
Speaker 1: or you know, change this list of stuff to this
Speaker 1: just in specific components on the page.
Speaker 3: It will I'm actually I'm an expert on the compiler.
Speaker 3: I just know it's a common misconception, but it will
Speaker 3: do your use memmo use callback stuff. Kind of it's
Speaker 3: a different way of doing it, but it will substitute
Speaker 3: whatever extra code you would add to add momorization for you,
Speaker 3: so you don't have to add it. Okay, So skipping
Speaker 3: skipping unnecessary rerenders and caching or memorizing heavy computations, is.
Speaker 1: There still work to do Unreact server components? Is there
Speaker 1: still stuff on your wish list?
Speaker 3: Well, there is a lot of things happening actually still
Speaker 3: because again the next year is implementation is one one approach.
Speaker 3: You have other frameworks that have kind of been emerging
Speaker 3: recently with their own dots on how to deal with
Speaker 3: server components. So maybe you know, well, you know remix, right,
Speaker 3: you said remix Remix has now been or I guess
Speaker 3: renamed or been migrated to Reactor out of v seven
Speaker 3: or did you have you heard of that yet?
Speaker 2: React?
Speaker 1: What seven?
Speaker 3: React router v seven?
Speaker 1: Router v seven So React router is like.
Speaker 3: The biggest React library, right, and Remix is built on
Speaker 3: top of it, same creator. Now it's been merged. This
Speaker 3: is a pretty big deal actually for those millions of
Speaker 3: React apps out there.
Speaker 1: So Remix became React router v seven. Is that what happened? Yeah,
Speaker 1: kind of Yeah, Yeah, everything you love about remix back
Speaker 1: into React router proper. So they're encouraging all Remix v
Speaker 1: two users to upgrade the reactor outer v seven.
Speaker 3: Yeah.
Speaker 1: It says for the majority of the React ecosystem that
Speaker 1: has been around for the last ten years, we believe
Speaker 1: React Router B seven will be the smoothest way to
Speaker 1: bridge the gap between React eighteen and nineteen. Oh that's interesting.
Speaker 1: So if you have React eighteen with remix and you
Speaker 1: want to move to nineteen using React router v seven,
Speaker 1: that's the.
Speaker 2: Way to go.
Speaker 3: Yep. And also going from reactor out of B six
Speaker 3: and kind of incrementally adopting Ahmeda frameworks features, which is
Speaker 3: amazing because that's not always so easy as with if
Speaker 3: you worse to do it with the next ye just
Speaker 3: app router, it's not like that. So it's a pretty
Speaker 3: pretty big deal.
Speaker 1: Yeah, yeah, seems like it.
Speaker 2: Yeah, and definitely feels like the ecosystem trying to consolidate
Speaker 2: into a few more standard approaches. I grabbed a link
Speaker 2: off of Microsoft learned about running next JS since Azure
Speaker 2: static web apps, and it reminds me of things like
Speaker 2: making word Press run on Windows, Like just because you
Speaker 2: can doesn't mean you should.
Speaker 3: I actually encounter someone who had been doing that and
Speaker 3: don't do that. I think they've done this. I don't
Speaker 3: know this, but I think that they have this docks
Speaker 3: on it. But it's not supposed to really be done
Speaker 3: this way. I just remember the person who tried it
Speaker 3: and it was just not something.
Speaker 2: I mean, what is the like you said, it is
Speaker 2: the typical react to play with versll because that's the
Speaker 2: end to end sort of we know it works, all
Speaker 2: the docks exist, Like that's easier. What do you or
Speaker 2: what are the all sort of known good alternatives that
Speaker 2: you're going to get decent support for?
Speaker 3: Alternative for versall or yeah, there's a lot. I know
Speaker 3: a lot of people deploy on netfly cloud flair right
Speaker 3: right in ws Azure, But at least for your own projects,
Speaker 3: versael is just so smooth, right.
Speaker 1: Right, so the experience is smoother just because they own
Speaker 1: the whole stack. Is that the Is that the idea?
Speaker 3: Yeah, but they also support other frameworks, by the way,
Speaker 3: not just but you're.
Speaker 2: Dealing with a with a customer and they are primarily
Speaker 2: an Azure tenant. You want to run this an Azure
Speaker 2: It sounds like the way to go is is containers,
Speaker 2: is Docker.
Speaker 3: That's what we see.
Speaker 2: That's well, that's the well documented strategy deploying React. I
Speaker 2: mean node runs and Azure functions. I just don't that
Speaker 2: I'd want to try and implement it this way because
Speaker 2: it is kind of odd, right, You're going to be
Speaker 2: by yourself if you do this. Yeah, though, just trying
Speaker 2: to get you know, there's always these perfect well you
Speaker 2: could do that, but you'd be all alone if you
Speaker 2: did so.
Speaker 1: Again, when I asked you, what's on your wish list?
Speaker 1: You said what they were doing. That's really great. So
Speaker 1: what's on your actual wish list?
Speaker 3: Well? Actually I got kind of derailed here, but what
Speaker 3: I was going to say was that retch out of
Speaker 3: the seven is also getting server components in a whole
Speaker 3: different way.
Speaker 2: Oh, it's so good thing.
Speaker 3: It depends if you don't like the server first approach. Right, Yeah,
Speaker 3: there's and there's another one. Ten stack Start is thinking
Speaker 3: of server components. So base things are happening right in
Speaker 3: different approaches, not just the server first approach.
Speaker 1: Okay, so I guess this was on your wish list
Speaker 1: and now it's happening.
Speaker 3: I wouldn't. I mean, I already worked with the app
Speaker 3: router for such a long time. I like it. Yeah,
Speaker 3: but I'm I would be happy that there's other ways
Speaker 3: to do it as well.
Speaker 1: Other ways to do it.
Speaker 2: So what we call this the router first approach versus
Speaker 2: the server verst approach.
Speaker 3: It's more like a client first I guess. But you
Speaker 3: can return server components from loaders, right, which is kind
Speaker 3: of yeah.
Speaker 1: So your turn server components and then run them in
Speaker 1: the client.
Speaker 3: Your return it's well you return. It's like returning data,
Speaker 3: but you're actually.
Speaker 1: Returning so it's returning the markup.
Speaker 3: Yeah right, in a way, so.
Speaker 2: The router invokes the server component to write it to.
Speaker 3: You in a way.
Speaker 1: Yeah, it doesn't have the code behind it, but just
Speaker 1: the markup that's the result of running the code.
Speaker 2: Got it. You are sort of client first instance. You're
Speaker 2: loading a router then invokes different server components that send
Speaker 2: down the markup that rents the page.
Speaker 1: So that's different so it's a middleman, and I guess
Speaker 1: that's why the you know, moving from eighteen to nineteen
Speaker 1: is going to be easier with that because you're you've
Speaker 1: already got client centric code calling into the server, so
Speaker 1: you know you're just changing in the middleman.
Speaker 3: So yes, if you were to answer the question how
Speaker 3: do you opt into server components, probably the path would
Speaker 3: be go from your client side app to reactor out
Speaker 3: of you seven, enable the meta framework features, wait for
Speaker 3: server components, return server components. That's kind of the incremental
Speaker 3: way there. If you're not going to prod.
Speaker 2: It strikes me the next JS server components approaches a
Speaker 2: greenfield approach. It's a rethink.
Speaker 1: Yeah, greenfield. Yeah, that's what I was thinking.
Speaker 2: Yeah, where this is much more brown field. Get some
Speaker 2: of those capabilities your existing stuff keeps working here, you
Speaker 2: know you're bridging. Yeah, that's fair.
Speaker 3: That's why it's the big deal.
Speaker 1: Very good.
Speaker 2: Definitely make your life a heck of a lot easier.
Speaker 1: Yeah, it has productivity gone up with V nineteen.
Speaker 3: For you, uh, for me, yeah, because I know how
Speaker 3: to use this stuff. I think if you don't, if
Speaker 3: you didn't catch up to nineteen, it's hard to see
Speaker 3: why you would need the new hooks because some of
Speaker 3: them are useful for clients, but a lot of them
Speaker 3: are for like server they're documented in the next year
Speaker 3: stocks for example, in a certain way, there's not enough
Speaker 3: examples for the client something like that. So I'm definitely productive.
Speaker 3: I see the uses for all the new stuff. And
Speaker 3: also some of the new features like this use hook
Speaker 3: is for server components and cash api is for server companes.
Speaker 3: So there's things that I'm using a lot to improve
Speaker 3: my performance of that building.
Speaker 1: Well, that's great. Yeah, is there anything we haven't covered
Speaker 1: that you want to talk about?
Speaker 3: We have a look here, maybe like like an RC
Speaker 3: one year later. So this was kind of Yeah, I'm
Speaker 3: still using it. I'm still it still works for me,
Speaker 3: you know. But actually the State of React twenty twenty
Speaker 3: four survey says that sixty percent still didn't try it.
Speaker 3: Of the of the response still didn't try server components.
Speaker 3: Interesting and yeah, that's very interesting.
Speaker 1: Yeah, client side programmers like their client side.
Speaker 3: And it's hard to get into right because you cannot
Speaker 3: just opt in right. And also of the some of
Speaker 3: the people that did try it or twenty percent found
Speaker 3: it to be a pain point of the new APIs,
Speaker 3: So it's still not you know, doesn't still have a
Speaker 3: very positive what can you say, vibe around it?
Speaker 2: Do you think it's the ACNC side of things? Like,
Speaker 2: it's just hard to think that way if you're not
Speaker 2: used to it.
Speaker 3: I think it's a big mental shift. It's a learning curve,
Speaker 3: and it's you have to kind of do it on
Speaker 3: your free time if you don't use it at work.
Speaker 3: So it's a very big it's a big jump.
Speaker 1: Yeah. I was going to say there's probably less incentive
Speaker 1: for somebody who's maintaining or working on a project at
Speaker 1: a company YEP that isn't planning to move to service
Speaker 1: side components because it's a big rewrite.
Speaker 2: Well, no customer asks for this, right, Like, this is
Speaker 2: not a customer's like, oh I wish we had server components.
Speaker 2: They don't care, right exactly.
Speaker 1: But a consultant, you know, who's got multiple clients and
Speaker 1: is waiting for the next client to come along and say,
Speaker 1: we need a website. What are we going to do?
Speaker 1: That's when you want to whip out the nineteen server components.
Speaker 3: Yeah, because if you have like this new project, a
Speaker 3: lot of apps are just okay, let's pick next to
Speaker 3: us and someone. Companies even have that as their default
Speaker 3: app stack, right, So it's inevitable that at some point
Speaker 3: you're probably going to encounter it if if your work
Speaker 3: is using it, right, And there's lots of big apps
Speaker 3: like PayPal, New York Public Library, And we have this
Speaker 3: huge e commerce in our electronics sales, will you say
Speaker 3: company in the nordis called Elchap, which is like all
Speaker 3: on at prouder end of our sell and it's a
Speaker 3: big success.
Speaker 2: Story, right, but it's also not something you moved anywhere
Speaker 2: easily much less why Like, what is the business case here?
Speaker 2: Is it? I want our faster website. I want it
Speaker 2: more maintainable, Like what's the thing that customer is going
Speaker 2: to want? They're like, I'm really grad we made that move.
Speaker 3: So e commerce is I mean speed performance? That's always
Speaker 3: been our sales focus or next just focus. That's their
Speaker 3: that's what they're always optimizing for.
Speaker 2: Yeah, so all that psychosis we've always had about time
Speaker 2: to first bite, like how quickly can you get the
Speaker 2: page in front of people so that they don't switch away?
Speaker 2: Everything stays snappy and async is better for that because
Speaker 2: you don't get hung up on the realities of the
Speaker 2: Internet where some packet gets lost and the whole page
Speaker 2: is stalled. Oh, I appreciate that. That's the customer requests,
Speaker 2: can we make it faster? And it's like, yeah, we
Speaker 2: can reengineer it this way.
Speaker 3: Yeah, making it fast, definitely, that's that's easy.
Speaker 4: Pick.
Speaker 2: Yeah, it's just a question of whether it's true. Like
Speaker 2: the great thing about doing a refactor like this is
Speaker 2: you'll leave us alone for three months. It is going
Speaker 2: to take a while.
Speaker 3: Yeah. I think it took like, I don't know many
Speaker 3: months for the l shapre rite and that was from
Speaker 3: Angular actually, so it was like the biggest hall. So
Speaker 3: they rewrote Angular angularly next.
Speaker 2: Woo, there's a case study for you.
Speaker 3: Yeah Angular next Yeah.
Speaker 2: Yeah, oy boy, Yeah, that is a big jump.
Speaker 1: Do the View developers throw stones at you?
Speaker 3: They have their own thing. I think View developers seem
Speaker 3: pretty happy with you, that's my impression.
Speaker 2: Yeah. I don't know.
Speaker 1: We we like to stir up hat in discontent where
Speaker 1: it doesn't exist.
Speaker 2: So yeah, hey, you know what everybody has pain.
Speaker 3: I can tell you. The View developers were very unhappy
Speaker 3: when the React team deprecated create Recked app and did
Speaker 3: not mentioned it as the primary way to replace it,
Speaker 3: but the community changed that. So you had some new
Speaker 3: developers who were a part of that.
Speaker 2: Did they have a different idea of where to go
Speaker 2: besides VAT?
Speaker 3: I mean, for a long time, the framework, the docs
Speaker 3: have said next or frameworks. They've been encouraging frameworks and
Speaker 3: they still do. Yeah, that's just the thing. They encourage frameworks.
Speaker 3: They think that you should use a framework unless you,
Speaker 3: for some reason decide not to. But that shouldn't be
Speaker 3: the default. The default should be a framework. That's what
Speaker 3: the dogs lead you to.
Speaker 2: Right So, and actually most people, like you know, actually
Speaker 2: VATS an easier way to go. It gets me up
Speaker 2: and running.
Speaker 3: In a lot of cases, it could be and that's
Speaker 3: that's the reason for the community to push back.
Speaker 2: That's interesting.
Speaker 1: So react as a Facebook slash meta thing, is there
Speaker 1: any indication that they have moved everything over to nineteen
Speaker 1: or they're going to I mean, I can't imagine going
Speaker 1: from a previous model to that, as you know, as
Speaker 1: big as Facebook.
Speaker 3: Is, I don't know about that exactly if they're using it,
Speaker 3: but I do know that they're using the compiler in
Speaker 3: their internal apps like Instagram, So that's I guess a bigger,
Speaker 3: better metric for what they're actually building that they're using
Speaker 3: for themselves.
Speaker 2: Yeah, well that's always been the claim to fame. Right,
Speaker 2: this is how we build Facebook, so you can use
Speaker 2: it too, Right, if.
Speaker 1: We can if Facebook doesn't crash, europp won't Right.
Speaker 2: Was that great story where they locked themselves out of
Speaker 2: their own data center with some security there's assisted men's
Speaker 2: story about literally they had to take an angle grinder
Speaker 2: to a door to get into a data center because
Speaker 2: somebody had whoa had shut down a key account that
Speaker 2: didn't allow that took out the door controls. Oh my
Speaker 2: fun stories the hardware.
Speaker 1: Well, I guess the door controls weren't that good if
Speaker 1: you could take a saws all to it and cut
Speaker 1: it out.
Speaker 2: Apparently it took a whole day, so I think it
Speaker 2: was pretty good. Like everything will eventually fail if you
Speaker 2: try hard enough. But then I guess you're right. Yeah,
Speaker 2: fort there it's like we can't get into the data center,
Speaker 2: both digitally or physically. Okay, yeah, this looks like a
Speaker 2: big important version. Like you said, four years coming, that's
Speaker 2: a long time in our world.
Speaker 3: Yep, there's stuff for everyone. If you didn't like check
Speaker 3: it out yet you should, especially the improvement section even
Speaker 3: if you're a client set up. There's like a lot
Speaker 3: of things there that you might need, like pre loading
Speaker 3: CSS or other resources. And there's like acing script support
Speaker 3: with priority hydration air improvements for those of us who
Speaker 3: have experienced that, so you can actually see what is happening. Nice,
Speaker 3: there's a lot air handling out. There's a lot of
Speaker 3: like improvements that actually matter for you even though you're
Speaker 3: not using service components.
Speaker 2: That's good.
Speaker 1: Well, I imagine our listeners will have more questions than
Speaker 1: we do since we're not daily React users. But but
Speaker 1: so this would be great, you know, for to leave
Speaker 1: a comment on the website and you know, if you
Speaker 1: have any questions.
Speaker 2: For Aurora. Yeah, and where can folks find you.
Speaker 3: A XUS food? I'm still there. I works for me
Speaker 3: to communicate with people there, and I have a blog
Speaker 3: if you want to like read stuff. But for communicating
Speaker 3: probably extort Twitter.
Speaker 2: Awesome, very good.
Speaker 1: Well, thanks, it's been great talking to you again.
Speaker 3: Thank you, Thank you for having me back.
Speaker 1: All right, and we'll talk to you next time on
Speaker 1: dot net Bros.
Speaker 4: Dot net Rocks is brought to you by Franklin's Net
Speaker 4: and produced by Pop Studios, a full service audio, video
Speaker 4: and post production facility located physically in New in Connecticut,
Speaker 4: and of course in the cloud online at pwop dot com.
Speaker 4: Visit our website at d O T N E t
Speaker 4: R O c k S dot com for RSS feeds, downloads,
Speaker 4: mobile apps, comments, and access to the full archives going
Speaker 4: back to show number one, recorded in September two thousand
Speaker 4: and two. And make sure you check out our sponsors.
Speaker 4: They keep us in business. Now, go write some code.
Speaker 1: See you next time.
Speaker 2: You got J middle Vans
Speaker 3: And