DejaVue

In DejaVue episode number nine, Tim Benniks joins Alex discussing how he used Vue in huge applications and how Tim and his team built 3000 websites for a single brand that most of you know - Louis Vuitton.

In addition, Tim shares his journey from becoming a nurse to eventually learn web development. Learn which benefits Vue brought compared to the old jQuery application, how Tim and his team migrated a huge system step by step and more!

Enjoy the episode!

Chapters
  • (00:00) - Start and Guest Introduction
  • (01:34) - From becoming a Nurse to becoming a Developer
  • (06:49) - Building Social Network before Facebook
  • (10:33) - Getting into Vue.js and Abandoning jQuery
  • (16:01) - Reducing Bugs with Vue.js
  • (19:33) - Accessibility - Reaching AA or AAA
  • (26:16) - Balancing the Stakeholder Needs
  • (30:39) - 3000 Websites with Vue.js for one Company
  • (32:49) - Building your own Component Library?
  • (35:40) - Cleaning up Technical Debt at Louis Vuitton
  • (38:23) - Gradually upgrading legacy LV software
  • (43:43) - Why not React or Angular?
  • (52:40) - Mitosis
  • (55:13) - Outro

Links and Resources

Creators & Guests

Host
Alexander Lichter
Web Engineering Consultant • Founder • Nuxt team • Speaker
Editor
Niki Brandner
Sound Engineer
Guest
Tim Benniks
Developer Relations Lead at Hygraph

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.

Speaker 1:

Hey, everybody. Welcome back to another episode of Deja View, your favorite view podcast. You just don't know it yet. Or maybe you do. Maybe you're a long time listener or maybe it's maybe the first episode you've ever listened, so welcome to the show.

Speaker 1:

And, as you've seen or as you hear, maybe you don't, Michael is, once again, still on Pertentive, but he will be back very, very soon next week. You you've heard him last week already, and you will hear him next week again. I'm I'm very convinced about that. So yeah. And, of course, I can't do the podcast alone.

Speaker 1:

I would I would never. I would be boring. So instead, I have an amazing guest here. He's, once again, a public speaker. He's a very, very amazing guitar player.

Speaker 1:

Some people know him as the doorbell death rail. We'll hear about more of that, in a bit, and he's a big enthusiast of UJS. So welcome to the show, Tim Bennix. How are you doing?

Speaker 2:

Thank you so much. I need to say your offline voice and online voice of this podcast is the most amazing change

Speaker 1:

I've ever heard.

Speaker 2:

That is super cool. Thanks. But that's like it's you are born showman. We all know that.

Speaker 1:

Oh, thank you so much. Yeah. We had a little little talk beforehand. It was like a few calm topics about, tractors, garden work, everything.

Speaker 2:

Exactly.

Speaker 1:

And here we go. Click.

Speaker 2:

Yes. Into the real thing.

Speaker 1:

Exactly. So, yeah, how are things? Pretty busy? All good.

Speaker 2:

Yes. As always. Like, I work at a start up, so things are going fast and everything changes all the time. And I get to use a lot of few, but also I have to use all the other things.

Speaker 1:

Yeah. All the other frameworks.

Speaker 2:

And learning as we go, basically. I I

Speaker 1:

think that will be an interesting interesting topic when we cover the the DevRel stuff in a bit. But maybe let's start in the beginning. I I like to do that with with guests a lot to start, like, okay. How how did you get into Vue. Js at all?

Speaker 1:

Or maybe, like, from from programming? Because as I know, but our audience might not yet, you you were didn't learn programming, like, straight away in high school. There was a bit of a journey there.

Speaker 2:

No. There there's a whole journey there, and there's actually another podcast I did a few years ago where it was all these people that came outside of code in an into code and how they did that. And I'm one of those weird ones because I studied to be a nurse, which is not something you would connect to, you know, being a programmer.

Speaker 1:

Not necessarily. No. That's true.

Speaker 2:

I I am, by nature, super creative. And so I've always wanted to do something creative like playing guitar or building something or drawing or and then at one point, a friend of mine showed me that he built a little website with Flash, and it had, like, some animation. I was like, okay. Let's go. It was done.

Speaker 2:

And I used to play some some old school games, and we had, like, a clan. So we would, like, be 16 years old and play with some friends. And now that's super normal. Back then, really not.

Speaker 1:

True.

Speaker 2:

And so we I just wanted to, like, make configs for the game and have clan tags and make, like, simple website. And it never became anything, but it gives you, like, a very simple in into trying out, hey, what is HTML? Do I even need Flash? All those things. Right?

Speaker 1:

True. I mean, you you had a purpose also. You had a problem to solve. Right? That's always the best thing.

Speaker 2:

Yeah. And even if you don't understand what you're doing, up until, like, my second job, I don't actually think I knew what I was doing. But I'm old. Like, in that time, nobody knew.

Speaker 1:

Yeah. We're all beginners.

Speaker 2:

Yeah. Exactly. If you were able to do HTML that was somewhat semantic, you were in the top 1%.

Speaker 1:

Yeah. Because we didn't have, like, I guess, Stack Overflow.

Speaker 2:

Oh, no.

Speaker 1:

Not a thing.

Speaker 2:

Yeah. None of the things.

Speaker 1:

We don't even talk about AI.

Speaker 2:

Yeah. Even that. And, like, I'm looking at some of the answers AI is giving now, like Copilot, and you're looking at, oh, that might be like a thing we did in 2009.

Speaker 1:

Yes.

Speaker 2:

Right? It's kind of fun how that history

Speaker 1:

seeps into it.

Speaker 2:

Right? Oh, absolutely. I I think I started doing it more and more. And then over time, I was able to pay, like, my university tuition with it. And I just did, like, super small things for friends and family.

Speaker 2:

And then I realized the the school that I did for to become a nurse, it wasn't really for me because I noticed when you work in that field, if you are super creative, you can actually solve a lot of problems. Mhmm. But not everybody in that space is in the mindset to be creative and then solve these problems because people are literally dying on you every day. You have to fix things. And everybody is in panic mode.

Speaker 2:

Everybody is in complainy mode. And it's just really hard. And it was also right at the time where the health care system in the Netherlands, where I'm from, switched to a more private approach, much more money regulated, and very complicated thing. And now it's kind of alright. But back then in that switch, I think in my class there were 230 people, of which probably 10 are on nurse now.

Speaker 1:

Oh, wow. That's that's really low for now. Return Yeah.

Speaker 2:

In that, in that year.

Speaker 1:

Crazy.

Speaker 2:

And so, yeah, at one point, I was having a dinner with my parents, and I and I said, oh, yeah, I saw my brother go to like a coding school. And I was like, I want that too. And they're like, please do it. Do what you want. It's much better than just do what you think you want.

Speaker 2:

Right? And so, yeah, from there, I did that school probably 4, 8 months, dropped out, started my first job, and there we go.

Speaker 1:

That's but it's so nice also from a parent saying, hey. Yeah. Do do actually what you what you like to do, Like, not get stuck in a job where you all, you know, like, hey, that's that's not for me. So there's also, like, a big big props to, like, your parents because, like, it's it's a big pillar of support there.

Speaker 2:

That's a that's a huge benefit and a huge win. And the funny thing is I didn't expect that at all. I felt like I had to do that thing because it was expected and we talked about it. Yeah. That gets a good cause because otherwise, if I hadn't done that nursing thing, I would have gone to, you know, school for music.

Speaker 2:

And I already kind of didn't choose that because I thought the other thing was better because everybody expected. Not really expected, but it it feels like a more solid approach. And it wasn't. So in the end, I still did whatever I wanted, which was nice, and it's a creative outlet. So I learned it through seeing people fail and nobody knew what they were doing.

Speaker 2:

So who cares? And then we started building cool things. And then most of all that after that is luck. You come at the right place at the right time, and you work hard, and you have the right people around you to teach you. I had luck, and I still have luck like that.

Speaker 2:

And so that's cool.

Speaker 1:

I I think, like, luck is definitely a part of it. But as you said, you worked hard. And I think this is something that's that's always important. It's not only like, okay. They're they're lucky people, unlucky people.

Speaker 1:

Like, if you don't work hard, luck doesn't matter that much. So

Speaker 2:

True. You have to be in it. Like, I always wanted to really go for it and do something really amazing even though I didn't know what that amazing was. And so you're kind of oblivious. And so I've worked in this place where we build social networks, but before Facebook was a thing.

Speaker 2:

Or, like, maybe at the same time. And so, we have these ideas of, like, doing small social networks around art related things. And then you could actually have multiple accounts on these different social networks, but you could be seen as 1. So, we need to figure out how can I jump from the one social network to the other one without changing my login, but they cannot know about each other's credentials? I see.

Speaker 2:

They probably know where we're going with this.

Speaker 1:

Yeah.

Speaker 2:

And so we're working on that stuff. And I remember doing, like, a drag and drop dashboard so you could see all your accounts. On all these websites, you could just drag your account from the one to the next to do a proper move or only do a clone and all these weird things.

Speaker 1:

Oh, okay.

Speaker 2:

And so from that came the first version of OAuth.

Speaker 1:

Really?

Speaker 2:

And I had zero idea. I was working on the first version of OAuth because it was just horrible. Nobody understood it. Because we didn't have that concept of, I'm logging in with a to b, and then we have to show the design of a on b. Otherwise, you don't know that you're logging in there with it.

Speaker 2:

We we didn't know. We had to find out the hard way. And then we did everything with get queries. So it was a huge URL with all the states.

Speaker 1:

Also limited as in like the URL length you own. Exactly.

Speaker 2:

We were hitting the limits of routers of people and sometimes you would actually not be able to log in because we kept the state on the URLs. Horrible. But the thing is, at that time, the people working in my office, they were contributing to the OAuth group. And I'm not sure what it was called, like a working group thing. And so we contributed a whole bunch of things, figuring out what to do and to try.

Speaker 2:

And then, of course, Facebook came along, took it, make awe too, and now everything is awesome. But it's so fun that you're completely oblivious. Just try some stuff and just use it. And then if it works, it works. And now looking back, that was pretty cool.

Speaker 1:

Oh, absolutely. And I I think it's really nice to be also, like, close to, like, pioneering such a thing as, like, OAuth. So, like, okay. Hey. We faced the issues beforehand and, oh, here's a way you solve it.

Speaker 1:

We, like, contributed to it. And I mean, without OAuth 1, OAuth 2 wouldn't be there. So it's, it's it's always nice. Even though, of course, it's like, oh, yeah. Okay.

Speaker 1:

We we worked on a certain part. And then, unfortunately, it's not in use anymore. But all the things that got inspired because of this, it's like it's such a big impact in the hand.

Speaker 2:

But that's also luck of the place where you are and also the time. Because you do you know this payment provider called Adyen?

Speaker 1:

-Yes.

Speaker 2:

-Or Adyen? Back then, we had to implement them on our website because people could buy a ticket to an event with that same account with OAuth and then pay. Then there were 4 people on the canals in an office trying to do payment. And so we're like, dude, that that's so cool. And it works so weird.

Speaker 2:

Let's do it like this. And then so you influence each other somehow. And now they're probably the biggest company for payment in the world

Speaker 1:

for sure,

Speaker 2:

but it's close.

Speaker 1:

They're they're definitely huge. Shout out, by the way. They they

Speaker 2:

knew how to do it. But it's kind of fun that I, of course, didn't contribute to their success. But you're close to it in that same in this, like, the time space. Right? I mean So that's where that luck is, though.

Speaker 2:

Yeah.

Speaker 1:

I I agree. And, like, also being in, like, in reach to these people, like, having also thanks to the Internet, but also sometimes physical to to be in touch.

Speaker 2:

Amsterdam was a good time in like 2,006, 7. It was an amazing place for startups and stuff.

Speaker 1:

I mean, still it's such a big tech type capital as someone living here. So now it's, it's pretty amazing. So, yeah, definitely, no regrets moving here. Of course, not just for that. But it's a nice side effect for it.

Speaker 2:

Be careful. No. But my, my first hit into few GS came a lot later.

Speaker 1:

Yeah. No.

Speaker 2:

Because I was in the space when j jQuery came out and it solved all our problems.

Speaker 1:

Yeah. Like, it unified all the APIs from all different browsers.

Speaker 2:

And it even it came up with APIs that are now normal. It's incredible what these guys did. And so then we had this whole phase of not wanting to do jQuery anymore because it was kinda slow, and all this dumb stuff was hard. And, like, we went through all the things. And I tried Angular and React before I tried Vue, but only their very first versions.

Speaker 2:

And I remember distinctly, I could not wrap my head around data flow first, then structure of HTML versus HTML first and then attaching something to alter it. Yeah. I remember distinctly when my back end colleagues figured out, Hey, with Angular, we can do this whole data first approach. And we can have these models and all these really cool things that then output into HTML that becomes something to show a state. And for them, it was so normal.

Speaker 2:

And I was struggling. I hated it all. It just didn't work for me, which is kind of fun because I just didn't use it for a long time. And everything that we did was just vanilla JavaScript. For the biggest projects we could have conceived, like, you know, we did FIFA 2012 website.

Speaker 2:

Really? Games, things like that. All just vanilla JavaScript. Just, you know, raw dogging it.

Speaker 1:

Yeah.

Speaker 2:

And so, yeah, it's it's kinda fun how these things move. And then when few came out, I I I remember I went to a job, to a new job, to work on this huge thing. And then they said, yeah, we're going to use, few GS, but not in the way that it was intended or not really.

Speaker 1:

What what was different?

Speaker 2:

Yeah. That's the thing. You probably know better than me because you've been in the few ecosystems a bit longer, even though you're younger. They had a back end generated HTML page from a dot net thing where we would then sprinkle on Vue. Js in different places, and then it would just enhance the DOM.

Speaker 1:

Oh, okay.

Speaker 2:

Which is exactly like how I used to work my whole career. Well, I had, like, little dabbles in isomorphic JavaScript with Node. Js that would then have scripts on both sides. Do we have to explain what that means? Because now it's so normal.

Speaker 1:

Actually, we talked about it in the the very first episode about the need for server side rendering. So, if people don't know what SSR or universal rendering or isomorphic JavaScript is, then, back to episode 1.

Speaker 2:

Yeah. Go to episode 1.

Speaker 1:

Good plug there.

Speaker 2:

That's my luck. The I didn't know that was gonna come up. But anyways, I did dabble in that a little bit. And so I thought, okay, so this is this new project. And I knew the back end stack because I had worked with that for a long time.

Speaker 2:

Yep. And so I thought, why do few GS at all? It doesn't make any sense because it's so amazing to do single page apps with and all that stage and all that cool stuff. And they even came up with and that was right before I started. Some of my now good friends actually worked on that architecture, and they had a combination of jQuery and few.

Speaker 1:

Buy both?

Speaker 2:

That was my question. Yeah. The first day I joined, I was looking at this. It's like, okay. Fuji is this new thing.

Speaker 2:

I've never touched it. Like, why the heck would we use that? Then I saw the jQuery thing, and I saw these, like, mid level developers getting no guidelines on a huge project. We're talking 3,000 websites here, like something like that. And they were just making plugins and stuff without rules.

Speaker 2:

And it was like all over place. I'm like, oh, boy. This is gonna be interesting to say the least. Because that back end system also had a front end accelerator that that was based on jQuery. So it kinda make sense that they chose that.

Speaker 1:

Okay. Yeah.

Speaker 2:

But I I don't know why I did it. But the first time I came in, I wasn't the lead of all of it yet. I was just in charge of this one project for the front end. And I said, you know what, guys? Let's do only a few.

Speaker 2:

Let's kill this whole front end accelerator of this tool. Let's build a grunt config Oh. Or maybe it was a gulp. It might have been a gulp. Alright.

Speaker 2:

I think it was a gulp.

Speaker 1:

Like, grunt grunt and gulp. I'm pretty sure some people listening don't know any of these tools. So

Speaker 2:

Good for you, people. Please don't learn. Yeah. We we had to come from somewhere. So we we and in in the end, we we build it on Webpack and a newer fuse stack, and it all was awesome.

Speaker 2:

But we have that, and I said, let's kill all the jQuery you already did. Let's rebuild it together and learn few together to rebuild what we did. And we started to use it a lot for all the interactive elements on these websites. And they were kind of, like, in this cosmetic space with lots of animations and fancy shampoo bottles turning and all that kind of stuff.

Speaker 1:

Lots of elements. Lots of images.

Speaker 2:

Yeah. Lots of, like, lazy loading, carousels, all the things that, like, cosmetics luxury websites would have. And I didn't know it then, but that set the tone for all our projects. And we went deep and we really learned few 2 at that time. It was when we started with few 1 and then few 2 came out Mhmm.

Speaker 2:

And I was lucky enough to not know few 1, and so I just did 2.

Speaker 1:

Yeah. That helps, like, with a fresh mindset, let's say.

Speaker 2:

Exactly. I I knew nothing. I just said, like, let's try. And we taught it to all our developers, and everybody started to love it because you have this especially with the options API, it was one way to go Yeah. Or kind of one way to go with its limitations, but we love those limitations because if we were teaching people, people who were just starting out could just look at it.

Speaker 2:

It's always the same. Let's go.

Speaker 1:

Exactly. Oh, yeah. Where to put things? It's very easy because you group it by the category of these things. So

Speaker 2:

Exactly. And so it really fit my brain personally because I'm this template first person and then you attach other things to it. That's why I had so much trouble with JSX for a long time because there it merges everything together. Yep. Where in Vue, you had the template and then you had the script.

Speaker 2:

And

Speaker 1:

And but back in back in Vue 2, even, like, the template tag first and all your templates, part and then the script tag. Like, now it's the other way around commonly, but, I mean, you can do it however you prefer.

Speaker 2:

Sure. I still do it the few two way.

Speaker 1:

That's that's totally fine. I mean, if it

Speaker 2:

If it works, it works. Right? Exactly.

Speaker 1:

If it's just that, then then, I mean, the grouping of of, let's say, variables, like, I don't know, my state, my props, my computed, and so on, With the composition API nowadays, of course, that makes sense to group by logic. Like if you have big components and not basically copied options API way. So as long as that that's not happening.

Speaker 2:

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

Speaker 1:

That was the space for it.

Speaker 2:

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

Speaker 1:

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 then x's if with with dollar options dot whatsoever as, like, a

Speaker 2:

done things like that, like workarounds like that and or or in an mounted function, just put a far or something.

Speaker 1:

Yes. Yes.

Speaker 2:

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 Few and we we were teaching each other to do it well, we found our way of doing Few. I think we had, like, 80% less bugs.

Speaker 1:

I can imagine.

Speaker 2:

That's just crazy. Like, for a project like that, on that level for a customer like that, that was a huge win. Of course, our back end systems caused enough trouble, so it was never great. But at least I could see it myself in my personal space from going from, like, this vanilla or jQuery based things to few, it changed the game completely.

Speaker 1:

Why do you think the bugs were were way less compared to jQuery over in the JavaScript? Like, what what changed from the coding perspective and from the mindset?

Speaker 2:

I think because it's quite structured, that helped a lot. So juniors and seniors could do similar things very fast, but also how few abstracted all the event bindings. Mhmm. And, data attributes setting or removing or all of that, it's done extremely well. And I think that's kind of that state machine of how HTML is set up and how you can bind events to it.

Speaker 2:

That's where we saw most of the trouble. And that's where it literally just took that whole thing away. So now the issues we would find is like some race conditions here and there or memory leaks because we would do weird things. Of course, that's what happens.

Speaker 1:

Yeah. For sure. For sure.

Speaker 2:

And the hardest bits what became in the end the more fun things is we had to do accessibility AA or sometimes AAA.

Speaker 1:

AAA is tough. Like, AA is

Speaker 2:

doable? AA is quite doable now that I've done it many, many times. But we had to teach people, okay, you have a few components that gives you a pop up. And inside the pop up, you have to do a few things with your keyboard and whatever, and then the pop up has to go away. What you need to do, especially in that time, we didn't have a lot of extra tools that we have now with few use, but we had to make a focus loop inside the pop up.

Speaker 2:

You couldn't focus something behind it anymore. And then sometimes based on the opinion of the accessibility people, you have to use your arrows or it has to be the tab or it's a different kind of list because with tabs, it could be arrows or the tab key if it's a list of tabs.

Speaker 1:

Oh, okay. Yes. Yes.

Speaker 2:

And so we were dealing with experts in the field that knew what they wanted opinion wise. So apparently, AA, if you do that, you can just get code compliance, but that's not actual compliance. Because then there has to be multiple people with opinions and say, yes, this is good. And then you have to recheck it. And I had developers cry when we try to do these kind of things.

Speaker 2:

But when you, you know, work together, in the end, it worked out so well and you learn

Speaker 1:

across. Yeah. Super fun. Just to to chime in here, could you just briefly explain, what AAA and and AA mean in terms of accessibility guidelines just, like, very, very briefly.

Speaker 2:

It's just how accessible something is for people that need assistance. And there's a few things you should say before we go into that. A lot of people have temporary assistance needs, which is very interesting. Let's say Michael who just had a baby. He will have a baby on his arm and then have to use his keyboard because he cannot use his mouse now or both.

Speaker 2:

That's a temporary accessibility need. And, there's also a difference between getting the actual stamp of yes, it's there versus the code compliance of it. Mhmm. Because there's an extra, opinionated piece there. Because if you look at something holistically, all your code can be awesome, but if it's unusable Yeah.

Speaker 2:

It's not accessible.

Speaker 1:

Absolutely.

Speaker 2:

And so the difference between all these As is just how many extra rules are set on top. And so AA is the, probably the base everybody should be able to do. You should be able to, have a whole keyboard. Like, you you can do everything with your keyboard on the whole side. There's labels on all the things there.

Speaker 2:

If something is expanded with every real roles, you have to say it's expanded or not. All those kind of things are states. But when you go to triple a, you have to also be able to say, let's do a checkbox for extra contrast or have a checkbox for, no animations are allowed. So you remove the checkbox.

Speaker 1:

Or you can

Speaker 2:

set it and then then yeah. And everything has to scale perfectly. And so we've learned this the hard way where in Chrome, when you just do command plus everything kind of scales nicely, right? Even if you don't use EMs or REMs. But when you then go to Firefox at that time, it would scale it differently because you use pixels somewhere.

Speaker 2:

And so you learn over time all these like details we shouldn't go into now because you have a whole different podcast then. All these little tricks. And in the end, we build great websites because of it. Because what you start doing is you use much more of the browser and then you enhance. So it's, it's basically this enhancement of basics of browsers.

Speaker 2:

So the more you use the browser, like if you do a form, actually build a form and then enhance its features so you can do fancier things. And so we just build better website with less bugs because of that.

Speaker 1:

I think also because you focus on the user, as you said, like, you actually test it, maybe even, like, use a screen reader or whatnot to, like, properly test

Speaker 2:

your website. We had so many, like, plugins installed. And then people who actually use those, they use screen readers about 60 times faster than you think they will. Yes. That's great.

Speaker 1:

I've seen I've seen it, like, in in real life how people that rely on a screen reader every day, like, use it, and you think, like, what what's going on? Like, they they know exactly because that's how they use the Internet. Right?

Speaker 2:

And also, you realize how crappy you build something. Yeah. Because they'll hear the same menu item, menu item the whole time. And if and if you just said what type of menu item it is, it's much nicer for them. Right?

Speaker 2:

So they have to tap in again. It's like all these things, like, you really learn how to build things better.

Speaker 1:

Exactly.

Speaker 2:

And FUEL helped a lot with that. Let's be honest.

Speaker 1:

That that's even better, like, because I think nowadays people always say, like, oh, yeah. The JavaScript framework, they will, like, really mess up with accessibility. And, of course, there are some things that you have to take care of when you use like, when build build SPA, like, when you navigate from one route to another to have, like, a Yeah. Route announcer.

Speaker 2:

Yeah. Exactly. That's an important one. Like, use actual links for things.

Speaker 1:

As well. Yeah.

Speaker 2:

But I think the only ones that really screwed up accessibility was was systems like Knockout JS. Remember that?

Speaker 1:

Oh, never used it.

Speaker 2:

So Knockout had like this first reactivity idea, but they would render a span to put all the reactive properties something could be in. So you would have multiple spans that would be rendered and removed and rendered and removed the whole time. Yeah. It was revolutionary but horrible.

Speaker 1:

Horrible for a a 11 y. That's true. That's true.

Speaker 2:

Yeah. Exactly.

Speaker 1:

Also, we we've linked the, the WCAG guidelines down in the show notes, of course, for double and triple a. Smart. But that's, as Tim said, for for another podcast because we can fill we can fill so much time on that. Oh, yeah. It's super interesting.

Speaker 2:

Exactly.

Speaker 1:

And, by the way, I like that a lot. I also also try to to use that, info about the temporary accessibility needs. Same like, I don't know. Okay. You you can't, listen to sound.

Speaker 1:

That's also, like, some people are deaf, or sometimes it's just a loud environment like a club or, like, you're a bartender or something and so on. So quickly.

Speaker 2:

Or slow Internet. Yes. Stuff like that. Yes. So it's it's Progressive enhancement is more about accessibility than you than you probably think.

Speaker 1:

That's that's true. And I think everyone will find a situation when where they have been into or might get into easily where they would appreciate these features. And if you think about, like, okay, hey, it's in the end, it's all of us. Like, it's it's good for all of us, then it's also a bit easier to think about implementing that.

Speaker 2:

Yeah. I was lucky again that I worked on these huge programs where they had top down rules. It has to be AA or you do not go live.

Speaker 1:

That's pretty cool. Yeah.

Speaker 2:

Right? But it also said you have to render the whole page, including page load of a CMS you don't actually have much control over. And document ready has to be in, like, 3 seconds, I think.

Speaker 1:

That's the performance part. Yep.

Speaker 2:

Yeah. And but they would if we would not make that, KPI, we would be fined, like, $5 a day until it's fixed. Really? We signed that deal.

Speaker 1:

Wow.

Speaker 2:

The thing is, though, they would add tech manager and add any kind of crazy thing on top, obviously. So we negotiated that down. It's like we deliver it like this and then we don't touch it.

Speaker 1:

Yeah.

Speaker 2:

And it's you. And then, like, you find all these balances. And that's how it works if you do it at such scale with companies that work in 60 markets that all have different needs. It's it's too hard to maintain that constantly. But it's really interesting to get into a project and then do all those things really well and then let it go.

Speaker 2:

That is just how it is.

Speaker 1:

Then see how it's rotting. Yes. No. But I And

Speaker 2:

there's a bunch of rot in there because we didn't have loading equals lazy in image text then. So I build all this JavaScript stuff with few JS to do, like, really nice ways of lazy loading. But that didn't age well. Right? It's actually horrible for CLS now.

Speaker 1:

Yes. But the browser's catching up. But, I mean, it's also good. Right? But that also shows how often you actually have to touch older or, like, running projects again to update things to keep on track.

Speaker 1:

But what what you said about the the balance of, like, Google Tag Manager, it's always, like, the the hell of every performance analyst and developer saying, oh, yeah, it's working super fast and then tracking on and, but on the other side, of course, marketing department wants the data, wants to figure out You

Speaker 2:

need it.

Speaker 1:

Yeah. Conversions.

Speaker 2:

I'm in the marketing department now, and I realize how much we need that data. So I now talk to developers the way marketers used to talk to me because there's just different, you know, maturities in different places and you just need something sometime.

Speaker 1:

But you also know both sides So you have an easier way to, first of all, explain to the developer why it's needed. And with all the cool tools nowadays, it was like, I don't know, Partytown and Cloudflare SaaS and so on. So it's it can even be in a somewhat performant way. Exactly. On the other hand, you can also explain to marketing maybe, oh, yeah.

Speaker 1:

Let's maybe use a different tracking tool if that's possible, which has less impact on the site and will maybe even lead to a better conversion rate because the site is loading faster and so on and so.

Speaker 2:

Yeah. There's there's lots to say there between marketers and developers and how it all works, but I'm pretty happy that I've now seen both sides.

Speaker 1:

Yeah. And that's I think it's it's so valuable. Like, I was talking with Mark, in the previous episode who is also talking a lot about that business versus the developer side and so, like, hey.

Speaker 2:

Exactly.

Speaker 1:

Let's if developers understand a bit more of business, and maybe also business stands a bit more of developer side, like high level, that's that's so much worth it.

Speaker 2:

Oh, it's huge. Like, that's what this is one of those things that I learned from these these large programs that we would do. It's literally a pot of gold for your career as long as you understand where to pick from. Because I did a whole conference talk about what I've learned about how do you act as an individual in a group of people that have to build this complicated website for your own success. But then also, in this I made a little framework because we're developers.

Speaker 2:

We make we love making frameworks. Of course. And so we have it for you, but then also how does your leader have to to work? And also, how do you have to work as a group to be successful? And almost all of it is all about half overview of what other disciplines do.

Speaker 2:

Because if you don't know why somebody made some sort of business decision, you can argue whatever you want. You're just being seen as annoying because you don't understand why they chose. If you actually understand it, you have some overview. You can argue easily and they probably agree with you. But maybe due to some other circumstance, they had to choose it.

Speaker 2:

But then if you as a developer understand, you're no no no longer really upset.

Speaker 1:

That's true. And

Speaker 2:

But if you don't, you're horrified. Yes. You know what I mean?

Speaker 1:

I I I fully agree. And in the end, also, like, everybody works towards the same goal. Right? So that's also something, like, there is no department a versus department b or, like, marketers versus developers. And we all want the same thing, but so everybody can work well.

Speaker 1:

There are different requirements, of course. And Yeah. Exactly. As you said, talking about it is is the key here because otherwise,

Speaker 2:

I just failed for a few years, and then suddenly, it all came together. That's that's the way, I guess. True.

Speaker 1:

True. So, yeah, then that that big project, you said, like, 6,000 websites. It's it's huge.

Speaker 2:

Oh, you doubled it, but I'll take it.

Speaker 1:

That's fine. Oh, sorry. Well, sort of 3,000 to 6,000, yeah, same same magnitude.

Speaker 2:

No. But you know what? After a few 1,000, it's all the same because you try to make software that you can reuse. Of course. And then they can because this is generally complicated by this for this kind of programs where a large company is usually super distributed and decentralized because you sell a shampoo differently in Amsterdam than in New York.

Speaker 2:

Different people, different marketing, different messaging, probably even different product even though it's just the same thing. And so they adopted that and sold a crap ton of this stuff. They know how to sell. But if you do websites like that, it's very messy.

Speaker 1:

Yeah. Fair enough.

Speaker 2:

Because in Amsterdam, they would hire agency a. In Europe, they would hire agency b, and they would both build the same thing. And then you would see in Denmark, they put a website up with 60 languages. But the Dutch one also has that language. Like, who who rules here?

Speaker 2:

Like, it it never works. And so, yeah, you you have to kind of centralize that bit a little bit. And then suddenly, we did, like, one one of their bigger brands had had these 60 markets. Mhmm. So probably 25 languages, 60 markets.

Speaker 2:

But that code base was relatively the same.

Speaker 1:

Just like deployed it for for each market with

Speaker 2:

Yeah. You had different hubs and they could different do different content and then different localizations, of course, different translations. And then some of them had their own components. And so we had Blaze was another KPI of this program where it says you have to have, I think it was like 30% reuse of the few components between all the brands. So every carousel of all these websites was basically the carousel I built with its 80% unit tests, and it just worked everywhere.

Speaker 2:

And they would adapt it. And then we would build it in a way that's like a base project. Okay. Let's add the way they can add different buttons because they'll always want that or swipe in a different speed.

Speaker 1:

Of course.

Speaker 2:

And so all these implementers or the developers could check our docs, grab the thing, and use it. And so that way you can scale to a lot of websites fast.

Speaker 1:

But did you build, like, an old, let's say, component library? Or how how was that

Speaker 2:

the component? That was the goal, but it never worked. So what we did in the yeah. You have to be real. Yeah.

Speaker 2:

Those things are really hard because you make the money based on the projects you do. If you're gonna do a component library project, who's gonna pay for that? It's really hard. So you have to do it on the site somehow. So, of course, we had some of it.

Speaker 2:

But we would just build a new project for a new brand, really nice updated things. And then other projects could just grab that stuff from us and then sometimes copy it.

Speaker 1:

Mhmm.

Speaker 2:

Or and sometimes we because we work with c sharp, we had this NuGet packages. It's like the NPM of that language. And so we had sometimes back end and front end components bundled and they could just grab it from the NPM more than NuGet and then just install it. But that that was an ideal that was never really realized, I feel.

Speaker 1:

I see. And I mean, as long as the components don't change that often, like, there's

Speaker 2:

some And so much some updates, but the old one still kinda worked because everything went through QA, everything, like, round after round, every round. So every project, even if it's a year older than the other one with different code, it's

Speaker 1:

still good. It's the worst. Right? Exactly. Yeah.

Speaker 1:

Yeah. No. But it's I think that's also a good point. And the the component library, like, I I've heard quite some people talking about, okay, we do, like, projects, we do component libraries. I think, especially for a scenario like you described, like, you have a big brand with lots of marketing, lots of websites, like, starting with the concept of saying, okay.

Speaker 1:

We have, like, a component library that resembles corporate identity and so on. I think that makes sense, but as you said, it can also slow down the process a bit in in the beginning. Like, okay, we have to build it. People have to, like install the package and so on so on, and there are updates, and then they have to update or the classic, oh, there's a bug fix. Instead of fixing it, like, in the component library or telling the response

Speaker 2:

fix it on your own. Yeah. Of course.

Speaker 1:

And then you don't you don't We had

Speaker 2:

we had all these problems, And we always tried it. And then what we've noticed, because I have done a few of these kind of bigger programs, where you would start really enthusiastically and then halfway in, storybook is no longer updated. Yeah. People start taking things slightly differently because they just have to make decisions and run fast and go live because their customer is on fire, which is always the case. So as long as you start with a good base and then people deviate, at least you give them some rules to break.

Speaker 1:

That's true.

Speaker 2:

As long as there are direction, break the rules. And if it's wrong, you fix it. Otherwise, go live, be happy. And so if you're less idealistic, it's actually better. More pragmatism.

Speaker 1:

Oh, I also think, like, start with as you said, start with, like, the idealistic view of, like, okay, let's set it up nice way, and then we can, like, slowly, like, maybe, like, reduce the standards or allow some more fast paced work on it. And maybe at some point also cleaning up technical debt?

Speaker 2:

That, I'm not sure how often that happened to be fair.

Speaker 1:

In your project. Right?

Speaker 2:

In lots of those, like, for these bigger programs, there were maintenance companies that were different than us. So that's always complex. I'm sure they did cleanup. I'm sure of it.

Speaker 1:

I I think so too. I mean, especially if it's, like, long long running at some point, you you you kind of have to because if you have to maintain, update things, dependency hell, Well, what's what's the choice?

Speaker 2:

Yeah. I think those those websites like, it for different brands, it's different. So for for these particular ones, I feel like they just run for 2 years and they want to redesign and they tend to just throw money at something else and just build a new thing.

Speaker 1:

That's also possible. Yeah. But but also, as you said, that that depends on the on the project, on the brand. I also know, like, especially e commerce people saying, okay, no, we want to have that in house. We don't want to don't want to rebuild it every x years, but rather, like, run, realize our own requirements and and so on.

Speaker 1:

But, of course, it's a total different type of project then.

Speaker 2:

Well, I've worked for that. Like, and I can the name of that brand was Louis Vuitton, where they had, like, this old Java system with, like I don't I think it was a custom front end based on whatever that system outputted as its front end. It was a monolith. Mhmm. And so they they need to separate it out because I think one release would be, like, 24 to 48 hours because it's so it's so big.

Speaker 2:

So many different systems running in the monolith, and you have to kind of dev ops it until it works kinda thing. And then they went for this thing. We need to release every 2 weeks. This is our new cadence. And so all these tech people are like, oh, shit.

Speaker 2:

Yeah. One TSS change, and we're losing 48 hours. And then maybe something goes wrong, and then the Chinese market starts up again. Oh, let's roll back. You know, so they had this and it's a very interesting approach because it worked pretty well, but they had to have a huge team.

Speaker 2:

And so they started hiring people to solve the problems of the system.

Speaker 1:

Interesting.

Speaker 2:

Rather than if something had to change or be innovative, they didn't hire those people. They hired, like, 5, 6 teams of 6 people that just fix bugs and build features in the thing. And so the at one point, we all realized, k, we just need to separate at least the front end from the back end. So if you wanna do a front end change, then that just that just releases in an hour and we're good. And so some of the people in those teams were able to step up and say, okay, cool.

Speaker 2:

Now I'm gonna learn something new. I'm gonna do it. But a lot of people were purposely hired to not be that. So they were in this kind of complicated place. And so we I I think we hired, like, 20 people or something.

Speaker 1:

Just for that.

Speaker 2:

Just for that whole new thing. And so it was a very interesting thing because this company has basically a person at the top that says, this is good, this is bad. For every page.

Speaker 1:

Crazy. Yeah.

Speaker 2:

And so I did come from this other project where every content editor was able to make a little puzzle piece of all their components, his publish and be happy. In for Louis Vuitton, that doesn't exist. In Belgium and in in the US and wherever, those pages are the same. They're the best copy written, best designed experiences. It's a 100% different product.

Speaker 2:

And so for me to switch to that is so different.

Speaker 1:

Yeah. Once again, a really different mindset as well, plus requirements too because then you Completely. You have they have you don't need less flexibility, which is pretty amazing.

Speaker 2:

I was pretty happy for that. I was pitching that whole thing with flexibility in mind, and they kept telling me, Tim, why are you talking about that? We don't care. I just couldn't put my mind there. At one point, of course, we did.

Speaker 2:

And that means we could actually just say, okay, we have the old website and we have the new front end. Let's just grab a page because it was almost not a component library. Well, we did build a component library to make everything kind of the same, but we could take it page by page. And so we would just have, a server in front that would say, oh, this still goes to the old, this goes to the new. And so in a year, we just built page, page, page, page, and suddenly it was really fast.

Speaker 2:

And they didn't know the difference because this is another really interesting thing when you work with these high level companies. You cannot just do a big bang release and wait for a year. People always want to see change, update. Hey. How does this impact the numbers?

Speaker 2:

Like, this is an organic beast. It has to go. And so, we did a redesign with a really amazing agency and then we applied the redesign to the old site and to the new.

Speaker 1:

That's clever. Yeah. That works.

Speaker 2:

And so, every 2 weeks after or every 3 after the sprint, they would see an update in the design on the old site. So, we were training all these folks that were working there to apply those redesigns in these horrible Java, XSLT, whatever nightmare they had to work in to update all these things. And then we would build a new thing on the site looking exactly the same, but then with Fuji. Js and Nuxt.

Speaker 1:

Yeah. Smooth.

Speaker 2:

And, but that worked extremely well. It was hard to do. But over time, you saw that website pick up speed And then there we would be building on that monolith. We would be building API endpoints and stuff to be able to serve the front end. But they did it in such a good way that at one point this back end could be removed and another one could be plugged in.

Speaker 1:

That's really a bit modular then, let's say.

Speaker 2:

Yeah, we just have to make it modular. Yeah. I haven't worked on that side for a long time, so I don't even know if they fully removed that back end yet. But maybe they don't need to. If they're used to content editing in that, it's cool because everything is such a structure.

Speaker 2:

They just have to make JSON structures essentially.

Speaker 1:

And they exactly know what they need and how to do it anyway.

Speaker 2:

Oh, yeah. They had 4 people, I think, working day and night figuring out search results. These shoes cannot be next to this bag, so let's change that algorithm a little bit. And it's incredible how much focus on detail there was. It's it was a really cool project.

Speaker 1:

For such a luxury luxurious brand, you you kind of would expect that as well, I would say, but still fascinating. Was perfect Yeah. Basically. Yeah. But as you said, migration did also, like, ring a bell.

Speaker 1:

Like, actually, nobody wants a big bang migration unless, like, it's a very tiny, tiny project because in in the end, you always have the issue of, like, okay, you can't just, like, say, let's stop our main product for, like, I don't know, half a year, a couple months, whatever.

Speaker 2:

Oh, yeah. It's it's impossible. Right?

Speaker 1:

No. But on the other hand, if you do if you do it like you did and and you described it very well, like a parallel thing, then Yes. You always have to apply everything that's new on on both ends.

Speaker 2:

Exactly. And that worked pretty well, but we also needed to gain the trust that we could pull this off and we had to hire new people and they had to hire freelancers. And so it was a really delicate balance of, okay. And they would keep asking me, Tim, how many people are you gonna hire? Like, I don't know if we're gonna go agile.

Speaker 1:

Yep. Let's see. You see

Speaker 2:

when I see. And that was really complicated to see and because they had come from this super organized approach, but we had to be extremely agile to make this work. Yeah. And so that was a really cool time because I had meetings with Philip from back then few storefronts, but it was few storefronts alpha for version 1, I think.

Speaker 1:

Well, that's quite some time ago. Yeah.

Speaker 2:

They just started. It's like 2017 ish, something like that. And so we looked at it like this is actually perfect. And then I went on holiday and I hired really, really good architects and they just started with Nux 2 out of the box. And that worked so well, we never looked back.

Speaker 2:

So I'm sorry, Filip.

Speaker 1:

If you hear that, then

Speaker 2:

mature enough then. Now, different story. But back then, that wasn't there yet. But it was really cool to see the beginnings of all that, and they need a lot of luck to change it all to few to Nux 3 now. Oh, yeah.

Speaker 2:

Nux 4 is coming out, like, next month.

Speaker 1:

Oh, that's fine. That's fine. Nah. But Nux 4, it's that's no biggie. First,

Speaker 2:

that's what they said for Nux 3. No.

Speaker 1:

Oh, no. No. No. No. No.

Speaker 1:

Luckily luckily not. That would be a blatant line. We all know that now.

Speaker 2:

Oh, yeah. Exactly. Now Nux 3 took a while to get there, but now, holy crap, it works so well.

Speaker 1:

Yeah. Right?

Speaker 2:

But Yeah. It's just ridiculous.

Speaker 1:

Talking about the past, so you you were using Vue and then Nuxt at Louis Vuitton, but how did it come that you that you applied Vue and and Knox there? Like, oh, I I guess there were also people saying, hey. Why not React? Hey. Why not, I don't know, Angular, whatever was fancy back then?

Speaker 2:

The funny thing is, if you work at an agency, you assemble a crew of people that can do a certain job well Because you don't want to have them sit twiddling their thumbs on the bench not doing something for a project or if they don't have a project. And, of course, you want to hire kind of generalists. So if you understand Vue, you probably understand React also a little bit. But because we did that large Vue. Js project before, I had this whole crew of amazing Vue developers.

Speaker 2:

They were really, really good. And so why not propose Vue? Because for us, it was then it's kind of the cheapest, I guess.

Speaker 1:

Of course, That experience, you had, like, the people there knowing that as well.

Speaker 2:

Exactly. And also in France, few and Nuxt are big. And if you are France, Paris based, like, I would just take the train to Bordeaux and speak to the Nuxt guy in their office. Yeah. Because why not?

Speaker 2:

You know, have some wine and discuss a project. That works pretty well. And so, we kind of just fixed it almost like this is the only thing you why not?

Speaker 1:

Yep. There's no reason against it. Yeah.

Speaker 2:

Yeah. And the only thing you could think of is that you could potentially, if you wanted, a lot of freelancers, for example

Speaker 1:

Job market.

Speaker 2:

Because you have to grow, React is easier. Yeah. Of course. Like, the job market in React is bigger. The thing is, though, the quality range in that job market of React folks is huge.

Speaker 2:

Like, if I were to I wouldn't do this now. But if I were to become, like, a freelancer to fix up React projects, I'd be rich. Because there's so little structure, you have to be incredibly good to do the best things. And it can go, like, to the stratosphere how awesome it can be. But it's really easy to miss it.

Speaker 2:

And, of course, with few to a to a degree, of course, you can do that too. I've seen horrible Vue implementations.

Speaker 1:

The same.

Speaker 2:

Yeah. But it feels it's slightly more structured due to the approach Vue took with the template and the thing, and it's slightly more structured at least.

Speaker 1:

I I agree. I was also I was talking to another colleague at a conference recently talking about, like, yeah, he's also doing lots of code reviews. And I said, like, yeah. Okay. Framework versus not a framework.

Speaker 1:

And then the topic was, like, yeah. Framework gives an easy onboarding because, well, every Yeah. Your application looks the same. And I said, like, yeah. Probably the same for React and Angular.

Speaker 1:

And then he was like, yeah. Well, Angular, yeah, sure. Vue, of course, from React. I don't know. That I I don't think so.

Speaker 2:

I'm not bad mounting it here because I've done a bunch of React projects recently, and I kinda love it. It's just a different approach to it. And, like, I love my Next. Js project that I did before they did the app directory thing.

Speaker 1:

So the Pages router was still your favorite? Don't like the App Router?

Speaker 2:

Now I don't try Pages Router anymore because I feel like the App Router should be the thing. And then you find so many quirks. It's not there yet. It's great. The ideas are super awesome.

Speaker 2:

When you see the folks to build it, demo it, you're like, yes. And then you use it and it's like, why doesn't it work?

Speaker 1:

Yeah. It's like, it's nice if it works in a demo, but then in real life project having all these issues.

Speaker 2:

Yeah. But they just have to grow. It's the same as with when Nux 3 came out, and it was so different. It had to just grow.

Speaker 1:

Yeah. Like, best practices and patterns have to emerge. Like, people have to use it, of course. Yeah. And I'm I'm also very happy that we are kind of over that phase in, like, Vue 3 and Nux 3 are, like, in a very mature way of, like, okay, how do you use it?

Speaker 1:

How do you do data fetching and so on and so on? So that's that's really a good thing. Yeah. But also, like, of course, not about badmouthing, right, it's more like the structure, like, because of the flexibility, because it's more, like, just JavaScript approach.

Speaker 2:

Exactly. It's very interesting, though.

Speaker 1:

And it's it's also way more flexible. And then you have, like, okay, state management, you can use whatever. And then you have, like, maybe files components and hooks and this and that. Yeah. That's, of course, these are problems that, the Vue ecosystem, for example, doesn't have in that way.

Speaker 1:

We have options API, composition API, and that's it more or less. So Yeah. Exactly. Besides that, we have one way to go. We have, like, one router.

Speaker 1:

We have one state management with UX being obsolete now. And that's that's a pretty good

Speaker 2:

Well, you can use use state now by Nuxt, I guess.

Speaker 1:

Yeah. Yeah. As well. True. If you use Nuxt, then you can also use that indeed.

Speaker 1:

But, yeah, in in the end, you could also, of course, build all yourself of composables. Like, nobody stops you doing that.

Speaker 2:

Oh, yeah. I've been down that road before because I just didn't know any better, and it kinda works.

Speaker 1:

Oh, it it works pretty fine. Yeah. Yeah. But, of course, Vipinha in the end is also a composable, but, let's say a glorified composable with, like, the dev tools, things, like, the the the plugins, all that. And and I see consistent to work with and with with lots of faults from Eduardo.

Speaker 1:

So it's like, how high does it how does it hydrate and all that. So Yeah. In the end, there is a reason why there is the solution. But, of course, to get started with or just to try it out, you can just do it yourself with composables.

Speaker 2:

But to be honest, I was building something a while back. I forgot what it was exactly, but it was lots of rendering of HTML that was super conditional and complicated. And I think it was probably in my conference talk that I did recently where people could live vote and then you would see a bunch of different screens update based on people's live votes and logins and lots of craziness in that in that talk. And I had it was in it was a little insane, to be fair. But in that, I was, like, rendering different buttons that people can share their vote.

Speaker 2:

And there was like 4 or 5 different options. And I was thinking at that time, like, if I had JSX and I could just render little scriptlets of HTML that I would then later on concatenate and then that's the thing Mhmm. Would have been incredible.

Speaker 1:

But you could.

Speaker 2:

Of course, in Vue, you can you can just do it. Exactly. You can even do JSX in Vue.

Speaker 1:

Indeed. Indeed.

Speaker 2:

I just didn't want to go there. But, like, this is the thing, right? In the end, all these tools have their own benefits. And you just need to kind of let go of your like, people like to love to be partisan about things. We don't have to do that.

Speaker 2:

No.

Speaker 1:

It's not. Use with you. It's not a framework war. I mean, also, we are all we all inspire each other as well. And the most important thing is that you can ship amazing things.

Speaker 1:

But, of course, if you have a certain use case where you have to think about, I don't know, performance or this or that, then there are just simply cases where you just evaluate, okay, which framework has the makes it the easiest for me without much manual work. If you know, like, okay, I have to switch maybe, my my platform provider in the future because you don't know if you go on the edge or not, then, of course, for example, Nuxt helps with universal deployment.

Speaker 2:

I I don't even think about where which edge I'm pushing it to. It just works.

Speaker 1:

Yeah. That's that's so nice.

Speaker 2:

But, of

Speaker 1:

course, if you say, okay. We're we're on Vercel. We need big job market. We have team experience again. We have so many people doing React.

Speaker 1:

And why should we say, okay. We use Vue now or Svelte. This is just realistically not how it works.

Speaker 2:

Exactly.

Speaker 1:

I think these are these are pretty amazing end words already. We're we're going for for 52 minutes almost. So

Speaker 2:

Yeah. I just told my colleagues I I'm I'm gonna be late to our meeting. So if you still have something else, we're good.

Speaker 1:

Yeah. So, I I thank you so much for for coming. We still have lots of things on the list, for another episode. So I'm looking forward to see you back here, then of course also with Michael, then, where the 3 of us and there were more interesting questions.

Speaker 2:

Yeah. I would love to look some at one point at that conference talk I did because if you want to go deep into how to connect technologies together in, like, this live fashion, it's it was crazy fun to do that with you. But that's maybe not for this episode.

Speaker 1:

Yeah. You can you can watch it already because the replay is live. Like, the last episode we talked a bit about Vue's Amsterdam, of course, also mentioned Tim's talk.

Speaker 2:

When is it live, this replay?

Speaker 1:

It's when it this this is, recorded it already is recorded. When this is, at a, like, show broadcasted release, then it's already live. It should be on Friday 17th to Thursday 16th, something like that. So I'm gonna see back

Speaker 2:

my talk for the first time.

Speaker 1:

Yes. Go for it. And, yeah, of course, all the links in the show notes as well, and that's definitely something for for next episode to dig deeper into, like, how to do that, how to play guitar live on stage.

Speaker 2:

Yeah. That's a whole different thing, but few help me. Like, that's so much fun.

Speaker 1:

Oh, I can imagine. Also, like as a as a visitor and viewer, it was amazing. Last question from my side is, is there okay. 2 more 2 last questions. Is there anything else you didn't talk about besides the conference talk that you were like, hey.

Speaker 1:

This this, is a must have. Anything we missed out?

Speaker 2:

Not really. I think I think we're good. We still have a lot of more in-depth things if we wanted to, but maybe that's not for now.

Speaker 1:

For sure.

Speaker 2:

Yeah. One thing, though, I saw this morning. You probably know this thing called mitosis.

Speaker 1:

Yes.

Speaker 2:

You heard of it?

Speaker 1:

Yes, I did.

Speaker 2:

And so I'll explain it a little bit to the people watching or listening and because I have this thing at work where I work at High Graph which is a headless CMS and of course you can use any front end to connect to it. But to be able to show that off, we need good demos. And so our demos are not just in Vue because I like Vue. There's lots of our developers that use other things. And so I was thinking, what if I do one mitosis database or one mitosis code base that would then spread out into all these other front ends for one demo.

Speaker 2:

Because Mitosis can do this thing where you have one base and you say render it in few, please.

Speaker 1:

Exactly.

Speaker 2:

And render this in React or whatever. And I think it matured a lot. And so that that's what I'm pondering today. Like, maybe I can do one code base like a monorepo maybe with a base and then 4 other projects in different languages. Yeah.

Speaker 2:

Have you ever done something like this?

Speaker 1:

Like, not not really like this. Mitosis as the, let's say, just to to to give a give a frame around, it's basically a component library with, like, own syntax. You can use, like, the Svelte style or or It's

Speaker 2:

kind of jxx ish.

Speaker 1:

Yeah. Or jxx, you have these two options. And then this can compile to not all, but lots of the popular frameworks. So Exactly. You, Svelte, probably also Angular.

Speaker 1:

I don't know it by heart, but React and so on so on. Yeah. So the I think the idea is pretty cool. I know like, when I took a look at this, when I did my thesis, so, like, roughly 2 months ago, it was still in beta. It worked for simple components, but Okay.

Speaker 1:

The the more complex gets I was saying, like, okay. First, in what you said, I don't want to use anything that's in beta because it's always hard to compare things move so fast. But I would definitely give it a try because especially for demos where you don't have, like, I don't know, a huge 30,000, or 300,000 lines of codes, thing.

Speaker 2:

No. They're just, like, simple websites, like a blog start Yeah. Or stuff like that, you know? It's a that just show features of a CMS.

Speaker 1:

I think that that would that would be a good start. And even if you said, okay, let's let's use this, compile it to, let's say, a view or Nuxt code or whatever, and then refine it, it can still maybe, it's pretty popular, man. Yeah. It is.

Speaker 2:

So that that's some stuff I'm pondering that's not super few first, but who cares? It's in the end we're just building websites. Right?

Speaker 1:

Exactly. And I mean, there's there's so many people saying let's do our web component library. Maybe, let's say, in universal language is the future that compiles to the rest.

Speaker 2:

Oh, we just build it in Vue and compile it to that. We're good.

Speaker 1:

You can yeah. You can exactly. You can just build in Vue, compile the web components. You're good.

Speaker 2:

Exactly. Yeah.

Speaker 1:

Alright. Then last last question is, Tim, where can people follow you if they want to hear more, if they want to see your videos, if they want to, see your content? Where is it?

Speaker 2:

Yes. So I used to be doing everything basically just on Twitter, which or x. I'm sorry. It's at Tim Bennetts, which is my name. However, recently, like a few of my peers, I have noticed that LinkedIn has been growing quite a bit for for me as, an outlet.

Speaker 2:

Because, of course, I'm in a start up. We're in b to b marketing and all that. So it's a little bit more that direction. So also on LinkedIn, it's just my full name, and I do a lot there. So lots of my little videos like this doorbell def rails is like that grew out of everything is so polished and awesome all the time, and marketers make content for other marketers almost.

Speaker 2:

It's almost kind of like SEO and then look at what they did and what they did, but nobody learned from it.

Speaker 1:

Yeah. I see.

Speaker 2:

So I felt like I'll just walk up to my doorbell, talk to it, and then whatever comes out of that, I just straight post it.

Speaker 1:

So really raw, let's say.

Speaker 2:

Just yeah. No edits. If I say something wrong and I look at my phone because I get a message, that's what I will be doing. If my dog runs around, you'll see me changing it. And so, those are I put them on TikTok, actually.

Speaker 2:

I might be a bit old for that, and I don't have any followers there, but that's felt like a good place. But I also just upload them to LinkedIn most of the time. And so if you want do want to find, like, more fancy, videos of mine, you can just go to, again, my full name, Tim Bennix, on YouTube. But also, you can go to the High Graph, YouTube channel where I have lots of videos. And day every week, we do a livestream.

Speaker 2:

So that one is also pretty full.

Speaker 1:

Lovely.

Speaker 2:

I guess that's that's it. And you can just go to timbennix.dev if you wanna see everything combined.

Speaker 1:

Awesome. Of course, all the links also in the show notes so you didn't have to get out a pen and paper and write it down. We have it all for you there. And, yeah. Then once again, Tim, thank you so much for coming.

Speaker 1:

It was a lovely conversation about Vue, about how you got your career started and big projects in Vue. Js with their merits, pros, and cons. So Exactly. I I hope to see you, also real life soon again, of course, but also Yes. During the podcast or in any other format.

Speaker 1:

We'll see. Right. And, yeah, thanks to everybody. Thanks for listening. Tune in to the older episode.

Speaker 1:

If this was the first episode, of course, go all the way back. Super interesting stuff. You already mentioned episode 1 for the need of SSR, the VGS episode from last week, and so on and so on. So definitely, have a look into that. Thanks for listening, and talk to you soon, folks.

Speaker 1:

Bye bye.

Speaker 2:

Cheers.