So let's go!

As we all know, single file components are the main way to write components in Vue.js, except when you need multiple components in one file, then we can talk about libraries like Vue Wine, where I've talked about in a video last year, so take a look if you're interested in that.

But sure, if you have a script tag and only use it for progressive enhancement, it might not be that easy to use a single file component, especially if you don't have a build step, then it won't work, but commonly, especially if you build your whole frontend in Vue or Nuxt, then SFCs are the way to go.

And these .vue files have a specific beauty because, well, we can put our styles, our script logic and our templates in three different parts, they still belong to the same component and there are lots of discussions about separation of concerns, but we'll skip that here.

We really talk about the order of which these tags appear in the single file components because that changed over the while.

So commonly nowadays, a lot of people have strong preferences and, well, there are two of the common choices, I would say.

So let's start with the more traditional one.

Traditionally, Vue, especially Vue 2, had always the template tag on top and that kind of makes a lot of sense.

We see the component structure here, we see, okay, we have an h1 and an input here, we have some directives like vmodel and it's quite nice to have a look at the structure of the component itself, how it's rendered then.

The next part then was the script part, of course, typically with the options API in Vue 2, but of course, we could just rewrite that part to the composition API, so just use the script setup and say const message is ref and import ref from Vue here and we'll be good to go as well, so that would work the same way.

But the bigger question is, what does the script part here, the second one, brings us?

Well, of course, we want to see our logic, right?

We want to see what is happening in our component, how specific parts interact with each other, if there's some lifecycle hooks called and so on, so on.

So we see all of that in there.

And then last but not least, the styles, because, well, styles last, they're not as important as structured logic, and we're good to go.

But as most of you know, this traditional way of writing single file components changed, and actually, the only thing that really changed is moving the script part all the way to the top and the template second.

Now you might wonder, why did it happen?

And when did it happen?

Well, the answer is, it happened roughly around the same time as the composition API came out, and thus also Vue 3.

And Avenue himself also switched to that, the documentation switched to that, and he basically said the following about it.

I've been moving to script first, and as I've seized myself, especially with script setup.

And then Evan talks about a tool that helps you automating that.

Jonathan Rennink, who is the author of Inertia, also working on Tailwind, asked back then in 2021, okay, hey, but why?

What's the motivation?

And the point that Evan makes here is that it aligns better with the plain JavaScript mental model.

So imports and declarations first, and then usage.

And of course, he also points out that this is because script setup itself, so the composition API itself aligns way more with the plain JavaScript mental model.

Well, we already know that the composition API is way more JavaScript or just JavaScript than the options API was, so that kind of makes sense.

But what's the benefit in a bigger component there?

Well, for me personally, I think if I see at first what the component is doing, maybe even some inline composables of the certain concerns the component has, I at least know, okay, what do I expect of that?

Plus, when I read a big component, and there would be a template first, then I might jump, oh yeah, here's a click handler, I jump into the script further down, I read what is this click handler doing, maybe another function, take a look at that, and then have to go all the way up again to continue.

Well, that's not ideal, because in the template, you can't really group everything by concern, right?

It's based on the markup and how you react to things.

While in your code, you can have nice groups, for example, with inline composables, also video on that in the description or up there, that groups everything nicely by concerns, you know, okay, this functionality, here's all the code I need for that.

And if I now want to see how this is implemented in the actual template part to see which click handlers are triggered, where do I loop over things, where's two-way data binding, then I can easily do that after that I know all of the things about these concerns.

A lovely example for this that I always like to bring up is basically what I just said in the comparison between options API and composition API.

And keep in mind, this is only the script part that you see here colored by concerns.

And as some of you might know from other videos of mine, yes, there is also the non-blurry version of the right part here of the composition API in a gist that Evan made back then where you have everything nicely grouped by concern and top level called what the component is actually doing, and then having all the reusable functions aka inline composables further down.

And after we scroll through these 200 lines, we at least know what the component is doing.

And then we have the template part here, which, well, is fully omitted.

So that would also be a couple of hundred lines, I suppose, but doesn't have to be.

And even if we just say, okay, we read this top part, we at least roughly know what's going on here.

So we have a good overview of the component, contrary to when we read all the template and like, okay, at least we know how it's rendered.

So in my opinion, that's a quite good option.

And of course, we also have another component here from Elk, the open source mastering client based on Vue, Vite, Nuxt, UnicSS, and so on.

So definitely have a look, link in the description as well.

And here we see, okay, this is a command panel that Vue component.

And here we also have everything related to the component logic in the script part.

First, script setup, we don't have any inline composables.

The logic is, I would say, still manageable though.

Here and there we have some functionalities that we could align better together, but still, we could see, even if we just simply collapse these in a proper editor and not in GitHub here, then we could just say, okay, yeah, no problem.

On key down, okay, there's something that will happen on key down.

It's fine.

Oh, where is it happening?

Sure.

Let's see.

Okay.

Here, something's rendered.

No problem.

And we have that on key down easily up here in key down.

And now the big question is, is the script part on top order really better than the traditional or like OG order of tags in a single file component?

Well, as I said in the beginning, a lot of developers have a lot of opinions.

So let's reveal the best option.

The best option is whatever you pick, but please stay consistent.

So try both out.

But if you have a project, please don't go there and say, hey, script part first, style part first.

That would be really crazy though.

Template part first.

Please just stick with one of the ways, especially if your whole team settled on that easily.

And that's it.

And in the end, well, if you work alone in your projects, you can do whatever you want, right?

Though I still would suggest consistency because it's easier to onboard people sometimes to take a look at your own code in, I don't know, a couple of days or like see what you wrote before Christmas, because you certainly won't remember any of that anymore.

At least that's how I feel sometimes.

So yeah, please just stay consistent.

And if you use a normal IDE, you can even do another nice thing.

So let's take a look at what the Vue extension is doing for us.

So if you're in VS Code, you should also work in other editors.

The Vue extension allows you to split the script, template and style editors into separate windows.

So here when we have script and template, you see the template part and you see the script part.

And of course the other part is collapsed.

So you have a nice overview.

You can even have that under each other if you want to.

You can lay it out on different screens if you work in one big component, that's all up to you.

But luckily, all of that is fully possible.

So no matter the order, you can still arrange it as you want in your IDE.

And also Vue is not really enforcing an order, right?

There are some suggestions, but once again, in your projects, you can do it as you like.

If you have a bunch of OJ developers say, hey, this is the way I want my structure first and not my logic, that's totally fine.

If you're maybe still using options API, that's probably also something where I would prefer a template first, but everything with composition API and beyond, I personally think the script part on top is the best.

Now I want to wonder, what's your take on that?

Are you a big enthusiast of script first or template first, or maybe something total curious, maybe using, as I said before, Vue.Vine and don't have all these issues at all?

Let me know in the comments, of course.

And well, I'm interested to have you any experience with switching back and forth.

So yeah, what's your take on the whole point there?

As I said before, we have a lot of people with a lot of opinion there, and that's totally fine, because that is also how we shape the future of our framework with some more input here and there.

And nevertheless, take a look at the latest Azure Vue episode where Michael talked with Adam Jar of Vue Mastery about creating content, because this is a key skill for all of you developers out there.

So learn a thing or two there.

And obviously take a look at all the other videos, because I guess they're pretty nice, still relevant.

And yeah, I hope to see you next video as usual every Friday.

So until then, and maybe in the next video.