Back to the Roots With Remix

Rate this content

The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?


- Good understanding of JavaScript or TypeScript

- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications

- Preinstall Node.js, npm

- We prefer to use VSCode, but also cloud IDEs such as codesandbox (other IDEs are also ok)

106 min
13 Jun, 2023

AI Generated Video Summary

Remix is a modern full-stack web framework that works on both the backend and frontend, providing features like database interaction, SEO, data serving, page rendering, and form validation. It implements the unidirectional data flow and supports server-side rendering plus rehydration. Remix provides utilities for backend and frontend integration, with a folder-based routing system and error boundaries. It solves the water flow loading problem by supporting simultaneous data loading for all components. Remix is compared to Next.js, highlighting its better loading time and support for layouts. While Remix is suitable for small to medium-sized projects, other factors like community size and documentation should be considered for large production applications.

1. Introduction to Remix Workshop

Short description:

Welcome to the workshop, Back to the Roots with Remix. Today's workshop is mainly theoretical, but we have prepared a few exercises. We will discuss Remix applications, how the Remix framework works, and the specific problem it solves. We will also introduce ourselves before diving into the content. I'm Alex, a software engineer located in Amsterdam, Netherlands, with experience in front-end and backend development.

So, welcome everyone to the workshop, Back to the Roots with Remix. I'm Alex, here is Pavlik, and we are together today for this workshop slash masterclass. So, today's workshop about Remix, you can expect it would take around half an hour, an hour and half.

And yeah, some of the things that might be interesting to know upfront. So, first of all, let's quickly, I hope you saw this content description of the workshop before, so you know where you are and yeah, maybe have already some questions to ask or maybe some thoughts to share with us. Anyways, so this workshop is mainly theoretical let's say, but we prepared a few exercises and we're going to go with them by the end of today's session.

And that to make them work for you on your local or on the code sandbox, you would not need them much, to be honest. You would need just Node.js environment somehow, either in the cloud or on your local. And yeah, it would be great if you have already some React skills to do that, to make the tasks easier. React and Node.js or Node.js. So yeah, that's just simplification let's say. I guess you have these skills already.

And then the agenda for today is something like that, that you can see on the screen. By the way, the workshop agenda and all materials are available through this link. I will post it in the chat as well for you, to ease opening it. And let's say bookmark it, that would be great. Also there you can find some feedback forms additionally to what Nikolai has said. Anyways, the agenda, we are now in the introduction, that will last not too long, maybe a few more minutes. And then we're going to start doing the real thing. So we're going to talk about Remix applications and how the Remix framework is working. I think that's the main idea. So yeah, the thing is, we're going to discuss Remix, what it is, what this technology consists of, how it works. First, we're going to see some example, and then discuss some specific use case, like where in the rendering history of modern frontend Remix stays and why maybe. And then we're going to talk about how Remix works indeed. Later, we're going to discuss one specific problem that Remix solves, with their framework solution. And we go to the summary, where we basically make some conclusions based on our knowledge. And then we can try to solve some of the tasks that we prepared. But before we do all of that, just quickly about myself, and then public also will introduce himself.

So I'm Alex. I'm a software engineer located in Amsterdam, Netherlands. I primarily started as a JavaScript developer. That was a long, long time ago. I think it was somewhere around 2009, and I was a front-end engineer for quite a while. So it was a really nice time, you know, to see how the JavaScript ecosystem was growing at that time. Basically, I started before jQuery, and then we brought our own jQuery to the project I was working on. Then we switched to jQuery, then XJS framework, then backbone was there. So yeah, many things even before AngularJS. And then AngularJS to Angular 2 React. Yeah. Yeah, it's crazy if you think and look back how that whole thing can develop. Somewhere in between my career paths, I started feeling a little overwhelmed with the front-end, and I decided maybe switch a little bit myself to more backend story. Specifically, I was getting more engagement in doing the tools for developers. So it's something between DevOps and backend. And I joined a company, ING, in the Netherlands. It's a bank. So I was doing there, for quite some time, pipelines for front-end engineers with a very extreme front-end stack, let's say. So it was very cool project to participate in. And later on, nowadays I'm more, let's say, in traditional stack of a backend with Java and with a Ruby. So many things, but I prefer nowadays to use a Golang when it's possible. Still enjoying JavaScript, especially on the backend side of it.

2. Introduction to Pavlik and Remix

Short description:

Pavlik introduces himself as a software developer with experience in both backend and frontend development. He currently works at ING and runs a small development agency called CodeWheel. In his spare time, he discusses technologies like React and uses Remix and serverless for client projects. Remix is a modern full-stack web framework that works on both the backend and frontend, covering all needs without the need for additional rendering libraries. It helps with database interaction, SEO, data serving, page rendering, form validation, and more. Pavlik provides a code example that demonstrates Remix's capabilities.

Sorry for the long, big wording. Pavlik, can you introduce yourself please? Sure, I'm Pavlik. As Alex, I started like years ago, and I started as the primarily, like in the beginning, backend developer. So I was working with Python and PHP, and later on with even Perl a little bit. And then like seven, maybe eight years ago, I switched completely to frontend. Throughout my career, I've worked always with JavaScript I enjoyed JavaScript. And I decided that I can bet on JavaScript in my future. So like, that's how I turned to frontend. And also kept doing some things on the backend with JavaScript. Nowadays, probably I should say more often TypeScript, but I'm still primarily a JavaScript developer. And we met with Alex at ING, back in the day when he was working in the pipeline stuff. And I was using those pipeline stuff to build our frontend stuff. And so I'm still happily working at ING. And that's what I'm doing during the day. And during the night, and sometimes evening, I run a small development agency that's called CodeWheel agency. And in my spare time, apart from all of this, I talk about different technologies like React that I use not at my work, not at ING, at ING we use Web Components, but at home, at home. Remix, when I tried to run a couple of projects for our clients. And serverless, that's what we use also for our clients. You can see some information about me, like on Medium, the stuff that I write, or GitHub, the repositories or contributions that I make here and there. Thanks, Alex.

Yeah, cool. So yeah, we are actually eager to know a little bit about yourself. Maybe the easiest would be to just, yeah, use the Slido. Actually, just one question, so yeah, feel free to scan and answer that. Have you heard about, have you used DreamX before? Maybe if you can drop a few words to the chat, like what's your experience would be also very cool. And, by the way, yeah, any questions that you have during the session feel free to ask straight away, use the chat or just voice, if you prefer that, that's both fine. Um, nice, nice. Thanks, I already see some feedback. Cool. Yeah, and maybe I want more important thing before we start is the repository, you can also find the link, of course, yourself, but just that's gonna be our main repository for today. You can find the resources that we're gonna talk about here and the experiments that we're gonna discuss also here and maybe the most important issues that's supposed to be our practical part today. So we're gonna discuss them in the end of today's session. Alex, can you send this link also to the chat? Yeah, of course. Here we go. Ooh, cool. Thanks for the feedback, by the way. Thanks for your comments. It's very helpful during the session like that. Right, I will repeat also the first link in case someone missed it, maybe yeah, for more resources you can use it. Anyways, so today's about a remix. So that was most of the introduction but one more important part is left, which is what is remix? What are we talking about? Public, can you tell us a little bit about remix for now?

Okay, I'm not sure is it like misspelling that you said, like sell or tell, but I'm going to sell it a little bit, yes. So yeah, like remix is the modern full stack web framework, that means that like full stack, that means that the framework works on the backend and on the frontend and it covers all the needs. So like it helps to interact with the database, it helps to improve your search engine optimization of the website like to serve the data to the client and also on the client side, it helps to like render the page for the client to show it, to do the validation of the forums, to save the data, so everything. Basically remix is the framework is what you can build the entire service, like without any need for any other like libraries instead of some utility or like, of course there are some utility libraries that you can use, like to access the database for example, with the GraphQL, but you don't need any rendering libraries whatsoever to build the entire web service. Here is the tiny example of the code, but it shows like really well, what Remix is. So it starts with some inputs and already you can see that it can import from the node by default or CloudFlare or Deno. So it can also run on so-called edge servers. And then there is a function loader and this function brings the data to your component and like this one gets the gist from GitHub account and gets like the description of the gist, like HTML, blah, blah, blah. So some information about the gists. And then one of the maybe primary part of the component is the default expert and this is regular React component.

3. Remix Rendering Strategies

Short description:

All the data is received and rendered with regular React syntax. Remix is compared to other technologies. Server rendering strategy renders on the backend, while static SSR generates HTML code without running the application. Full client-side rendering is driven by React and Angular. SSR with regeneration generates the skeleton on the backend and signals the front end to continue rendering. CSR with pre-rendering includes techniques like web workers and prefetching.

So all the data is like is received, we are at the special use loader data hook and then this like data is rendered with the regular React syntax and that's basically it. So this is the React or the Remix, however, like we also need to understand where it is like Remix in comparison to other technologies.

So Alex, can you help us with this? Absolutely, I will try. I will try. Yeah, if you open this web page and if you click on the image, you will find the original data, which is rendering on the web article, on the, the Google team durante this article, Eddie Osmany and Jason Miller. So what the guys propose is some specific grouping of rendering strategies in a web, let's say from the beginning to today. And I mean, it's really hard to make a point where it stops. I think these strategies topic is, sort of in transition, it's always moving. And it's a really hard to do this grouping and even to state them like that, it's already a little bit doubtful, but let's try to stay with the authors on that. So it's also not historical line you can see here, but I think some of the parts are very clear.

Let's start from the left, for example, this server rendering strategy is basically rendering on the runtime on the backend. So that means maybe you're familiar with Java in your daily work, and probably remember something like a GSB pages where you could make a template in with the data from backend, and then you integrate this data inside your HTML pages. I like HTML pages. It's a specific syntax of some templater, and then you get this data out to the client. That's the first strategy. I think it was used for a long time, like a main one. Close to it, actually, there is a thing that the authors of the article call a static SSR or Static Server-Side Rendering. Basically, this is how it differs from the previous one is that it generates HTML code for you on a builtin, so you don't have to run your application to generate this code, to generate all the parameters and all the pages of your application. I think it has some limited applications set where it can be applied, right? I mean, if your application depends on the data highly, then it would be almost impossible to generate all the possible flows of this data to the application pages. But we see these examples still in the web and still in the web quite a lot. Maybe you can give us some examples yourself. So I would say to me, these assesses mainly with the old-style web, maybe you can think of specification, you know, pages like EATF, for example, those sorts of articles that I'm driving out of that even today. Is Static SSR, is SSG, Patrick, any opinions on that? I would say so. So I think that's like, the origin of this article was 2019, and then this term was coined like server-side or static-side generation, SSG, what they meant by this static server-side rendering. So it's exactly SSG. Okay. I would say, for me, it was complicated because I didn't know the interpretation of G, but indeed the static server-side generation, that makes a lot of sense. Yeah. So those are two, I think are relatively clear, and then what also is clear are the right side of this picture with our browser full CSR, full client-side rendering strategy. I think that is most known to modern front end, and I hope to you guys as well. Those are things that are primarily driven also by React and by Angular and by many other modern frameworks in the front end. So basically the cold templating and the data retrieving happens on the client-side on essentially on a user browser, and it might have some data pre-loaded but probably it will do some XMLHTTP request, but no, not XMLHTTP request, but a fetch request for API on the client-side and then use this data to render some content to a user. So I think this is a very straightforward part that most of the applications used today, even in article, it says most applications using it, and then we are left with two strategies that are also overviewed in this article, and actually this is the most complicated, the differentiation between them. So first one is SSR with regeneration. So I think of it like, okay, we have these two different angles, so the first one is a poorly search. And then the other one is fully client-side rendering. And the rest of them it's somewhere in between. And at some point, content engineers, they have these wonderful applications driven by React or by Angular, any other framework generated in browser. And then people start looking for how to optimize it. And the first approach that I think React was having for a long time already was called regeneration. It's the approach when you have your application living basically on both sides. You generate part of it on the back end. You generate the skeleton on the back-end side. And then if you can signal, if you can specify to a front end where the front end should pick up the work and continue doing the application for the browser, then it will take probably less time to see the content for it, so to show content for a user and that is a successful application. Yeah, so that's, to me, the regeneration part. And what the CSR with pre-rendering is, I think, it's just a few more nuances to what techniques the SSR and the CSR can use to make this transition for a user better, so that may include some web workers, so maybe some prefetch work. Yeah, maybe actually public knows what to add there. I think definitely you know, public. Yeah, so there is, like, I think you're very, very precise about this separation. So it's very difficult to draw the line to understand where the prehydration ends or, like, a service, and the server site render and client-side rendering interact with each other, so where exactly is client-side rendered already and not server-side rendered with prehydration? So, like, it's just maybe, like, maybe it's the size of the part that is rendered, like, whether it's bigger on the client-side or on the server side.

4. Remix Rendering Approach

Short description:

The rendering happens on the server side and then on the client-side. When fully or partly on the client-side, we can have the state on the client-side, but it's not possible in a fully server-side rendered application. Remix serves something on the server and then renders something on the client side. It supports two different rendering strategies: server-side rendering plus rehydration and fully server-side rendered application.

However, it's not, like, important, is the key part that there is, like, the rendering happens on the server side and then on the client-side instead of fully on the client-side and fully on the server-side. I would also like to add a little bit that, for example, when there is a full server-side rendering happens, the input for, like, everything also is retrieved from the browser navigation bar. So, that's kind of, like, important, and because when we are fully or partly on the client-side, we also can have the state on the client-side. For example, we have Redux or any other state management, and we keep track of our currently-opened page without even changing the route. That's maybe not the best idea, but it is possible when you have a client-side application or, like, something on the client-side, rich client-side application.

However, that is not possible when you have a fully server-side rendered application because the only thing you get from the client is the URL or the navigation bar. So that's the thing that I would like to point out as well. All right. Yeah, indeed. Yeah. So, where the remix stays in this picture? Do we know that, Pavlik? Can you answer that, maybe?

Oh, of course, yes. Let me try to discover this. So, this is a very similar application. It does not have any business purpose whatsoever. It's just purely for the demo purpose. And during this workshop, we will come to this application quite a number of times. So, the idea is very simple. Functionally, we have the list of the movies on the left side. And then we have the details, some details of the movie, in the main part of the page. So we can switch the movies, see different details. So we'll see that the URL is changing. So, it's very simple remix application. Quite very simple. So, the thing that I wanted to show here is like we are still trying to discover what is the rendering approach of remix. So, probably it's like, what is very popular right now is it serves something on the server and then render something on the client side. So indeed, if we refresh the page, we see then like the document. Let me just show the preview. It has some HTML here. So, we need to render something on the server. This is one of the document. And then, it has some remix content. So like this... The information or code that is needed to actually for remix to work in the development mode, but also to load other parts of the application. So, it does the work on the client side, it goes JavaScript for like the movies and the list of the movies for the movie ideas, like for one of the details of the movie. So, that's very similar to what probably is the most popular approach nowadays. So, it render something on the server and then it rehydrates on the client-side. For example, there is another popular framework that does exactly the same, it's NextGen. However, there is a cache here. So, I can comment out one line in this application in this remixed code. What is this line? It's just a scripts component that comes from the remix run React. So, it's like essentially just a scripts component that is rendered somewhere in our application, which is like app function. And now, let's clear our network request. Refresh the page. And now, we don't see any JavaScript request. So, essentially now, remix is churn from the servers like server-side renderer plus rehydration to fully server-side rendered application. So, we still have something remix related like which basically just refreshes the page when we do some changes in the source code, we can validate, okay, Pulp Fiction, show the show the same production. So, it did, it works, it loads different URLs, it loads different movies and we can see that it does not load any JavaScript. So, that comes to the point that remix supports two different rendering strategies. And now, Alex, can you explain, can you help us? How does it, how does it works?

Indeed, I will try to, yeah. So, I hope you can see my screen.

5. Remix Compiler and Server-Side Support

Short description:

Remix is a compiler that transforms code into browser and server-side builds. It analyzes code, handles routes and data, and supports multiple HTTP servers. The server-side supports loaders for retrieving data and actions for sending data to users. React components are transformed into both backend and client parts of the application. The client-side build involves a layer executed on the backend, where data from a loader is fed to a backend-side component. The component is then generated on the server-side and given to the client for hydration and rehydration. Using loaders and actions in code enables data retrieval and updating.

Yes. Cool, yeah, I like this demo by Public and I like it even more when you can actually in Chrome, DevTools, you can disable JavaScript and then without changing any code, you will see same effect basically. Let's see if we can get it, get it somewhere during today's workshop as well.

Anyhow, so how Remix works, how it make it work like that, so how it makes it different strategies, different rendered strategies in the same box and yeah, how it does everything? So if you look at the documentation, by the way we haven't said anything about documentation yet but it's very powerful, maybe one of the most powerful documentation pages that I have seen and it's, yeah, it's basically a piece of art itself but let's say maybe some more words seen by the end of it. So if you look at this documentation here and about different concepts that I described so they explain Remix is first of all, it's a compiler.

The compiler that takes the code that we seen as an example in the beginning here and then it transforms by using the compiler into the browser build and the server side build. So essentially the left part the original code contains some keywords, right? Because remixes we can say it's a framework so you have to follow some rules and remix defines some of the key definitions that you have to write inside your pages, inside your code. And then at the compiler which is using esbuild inside it's transforming this code into two parts. Of course, for the browser part and for the server part. So for a server part it's not entirely a code it will need to serve your application. So for that, it will need to make some HTTP server working for you. So again, the compiler will analyze the code. It will try to get, it will get the information from your code about the routes that are used there, about the data that is used there. And then it says in the documentation that it will handle it by any, well, not by any, but by the several HTTP servers. And what that means, like we started again in this code with an idea that remixed run slash node that is supported by default from the box, and you also have a cloud-flare, Audino approaches. So basically these are the utilities that you can use for your server side. And for the node, by default, it would use the Express server, if I'm not mistaken. So it will, on your local host, it will configure the Express server that you can just run with Node.js. But you can also directly use the cloud-flare provider, so it will run by the H run time after deployed, of course, after it's deployed. It also supports the Dino compiler. And probably the Dino runtime and probably more than that, which you can find in the documentation about that.

So what else are the server side supports? So what we seen so far was a loader, and that is a function, the keyword that you have to write in your code to make REMIX know about the function that will retrieve data for your application. So it's just the name and it's about naming, right? You have to export a loader name, and that should be a function, can be probably asynchronous, in most cases it will be asynchronous. And then you can attach inside this function, any, let's say, database layer. So you will go to database, retrieve some data from there, and put it as a response from this loader function. So that will be executed on backend, which just makes it logical. Other than loader, you also have an action. So action is something that I will show a bit later, but just a few words, action is something that doesn't load data, but it allows you to send the data to a user. We will see an example in a few minutes, but just keep in mind that we have also an action. And yeah, when we define our order, we also have a React component, but the React component will be transformed into both backend and the client part of our application. So how are we gonna do that? Well, that's actually how Emix will do that. That's pretty much possible. We will explain it in a few moments. But what you need to do is take this component and then transform it to some part of application. So you have actually from Emix, a possibility to do so, from React, sorry, a possibility to do so. But yeah, let's talk about it in the experiment part.

So for client-side build, you have multiple features too. So first of all, you have a layer in between client-side and backend side, well, essentially, it is executed on a backend. The part that is using the data from a loader, that will be executed on a backend, like we said, but it will be fed to a component, again, on the backend side. And then it will get the data, retrieve the data on backend side, generate the component, again, on the server-side, and give it to a client, where the client application will pick it up and will continue from this moment. So that's probably better described by the term hydration and rehydration. And the beauty of it, it all happens behind the box. So you don't have to do anything at all to make it work because it's already working now from the beginning. So what you need to do is just to use a loader in your code. I hope the noise is not that bad. So in here, in this example, you can see also the action. So I promised to talk a little about that. So imagine in your component, you need to not only to show the data, but you want to update the data. And for that, you can use the action keyword. So in your code, you described an action keyword and that also would be a function.

6. Remix Unidirectional Data Flow

Short description:

Remix implements the unidirectional data flow, originally promoted by React with the Flux approach. It handles actions that apply logic and make changes on the backend. Remix wraps best practices like web workers and session storage, making optimizations behind the scenes.

It will get the data from a client side, it will do some logic, and it will then can decide what it needs to do. Render afterwards. And that actually also very cool, and that brings us to the unidirectional data flow that was promoted originally by React with the Flux approach. And yeah, later on, was also used by Redux and many other things.

So what would happen if you define an action that in a life cycle of your page, of the application, it will just start from action. If any data was received on backend side, it will apply the logic that you described inside the action code here. And then it will do the change on the backend side for example, do some write to a database. And then it will actually redirect it in this case to the page where again, your component can retrieve the data first. So this unidirectional flow, and it will show you a updated page. And I think it's really beautiful how it all works between backend and the client side.

So on, I think essentially what Remix does and that we just quickly touched it so far, but it wraps a lot of best practices that your modern applications use already. So you don't have to implement them yourselves. Things like you can think of web workers, like you don't need to even know about them if you use a remix. I mean, it would be better to know them, of course, but many, many things Remix would do for you just behind the scene to make this optimizations for you by using web workers, for example, or a session and the cookies approach.

7. Remix Backend and Frontend Integration

Short description:

Remix provides utilities to store user data in the backend by attaching session storage to a database. It supports key-value storage options like Cloudflare workers and Deno deploy. On the client side, actions are bound to sections using forms, allowing the application to function even if JavaScript is disabled. The Remix compiler analyzes code, constructs a manifest of routes and data flows, and generates backend and client-side code. The compiler transforms the code into request-response handlers, which are used by adapters like remix run slash node and remix run slash Cloudflare. The application structure in Remix follows a folder-based routing system, with dynamic parameters and utility functions for client-side and server-side database requests. Remix incorporates features from React Router and introduces the outlet pattern for rendering nested components. Error boundaries allow catching and handling errors on the backend and displaying them to users. Stacks are a pluggable feature in Remix that provides additional functionality for both frontend and backend development.

So that's something that once we have in browser, in browser possibilities to use the cookies and to save some store some data about the user. The question is, yeah, how are you gonna store it in a backend? So what Remix does in this case, to provide you some utilities, which means you can attach your session storage to database that is available for you on the backend side. You can think of age around times again. And remember that the Cloudflare workers, they have a key value storage nowadays. And in Remix way, you can a bind session storage to these key value storage. And then you, when later you deploy your application to the Cloudflare, it will be just working natively on this age runtime. And same goes for, for example, Deno deploy. Deno deploy nowadays also have a key value storage they brought it a few months ago. If you haven't heard about it, like I turned it to Cloudflare key value storage. And I guess the idea is to compete with them. Again, you can just bind the session storage with a risk key value. And then later when you deploy it, you will, yeah you wouldn't get it almost for free. Yeah, one thing I haven't mentioned about the action so far. So we talked about the backend side of it. So what the action is a code that will be executed on backend side. But on the client side, you will need to somehow bind it to this section. And you do it by using forms. So it's, again, the approach when you use browser possibilities. And later you slowly advance it, let's say, or evolve it if your browser supports this feature to different approaches. Like, for example, just XHR or Fetch Request. So what I'm saying is if your JavaScript is not available on the browser, it's not enabled on the browser for some reason, your application will still work because your page will be constructed of a native form, HTML form to be submitted. And then, the code will be still getting the data from this form and you using this unidirectional flow, it will populate this data. It will update the database is needed and then it will render the response to a client again. So that's very, very nice how Remixall combines that all. So again, just to repeat it to myself a little bit, so what the compiler does, it analyzes a code, code like that, which can contain actions, which can contain some components or React components and the loader and those are the main features but there are more on that and you can explore documentation for more possibilities. But again, the compiler will analyze this code, will construct some manifest of which routes are used, which flows are used for data retrieval, for data loading and then it will produce a code for a backend or a server-side, in which case it will configure your server-side with a library that you decided to use, for example, a remix run slash node but in this case it will be using again Express web server but if you use a remix run slash Cloudflare, it will use just the Cloudflare runtime and that's also a nice explanation of how it does it. So essentially what remix compiler transforms your code into is not just Express router, not just Express application related code but it will transform it into the manifest of the request response handlers, which is a web senders and those can be picked up by this adapters, remix run slash node, remix run slash Cloudflare, et cetera. So those will be using again, that standards request and response to use it for configuring web server on a backend side. For client, it's sort of the same, the compiler will analyze the code, which by the way is written in one file, so that I really liked about remix, and then it will configure it, it will again, construct this manifest, the which routes are used inside the application, and then it will construct the React application, let's say in the scope of React framework, and it will encapsulate all the best practices that it can from the code, like React Regeneration to pick the application from the state where the back-end left it basically. Okay, that's a short high-level overview of it, so let's continue with looking at some code examples in a minute, few more features, so before that is the how your application should look like in a Remix way. This is an example of the application which contains some blog pages, so you can see that Remix uses the routing by the folder structure. I think this is very popular nowadays with the modern frameworks to use a folder structure so you don't have to actually connect yourself like which routes will be used here and there. So what Remix does, it will construct the URL by the directory bus, so blog and then slash categories or just blog will go to index. And you can see some of the files started with $ and that means that you have some possibility to have dynamic params there and you have some utility in your client code, in your client side code to recognize which param you got on this page. And based on that you can do the, you can do the request to database both in client side and the server side. So utility too can be used on both of course. Yeah, so this, one thing that we haven't mentioned so far is that the Remix was built originally by the developer software React Router and the React Router has a lot of features and the authors of the Remix tried to sustain most of the features of React Router and encapsulate it again in the Remix framework. So you can think of so-called outlet pattern where you have children and their parent components and in your parent, you can specify the outlet component which later will contain a code of a children component that can be inside this blog page. For example, you have the main page from blog and then you have some section in this blog page that will contain this particular part of a blog and it will render it steel on the URL of blog itself. We'll see it in the code, I hope in a few minutes. Yeah, what else? Just a few things that I wanted to mention. Well, error boundaries, yeah, you have many, many other features but I just wanted to discuss these two more. So error boundaries, you have the ability to catch errors on the backend side and then you have a choice to basically show them to a user or you can decide to just, yeah, you close your application, failure application with an error code, for example. If that's what you want for your backend side. So error boundaries, it's, I think, two components essentially that you can use on the client part of RemixCode and on backend part of your RemixCode to either decide what to do with the error if you caged an error and how to show it to a user. And in here, you can see a page which caught an error on rendering a particular invoice and it showed it in the outlet of a parent page based on the error that it got, basically. And one more thing, which is not related to particular front end or back end, it's called Stax. It's related to all of them. So it's a nice, pluggable feature of Remix. So basically, it's what we saw in the beginning of this Remix, run slash react or Remix run slash node.

8. Remix Stacks and Code Configuration

Short description:

You can use different technologies other than React with Remix, and the code will remain the same. There are three main stacks to choose from, including deployment options. The code defines loaders, components, and dynamic routes, which are transformed by the Remix Compiler into a manifest. The manifest can be used by the client or server part of the build. Let's dive into an example to see how it works. We will depend on the compiler to analyze and produce code for the web server and client build application. Starting with the packages, React and React DOM are the main dependencies. The stack includes adopters like React and Sorb for server-side rendering. The configuration is generated by the official Remix supported CLI.

Those can be called a Stax as well. So you can decide what technology your application will be based upon. Like you can think of, you can even use some other things, not React. If you have a community-supported Stack that uses not React, buy some other technology, yeah, still the Remix code will stay pretty much the same, but it will be using a different framework and it will be using a different approach of these adapters for your application.

Yeah, so there are three, I think, main stacks that you can use. They also include how you deploy your code, for example, to Cloudflare or to, I think, Versell by default. It's one of the main popular Remix targets for deployment. But again, you can decide what stack you will be using and where you want to render it.

And that last final picture of what we just discussed, how it all looks like altogether. So we have a code. So we have, we define in code the loader and component. Those are the keywords that are gonna be used in every file in your application. And you have dynamic routes, like we just saw in the other example. And those, by the Remix Compiler, transformed into some manifest. And the manifest can be picked up either by the client part of the build or by a server part of the build, and will be transformed to the server configuration or the public build for a client-side. Yeah, this is an example of, I'm not mistaken. Yeah, it looks like to me like a backend code, just because it uses Remix Run Node, but I'm not sure what exactly part of the build it is, can be also client-side, but we just don't recognize why it is yet.

Yeah, so, oh, I hope that was not too boring. So let's have a look at one particular example of how can it work? Like, okay, that's all cool, we discussed it, it's in theory that that sounds fun, and it sounds fine, and maybe even not complicated. And then I thought, okay, but can we actually prove that it would work that way, like, if I do a remix myself these days, how would I do that? So yeah, Do-I-Y, let's remix today with our own hands. That is a part of the section that I want to show. So the goal was, again, to prove that a remix can make it, and it can make it that way. So we will depend on the compiler, and the compiler will analyze the code, and it will produce a code that will be picked by the web server and by the client build application. So that was the target for this experiment. And now let's dive into code. I will reshare my code now. So yeah, first of all, I was showing slides for some time. So let's quickly double check the configuration of a normal remix project. I will close other tabs as well. So let's say this is our remix application. So what you can see here, I like to start with the packages. So when you just start with a remix, you will find something like some package, some like that. So what it consists of is a few dependencies like React and React DOM. I think this is logical. I think so, yeah, Bruno. I think it was created by that, yeah. What else you can see here is a few helpers. Not the helpers, but even adopters, right? This is the part of the stack that I tried to explain. So slash node slash React and slash Sorb, and slash Sorb, I think it's what allows you to server from local also to use express web server. And yeah, you configure... I haven't written any line in this packages that was generated all by the official remix supported CLI. So yeah. I said bootstrap. Excellent stuff, it's a... You didn't try this any lines, but I added this, so sorry for this Alex. Not the bootstrap I added yes. Okay, I was chosen between these two, okay. Which should I discuss and I thought, yeah, I will go with that. I miss it, but yeah, okay. That's a wonderful public approach with bootstrap, best practices and all.

9. Remix Structure and Experiment

Short description:

The Remix framework follows a specific structure with routes and pages. The entry server TR6 file defines the backend behavior and page rendering. Remix uses the render to PyPool Stream strategy for server-side rendering. For the client side, there is a configuration for enabling scripts and adding style sheets. The experiment involves building a client-side rendered component and sending data to the client. Two packages, Turbo REPO and ES Build, are used for compilation. ES Build transforms the code to normal JavaScript and includes the React create element. The GS6 code is transformed to JavaScript that can run anywhere.

So that's what we have here. And then like we saw the structure of, no, actually let me quickly switch to even this block tutorial. That's what you will find yourself if you go and through the remix official tutorials. So yeah, it all basically follows this structure. You have routes and inside routes, as we saw, we define the pages. It can be just a route, just an index, which will contain the main page for this route. And then it can go with, yeah, slash posts for example. And then you have an index with a post and it can have some outlet inside to show the child component and so on and so forth. So I think that's all we expected. What else we can see here in this structure? We can see that entry points. There are few of them. Actually, there is an entry server TR6, which defines some pieces of how the backend side will behave and essentially the rendering of pages. So you can see here that already some of the hints of what I will be using later on. It's a render to PyPool Stream. So that's what React has from the box. So you can transform your React component to HTML. And you can do it from the React box itself. In Remix, as you can see here by default, they use a render to PyPool Stream strategy. I use the simpler approach to, I will show it in a second, but that one is what Remix uses by default. And for the client side, yeah, I think public showed a way how to enable scripts, for example, and yeah, that looks more like a client's set configuration. Okay, I will have some definition, what style sheet I will need to add to my application. I will also have description all the links to create a React router, I like functionality and so on. Yeah, this is scripts and out that we discussed so far. All right, that's a structure that we've been discussing so far. So now about experiment, how we can build our own remakes. Let's have a look, actually. So for my experiment, what I did, first of all, I wanted to follow some a like remix approach, so I wanted to define my client side rendered component and I wanted to send also the date to client. For that, I defined two keywords, let's say, in my code. So that's my RemixAleks, or Remix, yeah, RemixAleks framework you can think of. It has a route, a route will produce a JSON, hello, indexAPI world, and I have a component which essentially is a React component because it's a JSX file, as you can see. So that's my application, it's very simple and tiny. As you can see, it's nothing really fancy here, but I wanted to make it work and how I made it work, well, in a few steps. Actually, I just needed two packages for that, define some Turbo REPO, by the way, if you wanna play with it, yeah, I highly recommend it's a very easy configurable tool and it makes your life so much easier to open up all the dependencies and the link in all of the cross-dependencies to each other. So definitely recommend it to play with it. So what I defined here is two packages. One is super easy, one is like what is doing, it has the dependency of ES build itself and that for a DevServer, which is this part, it uses one small utility to traverse the files in my file system. So nothing, it actually is not needed there and maybe should be gone later on. So what it does here, I will just call the ES build on my code, basically, that's basically my compiler. So what it will do, it will get all the files, it will traverse the files in the project, should be J6 file and it should not be in a dist folder, yeah, it's a little ugly, it's a lot of hard-coded things. What it will transform it to, it will basically use the ES build, ES build transformation method. So in this method, you can define what you're gonna do with each file, and what I do with each file, I basically attach the usage of react, that's what I need, as you can see, I haven't defined any react at all in my Alex Remix framework application here, so that's what I need to fix, because later on, when we're gonna be configuring our React build, and the transformation of our React component into the backend side, we will need to react anyway, otherwise, it will not compile. So how I overcame it, I basically added static imports, import React from React to my server-side rendered pages. That's essentially what I do here. So I just add a source with imports, I add there my original code, and yeah, that will be produced to my dist folder, so if you look at the dist folder, it follows the same structure here. Yeah, ESBuild is super powerful, and I set some complements to remove the documentation, but I can say the same for ESBuild documentation itself, it's a very nice tool. If you haven't used it yet, it's very easy to start. As you can see my compilation strategy is 50 lines of code and most of it is nonsense code anyway, so yeah, as you can see, it's really easy to use. So it will produce the multiple files for each of my input file, it will produce the output and how it looks like here, well, it actually converts GS6 to a normal JavaScript and it will be using the React create element here. And so that is automatically generated of course, and it also produces the route which stays the same because it's a normal JavaScript code here. And so what I did in the first step, I transformed GS6 to the normal JavaScript that can run, well, sort of anywhere.

10. Remix Compilation and Server Setup

Short description:

The compilation step is completed, and now the web server needs to pick it up for rendering on both the client and backend sides. The second package, dev server, contains the necessary parts. The server is a simple Fastify example web server that listens on port 3000 and defines a function to add routes. The run command adds the route to the code. The application structure involves traversing the file system, generating URLs for each file, and producing two endpoints for each component. One endpoint renders the component using the React to HTML strategy, while the other handles backend actions. An additional route is added for APIs using the action route.

Yeah, so that's my compilation step. And now it should be picked up by a web server and it should be picked up by a web server to render it for client side and for backend side. And that's my second package here. It's called dev server and it contains a few parts. So I almost finished, hang on there.

So first of all is a server. Server itself, as you can see, it's even less than the previous file. So this is just a simple Fastify example web server. I just started on port 3000 and I define a function to add the route to it. And that's what I define my server here. So it's a very, very tiny.

Yeah, and then I have to put path, the URL for the route and the callback, which will work plus or minus like express callback for a route. And then, when I start it, I need to add this route of my code, right? So that's what happens on the run. So just to show you how it is structured on my Alex Remix framework application, I have a task in my scripts to convert JS6 to JavaScript. So that's using my converter as compiler. And I have a start server dev. So you can think of it as a remix adapter for Fastify, let's say. However, I think it doesn't exist yet. Maybe you can write it later on. So, yeah, it starts the web server. It checks some things. It adds the routes. And that's what is the most important here.

So, again, it traverses a file system. It goes through this dist folder here, it gets index b, a URL, so it gets all these files, it traverses all of these files, and then it says, okay, make a URL for this file. Again, nothing to focus on here. It just says, yeah, based on the path inside my directory, I will say a slash index on slash b or just slash as a route URL. So we know the URL where we need to attach our handler to. And for each component, in my code, I had to produce two end points. One is gonna be rendering the component, like React partly publication, and one will be about backend. So that's what it does. First, it does the component rendering. And then where I use the other React to HTML strategy. So if you remember when we were showing the other one, it was using the streams. So my approach is slightly simpler. It's using a render to static markup. So it will just convert this React defined components into the string and then I will just render it as it is to a user, to a browser. And that's what it is. And I will add another route for API. So for APIs, I will use the action route. So for that, I will actually need to understand which is the component route and which is the action route handler, right? And how I do it, again, very, very dirty way. I just imported the whole file that I found in my this folder into the context. And when I import it, I know that I can export the route keyword from it and I can export the component keyword from it. And that's how I understand that I need to... Again, where was it here? I think, yeah. So that's how I understand which is the route and which is component. I converted the component as a React to Static Markup and I convert action route just as a handler to backend. And let me start it, start Server Dev. And now I will switch to the browser again and that's working. So that's my a route and then I think I had a API with a slash probably.

11. Remix Folder Structure and Code

Short description:

The workshop demonstrated how to structure URLs using folders, with the compiler analyzing the structure to produce code for client-side rendering and data retrieval on the server side. While not a complete solution, it covers important aspects of working with Remix.

Yeah, so that's hello, api-walt. And then I think I had also the b route that's api-walt and then I had a, like that, I'm not mistaking. So that's my api-a and that's my just slash a. Yeah, again, nothing really fancy, but I, what I wanted to show is that, yeah, can I build something like that? And it didn't take me a lot of time and effort actually.

So what we saw so far was a, okay. Some code that reminds us about the remix structure. So it depends on the folders to structure our URLs. It will have the compiler, which will analyze this folder structure and produce two parts of the code. One that we'll do the client-side rendering. So that was my component rendered and one which will be picked up by the back ends to produce some data. So that's what I did for, that's what we did for the server side. And yeah, it's a not full way, to make a remix alive but it covers some of the things that are very alike working in remix. Right Pavlik? Yes, absolutely right.

12. Remix Waterflow Loading Problem and Solution

Short description:

Remix solves the water flow loading problem by supporting two rendering strategies. It allows simultaneous loading of data for all components in the chain, resulting in faster rendering. The solution involves layouts, the outlet component, and the build process to extract data loading from components. Remix's approach enables immediate loading of data for all components upon receiving a request from the browser.

However, the question for me is, why do we even have this? Why bother? Like, why do we have this, like, build and complications? Yes, of course, like you can, it's very nice that you've built it, but why remix has it in the first place? So, and there is like a particular problem that remix tries to solve with all of this approach. I don't know if you are sharing or not sharing, like what slide are you? If you can stop sharing, I will be on this slide on the correct one. So yes, basically what I'm talking about is Waterflow loading problem.

So let's imagine we have quite simple application. This application is very similar functionally to what I've already shown, like there is some list of invoices, for example, and one details of one invoice. So for example, we have a sales folder, inside we have invoices folder, and then we have some route that renders invoices page. For example, in the invoices page, first of all, what we're going to do is get the list of invoices. So, and like before, like, we get all the list, we're not going to render anything while like in real world example, it can be loading component, some like throttler, and once we have the list of the invoices, we are going to render the list of the invoices. Pretty simple. And once one of the invoices is selected out of this list or by the URL, we are going to render this invoice.

So far, so good. The component for the invoice is pretty straight forward as well. We just get the details for the invoice from the backend or by the API call and render the details on the invoice. However, what's like the downside of it? The downside is that the call to get the invoices is not done till the list of the invoices is retrieved. So, therefore, what happens is that we get the list of the invoices first, wait for this to load from the backend, then we make another call to the backend to get the details of the invoice. And then we render the invoice component with the details of this invoice. So, this is called eventually water flow loading. And the more nested components we have, the bigger the problem because you will have like the most parent, the most root component first load its data, then its child, then the child of the child, et cetera, et cetera. So you will have sequential loading of the data, sequential throttlers and loaders and water flow loading problem of the UX. So what would be the solution for this?

Let's reiterate quickly on some ideas of Remix. So, first of all, it supports two different rendering strategies. And some of them full server side rendering has all the input from the navigation that combines nicely for the folder based routing files based routing. So essentially, we have all the data from the navigation, all the data from the initial request, all the data of what components we're going to render all the chain of the components. The second idea is we have layouts and layouts are like natively supported. So we have this outlet component that Alex mentioned, and then the child components from the child folder will be rendered in this outlet slot. So that allows us for the whole chain of the components, specify image component image, layout the data that is need for this particular layout for this particular component. And then what Alex explained in details, we have the build that's going to extract this loading of the data from the component and put it somewhere like on the back end, but essentially, we can simultaneously access this loading functions. So, and that's all of this IDS combined bring us to the fact, then we get the request from the browser. We can immediately start the loading for the, start the loading of the data for all of the chain of the components. And then we can render all the components at once. So instead of going like water flow, one by one by one, all the nested components, we will get all the data first and then render at once. So this sounds really nice. And here on the screenshot, for example, this is like the sales and was just in the details on the invoice. We can see here that it's like some components are nested and it's like the way the nested component. It imports the invoice to GS and fetch the details of the invoice and it happens right together with all other requests. So this is kind of an idea. This is kind of the solution that Remix proposes us.

However, like we can just like not take it by word, but validate all this idea. And that's what we built. With Alex, again our favorite application is the list of the movies and the details of the movies on the page of the movie. And now let's check. So inside this component, we have a sleep function. So let's try to change it to, let's say five seconds. So let's enable back our scripts, just to be as close to production as possible. Let's clear the network tab and let's clear it one more time and refresh the page. So here we can see after some time, how much time it will take for us to load the data. So we can see here, for example, in the very, very last, so the data take us five second to load and there are no more requests for five seconds. So even though we have two sources of data and two API requests for the list of the movies and for the details of the movie, it takes us only five seconds to load the data. And this exactly because those two requests are done simultaneously. Just to prove a little bit, like we have the loader in the movies component and indeed there is a sleep on top of it and this is at layout and then we have a movie ID component and again we have sleep inside it to load the data inside the loader.

13. Comparison with Next.js and Layout Implementation

Short description:

The Next.js application takes a long time to load the data, even though the details and functionality are the same as Remix. The loading time is longer because the requests are made simultaneously. Inside the movie component, the movie ID can be defined using the dollar sign as the file name. The movies component acts as the layout and renders the child component using the outlet keyword. The layouts are implemented in this way.

And then again we have to just the details of one movie. I also would reviews but reviews does not change anything so they're not even shown, I believe, but exactly like this we can at least see that the data is loaded simultaneously. So after one seconds we have two different requests and we also promised with Alex to compare it with other frameworks and we are going to compare it with another pretty popular framework nowadays, nowadays it's Next.js and we are going to start this Next.js application and we'll see how it's done there.

So it has, I believe, exactly the same URL, so we can just refresh the page and after some time we will see the data. Like visually, it's a little bit differently, but at least that's exactly the same page and exactly the same functionality. So we can already feel that it takes quite a lot of time to load the data. Why is it so? So the details like all the functional applications are exactly the same, it's just like layout is a little bit different, the list of the movies is on the top and then the details of the movie is on the bottom, however, we can see that the six movie, The Good, The Bad and The Ugly, it's indeed the details of this movie are shown. So however, why does it take so long to load this application? It has exactly the same timeout right now, five seconds, but it doesn't load in five seconds. It loads like really, really long. So how much it loads still, so it loads five seconds here and then for the initial request is another five seconds. So it loads in 10 seconds and that's exactly because we do the request simultaneously. Let's dive into code for a little bit just to see what's going on on the code level.

Publik, may interrupt you, while you are in the code, maybe you can show how you can define the Movie ID inside a movie component. Bruno was asking about it. Absolutely. So if you are talking about the remix, so here we have routes and the Movie ID should be like the file name should start with the dollar sign and then that would be the variable name. Then inside this component, we would have in the loader function, we accept the loader arcs and this like it has a params key that will contain exactly the same params for the whole chain. So here it's like the only one variable, only one dynamic part it's movie ID. So we will have a move movie ID here. And also I believe you can also have them inside the component self. However, like here I can see that this is not used, but most probably it would be also the same something like params movie ID. All right. Sorry. But how do you say where in the movie component you will render the obtain? So just say it again. In the movie component. Yeah, because the movies of the movie component, right? With the list of movies. Yeah. Yeah. Mm-hmm. Yeah, I understood the question now. So the movies component is, indeed, it contains list of the movies. But it also has this special keyword outlet. And this special keyword outlet, it makes this movies component as their layout. And then instead of this outlet keyword, it will render the child component. So here, for example, it doesn't have any params to get the list of the movies. So it's just takes the list of the movies from the mux files. And then in the port let, in this movies directory and movie ID component, we render everything that is for the movie. The details of the movie name and the description. And we get this movie by the, essentially, the same list of the movies. And just find it by the movie ID. And then whatever rendered here goes to outlet. And then what we get as the result in WebPatch. Got it. That was my question. Thank you. Yeah, sure. All right. So this is like how the layouts are implemented. Thanks a lot for the question. That's, it was really nice.

14. Next.js Layouts and Sequential Loading

Short description:

Next.js does not support layouts natively, unlike Remix. In Next.js, a getLayout function is called on the client-side, resulting in sequential loading. This means the initial document takes five seconds to load, followed by the layout for another five seconds. Next.js makes multiple requests for movie data, including a second call to retrieve a list of movie IDs for static site generation. While Remix improves the first user experience, there is a downside to this approach. If a nested call takes longer than others, it delays the rendering of subsequent components.

And now we are going to take a look at a similar framework. It's Next.js. And here we also have very similar functionality what I've already shown. However, in this stable version of Next.js does not support layout natively. What does it essentially means? It means that we need to do some kind of magic which is explained in their documentation, so there's like a plus for it. But this kind of magic is like the following. We have, on the component, a getLayout function. And this getLayout function returns a layout for a particular component. And then this getLayout function, let's take a look where it's called. And it's called in underscore up. So in underscore up, where we, by default, render a component, we also check whether it has a specially defined getLayout function. And if it has this function, it rendered this component, it calls this function for this component. So what does it mean? Remix supports layouts natively, so you can get the data in exactly the same way as my component is dynamic params and for layouts. It's just the function that will be extracted and called on the backend. Next.js does not support it. And that means that this getLayout function will be essentially called on the client-side. And then what we can see that this getLayout function, let's take a look at our movie layout. It has very similar functionality. It just, like, calls the backend, gets the list of the movies, and then renders the list of the movies. However, that means that what we have essentially is that we have five seconds to load the initial page or the initial document with the details of the movie. Then we will see on the client-side loading text. And this loading text happens when the layout starts rendering. And then this layout loads the data for another five seconds, sequential loading. This is our layout. And that's what we can see here. So we get the document first for 10 seconds, and then we get the layout for five seconds. Why is it 10 seconds? It's another very... It has nothing to do with the problem directly. It's just how Next.js works. Because actually we have not only two requests for a list of the movies and for the details of the movie. We have three requests. And we make the request to get the list of the movies twice. The second time, because Next.js provides another cool feature for Next.js. It allows to build your website statically. So server-side... Static site generation. And for this, it needs to know what movies you have in your database. Because it should know that you have the movie with ID one, with ID two, three, and so on and so on. And because of this, we need to give the list of IDs. And for this, we need to make another back-end call, another API call to get the list of the movies. That's like the second call to get the list of the movies. And then layout makes another call for five seconds to render the list of the movies. So like for our really simple case for this application, we can see how Remix actually improves your first user experience. However, there is downside of this approach. And that's very nice that Alex mentioned the error boundaries. So the downsides is that it needs to get all the data first. So let's say we have very very nested like component, for example, five layers. And one of the calls like the most nested call takes for example, five seconds, while all the other calls takes 100 milliseconds. So for the regular approach, for the sequential loading, we will load the level first component first in the 100 milliseconds, level two component in 200 milliseconds. And then after like a second, then two seconds, most of the part of the page will be rendered like customer user will already see something.

15. Remix Validation and Exploration

Short description:

Remix offers better UX by loading data simultaneously, rendering only the happy case, and showing errors for specific requests. It follows web standards, including navigation input and form-based mutations. The modern web app UX is enhanced with optimistic updates and a solution for the waterfall problem. Remix supports full server-side rendering and authentication, improving security. It also provides tools for search engine optimization. To explore Remix, start by validating its focus on web standards, modern web app UX, and better websites.

And then the very, very nested part of the page will be still loading, while in Remix, it's not going to be like this. It will load, it will wait for all the data for five seconds, and only after it will render all these components. And error boundaries I mentioned because even though it loads simultaneously for all the requests before it render something, if one of the requests fails, it will show the error only for this part. So like it renders only happy case and it waits for everything. If one of the requests fails and it shows the error only for this request, not for the whole page. So that is it about the comparison with the Next.js. And now let's go for the summary for the thing that like we were promised.

So like Alex also mentioned that the documentation of the Remix was really, really great. I also wanted to show something else and this is their landing page. I'm kind of a fan of it because I really like how it looks and here we can see that like the Remix is focused on the web standards, modern web apps to build better websites. Quite a solid statement. And now after we already talked about this for quite some time, we can validate this statement. We can see whether the web standards, modern web app UX, and the better websites are indeed proposed, are indeed fulfilled by the Remix. So what do we get in the result? We can see that the navigation input and the form-based mutations, so this component that Alex mentioned, form to send the data from user to the application, it's all standards. It's all based on the standards years ago. From this server-side rendering. So indeed it's based on the web standards. And there are a lot of different web standards. For example, at ING we use web components. This is another web standard. It's entirely different. This remake uses native standards to send the data, to get the data from the navigation bar. So those are like standards. So modern web app UX. If you work with Remix with the scripts tech enabled, then it gives you some additional benefits on top of everything. For example, it allows you to do optimistic update. So you can just get the data immediately render from what the client provided for you, send the data to the backend, get back like successful response after some time, maybe not a successful response, then you will show an error to the client, to the user. But if it's a successful response, which happens like 99% of the cases, why would user wait for it if they can see the data that they provided immediately. So this is indeed like good thing for me, like UX and on top of it, this Remix offers these solution for the waterfall problem. So this is also better UX by default. So I would say the modern web apps UX and the better websites, they're like kind of covered, especially because like authentication is built in for like a remix. It's not, for example, nowadays with full client side applications, you can have this on web token based authentication. You can keep the authentication information about the user, the local storage on the client side, and then get added as the header for some particular requests. So that helps, for example, because you manually add this header to the request you want. So this header is not shared as cookies. For example, this all static files on the same domain. It cannot be shared with some unexpected. For example, if there's a forged request or the client side code was somehow compromised and then it's loaded from a different domain. So those are things can be improved using the JSON web token, but Remix supports full server-side rendering strategy. And in this approach, you don't have access to the local storage because imaginatively consume, yeah, you just don't have client side. You just don't have JavaScript. And then all of your authentication should be kept in cookies in session. There is still like benefits of doing this. This is another standard. However, just be aware of this limitation. And as AIO, there is like for the search engine optimization, it allows to change the metadata. It allows to check whether it works with user currently or with the search engine. So it's kind of very, it gives some additional tools to improve search engine optimization. So let's assume, we managed to convince somebody, Alex, about this. How would people start to explore the remix? Mm-hmm.

16. Introduction to Remix Tutorials and Deployment

Short description:

The website is a great starting point with tutorials of increasing complexity. The blog tutorial shows key features and how to build an application. The app tutorial goes into more detail on strategies. You can deploy your app to Vercel and share your experience on platforms like LinkedIn and Medium. Remix is cool for small to medium-sized projects, but consider other factors for large production applications.

Yeah, essentially the website is a great starting point for that. It has gradually increased the complexity of tutorials. If you open the docs, you have a blog tutorial that will take you about an hour to go through. It shows the key features and how to build an application. If you want to go deeper, the app tutorial is a great continuation. It goes into more details of the different strategies and how they work. You can build the application yourself while following the tutorial, which is a nice approach. After following the tutorials, you can deploy your application to a serverless tool like Vercel. You can also write about your experience on platforms like LinkedIn and Medium, which improves your observability and allows others to see your interest in different technologies. In summary, Remix is a cool framework that has everything you need to build full-stack applications, but consider other factors for long-term, big production applications.

17. Remix Benefits and Considerations

Short description:

Remix is a cool framework for building full stack applications. It provides everything you need, including layouts and build tools. However, it's best suited for small to medium-sized projects. For large production applications, other factors like community size and documentation should be considered.

You can also, yeah, basically it's built, like you have to build the application yourself and it makes you feel it, touch it in the same time and see the explanation. Okay, it's a very nice approach of dealing with it. Yeah. Do you agree? Yes, absolutely, absolutely. And of course, on top of it, like after following the tutorials, you would have some application and then you can deploy it to serve like to some serverless tool, maybe Vercel. Why I mentioned this, and they're not paying me for the advertisement but I just mentioned them because I deployed to this Vercel service and I know that it's quite simple. They have a template for like Remix. So you just create a Remix project, put it on GitHub, connect it to Vercel and every time you push the code, the code, it's deployed and it's working. Another thing, of course, you can write about it like LinkedIn, Medium, you can describe your experience, what you feel when you work with the Remix, when you follow the tutorials and also it improves your observability maybe. Some other people will see that you are interested in the different technologies. So that's also like always nice. So to put it like to summarize, Remix is really cool. So we describe that it has everything you need to build the full stack application. Like we discovered or entangled some mystics, some magic behind the Remix, how it works, it's like and what benefits it give us, it gives us all these layouts and build tools, et cetera, et cetera. However, like for example, I would say that the Remix is ideal for like small, maybe medium sized projects. When there is a really huge production application, there are way more factors that needs to be considered. For example, like how many years the technology already on the scene. Who is the behind this technology, how many documentation, how many people are aware about this technology, the community size. So all of those things should be also considered for the long-term big production applications. So I would say Remix is very cool, but chose this nicely.


Remix Layouts and Server-Side Loading

Short description:

Previously, in the stable version of Next.js, layouts were not natively supported. However, in the Beta version, layouts and server-side components are natively supported. In Remix, both calls are done on the server-side, regardless of whether it's a layout or a regular page. However, if JavaScript is enabled, Remix can dynamically load data on the client-side after the initial server-side render. As a developer, you have the power to choose whether to make calls from the client-side. Unfortunately, there is no information available about Astro Public's layout and data loading capabilities. In terms of lazy loading routes on the server, Remix allows for automatic lazy loading based on its file-based or folder-based routing approach.

Ooh, Pavlik, we have a lot of wonderful questions. Let me ask them you first, if you don't mind.

First of all, I think previously you were saying it out loud like in the next year, which version have you used actually? And what is comparing to a new version changed to what you've shown? Yeah. Good catch. Good catch. Like, that's a... I mentioned that's like the layouts for example, are not natively supported in the stable version of Next.js. There is Next.js Beta, I think 13. And it has a new way of defining like routes. It's not a pages folder anymore. It's app folder. And in app folder, they have natively supported layouts. They have natively supported server side components. So this is still Beta but this is huge improvement and huge kind of maybe borrowing ideas or some shared ideas, same functionality as in the Remix, as Remix proposes. So in the unstable or in Beta version in Next.js, there was like already a layout and already some solutions for this problem. A nice one.

Yeah. So next one is when we were showing this, the Waterfall problem, the question was that both calls in Remix are done on Server-side or one of them is done on the client-side? It's a very nice question as well I think. In Remix both goals are done on Server-side. So because Remix supports like all these layouts natively and I would even say they're like close to the first-class citizen. So like every component, every page, it can be a layout, it can be a regular page. They're equal from this perspective that they load data equally, they're rendered equally. So from this perspective, it's really nice feature of Remix. And because of this, the data is loaded on the Server-side independently on whether it's layout or the regular page. So it's just like always loaded on the client-side. Of course it can be different and it can be different if it's, for example, the loading, the rendering strategy, which is like there are two in Remix. And if you have the client-side trend or like support for JavaScript, and then you have rendered page and the data was like initially loaded on the Server-side for layout and for the component for the page, no matter how many nested levels and then you switch to another page and then Remix can do some magic to load the data now from the client-side trend or always everything on the client-side, sorry, everything on the client-side and then switch the page. So it's can like dynamically changes on the fly after the first render. So from this perspective, it can also be loaded on the client-side, but it's always the same platform. If it's the first run, always the Server page or layout. Doesn't matter. With the second run and JavaScript enabled, then it's a client-side and again, the page or layout that doesn't matter.

Yeah and to add to that, of course you can choose yourself, like if you wanna do the call from client-side, you can specify the directly in a component. You have a power to do that as a developer. Yeah, yeah, also also. Yeah, we didn't cover Astros day, as I said, that's maybe for a future. Yeah, anything about any insights about Astro Public just quickly or let's keep it like that. No, unfortunately no. Like from the brief, I never worked myself like on the production with Astra and from the brief examination of the documentation, I could not find whether it's like, I knew that they have layouts in some way, but I could not really quickly figure out how they work, whether they will load data on the server side, whether it's a full client side application. So, and I did not build an application to try it myself to actually experiment with this. So no. Cool. Yeah, there are more public and then. Of course, yes, yes. Does Remix support something like a dynamic or lazy loading of routes on the server in order to handle large modularized projects? Um, lazy loading. Oh, so I think like the trick. Yeah, that's difficult to say. So on the client side, I would say yes. So the trick is that always with this, why is this idea of like file-based or folder-based routing is powerful? Because it also allows automatically to have a lazy load. Because once a client on some particular route, it's already known that other files from this route or from a different folders are not needed.

Remix vs Next.js and Summary

Short description:

Remix is a fresh framework that supports web standards and provides a great user experience. It allows developers to write code closely together, combining backend and client-side practices. It brings the magic of combining different best practices without the need for complete awareness. In comparison to Next.js, Remix is suitable for simple websites that don't require constant rebuilding. For long-term projects or when working with multiple developers, Next.js may be a better choice, especially with its support for React-server components.

So they will be loaded lazily only once they're needed. So that's kind of very nice idea. Like next just probably create some other frameworks with the file and folder-based route and created it. However, how would it be lazy loaded on the server side? That's kind of difficult to say. Most probably like the application would be rendered just regularly and the code from outside routes will not be just even executed at that moment of time. And then when the application will be, or like when the client, when the user will hit another route, then another code on the server will be executed. And maybe again, like another code do not only be not lazily loaded, it's not going to be executed at all. So like it's probably this feature, for example, I mentioned from the next JS that allows to build the websites, I am not aware that Remix supports this. So that means that Remix does not need to know beforehand all the list of the URLs to actually like build them and then serve to the client, the static site, generated static site. It will always dynamically with the server gets the request, tries to get to the database. If there is data, renders the data back, if there is no data renders the error back. So that will not be a lazy loading as well.

Yeah, there is one last and probably is about what would be your preference next JS versus Remix? Let's combine it in the summary, I would say. So to start on a summary, I will give my two cents first. So what I really liked in Remix, I think it's a very nice and fresh framework and especially to start up something really quick, it's very handy. And what is the best about it? Beside what we said, like I said, supports web standards. It can gradually update a web application in a best experience way for a user. I mean, that's a cell in itself. What I like about it is that as an engineer, as a developer, you write code really close to each other. Your backend is close to client's side. And that's what I think nowadays, this is very priceful in the development. If you remember when Vue.js just started, that was one of the killer features they proposed, because you have written both the styles and the HTML structure and JavaScript in one file. And that's what, I think, Remix brings. But now in between the environments, it brings the backend and the client side, and then does the magic to combine different best practices that you don't have to be aware of completely. Just that you belong to Remix. And yeah, it does all the magic for the best user experience.

So, really nice. And then the word to the public. Yeah, I did, I really like your reference, for example, to Vue.js, how it combines the styles and the JavaScript. Or, for example, to the React initiative, because React combined the template and the logic, which I was 10 years ago, or something, not a fan of. I did not like React at all for this, but now it turns out quite a nice idea. So, and I did like to answer more directly the question to compare with Next.js and Remix, I would say like this. So, if you have a simple website, and you have a server, for example, Vercel, and you don't care, it's not like very critical website that has to be running like 100% time. So, and then I would go with Remix. Like you have server, you don't need to rebuild the pages. So, that's the feature that like only in Next.js. And then it's like, it's a small project, like not critical. So it's absolutely fine to go with Remix, and I would go with Remix. However, like if you have a long term project or there are other people involved in this project, for example, many different developers and they already have some experience with Next.js, or maybe if there is like a huge project, or even if you want to be a little bit closer to the standards of React. Because another thing that I mentioned in Beta of Remix is they like put focus on, is the server-side components, yes. React-server components, most precise name. And React is working hard on them. I saw in their blog there is like some article from me the last time I checked. And it was like a month ago. So they're still like working on it and they're like thinking how to create this React-server components. And they already mentioned that it's a hard technology. So it's like, it will be challenging and people need to have some support with this. And then like Next.js is going to support React-server components natively. So there's like a framework of their choice because like if there is like a challenging technology, it's easier to pick one framework that is going to work with this technology and then adjust this technology for this framework and wait for this framework to adjust for this technology rather than like work with everyone else. Of course, this probably is just the beginning.

Remix and Big Projects

Short description:

For personal projects, Remix is ideal. However, for big projects, it is advisable to be cautious. Remix was recently acquired by Shopify, which may lead to a more specific focus on serving the needs of Shopify. This could result in less community support. It is risky to bet on Remix in the long term, especially with version two on the horizon and potential changes. It is recommended to wait and see how the community and Shopify develop the framework. Maybe in the future, Remix will support server-side components natively, but for now, it may not be preferable for large projects. Let's explore the practical exercises and take them offline to play with Remix.

Like later will be more frameworks. However, at this particular moment, that's Next.js. And then if you're like waiting for React-server components, if you're waiting for React 19 and you're going to stick with this React for like time being and your project is big or like you have other people in your team that already has experience. So then I would go with Next.js.

So, but for personal projects, more projects, Remix is ideal, I would say. Very cool. I think we covered all the questions. I would not come in a big project to use Remix. That's our summary. That was a question. Would it be our suggestion for big projects to not use Remix? What do you think? I would say the moment, like to be careful with this. Yes, definitely. So, of course like, for example, Remix got bought recently by Shopify. So there is already a huge company that supports this framework. That's going to work and like develop this framework. This like the framework it gets the version two. However, there is like a plus, a pros and cons of this. And the cons is that maybe this framework will turn to a specific like to serve the purpose of the one particular company of Shopify. And then the community will get less of it. So at that particular moment, I would say it is quite risky to put a bet on Remix in the long term. Especially now they're working on the version two. So there is like quite some changes coming. So I would a little bit wait for it. In a half of year, in a year that will be clearer how the community react on this purchase, how the Shopify develop this framework. And then what's like the future of Remix. Maybe they're going to support service add components natively. Maybe that will be the choice of the React team. So maybe at that particular moment, it's not preferable to go with the huge large projects for Remix. Maybe to little, like to wait a little bit. So that's... Yeah. I think it's a good summary of it. I agree.

Yeah. I think we don't have that much time left, so maybe we are not gonna do the live coding, but let's explore the practical exercises that we prepared. Maybe you can take them offline and play a bit with the Remix. So Pavlik if you can go to the issues please, that would be awesome.

Sure. It was in the beginning, I think of this page you can find that code. I'm afraid and like in this incognito tab, I'm not logged in. Okay. I will just send it to the message share box. Yeah. Yeah. So I can also stop sharing the screen if you're sharing and then you can also show them. I think it's a good idea to go through the the issues. Just- Yeah, yeah. I just shared. Yeah. That's fine.

Workshop Tracks and Final Words

Short description:

We have prepared two tracks for you to explore. The first one involves creating an Express server adapter for the Ease Build Compiler. You can also use data from API endpoints in your backend components and migrate to using streams instead of render to markup. The second track focuses on working with Remix to load and update data. Each issue in this track provides a link to the documentation for reference. We hope you enjoy the workshop and encourage you to provide feedback. Thank you for your time and good luck with your coding endeavors!

Thanks. All right. So yeah, what we composed for you, if you'd like to play a bit more, let's just quickly discuss them. So, we prepared two tracks for you. First one I will, since I'm sharing and already talking, I will start with the backend sort of track. So, it's about the experiment that I showed in the beginning. So, what we propose to you to do, first of all, I think it's not a big task itself. You can play around and make another server, let's say express server, express adapter for the Ease Build Compiler. So I described a bit the situation here. You can start just from where we showed it in the Ease Build experiment. And then, yeah, either I modified or just added another adapter. So yeah, feel free to play with it. I think it's nice if you want to explore a bit express and how can combine API with components rendering end points. And the other one indeed is like, that's already more complicated might be. So in this one, you need to explore how you can use the data from the API end points inside your component, on the backend side. Shouldn't be very difficult. I think, I hope the explanation helped with that. But idea is that you're gonna use the data from the route end points that's produced at the JSON. And you will use as data in rendering component. And last one is to use streams instead of the render to markup. If you remember that strategy. So what, server-side rendered components that what Remix sort of does. And the idea in this last one, which is, I guess the most complicated is to migrate to that approach.

Pavlik about the front-end maybe? Sure. This one is like quite maybe like a remix related around. Its idea of this is to work with the Remix a little bit to stop the Remix, to have the first round to load the data, the first round to update the data. So, and the idea of this issues like inside is that it always just has a link to the documentation in order to like learn the information about what's, how to do this. And the cycle idea that I had in mind for this is that the workflow would be just to learn the issue, understand how to do this, go to the documentation and then do it. And then with this cycle, with this workflow to get acquainted with the documentation and then if you're working on your own the remix project, then you're already familiar with the documentation, how to find it, how to get it, how to use it. So that was the ideas of those three issues.

Nice, nice. Yeah, then. Yeah, sure. Bruno, yeah, I think Nikolai said it will be all recorded and available in a few days if I'm not mistaken in the Git Nation portal. So it should be all good. I hope our beginning conversation is not there with the we discussed the graph kill over rest API or something like that. Yeah, and with that, I can say just some final words. Yeah, if you liked the workshop, please let us know. If you don't like the workshop, even more encouraging you to let us know why. Otherwise it was a great to meet you guys. Thanks a lot for your time. I hope to yeah, meet you in the other events and good luck with coding. Thank you very much.

Watch more workshops on topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Featured WorkshopFree
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions
Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Featured WorkshopFree
The Vue3 has been released in mid-2020. Besides many improvements and optimizations, the main feature of Vue3 brings is the Composition API – a new way to write and reuse reactive code. Let's learn more about how to use Composition API efficiently.

Besides core Vue3 features we'll explain examples of how to use popular libraries with Vue3.

Table of contents:
- Introduction to Vue3
- Composition API
- Core libraries
- Vue3 ecosystem

IDE of choice (Inellij or VSC) installed
Nodejs + NPM
JSNation 2023JSNation 2023
174 min
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
Featured WorkshopFree
This SvelteKit workshop explores the integration of 3rd party services, such as Storyblok, in a SvelteKit project. Participants will learn how to create a SvelteKit project, leverage Svelte components, and connect to external APIs. The workshop covers important concepts including SSR, CSR, static site generation, and deploying the application using adapters. By the end of the workshop, attendees will have a solid understanding of building SvelteKit applications with API integrations and be prepared for deployment.
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
JSNation 2022JSNation 2022
28 min
Full Stack Documentation
Interactive web-based tutorials have become a staple of front end frameworks, and it's easy to see why — developers love being able to try out new tools without the hassle of installing packages or cloning repos.But in the age of full stack meta-frameworks like Next, Remix and SvelteKit, these tutorials only go so far. In this talk, we'll look at how we on the Svelte team are using cutting edge web technology to rethink how we teach each other the tools of our trade.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.