What is the tech stack using Remix look like?
>> Yeah, that's a great question.
Use more than React, right?
>> Yeah totally.
So first on the React piece we will support other frameworks in
the future that is not the case now but yeah Remix will support view,
I'm thinking on the order of months probably maybe weeks.
In the next week or so
we should release the Remix router which is going to enable other frameworks.
In fact there's already experimentation and working experimentation of using
the pre release of the Remix router with view, angular and svelte and pre act.
So that work has already been done getting that into Remix is
the next challenge but the new Remix router has a lot of the really
cool features that we're gonna talk about.
What's cool about Remix itself, is that it handles all the server rendering,
the file-based conventions and all that stuff.
But a lot of the really great DX that you experience with Remix can be used just
with the Remix router and that you could use today.
I mean, it's a pre-release so, beware but yeah, it's pretty basically done.
So as far as other elements of the tech stack because Remix is full stack
you're gonna need some server runtime to run it and
Remix runs everywhere anywhere you can run JavaScript.
Maybe not IoT I don't know because some of those have a small JavaScript environment.
But for any modern JavaScript runtime you can run Remix.
So we even have one running in Bun, we have official support for
Dino and of course, and then Cloudflare workers,
Akamai EdgeWorkers, all of the things wherever you can run JavaScript.
So as far as hosting is concerned, you're everywhere.
And what's cool about that is a lot of people are like,
there's no way we're gonna ship node in production.
And that's fine.
You're probably using Akamai or one of these other CDN so
you can still actually use Remix in those environments.
As far as like database it's really whatever you want it to be.
So at the top here we've got an example of a route module and
this loader function runs on the server and so you can have it hit,
you can have it make a fetch request to another downstream API that you've got.
If I were still at PayPal and I were implementing Remix,
that's what we would do.
We actually wouldn't do fetch requests.
We had like a bunch of modules for accessing different services.
So we just X those access those services in the loader,
as well as in the action for mutating data.
So however you want to do that Remix has no opinion.
Actually Remix we consider to be center stack, so we're in charge
of the network we'll take care of that between the client and the server.
We'll take care of that for you that's actually as it turns out the hardest part
of building web app is managing that Chasm between the client and the server.
So we manage that for you.
And then further downstream on the back end, you're responsible for that stuff.
We do have if you don't wanna make all these decisions, because I remember when I
was making these decisions for my app, it was like I don't do backend stuff.
So I don't know what database to use and or whatever.
So we put together this really cool thing called Remix.
If you go to Remix.run/ stacks, these Remix stacks that come pre configured
with a bunch of tools, a hosting provider, like all of the things that you want.
And what's really cool about this is you can actually make custom Stackins.
So And they're all named after music sub genres because of course they are.
And so there is one.
I think my favorite is the Kpop stack by Netlify.
And that one of course, the poison Netlify uses Super Bass for the database,
just like all the things and just instructions in the read me of how to get
things configured and connected and stuff.
So, yeah, does that answer your question?
Okay, sweet, we're gonna be using the end stack today.
>> Why in general is it not possible to achieve the best UX with static site
generation?
>> Great question. So, because the best UX is accomplished
without, things popping into place like this.
Right.
So if you are building a blog and all it has a static content,
then you're not going to get any different UX whether you serve a render that or
SSG that, and some people are like, hold on a second with SSG.
I can put that on a CDN and so it's gonna be faster, right?
Well, it turns out that for decades now CDNs have been
able to take a server rendered HTML and save it on the CDN.
And so you get effectively the same UX anyway and
then you have way more flexibility if you SSR that.
So SSG will be no better at serving the user than SSR will even for
a completely static site.
And so all that you're left with is okay, well,
what about use cases where you're loading unique data for each user?
And yeah,
you cannot tell me that the site on the left is better than the site on the right.
>> Right, If I have a marketing site built with a headless CMS if there
is no static doesn't it mean calling my CMS for every request?
>> Yeah that's a great question actually what's interesting about that is every
time you make a change to your content.
You're calling your CMS for all the content on your site to rebuild the whole
site, and then you say, no, but next is building ISR or whatever.
Well, they actually just invented stay while revalidate which CDN supported
for years.
So if you truly have a static site,
you can use a CDN between your user and the origin server.
And now you're just hitting the CDN which is exactly what you're doing with SSD.
So again you can do everything from the user experience standpoint,
you can do everything with SSR that you can do with SSD.
And way more.
>> Is there a way to get props at run build time?
>> It is possible to do things that run only at build time that is not
something that's built into Remix.
>> Do each of these child or children segments have their
own loaders Like Sales Overview wouldn't call the loader for invoices.
>> Yes. >> Is it one loader and
it's all fetched on the server already?
>> Yeah, great question.
So each one of these, and we'll talk about this, but
each one of these will have its own loader and they're all called concurrently.
>> For a landing page, how would you deal with SEO?
>> We will sort of talk about that we don't have an exercise on it.
But you will see in a couple of spots in the code where we've got stuff for
SEO, but like the title and the description and OG image and
all that stuff, but yeah, it's all just exports on your route.
What about support for lazy loading of components?
>> Yeah react dot lazy is totally supported and
with streaming you can actually even stream lazy loaded components from
the server well, >> Yeah, it works a little differently
than that but yeah, you can use React lazy with Remix, so lazy loading.
You typically don't need to unless you've got component that's like rendering
some D3 chart and it only shows up when the user changes some state or
something pretty.
Unusual use case but unusual use cases or what we call the world.
And so yeah, that's totally supported but you normally don't need to worry about it
because Remix automatically chunks up each one of your routes anyway.
Can you have multiple forms on one page with his approach?
>> Yes, absolutely.
And we have an exercise for that.
>> What is the benefit of forms?
Is it used instead of fetch and are there benefits that come with it?
Or am I misunderstanding?
Something.
>> Yeah, so benefit of form is the simple mental model,
under the hood the form component that Remix gives you is just doing a fetch.
But what's cool about it is that it gives you a simple mental model to work with.
And we will definitely get into that quite a bit.
>> What's the main difference between Remix and Next.
>> Yeah that's a great question.
We have a blog post that goes into really deep in depth on Remix versus Next and
I can't do it justice in a quick answer here so I would defer to the blog post.
But it really goes deep into the into the difference between Remix and Next.
>> How does Remix handle state management.
>> What is state management?
No just kidding but sort of not I'm gonna to show you that you don't actually
think about state management when you're using Remix.
No Redux, no Apollo, no Mob X, no React Query, no application state management.
>> You will of course need state management for
components that like a drop down or different things like that autocomplete,
so there is still use cases for use state but
yeah you can say goodbye to your application state management libraries,
which is like that's a big deal folks like you.
Probably half of the code that you write if not more,
is related to state management.
You can just take all that and throw it away when you're using Remix.
Your Redux store is the database, this is pretty rad.
>> Can you get end to end type safety working in Remix?
>> Yes, you can.
You will see that today and it is legit.
It is so cool.
Yeah, you're gonna experience that today.
Ryan, you had a question.
>> Is there any scenario where you would not recommend using Remix?
>> Yeah, good question.
No. [LAUGH] So here's here's the thing.
I wouldn't say that Remix is perfectly well suited for
every use case that you can have on the web.
Like, let's say you're building a game, and it's just one page.
There are no routes.
There aren't a lot of use cases like that,
like even games are going to have your user profile and stuff.
You're gonna have routes but let's just say that's what you're doing.
What else are you gonna use?
Is there anything else that would service that use case better?
I don't know what you're probably going to use some libraries and
stuff you can use those with Remix.
Why not sure so that's why I say I can't think of anything that I would use for
any use case for anything that has a URL.
I'm not just talking about UIs,
I would build a web API for a mobile app with Remix.