DejaVue

To start the year light and fun, Michael and Alex are joined by Rijk van Zanten, the creator of Directus.

Of course we talk about his journey into web development, the Vue.js ecosystem, what Directus is and why he chose Vue over other frameworks for it's extensible frontend.

Further, Rijk shares his thoughts on the Vue.js job market and how his "Quadruple Migration", over to the Composition API, Pinia, Vue 3 and Vite, went. As a cherry on top - this all started *very* early in the development cycle of Vue 3!

But the fun doesn't and there because Rijk comes with the one or the other hot take on topics like TypeScript and whether our libraries will be worse for JavaScript developers, testing, and many many other scenarios.

Enjoy the Episode!

Our Guest

Rijk van Zanten

Chapters

  • (00:00) - Welcome to DejaVue
  • (00:47) - How did you got into Web Development and Vue?
  • (03:10) - Does Vue appeal to a certain kind of people?
  • (05:35) - The web as the primary platform
  • (07:47) - What is Directus?
  • (10:34) - Why Vue.js and not React for Directus?
  • (18:28) - Jobs for Vue vs. React Developers
  • (26:33) - Green Flags for Hiring Candidates
  • (27:19) - Composition API and Pinia from 0.0.1
  • (39:02) - Breaking changes and Migrating from early versions
  • (44:28) - Testing when Prototyping - Unit and E2E
  • (53:11) - The right level of Testing for the project
  • (55:56) - Mutation Testing
  • (59:09) - Does TypeScript makes us writing worse JS libraries?
  • (01:09:09) - Dealing with Legacy and EOL
  • (01:18:38) - Where can people Follow you?
  • (01:19:42) - Wrapping up

Links and Resources




Your Hosts

Alexander Lichter


Michael Thiessen


---

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

Creators & Guests

Host
Alexander Lichter
Web Engineering Consultant • Founder • Nuxt team • Speaker
Host
Michael Thiessen
Full-time Vue educator
Editor
Niki Brandner
Sound Engineer
Guest
Rijk van Zanten
CTO and Co-Founder of Directus

What is DejaVue?

Welcome to DejaVue, the Vue podcast you didn't know you needed until now! Join Michael Thiessen and Alexander Lichter on a thrilling journey through the world of Vue and Nuxt.

Get ready for weekly episodes packed with insights, updates, and deep dives into everything Vue-related. From component libraries to best practices, and beyond, they've got you covered.

Michael Thiessen:

Welcome to DejaVue.

Alexander Lichter:

It's your favorite Vue podcast. You just don't know it yet. Or maybe you do. I mean, well, we have quite some episodes, on on the list here, and it's another one with, my lovely host, Michael, here. Michael, how are you doing?

Michael Thiessen:

I'm doing great. How are you, Alex?

Alexander Lichter:

Fine. Can't complain. Of course, we are not alone again, for our lovely episode here. We have a special guest. He is the founder and CTO of Directus.

Alexander Lichter:

It's Rijk van Zanten. Rijk, how are you doing?

Rijk van Zanten:

Hello. Doing fine. Thank you.

Alexander Lichter:

Glad to hear that. So, yeah, you join us, and we'll talk about a lot of things from, migrations from YouTube to view 3, which is an an interesting topic, especially when it comes to huge copays that used by, well, thousands of thousands of people out there, what you learned in there, what directed this a little bit.

Alexander Lichter:

But first of all, maybe tell us, how did you get into web development and Vue.js after all?

Rijk van Zanten:

Yeah. Great question. I mean, I got my start, funnily enough, as a user experience designer, So I really didn't even do any coding for the longest time. So I was in college. I did user experience design, and I got into front end development a little bit, mostly out of necessity.

Rijk van Zanten:

Right? But it's like I wanted to build my own designs and and execute and then maybe be able to make it testable and all that kind of thing. So I got into front end development, sort of halfway through college at that point and realized that it was sort of weirdly easy and fun and that nobody else thought the same thing in that college. So that was kinda funny. It was like, alright.

Rijk van Zanten:

Maybe maybe there's something here. So I kept doing it more and more, and then I got into it. And eventually found myself in this sort of, you know, designer developer type role over time. So I worked at agencies for a little bit as this sort of dual, you know, know enough about design to just be able to take an idea and just execute it immediately, but also know enough about development to just be able to do this stuff.

Rijk van Zanten:

Yeah and then did that more and more and more. And at a certain point, this was this was still in the the sort of jQuery, WordPress days. Right? And then at a certain point, reactive frameworks became a thing.

Rijk van Zanten:

And then it was sort of, like, right there trying to figure out, okay. You know, we've been building apps with with, what was it, knockout JS or or Backbone and and tools like that. Oh, yeah. Oh, yeah. For for a little bit trying to make it work, but it was always just a bit, you know, fighting at tools and feeling like you're you're just misusing the platform at that point.

Rijk van Zanten:

So when the first reactive frameworks came out with React, of course, being one of the the early ones then, that that kinda got some traction. It was kinda tricky to use. And and because I came in from sort of a designer perspective first and then doing web development, that was very much like an HTML CSS cat. Right? That that didn't do a lot of JavaScript development because that was always just the extra on top of it.

Rijk van Zanten:

Like, you would build the whole thing with HTML CSS, just sprinkle on tiny little bit of JS to make it interactive, and then that's it. So trying to flip that upside down with something like React never quite fit. It never quite worked for me. So, yeah, when Vue came around, especially with the Vue single file components, that was kind of the moment that it was like, oh, this is home turf. Right?

Rijk van Zanten:

This this is familiar. This is now now we're dealing with HTML and CSS like I know and love. Sprinkling a little bit of JS for the, for the interactive bits. This is great. Love it. That's interesting. You, you mentioned that because I've, I've thought before that react seems to appeal more to like the computer science-y people who are like, you know, they're gonna learn Haskell and, like, go hard on, like, type systems and, like, crazy stuff, and they like to talk about monads and and all of that. Whereas, Vue seems to appeal more to people who are, like, just wanna get stuff done or who haven't had that that same, like, computer science, like, like, super technical background. I don't know if that's true, but that's Yeah. I don't know. That's the impression that I got.

Rijk van Zanten:

I think there is something there, honestly. And you you see the same I mean, industry wide, you see, you know, the your traditional web developers turn more full stack and more back enders turn more full stack. So it's like how where do you find each other in the middle? But yeah. No.

Rijk van Zanten:

I I I've seen that same thing happen, on my end as well. Yeah.

Alexander Lichter:

And I think also with with a lot of people coming from actually the other side, not from a UX perspective or, like, you you your UI/UX perspective, but from the back end also there that just mentioned, like, okay. Getting a bit more into the front end part, not only okay. Here's a model. Let's make that, open up, but then, yeah, more and more things are coming to the front end or came through the front last years. And, also someone who came from Laravel from the PHP universe years ago, it was so interesting that then there are people reached out for Vue that were not, like, I don't know, front end developers by profession at all, but they wanted to get things done.

Alexander Lichter:

And having a solution for progressive enhancement in the 1st place, which is where Vue came from, while other frameworks like React or Angular, they kind of forced you well, React, you could also use it with a script tag, but no JSX, so that's a no. Mhmm. And Angular, really. So the only way besides jQuery, which was a bit meh, was Vue, so to say. Right?

Rijk van Zanten:

Yeah. I mean, like, hey.

Rijk van Zanten:

You gotta you know, it's it's funny that people started hating on jQuery over time, but I've I've completely one eighty that I'm like, credit where credit is due, man.

Alexander Lichter:

Oh, I don't

Rijk van Zanten:

It's It was jQuery is It was before, and then it was really good when it came out.

Alexander Lichter:

Yes. And it's so important that the jQuery actually was there. I mean, in the times where browsers implemented things differently, like, the hell no. You know?

Alexander Lichter:

Like, it was great, but, of course, nowadays, like Times change. jQuery

Rijk van Zanten:

Times change.

Alexander Lichter:

Yeah. Yeah.

Rijk van Zanten:

Exactly. For sure. For sure.

Alexander Lichter:

Yeah.

Rijk van Zanten:

And now that the web, you know, the web and the browser became I mean, I almost wanna go as far as to say it's now the primary application model. Right? So it's like, if if a new startup comes along, including us, you're not building, you know, a a Windows app and a macOS Swift app. First and foremost. You start with, you know, a web app, you make it a progressive web app, and then maybe, you know, you you fly it into a an Electron or Atari or something to turn it into a native wrapper.

Rijk van Zanten:

And even on iOS, like, the you don't see a lot of native apps anymore. So it's like the the the primary application model now became web development, which is interesting. That's that's that's wild if you think about it from just 10 years ago.

Alexander Lichter:

Yeah. It's it's it's interesting also how to shape from I don't know. So many people use Java. It's like, oh, Java runs all the devices, and we have all these Java applications. Well, of course, now spinning up everything, even without knowing necessarily back end skills with all the services available, with all the, the headless CMSs out there, for example.

Alexander Lichter:

Yeah. It's it's pretty easy to get started without knowing all these, like, skills super deep, which you needed before. It's like, okay. I built my application, and not even getting started saying, like, yeah. You just use something like bold.new or or VC or whatever.

Alexander Lichter:

Just like, here here AI, go for it. But even without that, it's it's

Rijk van Zanten:

Yeah.

Alexander Lichter:

It got significantly easier.

Rijk van Zanten:

Which is that is that is that a bit of a curse and a blessing? Is it

Alexander Lichter:

Just what I say. Yes. Yeah.

Rijk van Zanten:

Because it's, you know, from from where I am standing it's, of course, like, for the record, I couldn't have I couldn't have started Directus for what it was if it wasn't for that. Right? If the tooling wasn't available and I wasn't able to do enough JavaScript on the server side to get something going, like, it would have never existed. So it's definitely a blessing. But at the same time, you know, I've made mistakes on the server side that a back ender would look like and and just in the first second be like, well, don't do it like that.

Rijk van Zanten:

Right? Just because I'm coming from a CSS is my hometown. Let's try to make a server, I think, work, you know, early days. That is also a bit risky sometimes.

Alexander Lichter:

Right? 100%. And I think that's that's a really good point to touch on. So it's like, okay. You basically had a lot of skills learned from the UI UX perspective going to, like, programming, going to Vue.js in the front end.

Alexander Lichter:

So how did it happen that you eventually landed on Directus? And maybe for everybody not knowing Directus yet, what is Directus?

Rijk van Zanten:

What is it in the first way? Yeah. Very good. So Directus is a source available project. It is it started way back in the day as a headless CMS, 1st and foremost.

Rijk van Zanten:

So we were doing, you know, a lot of agency work. And for that agency work, I had more and more sort of custom projects, let's call it. So instead of your standard website, it became around, you know, museum inventory management or collection management or it became, what's another weird example? Like, a muse like, the museum is this is what I mentioned, the collection management or you have, more retail management or we had, like, a job site management at some point.

Rijk van Zanten:

So you got all

Rijk van Zanten:

of these weird management or we had, like, a job site management at some point. So you got all of these weird flavors of data management. Right? So at the time, this is, what, 2014, 15, 16, that window. There wasn't a new

Alexander Lichter:

Like 10 years ago-ish.

Rijk van Zanten:

Oh, god.

Alexander Lichter:

Sorry. It should make me feel older than everybody else. Yep. 10 years ago.

Rijk van Zanten:

Yeah. You're right.

Rijk van Zanten:

I'm telling you that 2015 is 10 years ago. Hoo, boy. So around this time, you didn't you didn't really have a lot of options to make stuff like that work. And as as a developer at the time, I was like, okay. I just need a database with this stuff in it.

Rijk van Zanten:

But then at the same time, I need to hand over something to the person in charge of managing the collections to be able to manage that database. And you're not gonna give somebody, you know, a PHPMyAdmin credentials or something and then, you know, wish for the best. So that's kind of where, you know, the the director's idea started to to brew and become a thing. It's It's it's a it's a funny backstory. I I I started noodling on something that later became sort of the current director scope base by myself.

Rijk van Zanten:

First, I was, you know, searching online, doing some research, and I came across a thing that Ben, my cofounder, open sourced right around the same time that was, like, vision wise very similar. Like, I had a very similar idea around, okay, it's basically just a user friendly layer to a database, but then you have a set of APIs so developers can also still use that in the same safe way. So you get the flexibility of a database without the sort of complexity that is usually associated with that. So, yeah, we we met up and and we started partnering up and and then started working on it together. So it was really a very typical sort of open source, 2 different force come together type of moment in that sense.

Rijk van Zanten:

2 different branches.

Alexander Lichter:

Sweet. Open source wins again. Yay. Yeah. Well yeah.

Rijk van Zanten:

It it's it's I think we can do a whole different session around, you know, how do you grow a project sustainably in open source, but let's let's let's save that for a different day. So, yeah, building that, it it it really started as a scratch your own itch type of thing. So when we started working on it more in-depth and and more seriously when when more people started using it, it was the question of of, like, okay. What is the right tool stack for this? Right?

Rijk van Zanten:

So the very first iteration that Ben opensource, I think it was Knockout JS together with, like, PHP with slim or something on the back end. If I remember, this is a long time ago. I was working in Node.js because it was JavaScript, and I was a front end developer. It was the only thing I could do.

Rijk van Zanten:

So there was a moment in time. It was like, alright. We we know we need to do a sort of major upgrade because the system right now has a sense of it old. The vision is really good. Let's figure out where do we go from here for the current sort of iteration.

Rijk van Zanten:

And we know, like, it is a fairly stateful complicated app. There's just a lot of moving bits and pieces, and you have a lot of sidebar and toggles and collapsible bits and, you know, buttons that execute little scripts and and all sorts of weird things. So I was like, what is the right tool for the job? And React was honestly sort of the obvious first choice at that point in time. It was the one that people sort of knew about, and they had the biggest sort of existing libraries and all that kind of stuff.

Rijk van Zanten:

Because this is, again, we're talking 2016 or so. This is really early days. Right? But one important requirement for me was, well, a, I wanna make sure that front end developers can do front end development efficiently. But also, b, because it's it was gonna be an open source project, and it still is, I I found it very important that it was easy to contribute to.

Rijk van Zanten:

And I think that was really the main the main reason for me to go with Vue. It was like I felt like that was the easiest to learn if you've never used it before. And I think that's still true even to this day because even even though React, you know, is still the powerhouse that it is, and it's it's one of those, you know, vicious cycles of, you know, companies ask for it, boot camps teach it, therefore, every new developer learns it first, therefore, companies hire it circle. But it's I think it's still true because in in a in a React code base because it's just at least at the start, I haven't used it in a minute, arguably. But as I said, at the start, it was very unopinionated, but it also meant that every single React code base is just totally different.

Rijk van Zanten:

Like, there's

Alexander Lichter:

I think that's some 2 big parts is still the case.

Rijk van Zanten:

Yeah. I think that's true. Yeah.

Alexander Lichter:

I was talking to a lot of people of, like, oh, yeah. Reviewing, especially applications and, like, yeah, with a framework. Yeah. Like, you know, if you use, I don't know, framework x y z, then you can look into 10 different applications so you feel at home. And then someone's like, yeah.

Alexander Lichter:

For for Vue, for Angular, for Svelte, sure. But for React, it's a bit different there.

Rijk van Zanten:

Right. So I I that has been the case since day 1. But it's it it is kinda funny because that means that whatever opinions that I put in place or whatever code style or rules or something, that is another new thing for people to learn on top of React itself. Whereas with Vue, single file components rather, you had a fairly well defined, this is what it is, and you do it this way and no other way, full stop. Right?

Rijk van Zanten:

For for better or worse, there's there's some parts, especially, you know, in the Vue 2 back in the the object days the object components, what would they call again?

Alexander Lichter:

Options API, I mean.

Rijk van Zanten:

Yeah. Yeah. Options API. That's the one. Exactly.

Rijk van Zanten:

There were some, you know, some rougher edges around that structure sometimes where it just got a bit like, oh, my compute is turned down here, but then the methods are up here. Now this all that comes again, which has since been solved, luckily. But at least that that structure did mean that for somebody coming in, you know, especially if you wanna contribute, oh, there's a little CSS glitch. You can just dive in and find it and just do it even though you've never used Vue before. And I think that was huge for for an open source project.

Michael Thiessen:

I think one of the the benefits or the the appeals of React is actually that it is unopinionated in that way.

Rijk van Zanten:

Sure.

Michael Thiessen:

And that you can look at, oh, there are 10 different state management libraries. I get to pick and choose exactly which one I wanna use. It can be fun for the developer in the short term, but then in the long term, it it can get, pretty tricky because no one knows what's going on, and you do some weird stuff.

Michael Thiessen:

I've done some really weird stuff with React, but, that's probably my own fault and not React's fault.

Alexander Lichter:

I mean, to some degree, if the API is not really, let's say, clear in terms of what you should do or shouldn't do, if there are many foot guns, then of course, in in a way it's like, yeah, a skill issue or like education whatsoever. But it's a bit like yeah. If it's a bit code and jokes are like as in if you have to explain it, not really not really that good.

Rijk van Zanten:

That's very good. Yeah. Code is a joke because if you have to explain, it's not very good. It it looks

Alexander Lichter:

In that way, it's, it's similar enough. Right? Yeah. Now I'm a bit fascinated that you that you said, okay. You chose Vue, so it's the easiest to contribute to, especially aiming at people who maybe never wrote line of, like, front end like, quote, modern framework front end code before.

Alexander Lichter:

It's just strange interesting because I talked, to a few people and, Omar McAdam, for example, created an inbox and moved it eventually from Nuxt to Next.js, and I hope we'll have in a podcast in the future talk about all that as well. In terms of, okay, we want to have more contributors for an open source project just because the React and the, the whole ecosystem is so big. So going the other way around of saying, okay, it's maybe not easier, let's say, but it's more it's more accessible to people because as you mentioned before, right, the whole, like, loop of, like, okay, boot camps. We we learn React.

Alexander Lichter:

This is the thing we know that's there. So do you think that's just because back then, it wasn't that, let's say, that major as it is right now, but still, like, a different time, or would you still do the same again if you have the choice now?

Rijk van Zanten:

I would yeah. I would do the same again. As a matter of fact, we are. Oh. Spoiler alert.

Rijk van Zanten:

No. Yeah. It's it I think it's it's still true. It's still very much true. I think Next.js brought a lot of those opinions into the mix.

Rijk van Zanten:

I do think that in more modern sort of React development, it sort of became Next. Js became sort of the standard, with Vercel's hosting model there as a sort of, you know, typical typical funnel. So I think that brought a lot of those opinions. We're fair and square in opinion territory, so get in the comments if you have other thoughts.

Rijk van Zanten:

But it's like, I think there's still a lot of sort of design choices from, you know, the 2015 era React that are starting to come back and just be annoying now that make it not the right choice for me. And that is kind of the state the the answer there. Whereas with the Vue 3, especially now with the composition API, the Vue bits of it feel very minimal. Because, like, the HTML is effectively just HTML with a couple attributes. The CSS Mhmm.

Rijk van Zanten:

Literally just CSS. Like, there's no you're not doing camel casing or anything else. There's no shenanigans going on unless you still went different podcasts for a different day. But it's still fairly it's just HTML. It's just CSS.

Rijk van Zanten:

And the JavaScript now, because you effectively just write it yourself, right, with the compositions, composables, make it so that it feels the least framework-y somehow even though it's still opinionated in its own right. Does that make sense?

Rijk van Zanten:

It's a bit of a ramble.

Alexander Lichter:

I would say it makes sense. I said it in a different podcast, actually, the contagious podcast with Tejas Kumar. I was, saying, yeah. I would even say Vue is more JavaScript more just JavaScript than React itself, and that

Rijk van Zanten:

Literally. Yeah.

Alexander Lichter:

It feels the same way, frankly. Yeah. So I I I totally agree with that sentiment to be like, it's more close to the standard. If you know HTML, CSS, and JavaScript, you can easily get into that even more now with the transition API.

Rijk van Zanten:

Yeah. And I think over time, you know, more and more frameworks are are are coming on the scene. You know, the joke is every week, but it might be more often than that. Who knows? But it also means that, you know, there's more and more folks that do end up coming out of a Svelte environment, 1st and foremost, that are trying to contribute, or they've used Angular at their work for a decade before they jumped in, or they've been Drupal developers for the last 30 years, and they're now trying to contribute something.

Rijk van Zanten:

So there's, like, a lot more entry points than just the sort of usual web framework bubbles of folks that are trying to contribute. So I think the ease of getting started there is still still true to this day. Yeah.

Michael Thiessen:

I've always wondered about the whole supply and demand aspect of this this thing too, because people often say, like, oh, should I learn React or should I learn Vue if I wanna get a job? Right. And people are like, well, there are way more React jobs, but it's also there are way more React developers applying for those jobs. So, like, at what point is, like, like, you also you you you can't just look at the supply of the jobs. You have to look at the demand for the jobs or, I don't know, flip that around.

Michael Thiessen:

But Mhmm. Yeah. Like, how does that how does that come into?

Rijk van Zanten:

I have a hot take for this one. Uh-oh. And we're gonna get in trouble with this. Person a blessing for from a company's perspective. Right?

Rijk van Zanten:

So, like, the the Directus project grew to a point, a bit of required backstory to see why this makes sense. It's project grew to a point where it turned into a full time job and a half. And then, of course, you have to start making money off it. So we did the typical upstart thing. We started, you know, putting some revenue models in place, and it's grown to an to a company over time.

Rijk van Zanten:

That also means that I had to sort of onboard new core maintainers over time to make sure because it went from one full time job to 20 full time jobs of of maintenance work and and, features and stuff. So how do you do that hiring in the first place? It's like a whole new challenge, that as a developer, you never think about. But then if you're thrown into the, oh, now you're in charge of finding another another developer seat, you learn so much from sort of the other side of what that looks like. And what I've noticed over time is, like, to answer that question the way I would answer it right now, it's like, it doesn't matter as long as you can learn either of them quick.

Rijk van Zanten:

Like, that's the important skill. It's not so much that you know React very well because it will change. Like, whatever you know today is irrelevant 2 years from now. That is just an evergreen truth. So it's like the ability to be, you know, excited about learning the new thing and not feeling bad that your sort of home turf gets ripped ripped from underneath.

Rijk van Zanten:

That's that's the real skill I feel like that is that is important, to learn.

Michael Thiessen:

I would definitely agree with that that it's like any, like, good developer should be able to learn eventually. Like, it takes time to learn a new framework, of course, but, like, you should be able to learn. Like, React and Vue are not that different, like, once you get get into it.

Rijk van Zanten:

I I think that is that is, funnily enough to me, the crucially important part there in the middle. Because, like, I'm right there with you. To me, it's like, okay. Once you know and internalize the concept of, like, a component model and reactive updates and some of sort of, like, the general store strategies around, you know, you have mutations and then that goes through a server somewhere. It's like, that is applicable to all of these frameworks.

Rijk van Zanten:

But there's a lot of folks that start deep within React, but they never sort of get to the theoretical level there. They just do the execution part, and then it's super difficult to switch. Because now you're like, where's useEffect? Yeah. It doesn't exist.

Rijk van Zanten:

It's gone. But if you're like, oh, but you can just do a computed and just do this and this, and then it's the same underlying, you know, reactivity model, then it becomes easy again. So it's like it it I think that's the perfect example of the whole, you know, be able to learn it.

Alexander Lichter:

Yeah. Like, the concepts. I mean, finally, as someone who went to university and did a did a CS degree there, and Michael as well, a lot of lot of times people said, like, yeah. It's nice to learn tech, but understand the concepts, and I think there as well. It's also something that Evan, for example, said about, like, yeah, you're of course, you can say you're, a React developer or Vue developer, Angular, a Svelte developer.

Alexander Lichter:

At the end, we're all front end developers. And if you wanna find a job, then, well, you can if you know one of these frameworks and are able to, like, map the concepts to another one, it's like, okay. It's more about onboarding. It's more about getting to learn a framework, especially how the company uses the framework. That's a whole another discussion again.

Rijk van Zanten:

Right. And Right. Yeah. So, yeah, whole different thing. Yeah.

Alexander Lichter:

Yeah. So so then it's really more about like, okay. Hey. Look. Here, I have some some work done in framework x.

Alexander Lichter:

I can do it in framework y as well. I maybe took some time to showcase that I understand a few things if you want me to ask me some some questions around that. And, yeah, give me a bit time, and I'll be I'll be of use. And I'm excited to do that, and I think that's that's key. Yeah.

Rijk van Zanten:

I I know it's a lot more opinionated in the tech industry now, but if you compare the similar discussion in any other industry, it immediately sounds silly. Like, for ex I mean, you can clearly tell I'm I play a lot of music on the site. But it's like, if I go to audition for a band or

Rijk van Zanten:

a play or something, the first question that I'm asking myself is not, oh, what could what guitar am I bringing? Because that's not the make it or break it. Right? It's like I'm just a musician. I show up, and then I'll fit I'll make the tools fit the the goal, not the other way around.

Rijk van Zanten:

Right? It's not like I'm not searching for for gigs just based on the exact tooling that I bring along. It's the other way around. You find the tooling for the job.

Alexander Lichter:

Mhmm.

Alexander Lichter:

That's that's a good point. Also, for everybody listening, not checking a video, check now what is behind Rijk's back.

Rijk van Zanten:

Yeah.

Alexander Lichter:

You might have guessed it already.

Rijk van Zanten:

It's a guitar.

Alexander Lichter:

Exactly. Yeah.

Rijk van Zanten:

Notice the same. It it goes for every other industry. Right? It's like you're not gonna go to a construction site and hire somebody or not hire somebody because they use, I don't know, one brand of drill over another. That that matters not at all.

Rijk van Zanten:

Right?

Rijk van Zanten:

So you're not a DeWalt guy?

Rijk van Zanten:

It makes no sense. It's like you you just you know how to do the job with the tools that are available to you, but it doesn't matter what tool it is. I think that's very important.

Rijk van Zanten:

And that that yeah. It's a long winded way of saying, don't matter what framework you start with as long as you just Mhmm. You know, are able to pick one up at a moment's notice.

Michael Thiessen:

I feel like this is a good opportunity for me to plug, 2 of my courses, which are actually about patterns and, like, the conceptual things that actually transfer to other things quite easily more than, like, oh, this is how you do slots in in Vue.

Michael Thiessen:

So the one that I've had out for a while now is about component patterns, so dealing with components and single file components and all that kind of stuff, clean components toolkit. And I don't know when this podcast is coming out, but I will be either launching soon or have launched one on composables. So we were talking before. It's kind of just like writing JavaScript, but there are also some other, like, interesting things and patterns that you can do to sort of wrap your head around that better.

Michael Thiessen:

So just gonna slip that in there.

Rijk van Zanten:

Where where can where can we find this? Yeah. I was gonna say

Alexander Lichter:

Links all the description on the show notes as usual. Otherwise, on Michael's website. Very good. Right?

Michael Thiessen:

There you go. Yeah.

Alexander Lichter:

It's like hold a big banner straight away when you're on the show notes. Yeah. Like, a non click away pop up like, hey. Oh, boy. No.

Alexander Lichter:

No. Of course.

Michael Thiessen:

When you try and close a tab, it'll say, wait. Don't

Alexander Lichter:

leave. For sure. I sure be

Michael Thiessen:

a picture of me crying and yeah.

Alexander Lichter:

And on on that note, I also wanna plug something. The the plot twist, it's, of neither of us, actually. It's from, Danny Roe who leads the Nuxt team and, is planning on making a course. Yeah. It's called, react to Nuxt, and it's available on reacttonuxt.com

Alexander Lichter:

Also link, down there somewhere. It's not there yet, but if you are very unlikely, but if you are a react developer listening to a podcast because you might be interested in Vue.js, could be. Right? Maybe not Send this

Michael Thiessen:

to all your friends who are who are React developers and and bring them over.

Alexander Lichter:

Exactly. Like, check that out. He's he's working on a course. He's like yeah. It would be pretty amazing.

Alexander Lichter:

And otherwise, last thing, I also I I did it. I migrated a little Next. Js application over to Next. Js in, like, an hour. It's really not that big, but just concept wise could be also interesting.

Alexander Lichter:

So, yeah, react, to to any other better framework, advertising block over here.

Alexander Lichter:

But coming from that and also from the the job search topic, which I think it's it's always really good to focus as we all sat on on the concepts and on the skills actually and also to show them. I would be just so, like, happy to hire people that are just interested in the things. Right? That they show, like, like, they they show actual passion and, like, always the green flag is like, hey.

Alexander Lichter:

People going to meetups. They're like, oh, yeah. I on my free time, I if there's a meeting in the city, of course, right, or online, I'll I'll go to these. I'll listen. And that's always like, people going to meetups, you usually wanna hire them because they're a lot of the developers actually care about it.

Alexander Lichter:

And for me, it's always a, yeah, a a good a good sign, so to say.

Rijk van Zanten:

I think it is a it's a super frustrating job if you're not sort of interested in it. Right? It's like I I don't think programming is one of those jobs you can do if you're not intrinsically just interested or curious about tech, like, in in sort of that that realm. It's just too frustrating otherwise. Like, we've all banked our head against the wall for hours on end trying to solve a problem.

Rijk van Zanten:

But, you know, if if that doesn't excite you, then it's gonna be a tough one. Yeah.

Alexander Lichter:

I guess it's it's even tougher if you come into, like, a a legacy code base and you have to migrate things all over with with the framework. And it's especially it happens, to to your code base, not only to yours.

Rijk van Zanten:

Very good segue. Yeah. Yeah.

Alexander Lichter:

Thanks. Thanks. To many others out there. But yeah. So so the Directus thing that you you migrated, but, so I said, like, yeah, Vue 2 to Vue 3, like, the obvious things, but it's kind of a quadruple migration.

Alexander Lichter:

It has

Rijk van Zanten:

been fascinating time. So at the time, mind you, front end developer, first time really doing big app or sort of complicated app, bit of both, first time Vue. So the first iteration of the app, this is very early days of the open source project. Right? It was trial and error.

Rijk van Zanten:

Bit rough around the edges, proof of concept, really.

Rijk van Zanten:

So a lot of things worked really well. A couple of things really did not at all, like on a foundational level, happens, right? 1st iteration happens.

Rijk van Zanten:

So it was right around that time that it was like, okay, we were also moving the API from the the PHP stack of of olden days to a Node.js based system, and it was right around the time that the very first ideas around the composition API came out.

Rijk van Zanten:

This was before the sort of compatibility package layer, opt in proof concept. It was before any of it. It was just the first, you know, couple of tweets and blog posts with screenshots of, like, is this anything? That I was like, yes. Yes.

Rijk van Zanten:

Yes. That is the thing. Give me give me to it now. So it was just a very interesting turn of events that the timelines like, the stars aligned for all of it. Right?

Rijk van Zanten:

So the the composition API, Evan was was working on that as that that Vue 2 package, for people to opt in and leave feedback. You had, you know, Eduardo working on on what later became Pinia and sort of the replacement for Vuex at a fairly similar time once the composition API package shipped. You had, with the composition API, way more opportunity to use TypeScript effectively. So that was very interesting around the similar time. You had the Vue CLI that was sort of being replaced or phased out by Vite around the same time.

Michael Thiessen:

Mhmm.

Rijk van Zanten:

So it was just a funny moment that it was like, oh, here I find myself at a point that I'm like, okay. I need to make some big foundational upgrades to our Vue app to just get rid of some of the the sort of mistakes made in the early days, to make this something that we can run with for years rather than months. And you have all of these interesting improvements happening at the exact same time in in sort of that Vue ecosystem, and it was just too good to pass. So I took a tremendous risk at the time and just be like, npm install Pinia 0.0.1.

Rijk van Zanten:

Here we go. It with the intent for, you know, this is gonna be a big production app that is used all over the place, but it was sort of that. And it was just because I I I believe in in the APIs of it that much that I was looking at the composition API in those very early days, and I was like, this is such a tremendous improvement over the component API that happy to or the options API. I keep forgetting.

Alexander Lichter:

Yes.

Rijk van Zanten:

I don't know why.

Alexander Lichter:

I haven't used this for so long, unfortunately.

Rijk van Zanten:

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

Alexander Lichter:

Yeah

Rijk van Zanten:

name all of a sudden.

Alexander Lichter:

Fair. Fair.

Rijk van Zanten:

I guess they they call it the object API just because it anyways, don't matter.

Alexander Lichter:

It's a big object.

Rijk van Zanten:

It's just a big object.

Alexander Lichter:

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

Rijk van Zanten:

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

Rijk van Zanten:

That, you know, makes sense conceptually, but at the same time, once you have bigger components or just more complicated workflows or, god forbid, you wanna share, methods between components, that gets tricky pretty quick. And we noticed the same with some type safety things as well because of you know, to access all the data, you go this dot data, blah blah blah. It also meant that sort of getting TypeScript to work well into that mix in those days was basically you could kinda with a with some pain and suffering, but it really wasn't worth it wasn't worth the effort yet. Right? So the composition API sort of removed a lot of those pain points because now I could group my files by, okay, here's everything that has to do with sort of this, this responsibility and just get all the refs and all the computeds and all of the methods just in the same vibe, in the same part of the, the file.

Rijk van Zanten:

And it also helps that it became a little bit less opinionated again, funnily enough, or in the sense that it's it's I am catching myself in the funny irony that I said earlier that it was more opinionated. That's a good thing. But it it does it did mean that you didn't have to go searching through like a this dot chain to find some data because you had a variable that you defined yourself, and that's the thing that you're talking to. So I think from a mental model, that that sort of simplified things a little bit.

Alexander Lichter:

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

Rijk van Zanten:

It It became a bit more JavaScript to this. Yeah. Yeah. Oh, exactly. Exactly.

Rijk van Zanten:

And that that just took it one step closer to the sort of, oh, it is just HTML JavaScript and CSS with a bunch of utility functions that you can use to make it even better. Like, that's that's kind of the feeling that it that it raised, which was just, yeah, I felt like right at home. And I had to say with Pinia. Like, Vuex was really good for what it did. But at the same time, the model of, like, you're defining an action and that then runs a mutation that goes into a store and then that sort of updates somewhere and then you pull the data out.

Rijk van Zanten:

And it's like the mental model of that and I had to say it was Redux in in the React land way back in the day, which had a similar mental model. It was always just a bit tricky because I'm like, it's just JavaScript. Just let me update a variable. What what are we? What what are we doing here?

Rijk van Zanten:

So when, you know, the very, very earliest thoughts about Pinia came out, that it was like, oh, this is literally just a ref, like, I would use in my own components but in a separate file. Well done. There we go. High fives all around. High fives all around.

Rijk van Zanten:

This is all I need.

Michael Thiessen:

Yeah.

Rijk van Zanten:

This is all I want. So I had a similar thing that I'm like, yeah. Because, you know, in in a platform like Directus, we have, I don't know, 15, 16 different stores with interlinked dependencies and, like, some very specific hydration points where some of these stores need to be loaded in a certain order and all that kind of stuff. I was like, okay. I need to make a choice now.

Rijk van Zanten:

I either set up that complicated system in Vuex again, and then don't change it for 5 years, or I'm gonna get take a gamble, use Pinia, and roll with the punches and the breaking changes as they come. Because this is 1. I know there will be breaking changes and loads up. Just because I know that the sort of 5 year plan is gonna be way better because of it. And that was the risk that we took, and it's paid out, luckily.

Rijk van Zanten:

Yeah. Paid out luckily. It was, it was a gamble. I'll I'll I'll be the first to admit. It's like, that is a risky move, that Mhmm.

Rijk van Zanten:

You, you gotta know what you're getting yourself into, but it paid out. It paid out big time. And I'm very glad we did it.

Alexander Lichter:

And just to mention that back then when Pinia was released, it was not clear that it would replace Vuex at some point. It was an experiment. It was communicated as, hey.

Rijk van Zanten:

I'm the author of Vuex. I have a new idea. Let's see if this is anything. It's just a little thing on the side. And then I was like, this is the thing.

Alexander Lichter:

To remark, like, Eduardo didn't even write Vuex. Right? Like, this was just like Right. Right. Right.

Alexander Lichter:

He did he did router. Right? It was like, maybe

Rijk van Zanten:

Oh, yes. Oh, yes.

Alexander Lichter:

Maybe could be a bit easier. Mhmm. Mhmm. So that's that's that's, I think, even, even more of an achievement. Like, hey.

Alexander Lichter:

This. Right? Yeah. I wasn't even I wasn't even involved in Vuex. Of course, he he used it, obviously, and was aware of internals and stuff, but still yeah.

Alexander Lichter:

And, here we are with, Shiny, the one way to go state management tool called Pinia. Right.

Rijk van Zanten:

Right. And even even to to go back to the whole, it's it's just JavaScript y part. It also feels like a state management tool you can just use for for anything else. Right? That's also kinda nice.

Rijk van Zanten:

It is it's, of course, made for Vue first and foremost, but at the same time, it feels like the mental model of it and just the way that reactivity works under the hood, it doesn't feel coupled to Vue at all. Like, which is which is just very neat. Big fan of that. Yeah. And then around the same time, because you're now in this composition API, this was still Vue 2 with that sort of opt in, let's try it out before it becomes a thing library.

Rijk van Zanten:

Because Vue 3 was again I I think there was some rumblings and rumors, but I I I'm a little hazy on the timeline details. It's been so long ago now. But it's like, I wanna say the composition API came out as an idea first, and then Vue 3 rumbling started around, oh, there's some big improvements under the hood. And then the composition API became that package, and it became more and more defined. And then sort of Vue 3 came out with it baked in from the start.

Rijk van Zanten:

I wanna say that's sort of

Alexander Lichter:

That's that's almost almost right there. I think, like, composition API, of course, was drafted before, but also in anticipation of Vue 3. Right. Yeah. So and then the thoughts were, can we even back port that to Vue 2?

Alexander Lichter:

That was, like, ideally, yes, and that's why the the package, the Vue 2 package would came out later because it took a while. Eventually, it was, like, then integrated in Vue 2.7 even without the package. So you can use the composition API with without that, which is is great. And

Rijk van Zanten:

I just remember that composition API being available in Vue 2 through that sort of opt in additional library

Alexander Lichter:

Yes. As was before. Before 2.7. Yes.

Rijk van Zanten:

Before Vue 3 was even even available to to beat that test at that point, I wanna say. So but but we had the same thing. I was like, well, I wanna switch to Vue 3 the second it comes out, but I do wanna wait for that one to be sort of a stable production release before it comes out. But the composition API felt like, okay, this is both a huge deal, but also small enough in scope where I was like, okay, I feel like I can roll with the punches for the breaking changes that come with this. So we just ran with it immediately, just this with Pinia.

Rijk van Zanten:

And it it worked out. It worked out, luckily. But it worked out. Luckily. Yeah.

Rijk van Zanten:

It it is it there's a lesson in there around, you know, who do you trust with that and and what libraries am I willing to take that risk with? And I think it has a lot to do, you know, credit what credits do, which is the author behind the hood. Like, I would never do such a zero zero one thing with most every other library. Right? This is just coming from I've I've used Vue router a long, long time before.

Rijk van Zanten:

I sort of trust the development model and trust, you know, the source. And the same with Vue, obviously, that I'm willing to take a risk like that. But if it was any other library, I would think twice. Like, this is not I do not do not take this as a tip. Build your stuff in in 0 point libraries.

Rijk van Zanten:

Don't do it. Don't do it. That's the lesson learned. But sometimes it works. Sometimes it works.

Michael Thiessen:

But if Eduardo makes it, then Then then it's okay.

Rijk van Zanten:

Then maybe

Alexander Lichter:

Eduardo Evan, all good. Otherwise, tweet with care, so to say.

Rijk van Zanten:

I'm sure they'll be thrilled to hear that. They're they're shaking, like, yelling at their screens right now. Yeah. No. It's it's funny how that works.

Rijk van Zanten:

But it is it is true. It is true that that that raises a lot of trust. Now, of course, I I don't wanna make it sound like it it was all it was all roses and sunshine because it really wasn't. There's a lot of sort of pain points that we we saw a lot of things coming by taking the risk. Like, of course, you're gonna have breaking changes.

Rijk van Zanten:

Like, Pinia straight up does not exist. It's an inkling of an idea. It's the concept of a plan. And then, you know, how does that grow over time? Nobody knows yet because nobody really knows if it even takes off in the first place.

Rijk van Zanten:

So, of course, you have to be prepared for breaking changes in there. The parts that I I sort of you know, in hindsight is very obvious but didn't see coming at the time was things like because nobody's ever done it before, how do you write unit tests for a Pinia store? Like, that was just a question that was not answered yet. There was just no way. Because at that time, with the composition API plugin, I think you had to, again, this is just so long ago.

Rijk van Zanten:

I might be wrong here, but there was something around you had to, mount it inside of a component for the composition part to kick in and therefore for your Pinia stores to kick in. But that in turn also meant that for unit tests, now you have a bit of an interesting problem because your opinion source is a separate file, but you cannot just test it in isolation. So what do? Right? So at the time, I I did a bunch of experiments, set up like a little mini sort of test component that would just import the store to to run it and then run the unit tests within the sort of setup of of a view component.

Rijk van Zanten:

It was a bit and it works, and it was great. It's like, this is fantastic. It just works fantastic. Get that for all of the stores, all of the tests, all the units. It's great.

Rijk van Zanten:

That's the point where it was like, oh, that shouldn't have done that. Shouldn't have done that. Because then, of course, breaking change of Vue 2 to Vue 3, now that part is both irrelevant and works totally different under the hood. All those are now just officially pointless. Because the way I have to write the test is that it was poking at the Vue component to see the output of Pinia rather than just the Pinia store itself.

Rijk van Zanten:

Right? Yes. So that was the part that I really was like, oh, that that is a that is a part that I didn't account for with all the breaking changes in these libraries. Second big one there was storybook. Like, I I use that heavily to just have my my component library and just debug it and click around, test it, and build it because I'm just a very visual builder.

Rijk van Zanten:

I like seeing the stuff that I'm writing live. Right? Same thing. Vue 3 files, didn't exist. Right?

Rijk van Zanten:

This is not a thing. Composition API kinda sorta worked because it was still in Vue 2, so that sort of compatibility kinda worked. But then there's an update to Storybook, no longer works. There's an update to Vue, no longer works. Storybook, at one point, had an exper similar timeline, had an experimental I wanna say it was like a markdown mode.

Rijk van Zanten:

It's like you wrote a markdown file with all your docs and then you inline some components. I was like, this is sick. Like, that is really the way that I like thinking about this stuff. Use that with Vue 3, same thing. It all worked until it super didn't.

Rijk van Zanten:

Yep. Because we, we made it work. I made it work on the sort of, okay, you have a 0.1 talking to a 0.5.1 to a 0.3 and everything works and life is fantastic for the 3 weeks that it worked.

Alexander Lichter:

Yeah. One version bumped later, one patch even, it's over. Yes.

Rijk van Zanten:

That that was that was just one of those things that I'm like, again, I I don't regret it. It's it's just one of those things that you're like, oh, of course, you don't think about storybook maintenance over time if you're thinking about updating your component model. Right? It's just one of those things. Of course, in hindsight, you say, yeah.

Rijk van Zanten:

No shit. It's all connected. But in the moment, those are the devices you don't think about.

Alexander Lichter:

Yeah. No. Though it's it's interesting in a way because, for example, for the test, it's it's really good that you at least then okay. You had tests or you had to update how you, like, set up the pinion store to be tested, but at least you could still say, I have all my cases. I just have to make it work again and apply it to all.

Alexander Lichter:

So, like, you don't start from 0 by, like, Tests, what what is this?

Rijk van Zanten:

The funny thing, though, and this is, again, this this is this is a a a product of this is a one person job and you just do improved concepts and moving quick. Once all of the tests broke, you'd never go to sit down and spend a week to just re fix them all. That just didn't happen. Because it was like, at at that point in time, you're working on this incredibly quick development cycle. It is still early days into, in the project where it's like, is this a thing rather than this is the thing to use.

Rijk van Zanten:

Right? So you're still in a very experimental mode. And at that point, if somebody tells you now all of the tests are gone, are you gonna go sit down and rewrite all of them? Because it wasn't so much a migration at that point, unfortunately. Because like, because of the whole Hecke system where it had to go into a component first and then inspect the the the component instead of the store output, it does mean that, yeah, the cases are kinda there, but you still have to rewrite them all to to fit, you know, the the different place to look for what you're expecting and all that kind of stuff.

Rijk van Zanten:

And it just never happened. Just straight up never happened again. Right? And then you over time, you include new ones, like, whenever you make a patch or a change. And it's like, okay.

Rijk van Zanten:

You you sort of add them back in over time. But that was, like, that I'm think of.

Rijk van Zanten:

So, like, I I think unit testing as a whole is just a whole different topic for a different podcast, of course. But I think that's one of those things that, lesson learned, you have to include it from day 1 in the way that you wanna maintain them for years to come because otherwise, you won't, and then you might as well not have them.

Alexander Lichter:

Interesting. Yeah. I think it's fair, especially as the development cycle is very rapid, and you're like, okay. Here here are new things coming in and be, okay. Our tests are broken now, and maybe some things don't need to be tested because they well, in in 2 weeks, not sure if they're there or tomorrow if if we have to change them again.

Alexander Lichter:

Right.

Rijk van Zanten:

I think that is that was the biggest part of it for for me, especially in those days. The earliest view at the first one, it's like, I don't know how any of this is supposed to work. I don't know what any of this is supposed to look like. We're designing in code, and we're implementing all of these features and things based on the feedback that is coming in in real time. So therefore, I to your point, it's like I can write a unit test that is like, this is how it works, Monday 16th, but it does not work like that on Thursday.

Rijk van Zanten:

Right? And and then it's like, okay. How much time do we invest if that is the development model? And again, that's for prototyping and proof of concepts. Right?

Rijk van Zanten:

For for production stuff, highly support doing tests. But it's it's a different point in time at that point.

Alexander Lichter:

Yeah. Also or, like, where do you spend your limited time on as well? Like, obviously, if if your prototype is just like, hey. We wanna get something up and running, see if it works. If it doesn't, let's squash it and, build a new thing or, like, build differently.

Alexander Lichter:

Sure. Totally understandable. Like, then better focus on making the the MVP or the the POC as good as possible.

Michael Thiessen:

I've seen some people recently who like, for for smaller teams and earlier projects, they just write in time tests, like with playwright, for example, because then you get like, they're not that hard to write, and you get pretty good coverage, and they're less likely to break because they're not, like, as as coupled to implementation, so you can still have that speed, but have a little bit of, like, okay. People can log in to our app, and you know that that's gonna work. And, like, you know, when you're starting out, that's, like, the main thing. You know?

Rijk van Zanten:

For sure.

Michael Thiessen:

You can buy the thing. People can log in. They can, you know, do the main thing the main action on the app and, like, okay, base is covered.

Rijk van Zanten:

Yeah. Because at that point, the only thing you really wanna know from your tests is does this still work? Yes or no? Like, that's what you wanna know. And everything else you could figure out from there and just keep moving quick.

Rijk van Zanten:

It's like once you get to the point, it's like, I wanna know the exact place where it broke and who broke it and what commit and all that kind of stuff. Now you're in the territory where it's like, okay, need to start thinking about tightly coupling it. But it's a very good point because I think a lot of devs sort of circle it all the way back to, you know, what do you learn first? I think unit tests are one of the sort of deceptively luring options that you have available because you have just a tool that says, well, you're 90% done. Yeah.

Rijk van Zanten:

Coverage. Yeah. You have coverage. And once Yeah. The tool says a 100%, you're like Easy.

Rijk van Zanten:

Done. But that also means that you end up writing tests for to your point, Michael, every tiny little permutation of every tiny function that in the bigger hole is that worth spending your time on, or are you just trying to chase a number? Depends. It depends on the team and the thing you're building and where it is and what's the risk and and how fast do you wanna move and all that. Yeah.

Michael Thiessen:

Mhmm. Or you're just chasing that high of the the green check marks. Yeah. The lighting

Alexander Lichter:

numbers go up. Check marks go green.

Michael Thiessen:

That is fun. Mhmm.

Alexander Lichter:

That's that's that's fair. No. I also think, like, unit test, especially, as you said, like like, this this is what you usually learn first because, like, okay, end to end is a bit more complicated. You also have to have something, not just like a function, but, like, something that's you can actually test. Like, oh, if I click on a button, it shows something.

Alexander Lichter:

I still think, especially for, like, some business logic stuff, it's always nice to have them around. Right? Even, I don't know, for some tiny helpers just to okay. You test them anyway. And if I start, like, hey.

Alexander Lichter:

I built like, boot my app up in a super complex environment, and now I add a function there, and, I just wanna test 3 cases or okay. I simply, like, okay. It's a it's a pure function. I did the input output, all good. It's I just boot up a test case, all fine, and it it doesn't hurt as long as there is a CI set up already and it will actually also run on every commit, which is another thing.

Rijk van Zanten:

Mhmm.

Alexander Lichter:

Right? And I I especially prefer it when it's, like, not, let's say, coupled to a framework. It's more like contextless and just, like, business logic because that's also where it's really helping. Like Mhmm. Yeah.

Alexander Lichter:

Sure. You can test your button component, but you also can just have an end to end test to make sure you can log in or sign up as Michael said as well

Rijk van Zanten:

It's just to your point.

Rijk van Zanten:

Like, the fact that you could click a button. Yeah.

Rijk van Zanten:

That's important. Because if your button doesn't click, everything goes to hell. But at the same time, that doesn't mean that somebody can log in. Those 2 are not the same. Right?

Rijk van Zanten:

It's like you need both to test both sides. But it's it's it's kinda funny because, like, end to end test has always been such a tricky thing. And and that this is just a a specific byproduct of the direct this project. It's like because we're trying to support so many different underlying databases, it means that in order to have an end to end that is proper end to end, it means that in our CI we do run it still, but we're we're about to just overhaul that because it doesn't scale anymore. It's like we spin up in the CI 7 different databases through containers and then 7 copies of Directus, one configured to each database, and then run the tests in parallel to each of those 7 copies of the app.

Rijk van Zanten:

Takes about 45 minutes. Like, it's it's Yeah. It it just doesn't. It it it stopped working the more databases we add because that just goes, you know, exponentially up in in minutes used on GitHub and and, you know, the maintainability of it all. Because I can't even run it locally anymore now on ARM because, like, one of the databases just straight up does not have a container that works.

Alexander Lichter:

Really? Oh, wow.

Rijk van Zanten:

So so what do you do then? Right? It's like, I if I cannot run Oracle DB on my local machine, where do we go from here?

Rijk van Zanten:

So now you have to trust the CI, but then if that takes 4 to 5 minutes, it it gets really quite fiddly.

Michael Thiessen:

Yeah.

Rijk van Zanten:

So we've reached the point now where it's like, okay, end to end, like, proper end to end is kind of no longer an option for for the project that we're building. It has to be integrations that are just a bit wide like, a little end to end d. But instead of hitting database, it just hits an abstraction of a database so we can check that it would have done the right thing. And then each database abstraction needs its own set of tests to make sure if that input is correct and it does the right thing, because otherwise it became untestable, to do full end to end in in that setup.

Michael Thiessen:

I think that's a key point about end to end tests is that they're always thought of as being, like, representative of, like, this is the actual thing. Like, this is fully real. We're not not doing any, like, shenanigans here, but, actually, I think most end to end tests, you are faking some parts. You are, like, mocking out whatever word you wanna use for that. Like, you just have to, like, decide where that that line is, what that boundary is.

Michael Thiessen:

And so, like, yeah, for, like, your case, it doesn't make sense to spin up 7 different databases. And so, you know, maybe you do have that run, but not as part of CI

Rijk van Zanten:

Right.

Michael Thiessen:

Or, you know, you have all these different decisions because you don't wanna, yeah, 45 minutes to wait to find out that your PR doesn't doesn't build is not

Rijk van Zanten:

It's not good.

Michael Thiessen:

It's not great. So

Alexander Lichter:

But it's all fine. Like, 45 minutes, like, oh, I knew.

Rijk van Zanten:

Yes. Right. Right. Right. Yeah.

Rijk van Zanten:

That's so so that that just, like, you know, that came out of a world where way back in the day, it was just one database type, and then it worked perfectly fine. Because now you had just MySQL and you spin up Directus and you have the full proper end to end. You can test the whole thing. It's amazing. And then it's like, alright, let's support more types of databases.

Rijk van Zanten:

And then over time, it's like, okay. We've reached that that point now of scaling where that you just have to be like, okay. Not that.

Alexander Lichter:

Not that. And, I also think, like, the the tricky part of end to end testing if we come back to, like, why people start off unit tests, for example, is like, okay, the whole setup part, like, yeah, you you have to have let's say you have a software as a service application. Okay. Cool. You need, like, seed data.

Alexander Lichter:

You need to keep them in sync and up to date. I I had it also in, like, multiple time projects. Like, okay. We wanna enter n test. Like, how do we start?

Alexander Lichter:

Staging environment is that. What is part? And once again, where we where we bake the data. Like Mhmm. How representative is the data actually to what the users use?

Alexander Lichter:

And, yeah, it's it's a big hassle Mhmm. On its own, but it's definitely worth doing, especially if you start with simple cases that are mission critical, which is usually that is the the tiny thing you have. Even it's just like, does the app start? Like, I started my application, and I can see things. Because a unit test will not tell you that if your application is up and running, but an end to end test will ideally.

Rijk van Zanten:

I I think the the most difficult part there is just to to answer the question of what is the right level of testing at a certain point in the development stage of the project or at all. So one other thing, which in hindsight sounds absolutely bonkers, but it was true, is I guess to work at a web development agency where for most websites this is this is smaller, you know, little websites from companies around, you know, the Amsterdam region and sort of the Netherlands as a whole. Like, at that company, didn't use any Git at all. It was just all straight on a live development server. No tests whatsoever.

Rijk van Zanten:

Just full stop. And it was fine. Because it's like, you just make a change, you hit save, it just goes to the live production server. And if you just

Alexander Lichter:

Just FTP?

Rijk van Zanten:

Just straight FTP it up.

Rijk van Zanten:

And and you refresh the website, and it's like, oh, whoops. And you just fix it and it's done. But it's like it's it's a fairly low risk environment. But I'm like, in hindsight, you know, again, testing, tremendously good thing.

Rijk van Zanten:

I can't stress it enough for production environments. But at the same time, there are some projects where you can get away with taking more risks. Right? And the amount of of, time and effort that you save, you can reinvest into making the thing better to a point where tests become important. So there's such an interesting balance in the tests are a good thing, but at the same time, if you are, you know, chasing the a 100% whole green check marks all the time, you might be investing a hell of a lot of time into something that might not matter as much quite yet.

Alexander Lichter:

And especially if it comes to your own application and you have, like, 0 customers.

Rijk van Zanten:

Oh, especially if it's, like, insert yeah, sir. Yeah.

Alexander Lichter:

Yeah. Yeah. So if you're right if you're right, like, unit desk before having a single customer, maybe double check check it.

Rijk van Zanten:

It's it's just a it's it's such a case by case, and it's such an opinionated thing. And some developers, they they do everything test driven because that's just the way they're sort of you know, that's how they are more efficient, that they think about what is the when does it pass, write the test first, and then implement the thing. Fully support it. Like, if that's your way of working, then good for you. But it's just an interesting thing because there's no rules for how to test the there's no rules of of how to test if your tests are relevant yet.

Rijk van Zanten:

Right? There's no one answer that says, oh, at this point in the life cycle of a product, do you start using XYZ or something like it? The because it's, it's so different. It depends on who's your audience, who's your user, How much risk are you willing to take? Are people expect like, if it's a 0 dot release, are they expecting things to break?

Rijk van Zanten:

Sure. At that point, do you care as much about locking it down yet, or are you just in a quick cycle and it's like it depends on so many things. It depends on so many things.

Michael Thiessen:

This might be a little bit of a tangent, but I thought I'd throw it in there. So there's this concept called mutation testing. I don't know if you've heard of this. I spent one internship researching it, but it was very interesting. And basically, the concept is you have these this thing that tests how good your tests are.

Michael Thiessen:

And, basically, like, it it will

Rijk van Zanten:

Very Good, Yeah.

Michael Thiessen:

It basically changes one piece of your code base. So, like, it'll change addition to subtraction, and then it will run your test suite. And then it will say, do any of these tests fail? Because one of them should. And if none of your tests fail, then you like, that bug is not caught.

Michael Thiessen:

That mutation is not caught. And so then, you basically go through, like, it's this explosion exponential explosion of, like, okay. For each line, you can do all these different changes and, you know, and it's just like so there's like

Rijk van Zanten:

I I Yeah.

Michael Thiessen:

I think it's mostly used in, like, research areas because it's not feasible, like, computationally because there's just so so many, like yeah. It it's crazy.

Rijk van Zanten:

But there's also an infinite amount of permutations, like, every single line of code you can do.

Michael Thiessen:

Yeah. But then there's, like, research for, like, oh, there's this subset. If you use these 7 changes, you can catch, like, 90% of Yeah. Potential bugs. And so then, you know but anyway, I thought I'd throw that out there.

Alexander Lichter:

It's actually it's really fun because I I actually researched the same thing in university with, a friend of mine back then to do to get some credits. And, there is a framework out there, called Stryker, for JavaScript to do exactly that in patient testing. We used it back then. Finally, I met the author. Shout out here to to, Nico Jansen, who is, well, not living too far away, actually, in in Belgium, I think.

Alexander Lichter:

Hope I didn't get it wrong. Otherwise, Nico, correct me. Because I'm in the the conference or so. Like, last year, the the conference was really funny to, like I haven't used it for ages. It's like, wait.

Alexander Lichter:

Striker. Like, has the shirt like, the logo is, like, very, very dominant colors, and and I was like, wait. I I know that. It was it was super fun. But, yeah, especially interesting, like, the low level programming of, like, hey.

Alexander Lichter:

If you change things here and then, oh, yeah, you have, like, memory, like, you you have, like, some issues with, I don't know, stack overflows or, like, using memory that's not allocated or whatnot. Right? Like, we're all no well, left, I guess. So the people roughly have an idea what to talk about.

Rijk van Zanten:

Immediately curious what does the testing look like for Stryker? Well, do we have a link and show that a little bit

Alexander Lichter:

Yeah. Exactly.

Rijk van Zanten:

I'm sure it it is gonna be a very sell referential thing, isn't it? Because I I'd bet money that Stryker is using Stryker to test Stryker, and it just gets super interesting.

Alexander Lichter:

Indeed. And they also support TypeScript. So it's like there's there's a lot of things, to to look into that. I I wish I'd have more time because I think it's a super interesting part of the whole thing, like, are tests relevant? Are they actually testing something?

Alexander Lichter:

And not only by saying I deleted and the coverage is the same, right, for for, like, unit testing.

Rijk van Zanten:

Also, related, I'm wondering a bit of a hot take maybe. And, again, don't take this as as gospel, but I'm also curious how much the usability of unit tests goes down a little bit the stronger you make your type system. Because, like, that's another thing I noticed when we switched to TypeScript that it's like a lot of the unit tests that we have to write ahead of time, which is like, okay, we have to make sure that the parameter that is input, that it doesn't break if you throw it a null or an object instead of a string or whatever. Right? Or you have to make sure that it is strongly equal and strict equal instead of a regular equals or something like that.

Rijk van Zanten:

But with, you know, TypeScript, the moment you make it super strict and you don't allow any any use or unknowns or anything like that floating around, At that point, you get a level of guarantees around what the types are coming in and out of functions. So therefore, as long as the output type still matches as defined and the input type still matches as defined, Now your unit testing that the operation within is correct, but you don't have to, you know, the coverage number that you're trying to hit can go down quite a bit because you can just rely on your type system for a large chunk of what usually had to be unit tests before that, which is interesting.

Michael Thiessen:

Yeah. The TypeScript sort of eliminates some of those unit tests that you don't don't need to write otherwise.

Rijk van Zanten:

It also makes your functions a hell of a lot brittle for for for the same reason, which is, like, if I'm making a a thing with a public API and somebody's importing my function in another project, but in my code, I use TypeScripts, and therefore, I know that the input parameter is a string, and I don't check for any other cases, it's fine for internal stuff because I know where I'm calling it and the types checks it on both sides. But if it's some some other person that is using Node. Js without TypeScript or anything else, they can run into some very strange behavior. Mhmm. Because I never bothered to implement any of the type checking anymore, even though it's still JavaScript under the hood.

Rijk van Zanten:

Right? Bit bit odd. It's like we're still writing JavaScript with TypeScript. So therefore, did we end up writing worse JavaScript because we're relying on it? Hot take.

Alexander Lichter:

I would argue that really, like, the people that don't use TypeScript, they are responsible to make sure if it's documented that, like, oh, this method only takes a string and you pass in the number or, like, null or undefined, that's not up to you as the library author. Right? He documented, hey, this is the do the correct behavior. If you pass in a string, all good, then we can do that operation here and reverse it. Pass a number is up to you.

Alexander Lichter:

So if you don't use TypeScript, which is also fine if that's your choice or if you can't, like, actually, I have heard companies saying we can't use TypeScript, for for a bunch of reasons. Like, oh, we have to get every NPM package approved and all.

Rijk van Zanten:

Oh, yeah. Compliance.

Alexander Lichter:

Yeah. Yeah. Yes. Compliance, especially. Yeah.

Alexander Lichter:

Then, like, okay. Then you have to make sure that this is really a string, and, then that's sadly up to you in a way. Probably, like, you your IDE can still help you. Right? But you get run through the

Rijk van Zanten:

Is it though? Because at the same time, you know, from a a library is nice to use perspective. It's like if I use a library and I use it wrong accidentally, because I misremember or read the docs wrong, and it just throws an error that shows me exactly what I did wrong, I have such a better experience using this thing that I'm way more likely to keep using it long term. Whereas if it just behaves weird with no explanation as to what is happening or how to fix it, what ends up happening is I go to GitHub, I open an issue and it's like, it behaves weird. And then the author is like, well, yeah, you're using it wrong.

Rijk van Zanten:

Like that whole circle of annoyance on everybody's side could have been prevented

Alexander Lichter:

by adding checks.

Alexander Lichter:

Yeah. Using TypeScript.

Rijk van Zanten:

Or by using TypeScript.

Rijk van Zanten:

I'm just yeah. Yeah. For sure.

Rijk van Zanten:

Sure. Sure. Sure. Sure. Sure.

Rijk van Zanten:

It's it's just funny how that works because we're still we're still targeting JavaScript even though we're writing TypeScript. Right? We're not saying this is a TypeScript only library. We're saying it's a thing you can import with JavaScript even though we wrote it with TypeScript and we expect you to use it. But that does set a different expectation model that if I were to make a new, you know, the, let's say we we have, like, the Direct SDK or something.

Rijk van Zanten:

It's like a separate library. People install it into their own projects. You import the function you wanna use. We're in the same boat. We had it all in TypeScript.

Rijk van Zanten:

We expect that the parameter of, like, what table you wanna hit is a string. If it's not, lord knows what happens. Like, we don't we don't account for that. We don't test against it. Haven't even thought about it.

Rijk van Zanten:

Because we're saying in TypeScript, this is a string, therefore, we assume it's a string. But nothing is checking that. Like, somebody could import the function and just throw a Boolean in there, and then things go weird. But at that point, they don't break. They just behave weird.

Rijk van Zanten:

Right? It's like things might work sometimes Yeah. And not in other times. And it's just it becomes it becomes annoying on on both sides, because it's like, the end user doesn't know what they're doing wrong, so they come to ask in, you know, either the Discord server or they come to ask on GitHub or elsewhere. They get annoyed.

Rijk van Zanten:

You know, they're running into it. They're banging their heads. And it's like, is is the answer that I then give, well, sucks to suck should have read the docs? Like, that that that feels a bit weird as well. You know what I mean?

Michael Thiessen:

But Just throw all the error messages are use TypeScript.

Rijk van Zanten:

Right. Yeah. It's like if

Alexander Lichter:

you can send

Michael Thiessen:

A Link to install.

Rijk van Zanten:

Yeah. In order to open an issue, please use TypeScript first. It's it's just a bit of an interesting thing, which which doesn't exist in other programming languages for the record. Because, like, if you're in Java or Go or Rust or whatever other thing nowadays in Swift, like, because it's you have a guarantee it's strongly typed on both sides. Right?

Rijk van Zanten:

So you don't have to implement a lot of those checks because the thing won't compile in the 1st place if you use it wrong. And we don't have that luxury yet because we're still targeting JavaScript, which is an interesting you know?

Alexander Lichter:

I wonder how it is in a language that Directus was written in before in PHP nowadays, given that, like, PHP hasn't had, like, type hints for a while and it's in, I don't know, 8 or so or before. I think it was an 8, but I don't know.

Alexander Lichter:

And how that will work nowadays? Like, okay. Yeah. Also there, you don't have a guarantee that what you do is is fully typed.

Alexander Lichter:

So there, it might be a similar issue. But on the other hand, if if you let's say, if if you as the the consumer of a library or, like, see you as an app developer, you write JavaScript deliberately or, like, because you're forced to, then you already make all these trailers and they say, okay. You read the docs and say this should be a string, and then, ideally, you already make sure that, oh, if it's not a string, then don't continue here in your own, let's say, wrapper function in your own, before calling it, ideally. Because usually, you are aware, okay. We don't have any runtime errors.

Alexander Lichter:

I have to because I don't have any types. Make sure this is what is getting passed in. And if you're aware that it should only be a string, then you would check that before in in theory. But I see the point in terms of it's it's a trade off of, like, DX versus, bundle size performance whatsoever of saying, yeah. If that's a common mistake and people do it commonly, then there's a a way around to fix that, which is giving an an error message.

Alexander Lichter:

The problem is, are the people really happier about that when their production environment just throws an error message? At least they can track it. Right? That's that's good. Or they see it in-depth.

Rijk van Zanten:

It's I I think at at any point, especially in development modes, you wanna be told what you did wrong so you could fix it. It's like if if you run into an error and it just behaves weird, now the answer of how long is it gonna take to fix is anywhere from 2 seconds to 20 hours. Right? Because you don't even know where to look. You might have to pull up source code and figure it out.

Rijk van Zanten:

Sure. Which funnily enough, call back to the whole Vue 2, Vue 3 migration. One of the pain points that we also ran into at the time is that this the SEO for the Vue 2 tutorials and docs were so good that it was near impossible to find any information about the composition API.

Alexander Lichter:

And I guess that was also just less available. Like, there was

Rijk van Zanten:

Of course. Yeah.

Alexander Lichter:

It's it's new. Like Yeah.

Rijk van Zanten:

But it it was a similar thing that it's like, okay. You run into weird behavior of the composition API. Now I'm at a point of like, okay. Is that something that I did wrong? Probably.

Rijk van Zanten:

Because I don't know how to use it yet. Right? Where do I go to find this? How do I know what I did wrong? And it's like, if the tool doesn't tell me and there's no dev tooling around it, nor TypeScript types or anything else,

Rijk van Zanten:

where do I

Rijk van Zanten:

go from there? And that is still the reality for a lot of people because at the end of the day, we are shipping JavaScript to both Node. Js, to the browser, to bun, to well, I guess Deno is a bit of an outlier there, but it's like There. Yeah. I mean, even in Deno, you can have not strict TypeScript, so therefore, it becomes, you know, more of a hint than a requirement.

Alexander Lichter:

I wonder if you

Alexander Lichter:

can solve that by by just saying you have a dev bundle, which is loaded. There you have all the error messages and say, hey. This error is only thrown in dev. In production, you have a minified version, which, well, makes it easier. You can even automatically tree shake that with, like, I don't know, rollup when you bundle stuff, say, oh, if this flag is not set, then remove these checks.

Alexander Lichter:

That could be, I think, interesting to have that experience. Like, Vue is also doing that with a lot of things, like hydration errors, with validator warnings, whatnot. You just make sure, okay, and, definitely, you have that DX in production. You have the the lean bundle, and if you pass something else there, too bad for you. Mhmm.

Rijk van Zanten:

Yeah. Yeah. For sure. But that that puts a lot of additional because because to your point, I'm I'm really much on the fence. Right?

Rijk van Zanten:

I'm I'm on the one hand, I'm advocating here for, like, oh, we gotta make sure that DX is good libraries. At the same time, I'm not doing it for the for the exact same reasons you just outlined because it's so much extra work to to get that nice. And we are using TypeScript and expect people to do the same. So, therefore, what's the point of spending all this extra effort in in doing type checking in runtime if it already exists in TypeScript? Yes.

Alexander Lichter:

That's a whole different problem

Rijk van Zanten:

But it is a

Rijk van Zanten:

very interesting sort of, like, you know, where do you sit and and how much do you value DX for non TypeScript folks? And is it a TypeScript module? Should we ship it and say this is a TypeScript library and its intent to be used there only? And, yeah, it's it's an interesting time in the industry, especially now that, you know, you have those those proposals that have type hints in native JavaScript. Like, that opens up a whole different world of, like,

Alexander Lichter:

Difficult.

Rijk van Zanten:

Yeah. Yes.

Alexander Lichter:

Yes. Oh, really, really tricky.

Michael Thiessen:

I wonder what the the adoption rate of TypeScript is, like, across across companies. Like, I mean, obviously, migrating from JavaScript to TypeScript can be a big a big chore, so not everyone, even if they want to, can just, like, switch over right away. So I wonder what the what the split there is. Is it, like, majority TypeScript, or is it just, you know, all the stuff you see? There's this, like, weird perception issue that I that I've noticed where people think everyone is on the latest thing, everyone's on the on Yeah.

Michael Thiessen:

Q 3. Everyone is, like

Rijk van Zanten:

Yeah.

Michael Thiessen:

Doing this stuff. And then, you know, you talk with other people and you're, like, oh, wait, you're still on the the version of you that's, like, not really supported anymore because it's, like, insane amount of work to to to do the migration and we're trying to ship features. So

Rijk van Zanten:

say, we can't do it. That how do you defend that on your roadmap? Right? It's like, I'm gonna spend

Michael Thiessen:

Yeah. Exactly.

Rijk van Zanten:

2 months with my whole team and you get nothing in return from from a business value perspective. Right? Which is silly because, of course, the way engineers know that it's a you have to do it at some point. But from from other stakeholders, how do you defend that? It's like you're you're circling, you're you're spinning your wheels, and then you get nothing in return.

Rijk van Zanten:

Right?

Michael Thiessen:

Then me and Alex are out here just look, we're only talking about the new stuff. Like, I'm not talking about Vue 2 or Vuex or anything like that. And we're talking about the latest features and the new stuff that's coming around. And so it yeah, that's just weird.

Rijk van Zanten:

I had a very similar problem just the other day. It's like we've been running so, so Directus is shipped as a Docker container, sort of the primary hosting model, because it's just the easiest for people to spin it up. Right.

Rijk van Zanten:

Cause you don't have to fill the native dependencies, not looking this up. We have been running on Node.js 18 since it came out, but we didn't upgrade to 20 when it came out.

Rijk van Zanten:

Because I had a very similar moment in time that I'm like, okay. The upgrade's between 18 and 20. Yes. It's an improvement.

Rijk van Zanten:

But is it enough of an improvement to warrant upgrading the version of Node? Not real. I I had some trouble just defending investing, you know, a week or 2 in doing that. And I'm saying a week or 2 because we're dealing with Docker containers and a bunch of extensions and plug in authors and, like, you know, documentation updates and all that kind of stuff. There's a lot more that goes into it now.

Rijk van Zanten:

But then somebody rightfully opened an issue and was like, hey, are you gonna update to Node 20? I'm like, yeah. Make yeah. And then somebody the other day was like, well, at this point, you might as well go to 22. And I'm like, oh, honestly though, that is now the plan.

Rijk van Zanten:

Yes. Yeah. Because

Alexander Lichter:

Skip a major.

Rijk van Zanten:

Yeah. Now Node 18 is going end of life. That's a very good reason to upgrade, and we will. But at the same time, it's like the benefits of that upgrade in between didn't outweigh the time investment and and sort of the the risk of breaking changes and all that kind of stuff and extension authors in trouble and all that. But now that I'm like, okay.

Rijk van Zanten:

Node 22, 18 is end of life. Now there is a definite bump in performance. It I can make it make sense. Right? So we're gonna do it. But it's it's funny how that works because I I was right there with you, and I thought, oh, it's always gonna be on the latest thing. And then now in real life, I'm like, nope. Nope.

Alexander Lichter:

As soon as it gets about business value and I was like, how to spend your time as there are so many things around, like, that's that's a common thing. And, like, quote, unquote justifying, like, even package maintenance for business, there there are ways, of course, to deal with that. But we had to suit Kumar on here in the podcast in the last two episodes, actually, before this one where he's running a a SaaS, like, with 250,000, like, customers or, like, users logged in and registered. And he's also like, yeah, upgrading for Nuxt 2 to Nuxt 3, which is also like a a huge thing, of course, like the YouTube user migration, like similar, maybe a bit more, a bit less. Depends.

Alexander Lichter:

It was also, like, yeah, push pushing out as much as possible because what you gain, sure, like, developer productivity, but how do you measure that? How do you attribute it? And in the end, at some point, you don't really have a choice in terms of security, of course, same with, like, end of life with versions, be it Vue 2. As end of life for, well, almost a year now, be it, Node and, obviously, That's that's one point. And there are and also sometimes libraries that say, hey.

Alexander Lichter:

We don't support options API. We don't only do composition API, which is

Rijk van Zanten:

They are blocked out.

Alexander Lichter:

Yeah.

Rijk van Zanten:

Yeah. Yeah. Yes. I mean, you mentioned security, which I'm right there with you. It's like the second you have an end of life thing, you gotta get out of it immediately because if there's any security problem, then you're out of luck.

Rijk van Zanten:

Right? At the same time, just looking at the user base of directives in real life, the amount of people that don't upgrade, even if there's known security vulnerabilities and all that kind of stuff, they just don't. They just don't. And it's like, they either don't care or it's too much of a I don't wanna upgrade because then I have to double check if all my stuff still works or, you know, any of those things. But what I what I have noticed is that there's a lot of companies where even security patches are on the pool of, like, oh, that is time spent without measurable output, so therefore it's time wasted until it goes super wrong.

Rijk van Zanten:

And then the person who didn't do the upgrade is now at fault. You know what I mean? It's like, it's such a double edged sword, but it is how it is. It is how it works at at some companies, which is crazy. But I've seen it a lot a lot more, and it worries me greatly.

Rijk van Zanten:

But, yeah, just security patches by itself is not even you know, for a lot of companies is not not a reason, which is weird. And I

Alexander Lichter:

mean, then thinking about we'll go back to the status quo of like, okay. Yeah. We had that incident now, but from then, whatever. Or then it's finally, like, hey. Security updates are are important.

Alexander Lichter:

But on the other hand, I also think, like, I don't know if you have an old running Vue 2 application. Like, if it's a done project, if there is no money for that, if it's working, do we really need to upgrade that? I don't think so.

Rijk van Zanten:

That's another very good point. It's like this, this harsh spec to the agency days is built, but it's like, we, we would build a WordPress theme that it would up on the FTP server, hand it open to the customer, money gets paid. At that point, never touch it ever again. Right? It's like, you only touch it if somebody 5 years later reaches out and is like, oh, can we get an extra link in the nav?

Rijk van Zanten:

And then you pull up the code base. I'm not gonna spend a week upgrading it to the latest and greatest. I'm just like,

Alexander Lichter:

30 30 hacks. Yeah. 30 hacks. Run it.

Rijk van Zanten:

And it's just like, I'll just go ahead and ship it because that's the quickest way. That's the most efficient way. And therefore, the most profitable way at the end of the day. That that is that is how businesses run. Right?

Rijk van Zanten:

It's it's all money at the end of the day. Can also

Alexander Lichter:

tell your customer, like, hey. Look. Yeah. We upgrade this now for 2 weeks, so it's up and running. And then he will say, like, how much is this?

Alexander Lichter:

And you say number, and he will say, no. Thank you. Yeah. It's like, what

Rijk van Zanten:

what do I get from this upgrade? I'm like, well, it's gonna be a little faster and a little bit more secure. And the person's like, I don't Yeah. I don't care. Whatever.

Rijk van Zanten:

Yeah.

Alexander Lichter:

Yeah. But especially for, like, all these custom projects, we're like, okay. Vue 2 is not end of life. And for the majority of the project, it's probably fine. It really depends if it's still, of course, ongoing running any

Rijk van Zanten:

I think that's a big difference. Right? It's like if you're running a SaaS or you're running a startup app or something, you wanna keep it up to date and on the latest and greatest because every improvement in the framework is an improvement for your end users. So it's worth doing. But if you're in an agency life where you're building, you know, let's say, primarily static websites or primarily static plus static static with a form, websites, then it's like, do you really care?

Rijk van Zanten:

Probably not. It it'll work just fine. It'll work just fine. So, yeah, you you probably won't. But that's that is where it gets a little tricky with when you have when you're dealing with, you know, server side stuff or or database, you know, in my world now.

Rijk van Zanten:

That it's like, okay. Even if you have your website that you delivered a year ago, if now there is a security patch in Directus itself that you're using to power that website, you should still update the back end. Right? Because you have a live server and a database and customer information flowing in and out. And, like, somebody has to own that dependency and and keep it keep it alive.

Rijk van Zanten:

Yeah. For sure. That's that is the heart of the part of the work. And and back in the day, I mean, I again, guilty as charged in the WordPress days. We never ever did that because it's just like it works.

Rijk van Zanten:

It's fine. Oh, there's a WordPress security problem. So it's a small website. What are the odds? And then some automated bot does it anyways.

Rijk van Zanten:

It's like, oh, whoops. Well, revert to backup and on with life. It's it's kinda surreal, but it is it is how it works at a lot of places, unfortunately.

Alexander Lichter:

It still does. Yeah. I guess so too. Yeah. But luckily, not in our places, neither, it directs itself nor, well, we we both we all have our own companies, so to say so.

Alexander Lichter:

Yeah. Yeah.

Rijk van Zanten:

For sure. No. It's it's it's like I I strive for it. And I I wanna make sure that, you know, within now now that Directus is more of a business than just a project as well, I I wanna make sure that we we keep that top of mind. Right?

Rijk van Zanten:

That it keeps security patches are critical. There are always top of the to do list. And it's, like, dependency updates, you know, we use Renovate bot, to automate a lot of the patches, and we have some test suites to make sure that that is automated. You know, we push out patch releases roughly every 2 weeks or so for people that wanna follow along. So it's like very important, but that takes a bit of, you know, whoever's in charge of the roadmaps and decision making has to find that important, and that is just not a universal truth.

Rijk van Zanten:

Absolutely. Yeah. More often than not. Yeah. Right.

Alexander Lichter:

I think that's a a good moment. We've been, in for more than oh, almost one and a half hours here.

Rijk van Zanten:

Oh, jeez. And we have

Alexander Lichter:

and we can fill probably 2, 3 more episodes with everything mentioned.

Michael Thiessen:

Yeah. We didn't even talk about, open source funding or anything like that. So Yeah. I think we've got a couple of, like, couple of episodes.

Alexander Lichter:

We heard Directus was a source available, project. So we'll we'll come to that another time because

Rijk van Zanten:

Yeah. Very good.

Alexander Lichter:

We can we can easily add another 90 minutes to that. Rijk, it was a pleasure to have you on the DejaVue podcast. So we have one last question. Where can people follow you and direct us?

Rijk van Zanten:

Follow. You can follow me ideally on Blue Sky nowadays. I I I am one of the folks that switched camps. It is 2013 Twitter, and I'm all about it on rijk.nyc. There will also be a personal website for the first time in a decade under that same address.

Rijk van Zanten:

So that that'll be exciting. It'll be a good place. Otherwise, on GitHub, I have my full name, Rijk van Zanten, and just directus all over the Internet. We're we have accounts on every single platform you might you know, you're you're on. So find us wherever you are.

Rijk van Zanten:

Sweet. Of course, all

Alexander Lichter:

the links as usual in the shown and slash description so we don't have to, like, type it while you're in that going back. I mean, you can if you if you feel like it. Yeah. Like, thank you so much, for for, being with us here and, sharing not only your your journey, all your experience, and, of course, also all hot takes.

Rijk van Zanten:

That's what I love doing. Take a breath of me.

Michael Thiessen:

Yes.

Rijk van Zanten:

Take a breath of me.

Alexander Lichter:

Yeah.

Alexander Lichter:

And, for everyone else, if this is not late in your episode, jump straight to the next one, you know, that's in queue. Otherwise, go back to the the old ones. We have, linked a few also in the the show notes as usual. It could be interesting. And if you offer it, then congrats.

Alexander Lichter:

Leave us a comment, and, you'll we'll get your cookie at the next conference, I guess. Talking about conferences, though, is very important. The Vue. Js Amsterdam comment conference is coming up soon, and we have a little 10% discount code if you're already interested. Reich was a a speaker before.

Alexander Lichter:

I've been there a couple of times, and I hope Michael will be there, next year, in the 2025 edition. So, I hope all of you will be there, actually. I mean, like, you're you're from Amsterdam, living in New York now, so it would be a great excuse to come around.

Rijk van Zanten:

If if they'll have me, I'll be right back.

Alexander Lichter:

Sweet. So I hope, we will see all of you there, and you will see all of us there. And we'll see you in the latest, or the older episodes. So thanks for tuning in, and, see you in the next one. Bye, folks.