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