DejaVue

Welcome to the sixth episode of DejaVue! Alex is joined by another amazing guest - he is a Front-end Developer, Public Speaker and also part of the Nuxt.js core team - Julien Huang.

While Michael is still off on paternity leave, Julien and Alex talk about how Julien started to code (during COVID 😲) and when he dabbled into open source, which culminated in joining the Nuxt team and regularly contributing.
One of the key feature that Julien is working on are Server Components - so of course the rest of the episode revolves around them. What are they? How do they work? And when should you use them? Julien will go in-depth on all these questions, give some behind the scene looks and "do's and don'ts" advice too!
Eventually, the future of Server Components is discussed.

Enjoy the episode!

Chapters
  • (00:00) - Intro and guest introduction
  • (00:50) - Julien's day job
  • (02:31) - His programming journey
  • (10:28) - Getting into Open Source
  • (15:47) - What are Nuxt Server Components?
  • (17:37) - When would you use Server Components?
  • (20:27) - Server Components and interactivity
  • (26:55) - How are Server Components handled on the client side?
  • (30:21) - Does Static Site Generation (SSG) work with Server Components?
  • (32:43) - Why are Server Components still experimental?
  • (35:02) - Remote Component Islands
  • (38:32) - The future of Server Components
  • (44:38) - Julien's thoughts on React's vs Vue's Server Component approach
  • (47:53) - Outro

Links and Resources

Creators & Guests

Host
Alexander Lichter
Web Engineering Consultant • Founder • Nuxt team • Speaker
Guest
Julien Huang
Nuxt team. Working at Leetchi. Learning from open-source.
Editor
Niki Brandner
Sound Engineer

What is DejaVue?

Welcome to DejaVue, the Vue podcast you didn't know you needed until now! Join Michael Thiessen and Alexander Lichter on a thrilling journey through the world of Vue and Nuxt.

Get ready for weekly episodes packed with insights, updates, and deep dives into everything Vue-related. From component libraries to best practices, and beyond, they've got you covered.

Alex:

Hey, everybody. Welcome back to another episode of DejaVue , your favorite Vue podcast. You just don't know it yet

Alex:

Somewhat. Or maybe you do as we are quite some episode already, as you know. Otherwise, check out the other episodes as well.

Alex:

Pretty amazing guests and talk about guests. Michael is not here once again because he is on well deserved paternity leave. Once again, congrats to him for becoming a father. It's pretty amazing, and we are looking forward to have him here soon again. But nevertheless, I'm joined today by another amazing guest.

Alex:

He's a public speaker. He is an open sourcerer and also part of the Nuxt.js team. Welcome, Julien Huang. Hey.

Julien:

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

Alex:

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

Julien:

In my day job. Exactly.

Alex:

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?

Julien:

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.

Alex:

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?

Julien:

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.

Alex:

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

Julien:

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

Alex:

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

Julien:

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.

Alex:

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?

Julien:

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,

Alex:

all airports are closed. Yeah.

Julien:

Yeah.

Alex:

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

Julien:

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

Alex:

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.

Alex:

So that all really evolved pretty fast, and it's amazing to see. I mean, COVID seems hopefully super far distant, but 4 years is almost nothing.

Julien:

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.

Julien:

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.

Alex:

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.

Alex:

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?

Julien:

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.

Alex:

Okay. Smart.

Julien:

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

Alex:

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

Julien:

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

Alex:

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?

Alex:

I'm curious now.

Julien:

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

Alex:

Really? Okay.

Julien:

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

Alex:

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.

Alex:

Then, did they also, like, point you into web development straight away?

Julien:

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

Alex:

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.

Julien:

Yeah.

Alex:

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

Julien:

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

Alex:

I heard about it. Yeah.

Julien:

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

Alex:

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?

Julien:

Actually, no. Oh. No. Plot twist. So Vue was the last one.

Julien:

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.

Alex:

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

Julien:

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.

Alex:

And then It

Julien:

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

Alex:

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

Julien:

Yeah, exactly. Okay.

Alex:

So it's more about mental model. Yeah. I see. Yep. That makes sense.

Alex:

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?

Julien:

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.

Julien:

Well, now Angular also has have SFC now, thanks to Vite.

Alex:

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?

Julien:

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.

Alex:

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

Julien:

That's a win. Yeah.

Alex:

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.

Alex:

Lovely. So then then you learned Vue, and, you you use that to to build certain things. And how did you how did you then tap into open source? How did that start in your journey?

Julien:

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.

Julien:

So we couldn't configure the which bundle of view Nuxt will use.

Alex:

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

Julien:

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

Alex:

And it wasn't possible. Yeah.

Julien:

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.

Alex:

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?

Julien:

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.

Julien:

Vu runtime I think or vu compiler.

Alex:

Yeah.

Julien:

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

Alex:

Oh, wow, that's wild.

Julien:

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

Alex:

I see.

Julien:

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.

Alex:

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.

Alex:

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.

Alex:

Similar to what Puya did with the build cache module, and if anyone in your audience didn't hear about that, link to the video and to the modules and, of course, in the show notes. So I I really like to see, first of all, that you are welcomed so nicely in the community, and then that you that you just straightaway said, like, yeah. Let's do it. Let's open the PR and also just straightaway publish, an NPM package solving that for people. That's pretty

Julien:

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.

Julien:

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.

Alex:

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.

Alex:

And, yeah, I just got to contact. But so it's really cool that you, like, joined open source, started open source journey with Nuxt itself back in the time. And, I mean, now you're here and you're part of the core team. So do you, like, briefly have in mind, like, how long it took you from your first open source contribution to to join the core team? Just, like, rough estimate.

Julien:

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

Alex:

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.

Alex:

I mean, I know you joined the Nuxt Insiders before, which is a group of, people that basically keep up to date what they're doing, like library authors, of course, people of the framework and team, the broader community. So, yeah, all all all, you joined, you joined the team. And probably, the people who have heard of you, they have a certain feature in mind when they hear the name Julian Huang or see your your image on GitHub, like, commenting somewhere. And for everybody who's not aware of that, Julian, you might wanna tell us what that certain feature is.

Julien:

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.

Alex:

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.

Alex:

But so you said server components or or server islands. Could you could you briefly run down what that exactly is? I mean, we both know, of course. We we talked about it quite some time, but just to give a really easy version, what's what what that means, like, just what it is and then what it means for people.

Julien:

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.

Alex:

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.

Julien:

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

Alex:

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.

Alex:

We somehow we'll come to that in a second, set it up as a server component, and and and use that. But when exactly would you recommend people to to use these server components? These are, like, case events like, oh, yeah. That's perfect. You should always use a server component here or, maybe here and there that could be worth it depending on what you're doing.

Alex:

Are there, like, any rules of thumb where you say, that's it?

Julien:

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.

Julien:

So for your current question would be like, I would use it for things like CMS, like, like whole static, portions of your application. You know it's only to, like, render a thing that your user can cannot interact with. The most easy example will be a CMS, that stores your, like, maybe HTML in a database, like, some old WordPress thing, and you can retrieve it, then render it. You can also access to any server side stuff like private config, private one time config, without like, being worried to leak it because everything wants server side. Of course, you don't have to put it into the HTML, but you can use it to do operations, maybe an API call.

Julien:

Yeah. I don't know. Maybe so that's some easy example, I would say.

Alex:

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

Alex:

Like, I think it's really nice to play around with new features. But when actually choosing them for a production level application, then, of course, consider why you would need it, what the benefits, and and, of of course, also the downsides are. So I'm I'm fully there with you, Julian. And with the examples, yeah, so you just said, okay, typical, like, CMS, let's have some, let's say, HTML stored and it would just, like, be a long block of different nodes. Then you say this would make sense to just be running a server component.

Alex:

Okay. And what if I say, yeah, there are some I don't know, some links in there, in that HTML or I want to have, I don't know, I have I have a big component rendering some some other components. You just said there is there is no interactivity possible because there is no JavaScript, right? It's all coming from the server side and there is no JavaScript included, so just the HTML. So how does that turn out?

Julien:

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.

Julien:

It means that you can, for example, set Nuxt clients on a Nuxt link within a server command and have it interactive, client side.

Alex:

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

Julien:

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.

Alex:

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?

Julien:

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.

Julien:

I just don't recommend it.

Alex:

It just yeah. There's a yes and a big but there. Yeah. Okay. I see.

Alex:

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.

Alex:

Is that still possible, or are server compilers, like, fully stateless and they can only render like one thing?

Julien:

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.

Alex:

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

Julien:

Yeah.

Alex:

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.

Alex:

What happens then with the server component?

Julien:

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.

Alex:

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.

Alex:

It can still be refreshed based on the reactivity of the data. Right?

Julien:

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.

Alex:

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

Julien:

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.

Alex:

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?

Julien:

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

Alex:

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.

Alex:

So so maybe let's let's make it clear one more time. How do server components work after the initial rendering? Because during the initial render, of course, it will be just your server application will be service that rendered. Right? But what happens on the client side?

Alex:

So you go from /a to /b. You have a typical SPA, and on /b, there is a server component. So how will that be handled?

Julien:

Probably, like, any normal component.

Alex:

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

Alex:

How how does that work?

Julien:

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.

Julien:

Everything required at least, and then just return the content in as a stativ node.

Alex:

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?

Julien:

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.

Alex:

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

Julien:

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?

Alex:

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

Julien:

The classic.

Alex:

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?

Julien:

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.

Alex:

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

Julien:

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.

Alex:

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

Julien:

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

Alex:

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.

Alex:

So we have server components that are detached from server side rendering still work with SSG. And even if you would disable SSR, that's pretty amazing. Then I then I wonder, now that we have all that, it's still under experimental. So to enable it, we have to set, like, experimental and then, I think, component islands to true. Or nowadays, if you just start a dot server dot view component, it will be enabled, I think, by default.

Alex:

Nuxt will do that for us. So why is it still under experimental? What does that mean?

Julien:

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.

Julien:

It has changed multiple time because we still haven't found, not a good API, but like, I would say a stable one. Everything can change within it like internals. Also, we have remote island, so which is the capability to call another server to render not of course, not components. You can do it, but like static HTML. And they will be relying on some types we are using internally at Nuxt for Nuxt Island, especially the response type which can change.

Julien:

So these are yet to experimental, I don't know when they will move out from experimental state, but probably probably not in the final meeting month.

Alex:

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.

Alex:

So you can actually get remote content, which could be another Nuxt application serving, like, server components or technically anything else. So how does that work?

Julien:

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

Alex:

Yes. Correct.

Julien:

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

Alex:

That's a good point.

Julien:

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

Alex:

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.

Julien:

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.

Julien:

Oh, I forgot the name but yeah, there's a configuration.

Alex:

Remote source or something. Yeah.

Julien:

Remote source maybe, yeah.

Alex:

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

Julien:

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.

Alex:

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?

Alex:

Then also the remote islands would have to update their format because, well, otherwise, it wouldn't work anymore.

Julien:

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.

Alex:

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.

Julien:

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.

Alex:

That makes sense.

Julien:

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

Alex:

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?

Alex:

Do you think, like, that could be, something that's used more in applications, or do you think there will be more of a you use it when you need it case?

Julien:

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.

Julien:

1st because like we had an example, I think so maybe just in from time view, I have to confirm it. I think had an issue with Ion component because there was so many island components within a single page that the first vendor took a really long time to the server took a really long time to render the response, because you have the island content and a markdown renderer behind it. So each island was using the markdown renderer and if you end up like maybe with 10, 20, or 100 requests at the same time, the poor server yeah.

Alex:

I see. I see. But I guess there are also ways to optimize that. Right? Just like, okay.

Alex:

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.

Julien:

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.

Alex:

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.

Alex:

Like, then you don't have to go through all the dominoes because, okay, that's static. It's sent over. It's fine. And probably also to move the CPU heavy tasks, maybe more on the server than on the client. But do you think there is a future where maybe Nuxt would go like, hey, the whole Nuxt app is a is a server component, and then we only have small little interactive pieces.

Alex:

So think of an Astro for Nuxt because right now it's the other way around. Right? We have clients only thing or, like, we have a client based system. It's server rendered, of course, but everything is interactive by default, and then we have static islands. So what do you think about the whole thing the other way around?

Julien:

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.

Julien:

They are in the main instance when Nuxt is completely isolated. We currently have server pages in Nuxt, so you can already use it and so you don't need to enable any additional flag in experimental, you can just create a dot server dot view, component in your page directory, and it will just work.

Alex:

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

Julien:

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.

Alex:

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.

Julien:

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

Alex:

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.

Julien:

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

Alex:

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.

Alex:

And maybe maybe one question for to to slowly, slowly wrap it up, but just one, let's say, one interframework question. You probably also noticed React going a bit like server first with React server components built into React itself, saying React shouldn't be used without the framework anymore and so on and so on frameworks implementing server components like Remix, like Next. Js, 10stack start in the future, too. So what do you think about that approach versus Vue's approach? And Evan Dyer said, for example, that Vue is not going that way of including server components as like a first class citizen in Vue itself and that these explorations should rather be in the meta framework.

Alex:

So next, what we are doing. What do you think about that?

Julien:

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.

Alex:

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.

Julien:

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.

Alex:

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.

Alex:

Nevertheless, a last question for you, Julian. Where can people follow you? Anything you want to share with the people before the end of the episode? Any last words, so to say?

Julien:

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.

Alex:

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?

Julien:

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.

Alex:

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.

Alex:

I'm more than sure, you will come back when there is some more news about server component or maybe other interesting topics. So, yeah, thanks everybody for listening. Tune in next week again with yet another episode. Take a look or also listen the other episodes before, and then see you next time, folks. Bye.

Julien:

Thank you. Bye.