The second half of the conversation with Sumit Kumar focuses all on the technical side of his SaaS.
At first, Michael and Alex talk about Sumit's experience with the migration from Nuxt 2 to Nuxt 3 - and we all know this isn't an easy one. Further, the Composition API vs. the Options API, as well as structuring code and writing good composables are discussed. And of course, the question if Sumit considered rewriting the application based on another tech stack was part of it too - he had really good reasons why he didn't!
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.
Chapters
Welcome to DejaVue
How did your Nuxt migration go?
When did you start considering migration and why not earlier?
Composition API only packages and other pitfalls
Steps that you tried out
No such migration anymore
Time frame of the migration
What is CAPI and what stays OAPI
Getting acquainted with the Composition API
Structuring your Script part
Reusing Composables
Changing the Tech Stack?
Wrapping Up
The second half of the conversation with Sumit Kumar focuses all on the technical side of his SaaS.
At first, Michael and Alex talk about Sumit's experience with the migration from Nuxt 2 to Nuxt 3 - and we all know this isn't an easy one. Further, the Composition API vs. the Options API, as well as structuring code and writing good composables are discussed. And of course, the question if Sumit considered rewriting the application based on another tech stack was part of it too - he had really good reasons why he didn't!
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
Audio Engineer and Video Editor
Guest
Sumit Kumar
Founder of Parqet & Podcast Host
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.
Michael Thiessen:
Welcome to DejaVue.
Alexander Lichter:
It's your favorite Vue podcast. You just don't know it yet. Or maybe you do because, well, this is the second part of our lovely conversation with, the founder of Parqet, Sumit Kumar here. Before we talk a lot about the whole business aspect of creating an owned software as a service application, now we come to, an at least equal juicy part of the whole conversation.
Michael Thiessen:
And don't feel like you need to watch the previous episode if you don't want to. But if you do, definitely go check it out and find some great content there.
Alexander Lichter:
Exactly. So let's start with, all the technical parts, Nuxt 2 to 3 migration, and some more things we don't wanna spoil here, so let's jump into it.
Michael Thiessen:
So we've been talking a lot about business side of things. Now let's maybe bring it back to the the technical the view stuff. I mean, this is called DejaVue after all. So, let's let's bring it back. So you recently did a Nuxt 3 migration, I hear.
Michael Thiessen:
How did that go for you?
Sumit Kumar:
Woah. Not well. I'm not sure if there's anyone, who that migration went well for, but, no. It's not it's not fun at all, but, it had to be done. We also we didn't really prioritize it in the beginning, but at some point, there is, like, a point of no return where if you delay it any longer you know, we we tried with Nuxt bridge and everything, and then things start to break.
Sumit Kumar:
It's it's not a good experience. And, at some point, we said, okay. We drop everything else, and all the the entire team basically pushes through it. I don't know. It took us a month or something then, of focus very focused effort after some initial, exploration and and getting Nuxt Bridge to work.
Sumit Kumar:
Where also Daniel of the Nuxt, core team. Shout out, from my side, and very much thank you. He helped us, here and there with getting the first pull request to work. Yeah. And then we we finished it.
Sumit Kumar:
Now we are there, which is which is great, but, yeah, the migration is not fun.
Alexander Lichter:
So may maybe let's start, like, going roughly through migration itself. I mean, Parqet started as a Nuxt 3 application, and then, obviously, when Nuxt three came out and the stable release was there, of course, the first thought was not like, okay. Let's drop everything and migrate over. So this has to be planned nicely. This doesn't take just a couple of hours, of course.
Alexander Lichter:
So when when did you start considering migrating or you had to put first thoughts into moving over? And maybe what stopped you from doing it earlier?
Sumit Kumar:
Well, because because it doesn't provide any business benefit and not no benefit to the customer. Like, obviously, you can say, yeah, it's faster and just that and has more developer productivity, but these are very vague metrics. Some some metrics you don't even, track. So it's obviously not a priority at all to do this kind of stuff. So if I could avoid it, I would have avoided it because Nuxt 2 works great.
Sumit Kumar:
It solves all of our problems. The customer doesn't care at all. So, there was no point in migrating. At some point, there is, you know, if supports drops and everything, but especially in the beginning, Nuxt 2, I think, came out, what, 1 year after Vue 3, something like this. So
Alexander Lichter:
Nuxt 3. Yep. Yep.
Sumit Kumar:
Yeah. Sorry. Nuxt 3. So there was a big discrepancy where Vue 3 was already out. Then Nuxt came.
Sumit Kumar:
Nuxt 3 came, but the modules, the community modules, and all these things we, like, we we use so many libraries and and modules. There was just no support for everything that we used. So it was always like, okay. You can migrate this, but this doesn't work yet, or you can do this, but this doesn't work yet. So we waited until we thought, okay.
Sumit Kumar:
Everything has moved over at some point, and we also didn't want it to be the first to to migrate. Because if you run into problems that no one else had, like, how are you able like, it's impossible to find solutions except if the the core team helps you, but you don't want to be a burden on them as well, because they are doing this for free. They are doing this open source. You can't expect them to help you. I don't want to expect them, to help us.
Sumit Kumar:
So there was just no no reason to upgrade immediately, only downsides, basically.
Sumit Kumar:
And
Alexander Lichter:
Or that it's not even possible, as you mentioned. Like, okay. If if you have a lot of, like, libraries you depend on, they don't have a Vue three equivalent yet or they might not have one, then, yeah, what's the options of waiting or doing it yourselves, which is also really possible given that you don't, like, are not a big company and you also have features to ship.
Sumit Kumar:
And there are, you you know, there are all kinds of things. And Vue 3 introduced the the composition API, and that meant that some libraries or plugins or components, not not components, but but, yeah, libraries of Vue 3, they switch to the component API, and that means you can only use them with the component API, and that means you have to rewrite every component because of that migration. And that is not something that is, like, a lot there, but we noticed this, because Vuex, for example, we use Vuex very heavily, and now you have to use the Pina store and or you should use pinia store. And everything was centered around that. So you read the documentation, you read the migration, you read what people say online, and you think, like, is Vuex even supported?
Sumit Kumar:
Like, can I use it? And if I use it, like, where do I get help if I have problems? It seems like it's deprecated from, you know, from and I know I might be wrong on this. I'm saying this as someone who where I know you you 2 are very into Vue stuff. You know all of that, but I don't.
Sumit Kumar:
I, like, I use again, Vue is a tool for me. I don't look at it as a a hobby to do Vue or to learn Vue or to learn everything about it. I I read what I have to read in order to do what I need to do. So, even though I'm I might be wrong, it's just when I tried to do it, we had, I don't know, 10 different pull requests at some point where where we try to migrate or try to introduce Vue bridge and stuff just broke everywhere. We also had front end tests, you know, component tests.
Sumit Kumar:
They broke, obviously, all of that stuff. It was very chaotic and very, very hard to debug and to find the like, I couldn't have done it. I couldn't have done it. My my team did it. With the help of, Daniel.
Sumit Kumar:
We we did, we solved some stuff, but at the end of the day, I can definitely say I would have not been capable to migrate me personally. My team luckily was capable to do that.
Alexander Lichter:
So what what were the exacts, like or exact what's most roughly the time or the steps that you tried out or, like, that maybe didn't work? Because, I mean, you you said, like, for example, oh, yeah. Vuex and pina or options API, composition API. And while these obviously are are big things, I I personally at least have seen a couple migrations where people said, like, you know what? Of course, the components that touch pinia in a way, we have to change them.
Alexander Lichter:
We have to maybe migrate them over at some point. We maybe have to, I don't know, create a wrapper component that uses the composition API and leave the rest, like, out. But keep, let's say, most things static and avoid all these moving pieces. While it's, of course, very tricky with lots of libraries changing and and Vite and Vue 3 and so on so on and and Nuxt modules. But, like, yeah, what what what was your your approach, so to say, there to make sure this was as painless or, like, as little as less painful as possible, I'd say.
Sumit Kumar:
So to give context, right, we have about a 150,000 lines of code. We use server side rendering. We use precaching. We use the JSON LD module, right, for for SEO stuff. We have obviously all the single page application stuff.
Sumit Kumar:
We had the progressive web app stuff. We had, the Vuex, we use vee-validate extensively in our forms with vee-validate was a very hard topic during that migration, because we basically had to touch everything, for that, everything where it's used. So I would say we use the full power of Nuxt in in every regard. We have a lot of dynamic routes, like programmatic routes, thousands of pages or tens of thousands of pages, actually, and even a 100 thousands, I think.
Sumit Kumar:
So, yeah, it was it's a lot, that you have to think about and test.
Sumit Kumar:
And the first step obviously was to go to the Nuxt 2 website and look at the migration guide. Right? And that then you go to the first steps, and this is what we did. Like, we try to prepare as much as possible and and but at some point, it's like quicksand.
Sumit Kumar:
You put one step in and then there was an error and the solution is, oh, you also do that step. And then there is another error. Oh, for that to solve, you also have to do that step and bah, bah, bah, bah, bah, bah. Your pull request is not one step into the Nuxt 3 migration. It's the whole Nuxt migration.
Sumit Kumar:
And, yep. Then at some point, we said, okay. Our foot is already eaten by the quicksand. Let's all jump in and just just go through with it, and then we did. We didn't really find good cutoff points where we could say, okay.
Sumit Kumar:
We can we can do this part and then ship and then just continue. So we would try to find them, and there were maybe 1 or 2 things that we were were able to merge into production, continue with our future development and things like that, and and these were good steps into into the Nuxt migration. The first thing was to install Nuxt bridge and have it work. That was the the first thing that we shipped, but we, for example, had to we had to do a lot of migration already, like, from the test suite and and and things like that to make that work. And then at some point, it was, yeah, again, no return, and we just went through with it.
Sumit Kumar:
The the it's also much better now, by the way. It we are we are glad we did it. That I also want to say that the migration is painful, but we are very, very happy that, we we did it.
Alexander Lichter:
Of course, I I just wanna say I hope that won't ever happen again like that in terms of future Nuxt majors. I mean, I'm I'm pretty pretty sure in that. But, also, we'll talk about Nuxt 4, which is awesome in a bit. I'm I'm just wondering back to the, like, the Nuxt bridge part. So you got that up and running.
Alexander Lichter:
How like, you said, you did roughly the migration rough almost a month. What do you say time frame wise? How long did it take you to actually get Nuxt Bridge up and running versus the, let's say, the rest of it?
Sumit Kumar:
It's hard to say because, there was always one developer, someone from the team, like, one person doing this exploration, trying to get it to work. Right? It it's a whole different game if the whole team is focused on this. Also regarding, like, costs, you know, or opportunity costs, what you don't do instead. And if only one person is there, they might try this on the side for a few weeks while then if the whole team goes at it, you can you can solve it faster, like, in 2 weeks or 3 weeks.
Sumit Kumar:
So that's why it's very hard. We always had someone there was always a pain or something where we said, okay. We we gotta do it at some point, and then someone just tried it on the side. You know? Try to get there, called other people to for help if they got stuck or ranted on Twitter, which was mostly me.
Alexander Lichter:
I've seen that
Sumit Kumar:
and trying to get get get help there.
Sumit Kumar:
Yeah. So at the end of the day, it took us a couple of months of thinking, but it's not it this sounds harder than it actually was. Like, it wasn't like the whole team blocked for for a few months. That that that was not the case. It was always someone trying, lots of frustration, and and then it was just, okay.
Sumit Kumar:
Let's do it. Let's migrate everything. Let's get a get rid of Nuxt bridge. We migrate everything. We look at all the errors and just fix all of them, and whatever it takes, we we do it.
Sumit Kumar:
And, yeah, that was then the migration path.
Alexander Lichter:
And now your components are all in composition API, like
Sumit Kumar:
No.
Alexander Lichter:
Okay.
Sumit Kumar:
No. No. No. No.
Alexander Lichter:
Because you as you said, like, you were like, okay. Options API now use everything in composition API with for example, which should also have an option API support. But anyway So so you left
Sumit Kumar:
For example, tanstack query is something that is only you only supporting composition API.
Alexander Lichter:
Sure. Yeah. That's true.
Sumit Kumar:
So whenever we wanted to use that, we we transitioned to the composition API. And every like we said in the team, every new component that we write is composition API. That is something the team decided I adhere to. I would have voted differently, but not my call anymore. Again, I'm I'm not a main developer anymore.
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 Vue composition API package or something?
Alexander Lichter:
Yeah. @vue/composition-api we used that to 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? Yeah.
Alexander Lichter:
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 API, but now what? Are they faster?
Alexander Lichter:
Well, that one millisecond, it doesn't really matter. I really like the boy scout 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. It was not like, I don't know, 3,000 line component, which theoretically shouldn't exist, but we we all know that can happen every now and then or, like, a big page component. So that that totally makes sense, and because otherwise, yeah, migrations with 150 lines like, 150000 lines of codes, they they would take forever and ever.
Sumit Kumar:
And, also, like, again, the question is also why migrate them over. Right? Like,
Sumit Kumar:
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 Evan 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 chaotic
Alexander Lichter:
You you by the way. You just mentioned maybe Evan was wrong with that that that what you just mentioned, composition API without the script setup compiler magic. Evan said in in the day of your episode actually on that, that this was probably the biggest mistake in terms of Vue 3. So
Sumit Kumar:
Okay.
Alexander Lichter:
Actually, yeah, not using it with with script setup and especially people coming over from other frameworks like, hey.
Alexander Lichter:
New composition API. Let's take a look. And then having that, like, bloated setup function with all the returns and super hard to understand and what's happening with props and and the context. Yeah. Yeah.
Alexander Lichter:
100%. That's why ideally, if you if you have to mix them, then probably migrating them over is is the better way than, like, mixing altogether, especially with service that are running coming into play there and and other issues or, like, using composables and then, like, not the setup function. I've I've seen a lot of interesting things in the last years.
Sumit Kumar:
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 asyncData 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 the a 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.
Sumit Kumar:
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. 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. That that 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.
Sumit Kumar:
And I couldn't warm up the idea of putting something in the composable just to structure it differently. Like, you know, having not, like, a 1,000 lines of code in one component, but, like, putting it into a different file via 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,
Sumit Kumar:
it It doesn't look more structured than than the options API in my like, for my eyes.
Alexander Lichter:
Let let's let's quickly stay there because I think that's pretty good. Because I heard it I 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? Okay.
Alexander Lichter:
I haven't thought about that. I've yeah. Please don't. Please don't. Ignore what I just said.
Alexander Lichter:
But what would you do in in like a normal JavaScript or TypeScript file, 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 Yeah. Like belongs together, same concern.
Alexander Lichter:
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 I usually call inline composables. So keep them in components. You don't have to release 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.
Sumit Kumar:
I will try this actually tonight, and
Alexander Lichter:
Perfect.
Sumit Kumar:
See, yeah, how it works.
Michael Thiessen:
I do. So I have a I have a an article that I wrote on this, and and the link will be in the show notes. And I'm also working on a course for composable patterns and and all that kind of stuff. So if you're interested in that kind of thing, just, you know, keep that keep that in mind. There'll be some more, info on that in the in the coming weeks.
Michael Thiessen:
That's awesome.
Sumit Kumar:
You can you can position your your tutorial to Boomer coders who doesn't like change, and they can, you know, they can learn this like me.
Alexander Lichter:
Yeah. But but yeah. Also that, like, Michael it's, like, in Michael's article is there also made a video about that, like, components organization, like, with the composition API, like, how to put code where and what's the composable and all that. So, yeah, all of that is also in the show note, and we'll send it to you after the show as well. Yeah.
Alexander Lichter:
Because, yeah, that's that's very commonly used. Probably you you all know that, like, that screenshot or, like, of of the the two sides, like, the options API and the composition API and different colored sections. It was, like, in the docs and and the RFC where it's like, oh, yeah. That's that's concerned by logic, and that's concerned by by, like, let's say, the the structure. And you see, like, all these scattered colors, like, okay, logic is separate in the in the options API, especially with big components you have, like, in your data function that returns the state, you have, like, 10 different features and compute it as well and so on and so on.
Alexander Lichter:
Well, of course, in the composition API, it's structured very nicely, but and that's the downside. You have to figure out how to structure that. But in a way, that's also part of being a, let's say, quote unquote, good programmer. I find a good structure for that in on the JavaScript and TypeScript. Now just making the connection, hey, you can use reusable functions.
Alexander Lichter:
You just put use in front of the composables if they have some kind of state, if they take reactive values and so on and so on.
Sumit Kumar:
More freedom means you have more responsibility to do the right thing and, or but you also have more ways to to screw up, the code base. And in my opinion, I'm I'm someone who is for very strict rules. Like, this is how we do it. This is the design pattern, and and this, what I liked about the options API. Mhmm.
Sumit Kumar:
But, on on the on the composition API, for example, you mentioned the in the docs, right, with the colors and and concerns. One thing that, like, I I I'm trying to do this. Right? But, again, I cannot, I can, for example, not collapse, like, I can do this with inline components. I understood now, so I would try this, but imports, imports, you have, they have to be on top.
Sumit Kumar:
So they are not separated by concern. They are still grouped together. Then the next thing is defining refs, right, const variable, whatever equals ref. I feel weird having those scattered across the code
Michael Thiessen:
Yeah.
Sumit Kumar:
The code, you know, by concern.
Sumit Kumar:
It's it's just a pattern that I grew up in and was, like, pushed in. The variables have to be on top. And so, I know I should do this in the in this new paradigm, but, it it's hard to to change that behavior.
Michael Thiessen:
I don't think I've ever thought of that until you brought that up, but I totally know what you mean that that, like, writing JavaScript is like, oh, put your variables at the top, always put them at the top, put them at the top. And so then, yeah, now I feel weird, like, declaring a variable further down, even if it makes more sense to be grouped somewhere else. Like, yeah, it's not it's not a natural way of writing.
Sumit Kumar:
Yeah. You define it at the top of the block scope. Right? So in the script tag, everything is top level, at at least from the the rest you define. But if you put them in inline composables, that's why I think this might be a good solution.
Sumit Kumar:
If you define it in there and return it, then we are getting somewhere
Alexander Lichter:
Exactly.
Sumit Kumar:
On the structure.
Alexander Lichter:
Then you don't have all the global state in the component, but it's really grouped to the feature. You can return them. You basically call them on top.
Alexander Lichter:
And to actually close the loop here, when we come back to the screenshots, like, to screenshot of options versus composition API, a lot of people and I have that in workshops a lot, and also made a whole video about it as well. It's like, hey. Can we see that un pixeled? Because it's always, like, super, like, pixelated and everything. And if you take a look at how Evan refactored component was back then from Vue CLI even, he literally did the same, had all the imports on top.
Alexander Lichter:
If Nox, you have auto imports. So if you use them, if you're a fan of them, they don't need to be all on top, but they don't need to exist. But that's that's also yeah. That depends a bit on, what you like or not like. Then you have basically all your composables called.
Alexander Lichter:
Like, it was, I don't know, useFolderPath, useNetwork, whatsoever. And you have also hierarchy. Like, okay. I need the network ref first and data pass into another composable. And that composable, I get something out and that this will go further and further until you have all the parts for the component.
Alexander Lichter:
And under then, like, a bit like the the newspaper stuff, like, the headlines first important parts, like, the the abstract ones, and then you have the functions, like, the the composables explaining, oh, this is how the network is initialized, this and that, this and that. So and and this is what Evan did from the from the get go, but I have the feeling a lot of people also when the composition API was introduced, they were not aware of this is how we should write it. We're like, oh, nice. Reusable. I can extract it.
Alexander Lichter:
I write a composable. I put it in extra file, and it's gone even if you just use it one time. And that's definitely no go. Like, only abstract it away for really will you reuse it, like, I don't know, notifications, toast, and whatnot, but not your components' internal functions.
Sumit Kumar:
Yeah. That's, I think that's a good way to think about it. So for me, inline composable is just, like, they they flipped a little switch regarding code structuring for me. I will, try this, as soon as possible.
Sumit Kumar:
And reusability, I have to say when I use a composable that someone else wrote, I can definitely see it.
Sumit Kumar:
I haven't wrote it myself, and it's still a bit intimidating to me because I'm scared a little bit of, for example, the life cycle hooks. The rule I was told or read was on mounted hook, for example, only on top level.
Alexander Lichter:
Or the composable.
Sumit Kumar:
That's also fine. Composable on top level. That's right. But yeah, then there are like some, there are some composables who use life cycle hooks in them, and that means I can put them in a life cycle hook themselves. Like I can do on mounted and then another on mounted that the composable is using for example, and this sometimes limits how I use them.
Sumit Kumar:
And it, it is a mental burden for me to think about this because I do it. I do it as an example in case it's too abstract. If you like, you want to do keyboard shortcuts on a on a website. Right? Then you do a composable for the escape key, and then you use it in there composable for key binding, like binding the events and un unbinding the event.
Sumit Kumar:
And binding the event should happen on onMounted hook. So where do you use the onMounted hook? Out, on the outside where you do, you know, use escape key, whatever, or do you use it during the key binding?
Sumit Kumar:
When it's in the key binding, you can do it, but then at some point, you arrive where you want to key bind something, and you use it in a different context, and that context has to be in the onMounted hook talk or something. Right? And then you you run into this error. I I did. So you just you need a rule set for structuring your code, and you need to think about this in the beginning.
Sumit Kumar:
Otherwise, at least I feel like this, you know, I feel like there was a lot of responsibility to do this right. And it's just intimidating for me to write composables because I don't know how they will be used in the beginning. I noticed one use case here, but it's very hard to understand how how they can be nested, etcetera, and some stuff work and some stuff doesn't work. So if there are rules in place in teams that say there is no life cycle hook in a composable, for example, right, to avoid this, then I can understand this, but I don't know these rules. I don't know where these best practices are or if there are best practices for this.
Sumit Kumar:
We have to find out and see what works, and this is a process that I'm I'm a bit concerned about. You know?
Alexander Lichter:
Actually, not the first one mentioning that. Like, we had, Natalia Tepluhina on from the the core team who wrote, big parts of the Vue docs as well. And then she's she's working in GitLab. Right? They have, like, also a a huge number of engineers, and they still use the options API.
Alexander Lichter:
And it was the same part. Like, composition API is all nice, but the thing is of, like, finding a good set of best practices and rules is super important. The thing is they're not the best practice and rules for all like, not fall the same. If you use SSR, it might be different than using a plain Vue application. There might be shared, like, design patterns and ideas, also like what Michael and I talked about in previous episodes of Michael's course and some other free material as well, but it's true.
Alexander Lichter:
In terms of the life cycle hook in the composable though, it's totally fine to have a life cycle hook in there and have a life cycle component. Like, you can have tons of composables calling life cycle hooks. That's that's fine. You can even have a composable in the composable in the composable as long as they're always called top level. It's like, okay.
Alexander Lichter:
Component invokes composable useA. useA invokes useB, and useB says, oh, at some point, it's all cool. In a way, that's that's the beauty of it, that you now actually can share states besides some ugly mixins that you actually have functions. Okay. Whatever I'm called, that can be in a weird chain of reactions, but still top level in the setup function.
Alexander Lichter:
Even though it's through multiple levels of function execution, my Vue life cycles will still work. And sometimes, I'm just called directly, and that's also okay. So in in a way, that's that can work pretty well, but I agree there have to be some good rule sets in this practice because otherwise, like, oh, this composable should only be used, like, to say outside of server side rendering, then you have to denote that. That's, that's also one thing that's, it is definitely, like, how do you express that in the code base? What do you do with that?
Sumit Kumar:
Yeah. It's it's super powerful. And what what my team, also mentioned to me is that it's so much better than mixins and Yeah. This what I wanted to say is, I never used mixins. I maybe used mixins twice or something in, like, what, 10 years or something of Vue.
Sumit Kumar:
I'm not sure. So, also, again, a pain that I haven't felt, so I can't see the benefit yet regarding that specifically. Yeah. But, I I I'm getting around to it. I'm I'm I'm sure.
Alexander Lichter:
Definitely. So after the whole Nuxt 3 migration, or maybe during that. Have you ever considered switching your tech stack in terms of front end framework? Because of course, then people will think, oh, it's so much work to migrate. Maybe it's better to, like, I don't know, move to swells or or react or whatnot.
Alexander Lichter:
And, yeah, was it ever in on your mind that you feel like maybe that effort could be just a rewrite in a different stack?
Sumit Kumar:
So I thought about rewrite, in the sense that, maybe it's faster to rewrite everything than to, or, you know, copy the components over, but rewrite the entire app on a fresh Nuxt 2 installation Nuxt 3 installation than to do the migration. I thought about that a lot, and we talked about this, but it was never an option at all to to move to a different framework. We wouldn't switch away from Vue. I I will tell you in a second why. And regarding Nuxt, the the Nuxt migration was a little bit of a shakeup in the trust in the in in in how this works, from Nuxt, but I also think the Nuxt team did a great job in, like, catching that.
Sumit Kumar:
Like, I think it was it was very tough. I I I also think this came from the community feedback to the Nuxt team. They understood and they responded. I I think they responded well. And you also said, just hopefully, it never happens again.
Sumit Kumar:
I and I trust the Nuxt team that, you know, this this doesn't happen like this again. That basically very late after the Vue 3 release, you can even upgrade, but then there are so like, the community is so far behind that as soon as the community is ready, the support drops, for example. So we we felt like there was never the right time to do that, and I feel I feel like everyone learned from this. The community did not see everyone. So I think that was really nice.
Sumit Kumar:
There was a but at that point where this trust was a little bit shaken, I looked at other SSR frameworks on top of Vue. And the only one I found was still in development. I I thought it was really nice, and and how how we did things, but, it was not battle tested. Right? It was very in the beginning.
Sumit Kumar:
And, again, I'm not looking for a solution to toy with. I'm looking for a battle tested solution that I can build a business on. So, yeah, I I don't like to try stuff. I want something boring that everyone uses that just works, basically. And that is also where we get to why did we stick to Vue and and Nuxt in this case, and it was not an option to switch, purely business perspective.
Sumit Kumar:
Everyone on my team knows it. Every developer that we hired knows it, and the customer doesn't care. And there is no benefit for us in switching only only costs. It only costs us time. It costs us stuff to learn new things.
Sumit Kumar:
And, yeah, and and the preference from my personal point of view, even though that is not the deciding factor today, but, it's still there for the, for the syntax of Vue for the way Evan and, and the team and everyone, that is like, working on Vue and and Nuxt is deciding stuff. Like, I'm much more aligned with their point of view and how things should be and and and where things are going than, for example, with React or some other frameworks, but all of the meta frameworks, like, I haven't even looked at them.
Sumit Kumar:
Again, there is no point in in learning new frameworks for me right now. But again, it's a team decision at the end, but there are some things that I would block. For example, I don't block that the team is going for TypeScript on the front end or going for the composition API, etcetera.
Sumit Kumar:
So it's their call. But if they say we want to rewrite everything in React, I would block that. I that's that's a there is no benefit that they can convince me of. And I would I would still have a lot of, the downsides. I need to maybe hire new people.
Sumit Kumar:
Everyone has to learn it. We have to rewrite everything, and we would be, like, I don't know, half a year or 1 year busy without benefit to the customer. And this is this is not an option at all.
Alexander Lichter:
Totally makes sense. I I think that's also the problem a lot of other people have with their projects. And I think, like, a problem in terms of people using other frameworks saying, hey. I let's say I use React. I always use React.
Alexander Lichter:
We have a project in React, and, of course, you can't just rewrite it to Vue, do, like, half a year or a year of, like, halting the business. Even if your developers say, hey, Vue is so much more fun. It's more joy. So, obviously, that's not a that's not a way. Have you thought about maybe, I don't know, smaller pet projects in the company being spun up with other frameworks?
Alexander Lichter:
They're like, hey. Okay. Just, like, try it out, test it. Maybe that's that's the way to go. Can also, of course, be in in other directions as as, for example, Vue is lacking, like, a React Native.
Alexander Lichter:
So for a native application, well, there are other solutions. So I'm I'm curious which, which results you have there.
Sumit Kumar:
Yeah. That is a good question. So I have seen many approaches in in my career, and I also think I've made some mistakes on that front, as well. If it depends on how well it has to be maintained. Like, what what happens a lot in in teams everywhere, I I would say in every in every team this happens, and it's totally normal that there is a young or junior developer coming in very excited about a specific framework, has has opinions, knows it best, like, knows it better than the people working on the team, but, also, it's the best thing he knows.
Sumit Kumar:
And they come on and they want to rewrite everything, or they want to have a new app and that has to be React because framework, whatever, Vue is old and or not large enough or whatever. I can understand that a 100%, but it would be a mistake to give into it because if that person then writes this new app and you want to maintain it and they leave, then the entire team has a problem. And this is not only for frameworks.
Sumit Kumar:
Like in the beginning, I was like, okay, front end developer, he has to be able to write all of the frameworks, but the frameworks became so powerful that you can't that there are terms like React developer and Vue developer simply because the frameworks are like, they have their own kind of language, and and you should you should know them ideally if you join the front end developer team. A good front end developer is still able to learn all of that, all of them, but, still, people have preferences and all of that.
Sumit Kumar:
But it's a rule for for the entire code base, for the entire developer team. If, like, someone wants to write a microservice in Go or and Rust, that's cool. If the rest of the team is on board and is, like, supports that. And I think as a CTO, one needs to define a set of programming languages that are, you know, allowed at the company and allowed to test out and that are supported and that we will hire for, and the rest, we don't. Because if you have a zoo of programming languages and libraries and best practices and things to do, like, things are very hard to sync.
Sumit Kumar:
Things are very hard to find the right people to support, and you cannot switch around people, and you don't want your technology to stay in your way. All of the programming language will solve 99.99% of all the things you want to do as a business and of all businesses that exist. It does like, you don't need trust or go or react versus Vue. It's just preference. And there are a few very, very small edge cases where you get to the limits of note or the limits of Vue or whatever.
Sumit Kumar:
So it's a personal preference. And in my opinion, it should be decided once and then the company just sticks to it and ships. And only if there is a very, very tough, like, downside, you should you can migrate away from that, for example, from Java to Node or whatever, something like this. But as long as you find developers for it, it's, you shouldn't you shouldn't make that that effort or, you know, just as a hobby. You're wasting time if you do that.
Alexander Lichter:
Yeah. I think with that, we're we slowly have to wrap up. There's still so many questions in terms of, what you think of the the the future of the Vue ecosystem, maybe what's missing from from your point of view. If you have tried out the Nuxt 4 migration, the breaking changes yet, and so on and so on. But, I'm I'm more than sure that, we'll have you on soon again, in the DejaVue podcast if you're inclined to join us, one more time.
Sumit Kumar:
Definitely. Perfect. Definitely.
Alexander Lichter:
I mean, it's like going on for almost, 2 hours here, raw recording. So it's, it was a lot of fun. We we all learned a lot from a business side and from a technical point of view. And, of course, there's there's one more last question, Sumit. Where can people follow you all around your your bootstrapping story, all around, Parqet
Alexander Lichter:
Share everything you want to share with us right now.
Sumit Kumar:
Okay. Yeah. Thanks for having me. This was this was really fun. Okay.
Sumit Kumar:
I share most of of, what I do and how I do it on on Twitter, so you can follow me at @TweetsOfSumit. That is my username pattern. I use it everywhere. VideosOfSumit is the YouTube channel, of course, and, I also run a podcast. Currently not that, active, but, I will get back to it, soon.
Sumit Kumar:
That is called minimal empires. That one is in German, though. It's also on the YouTube channel, and and focused on on bootstrapping and building a business. Yeah. So these are the main channels.
Sumit Kumar:
I'm on most of the social networks as well, but on Twitter, I share most of the stuff. Instagram is is private, and I'm also on Blue Sky and stuff like this, but but Twitter is the main one. Yeah. That's, that's it, I think. And, of course, if you're German and a finance nerd, you can also check out Parqet, also on YouTube, and I'm I'm live there every Friday, as well, but that is probably very low overlap in audiences.
Alexander Lichter:
Well, I mean, there are a lot of German listeners actually according to our stats. So yeah. And, why not? So yeah. Sumit, thank you so much.
Alexander Lichter:
Links, of course, to all of that in the show notes slash description so you won't miss out. You don't have to, like, lifetime it. So don't don't worry about that.
Sumit Kumar:
Awesome. Thank you very much.
Michael Thiessen:
Yeah. Thanks for coming on.
Alexander Lichter:
Thank you. And, for everyone, who didn't listen to all the episodes before, please check them out. We had mentioned some of them, like, with with Evan, for example. We had some with with Daniel Roe, other Nuxt core team members, Vue core team members that we mentioned along the road. And, yeah, definitely give them a listen.
Alexander Lichter:
And if that's not the latest episode, then quickly jump to the next one and continue. Thanks, everybody. Stay tuned and, hear you all slash see you all soon.
