Nuxt Server Components (with Julien Huang)

Hey, everybody. Welcome back to another episode of DejaVue , your favorite Vue podcast. You just don't know it yet Somewhat. Or maybe you do as we are quite some episode already, as you know. Otherwise, check out the other episodes as well.

Hey. How are you doing? I'm quite good. I was working, so just doing some PRs.

Yeah. Fair. Fair. Working working in your day job?

In my day job. Exactly.

Yes. So do you want to share with the audience what are you doing in your day job? What's, what's your what's your task usually? What are you using?

Yep. So, in my day job, I'm a front end developer at Leetchi in France. So we're basically having we just have a website that does Moneypots, you know, for solidarity events and private events. And so as a front end developer, I mainly working so I'm not part of the, like, the front end team, but more like on the back office.

Ah, okay. I understand. Yes. And they there you like, you work also together with with the back office team there, and you're have, like, the front end in solely your responsibility, or how is the structure there?

So, yeah, I'm mainly working on the front end part of the back office at Leetchi and I just like working with the project owner, that we just decide on task we need to do for, the next sprint. And during like 2 weeks, I just do open PRs and work on the code.

Nice. And so what's the tech stack? What you're using over at Leetchi for the back office?

For the back office and the front office, we're obviously using Nuxt on Fonten. What a surprise. What a surprise. Yeah.

Sweet. And I I guess you you're kind of okay with using it. Yeah. Could be could be worse.

Yeah. I don't know why. I I think, like, Nuxt is is a very good tech stack for front end, especially for me. I don't know why, but, like, There's maybe a small idea.

Great. But then before we get into all the details there, maybe let's let's go a few a little bit back in history. So, Jun, how long are you how long are you programming, like roughly now?

So I began learning how to code post COVID during during COVID, actually, actually because I lost my previous job. I was working on at an in an airport and like, you know,

all airports are closed. Yeah.

Yeah.

That that means you started learning how to code around 2020, 2021, something like that?

Yeah. In May 2020, I think. Yeah. In May 2020.

Crazy. And I mean, now you hear, like, in almost 4 years later, you're doing all these amazing things. Like, as mentioned in the intro, you're doing public speaking at meetups, at big conferences like Vuegis Amsterdam, which which we'll also talk about in a future episode, actually. A little spoiler ahead here. And you're you're also part of the Nuxt team.

Yeah. Especially for a developer, I guess. Even all my colleagues are surprised. Even I am surprised of how, like, how everything moved so fast since, since I started to learn. But it was honestly, like, pure grind. I could spend maybe 10 to 12 hours just learning, a whole day. Sometimes even more like spending maybe just sleeping, waking up, coding on yeah. Opening my laptop or my PC and writing code.

Wow. I mean, yeah, during COVID, I guess, the things to do were a bit limited as well. So that in a way helped speeding the process because like, okay, I can do that. No other responsibilities. Let's go for it. But like, how did you start learning to program, let's say? Because, okay, you you found out programming seems seems to be a good idea, very much in demand, interesting, And I guess you also like it somewhat, but how did you start, like, learning the basics?

Okay. So, I have some friends, so from back in high school and even, like, in media school. They went, so we chose a different path, when we were in university. I chose, like, to learn foreign languages, and they chose to go on an engineer path. So I basically just asked them what I could do.

Okay. Smart.

Yes. So they gave me the advice, why don't you try development? It was probably the best advice in, like, my whole life.

Pretty cool. And it must be pretty life changing as well.

Yeah. Exactly. I don't know what my life would be if I didn't choose programming.

Same, actually. Yeah. It's it's sometimes it's so interesting how these career changes or, like, these these decisions really are key points in life. And you just said you you learned 4 languages in university. So besides JavaScript and TypeScript now on the list, which other foreign languages, did you learn or you speak? I'm curious now.

So, yeah. So English, my main language, there was Chinese and German.

Really? Okay.

So we will have a little after talk then in German. Yeah. But like I only remember probably one sentence.

Oh, that's better than none. That's good. That's good. Sweet. And, yeah, then not then, like, after your your friends, that weren't into engineering said, hey, development sounds good. Then, did they also, like, point you into web development straight away?

I don't really remember, but, yeah, I think they told me about, web development.

Perfect. Yeah. Then you started in and were like, hey, that's cool. You can do things. You don't need much except ideas and laptop and some time, and and you got going.

Yeah.

And so you started learning HTML, CSS, and JavaScript first, I suppose?

Yeah. So, I followed an online course. So, so in France, we have like company or a school, which is called OpenClassroom. Okay.

I heard about it. Yeah.

Yeah. And yeah, I just took a few lessons on OpenClassrooms. So that's how I started to learn HTML, CSS, and then JavaScript.

Sweet. And I guess then at some point, the the difficult question came up of which framework to use because for everybody, like, using vanilla Java JavaScript every now and then, I I like to do that in workshops. And it's like, hey, let's build a to do list after learning all DOM operations. It's maybe not necessarily the the most scalable thing straight away. So, yeah, how how did it come, that you choose Vue, I suppose?

Actually, no. Oh. No. Plot twist. So Vue was the last one. I started with Angular, I think, but I gave up pretty much quickly because it was really hard. I think like types the fact that you have to learn a new framework and typescript like and the whole like, how the characters work. Yeah, it's very complicated. Then I had I went to try React, but, yeah, I don't know. I I just didn't like it.

But did you did you try it longer than Angular, or was React quicker out there?

Oh, no. I did try longer because I even went to well, after in my first job, I even used React Native. So yeah. But yeah, but for pure web, I don't know. I didn't have the feeling I had with you.

And then It

wasn't the same feeling, you know. You mean like A small snarkle.

It it was like was it less let's say it didn't click that well Or No.

Yeah, exactly. Okay.

So it's more about mental model. Yeah. I see. Yep. That makes sense. And then eventually you came to Vue after not being that happy with Angular, moving away from OOP decorators straightaway TypeScript and then React. You found Vue. And what what happened then?

Yeah. So I followed another online course on Udemy. And my first thought was like, why is it so easy? Like, everything made sense, especially with SFC. And this is probably what was missing on Angular and React. Well, now Angular also has have SFC now, thanks to Vite.

And and analog as well. Yeah. I remember Brandon Roberts pushing that more and more, and, people tend to like it more and more, which is great. So so SFC has really made a click for you mainly, I guess, because it's like really, okay, you have HTML and JavaScript and CSS, and that's all in one component. You don't need, like, multiple files for it and don't have to juggle around with JSX?

Yeah, exactly. So it's very easy to understand for like everyone, anyone, honestly, like from juniors to seniors, even like on my current job, I have a back end developer and he also thinks that Vue is very easy to understand.

Perfect. I mean, if even back end developer that are not that much into front end say that, that's always a good scenario.

That's a win. Yeah.

And I also agree. I remember when I started learning Vue, it was the same idea. Like, I came from Laravel back then, PHP and so on. And I was, like, not too crazy into JavaScript, but it felt really easy compared to React. For me, it clicked and, well, here we are now.

So for my journey into open source, it was my first job, I had the chance to do some, you know, research and development for a new product. At that time, we were doing it in Vue. Then moving on to Nuxt 2, I think it was like 2 years ago, NUXT 3 was not probably not even in RC. And so I wanted to just to try it out by moving the project to Nuxt 3. My first issue was open due to a missing feature. So we couldn't configure the which bundle of view Nuxt will use.

So you mean the runtime bundler reflected the templates compiled at runtime semi compiler or like the optimized one without a compiler, I guess?

Yeah. So I wanted to have the one time the bundle with the one time compiler.

And it wasn't possible. Yeah.

Yeah, it wasn't possible yet. And that's how I started to dig into the whole, source code of Nuxt and then Nitro because I had also to open, I think, 1 or 2 PR to Nitro to allow some more configurations.

So and then you opened that issue about the right, like, different view bundle, and you dug into the source code. And did you send eventually a PR to solve it or, like, to to have an idea or did someone else close the issue eventually?

Oh, no. So I opened the issue. I don't really remember, but I think Puya maybe Daniel was the first to reply and then Puya also replied, but they were both so welcoming, so kind. So I just wanted to do it. So I opened a few PRs and the actual PR to add, you know, at first it wasn't experimental, so experimental. Vu runtime I think or vu compiler.

Yeah.

That PR was open for I think for 6, 7 months.

Oh, wow, that's wild.

Yeah. In the meantime, there was I created my first open source package which was called Nuxt One Time Compiler.

I see.

Yeah, just change your configuration because I think also we had the issue, some issues on Next 2, which you had to set all aliases, all possible aliases for Vue to the one time bundle.

That makes sense. Yeah. And that package would have fixed it. And I mean, that that goes pretty much in line what's, I think what's recommended. Okay. Let's raise an issue. And if it's possible to implement it as a module, either as a proof of concept or, like, to something just just to show, hey. This is possible. It should be nice to be in the core, but here it's working already. I think it's always a good way to go.

Yeah. And and, you know, when you answer in an issue, you you answer it, you you don't talk. So people can't cannot know what tone you're using. Yeah. That's true. But Daniel and Puig are so good at answering, like, maybe it's from pure experience. The way they write, the answer just make you feel welcomed and gives you the motivation to dig into the issue.

Yeah. I second that. I also remember that very clearly back in time when I joined the core team in in 2018. Puya and also Sebastian were, like, all straight away, like, oh, yeah. So cool.

Maybe 1 year and oh, almost 2 years, I think.

Yeah, that's pretty fast. Giving like your first ever open source contribution, which was also pretty fast after you learned to program. So this is this is really like a crazy speed. And, yeah, it's it's amazing. It's it's really amazing to see.

Yeah. So usually, I I was working on server components and Nuxt Island, in the Nuxt core repository. So, yeah, usually, we have the office hours and each time everyone's ask a question, you'll probably see my name pop up on on the on the scene.

Yes. Exactly. At the office hours, it's really, really fun. Like, every 2 weeks on Wednesday, the next Discord, just a casual chat, no recording, just an hour of q and a checking in. That's really cool.

Okay. So short version is server components are components that are only rendered server side, and you don't import any JavaScript for it, to render it in in your browser. It means that, well, it's a bit lighter, and, of course, you don't have any interactivity.

Okay. That makes sense. So it's really just like here is more or less. Here's the HTML. Vue just inserts it, and that's it.

That's it. Of course, there's some a bit more features, but, yeah, we will probably talk about it.

Oh, exactly. Yeah. So so, I mean, this this sounds pretty cool if you say, okay, you have a certain part of your website that doesn't need interactivity. So we can just, like, okay. This is a server component.

I don't think you should use server contents for everything because, first, the way how they works is that we create a whole new Nuxt app or well, not Nuxt app, but Nuxt instance and view instance for each server commands. So it means that it can be heavy on your server, of course. Then also try to avoid hype driven development. Don't do it because it's new or everyone is doing it. You have always to think about pros and cons, when using a new feature.

Okay. Yeah. I mean, that sounds good. 1st, let's circle back. Hype driven development, I also get that.

Like if you want to use links in your server components, at the beginning we didn't have any possibility to make it interactive. I think Daniel made a plug in to do a workaround, basically just catching every single links and linking it to the current router of your main application. And we have a new maybe directive, I don't know how to call it. It's not v dash something, it's called Nuxt client. So you just have to put Nuxt client as an attribute or prop of any actual component and once client side, Nuxt, we simply import the chunk and render your components like any normal component and make it interactive.

Okay. So you basically have, let's say, interactive islands inside server components once again.

Yeah. So you haven't so you have your, your main application interactive. Inside, you have an an interactive and non interactive island. And inside your non interactive island, you can have some interactivity.

And can you have, like, another noninteractive, like, server island in that interactive part again? Like, can we recursively do that again and again and again?

It would be technically possible. I don't sorry. I'm not sure if the performance will be good, but it's technically possible. I don't know also I also don't know if the hydration would work correctly, but I guess probably because of suspense. But yeah, it's possible. I just don't recommend it.

It just yeah. There's a yes and a big but there. Yeah. Okay. I see. I see. That that sounds good. And let's say you have a server component, and you said there is I said there's no interactivity. But what if I want a server component that has some properties? So let's say I have I have my, like, CMS renderer server component or, like, server on there, and I want to make sure that I can give it, through props, like, certain HTML to render or, I don't know, want to change a version of that.

So server component is, by definition isolated from your main NUCs application, you have only one way to pass additional data, it would be by props. We just have like a small limitation is that you cannot pass too much props because they are, stringified into queries and then yeah. You know, it's the oh, I don't remember the HTTP code. Maybe 4 31.

Oh, yeah. We're through out too long. Yeah.

Yeah.

I see. Okay. So but that means you can have server components that can have props. And what if you change a property? Like, let's say, okay, you enter the server component and then you have button that changes the property because, well, reactivity still works in Vue as I assume. What happens then with the server component?

So server components are basically Nuxt Islands, which is a one time component, present in server side and client side. So the way if you pass any data to your to Nux Island, it will be reactive. So if you have, for example, put down a prop or changed the name of the next island, it will refetch the island to your server and then re render your component client side. Of course, since it has to make another fetch request, it will not be instant, that's why you don't do server comments for like very interactive components.

Because of like the big delay in between because of the API calls again or, like, fetch calls again? Yep. And I think now you just said 2 important things. So first of all, reactivity still works. Even though it's a server component, there's no JavaScript coming. It can still be refreshed based on the reactivity of the data. Right?

Yeah. So the way, Nuxt Island is the one time command and it returns a static vNode, which is what has been rendered by the server. So you have like your main app, then the content Nuxt Island which will change what's the static vNode based on what has been returned by the server. So everything between your main app and Nuxt Island is interactive. So if you change maybe a prop, Knox Island will just render.

And then you call to the server getting the new, like, HTML to insert from the server there.

Yeah. Okay. Except if, like, so next I fetch your component and it will cache it. If NuxtIron has already a cache version of your components for some name, for a specific name and specific props, it will just retrieve it from your payload.

Okay. So can you just reuse it then if it's already there with, like, give a name in it's the same name as before, like 2 calls before, I would just reuse it?

Yeah. It's to avoid, like, having multiple fetch requests.

That makes sense. Yeah. And you already mentioned so we go into the Nuxt Island component in a bit, but we just fetching. So maybe let's let's paint a big picture again because we talked about Nuxt server components and that they come from the server. Now we talked about reactivity so that they can actually be re fetched somehow.

Probably, like, any normal component.

Okay. So so but there's no JavaScript. Right? So what what will happen? Like, what will be fetched from where? How how does that work?

So Nuxt Island, when it has to render for the first time, it will make a fetch request, let's say client side. It will make a fetch request to your Nuxt server at a specific endpoint. So we have like a reserved endpoint for Nuxt island, which starts by nuxtisland, yeah, I don't remember well, but should be the name of your component and, the all the context, which mean the props, which has to be passed down to the item component. Then, it will receive the response and simply return, so the response will have the HTML part, the HTML rendering of your server components. What else, and that's probably everything, I guess.

And then from there on, it goes as before. Yeah, okay. So the good part is even though you're in an SPA, and I presume even if you use Nuxt with service, the rendering falls, then you could still use Nuxt server components because they only depend on the Nuxt, the Nitro instance being available and giving you the server components, not necessarily on running server side rendering. Right?

So, I'm not sure about SSR. We probably had yeah. We had an issue about that, and it got fixed. So, yeah, you are not required to have SSR true to use islands.

Nice. But that also means that we talked about the Nuxt Nitro server very often. That wouldn't work if the the Nuxt Nitro server is not available because then the request will go into nowhere, I

assume. Yeah. Exactly. So if your your server is not available, it will have an error, and Nuxt Island will emit an event, we also expose an error reactive object. So you have multiple ways to handle, NoxIron errors to maybe show something else?

Mhmm. Like, yeah. Hey. This this went wrong. Try again later.

The classic.

I see. But and and what is about, static side generation? Like, can I statically? That that also seemed like an interesting case, but then yeah. How does how does that work, if that works?

Oh, it works. So, Daniel made an incredible job about it, because I don't usually work with SSG and with server components, with SSG I mean, server components still works at build time, so at generation time. We will generate the well, you will make a request to your like local server, so because like NUCs is wandering each page, to generate the HTML and we still need to have a server that runs. And at that time, if you have a server component, it will make a fetch request your own server and retrieve it as a payload. So the server will generate a JSON payload so you can have it as a static, static file.

Okay. And that is then just delivered as JSON to your CDN and whatever, I guess?

Yeah. So it will be available as, as a static file. It means that it will only work with the the initial state of the server components. If you change like some prop, of course, the static file will not be available, so you will have an error.

Yeah. Unless you generated exactly that static file with that combination of component name and prop on, let's say, another page.

Yeah. But it's I think it's pretty rare.

Well, unless you build it like that. Yeah. Like, I mean, you can also you could also provide through for, like, the routes array. Say, like, hey, I want to prerender that server component with these 10 prop presets, and I guess then you're good to go. Interesting.

So what's currently not experimental is like nothing, I guess. So everything is experimental, and you don't need to enable experimental dot component silence to true to have server contents. We Nuxt will detect on the if you use any island or server commands in your Nuxt app and enable it automatically with the, like, basic features. So it means that you don't have Nuxt Clients, in your server components. And it's still experimental because the API may change, in the future.

Yeah. So, like, with Nux four, maybe at some point after Nux four release, that's that could happen. But, yeah, we'll we'll see. And now you mentioned the remote islands. So if if I understood correctly, this is a great feature.

So, you know, NoxIron make fetch requests, right?

Yes. Correct.

It means that you can basically make a fetch request to another server. So you just have to pass down a new prop.

That's a good point.

So you just have to pass down a new prop called source, to Nuxt Inon. So it's something only available with the Nuxt Inon component. We don't do it for server commands because server components are your own components. So you cannot retrieve it from another server. So Nuxtion will get the source PoP and call the, another server with that one with that, well, that

pop. And that works already. Did you just you just have to set you just have to set something in the config, I assume, Ed, because by default, it could also sound like a little bit dangerous.

Yeah. By default, it's disabled. It's still another configuration within the experimental namespace. So you have to enable I think it's experimentalcomponentssilon. Remote or yeah dot remote. Oh, I forgot the name but yeah, there's a configuration.

Remote source or something. Yeah.

Remote source maybe, yeah.

And I also remember but TypeScript will give it to us.

Yeah, thank you TypeScript. And once you get it, once you enable it, you will be able to use it. You don't it don't it doesn't have to be a Nuxt server, you can also do it with basically anything that returns you a JSON response. It has to satisfy the NUCs INOM response type which means it has to have an HTML property that contains what has to be rendered. And then you can use it.

And that's the hard requirement, basically. Okay. I see. Interesting. But that also goes in line with what you said of, okay, what if the the types change and it's not called HTML anymore but differently? Then also the remote islands would have to update their format because, well, otherwise, it wouldn't work anymore.

Yeah. That's why it's still experimental. Yeah. We're we're still looking for how to make it stable and the best API possible.

That makes sense. Yeah. I mean, we also in the end, everybody appreciates stable server components, and that's, that might take some time, but you can you can already use it right now in your Nuxt application. I guess, just make sure to pin the version, not that you accidentally update and then things break and you don't know why.

Oh, also small fun fact. I think you can yeah, you can also use high end components with remote server. So really, yeah, just don't do it. It's behind, just don't do it. You can, but I don't recommend.

That makes sense.

Because like you have yeah. You have you import external JavaScript. So within your own application.

Sounds risky. Then, yeah, fun to experiment with, but don't do it in production, guys. And so so we we talked a lot about what server components are, how to use them, what benefits they bring. Let's let's aim a little bit of the future. So do you personally have a certain future for server components in mind?

Oh, yeah. It's always you use it when you need it. Why use it when you don't need it? After all, there's always pros and cons when you use like some new tech or even old tech. And I don't recommend people using too much iron.

I see. I see. But I guess there are also ways to optimize that. Right? Just like, okay. Let's have a, I don't know, single markdown render or to pre render all these, information so you could still get a performant website out of it.

I guess we I'm currently looking into ways to optimize it. I didn't had a lot of like, findings, but maybe having a single phone may yeah, maybe not a good idea, but like to, to make the Vue and Nuxt app instance more performance for Inland. And, yeah, it will be quite hard to do it, I guess, but we also have our contributors, amazing contributors who are working like everywhere on Nuxt.

So it's also your chance to contribute, Get involved, and, maybe you will also start open source with Nuxt. Js. Be welcomed by any of us, the core team or other people contributing, and we'll we'll have a good time. So definitely recommended contribution guide is is linked in the show notes as well. And one more thing I was wondering about is, I mean, the main goal of server components is to reduce JavaScript send to avoid, like, hydration there as well.

So the other way around so Nuxt, Astro and Nuxt works work differently. In Nuxt, you have a single Nuxt instance for your whole app. And then for each I n n component, you will have another so an independent Nuxt instance. While in astro, they so they render the whole, the whole application and then you hydrate parts of it, client side. It means that every components on their side, they are not independent.

And then the whole page is rendered as a server component?

So, yeah, you will still have your main app, the layout, and then inside it inside you will have, Nuxt Island that will make a request to, to Nuxt and render your whole page.

So that's that's pretty close already to that. We still need a bit of JavaScript to boot up, like, Vue and Nuxt, but everything beyond that can be, if the page makes sense, right, server rendered with maybe a little interactive Nuxt link here and there or Nuxt image or a button for a modal and whatnot.

Yeah. Everything will work, especially when you can mix it with Nuxt clients. So you can make like small parts of your page interactive.

So we we're in a way, even though Astro and Nuxt work differently fundamentally differently, we're still getting close to getting, like, let's say, an Astro like behavior with lots of things not being interactive by default. And thus, we don't need to hydrate and to spend all extra JavaScript in Knox itself.

Yeah, it's different. The idea is closed, but the way they work internally is different.

Absolutely. That makes sense. But I mean, it's still nice to see that we have something that's while internally under the hood differently. It's comparable from an experience or, like, from like, what we want to achieve, which is less JavaScript, of course, if we don't need it. Nice.

So I don't have that much experience in web development. So as we talked about it in the beginning, I only have like 4 years of experience as a developer. But my personal opinion is that, so React was made first for client side rendering only, then they moved to server side only, which is quite weird for me because, like, JavaScript was made for browsers, and then you start to move your whole framework to, to server side. I kinda agree with Evan what Evan said, and I'm good with views and client side first and maybe having some, like additional features for server side which should be, brought by Vue SSL, at least not from Vue core, but for, from another package. And yeah, I don't think Vue will go to server side first in the future.

Probably not. Yeah. But it's I I also I also think that's a good point here, especially because I think lots of people nowadays use Vue still as, like, a drop in with a good old script tag and just using them on maybe a Laravel or Django and so on rendered page or just to say, like, hey, let's replace jquery. And saying that you can't use Vue easily as just, like, a simple CDN link to put in and then write your components might also upset quite some users because that's the main use case. Even if we all build our our things with with Vue and Nuxt only, there are so many people who don't.

And Vue is still labeled as progressive. So, yeah, you have to start by script. And I remember working with inertia. Js and Vue, and that was like an amazing experience on Laravel.

True. Also, Derek, shout out to to Jonathan Reining and team. Laravel, Inertia, it's a it's a really fun experience, especially I I definitely agree. And I'm super curious what the next things will bring, what the future will bring after Nacht four at some point. And, of course, this will also be a topic for the future, with a special guest on the podcast that's more closer to the restate probably.

Yeah. So, I'm available on, of course, GitHub, on the Nuxt Discord, so I think it would yeah, my should be my name and my first name and last name and also on Twitter. I'm not going to say the new name. Okay.

Great. Yes. The links, of course, to, all of Julian's socials, to the Nox Discord and Sauna are in the show notes as usual. And, yeah, anything else besides where people can follow you? Any any mentions, any shout outs, anything else?

Well, of course, to the whole Nuxt core team, I don't think we, I think that with them I learned a lot, like, my progression path has been has skyrocketed since, like, a whole year, also to the whole community, which I had the joy to work with. Many people who has much more experience than me, teaching me things. And, yeah, shout out to to the whole yeah, to everyone, basically, who has helped me to to learn so much.

Yeah. I I can only second that I think open source is once again, it's a great example how people can grow with open source. And, I also never had, like, a formal, like, supervisor, let's say, and open source really, really helped with that, becoming a better developer. So, yeah, last words for me is thank you, Julian. Thank you for joining for this wonderful dayjapu episode.

Thank you. Bye.