Sitemaps, SEO, and Nuxt with Alexander Lichter

EPISODE 49

[EPISODE]

[00:00:10] BH: Hello, everybody. Welcome to Enjoy the Vue. I am Ben Hong. Today on our panel, we have Tessa.

[00:00:16] T: Hello.

[00:00:17] BH: Our special guest for this episode is Alexander Lichter. Alex, would you like to introduce yourself?

[00:00:23] AL: Hey, for sure. Thanks for having me. Yeah, I’m a web development consultant at my own cellphone and company development and I’m also a Nuxt.js core maintainer.

[00:00:33] BH: Very cool. I got to say, I always admire people who are running their own consultancy business. I know. That's a whole topic in it of itself, so we'll touch on that another time.

[00:00:42] AL: True. Future episode coming.

[00:00:45] BH: Yes. In terms of people getting to know you who might not have heard you talk at various conferences, let's talk about some of your origin stories. When did you start getting involved with web development?

[00:00:57] AL: So — first time I really touched web development was when I went to school, was 14-ish, I would say. I started classic with PHP. I stick around and —

[00:01:07] BH: PHP.

[00:01:08] AL: Yeah. I’m still using it today.

[00:01:11] BH: Nice.

[00:01:11] AL: I stuck around the whole ecosystem a bit. Yeah, I started with simple things, like Joomla, WordPress and stuff. But also building everything from scratch and then reinventing the wheel, but worse.

[00:01:25] BH: Nice. With PHP, most people end up staying within that realm. You're talking about WordPress, Joomla. What brought you to using a JavaScript framework? Because that's a pretty big paradigm shift, I imagine, from a work perspective.

[00:01:38] AL: Definitely. Well, it all started when I discovered Laravel as a PHP framework and used that for quite a few custom applications. Because WordPress wasn't enough and it was just having lots of dirty hacks to make WordPress do what you want and — ah, no. Then I got to Laravel. Of course, after getting into Laravel and programming a few applications here and there, I found out about Vue.js., of course, because also, of the friendship of Taylor Otwell of the Laravel community and the Vue community, of course.

I got to use Vue in Laravel, because it was so easy to get started and the docs were really amazing and they still are. I mean, they're so, so good. Yeah, that's basically how I started using Vue.

[00:02:20] T: It's okay. You don't have to say the docs are amazing, just because Ben’s here.

[00:02:27] BH: Well, so then speaking of Vue, you had mentioned in your introduction earlier that you helped to maintain Nuxt. Just as a refresher, can you tell people who might not have heard of Nuxt? What is Nuxt as far as the Vue ecosystem is concerned?

[00:02:39] AL: Yeah, for sure. To summarize in actually a few sentence, it’s not that easy. Nuxt, it’s a meta framework. It's a framework on top of Vue.js. I would say, the main goal is to make the developers lives’ easier and to make it easy to develop powerful web applications. The idea here is to be versatile, to offer sensible defaults that can be changed, but you can get started very easily and you don't have to configure lots of things and add in some modules, or some packages. You just get started right away. If you want to change something, for example, to optimize stuff, you can do it of course through a centralized config file.

[00:03:17] BH: Very nice.

[00:03:18] T: I’m going to ask you the same question I asked Debbie, which is when would it be good to use Nuxt? And when would you recommend that somebody not use Nuxt?

[00:03:28] AL: Yeah, let's start with the second part of the question, because there's always one use case. I personally say, I don't use Nuxt there, because it's not really possible. That's also where I actually come from. If you have a Laravel rendered application, so a PHP application, Python, whatever, that's already server-rendered traditionally and then you want to use a framework like Vue to enhance pages. To add some fancy dynamic components and sprinkle a bit of JavaScript in there, that's not a use case for Nuxt.js. Besides that, the sky is the limit.

[00:03:59] BH: I love that answer. That is great. When it comes to Nuxt, if you had to pick your favorite feature from Nuxt, what's the hot thing that you would write a blog post about today?

[00:04:11] AL: Oh, that's tough, actually. Because at first, there are so many good blog posts already. I think, the best part is really how all the different parts play together, so that you don't have to configure lots of things. You just install it and you're good to go. If you say a centralized feature, or one of the main features, I would probably say the file-based routing, because writing router configs is — well, it's repetitive. And Nuxt.js all leverage the file system and you're good to go. Then definitely, that one, that's one of my favorites.

[00:04:42] BH: Yeah, that's definitely saved me a bunch of time, not having to define routes manually.

[00:04:46] AL: Yeah, same with Vuex modules if you use Vuex, right?

[00:04:49] BH: Mm-hmm. Recently, one of the big topics being discussed is the Nuxt content module. Have you had a chance to play around with that?

[00:04:56] AL: Oh, yeah. A good one. Yeah. I use it in a couple of side projects, actually. As it's strictly module, not a feature of the core. I wasn't able to pick that one, but it's amazing.

[00:05:04] BH: Fair enough. Fair enough.

[00:05:06] AL: Also, due to the live editing inside the browser by just double-clicking something that comes from Nuxt content, it's almost like pure magic. Kudos to maintainers. It's pretty good. I love it.

[00:05:15] BH: Yeah. Hands off to the core team for thinking of little developer experience, things like that, because I think I stumbled onto that feature by accident. I was trying to do something and then I was like, grab it and I was like, “Oh, wait. I can just edit it in the browser. This is amazing.”

[00:05:30] AL: Yeah. The good thing is — will be synced to your file and you're all good. It was also introduced in another version. So it wasn't there from the beginning. Whoever had this fault, it was like, okay, amazing. Really amazing developer experience. No self-praise. I’m not involved in module at all. Just saying that.

[00:05:48] BH: Well, so for those wondering though, you said you mentioned you are a Nuxt maintainer. What part of the Nuxt ecosystem do you have to contribute to?

[00:05:54] AL: That's actually difficult, because it's not like — I don't have a fixed role. When I got added to the core team, which was at the Vue.js London two years ago, so 2018. Time flies. I started contributing to various modules, also maintaining. Still maintaining some of my own modules under the Nuxt community umbrella. I also contributed lots of things to the core.

Now, that also Nuxt version two is on feature freeze, there's not much to contribute besides some back fixes, of course, there. What I mostly do is trying to help our people. Triaging GitHub issues, for example, helping on the Discord. Answering questions. Also, writing blog posts every now and then on my own blog, also on the Nuxt.js blog. Of course, then conferences, talks, Nuxtifying the world and so on.

[00:06:41] BH: You all have a great outreach team for sure.

[00:06:43] AL: True. Yeah.

[00:06:45] T: Besides Nuxt, what are other tools that you like to use when you are building websites, and/or —

[00:06:52] AL: I think, my favorite tech stack at the moment for public-facing websites, where I also have lots of time to implement a cool design and don't have to quickly putting up a prototype of maybe a dashboard with lots of functionality, I would say yeah, Nuxt for sure. Then, I would add as a CSS framework, Tailwind CSS for dashboards. For example, I really like to use beautify, because it's so easy to get things up and running quickly with lots of functionalities. I love to use Tailwind CSS, because it is also very flexible and customizable. Yeah, in the back-end, I still use PHP, but I’m happy with tinkering around also with Node and Python. Whatever fits.

[00:07:31] BH: Yeah, speaking of Tailwind, that has been generally, quite the buzz in the front-end community quite a bit.

[00:07:37] AL: That's true. Yeah.

[00:07:40] BH: People are reasonably skeptical. I guess to start, I mean, Tessa, if I were to ask you, what does Tailwind mean to you? How would you describe Tailwind to someone?

[00:07:49] T: A world of pain. No, I’m kidding. It's a type of CSS library in the vein of functional CSS, which basically means that you have a bunch of classes that each do one thing. It might set the color to red, or the background to blue or something. Instead of having assigning classes, or assigning styles to groups of elements by using selectors classes, instead you are putting these single-use classes, essentially, directly on each element in-line to prototype out styles.

[00:08:26] BH: What do you think Alex, as someone who uses Tailwind a lot?

[00:08:29] AL: Yeah. That pretty much hits the nail. The good thing here is that compared to frameworks, like Bootstrap, or also Beautify, or material design in general, is like a design system, you have the freedom to customize all the things. For example, if someone built like the Tailwind guys also did, say component library with templates, then you can just grab them and basically, it's just HTML and CSS. And you are free to change things around. Plus, also, Tailwind gives you, because it's very configurable and flexible, lots of options to enforce style guidelines and also, it provides more or less a mini-design system for you. You don't have 500 shades of green in your application and in your CSS, but maybe it's 10 and you're all good, or maybe even just three.

[00:09:20] BH: Yeah. I think the way you phrase that is really good, because most people are like — “Another CSS system, done bootstrap. I’ve done material. I just want to build my own.” I think the way you phrase it regarding a micro-design system is a great way of thinking of it, because I’ve had a chance to play with it a bit too.

While there are times where certainly it's faster for me to write my own CSS, I think I agree with Alex in that it really does provide that structure. Especially on a — as your team gets bigger for how utility classes are named. It has an opinion that then you can then customize on top of it. I think that's probably one of the things that makes it incredibly powerful and why it's so popular.

[00:09:55] AL: Definitely. Plus, the good thing is you don't have to name things. That's a really huge pro in my opinion. Even though, sometimes people say, “Okay, the template or the HTML is a bit cluttered because there's so many classes.” And yeah, you have to get used to that, that's true, you know exactly how each of the DOM elements behaves, more or less. Because you directly see, okay, this component has, say, rounded corners, or this component has a background of red 500, or however you configure your colors. Then you know exactly what happens, while if you use Vim, or a similar syntax then you know, okay, this is a card header. And maybe it's a card header around it, but you don't know, okay, does a card header have maybe a shadow defined by default? That's not what the name can tell you, for sure. I think that's another pro here.

[00:10:42] BH: Yeah. And I know that recently, you had an episode where you were with I think, Tim Benniks, trying to convince him. He was definitely a skeptic.

[00:10:48] AL: Exactly. Yeah. We had a long talk, actually. Unfortunately, the recording so we tried out Zoom there, didn't went very well. We talked, I think, for more than one hour. It was really amazing. Showed him all the beauty of Tailwind and also, the plugins, like the typography plugin, which is amazing standalone. Because you can just add one class and get default styles for your whole content, be it headings, paragraphs, lists and so on. It's fully configurable again. That was really cool and I’m happy that he might consider trying it out.

I remember a couple of days later, he wrote me a message. He said, like, “You know what? I’m trying this cool new thing here and I’m constantly thinking about adding classes and adding utility classes.” That was the moment I thought, “Hey, maybe he'll try it out.” I’m looking forward to that.

[00:11:35] BH: Yeah, that's a big win for sure. For those who haven't watched the episode, we'll make sure to include that in the resources, so you can check it out.

[00:11:42] AL: Perfect.

[00:11:43] T: One question I have when it comes to utility for CSS, because my team uses tachyons, which I believe is similar, but I could be wrong.

[00:11:53] AL: No, that's correct. Yep.

[00:11:54] T: Yeah. When you need to custom style a component, how do you divide that across your utility CSS library and doing styles the more traditional way, like in the style tag, or maybe with a CSS module? Because sometimes when debugging, I find it tricky if I’m expecting something to be either in the template, or in the styles, but it's divided across both.

[00:12:20] AL: I see. What I usually try — and to avoid custom CSS as good as possible. So I’m using Tailwind since 0. -something, so quite early and got released, I think, on Halloween two years ago roughly. Don't nail me down on that. Back then, there were a couple of utilities that weren't added. For example, it wasn't clear if we add position sticky utility class, because of IE support, and it's now there. Or, utility classes for transform, so translates and rotation and so on, or animations, or gradients and they're all there now.

Back then, I just tried to add new utility classes and it's really cool, because with Tailwind, you can also say, yeah, this is a utility class and you add variants. For example, utility class for hover. It's the same class, but just with the hover prefix and it's all there. You can reuse these classes. If it's really not possible, because it's something very fancy and you can't use that, then I try to use it in the style tag, because if it's really not possible otherwise, I go with that way, usually scoped. Then, you can use Tailwinds at apply function in that CSS, because it goes through post CSS.

Then you can if you want, apply Tailwind classes to for example, pseudo elements, like before or after. Then also, most leveraged Tailwind CSS power, even if it's a custom class there. I agree. Looking into the template and then maybe having to look through another source of truth there is a bit tricky. Ideally, this should happen very often Yeah.

[00:13:52] BH: Yeah. I think you're totally right. I think one of the things that finally sold me on Tailwind as I started using it was exactly that apply function. For those who've never used it before, envision that when you're writing your CSS. It might be .mycustomcontainer. Rather than writing explicit like, border radius 50%, you have utility classes that you apply. It might be like, apply — I don't know what the Tailwind border radius is. That says BR50 or whatever.

What you get is in a way to standardize, apply — this is particularly useful for units, like margins and padding. Then it just becomes part of your CSS class for those of us that still want to wrap custom classes for easy identifiers. But you're still leveraging the design system and not necessarily what you see some people advertise Tailwind as, which is a bunch of utility classes directly on the HTML. I don't know if, Alex, what do you think about that, but that was one thing that sold me.

[00:14:44] AL: It's definitely a huge pro, especially if you're transitioning your code base. One advice that also, Adam Raven, one of the creators gave recently is the ‘yet apply’ class is the feature that's loved, that he usually not recommends using.

[00:14:58] BH: Interesting.

[00:14:58] AL: It's mostly because if you say, if you have a component, you want to make class say, I don't know, card again. Then ideally, you should make a Vue component out of that part. You should use the framework, whatever you're leveraging. But Of course, sometimes it's not possible, because some frameworks don't have these component systems. Or if you're work in a PHP application, then there might not be any components, then you of course, have to go back to the reply function.

In the end, it's however one would like to use it. As long as you're consistent and have some rules where to use that apply, where not, it's all good. Especially for custom utility, or classes for features, as I mentioned before, when I created some gradient classes, then of course, I used colors from my config and not hardcoded them in. But used another option to pull them directly from the config. Definitely use cases there.

[00:15:51] BH: Awesome. Well, so we talked a bit about Tailwind, which again, if you all haven't had a chance to try it out, again, watch the episode with Tim and Alex. As you probably — Alex, there is a really progressive way of using Tailwind, so don't feel you have to buy into it immediately. I think I started using it with Nuxt. The first thing I got the most value out of was just the standardized typography ramp and then the margin ramp. I think that's what I use it for a lot.

[00:16:16] AL: Spacing is so good. It's just being standardized. It's really gifts sent from heaven. I’ve had it so often rewriting custom CSS, being like, okay. I usually declare variables, but then sometimes you forget it, or just having a quick hack and so on. One of the things that came out recently and which I mentioned slightly before is the typography plugin, which is, it's huge. What it does is you can add that as a Tailwind CSS plugin. You only have to add one class, which is called pros, and then it will format all content inside that, for example, div.

[00:16:51] BH: What?

[00:16:51] T: It’s especially cool for blogs, where you have, okay, I want to have the same style, but I don't want to style all the things. Or if you for example, have Nuxt content use and you pull things in, you can just use the pros class on the wrapper and you're all good.

[00:17:04] BH: Oh, I need that. I said they're defining paragraph spacing and line heights and — oh, my gosh.

[00:17:11] AL: I have the two. I really have to update my website too for that, because again, it's fully customizable. It does code highlighting. It handles so many cases. Also, nested lists and having done bolds, items in that list and so on. There's a really good example page where I think, it was also Adam listed a bit of text there and all these variants and said like, “Hey, this is all we thought about.”

Again, it's 100% customizable. If you want to say, “That's what I usually do for links,” if you hover over them, then by default, they're not underlined. If you hover over them, they're also not underlined. I always want to change that to give a bit more feedback. This is just one line in the config to do that and you're all good.

[00:17:52] BH: Wow. Well, I know what I’m doing after this.

[00:17:56] AL: Really worth digging into it. Plus, it works well if you also have a custom Tailwind config, you can configure all these stuff and especially. If you have a site that has to be really, really custom, that's a perfect fit. Because again, it's not like, every site looks the same with Tailwind. That's also what they try to convey in their documentation. They give a couple of examples of buttons. Then the people reading documentation really don't have the feeling, okay, these are the three types of buttons that Tailwind covers. These are three examples of what you can do with Tailwind if you want to.

If you want to have something totally different, it's all good. There are also so many larger websites made with Tailwind, for example, I think the latest Diablo website was also made with Tailwind, that show also very customized sites can be made with it.

[00:18:42] BH: Very cool. When it comes to Nuxt, I know recently at VueConf US, I had the chance to hear you give a great talk about SEO. This is something that — web developers have talked about this and this is ancient technology. I think, we all know that SEO is so critical to the life and blood of actually having basically, our website surface when people are searching for things. I would love for you to talk a little bit about what is SEO, like, in just a regular Vue application world?

[00:19:09] T: Wait. Why don't we start with what is SEO?

[00:19:12] BH: Yes. Actually, let's go even further back. Yes, what is SEO, Alex?

[00:19:16] AL: Okay, perfect. SEO is Search Engine Optimization. It's not rocket science. It's not witchcraft. So no worries. It's basically how to optimize your page for the user. Then for the search engines. Though it's called search engine optimization, the user is actually the focus.

[00:19:33] BH: Ooh, I like that.

[00:19:34] AL: This is also what I tried to convey at the talk. First and foremost, it's really about the user, because thinking about that from a search engine's perspective, so Google or Bing, they want to deliver the best fitting result to the user. If you have an amazing page with great user experience and good content exactly the content that matches the search intent of the person searching on Google and putting in the keywords, then why shouldn't they deliver your page as number one?

All you have to do for that is basically somehow, conveying, or giving Google information about — “Okay, what is your page about?” You do that usually by having good content. Of course, you can optimize that. Now, there is also of course the power of the user, so the search engine users that click on sites. They don't know if the content on your site is good, if they have that list of results. Your chance, basically, to advertise your content and to sell your content more or less to use and say, “Okay, this is the best result,” is through the title of your site. It's also the title in your tab above and the thing called the meta description, which is a 150, 160, or shorter description about exactly that subpage or page.

I would say, these are more or less the basics. If you have that for every site, then you're already good to go. Of course, there's lots of testing involved. What is the perfect title? Should I include my brand name or not? What is the thing that the users are actually looking for? This is also an important part. Understand if the user, if they're searching for some term, do they want to inform themselves? Do they maybe want to buy? Are they maybe looking for a comparison, so aren't they sure what they want to buy? All these things are important for SEO. It's quite a broad topic, unfortunately. It's hard to summarize in a couple of sentences. Yeah. Basically, it's really about the user-first, those called search engine optimization.

[00:21:19] BH: Yeah, I love that paradigm, because we always talk about optimizing for the algorithm, like Google’s algorithm. Putting it user-centric is a great way to reframe the importance and humanizing the problem we're actually trying to solve when filling out these fields.

[00:21:34] AL: It's what they want in the end as well. I mean, Google created this huge algorithm that nobody really understands, nobody knows how it works, mostly to figure out what's the best for the users. Of course, also what's the best for the company. If they serve users good things, then people will use it.

[00:21:50] T: One thing that I remember stood out to me about your talk at VueConf US was that you mentioned sitemaps, which I feel is a word that I haven't heard in a long time. I was wondering if you could talk a bit more about that and how that plays into SEO.

[00:22:04] AL: For sure. In my opinion, every site should have a sitemap. The sitemap is basically an XML file that contains all important URLs for the site that you basically want to have indexed in Google or other search engines. Usually, if your sites are very well-connected, so they're linked well to each other, they’re discoverable by Google, you might not need a sitemap.

To ensure that all your pages are indexed, for example, if you have a large web shop with say, thousands of products, then you get subcategory sites and detail pages and especially e-commerce sites can blow up really quickly. You want to put in the most important URLs and the things that Google really should index in that sitemap, but then also, tell Google, “Okay, there is my sitemap.”

You can do that by either submitting your sitemap through the Google search console, which is a tool for webmasters provided by Google, where you can register a page and then just say, “Okay, this is my sitemap.” The other option is to define the sitemap in your robot.txt, which is another file where you can just say sitemap: and then the link.

[00:23:09] T: Do you have any tips then, if you want or need to build a sitemap, but let's say, multiple pages linked to the same final destination, or you need to dynamically add to the sitemap, like if you have a new site or something with articles and you want all those to be listed, how would you go about handling those cases?

[00:23:31] AL: Okay. The good thing is that most of this can be automated. Going for this mostly, because I use Nuxt as a framework. There is a module called Nuxt communities. I don't know. Nuxtcommunity/sitemapmodule, I’d say. Yeah, we'll link that. This should pick up your routes automatically. This is quite cool. If you have a static steadily generated site, then it will just get all the URLs during the build time and then we'll link to add. Then you have a static HTML file.

If you use dynamic servers at rendering with the Node.js server in between that renders the request on the fly, then it's also no problem and it will be calculated and cached. If something changes, it will calculate it again. Then you can, for example, provide the URLs through an API request, which will be then cached and maybe in an hour or so, revalidated.

[00:24:17] BH: Very nice.

And that's it for this week's episode. Join us next week to find out why Nuxt is great for SEO, common Nuxt questions and static site rendering.

[PART 2]

[00:24:28] BH: Welcome back to part two of our discussion with Alex. As we talk about why Nuxt is great for SEO, common Nuxt questions and static site rendering.

For those who are still nearer to SEO, jumping into web applications, people are probably wondering like, “Well, why would I use Nuxt to do SEO? Can I just use Vue? What are the benefits of using Nuxt overview?”

[00:24:49] AL: Very good point here. Yeah. When you have a vanilla Vue application, then of course, it's a single-page application. For single page applications, you get the JavaScript, then it will be parsed and the JavaScript will generate the HTML. So far, so good. There are a couple of problems here. The first one is not strictly SEO related, but it's still an issue. If you for example, share a subpage through Discord, or Twitter, or WhatsApp, or whatever, then you usually want to have the correct title and also description. Maybe a cool image has been listed there. Giving some preview images.

With an SPA, that's not really possible, because the text, so called OG text, open graph text have to be embedded in the HTML, because there's no real crawler running over that, understanding JavaScript and parsing the site. It's more like, okay, the HTML that will be checked and there's no tags, or maybe just the default title and that's it. That's the first one. The most important part here is Google can understand JavaScript, so it can index your single-page application. That's really possible.

Five years ago, maybe earlier, this wasn't possible. Most major search engines can understand JavaScript, but the problem here is, well, even if they understand JavaScript and can index your page, it doesn't mean that Google will say, “Wow, that's a really, really fast page, or really good one.” Because again, the JavaScript has to be there first. It has to be fully downloaded, or at least the initial one. Then the HTML will be generated. The time to first paint, or for core vitals, the largest content full paint will be quite slow, because again, the JavaScript has to be downloaded first and parsed and then the HTML will be generated.

While, if you use Nuxt.js with servers at rendering, no matter if you use their site generation or dynamic servers at rendering, then the largest content for full paint will be quite quick, because either you have a static HTML file with the content in there already, or the Node.js server returning the HTML and then your content is there.

[00:26:45] BH: That's a great explanation.

[00:26:46] AL: I hope there weren't too many unknown terms, like dynamic service and rendering. Should I explain that one maybe?

[00:26:53] BH: To be honest, I would say that's a good one to cover.

[00:26:55] AL: Okay, perfect. Starting with Nuxt again here —

[00:26:59] BH: Surprise.

[00:27:00] AL: There are lots of frameworks that can do service set rendering. For example, Vue press also just service set rendering, but only a build time. That's also what we know as jam stack, or static site generation. Because when you build your site, there will be a server generating the pages.

Technically, see, I would say that's a subcategory of servers at rendering, though the server is not always running. To make the difference between servers set rendering at build time and service at rendering on the fly, or how I call it, dynamic server set rendering. That's where you have Node.js server running all the time. The initial request and that's important here, the initial request will go to that server and the server will fetch, for example, data from an API and then render your Vue application, the current route that should be loaded for that user as HTML and deliver it to the user together with the JavaScript needed to build your Vue application.

The user will get the HTML with all the content already and can scroll and can look at it and while it happens, your Vue application will be downloaded, so JavaScript will be downloaded and parsed and Vue will do a so-called hydration. It will take the static HTML that comes from the server and transform it to a Vue's own DOM representation with your own vDOM representation to make it reactive again. Then, the page is fully interactive.

[00:28:14] BH: Fascinating. For those listening, so why would someone want — if you know what your site is in advance, then why would someone need dynamic server-side rendering?

[00:28:25] AL: Okay. Again, coming here with an e-commerce shop, where you say, like, “Okay, I want to have the stock count, or all information in real-time,” so that's a good use case. Or having some analysis side, where I want to get results immediately. Then, because if you build your site statically, the build time takes a bit. Of course, even if you don't have code changes, generating a couple of thousand sites may take a bit more than 10 seconds.

If you need near real-time data and of course, if they are relevant for SEO, or for the user — so if the user can't wait, say five minutes for the result, then it would make sense to use dynamic server set rendering, for example.

[00:29:03] BH: Great example. Yeah, I think the real-time is the key piece to unlock there. Because otherwise, you're like, well, if you know, even in e-commerce that you know all your products, why would you need that? To your point, if you want to be in real-time.

[00:29:14] AL: Exactly. Yeah. I mean, you can still fetch, for example, the stock count on the client side, so that's all good, unless you need it for SEO purposes to maybe embed structured data or something. In general, there are lots of options. If you have a use case, you can always evaluate how much of the data is needed in real-time, how much is needed for SEO. By that, choose dynamic server-side running or not.

The good thing is again, coming to Nuxt here, if you use Nuxt, then a change in that is very, very simple. If you use server set running, or if you even don't use service set rendering at all and build a good old single-page application with Nuxt, which you can do, switching to SSR isn't difficult at all. It's actually just one config step and that's it.

[00:29:56] BH: Got to love the DX on Nuxt.

[00:29:57] AL: We try our best. One of the newest things in there is now when you use — create Nuxt step to scaffold your application, we've added some links to all the top-level keys, where you get information also to the modules that link to documentation, which is go.nuxtjs.dev, I think. Then you have go to nuxt.js.dev/content, for example, and you're redirected to the content module docs. You always know where to go.

[00:30:23] T: I’d like to switch topics a little bit and ask about your talks, because it seems like you give a lot of talks and go on podcasts and things. I’m curious how you come up with your subject and what you think about when you're communicating your messages.

[00:30:39] AL: Yeah. I indeed try to give a few talks every now and then. It's mostly because it's a bit how I come up with blog posts. I’m very active in Discord and GitHub. If I see the same question coming again and again and again, then it's usually either time to add a documentation. If it's a very in-depth and complex topic, for example, how to fix hydration errors in Vue, then I’d rather write a blog post, because it won't fit on a documentation page and it's a more narrow case.

Yeah, for talks, it's almost the same. If I would say like, many people are interested in Nuxt, then I would give a beginner's talk about Nuxt. What it is, what you can do with it, and what you can't. With Nuxt and SEO, it actually came up because I’m really focused on SEO in all my projects, because I mostly have public-facing sites. And also, client projects every now and then are public-facing. That's a common question. And SEO is in general, a topic for developers that's not often touched.

When I looked through most meetups and also conference lineup, then there almost never was an SEO talk. So I thought, well, why not just giving that a try and see how it goes. Actually, last year in October, there was a bar camp in Berlin, where I spontaneously decided, “Okay, look, I haven't prepared anything, but I just want to tell you a few things about SEO.” People really liked it, so I thought let's make it a real talk.

[00:32:06] BH: Well, we are all very grateful that you did.

[00:32:09] AL: Thank you.

[00:32:10] T: Are there any questions that you see coming up time and time again that you want people, perhaps our listeners, to just know like, “This is a common thing that I see people miss and here's how to do it?”

[00:32:22] AL: Yeah. One common question is almost every time about authentication. It's unfortunately, again, it's a very complex topic, mostly because the setup varies a lot. It can be off to, it can be JWT, it could be some SSO, as SAML. There are lots of variables, lots of unknowns here. This is again, on the Discord and also, sometimes on Reddit, where I’m also on every now and then. People are asking often, but answering these questions is really complex if you don't know about the whole scenario.

Also, the Nuxt authentication module is there, but again, we can't cover all possible use cases. Plus, we are all no authentication experts and neither the developers using Nuxt are mostly. Don't want to assume that you're not, but that's a point here. If you, for example, don't understand how JWT workflow works, then it's tough to implement it. This is a common question, but unfortunately, there's no easy answer to that. I have one more. I have one more common question, which is about Nuxt and Vue 3. Yeah, very common. The answer is it will be ready when it will be ready.

[00:33:31] BH: Yeah, I’m familiar with that answer.

[00:33:33] AL: Can't give an ETA. Bue The Vue Global Talks are online. Sébastien and Pooya talks a lot about Nuxt 3, things coming up, the internals there, and changing things and ideas. A good thing is a few things are already known, like there will be rewrite in typescript. Of course, you don't have to use typescript if you use Nuxt.

[00:33:50] BH: Yay.

[00:33:52] AL: This will be really helpful, especially for module authors and for people who like auto-completion. This is one point. And of course, while you're on Nuxt 2, you can use the Nuxt.js composition API package, which gives lots of composable functions for existing things, like fetch, static, async data and so on. I’m using that in a couple of projects and it's amazing how well it works. Again, shout out to Daniel who is mostly maintaining this year. Because again, it's not my work. Not at all.

I’m also “just a user.” A happy colleague. Coming to that, maybe the last question here that I get quite often, “Should we wait for Nuxt 3, or should we use Nuxt 2?” It is a similar answer for — “Should we wait for Vue 3, or use Vue 2, back then when Vue 3 wasn't released.” I would say, use whatever you want right now, which is Nuxt 2 and go for it and then do the migration. Mostly, because I always have that philosophy. If you want to get things done, then just go ahead and start and switching is always possible later. You would lose lots of time that's valuable for product feedback. Or seeing if maybe the whole approach doesn't work at all. You have to pivot in another direction.

To me personally, it's worth more just giving it a go and building something and then maybe switching later, because also, migration will be as well, as less painful as possible. Yeah, give it a go. If you like composition API like I do, use the composition API plugin and you're good to go.

[00:35:13] BH: Great. Great advice.

[00:35:15] T: Yeah. Speaking of Vue 3 and Nuxt 3, I’m curious, also, if you could share any common gotchas that you see when people are switching to Nuxt for the first time?

[00:35:24] AL: Good point. One of the most common gotchas is really server-side rendering, because it's really cool and it's amazing, but it comes with lots of complexity. People always underestimate that. Again, this was also one of my common gotchas at first. They don't understand how it works. I usually try to explain that every time I give a Nuxt workshop for beginners, or a Nuxt talk. The important part is really, it's only about the initial request. This is the most important thing, because I messed it up at the beginning first too.

I thought, okay, maybe it’s Nuxt calling that Node.js server also client-side navigation, but no. Not at all. It's only the first request. When you hard reload the page, or when you click on the page link from an external page, this is server-site rendered and all the other things happening in a similar way, like a plain old SPA. This is one of the common gotchas.

[00:36:11] T: Yeah, that makes sense. I remember the first and only time I used Nuxt, I was trying to build a portfolio site and none of my images were dynamically loading and I was like, “Ah. I thought it was the same as Vue,” so I was just wondering if there are others like me out there.

[00:36:25] AL: I actually made a blog post about that, because this is again a common question people do. “Okay, how can I dynamically load my images, but even also in plain Vue?” There's also, when I said okay, let's take a look under the hood. Why does that work when I just have non-dynamic string, why can’t it load my image? If I would say, okay, let's say @/asset/ then variable image name .PNG, why doesn't that work? Interesting topic, actually. Also, not a webpack expert, but at this time I dug really deep into it. I thought, “Okay, if you want to have a quick solution, click here. If you want to get all the nitty-gritty details, then read that post.” That's also a very often asked question.

[00:37:05] T: Nice. Yeah. I was like, why doesn't it work?

[00:37:08] AL: I think, one more thing is that so, if you're a Vue library maintainer, or if you’re a plugin maintainer, or whatever I want to call it, say a maintainer in the Vue.js ecosystem, then sometimes SSR is not your first, or your second, or your third thought. I’ve seen lots of libraries that don't have SSR in mind and that's completely okay, because you can still use them on the client set only. Of course, you need to know how and also, you need to evaluate if there are other options and if it's important for SSR or not.

This is also a thing, how to use components that are not ready for server-side rendering, because the common error, like window is not defined. Because on the server-side, you don't have a window or document available, because these are all browser-specific APIs. I think that's also one of the common gotchas here.

[00:37:56] T: Speaking of libraries, I’m curious, because I don't know if it's in Vue 3, but I remember in Vue 2, you used to be able to pick a render target of if you wanted to make your own package and I’m curious if with Nuxt as well, that is one of the recommended, or potential use cases is to use Nuxt to build library to be used by other developers.

[00:38:18] AL: Nuxt doesn't have that the Vue-ci has that with an option to export and to set the render target. But what Nuxt has now as an option is if you write a Nuxt.js module that adds components, you can add them to make them automatically detectable and addable. That's a cool new feature that came in the, I think the last, or the one before, or so minor version. Where you don't have to use imports anymore for your components. Nuxt will simply automatically import them and even lazily, if you want to. You don't have to declare them in your script part. What you can do is just write the name in the template and you're all good.

[00:38:54] T: Nice.

[00:38:55] AL: Yeah, coming back to your original question, I would say the talk from Thorsten Lünborg, which was I think, last year's conference in the Vue.js Amsterdam about correctly exporting and bundling Vue.js libraries is pretty good there, because it's totally fine if you have your Vue.js library and then export it for Vue CLI. It's all good.

I always suggest people who import other Vue libraries and Nuxt to import from source if possible. Then there is one common gotcha. Before I forget to mention that, all things in node modules are by default, not transpiled. Sometimes you have to add that specific library you're importing from source to be transpiled. Otherwise, it won't work.

Yeah, not exporting the fully minified build, for example, but use the source files themselves to import for example, Vue components to make the whole library tree shakeable. Not saying, import from the module/dist or something from node modules, but from the real .vue files.

[00:39:52] T: I see.

[00:39:54] AL: Yeah, that's mostly for optimizing things and reducing bundle size and performance.

[00:39:58] T: Nice.

[00:39:59] BH: Sounds good. Well, as we start to wrap up, Alex, so if people have questions, or want to hire you, where can people find you on the internet?

[00:40:08] AL: Yeah. First of all, for questions no matter what, if it's a business inquiry, or you're just asking what's the new coolest hot take on Nuxt.js, you can reach out on Twitter of course, @TheAlexLichter. It will be in the show notes, so no worries. I also have blog, blog.lichter.io. Yeah, again, my name is terrible to pronounce for all people in German. Sorry for that. Or nuxt.xyz, that's a better URL here, but it's less known. Well, there we go. You can always shoot an email at blog@lichter.io if you prefer email, so you're all good. Besides that, yeah, I think these are the best ways to reach out. Yeah, sounds good.

[00:40:47] BH: Perfect. Well, I think with that, it's time for us to move on to this week's picks. Tessa, would you like to go first?

[00:40:54] T: Yes. I have one pick for this week. It's the second season in Netflix’s Haunting Anthology, The Haunting of Bly Manor. It's based on several of Henry James’s books. Mainly, the teaming of this group, but also some other books. It's not as scary as the first one, for people who are not good at horror like me. Most of the scares are in the first episode, I think, to set the tone. I really like this series, because I feel both seasons have very lush set design and just really nice camera angles. Aesthetically, it's very pleasing to watch.

[00:41:35] BH: Great.

[00:41:36] AL: Sounds cool.

[00:41:37] BH: Alex, what do you have for us this week in terms of picks?

[00:41:40] AL: I have three. Quite the number. The first one is a bit more technical and from a maintainer's perspective and probably conventional commits — having chore, or fix, or feed in front of your commit to declare what the content of the committee is and the intention. Paul Slaughter from GitLab created something similar called conventional comments. For reviewing code, so pull requests, code reviews and so on.

To make clear your intention, also disparity, for example, of a comment, you could do the same here. For example, you could say suggestion, then colon, this is not worded correctly. Then, the person who wrote the code will exactly know okay, this is just a suggestion. This is not blocking at all. This is just an idea. Or, you could also say something like, nitpick, or a blocking, or issue to yeah, make your intention clear.

Because again, if we talk, it's easy to get the tone and to understand what we refer to. Well, not always, but most of the time. When we write, all these things get lost and the context is sometimes missing. To make attention clear, conventional comments might be a good option here.

[00:42:45] T: Yeah, that sounds fantastic. I feel like that would have saved me so much time on my last team.

[00:42:49] BH: Oh, I love this. Great pick.

[00:42:52] AL: Amazing. Yo you have to introduce that to your teams too, right?

[00:42:55] BH: Oh, I already dropped it in Slack, so way ahead of you.

[00:42:57] AL: Oh, perfect. Nice. Okay, the second one is something physical here. It's the TONOR T20 microphone arm stand, because when corona started, I got a new side project, which is by home studio, more or less. I got my old RØDE NT1-A out of the basement and I was missing a real microphone arm. I got that one, which is not comparable. It's very cheap, but it's not comparable to all the other cheap microphone arms there. It's not as good as the RØDE PSA1, which is masterclass. But it's really solid and I think it was 20 bucks or something. It's pretty good. It's spring-loaded and it's stable and it's 360 degrees turnable, so definitely a good recommendation from my side here.

[00:43:43] BH: Great.

[00:43:43] AL: Okay. The last one is the site Website Carbon, which is also due to a current situation, climate change is just a rough guidance on how the website actually impacts the planet. You could enter your website there and it will tell you how much greenhouse gases it will emit per 10,000 views, for example, and how it would compensate that. It will also tell you if it's for example, cleaner than X percent of the websites tested.

Especially now when there's lots of JavaScript loads and yes, I know I’m saying that in a Vue.js podcast here. Not saying that if you just JavaScript code. Oh, my God. That's not true at all, but having lots of large megabyte, large bundle. That might be a good idea to just check aside and see if you maybe also have a chance to improve your site there.

[00:44:29] BH: Perfect. Well gosh, I think I’m going to end up buying, or recommending all these to people. Definitely love the new upgrade for the TONOR microphone arm stand and the Website Carbon. Ah, these are great picks.

[00:44:41] AL: Thanks.

[00:44:43] BH: I guess, at least me for picks, and so I have just one pick for you all. For those who have been listening, you might know that I’m a bit of a productivity nerd and have been reading things like how to take smart notes. Basically —

[00:44:54] T: — Oh, this is a surprise to me.

[00:44:58] BH: My pick of the week is a tool called Roam Research. Basically, it's a new way of thinking about taking notes from a way of creating relationships between different nodes as you're writing. For those interested in this note-taking, a second brain, digital gardening, it's absolutely worth the time to look into and I’m always happy to chat about that stuff. You should contact me if you have any questions about it.

With that, that is all for this week's episode. Thank you everyone for listening. Until next time, enjoy the Vue.

[END]