DejaVue

This DejaVue episode comes as a little special! As a belated Christmas present, we got everything, literally everything that was discussed on this podcast about one big topic: Composition API vs. Options API.
A lot of our previous guests had their own takes on the two APIs - and some might surprise you! So, why not tuning in and hear fifteen people talk about their opinions, insights and suggestions when it comes to using their preferred API in Vue - and why.

Oh, and yes - there is even a little spoiler for next weeks episode

Enjoy the episode! 

Chapters

  • (00:00) - Welcome to the DejaVue Special
  • (00:37) - Evan You
  • (18:04) - Natalia Tepluhina
  • (26:09) - Tim Benniks
  • (27:11) - Joe Tannenbaum
  • (30:14) - CJ Reynolds
  • (37:33) - Simone Cuomo
  • (41:28) - Sumit Kumar
  • (48:29) - Jakub Andrzejewski
  • (49:54) - Rijk van Zanten
  • (53:47) - Eduardo San Martin Morote
  • (57:46) - Vue Toronto Panel
  • (58:18) - Wrapping Up

Links and Resources


Referenced Episodes


Your Hosts

Alexander Lichter

Michael Thiessen

Links marked with * are affiliate links. We get a small commission when you register for the service through our link. This helps us to keep the podcast running. We only include affiliate links for services mentioned in the episode or that we use ourselves.

Creators & Guests

Host
Alexander Lichter
Web Engineering Consultant • Founder • Nuxt team • Speaker
Host
Michael Thiessen
Full-time Vue educator
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.

Alexander Lichter:

Welcome to DejaVue.

Michael Thiessen:

Your favorite Vue podcast. You just don't know it yet. Today, we've got a special episode for you. We're gonna take a look at all of the previous guests that we've had on and take a look at what their opinions are on the Composition API versus the Options API.

Alexander Lichter:

Exactly. We had a lot of interesting takes there from people saying, oh, yeah, composition API. That's, the only API they'll ever use. And it's so amazing compared to the options API. And also are people saying composition API?

Alexander Lichter:

Tricky. So, yeah, we're here for all of them. So let's get started straight away.

Michael Thiessen:

Up next, the person whose opinion you maybe want to hear most is Evan, who created the composition API and also the options API, of course. And he has some very interesting opinions and takes on the differences between the two.

Michael Thiessen:

How was that transition from Vue 2 to Vue 3 along with the composition API and

Evan You:

Mhmm.

Michael Thiessen:

And all of that?

Evan You:

Yeah. I think so Vue 2 to Vue 3 is definitely probably the big the most challenging and, you know, grueling process or period life experience in a whole 10 years of working on view.

Evan You:

I think even to this day, there are still lingering just, like, arguments about options versus composition. It just takes a very, very long time, to for the community to move on. Right? So kinda wanna go back to why we started the idea about composition API in the 1st place. Right?

Evan You:

So one of the big issues in Vue 2 is TypeScript support isn't quite there. So options API, when it was designed, didn't really even take type inference in mind. So it wasn't really designed in a way to be easily type friendly, especially with mixins. Mixins are extremely hard to type properly. So nowadays in Vue 3, if you use options API with mixing, we can actually infer most of the stuff, which is amazing.

Evan You:

But if you look at the types that we have to write to get mixins inferred properly, it's just, you know, it's just so much extra effort compared to composition API where everything is just functions. It just naturally works with TypeScript, has better type inference performance. It's easier to reason about in type land in most cases. So that's one of the things that kind of pushed us to think about a different API that is designed with type inference in mind. Unfortunately, we can't

Evan You:

we can't just get rid of options API, so we have to carry along the burden of all the types that we wrote for options API. But, you know, in a way, like, we we want a new API that's just more type friendly from the get go. And also, mixins mixins is like the bane of both maintainability and type inference. Right? It's hard to hard to infer types also for users.

Evan You:

If you use a bunch of mixins, you don't even know where these properties come from. Right? So we really wanted a API that enables better logic reuse compared to mixins and also wanted the API to allow people to have a more higher upper ceiling in how to organize your code. Right? Options API forces you to group everything by type.

Evan You:

So if we go back to like single file components, when it first came out, there were a bunch of people who were like, oh, you're mixing 3 different languages in a single file. Where is separation of concern? Right? This very old argument about you should have 3 directories, HTML, CSS, JavaScript, and put all your files in these three categories. That's like options API to me nowadays, right?

Evan You:

So when you transition over to thinking about components, a component is a unit self contained unit that contains the cross cutting concerns from all 3 different layers, but they are grouped they are related to the same units of logical concern. And Composition API essentially gives you the ability to think about all your logic in the same way. So instead of thinking about here's data, here's computed, here's methods, it's like HTML, CSS, JavaScript, you can now choose to cut a piece of it out and say here's a composable, it has all the things that's related to this specific logical concern. I can move it anywhere I want. I can put it inside my component, I can move it outside of the component and share it between multiple components, or I can even extract it into a library and share with other people, share with other projects.

Evan You:

I think that's super powerful. And you can do that while having proper type inference all the way through. And you never get lost with where a property comes from because they always get returned from function calls. You can always just go to definition. You see exactly how they are created.

Evan You:

So this all of these just adds up to the overall maintainability of large projects with which we have seen over the years people just struggle with Options API. Like, I think a lot of proponents of Options API really, like, I think it works for them. It's great because their project just isn't huge. Right? There is a scaling limit to options API where if you have a huge project, multiple people working on, you have a component that's 100 of lives long, It's not gonna be fun.

Evan You:

It's just not. But with with composition API, a thing people don't realize is, it's kinda like building, you know, some like a model kit. One version is like it only has a fixed way of putting it together and you have to strictly follow instructions. So you don't need to use too much of your brain. You just follow all the instructions and things fall into place and you have something.

Evan You:

But that's the only thing you can build. And if you follow the instruction, that's the only outcome that's possible, right? But on the other hand, if you're something like Lego, like you can use your creativity a bit more, but if you don't use your brain, you just randomly put things together, it's gonna be a mess. But if you use your brain and think about a design and you think about I'm going to build this nice piece of Lego, now you can use your creativity to build something that's probably better than an off the shelf you know, thing that you can you can think of. Right?

Evan You:

So the upper ceiling is higher without composition API. And I also compare that to writing composition API code is more similar to writing normal JavaScript. Right?

Alexander Lichter:

Definitely.

Evan You:

Right? So it's like if you write messy code with a Composition API, you probably write messy code with normal JavaScript modules too because you don't think about how to group your variables and your functions together. How do you like abstract make abstractions? How do you split our modules? Right?

Evan You:

You think about all that when you're writing normal JavaScript. Composition API kind of forced you to think about these same concerns. You're writing new component code. So that is indeed a lot more you need to think about compared to options API. But that also allows you to apply all your JavaScript skills in terms of like how do you write nice abstractions, how you organize code neatly, how do you make them maintainable, All these skills that's applicable to writing good JavaScript now apply to writing good composition API code.

Evan You:

Right? So so anyway, if you are a good JavaScript developer, you will find composition API more, you know, liberating because now you can you can like fully leverage your skills as a JavaScript developer. Right? But I also understand like if you don't want to just spend time thinking about writing good JavaScript code, you know, like I want to just get my hands held all the time. I don't wanna think.

Evan You:

Right? Options API might still be a better fit, but as I said, Vue's user base changed over time. Like, we now have real view users who are trying to build really complex stuff and maybe they are really good at skilled developers who can write really well maintained JavaScript code. So it would be a pity if we lock them into the upper ceiling created by options API forever, Right? So in a way, my motivation is to create this alternative API that unlocks that ceiling for them.

Evan You:

Right? So, unfortunately, to some users, it might not be the most, you know, ideal trade off because they probably never hit that ceiling. So to them, Composition API API is just there's something I need, right,

Alexander Lichter:

Overhead

Evan You:

right, which is unfortunate, but I think it's a result of Vee's user base being really, really diverse.

Evan You:

And, you know, tough decisions have to be made. We try to, you know, make sure that if the existence of composition API won't affect how your options API code works.

Evan You:

Right? In fact, you can even easily leverage composables used by other people if you still prefer to write options. Right? You just use the set of a hook and you can still use composables. So we definitely tried our best to find find the right balance.

Evan You:

I think it's just it's not quite possible to make everything perfect for everyone. Someone will complain, but I think we tried our best. I'm pretty happy with the outcome in general. I think composition API achieved all the goals that we set out to do. It had better types of support.

Evan You:

It unlocked logic reuse and composition. It increased the maintainability ceiling. I it spawned projects like VueUse, and it's now the preferred way to write components for most new users. So, so I think we achieved the most of the things you wanna achieve with composition API, but options API is probably gonna be here to stay for as long as we know.

Alexander Lichter:

That's a good one because, like, that's that's definitely what one of the big questions. It also, like, came up in in the last weeks, weeks before. The recording here, like, there was a bit of social media drama about, like, oh, yeah. Composition API versus Options API. Here we go again.

Alexander Lichter:

And, of course, people were like, okay. Will the Options API stay? Like, you you said multiple times it will. You also made this tweet on Twitter. But, like, is there is there, like, an end of life at some point plan for the options API?

Alexander Lichter:

Will it probably around for for years to come or even, quote unquote, forever?

Evan You:

The cost of keeping options API around is, like, very, very low because there's literally no maintenance burden for it nowadays. Like, it's just a really thin layer, that's on top of composition API. Like, all the things, all the bugs we fix, it applies to both API styles pretty much. So, yeah, I don't I don't really see like, there's no really no reason for us to remove it, other than I think even if we wanna encourage people to use composition API, we will do so by just tweaking the documentation. You know?

Evan You:

Like, one thing that we acknowledge, is that actually, I've heard this from some people who've recently picked up Vue and they're pretty advanced developers. So their primary question is when they first look at the documentation, they see the API style toggle. Yep. And naturally, they want to understand what both how both API works because they want to make an informed decision. But unfortunately, that just creates this extra mental overhead for, like, people hate having to make decisions when they're first learning something, but we throw this big decision right in front of them at the very beginning.

Evan You:

It's kind of off putting to new users. I think at one point, we'll just have to be more opinionated and just, like, be the doc. Like, we will assume a lot more things because right now, like, we have to assume, do you use a build tool? Do you prefer options API or composition API? Like, this just leads to all these different branches.

Evan You:

It's a whole decision matrix, and that kind of blurs people because I think most new users nowadays, especially when they try to compare Vue to other frameworks, for example, Svelte, it has only one default way of using it, that's with a build tool. Right? So, so if people are comparing that, they're like, okay, Svelte just directly shows me the only way of doing things, but Vue gives me this, like, 4 different branches. Now I have to figure it out and just kind of, you know, creates a bunch of barrier they have to jump through before they get to know, oh, this is actually the happy place, you know, but that takes time, right? Because when we first did 1 view 3, the new documentation, I think having both conversation between options API in there is still definitely necessary.

Evan You:

Like, we kinda want to give them equal weight, equal treatment.

Alexander Lichter:

100%. I mean, there's there's so much content also still the options API

Evan You:

Yeah.

Alexander Lichter:

Which is which is another thing. Like, I I personally like to know both APIs. Not, like, for straightaway jumping in development, but more like, okay.

Alexander Lichter:

It's still good to see. Oh, wait. There's an older resource about, I don't know, a certain library to use, certain pattern, and it's it's still good to see, okay. This is options API, but I can still read it and transfer it over composition API because I know both.

Evan You:

Yeah. I think, like, all over time, like, we will, you know, have we unfortunately, we will always have these existing content that's created using, like, certain dialect. I think the most damaging part, the period where we shipped Vue 3, but we didn't have script set up. That's like between 3.0 - 3.2. That was probably the most hurting period where there were a lot of articles written online introducing composition API, but it's using this whole, like, setup return syntax.

Alexander Lichter:

The verbose one. Yeah.

Evan You:

Yeah. And some people using other frameworks during that period will be like, oh, let's check out view composition API. I see that. They'll be like, I don't know about that. Right?

Evan You:

So that's I think that's that's kind of a mistake on our side. We should have just, like, shipped with script setup straight away, but unfortunately, we kind of, again, didn't do that upfront. In hindsight, we should have just maybe shipped composition API with script setup from day 1. But when people say, show me what a Vue component looks like, we'll show them the default. That's SFC with script setup because we believe that is the most reasonable way for you to start a new application nowadays given all the support, given all the ecosystem tooling and everything and the maturity.

Evan You:

So, it's at a point where we can now recommend that as a default. So probably, in the next year, we're gonna do another revamp of the documentation and start to kind of be more opinionated on, like, if you're just getting started, this is the way of doing things. There's no decisions to make. When you get a bit more comfortable with this, you can then explore alternative options, you know. We'll make you aware of those options exist.

Evan You:

We'll still properly document them, but we want the default onboarding path to be to get rid of all those decision matrix and just like one straight away. And you get to something that you can like confidently say, now I know HOBE works, I can build something with it. And now I discover, okay, there are also other all these other ways of doing it. But if I am I'm already happy with the default way, I don't I probably don't even need to, you know, spend too much brain trying to figure out whether I should even use them.

Michael Thiessen:

Yeah. And if it's not a lot of cost to keep the options API around, I think it makes sense for sure to keep it around, especially because of the, the the whole spirit of of Vue in keeping oh, you can just drop it in a script tag.

Rijk van Zanten:

Yeah.

Michael Thiessen:

You can use the options API. That's a little

Evan You:

Yeah.

Evan You:

I think options API is still better suited for the drop dropping through a script tag case. Right? That's also one of the big reasons we wanna keep it around.

Alexander Lichter:

Very good point. Yeah. Like, maybe you've seen, Justin Schroeder's proposal saying, like, hey. At some point, maybe it would be good to to, like, put the options API behind a flag. I mean, there's a compile time flag already or a compiler flag already saying, let's remove the options API fully to make the bundle even leaner if you really don't use it at all.

Alexander Lichter:

Have you have you thought about that a bit more, and or is it a way you could imagine pursuing or or maybe not, like, in the in the future, like, not tomorrow, of course?

Evan You:

Yeah. I think you can already do that today. Right? It's really just a matter of flipping a lean as the default. I think we'll need an RFC on that probably.

Evan You:

I'm personally leaning towards we probably can consider doing it in Vue 4. You know, I think in a lot of things we do in Vue 4 that will be considered breaking changes just really like changing how something works by default rather than changing the way it completely works. You know, like, I think future to Vue 3, the biggest, like, issue in the breaking changes is a lot of them are kind of like these low level changes where it makes it really difficult for automatic migration.

Joe Tannenbaum:

Mhmm.

Evan You:

But something like, you know, a configuration flag that changes the default value or just like options that flips the value. These are extremely easy to migrate. So we, you know so breaking changes in Vue 4 were probably more along those lines. It's really just like we will also most likely have a version where you can say, like, turn a flag on, like, opting to all these individual it's kinda like migration build, but much easier, more compatible. Yeah.

Alexander Lichter:

That totally makes sense. And I I hope somebody will come up with the RFC just to see where where things are going.

Evan You:

Mhmm.

Alexander Lichter:

And next up, we have Natalia Tepluhina, our first, let's say, live and in person guest at the podcast. And she is sharing some thoughts from the perspective of, like, a big organization at one point adopting Composition API and, maybe struggles and hurdles and why the options API can still be interesting.

Alexander Lichter:

That might be a bit tricky. Also, Evan, I agree that, like, that the learning story for people coming to Vue is now, okay. We have these 2 APIs, and then you could technically even use, like, composition API without script setup, which is probably not in the docs anymore.

Alexander Lichter:

But still, you could just use a setup function also for migration, so on. So what do you think could be, like, a solution to a a better learning path for for the users?

Natalia Tepluhina:

So I still think that it might be a good idea to separate it not with a toggle, but with separate subdomains maybe or even completely separate documentation where you choose and go this way. Because we honestly, nobody wants people to combine to API styles of the same component. That's the worst outcome you can have. Unless it's migration. And even for migration, I would recommend, okay, you want to use certain API in this you rewrite it all.

Natalia Tepluhina:

Yeah. Don't do part options, part composition because that's the best way to get lost in this component forever and for reviewers too. So maybe separating and maybe I remember the discussion about eventually deprecating one of the things, but the point is there are many people around who like options API.

Alexander Lichter:

Yeah.

Natalia Tepluhina:

And, Ray, you remember this huge thread on Reddit about that?

Alexander Lichter:

The also the the video, the proposal of Justin, like, everywhere, people, had very strong opinions about other things. And in a way, like, options API is some part of Vue's identity. Like, it started with it. It's, like, it is easy if you just use it as, like, maybe not a fully proficient front end engineer. If you just need a tiny pieces of front end.

Alexander Lichter:

Why not going for that?

Natalia Tepluhina:

And it's also easy on the huge teams. Like, when you have a bigger team, 100, few 100 engineer, it's a good idea to to use options because you can look at the component and you have no idea who wrote it, but all the things are at the same places. It might sound as a really stupid argument, But trust me, when you have multiple merge requests to review every single day, you want to find things in the same places. So just quickly understand what's going on in someone else's code. That's the biggest problem.

Natalia Tepluhina:

Like, composition is amazing, and it also gives you a lot of freedom, which is a benefit if you're developing your own project or you have a few colleagues and you all agreed on like this. For bigger ones, you will need to invent your own convention. Otherwise, it will be really hard. And those conventions can be as silly as you want. I saw people grouping Composition API just like options API.

Natalia Tepluhina:

They literally have data, like, methods

Alexander Lichter:

Yeah.

Natalia Tepluhina:

Computed, methods.

Alexander Lichter:

I also made a video about that saying, like, hey, folks. If you use Composition API

Natalia Tepluhina:

It is not the way, but Yeah. Like, it works for them. And if you want them to use something better, you need to propose the alternative convention. Because no convention is the worst. People will be looking at each other's code and, like, what is happening here?

Natalia Tepluhina:

Yeah. So I think maybe the best way forward, maybe I'm just a bit too optimistic, is to actually offer this kind of convention very well explained. I'm sure not in the Vue docs because this is not the responsibility. Yep. It should be adapted adapted to the project.

Natalia Tepluhina:

But there should be some kind of the guide, like, okay, you have this kind of how do you decide on your conventions? How do you shape your code so that everyone can understand? So composition API is the way to go. Like, I think we all understand that it's kind of the future. There are libraries that only work with composition API.

Alexander Lichter:

Vapor Mode coming up also only for composition API.

Natalia Tepluhina:

Makes me a bit sad in terms because I will be behind, but still use Vue two. We will talk about that. But and, yes, that will be additional headache for me as principal engineer to invent the convention and agree this convention with everyone because we have developer democracy, and this this will be problematic. We will fight for 6 months probably over the convention only. But this is, I think, that it was the main point in ready discussions too.

Natalia Tepluhina:

Yes. People want predictability from the code. Yeah. Options give them this predictability with some price. And this price being not the flexible code, like, very opinionated grouping.

Alexander Lichter:

Yeah. I mean, like, if you have a really big component in options API, it's super tough to read. You might know where you find, like, your your variables and, like, your computers, your methods.

Natalia Tepluhina:

But that's a problem of architecture too. Right? You will need to split this component with composition API or at least move logic to composables. It's easier. But, again, that's I think that we will need to answer this question in the documentation outside of it for the people who love options API for its predictability and rigid structure.

Natalia Tepluhina:

Like, how what can we offer them instead? How can they use the composition API and still keep the convention in place so they feel more comfortable with the code of the bigger team? So, yeah, that's the problem to solve.

Alexander Lichter:

I mean, technically, as you said, you can structure, like, the options API eventually. Like But

Natalia Tepluhina:

you don't want to. You lose the flexibility again.

Alexander Lichter:

Exactly. But I also think if you like the composition API, like, there are certain concepts that people were not aware of. Like, what I what I was also showing in the video about inline composables. Like, Evan did it in his first draft of, like, moving the the Vue two thing over, but I still I have seen lots of projects in my day job, and I have seen no one using inline composables that way. Now consulting is not you don't see the most glamorous projects usually, of course.

Alexander Lichter:

Otherwise, you probably wouldn't be asked to to help out. But still, it's it's super interesting that not that many people are like, okay. Like, in normal JavaScript, you write a function to, like, encapsulate your code.

Natalia Tepluhina:

And that's weird to me because how many times did you write a method?

Eduardo San Martin Morote:

Yeah.

Natalia Tepluhina:

A method that is used in this component multiple times, not only for the side effects. Sometimes it's a method that does some calculation. Right?

Michael Thiessen:

Okay.

Natalia Tepluhina:

You pass a parameter. You do some data mapping. You return the value that you want. And that's exactly what composable can be doing too if you work on more advanced level with reactive state.

Alexander Lichter:

Yep.

Natalia Tepluhina:

Just put it there and use it. It you don't need to create an additional file, put it there, and import it to your component. And just

Alexander Lichter:

I think that the problem is a bit that, like, with the composition API, everybody praised, okay. You can now, like, share logic. And sharing is common, like, okay. I put in the file. I can use it everywhere.

Alexander Lichter:

It's really cool. But it's a bit like overcorrecting. Right? And I I did the same, like, in the beginning of the conversation. I was like, okay, cool.

Alexander Lichter:

I can, like, add a composables folder, put my composable in there, and then I use it in one component. Wow. But just leaving it in there and then, like, okay, I call my composables and reusable functions for that component just on the top. Maybe I pass in some state I get from other composables in there, or, like, Okay, I have my v model bound to something that I passed in there. That totally makes sense.

Alexander Lichter:

But making that connection, that took a little bit. And I hope that something like this, like, more architectural patterns, like how to deal with certain scenarios, maybe there will be somewhere documented to have, like, a bit of maybe something like a cookbook or best practices because then

Natalia Tepluhina:

But it all also takes the evolution of the framework. That's the point. You cannot try them from the start because it's really just your opinion.

Alexander Lichter:

Yeah.

Alexander Lichter:

You don't know if people like it or use it, if it makes sense in the projects. You need a feedback, of course.

Natalia Tepluhina:

It comes naturally. Like, the more people use view 3, the more they come up with the same problem and some solutions.

Evan You:

Yeah.

Natalia Tepluhina:

The more it's natural to then put it in the documentation or guideline or book because now we know. Like, people use it, try it this way, try it that way. Now we know what is better, and we can bring it back to the documentation.

Alexander Lichter:

Yeah. Yeah. Yeah. I also like this, like, symbiosis. Like, hey.

Alexander Lichter:

It's always a feedback loop. Right? You you do something. People use it. People complain about certain things.

Alexander Lichter:

They, hey. We can improve this, or we use it that way. Does it make sense?

Michael Thiessen:

And up next, we have Tim Benniks, who was one of the first guests on our podcast.

Tim Benniks:

Yeah. This setup function thing, it's it's for me, it feels now looking back, it's much nicer because we used to whack every prop in the data thing option.

Alexander Lichter:

That was the space for it.

Tim Benniks:

It all became reactive. Mhmm. But it wasn't even needed. Right? And so it over time, it just got slower.

Alexander Lichter:

And back in time, you didn't really have a way to say this shouldn't be reactive. Like, you could you could put it actually in top level of the other options than access with with dollar options dot whatsoever as like a little

Tim Benniks:

done things like that, like workarounds like that and or or in an mounted function, just put a var

Alexander Lichter:

or something.

Natalia Tepluhina:

Yes.

Tim Benniks:

Yes. All the things. But the the interesting thing is, like because I've done all these bigger projects over time as, like, from a junior to a lead to lead of multiple projects. And when we started using Vue and we we were teaching each other to do it well, we found our way of doing Vue. I think we had, like, 80% less bugs.

Alexander Lichter:

And up next, we have Joe Tannenbaum. He worked on Inertia.js, is working at Laravel straightaway, and, it's curious to hear someone who also came from the PHP ecosystem, like some other people, and thoughts about the composition API. And but you still support the options API in vue 3, I guess, with inertia? So that that doesn't matter which API you write, I guess?

Joe Tannenbaum:

Yeah. Both are supported. So it doesn't matter. You can you can easily write out the options of the composition and it'll it'll work either way. Yep.

Alexander Lichter:

Sweet. On that note, what do you prefer with just the 2 APIs? Personal question.

Joe Tannenbaum:

I feel like this is the this I like the composition API personally. I'm I'm a big fan. It I will say that in the beginning, I had to, like, force myself to do it a lot in order to, like, understand it and, like, rock it in a way that that made sense to me and it made it feel better. But once it one day it just clicked, and I was like, oh, this is the way. I don't see any other way.

Joe Tannenbaum:

This is so much better.

Michael Thiessen:

Yeah. That sounds pretty pretty typical of like getting over that initial hurdle, but then once you do, you're like, yeah. This how how can I ever go back?

Joe Tannenbaum:

Yeah. It's clicks to clicks. Are are you not on the, are you not on the composition API side of the equation?

Alexander Lichter:

No. I I'm I totally am. I'm a big proponent of the composition API. And like, there there are like tons of discussions that I I, like I I I I think both Michael and I, we created tons of content around that, like options API versus composition API. We had Avenue on the podcast talking about that.

Alexander Lichter:

We had other people from the Vue core team also on on that, tons of, like, Twitter and Reddit discussion. So, yeah, I think the the 3 of us are on the on the same line there, but there are still people and I also understand that to some of you select options API is a way because, let's say, big team, not everybody is, like, a front end expert. Some back end just have to write front end code and so on. It's like, okay. Review is easy.

Alexander Lichter:

Everything looks kinda the same. I don't have to think about abstractions, and also guidance and structure. So I understand even though I wouldn't touch the Objection API nowadays anymore if I don't have to.

Joe Tannenbaum:

Yeah. I just think it it feels a little less magic and a little more like you're just writing JavaScript and it's working as intended. And I think that's, that's what finally made it click was that the magic layer is a little bit removed and you can just see like, oh, it's defined up here and I'm doing this and now it's showing up in my template and it's, it's just a lot more like a to b and a lot less like a to b to c to d, you know.

Alexander Lichter:

Yes. True.

Alexander Lichter:

And with the script setup syntax, which is also the only way anyone should write a composition API, it's my own hot take.

Joe Tannenbaum:

Thank you.

Alexander Lichter:

Like actually, it's it's not even a it's not even a hot tech, avenue as well, so that so, like, they made a mistake, quote, unquote, that's, like, what hurt Vue 3 the most was really releasing the composition API without script setup because just with the setup function, sure, for migration, okay, exception made fine, but, like, without that that macro, it's just so lengthy. It's so difficult to read. And without it, it's clean. It's wonderful. It's what we expect from you.

Joe Tannenbaum:

It's also the it's the recommended path. Right? It's what they yeah. Okay.

Alexander Lichter:

Yeah. 100%.

Alexander Lichter:

And up next, we hear all about someone who wrote a lot of React, Swells, and, of course, also Vue. Js, especially on the side from the one only CJ Reynolds from Syntax.fm and also from CodingGarden. So let's jump into what he really likes about the composition API in Vue. Js.

CJ Reynolds:

Yeah. So I I followed it from the early days. Like, I I remember re releasing a video on CodingGarden where I used, like, a prerelease version of the composition. Well, I used the composition API when it was a separate library that you could pull in.

Alexander Lichter:

Mhmm.

CJ Reynolds:

And I showed, like, how it works, and I was like, this is potentially coming to view. But I I've been a fan from the beginning mainly because it's less boilerplate. Right? Like, you're not exporting an object with all of these sections. You can just pull in the things you need.

CJ Reynolds:

And to me, that is in line with how most Vue code has been, which is, like, as little as possible to get the work done and and simple. But I think one of the issues is and and I've talked to a lot of people about it since, and I and I did a talk on the view composition API at at Denver script. And some of the feedback was like, isn't this just gonna create, like, really messy code bases? Like like, I've basically it takes a certain amount of discipline to write it in a in a composable or write it in a way that can be maintained as well. And and it's super interesting to see it.

CJ Reynolds:

Like, there are some people who were telling me, like, at their company, they introduced the composition API, and the developers would write comments, dates, methods, computed. And so they're basically, like, recreating the options API with all of these composition functions. Correct. So, yeah, I I think it's also a it's a it's a learning thing as well because I've I've realized in my career, like, architecting code in a scalable and maintainable way is is a hard thing to do. And so if if the framework isn't showing you how to do that, then a lot of developers aren't gonna do that because they're gonna do the minimum to get it done.

CJ Reynolds:

So, ultimately, I like it, especially when they introduced a script setup. I think I think when they released it, it came out with script setup. But

Alexander Lichter:

No. No. They actually didn't. It was like in 3.1 or 3.2. Yes, sadly.

CJ Reynolds:

Okay. But no. But I I just remember, I remember seeing the RFC, and I was like, this is it. Like, basically, it's Svelte now. Like, we we we we had no boilerplate at all.

CJ Reynolds:

Just, like, write your code, and so that was really cool to see. But, yeah, I understand people's reasons for not using it or not liking it because, like, it it can be hard. It definitely takes some practice and some work to know how to structure those composition APIs in a way that will be maintainable. But at the end of the day, I think it was a good change also potentially for React developers that are moving over to Vue because it it's not the same, but it has a similar feel in that you have these little functions like useEffect or useState or all the things you're familiar with in React, but now you can use them inside of Vue.

Alexander Lichter:

Yeah. Something closer closer to React Hooks. That's true. It's I mean, there's even a chapter aligning like, explaining the the similarities, let's say, and inspiration. But it it's really funny to mention the, like, the comments basically replicating the options API structure because I made a video, like, I don't know, half a year, even a bit longer about exactly that.

Alexander Lichter:

It's one of my most popular ones of, like, organizing code with the composition API because, like, I I I really think if you use composition API and do that, then that like, you as you said, you replicate the structure, why you should just group things by logical concerns, say, the code that belongs together logically and not by type, by, like, oh, all the computers, all the the state, that should go together. And another thing I see people not doing very often is what you do in a normal JavaScript or TypeScript file. You create functions. Right? And people, when they use reactivity and, like, refs and and computeds, they put them, yeah, next to each other, but they don't put them an extra function because then, like, okay, what should I do with that?

Alexander Lichter:

So Yeah. Or or they they do that. They they write a new file, like, in a composables folder and say use whatsoever dot ts, and then they put it in there. But if it just lives in one component, just write a function at the very end of it, like, you really like newspaper code style and call it, I don't know. Yeah.

Alexander Lichter:

Use, I don't know, message or whatever. Do give me their call at the top, and you have a wonderful architecture and structure. If if you can't fully split the component up even. Right? That's that's also an option.

Alexander Lichter:

But if you have a component that's, like, orchestrating a lot of things, then, like, these concern based, inline composables, they help a lot. And, funnily, that there was always how the composition API was was imagined to be. And maybe you remember that that screenshot with, like, that color, that the color blocks in the RFC of the composition API with, like, options API or composition API. And lots of people are like, oh, yeah. Can we get that at some time, like, unblurred?

Alexander Lichter:

It's technically, it's not even important. But if you take the new file of the composition API that Evan rewrote for that, RFC, it was, like, part of the Vue CLI. He even does that. He even used these, like, inline composables that says, okay. Like, the first ten lines after imports are, like, calling these functions in the bottom.

Alexander Lichter:

So I think also there, it's just people were so used to options API. And then, like, oh, composables. We can share code now. Let's extract everything. It just it was a lot of overcorrecting.

Alexander Lichter:

But also by now, I think that's that's way more clear. And as you said before, you need some guidance, need some structure, some architectural patterns as well to actually make the composition API work well, as in, like, not writing spaghetti code. And everyone could also say, like, yeah, skill issues, like we like we had before, which is in any way, it's kind of fair. I still think it's worth to put in that effort to make the composition API work also because it's the future and also because there are a lot of shortcomings in the options API that were resolved for it, especially TypeScript, but, of course, also sharing logic, less, well, less magic, even less this dot whatsoever. So, it's it's nice that it's there.

CJ Reynolds:

Yeah. I think that was the other big thing. Like, last thing you mentioned is this dot. So, seeing this dot all over the place in the in the a component built with the options API, it it felt like I don't know. It felt like OOP.

CJ Reynolds:

It's like, well, what is this? Do I have to worry about it? And so, yeah, it's really simplified things to be able to you have these nice little functions. Everything is available within that scope. You don't have to worry about this, but I I completely agree.

CJ Reynolds:

I think it's ultimately, I think if there and and maybe you've created this, like, a a a place of a lot of examples of how things can be structured. That that that will help a lot of people. Because I know a lot of programmers that get onboarded to a new code base, they potentially try to follow the patterns that they see in the code base already. And so if they can see, oh, this is a good example of of how I can use the composition API effectively, and, oh, I don't have to pull out everything because because it can go in both directions. You can, like, refactor too hard, and now, like, all your stuff is in other files and it's hard to find, or you don't refactor at all, and now it's all just in one component.

CJ Reynolds:

And so because it's up to the developer yeah. Yeah.

Alexander Lichter:

And I've seen both in, like, code bases. I do consultancy mainly, besides content creation and the podcast and so on and so on. It's like I've seen people yeah. With, like, 1,000 lines of scripts set up, and I've seen people with, like, okay. I have 100 composables each in their own file, and they only just use the one component.

Alexander Lichter:

So it it actually can go both ways.

CJ Reynolds:

Yeah. So, hopefully, like, there's more examples out there, and and people can, like, learn better ways of doing it. I don't know if the docs potentially has anything like that, but that's, like, yeah, that's the one piece that I think is is hard for a lot of people. And, like, I've met people as well that use Vue that were like, I'm not even gonna use the composition API because it's just too messy. Like, I I need the or not too messy.

CJ Reynolds:

Like, if they're yeah. The Instructure. I need Structure, and so they stick with the options API.

Michael Thiessen:

At this point in the podcast, you might be wondering, does everyone love the composition API, or are there people who actually like the options API? Well, you are correct in wondering that. And our next speaker, our next guest, Simone, has a differing opinion, and he shares it in this upcoming clip.

Simone Cuomo:

I think the composition API, the way it's being used was a mistake. Like, I really don't like it. And my explanation is that I'm not I really, really like it to create reusable functions. So for creating composable, I think that was precisely what was needed. And we've seen this with the VueUse use from Anthony Fu.

Simone Cuomo:

That repo is the bible of Vue.js. Like, without the repo, you cannot develop. But then I don't think, creating actual components. So UI component with the composition API has made the overall development cleaner.

Simone Cuomo:

More importantly for me, it's made it harder for people to enter into the Vue ecosystem. It was easier to teach people with the option API that it is now that to teach it with the composition API.

Michael Thiessen:

Yeah. That makes sense to me. And I I think I'd agree with that. If there was there is a way to use you can use

Simone Cuomo:

Correct.

Michael Thiessen:

Composables from VueUse with the options API in your components.

Michael Thiessen:

Yep. Which is which is nice that you can have you can have the best of both worlds there. If you want to, you can use options API

Simone Cuomo:

Correct.

Michael Thiessen:

And then get that that reusability. But it's still but then now you're looking at 2 different ways of writing your logic versus just the one.

Simone Cuomo:

Well, depends how we look into it. Because if we just think composition composable as mixins, you say, oh, you're just creating the useful logic, and then you just import them in your component and component are always with option API. You don't think it is 2 different way. But again, I'm, I know that I'm alone, unfortunately. I'm alone in that world.

Michael Thiessen:

Well, no. Okay. It's, I want you to stay strong in your opinion because

Simone Cuomo:

I will. Don't worry.

Michael Thiessen:

We need people who are like we need, like, debate and, like, healthy Correct. Back and forth. And I think it's not wrong that

Simone Cuomo:

Correct.

Michael Thiessen:

You know, lots of people like the composition API, but it's yeah. We don't want, yeah.

Simone Cuomo:

And then and and funny enough, I like to be vocal when my decision is different from the rest of the world because, I want people to know that it's okay. So if you go on Twitter, it's very clear. I always like to tell people things that I don't know, but I don't complain. I like to give my explanation and why I don't like it and say it. Because many times people just say, oh, yeah.

Simone Cuomo:

Yeah. This is cool. And they've joined a train just to look cool themselves. But deep

Simone Cuomo:

inside, they probably felt more confident or comfortable with the other version, but they will, you know, feel like they have to say that it's cool because everyone else is saying it's cool. So I like to really people, give, you know, show everyone else that, you can't say no.

Michael Thiessen:

And I think the imposter syndrome is part of that too because if everyone is saying the composition API is amazing, and Evan says this is probably the way you should be writing it. And, you know, everyone who has a platform on Twitter or up on stage is saying composition API, every example is composition API, and you're thinking, wow, I really just don't get it. Why can't I just write it with the options API? Then it's easy to feel like you

Simone Cuomo:

You don't belong.

Michael Thiessen:

You don't belong or you're not you're missing something or you're not smart enough to get it or you're not a good enough developer to understand why it's better. But you know what? There's there's different opinions on on everything.

Michael Thiessen:

In our podcast with Sumit, we did actually a 2 part episode of that, and he focuses a lot on the business value of software development. And so his take on composition API versus options API is a little bit different than some of the other guests.

Sumit Kumar:

So, yeah, everything new is is is that we also just recently enabled TypeScript. So, optionally, of course, but we start to type new stuff. We start to bring the types from the API to the front end, which is a great thing. Even for me as someone who would have never ever done this, I would never have done this, but I I know the benefit. I see the benefit, and, I'm looking forward when when we are there.

Sumit Kumar:

So we are slowly getting there, and I'm getting more familiar with the composition API as well. So I'm warming up to it. Me personally, my team my team loves it, but it's not everything is like we try to rewrite or change only what's necessary to make it work. So most of the code is still options API and yeah. But especially new components are our composition.

Sumit Kumar:

And we did it in the beginning. We had, what was the view composition API package or something?

Alexander Lichter:

Yeah.

Sumit Kumar:

So we used the composition.

Sumit Kumar:

Yeah. Yeah. We used that a lot, but there was also a problem for the migration because you had to change stuff and this was not supported anymore and you know?

Alexander Lichter:

Yeah. So, I mean, it's good that you didn't, like, just say, hey. All components, let's, move them all over because, obviously, that would probably be even more work for well, and and as I said before, like, no tangible results. Like, okay, their composition, but now what? Are they faster?

Alexander Lichter:

Well, that one millisecond, it doesn't really matter. I really like the the principle there in terms of if you touch a component, if you have to implement something, then maybe it's good there to migrate over if it's not like, I don't know, 3,000 line component, which theoretically shouldn't exist, but we all know that can happen every now and then or like a big page component. So that totally makes sense. And because otherwise, yeah, migrations with 150 lines like, 1000000 lines of codes, they would take forever and ever.

Sumit Kumar:

And, also, like, again, the question is also why migrate them over. Right? Like, I don't I I don't know if the options up is suddenly bad. I I haven't read about it. I only know why the composition API exists.

Sumit Kumar:

And if these benefits or the downsides of it are, you know, either not important to you or you want to avoid them, then I don't know. The options up here is still valid as far as I know, but, I see many people advocating for it. And some of the benefits still have to emerge in my head, but, other people are seeing it. And this is something the only thing I I can think of where where I thought maybe even is wrong on this one. And but I I wish he's much smarter than me, so I'm sure, I will I will see the benefit at some point that he is.

Sumit Kumar:

And what I usually know from these front end or from programming in general, solutions like libraries and frameworks, etcetera, you understand them best if you experience the pain that they solve. And I probably haven't experienced the pain that the composition app is solving for me, not yet at least. And, at some point, I will get there, I'm sure, and and I will get it. And, again, I'm warming up to it. It's much much easier, in my opinion, or much more pleasant to use it with the script setup tag instead of having it having setup as an option.

Sumit Kumar:

This is this is something where when it's mixed, it's really painful with the return and everything, and, well, it's we have a lot of mixed components as well, and they are painful. So, that should not and we only have this mixed components because of, libraries like tanstack query that only support that while we were, you know, we were using async data a lot because it's great when you do server side rendering and have stuff pre rendered and prefetched. But now it doesn't work anymore, and we introduced this new framework and the, the, tanstack query, and then you need to use the setup. And it's just yeah. It's very messy.

Sumit Kumar:

But again, new components are very clean. They all use the composition API, and when you use script setup, it's much more pleasant, simply because you don't have to return this. You can structure structure it a little better. Just today, I was working on something, and I was refactoring something. And I liked that I immediately saw that, you know, every function, every computed prop, I saw that if it's not used in the in the template, my my IDE shows it to me, things like that.

Sumit Kumar:

And I know there are many more benefits that I just haven't experienced yet, especially with TypeScript, especially with, like, using composables more. Definitely. My team is very proficient, and they they use this all the time. I personally have never abstracted anything into a composable yet because I wasn't, like I always thought, you know, adding something into a composable means I want to reuse it. And I couldn't warm up the idea of putting something in the composable just to structure it differently.

Sumit Kumar:

Like, you know, having not, like, a 1,000 lines of code in one component, but, like, putting it into a different file via a composable. Like, I haven't warmed up to this idea yet, and just scrolling through a large component feels a lot more messy in the composition API because the code is mixed. Like, you can you can structure it by topic, but it's like, how do you structure it with code comment? Like, I put code comments and this is the logic for this. This is the logic for this.

Sumit Kumar:

They get

Alexander Lichter:

Well, it

Sumit Kumar:

It doesn't look more structured than than the options API in my like, for my eyes.

Alexander Lichter:

Let's let's quickly stay there because I think that's really good. Because I heard it heard it quite often, actually, like, what a lot of people coming from options API are like, what they're doing is writing slash slash props, slash slash data, and so on and so on. But Really?

Sumit Kumar:

Okay. I haven't thought about that. I've

Alexander Lichter:

yeah. Please don't. Please don't. Ignore what I just said. But what would you do in in, like, a normal JavaScript or TypeScript file?

Alexander Lichter:

Not Vue, just like in, I don't know, some some API router. So you probably would create a function. Right? Like, hey. This is code that

Michael Thiessen:

Yeah.

Alexander Lichter:

Like, belongs together, same concern. You put it in a function. And now if you say, hey, this is code that has some stateful logic. Right? It also belongs to one concern.

Alexander Lichter:

You can also put it in a function and then you put a use in front and it's a composable, but you don't have to put a new file. And that's what what Michael and I usually call inline composables. So keep them a component. You don't have to reuse them, and it's a bit like functions in JavaScript and TypeScript.

Sumit Kumar:

Okay. That's a good idea. I I wasn't thinking about inline, composables at all yet, and I will actually do that. I have a large component right now that, that is a composable API, and I like, you know, it had it has waypoints with observers, then it has drop down logic, then it had blah blah blah blah blah, all this kind of stuff. I will I will try this.

Alexander Lichter:

Next up, we have Jakub Andreevski, whose name I definitely didn't butcher here. We talked a lot about security of Vue and Nuxt applications, but also about the options and the composition API. Here are his thoughts.

Jakub Andrzejewski:

At first, I wasn't really into Vue 3 and the composition API. I was a huge fan of options API, and I really like this this interface. And I felt that the composition API reminds me too much of React. But honestly, when I started developing with it, I felt instant boost in productivity in terms of the things that I can do that basically work. And I have to do less work to make it work.

Jakub Andrzejewski:

In general, the new approach seems to be something that makes me more productive, especially if you join it or merge it with some great tools by Anthony Fu, such as the autoimports, for example. This is one of my favorite things in web development is when you have the same result, but you have to write less amount of lines of code.

Alexander Lichter:

And this is just It's still readable, right?

Jakub Andrzejewski:

Perfect.

Jakub Andrzejewski:

It's still readable. It still works. It still handles some conflicts. So it doesn't mean that it will break. It handles conflicts smoothly.

Jakub Andrzejewski:

So kudos to Anthony for that and many other projects he built.

Alexander Lichter:

And next up, we have Rijk van Zanten, who's not only the founder and CTO of Directus, but also big fan of the composition API. I guess let's, hear what he has to say about the options API and composition API there and why he maybe bet on quite early on it.

Rijk van Zanten:

And it was just because I I I believe in in the APIs of it that much that I was looking at the composition API in those very early days, and I was like, this is such a tremendous improvement over the component API that happy to or the options API. I keep forgetting. Yes. I don't know why.

Alexander Lichter:

Haven't used this for so long, but, you know

Rijk van Zanten:

I guess that's really why. It also never had a name until it became the old thing, and then it became it had a name all of a sudden.

Alexander Lichter:

Fair. Fair.

Rijk van Zanten:

I guess they they call it the object API just because it anyways, It's

Alexander Lichter:

a big object. It was just a giant object. But let's let's just stop real quick there because I think that's super interesting. So you straightaway had the hunch of, like, k, composition API. Like, it's it's miles better than the options API.

Alexander Lichter:

Why?

Rijk van Zanten:

It was, a, because you can organize the file itself by sort of logical grouping instead of what it's for. So in the options API write it down. On the options API, everything was grouped by the type of thing that it is. So all of your computers were were in the same block, in the same property. All your methods are in the same property.

Rijk van Zanten:

All your data props are in the same your your what you would call refs now are in the same block. Your props are in the same block. That, you know, it makes sense conceptually, but at the same time, once you have bigger components or just more complicated workflows or, god forbid, you wanna share, methods between components, that gets tricky pretty quick. And we noticed the same with some type safety things as well because of you know, to access all the data, you go this dot data, blah blah blah blah. It also meant that sort of getting TypeScript to work well into that mix in those days was basically you could kinda with a with some pain and suffering, but it really wasn't worth it wasn't worth the effort yet.

Rijk van Zanten:

Right? So the composition API sort of removed a lot of those pain points because now I could group my files by okay. Here's everything that has to do with sort of this, this responsibility and just get all the refs and all the computeds and all of the methods just in the same vibe, in the same part of the file. And it also helps that it became a little bit less opinionated again, funnily enough, or in the sense that it's it's I'm catching myself in the funny irony that I said earlier that it was more opinionated. That's a good thing.

Rijk van Zanten:

But it it does it did mean that you didn't have to go searching through, like, this dot chain to find some data because you had a variable that you defined yourself, and that's the thing that you're talking to. So I think from a mental model, that that sort of simplified things a little bit.

Alexander Lichter:

I would say this just became a bit more JavaScript again. It became a bit more JavaScript to this.

Rijk van Zanten:

Yeah. Yeah. Oh, exactly. Exactly. And that that just took it one step closer to the sort of, oh, it is just HTML, JavaScript, and CSS with a bunch of utility functions that you can use to make it even better.

Rijk van Zanten:

Like, that's that's kind of the feeling that it that it raised, which was just yeah. I felt like right at home.

Evan You:

And I have to say with Pina.

Rijk van Zanten:

Like, Vuex was really good for what it did. But at the same time, the model of, like, you're defining an action, and then that then runs a mutation that goes into a store, and then that sort of updates somewhere, and then you pull the data out. And it's like the mental model of that. And I have the same with Redux in in the React land way back in the day, which had a similar mental model. And it was it was just a bit tricky because I'm like, it's just JavaScript.

Rijk van Zanten:

Just let me update a variable. What what are we? What what are we doing here? So when, you know, the very, very earliest thoughts about pina came out that it was like, oh, this is literally just a ref like I would use in my own components, but in a separate file. Well done.

Rijk van Zanten:

There we go. High fives all around. High fives all around. This is all I need.

Michael Thiessen:

Yeah.

Rijk van Zanten:

This is all I want.

Michael Thiessen:

In my conversation with Eduardo a few months ago, we talked about pina and a whole bunch of other things, but we also talked about the composition API. So up next, you'll hear his thoughts on that.

Michael Thiessen:

And so the question is, k, we've got these, like, three main ways of doing state. And how do we know when to use which one? Like, when should we be using pina versus just using a couple of refs versus creating a composable?

Michael Thiessen:

Or how do you think through this problem yourself? Maybe there isn't like a like, a single answer or best practice, but, like, at least just, like, yeah, take us through your thinking on that.

Eduardo San Martin Morote:

Yeah. There isn't a single answer, and the reason is because, you have people who work different ways, and they like to organize their thoughts in different ways. And the composition API makes things very, freestyle. That's not a correct way to say in English, but you are really free to organize the code however you want. And that has its good parts and the bad parts.

Eduardo San Martin Morote:

I think it has been covered in other episodes with Evan You. So when you use the setup stores, which I will really encourage people to to use most of the time because they are really more powerful and flexible, you really have something that looks like a composable, and that's very intentional. Right? I want that to feel as close to pinion as possible because you can reuse all the patterns and the knowledge that you already know. You're not really wasting your time learning.

Eduardo San Martin Morote:

So they cannot you cannot say, oh, but I maybe this disappears later on, and then I will have learned something that I will never use because that's not the case. Yeah. I think another thing that maybe helps some people click is that when we look at stores with the options API, so state, actions, and getters, they are so simple that it doesn't come off as something very flexible or something where you can have a service. And so when you start using setup stores, because you have the full flexibility of just a function and returning whatever you want, Until you don't do that, you don't get to see the full picture of what you can do. And so I have this talk of that is called, disaster class Pina.

Eduardo San Martin Morote:

I think you've probably seen it in person or you were there, but it it talks a little bit about this, and it sees that it says I say at some point that I like to see sort our composable singletons with ASR Sport. So it's like a composable where you have the full power of a composable, but it only happens once too. There are, like, tons of ways of using pinion, and I know sometimes it's just the lazy way. And this is when it's just the lazy way, it's probably not the the good tool. Right?

Eduardo San Martin Morote:

You could use just the rest sometimes. Also, if you don't have SSR, right, you can use a global ref, and it works well. Although I wouldn't recommend that because you never know. You move to next year. You move to suicide generation.

Eduardo San Martin Morote:

We get into the complexities of of what Yeah. Development too.

Michael Thiessen:

Well, I think it's an interesting point about the, like, being lazy because I think that's a lot of a lot of things are affected by that. So when Evan was on talking about composition API and options API, he also mentioned that with the composition API, it's better, but only if you're actually, like, thinking through your stuff. And if you're if you're going to be lazy about it, then it can end up with, like, this mess. Whereas the options API, it forces you to have, like, some minimum level of discipline in, like, how things are organized. And so I think and even, like I mean, you could probably look at any any tool or any library and like, if you're lazy with it, then it it ends up working poorly for you and then like you yeah.

Michael Thiessen:

Just because you have pina doesn't mean you can't, like, you can't just stop thinking about what you're doing. You know?

Michael Thiessen:

In November, Alex and I had the honor to host a panel at VueConf Toronto, and the discussion was wide ranging, covering a number of different topics. But one that we made sure to get in there at the end was what different people thought about the composition API.

Alexander Lichter:

And let me do the other way around. It's a little bit of ping pong. Options API or composition API?

Evan You:

Composition.

Alexander Lichter:

Really?

Sigrid Huemer:

Composition.

John Leider:

Yeah. Composition.

Daniel Roe:

This isn't a question. Composition.

Michael Thiessen:

So now you've seen all of our guests that have given opinions on Composition API and Options API. Maybe you have your own opinion. Maybe you share your opinion with lots of these others. But, if you enjoyed this, then go and check out some of the other content that we've got. We've got plenty of episodes if you want to take a look.

Michael Thiessen:

We've got some downtime on the weekend and evening, you know, maybe while you're working even. Go check out those episodes. We've got, I think, 40, 41, 42 at this point. I'm I'm losing count.

Alexander Lichter:

Not too many. Still some coming. And of course, we also want to know what you prefer. Is it composition API? Is it options API?

Alexander Lichter:

Let us know on the socials, like on Bluesky. Let us know in the the comments, of course, on, like, Spotify or YouTube. We'll we'll check them all, respond to them. And, well, of course, you can also guess our opinions in terms of composition API or options API, at least if you listen to all the episodes and that little supercut here. So, yeah, looking forward to see you in the older episodes.

Alexander Lichter:

Michael said the next stuff as well. There are a lot more coming every week, and we have some amazing guests lined up, so can't wait for that. And, of course, hope you all enjoyed a few more quiet and relaxed days.