If you're interested in web development specifically with Next GS and Versal, this episode is for you. Joining me today is Tim Notgans, Next GS lead over at Versal and one of the earliest people to join and start contributing. With over 1,000,000 developers actively using Next GS, a lot of things have changed big time. He shares how things started, what has changed and where it's headed. So enjoy. Yeah, it's, it's incredible. Like next year's has gotten so huge.
I, I first saw it for me, it was about six years ago. And now it's passed more than 1,000,000 developers. That's insane. How long ago did you get in touch with it and how did you get started with it? So I've been in for sale for almost 7 years and I started contributing to it a year earlier than that. So it's almost eight years now. I think like it's already over 8 years now because we released it in October 2016. It wasn't very good. I first saw all the time.
So I, I just saw it in, in like open source. Basically, I was involved in the, in the Versailles community for a bit like working on other things. So there was like they, they had multiple like up source projects that, that were relatively popular at the time. Like nothing in the numbers that you see today in, in open source, but they had like thousands of like stars on GitHub. So that, that was like pretty
big at the time. And I just find it really interesting like what they were doing and they were building a like a terminal with eptech called hyper. I was contributing to that and, and to like plug insurance for it. And like, and then basically in the end, like I, I reached out to, to Guillermo to, to basically say, Hey, if you ever want to hire like anyone, let me know. And he was like, yeah, we work really small company. Like it was 5 people at the time, I think something like that.
And he was like, but let have a look at this like new finger building called Nextchez. And I was like, ah, this is pretty interesting. Like it's like I was doing a lot of PHP development at the time. Like I was building in like Rick Brass and Magento and Symphony and like that kind of thing. And basically what we did in the end is like I started contributing there because I found it really interesting and looks really like a lot like PHP to me, at least at the time.
Like it was like create like pages index and then like pages indexes a route. And it's like very similar to index of PHP and the way that that works. So it's like, kind of like if you get like PHP, but has a component model with React and you can build apps that way where where like I saw with the at least in the applications that I was building, this agency I worked for, like people were like copying the same codes a lot. So they, they would either like this button needs to be used
here. So we'll just copy the the HTML and see just for that to this other place or like even across apps, right? Like that. That was the big thing like we work in the agency should probably know like there's a lot of customers as well and they, they all have like very, at least for UI, it's like very similar needs like there's always buttons, drop downs, menu bars and like the variants of menu bars, that kind of thing.
But what I saw is that they were the company I was working for was recreating them every time that you start a new customer. And it was like, God, this could be better. I think. And like with this like reactors getting a bit more popular at the time, like not everyone knew about it, but at least like there, there was like some like
model to do this. And like they like in the long run, like we've seen that like UI frameworks are here to stay, not just React like few and svelte and solid and like all these other like libraries that they're just, yeah, they, they're here to stay. And like we're, we're going to like build apps in, in this way for quite a long time. I think even if it's not React, like if you're using like another UI library, like you're still basically building on the
same concepts, right? Like the statement is just slightly different and like the, the way that the outputs are generated and things like that. But in the end, like you're, you're still like componentizing your app and that's the the core like win that that we've seen over the last few years. Yeah. So you started actively contributing to next year's when it was open source then? Yes, yeah. So not before it.
It was like after after the open source and like that I think like a month later or something like that. Gotcha. Yeah. And when did Versal kind of pop up? Was that around the same time or was that after? The company was started in 2015 and they were building a it was called site at the time and they were building like a hosting platform but it was a single command to deploy website. So you have a PHP website or a or like no GS website or
anything like that. You would run now, which is the CLI command and it, it would just deploy it for you. And then you, you get like a magical like URL that you can share with your colleagues or you could put it in production and then see the like serve that as as like live traffic. And that basically like evolved over time into more like
serverless offering. Initially it was like old Docker and now it's sold serverless and basically over time we, we built out like all the core like tooling you need in order to build a, a website to like build it and then deploy it in production with preview. The preview URLs. Those are the URLs that you can share with like your colleagues or your customers or anything like that.
And that was really because I, I find the like Nexus I find really interesting, but also that like concept of having a like, almost like a staging environment for every single commit that you're doing is it's really powerful and started in like working at this agency as well. They had like 1 staging server where everyone was like merging their changes in into. And it's still like the, the way that most people work nowadays, I think.
But in practice, like what what I found is that that causes a lot of like conflict as well. Like you got like merge conflicts or someone merges their changes, but the changes to the database are, are not the same or things like that. And it would, it would just cause like the staging environment to break continuously. And that's also the reality you're sending to customers. So like your customers now seeing that you're like messing up in some way. Like the reliability is not
there if it breaks all the time. Yeah. And like we would get, as they say, we've got like customers calling like hey, we're trying to watch the the staging environment, but the staging environment doesn't work anymore. Can you add another staging environment in front of a? Stable one. Like the yeah. So like the like the you would call that like pre production or something like that. That is the thing that they used to verify the changes that you're doing are correct as well.
Look good. It's really funny because I, I joined Xavier around six years ago and then the first project I got on it was using Gatsby and it was using Netlify and Netlify had those deployable branches, deployable commits as well. Yeah, I was like, this is insane, right? I make a branch, I make the changes. I just sent that change specifically before it's even
merged. And I loved it and Gatsby even like I was really fond of it back in the day, but nowadays it's it's gone like I've been out of front and development specifically, but I definitely know Gatsby is not as big as it used to be yet. Next year's is like, why do you think next year's survived where Gatsby kind of perished? Because for me, Netlify, Versal, they were kind of neck and neck
Gatsby and next year's as well. And then also in an organization had a new CTO and he was like, we're going to migrate from Gatsby to next year. So I was like, huh, that's interesting. So I'm not sure about the the whole part about Gatsby, but I do know about the the Nexus part. And it's like we did fill in all the gaps that people were asking us for.
So a, a really big thing like around that time, I think that you were mentioning is that we, we launched like Nexus 9 point something that had static generation, but not static generation in the like SSG static websites. And which is like what I guess we output. It's it's like so, so let's talk about like what does Gatsby do first? So Gatsby in the first version and like the first few versions, it only had static generation, static site generation. And it basically means you you
get some data from somewhere. In this case, I was using graph KL, but like, let's not talk about that at all. But what it does in in practice is it it would take the data vendor, your React components with the data and then open them to static HTML on on disk and and then you use that output. So like this out directory or something like that to put it on a static web host so that it could be for sale.
But it could be like anything else as well, like at the pages or or Netlify or like like AWSS 3. So something like that. But that that's only static data, so you have to rebuild every time you make a change to the data. So that means there's like generation process. So there's like build step. Basically you always have to run that after you make a change through the data as well as through the code.
Usually you do a build after you change the code because then like otherwise it's not live as. Well. But for data changes, that becomes a, a bit of a like a hassle because you have to re like rebuild the entire app in order to get this like one change that. So, so you make a typo in your blog post and you say I added like a double character there or something like that. You delete that. Now you have to click save and the save will trigger like a rebuild of the entire app.
And if you're doing hundreds of changes per day, which is very common for for like these like larger, like larger websites that are using static generation, you would get into this problem where you would just get like a build queue. So like there would be a queue of like these builds need to run because you also don't want to run them all at the same time. And some could be cancelled in in between as well, right? Because if there's a newer change, then like this build is
not needed. So that's what's like side generation does. And then like Nexus was doing the complete opposite at the time. So at the time it would be a fully dynamic website. So you create a website, you have to basically same concept you need data, you need like components to render. Like we pass the data into the components and we render that using React and it creates an output.
But all that happens in a web server and the sub server is serving all the requests that are coming to the website. So, so you go to the website, you get like a render of that particular page for for you in particular, but there's nothing for you in particular on the page, right? Like it's always the same data that you're showing. If I go to the website, same thing. There's like no logged in state or anything like that. And because of that, you, you end up like wasting resources.
So in this case, you would re render too much. You would continuously like every time. It's like doing the build every time you get a request basically for the aesthetic page, excluding all the JavaScript being generated and that kind of thing. But so they sound very similar, right? Like it's, it's, you get data, you render it and you serve it to a user. But the one is dynamic. So every user gets his own like response that is unique, but
it's actually not unique. And the other is you do it all at build time and then you like everyone gets the same response. Yeah, from the server. So, yeah, from the from like the like static like bucket that you're hosting somewhere. So what you want to do or like what we were like, what we were thinking was like, OK, cache control headers, like they, they work in CD NS. You can add like cache control for a server. And then you basically say this dynamic response is actually static.
And now you can say cache it for one second or cache it for like a day or something like that. And you can also invalidate those. So you can say, let's invalidate like on your CDN, you can say invalidate this particular pod. The problem there was that we found that like not everyone knew about it and it was really hard to educate on those particulars of cache control, especially the because cash
control is like many directives. So like you, you also need like next to saying cash this for like 10 seconds, you also need to say, you know what, let's let let's not revalidate it like on demand. So, So what that means is that if you do a request to the page and like that that time has expired, suddenly everyone that goes to this page is going to get like a, a response from the server instead, because there's no cash anymore. Like there's the cash item is,
is expired. But really we don't want that because like what if you get like very high traffic, right? Like if you get hundreds of thousands of people going to your website and that happens and it expires, then suddenly it's going to be serving like 100,000 requests from the server and maybe the server can't handle that or your database can't handle that. You're going to get bombarded, yeah. Yeah, something like that.
So there's this other directive called Stillwater Revalidate, which came out around the same time we released this and it got like more adoption in, in like CDNS as well and like for sale CDN supports it, obviously that kind of thing. But basically what you find is like distillery validate behaviour is actually really nice for static websites. So it gets rid of this problem where you're saying generate this at bull time and then never generate it again until we do
another build. Because we can say if you go to a route and it's expired, served as still like cache entry still and then in the background generate a new cache entry. So that was the like the the big thing that we released. And then like AP is around doing the static generation for like a part of your app. So what we found as well is that like most people we talked to were these are like large
companies, right? Not so much like smaller users, but the smaller users also benefited a lot from this because they they were building their own personal websites, right? So if you build your own personal website, like high likelihood is that Guillermo would send your personal website that you're tweeting about to me and say this side is slow, but why is it slow? And then I would be like, yeah, the dynamic rendering and and this is not ideal for your personal website or my personal
website. So get like a new like website that someone released on XS ever where the person is super happy, like insanely happy that day. They were like next is amazing. Yeah, yeah, yeah. And we were like, we actually don't like this. We well, we like it in terms of like the thing that they built is really cool and like the website looks amazing and things like that. But then you look at the actual like performance numbers and it, it just didn't make sense for the type of app that they were
building. And it was contiguously sending the same response, right? There was nothing on your personal website that's going to say, hey, you're a team. So like, here's something else. And so basically we added this this way to create partially dynamic, partially static apps based on the right level, saying like on the right level, you could say this page is static, this page is dynamic.
And that allows you to basically say my marketing pages are static, but actually they might not be fully static in terms of like they, they're static, but also they have data that changes and, and obviously you can do like fully static where you don't have any data and like the data like the, the thing on the page only changes when you change the code. So that would be like MDX or something that's not remote, basically something that you don't fetch data for.
But what we found the the most like impactful was the like getting this play like getting to this place where you can do static and dynamic in one app. Goblet serve like hybrid websites applications because it allows you to say my dashboard is dynamic, it uses like a service app, props and my marketing page are as aesthetic by adding cats static. Props. Yeah, Yeah, I love that.
From the story, it sounds like you really listen to kind of what the market needed or at least your customers were saying or what problems they had, and that's what you implemented and improved. Yeah, yeah, it was definitely, yeah, it was something that we we had to like add at some point just because we saw like so many people struggle with it. So it was like not even someone it, it wasn't like a customer telling us like, hey, my wife is this. So they were like, no, next is amazing.
Like we're we're way more productive in in what we're doing partially also because they they switched from something that didn't have components, for example. Yeah, that helps. Yeah, that helps a lot in feeling more productive as well or like building pages out quicker. But also they were like NX is really like, it's working for us really well. And then like we were looking at their performance and it was just like we it's good. It's not bad.
It's. It's just that it's like 500 milliseconds for a page that could take 30 milliseconds or something like that. Were you that like specific focused on performance like with the builds and with speed and was that the number one, let's say target to look? Not the number one target per SE, but we, we always optimized
for for three or four things. So, so when it's performance, like your, your actual application performance is really important to us. The like, the overall, like the benefit that you get from adopting access is that you get compared to like other applications that you've built, you get better performance. But it'll also because like we tried to nudge you towards like static generation, for example, that you couldn't do before and things like that.
The, the other is security. It's like really important that you build secure apps and, and developer experience, right? So like we, we were like one of the, the early frameworks that like started to focus on developer experience, you know, like getting like really good error messages and they could still be better. Like they're, they're not, they were not there yet. But the error messages fast refresh. So like reacts fast refresh.
We started implementing that. So it basically allows you to change your code while like Allstate on the page stays the same. So that means if you throw the drop down, the drop down will stay open. If you're using React state for that or like anything else really. Like if you type something in a form, that kind of thing. And then yeah, that's like mode, like most of it is like DX performance security.
And like overall performance is also like, it's such a wide thing because it's it's like UX, like user experience, like that kind of thing, but also like the X related. So like performance in in like build tools. So like the getting the builds to be faster, getting your development to be faster, that kind of thing. That's that's what I mainly looked at when using tools or when adopting tools is like developer, I call it also
satisfaction. Like I love being productive and the feeling of the tooling that I use in making me more productive is a really big, let's say, hit or miss. Sometimes if there's a paywall, I'm not even going to use a tool. And if there's tools out there free of use and I can see, let's say the benefits, then you get hooked and you want to do more, right? And then you start looking into the resilience of whatever tooling you use, especially if you use it as a hosting
provider. Security definitely needs to be there because otherwise why use it in a more large scale environment? And then indeed performance, like performance that comes out-of-the-box and not necessarily is impacted by how you use it, because how you use it is always going to impact performance. So then you look at what comes out-of-the-box, I would say. Yeah. And like over time we we added these like improvements for UX as well.
So like the like next image components, for example, this like outer sizing, like resizing the image to to size that makes more sense to, to your like mobile device, things like that text font. So like being able to import a font that is like does all the best practices for you. So like, like if you ever used web fonts, like you probably know that the add font face thing, but actually that's just
the beginning. So like, if you do that, you get some kind of layout shift cause the, the font that you're falling back to is never the same font that like you, you wanted to use. So we're we're doing like this thing where if you're using X font, it will automatically create like a fall back font for you that is more like the original font that that you're trying to load in that little has like real like measurable UX like improvement. And then we, we tried to optimize CSS, JavaScript like
all that as well. Looks like reactors is not the smallest library to, to like bring in. But like we tried to do our best to, to also like reduce the size of Nexches for example, in between like 11. Good example of that is like Apprider is smaller than Paige's rider in terms of like size. It has more React, but it has less Nexches. So like React is doing more of what Nexches was doing before and but in in smaller size because it it just knows more about the environment.
So you can do optimizations that we couldn't do before or reuse like rendering logic, for example. Yeah, that kind of thing. Interesting in, in terms of usage with regards to the customers that you know of when it comes to peaks and traffics or just general amounts of users, what are like some cool projects that have been deployed with next year's on on reversal specifically?
It's a good question. I'm not sure if it's like any like super stand out or like what is nice to see is that there's a like a, the general distribution of like applications that we're seeing is, is way more like, well, when we started building it, obviously it was like early adopters. So like we would see like companies like MPM, for example, adopted for, for their website
and like start-ups, right? Like a lot of start-ups in, in like the Bay Area across the road, like CMS providers like, like the kind of thing at this point, what we're seeing is like the, the full like enterprise scale applications that are, are being built on, on extras as well.
And, and they're what, what was interesting to me is that like a lot of the constraints that we added already on, so like getting better development performance or better like UX, for example, like adding guard rails for, for like certain UX problems. They, they all exist in larger apps as well. Like it's not just the, the smaller like apps that you were working with back then. They like everyone is benefiting from this you Bristol website to
your like message corporation. And yeah, it's just like, it's really nice to see that people are like productive with it, but also got like relatively good like outcomes in in performance and user experience, that's all. Yeah, it makes a little sense. I mean, I know you were there like very, very early on and now we're here, we're probably the organization has grown a hundredfold. I don't even know how much when it also comes to the amount of engineers that are there.
How's your role kind of evolved from where it started to what it is now? Yeah. So I started when I joined for Sale, it was I think like 10:00-ish people or something. I can't remember exactly like what number agendas but if you ever add the light is. Blinking. The light is flickered. Yeah. Give me one SEC, Edward. Is that something we can do something about? All of a sudden, it started flickering. It stopped. Stopped. It fixed itself. It fixed itself.
But yeah, you were around the ploy #10 you mentioned. Yeah, they can redo that part if it's probably better. Yeah. So, yeah, I, I can't remember exactly. So I joined seven years ago. It was the like, like it was only 10 people or so. I can't remember what number I was to the agendas, but we're at I think over 500 people now or something. So massive expansion in in company size. Now people think like 500 people working on next chest like what
is this rain work? But there there's a lot of the Nexus team itself. It's around like if you count Turbopack as well, it's like 20 ish people at this point. Around 10 working on on next chest and it includes like managers and people work on triaging on like actually fixing bugs and adding new features. And we, we just hire like a really good team right on next shows. But that's not all of our engineering right out. Of yeah, so that's, that's like out of 500.
So that's only 20 people. And then like the rest is like engineering for for for sale platform. So it's like the the infrastructure, the like site reliability, the like marketing, like sales, like that kind of thing. Like we, we build out the whole organization, right? Like so it's very like professional company now like we have like legal team, like communications, like everything you could think of basically for like a business of our skill and security team also very
important they're. Also really good, so it's really awesome to see. Like just like the, the like everything around the company, like professionalizing way more over the last like five years or so, like as we started growing more and more. And yeah, so I, I joined very early and like the, to answer your question on like what, what
changed? I, I think was like the, the like I, when I joined, I had to do everything, which which meant like literally everything you could think of included like replying to people's emails that had like support questions for, for, for cell, but also like building out next sha. So like we had a team of like two people back then. I think it's like me and Aronoda.
And eventually that turned into just me working on it 'cause I know to start working on other things and like over time we, we start hiring like more people into the team. Got some like people that joined us interns like JJ who still works on the team and they like basically in the in the end, like we, we know the firing him and, and like some other people like this. I think like we were 3-4 people back then working on next to us kind of switched roles a few
times. So back then I switched to being like doing more of management type things. There was just like a lot of need to to gather this feedback from like these, this like increasing usage of of customers and like just general like Nexus users, right? Like back then, especially like you wouldn't see like every company like default to say, we're going to consider for sale this thing that we've never heard of that the buildest thing that we're like so happened to be using.
But over time that that shifted quite a bit and then we we eventually like hired a a. Manager for the team because I, I was also like, I kind of need more help, even if I just say as like doing manager or technique type work. And so, so that over time we just end up like hiring the people that we needed. So that could be people working
on engineering or management. And in the end, like for me, that meant like switching to the manager role a few times, but also going back and helping out on on rolling out certain Nexus features. And it's for example like Apprider and in Turbo pack helped quite a bit there doing like actual. Coding as well it. Sounds like a lot of fun that you can also kind of have the flexibility to move around now. Yeah. That, that was not always the case, obviously.
And like there, there was a lot of like, like I had to be involved in some way. And now we're at the point where we have like a really good like engineer manager Jimmy, if you ever have like feedback about next Shaz, just retire to Jimmy as well or to me like doesn't matter. I'll, I'll forward it. And and it just meant that I could focus more on the, the things that like I felt were really important for next Shaz in the future.
So someone of those is Turboback and I've been helping out there quite a bit. And like Turboback is like our. The like the a replacement for the compiler that currently backs next Jest. So that means basically our goal in in short is things are too slow, we want to make it faster. That's like the really that's the really fast explanation. The slightly longer explanation is like there there's a lot of like the the size of applications are are like
growing quite heavily. So what we see is that. Every year we we end up seeing more and more code being added into applications like Chrome team and people looking at web performance, they will say there's more JavaScript in client side bundles, but also there's more code to be compiled because of that. So that means that a compiler needs to be quite optimized in order to, to process like 10s of
thousands of modules. Where as previously we saw like 10,000 modules is like quite large and like 50,000 was like, that's what Facebook is doing or something. And then now it's just like someone that's like an icon library or something like that. That's like 10,000 modules easily in in the icon library, which is really like really cool because then I can import 10,000 different icons. But also means that we have to process like quite a lot of code
in order to make that work. And, and if you're like, not super into this, like it, it might sound like this thing called tree shaking. I've heard of this before. Like it can get rid of all the code, right? And that's true. But in order to get rid of the code, we first need to know about the code, which means that we need to process all of it. So there's like one of the the downsides of like building like a a compiler bundler for for JavaScript and like the overall ecosystem, but.
Yeah, we we've started building something that is looking really good at this point. It's much faster than the than like Nexus before. So that that's like, I think like so far we've made a 50% improvement on cold, cold compilation. So that means like if you're using day-to-day, 50% faster initial compiles. So that means like going to a page like opening it for the first time, then it compiles it, and then there's the.
The incremental changes is where the the real like magic happens, which is that anytime you make a change to like say a CSS file or like a JavaScript file, it needs to recompile that change and like apply it to your to your app. And that is now in many cases under 100 milliseconds, whereas. Previously it could take like 1-2 seconds sometimes. So we, we saw for like our own apps, we saw up to 96% like
faster. So it's like going from like seconds to to a few milliseconds for for a lot of those changes. Incredible. Yeah. And it's, it's like The thing is like in, in like all those years, the, the thing I've heard the most is like Nexus is great, but actually it's quite like slow for, for compilation. And that's what we're fixing, basically. Yeah, yeah, that makes a lot of sense.
When you were in, let's say those more managerial roles and the team was scaling up with regards to engineering capacity, were you also involved in hiring? Yeah. Yeah. I'm curious what you look at from that hiring standpoint because I know nowadays the market looks to be a bit more rough than it was. Let's say. I kind of think during COVID it was very much booming. People were switching jobs and there were a lot of engineers being hired, and now it's a bit more tight.
I feel like. I don't know if the same opportunities are still there, but what did you look out for back then with regards to hiring? So what we looked for and like our let's talk about the situation that we have, which is very different from from like a lot of other companies. So like we, we have like. We have an office, but in San Francisco, we have an office in New York, but we also have like a very large remote workforce.
So there's a lot of people in, in various countries all over Europe, in Asia and and like elsewhere as well. And basically like so for, for Nexus in particular, which is it doesn't apply to everyone at for sale. Let's start there. For Nexus in particular, we tried to hire adventures experts in the field as well, and they weren't always in the most beneficial locations. So that this this meant that we, we hired someone from like, say, South Korea, which is like time zone nightmare, but.
Time zone wise. So time zone wise, like the like overall, not talking about the people, I'm just talking about the time zone. It's like like overall we hired like really good people from from all over the place. And yeah, so time zone wise, like it's really hard to work with like for people here in Europe. So like we're in the Netherlands right now.
So in the Netherlands, like you have a nine hour time difference with San Francisco. So it becomes really hard to like do any collaboration with people in like in in depth like in California basically or like West Coast. So, and the reason for that is that just if you're like calculating or if you're in, in, in California and watching this is that our end of day. So like 5:00 PM is your start of the day, right? If you're in San Francisco.
So, and there's some ways to fix this or like to make it more pleasant, which is that all your meetings are at 6:00 PM or like 7:00 PM or you work at nights. But we don't want to do that. So in practice, like for me, that means we we schedule. Meetings at at like 6:00 PM usually or something like that. Five sometimes, but and and that's like beneficial because like then everyone can be there basically. But so, Oh yeah. So the situation that that we
have because I digress. So for the the Nexus team in particular and the Serbic team as well, there's a bunch of people in Europe, there's a bunch of people in the US, but also like kind of spread over the US. So that means in multiple time zones in the US, but that in general you can think of that as like 6 hour time distances. Here to 9 hour time difference because there's like all the times, all the other times that are in between that, so it's
like 7-8 hours. And someone in, in Canada as well, so similar thing. So first of all, we, so when I, when I was hiring, I wasn't looking at the time zone. I was just looking at because everyone's remote. Someone needs to be like they can be junior, but they have to be really driven and like continuously ask for like it would be very like open about like I I'm not I'm stuck. I need help here and then you. Can't be isolated. You can't be isolated and you can be isolated if you're more
like senior basically. So we ended up hiring a bunch of people that were either really good at like calling out that they were stuck and needed help because they were remote and you're not in office. So you just, you just can't see that they're stuck in in any way. And or you can notice it at some point, but like that, that's
besides the point. So in, in the end, like we, we start looking for people that were like, could perform really well in their like, like heart problems being given to them and they, they can figure it out either by themselves or like know how to ask the questions to get it solved. And that like works really well for next chefs. That definitely wasn't the case or like that that definitely wasn't like for all of herself per SE. It was just like for us, that worked the best.
We heard a bunch of people concerning to open source, sometimes other open source projects as well that that like works on on similar like problem space. So a good example of that is is Joe.
He goes by timer online. If you've never heard of him, you, you probably thank like if you use React like you can probably thank him for for a lot of getting knowledge about React 'cause he, he helped maintain create next app or create React app and create React app was used by Prince everyone to learn React, right? So, so he worked on that. But create react app is very similar to indexes in in a way that like has similar compiler, similar bundler like it had all
the same problems. And, and he was working like an aero overlay that made like react errors a bit better. So we, we hired him from like doing that and like working and like working the team like early on was, was just like, we tried to hire like the most senior people just because they had the experience to, to start like levelling up. Next, shells basically. And then we hired some some like more junior folks, at least at the time, like they're, they're
really good now. Like they, they know a lot more than they did back then. So like we would get like drive by contributors, right? So like thing that that happens to open sources is that you get some like one person that opens one PR and then they're gone basically, right. So usually they have like this this squiggly image that. There's like a default in get up. And they're you're like nowadays, you're like, this is
AI just something like that. But but McDaniel is like, I this must be some person that that wants to be anonymous or something like that. But there's a few people that usually that you see that will start contributing more. So they they do one PR and then like you land APR and they're like awesome, I want to do more. And like they just start adding like more like changes into next jazz. And JJ was a good example of that. He would pick up like heart problems, like out of the just
out of the repo. And witches are doing that, that that's kind of like you, you like we as maintainers see that. And they were like, this is awesome because like this is the thing that I wanted to do for a really long time, but I just never had the time. And so I reached out to him and I was like, what do you work on? He's like, I'm a student. Like I, he was like, I'm not sure what he was studying, but he wasn't even studying computer science, I think.
And, and yeah, so they like, I just reached out. I was like, hey, well, like, what are you, what are you working on? And why are you even contributing to the next test? Then basically it was like, yeah, I just find it cool. And then started like helping out. I was like, if you want to do an internship at some point, like let me know because we can
probably work something out. And then like he he joined as an intern pretty soon after that really like he was like he was able to do that next to the school I think or something like that. Then eventually I think he still like graduated and like after that joined for sale full time. Really nice. I. Think that still works? Like the the level of contribution to open source eventually landing you an internship or maybe even a job nowadays.
It depends because like I I don't know if the like if contributing to open source is like appealing to to a company that is. Is not particularly focused on that, right. Like I, I was very. So for me personally, I was contributing to open source because I just liked it and I was I was like 19 and I, I just had a lot of time like I had so much time and I didn't do
partying or anything like that. So I was just like on my laptop all the time continuously coding sounds very boring to most people probably, but I really like doing that and I, I just
learned a lot from doing that. So like I, I learned true like 2 two things that I learned a lot true, which was like I, I worked at an agency and I joined that full time like after I finished school when I was 18 and then I so there was a person there, Dwayne, she watches this at some point who, who was like, it was like university computer science, like masters or
something like that. It was the like, yeah, that's like the, the highest level of computer science you can do here, I think in the Netherlands. And so he had all this like crazy computer science, like, I don't know, like, like PHP, like design feather and stuff. And I don't know, like he and I was just like, this is kind kind of interesting and like he noticed. That at some point. It was pretty young. I saw I think it was like 25 or something, but he noticed that
it was something. It was just like, it's basically like every time he was doing something, it was like I come Luke because we were in office. That's what I miss about office really. But the he was like come Luke and like have a look here. Look, this is like some pattern to do this thing or this is like how you use like no jazz or that kind of thing. And like that really helped a lot because I didn't do it like CS degree here at all.
I just decided to start working there and, and in the end that was like super helpful. And then like the other thing was that like when I got home. After work I would start contributing to open source and like working on like side projects and and doing all kinds of like smaller contributions to to open source and like. For Nexus, that was really nice because like early on it was just like ton of bugs.
So like that you would just see like a new bug come up every day and I would just go and do it like fix it. I didn't know how to fix it. Let's mention that as well. So it's just like, I know some JavaScript. I wasn't even good at JavaScript. I think there was no TypeScript. Just to, to be clear, it's not very popular like then. And so I, I just started contributing and like trying to figure these things out. And I like to, it was kind of like, like puzzling, right?
Like creating a, like putting a puzzle together. It's like, you know, the pieces. We also don't really know how to fit them together. And you need to figure out like what the, like how they stick, they stick together and like what the right solution is. And then we know the solution. That's very fortunate to have this like this existing connection with Guillermo and the other people on the for sale team at the time where if I figured it out, I could ask them
like, hey, does this make sense? And then they were like, makes sense or they were like, doesn't make any sense. Go back and try this other thing that, that we're suggesting. And it was like for me, it was really interesting to learn from them as well because they, like, some of them also didn't have ACS degree, but they, they were just like really good programmers or really fast programmers, for example.
And like one of the like, one of the things that that was, it's also really interesting is that they, they were already successful in open source, like building good open source software that a lot of people used. So I, I was just like, Oh yeah, maybe this will at some point like be used by more people as well or like more people can get benefits from. From this, yeah.
That makes a little sense. It's interesting to me that when you say we were hiring people that don't have as much experience, you look for people that are eager but also call out when they're stuck, right? That's one of the pieces of advice that I got very early on, and I was fortunate to be in an
office space. And I also like the kind of colleagues next to me actually looking out for me and educating me when it comes to something that they really loved because that's if they have a passion for something, they share it. But the piece of advice was, well, Patrick, you've been stuck with this and I know you're stuck, but you're not like calling out for help, right? For me, traditional education kind of gears you towards figure it out yourself because that's
how you learn faster, right? If I have a question, it's like, have you looked it up yourself? Like how are you looking for the answers? Because then they might stick with you more. Whereas in an agency or even consultancy, like we're there for a job and in the end, yes, there's time for learning. But if you're stuck for a few days, then ask for help, because if someone can help you within 5 or half an hour, 5 minutes or half an hour, then that's just
more productive. So that's what you do, and that's how you learn. Faster Yeah it's even like what I found for myself at least is that when you do call it out is it one of the problems with this touch education, I think is that because I'm not sure if it's the same every hour, but is that you
would get. We do have this question like it's often like either figure it out yourself or you didn't study well enough instead of like explaining maybe you want to learn it and maybe you don't want to learn right. Especially in high school I had a lot of things that was just like, why am I learning This doesn't make any sense Montreux
anything under bus. But languages is like I know why they're useful for some people, but I I just thought like I did really well in in English, but like every other language that they teach you here like I was super bad at and it wasn't because I probably it wasn't because I couldn't learn it, but it just wasn't interesting. And yeah. So that was the, the thing that you learn like once you start working in office, for example, it's like your colleagues are
not out to get you in a way. And they, you can ask them questions and they, they will try to answer it or they will be like, don't really have time, but you can ask this other person, right? Or things like. That they will always help. And yeah, 'cause like in the end, like everyone benefits, right? And like some what I, what I find like working in an agency and I was pretty young, like I was 1819, is that like everyone
was pretty happy to help. But also at some point like people start asking me the questions, right? Like the, like other people that joined later were like, how do I do this thing or how do I do that thing? Or like I set up this like it wasn't a framework, but it was like a tool to set up like development environments internally. And, and in the end, like I was just running all of those like development environments for everyone to make them more efficient.
So yeah, it's definitely interesting. And like that's what we tried to look for early on. And like over time, obviously like our like hiring got way more professional as well. So we we have like a full interview process. Now. We have like some like interview where you have to show like technical skill, that kind of thing.
But in in practice, it yeah, like the the the thing that we were looking for at the time when when I was a manager was was just like people that could execute really well, but and that could bring something new to the team as well, right. So it wasn't like things that I could not do myself basically that that would be the the most like helpful. So like we like a good example of that as we hired to be us who we created webpack to, to work on Wepack full time.
Basically like that that was basic. Like we, we were like, here's money to start building foreign into into wepack. But also I have these asks for you that that are just like not getting resolved at the time. And there was like a lot of Iran performance and like I, I was pretty good at finding performance issues.
So I was like pointing to things and, and to me, this is really good at like measuring, like measuring like this, like performance, but but also coming up with solutions that are things that I would just never have thought of. And like he, he did a pretty good CS degree as well. So, so I know where my limits are as well personally and where like other people can help out quite a lot. And like, obviously, I'll learn quite a lot from them as well
through that process, yeah. That's the best, yeah. That you can look up to that can teach you something and that bring like something new to the table. Yeah, like, it's a lot of fun as well working with, first of all, like I, I like working remotely because I get to experience also people's other cultures, right? You get a very diverse team rather than being in a team with only, for example, Dutch people
like it's, it's different. I've had that very early at the start of my career and then I joined another team and it had still in office but people from like 8 different cultural backgrounds and I was like, I'm learning a lot professionally but also like culturally and personally. Definitely. That was a lot of fun and then nowadays since you can work remote like the step to do that, it's just easier. The only challenge is indeed like time zones is definitely a thing.
Never thought of that. And I've never worked with kind of nine hour differences. Either way, that's insane, Yeah.
Yeah, since the times as are the the hardest, I think, yeah, one one of the coolest things of, of working at Purcell is that we have such like the multicultural team and even just like, yeah, like being Dutch, like you don't see a lot of the road like growing up per SE. And it's just like, like, I don't know, like people in the US have such a different wreck ethic compared to people here in the Netherlands at least. And this is really like interesting to see that.
But we we had so many different cultures, like from Japan, and I got to experience a lot of it as well because I was able to travel to most of these places where people were. That was really cool as well. Yeah. Nice. I was wondering because I kind of as a last thought, I know traditionally software used to have, I think mostly kind of a license model. And nowadays we have this kind of product LED open source part,
right? They call it open core next year is there with versos kind of the the profit model.
And I've also seen companies try and do this, solve this chicken egg problem where they have something popular open source, They try and build a product around it to make it run easier and then try and find customers there or people that already have a business with customers, but they want to kind of explode it. So they need that community part and they try and open source something, but I haven't seen it work out as well as next year's and versus specifically.
I don't know why it worked out like it. It has basically, but I think it has a lot to do with kind of right time, right place and listening a lot to kind of what the market needs. Where do you think web development is going to evolve specifically with frameworks? Because for me, next year's was there. There's always many different frameworks. You have the more standard ones, but now you're also seeing meta frameworks kind of being created as well.
And even another cycle of that. I'm not sure if people are losing sight of like fundamentals in JavaScript, which you definitely still need, but things are getting more abstraction layers I feel like more and more. You know, like a big part of the abstraction layers is also that things are getting more complicated and not more complicated in in like a bad way. It's just that like there's more demands for more interactive apps or like websites or anything like that.
There's just like, yeah, there's been a lot of development in this like going from 2016 when I released Next Jazz, like, like I would have, would have not expected like, well, it's JavaScript framework. So maybe you could have expected. There's like many, many different frameworks now and many different UI libraries and like everyone trying to get their own big flavour of it.
But I, I also, I mean like personally, because I, I saw, I saw that like cycle of, of like React coming up and like, I don't know, jQuery and others being used less and, and all that. And I also didn't expect the, the, the current wave of frameworks to last this long initially at least. It seems like that that like, like this whole model of having a component layer doesn't matter which library you're using to create a component layer.
It's really like stuck around and, and like, what has been interesting is that like Reacts in view have stayed so popular over time basically and, and grown in adoption. Not like basically it's, it's similar to how you see like Jacery still being around. So like even if you look like 10 years ahead, it could be that like it's still, it's still the most popular solution. And like it's evolved over time.
And obviously there's new, there's new shifts in all those frameworks as well, like more server first or server driven UIS, so like React server components, for example, that kind of thing. And they see a lot of you also see just like a lot more like capital going into all these frameworks as well. I think that's a good thing overall. It it like it causes a like feedback loop of like you're doing it better than us. So we're going to make it just as good type thing or better
than what it was. I think it's really hard for like new frameworks to come in like to get into this adoption space. So because the, the problem is that once you build something new, it needs to be like 10X better than what it was before. And it may be like AI is going to help here. Like your, your framework is more optimized for the new thing that's coming up. So it's AI or crypto or Webtree, that kind of thing or or the existing frameworks already support what you're doing and
that. They can have pace you. Not per SE based on like just resources, for example, because I, I definitely think that you could build a framework like next to us yourself, but but it needs a certain like type of like support and Polish over time.
So like what we've seen is like as the team has grown, like the user base has grown like like 100 or 1000 X plus, if not more, probably more actually like 1000 X is still on 20 people still like, yeah, but so that's not, it's way more than that even. So like that what we see is that per user that's using it, we we have like a relatively limit, limited amount of people working on on the framework. Obviously, if you're building a framework like from scratch, you don't have users.
So you don't have to worry about anything. So you don't have to worry about breaking changes, for example, or like new, new releases or are you releasing too often? Are you releasing too little that that kind of thing.
And yeah, so that makes it harder to to start like a new thing in, in the space that if you want to that The thing is like, do you really want to make it like that large, like that large adoption, especially if you're like one person that might not be what, what you want per SE, right? Because it it might be that you get burnt out on the the amount of like questions you get from people or like support requests that you get on on your give issues.
But also if you're building it for, for like just your own, like I'm building my own website or I'm building my own app and like I have this framework because I need to have this framework, then it makes a lot more sense to, to work on it. And that's what like to add here. Like that was what Versal was doing. Versal was just building it for themselves. We, we needed it for our own website or on blog, our own, like like dashboards, that kind of thing.
And we're still using it today. Like that app is literally 8 years old and, and it's gone through all these like iterations of all the different versions and, and like using Turbopack now as well. So like a lot of the incentive that a lot of times, like I see people saying like the incentive for, for sales to sell you more hosting, but there's a lot of incentive for us to make Nexus better for just our own people working on it. And, and we're making everything
more efficient as well. Like we're making the compilation faster, we're making rendering faster, like that kind of thing. So there's a lot of like work to be done basically on making like everything that you're using faster. I think like we're, we're seeing similar things for, for like all other like libraries, frameworks out there. And some created the company around it, which I think is a good thing. It's just, yeah, like the, the business model that For Sale has
is very unique. I think 'cause it's not based on like having you use Nexchass per SE. So like the, the business itself is not a like Nexchass Enterprise IT like Nexus Enterprise Edition in the, in the sense of like Magento Enterprise Edition or things like that where you get particular features that are only available on Versailles that are part of the framework.
And that is one of the strengths as well that we've seen like over time, we're working with like a, a bunch of different like cloud providers now to, to create like a, a deeper integration into like their particular like hosting environment as well. That's really nice. I, I wouldn't, wouldn't have thought that that would be like a big benefit specifically, right?
But it makes sense that, I mean, a lot of enterprise software or at least enterprise editions, what I've seen is indeed they nudge you with specific features to then get a paid version basically, right? They lock you in with a free model and then you go more towards the paid version. But I think as long as the company has people that basically sees adoption, see usage and then are like, but we can do it faster or we can optimize it more, right?
I think it makes people more happy from a usage standpoint, from something they deliver from both sides. If adoption creates happiness, then also that is kind of that piece of fulfilment that you want and it's not only financially driven, which I think is valuable.
Well, we see at least what I've seen a lot is that like the, the people that come to us, they're, they're often more so like, hey, we have the scaling problem, not the, not the, hey, we have this Nexus problem per SE. So it's more like for we're under such large loads over time like that, that we're, that we could, we could hire like your entire team in terms of like DevOps people to, to keep it online, basically that kind of
thing. And that's where that's what I find really interesting about it because like that, like that, they don't come to us because we obviously because we host Nexus really well and like the, your app is really fast put in for sale. But what we see in like some customers is that they, they like it because they get preview environments and they can send it to to their colleagues or to
their like customers as well. Or they, they just like the, the performance of the production environment or they like not having to set up their servers or, or things like that. And we can do everything we can to make sure that like your app stays performant as well. So like monitoring tooling and things like that that that are being added into the platform as well. Yeah, absolutely, absolutely.
Thanks for coming on, Tim. This was a real blast learning from how you started and kind of how things have grown it. It must be insane, like you started so early and how big things have gotten now. Thank you so much for coming on and sharing. Is there anything you still want to share before we round off? Just that if you want to learn exhaust and like you're, you're interested in that there, there's a really good learn course on the website that that
is fully free. Like we're just giving it away. That is like really interactive. So like, what I like personally is that I learned a lot by doing, like I said, like I learned JavaScript and like better getting better at programming by going to regret of issues. But I also like that like art tutorial is really like
interactive. So you're building an app or like a website that is. It's like just like as you go through the course, you you just like get something real basically that you can deploy in the end. Yeah. Awesome, send it to me, I'll make sure it's in the description. Yeah, it's just next to. Doris has learned. Yeah. Perfect, we'll do that then. Thank you so much for listening. If you're still around, leave a
like. If you'd like to leave a comment and let us know what you think of the episode, we'll see you on the next one.