The Quadruple Migration (with Rijk van Zanten)

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

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.

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.

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.

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.

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.

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?

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.

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. I I I've seen that same thing happen, on my end as well. Yeah.

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?

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.

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. Just like, here here AI, go for it. But even without that, it's it's

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.

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

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. So you got all

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

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.

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.

2 different branches.

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.

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.

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.

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.

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.

Like, there's

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?

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.

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.

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?

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.

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.

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. 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? It's a bit of a ramble.

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.

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

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.

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.

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. That's that's the real skill I feel like that is that is important, to learn.

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.

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.

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.

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. 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.

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.

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.

So just gonna slip that in there.

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.

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. And for me, it's always a, yeah, a a good a good sign, so to say.

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. 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.

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?

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.

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.

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.

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.

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.

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?

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. This is all I need.

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.

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. 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.

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.

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. I wanna say that's sort of

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

And it it worked out. It worked out, luckily. But it worked out. Luckily. Yeah. 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.

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. Don't do it. Don't do it. That's the lesson learned. But sometimes it works. Sometimes it works.

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.

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.

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.

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.

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.

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.

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. I like seeing the stuff that I'm writing live. Right? Same thing. Vue 3 files, didn't exist. Right?

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.

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. 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.

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.

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. You you sort of add them back in over time. But that was, like, that I'm think of.

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.

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? For for production stuff, highly support doing tests. But it's it's a different point in time at that point.

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.

Coverage. Yeah. You have coverage. And once Yeah. The tool says a 100%, you're like Easy. 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.

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.

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.

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.

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.

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

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.

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?

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.

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

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.

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?

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.

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

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. 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.

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.

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.

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.

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.

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

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.

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. 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.

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.

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.

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?

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?

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.

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.

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.

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.

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.

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.

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.

Q 3. Everyone is, like

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.

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.

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. Yes. Yeah. Because

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.

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.

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

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.

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. 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

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,

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.

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.

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. 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. 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.

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.

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

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. Sweet. Of course, all

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.

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.

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.