Visualizing Data in Vue (with Dennis Adriaansen)

Welcome to DejaVue.

It's your favorite Vue podcast. You just don't know it yet. And we are in episode 52 here. It is Michael and me again both on the microphones after lovely episode with Patak all around Vite. Definitely check it out if you haven't heard or seen that yet. It's a long one as well. And of course, not only it's with us, we have a wonderful guest. With us is senior front end developer, Dennis Adriaansen. Dennis, how are you doing?

Yeah, I'm doing very good. I'm pretty excited to be here. Thanks for having me.

Of course.

Yeah this is a bit of a special episode in a way. 52 episodes, I guess. That's a year in my books at least.

It's a milestone.

Indeed. Yeah, it's a milestone. I don't know if we forgot to plan anything special other than having you on.

If you had me say something, I had to get some confetti or something. But

Yeah. Yeah.

Balloons. But, I mean, there there will be a kinda, let's say, unconventional episode in in a little bit, so you can definitely stay tuned for that. It's, like, maybe in one or two episodes from here as well so to say, belated special. But, yeah, it's it's happened. One year of the DejaVue podcast and hopefully many more years to follow.

Oh, congrats, guys.

Thanks. Yeah. Thanks.

Thank you.

And well, coming from that whole year to another special, Michael, you also have a somewhat big announcement, right?

Yeah. So Mastering Nuxt is the second edition or maybe not the second edition is not the right way of saying it. But the next big version, big update of Mastering Nuxt is coming out on March 25. And that should be next Tuesday if you're seeing this seeing this in the first couple days after it comes out. So you can go check that out at masteringnuxt.com.

Sounds great. Yeah. Check it out. Link in the show notes, of course, as usual. And, yeah, it's it's really nice what you cook there over the the last, well, months, so to say, of, like, preparation using all the new Nuxt features and diving a bit more into that.

Yeah. Yeah. I'm excited. I hope people like it. So we'll see see how it goes.

Yeah. If if people try it, they should leave some feedback here or send it straight away. Oh, yeah. For sure. We'll we'll look into that.

That's some time ago. I think I'm programming for more than eleven years now and I did start with programming HTML CSS like all of us. And then after my internship I went to a company and I could stay there with a lot of smart people and that was really fun. They introduced me to Angular, Angular 1.6, I guess.

Angular JS basically.

Angular JS, yes.

Wow.

Before the second two, it was pretty exciting. But other than I know Vue now, it was really MVC based. So Model View Controller, that was the thing then that was for the back end and Angular introduced it for the front end. So that was my first framework that I touched. And at my second company, they worked with Vue. Formerly a reason for that was Laravel shipping Vue JS really early on. And the back end was there, they're calling the shots. They used Laravel and they shipped Vue.

It's a pretty common thing that we keep hearing again and again about how either people started with Angular because that was popular at the time, But then Laravel has had such a big impact on Vue and I haven't used Laravel. I'm not part of that. I haven't touched that. I want to, as more and more people keep talking about it. But yeah, Laravel seems to have had like a really big influence on Vue and the popularity of Vue and how it shipped it at the beginning when it was not even version one yet and made it popular or helped to make it popular at least.

Kind of crazy how such a framework can bootstrap another framework just by shipping it it. I can remember a time that WordPress was programming on Gutenberg, their content management or their editor. And I heard sounds that they would choose for Vue, too. I do think it's React now.

Yeah, It has been React eventually.

It's been React. Yes. And they talked about maybe it's Vue. And I don't know, but if they choose Vue too, that's probably a major step towards the Vue ecosystem, of course. But it's React.

Yeah. But it's also funny, I don't know, Wikipedia, the Wikimedia Foundation , they, for example, also chose Vue as their JavaScript front end framework for all the tiny things they need there. Quite some other bigger companies chose it eventually. And Laravel is also someone who used Laravel in the past and came from the PHP ecosystem. So we have some in common there.

Oh, yeah. That sounds like sense.

Having like, Vue is first class. It isn't like, hey. You can try it out and people working on React, but Vue is the first in there. So it's still nice to see that even though React is, of course, the, let's say, biggest player in in the ballpark, Vue is still getting a very nice treatment, so to say.

Would you guys think that if the job market is a bit bigger for Vue, like if you ask people objectively to choose between developer experience of React versus Vue independent from the job market? I guess that so much more people would choose Vue or what do you guys think?

I think I'm not so sure about that because what I've seen in the past is people like React because it's almost simpler in a way because it's more JavaScript y and you can kind of there's less built in stuff. You, you know, you get you get to choose all the different libraries and things. And I don't know if it's quite the same as it was a few years ago. Maybe it's more standardized for, like, routing and state management and stuff. But it seems like there's some people who just want that choice, whereas, like, in Vue or Laravel, it's like, this is what you use, and it's easier in that way.

Okay. I would probably think the opposite. So that's that's quite interesting mainly because, yeah, the the just JavaScript part, I think, really changed with the composition API because now, like, Vue is closer to, like, the just JavaScript thing. Why people don't do this, of course, because and and, like, boot camps, for example, and, like, education, React is the main thing because of, okay. You wanna land the job. You should know React.

Let's change the job market then. Let's let's go.

I think it's really interesting because the quest the question always comes up. Right? And during Vue Amsterdam last week, there was also a panel discussion where, for example, Evan, Daniel Roe, Jakub, a few other people. And I also had a chance to take part while we're in there. And, course, the question also comes, yeah, job market.

So I see.

Under that post, straight away under that, was someone like, Oh, we are hiring for a Vue position. Why is nobody applying? So in a way it's really difficult and there might also be a mismatch in terms of hiring culture. It's no monocausal problem in a way.

I think you're right on that.

Think we also talked on the podcast about, I forget which episode it was, but about Nuxt maybe moving towards more enterprise-y level kinds of things. Because there is like a big difference in features that like a marketing agency or a development agency or like small these small businesses need and like a big enterprise needs Yeah. A different set of features. And so if Nuxt is more appealing to enterprise, then maybe that leads into more jobs as well.

That's a good point.

Yeah. It makes sense.

This could have been episode nine with Tim Benniks, where it was called Vue.js Large Applications or maybe with Daniel Roe, one of the many episodes with him. Maybe episode 13,

I thought it was a little more recent actually.

We have to to to watch so much episodes still. That's I don't have the time.

Oh, it's it's always tough with podcasts. But it's great for, like, commuting, just, like, listening to that or, like I I do it when I when I bike. I actually just came from a a wonderful lunch with Rijk van Zanten who was also on the on the show already, who was in town. I was like, let's let's grab some lunch. Okay. So that's always great a great chance. Or, like, in a gym. That's always good. But then it's like, ref versus shallow ref and you're lifting some weights. It's like

That kept you going. Right?

Either way, yeah, it's like, oh, shallowRef. Yes. There we go.

Well, if it's some hot takes that you disagree with, maybe it's like gets you, like, angry and you're like,

oh, yeah. Gets the

blood going. You can

Template template string on top. That's really a good debate and you get into a fight if you ask that.

Yes. Script first, not the template tag. No.

I posted about my charts on Reddit and Reddit is pretty not aggressive with their comments but they say what they think. But in the ranking for most popular posts in the month was number one was let's put the template tag on top. And you see that so many reactions and upvotes and downvotes, it's triggered so many people. It's so cool with such controversy the view ecosystem. It's so cool to follow.

It's it's also really funny. I mean, Michael, you post about it on Twitter as well. I even made a video about it too. So in a way, they're, like, controversial takes, and it's, I think, good to know why that also changed from, like, template first to script first. But in the end, these are things developers love to discuss, and it's great, but it gives zero value for any audience. Yeah.

No one no one experiences it in the in the full website. No consumer or visitor will ever notice such tiny thing.

And the code doesn't run faster. Your your code is like it won't change for the product if you do template first or script first. It's like, honestly, settle on the convention, enable like in the Essent rule that or like a lynching rule. Now we have also not only Essent the house that just says, okay. Template first and script or the other way around, and then you you just agree on things and it's fine.

Oh, I'm gonna push you in thinking.

I've actually switched now because I was I used to always just do template first because that's what I did. And then since I I posted about it and people told me that, they didn't like that, then I was like, well, okay. If I'm gonna do, you know, like recording videos and different content, then I'm gonna do it in a way that people are more used to. So I'm just gonna stick with the popular approach because at the end, it doesn't really matter to me how it's done. But if it's easier for you to follow in a video or something, then that's that's valuable.

Yeah. That makes sense. Yeah.

Do I also wonder, like, how much would it change compared to like, okay. Fine. I have the template part first or I have the script part first. Is it, like, really that big of a deal for people? I'm not sure about that. It's hard to tell.

I don't know. Don't know for sure. It's it's I think it's personal preference. If you like template first, go ahead. What's the most important is that you bring the team together.

Well, it's just one of those things where it's like, okay, if I remember to do it then it doesn't add any extra work for me and it might make it a little bit nicer for some people. If forget to do it then whatever.

Yeah. It's kind of balanced. If you please the others, disappoint the other group, of course.

That's actually one of the challenges that I got with the previous version of Master Egg Nuxt. I got a lot of feedback and it was like, all this like bimodal distribution, I guess, where some people were like, Oh, you're, you're going too fast. But then a whole bunch of other people would say, Oh, you're, you're not going fast enough. And then it's so hard. Or like, it's, it's too, the material's not advanced enough.

Yes.

Sampling different data points. So I have to get a bunch of data points. I can't just like see one person on Twitter said this was like, you talk too fast or you talk too slow. And I, you know Take it all at once.

That's the thing. Like, if you have to then, like, Gaussian distribution, just a normal distribution, you have, like on both sides, we always have people saying, okay. This is too easy or this is too hard or this is too fast or this is too slow. And the best case is in the most of the parts, especially with the speed, then put it down to 0.75 or to 1.25 depending on your needs. That's totally fine.

Yeah. This is so this is the last thing I'll say about Mastering Nuxt before we turn this whole episode into, like, an ad for it. And then we should we should get on to to talking about charts and things because that's, that's why why you're here, Dennis. So the, the last thing I wanted to say is that we were trying some, something new with the way that we structure it. So the first part of the course is like, kind of like the basics, getting things set up.

Very nice. I'm looking forward to this.

It sounds very reasonable. And it's it's a bit like the slicing that way. I I see the benefits. So, yeah, let's let's see how people like it. And in terms of people liking things, I heard a lot of people like charts, but they usually don't like building them.

That's a good question. I do think that the charts in general can make any dashboard or any interesting web page immediately more fun by its appealing. I don't know what it is. If you have two text blocks that are styled correctly and spacing is good and you add a chart, it's instantly more interesting. And I think the visual appeal about Charts is what we as content developers very much appreciate.

for, let's say, a dashboard, you want some charts. You want to see not only here is the text form, you want have the the things visualized. But even for landing pages, be it like for software as a service or anything. Like, yeah, some some graphics in a way make a lot of sense. And, I mean, there are also, like, tons of different ways to to actually show that, which I guess also brings some difficulties because, well, I don't know.

Oh, that's so cool. Yes. I like them too.

It's it's so great just to see a little bit little things visualize. So we see a lot of graphs in the end. And I wonder okay. Graphs are great. We'll we'll see them, but there are, like, tons of solutions out there already. Like, from things like, okay. Just use your own SVGs. Like, just come up with with a few tiny rectangles here and there. You have a bar chart. Tada. To more complex solutions like D3, for example. So how did you get into building chart components, first of all?

Another good question for sure. There are a lot of existing chart libraries and they are pretty good though. And I tested a bunch of them and the main thing I stumbled upon was getting into the details. I think we all know Tremor Labs and the Tremor charts and awesome components they are building. I kind of tried to reproduce such charts and what I found is that it's beautiful in the details.

Yeah. I think that makes a lot of sense. Like just, okay, I need these charts in different projects. Let's build a wraparound UniWiz and then making things even easier to customize for any level of setup necessarily.

Exactly.

Yes. And I've seen like you got like, yeah, I think thousand or so or even more likes on Twitter, which is of course great. I mean, people are always fascinated about charts, benchmarks, speed ups. So that was a good choice there as well. Before we get into the chart library part, what was your specific use case to say, okay.

My project before this project was our Nuxt error dashboard. So I previously launched an SEO tool on Product Hunt and that went firewall too. And there were way too many visitors on my site and I tested the application like 50% and I didn't catch all those errors. So it was partly a success, but it failed tremendously because the errors I hadn't overseen. So I thought, okay, I need to get a dashboard, simply take the Nitro plugin, catch the errors and send it to some dashboard.

Okay. So I'm not so familiar with unovis. So I'm wondering about what does UNOVIS provide? And then what does your chart library add on top of this to where are the lines there?

Most important difference is that Unovis is a wrapper around d3.js. And d3 provides exactly the vectors and calculations between a time series and how much values on the Y axis should scale if the data is increasing. So if you see that you have some reactive data, then the Y axis will scale with it. So that's what you obviously want. There are a specific set of calculations that D3. Js provides. And Unovus makes a wrapper about around that. So a bit easier to consume. But that's it too.

I think I see a lot of this around where we have like libraries or even services that make things just easier to use. I think that is a huge value, like without adding necessarily any extra functionality. If you can, you know, if instead of me taking a day to add a line chart to my app, I can take like an hour or even ten minutes, that's a massive thing because that's the difference between me adding a line chart or me not adding a line chart to my app because it's just like an extra thing.

I do think so. And I do not use AI a lot, but I saw the guys of Vercel and shadcn, they are pretty much intensified their CLI behavior and they want to run things via the CLI. So if you make things easier to generate, then those tools will be able to generate those things easier. I do think so. And if the generated code is also easier to interpret it, then UniR devs can work way easier with it.

I guess it also helps with the abstractions to like, okay, here's that component. It works. Here's documentation. You don't necessarily have to worry what's underneath. So you basically have that, let's say subset of an API. It still does what it should. It might be a bit opinionated but that's fine. And if you really need to then you can also read for something else if that doesn't fulfill your needs so to say.

Yeah, of course. You could first try my library and think, Oh, the charts are awesome. But if you find yourself in the spot and you think, I need more, then it's a level to downstep to. I'm going to use Unovis directly. And so you can upgrade as you need it to more dedicated tools. I think we all do that in all kinds of projects and software we use.

Yeah. Definitely. Like, I think using a dependency or like a wrapper of a wrapper of a wrapper until you might need to go a little deeper makes a lot of sense because, well, the rule of least power. Right? I have this specific subset. I use it until I need something more low level, so to say, or something that that wrapper can't do.

Yes. I don't know if the reasons for each library here lay down. But what I could remember for Chart.js is that they provide legends in the top right corner from the charts. And I find it way too hard to customize them. Maybe I didn't look enough, I don't know. But it's bothering me that it is there. Didn't like it. So it's mainly the basic configuration that pushed me away from it. I maybe had to dig a little deeper to learn it, to get the API up and running.

I used Chart JS in a Vue project a number of years ago and my experience was that there were some challenges with the reactivity, sometimes not working correctly. And I think it was really simple to get going and get started. But once I needed to customize something or get it to look a specific way, that specific customization was really difficult to do. And there was not an easy way to, you say, go down that level of abstraction to get a little bit more control over what's going on. It was like I hit a brick wall and was like, okay, we have to to throw it out and like try something new entirely.

Yeah. Same. Same. Exactly.

Yeah. Also, like, I think Chart.js is notoriously well known for not having the best docs. At least I've seen like, I I've used it in for as as you said, for, like, basic use cases. Like, it works.

I think something you said is really spot on. You said the ability copy paste something. I think we all like that we see an example that exactly matches our needs and that we can swap up the code and copy paste it. And it's even faster than using AI or something. It's why it's there and it's looking good. Want this. If you can copy that to your projects, it's an awesome feeling. So that's good reason.

100%. And then having, of course, all these examples that show different ways of doing things that like, hey, here are a thousand examples. Maybe they're tagged and you're like, I don't know. I want a bar chart and should have, I don't know, legends the legend only for I think legend on on the on the left or left and right and both whatsoever. Like, some more complex things as well.

Unovis has on this point no support for SSR as far as I know.

Okay. Interesting

They use the document I guess to generate the first baselines. Don't know this for sure, but I'm experimenting with some layer that I can fake the documents on the server and actually support the server side rendering in Nuxt, working on the module for Nuxt specific. So SSR is highly on top of the list because yes, it's awesome if it gets server side rendered.

Criticized.

Criticized. Yes. The most upvoted comment below that post was the performance of vector based charts. He said around 1,000 data points you get lag and your chart will slow down. I commented below, Okay, thanks for pointing it out. I never had such use case before so thanks that I know it now.

I guess that's because there are just so many DOM nodes going on in the document that it starts to slow down. I think, that's a good question because it's like, well, okay, that makes sense. At around a thousand, it starts to slow down, but how useful is it to see a thousand things on the screen at once? Like is it Exactly, yes. Like, can you actually understand that?

Solved it by avoiding it to choose not modal in the middle. It's funny you say that. I'm working at a great Dutch company and they have thought of modal and modals many times and they build it in jQuery and PHP. Long story, long story. But my team is always saying, do we need this?

Yeah. It's tricky. But I think especially they're starting with like, hey. Look. Let's actually see if that's something we can improve UX wise and then we can avoid all of that would be great.

That's awesome.

So we we've talked about it, like, in our, I think, 2025 prediction episode a little bit, but right now, like, vapor mode is is still work in progress. There will be if everything goes well on experimental version and three dot six, I think hydration is not ready. So for SSR, it's yeah. Not there yet, but the the Vue team is, like, working hard to get that done.

Yeah, true. Especially low end devices, yes.

So yeah, can't wait for that to happen. I think you can only try it out like in Vapor playground. We also linked that in the show notes for everybody curious. And then we can't wait for the next Vue Vue minor version as well where things happening.

Is there a time path for Vue Vapor that you know of of?

This is no, like, said thing, but I personally think this year would be very realistic. Of course, not like with full feature parity or, like, options API support, but as experimental comes in three dot six and the playground is already running it pretty well, I can imagine, like, that's we would see it this year. Yeah.

Awesome. I have to dive a little bit more into that. That's great material to dive into next week or this week Absolutely.

And are like as you said, there is the REPL you can already try out. You can run things in and see how fast it actually is. So definitely recommend checking it out. Also, some links for that for everybody interested in the show notes for the playground, but, also, there is a great document. We we mentioned it before about diving into the source code of Vue Vapor, which is, of course, a whole different story than using it.

Yeah, of course. I just released a beta version and that's containing the basic chart types like a line chart, area chart, bar charts and stacked area charts. Yes, stacked. I said that correctly. So those are the basic charts we expect in dashboard.

I think that makes a lot of sense. Focusing on that specific subsection, are you also planning to make some, let's say I mean, you have examples up there like, hey, this is how like a bar chart works or a line chart or similar. Are you planning to make like a little dashboards demo where you, let's say, have random live data being generated and the charts are updating, maybe some animations for that and all? Is it also on the list to see like, hey, this is what you could do or maybe hear even some default animations that happen when you update a chart or similar?

Yes, that's the first thing I'm going to do before expanding any chart types. I imagine a bar chart or an area chart with a sort of slider above that you can drag and that you can visualize the data changes into the chart. I think that's something we as front end developers really, really like. And it's cool to demo to stakeholders. Assume if we change this button color from green to blue, I assume that we increase sales by 1% and then you drag that bar to a percent extra and you see the data visuals.

More than sure, there are always people the same with I don't know. If you have a bug, you're not the only one having that usually. There are other people. And maybe they say something or maybe even contribute or just be like or just use it. Right?

I'm kind of new to the open source world. I programmed a long time but never did contribute to open source. But it's greatly allowed in our company And the Junior devs are pretty motivated to contribute to any library. So we had a bug in Tailwind CSS 4 lately. We were early adopters from the customized container queries.

But it's already great that you can do it throughout your working hours and you're not like, oh, there's a bug. I know there are some especially being a corporate and then they have policies saying, oh, yeah. You can't do that because then legal and this. As a as a German, I heard things. Well, of course, then what will happen is to just do it, like, sneakily with a different account and or, like, just write it down, do it in their, like, spare time.

Nice. We love to do it. And I think everyone should, especially if you make money about other people work, you have to give something back, right?

That would be great. The whole topic of open source sustainability and funding is sadly not solved. There are great initiatives like the Open Source Pledge where basically companies say: Hey, we give €2,000 per developer or employee. I'm not entirely sure, but you can check the website. I think it's per developer.

Yeah. That would be so great.

And yeah. That's I I think also if like more more and more corporations would do that, that that would just help. Plus, they can choose, for example, hey. That's your own our own stack. Let's support them. So we make sure we still can use them or there's a new version, things run faster, better and so on and so on.

And our people don't have to spend time fixing bugs or maintaining this project and they can focus on real business issues within the company. So it's a win win.

Exactly. Mean, that would be the other option of contributing. Right? It's not only money. Like we have talked with Patzak about it also last episode when he is hired full time to do full time open source and Stackbloods, but also other models like fifty fifty or a certain percent. So that's another way, let's say, not like throw money at it, but make sure, okay, people that maintaining critical parts or important parts of open source are well, can pay their bills.

Yes. Yes. Of course. It must be a win win. That's for sure.

It's kind of crazy when you think about like if open source software was all like if it didn't exist and was entirely paid for, there'd be so many companies that just wouldn't exist because they wouldn't have been able get started or afford the software or even now wouldn't be able to afford the software. So give some money

I mentioned some, but we all know the feeling that we really bite into a bug or bite into a solution we cannot find. And often that's happening in the night hours or in the evening when you're not at You can get loose from it and you keep thinking about it. But you say many problems get solved by an open source contributor. If it wasn't open source, that problems would maybe never get solved. So we are twenty years behind without open source, I guess.

Yeah. And some ideas don't even come up. Some things never happen. I also like the model that's like some source available because they're not by definition open source like projects follow on that you just say, okay, hey, it's free until your company reaches a certain amount of revenue they make and then you have to get license. Where it's like, it's basically open for everyone starting up and then at the end for the people reaching a certain threshold.

Yeah. I agree.

Yeah, we had you put down some things about what makes a good dashboard. We've kind of covered that a little bit about charts make a good dashboard. But do you have any other thoughts around maybe some UI UX ideas around that?

Yeah, I do think Charts make a lot of good dashboards. Also data tables, when you can't get to fill the data, they are just awesome.

Another easy component.

Yeah, I did tweet about the Nuxt UI three data tables that are using 10 stack tables and I just couldn't get used to TanStack tables. But now they are in Nuxt three UI and I played a bit more with it. I'm getting pretty hyped that it's the best solution to make such complex data tables, especially with pagination and I think that's a pretty good spot for now. So if if you say it was a good dashboard, I imagine some data cards, a chart, and an awesome data table below it. And then you can filter out everything you want and it's visual, awesome to look at.

That makes a lot of sense. Like, all the dashboards that you have, all data you want straight away there, it could be customizable as well. It's always a big big aspect. But like, oh, I want to see that differently or like give me that time span and save all of that. And yeah.

Yeah, let's fill it out. There is a thing with pagination though. You can paginate at the front end. So you get 1,000 records from the API and you divide it in pages. But if you need to combine the pagination component to an API and have to get pages with query paramates, page, it's X, whatever.

Yeah, there could be probably a whole other episode around that as well. On that note, in your company, your daily dev life, you use Nuxt, do you use a separate backend or is it all written in Nuxt JS and Nitro? So how are you usually doing that for your case?

No, it is a pretty old company. So the APIs are really old and they are making

Java.

No, PHP.

That was my second guess.

I say Symphony, but the real core API is built on Sense. Oh,

Zend framework.

Yeah. It's pretty old.

It's called Laminas now, think. It's still kind of around. Yeah.

I think you're right. Exactly. So they're making new APIs for us and we pass it to the next server routes. I love the option to cache our server routes. That in combination with Keep Alive, that has blown away some backend developers at our office. Come with me, work something on my page and I go page back, page back. Is this so fast? Did we do that? I said, No, no. That's the next part of the application. You have nothing to do with that.

You wish.

Yeah, you wish. It was fast. I know. That's something we do. We call the API endpoints from our Nitro server, do some caching and then modernize it to what we need. Also the transformer is awesome. We get a lot of unnecessary API data and we transform it exactly to our component props and we can just bind the response. Yes, it's a little too heavy. But we can bind almost directly the response and it works. That's the approach we use.

That's a really nice pattern because then you don't have to rewrite your entire backend, but you still get next step you're building gets a nice back end that's fast and like cached and everything.

You just consume

I've had a bug where we were V binding data from the API pretty much directly, but the component only took like a few props and then the the actual object from the database had I don't know. There were like probably like 20 or 30 different properties on this thing.

object object. That's also a very common thing.

Exactly.

You have to change that. That's so cool. And on transformers, you apply a response type and you apply the type you expect in your components and you write that once and it will work. And if the API is sending more data, if everything is correctly, we can see it while programming that's not good where we get back from the API.

That's true.

I love Nuxt server endpoint.

The whole back end for front end pattern is really useful. Then every application of multiple apps use the same back end as well, like different deployments, different regions, whatsoever can have their own caches, their own cache timers as well. So it's really customizable and you also don't have to budget like, Hey, backend developer, can you change this and that? You can just do it yourself, which is pretty helpful so to say.

True. Very true.

For those server routes, are you using something like zod or maybe contract testing or something like that to verify that the other API is going to give you back the things that you're expecting and things don't get weird and change around?

Not yet. It's response types with bind an interface to the response and we say, Okay, we expect a type for component x. And that's well developing. We can play with it. But as you mentioned, Zod prevents even more API data to come into the application and that's not the case for us right now.

There we go. Well, sorry for that.

Well, mean, it has pros and cons, right?

In my private project site, I do use it. I I wrote a little CLI for the server last time to reproduce some Laravel behavior in the the Nitro server folder. And there you have some resources and you have some request validation. And there you want to request validate with zod. So I kind of questioned myself why I do that in my private projects but do not apply it on my nine to five. Maybe I have to do that.

Yeah, definitely you should. Or at least bring it up and then people are like, Oh, what's that? Oh, parsing is apparently cool. Can make sure things work in runtime as well, not only pretend Predated you in real time. True.

Yes, it's really exciting to be part of this ecosystem. And I see a lot of backend developers kind of look at Nuxt before they, Oh, it's ugly, it's JavaScript in the backend. I don't like it. But now they see pretty much how the ecosystem provides lots of values. Think, oh, that's pretty cool. We need that too in the back end. I know for sure you need that in the back end. That's very cool.

Yeah. It's so great to see how that modern touch, like, influences people. Like, okay. I see where this is useful. There's still some parts that I don't like about it, but it's like, okay. That's that's good. Good that we have that.

Yes. Let's coach them to to do Nuxt too.

Yes. That would be great. That is the step where we're going. All right. For your dashboards, you have of course your chart library.

I do use Nuxt UI a lot lately. They do use SHACEN Vue implementation too. But I find Nuxt UI is really good, customizable and it's looking good already. So that's one thing I use the most lately and I think I'm going to use this for the upcoming projects all along. And my chart library will be focusing on supporting Nuxt as most important and therefore Nuxt UI too. What do you guys use if you have to choose a library today for a new product?

So I would choose Next UI now, but that's only a more recent thing for me. I spent a number of years working on component library for a company, so I built it all from scratch. And so that was like one of the most fun things that I I've done. So then I kind of got stuck in this mode where I just couldn't use any other UI library. I just wanted to hand roll everything myself.

Pretty sweet. Yeah. I I'm kind of in the same boat, I would like to say. I think I still hand roll a lot of things because I don't build huge dashboards. But for, like, let's say, internal applications, I just roll with with Nuxt UI.

Yeah. Yeah, that's cool.

And, yeah, shout out to the people there. Also like to Recur UI, which is the underlying UI primitives for for Nuxt UI as well. So it's basically a rebrand from Radix. And that's that's pretty good.

Yeah. One card zernonia is his name called, I guess you Yeah, exactly. He's also contributed to the Unovis Vue package a lot. So that's nice.

Yeah. That's that's the good part. He's also he's also into charts for sure. And, like, the the whole, yep, the whole RadixView port and now, like, the rebrand is, like, really amazing job. So Lots of credits to him. Yes.

I'm pretty active on X lately. So I post every day, mostly every day. So please follow there or send me a direct email. If you have my number, call me or ask for my number. I'm here to help and I like to share what I'm building. So keep an eye on my X profile and I will share a lot there.

Perfect. Links to all of that in the show notes, including your number. No kidding. We'll get all the links down there so people can follow along.

Awesome.

All right. Thanks for coming on. And yeah, it's been lovely to chat with you and to learn about some charts and things like that. I'm gonna have to find an excuse to add charts to to my next projects. Definitely.

Thanks for having me. It's that's been fun. Thank you again.

Of course. And for everybody out there, if that's not the latest episode and jump to the the next one or, like, keep listening. Otherwise, check out the older episodes. We mentioned a few quite old or the recent ones. But, yeah, definitely definitely have a look and follow along for more information around the Nuxt.me ecosystem. See you next episode, and thanks for tuning in, folks.