Episode 63 - Free
Daniel Roe: It doesn't have to come from the next team because these modules can do anything. In fact, a lot of nuxt code is actually written as internal modules. Most significant changes we make to nuxt start out as modules to test them. So it's not it, like everything that we use is exposed for anyone to use.
That is a hu has made a huge difference.
Justin Bennett: Hey, everyone. We wanted to announce a small change to the podcast, so we're really excited to share with you that we have a corporate sponsor now. We would like to thank Raycast for sponsoring our podcast. I'm gonna hand it over to Andrew to share a little bit more about what some of these changes mean.
Andrew Lisowski: So over the past year, we've had a free and paid version of the podcast. The free version usually cuts out 10 to 15 minutes of content thanks to the sponsor. We'll no longer be doing that! The paid version will just have the ads removed.
We're also excited to announce that by partnering with Raycast, we'll be able to bring you weekly episodes of Dev Tools fm, so you'll get twice as much content as you're used to.
Justin Bennett: we would again, like to thank all of our Patreon sponsors. You've really helped us get to this point, so we really appreciate you. Uh, we have a 30% discount code for you for any merch if you'd like to buy stickers or something. Uh, again, thank you so much, uh, and we hope you enjoy listening to the podcast going forward.
Andrew Lisowski: And if you yourself, are a business that's interested in sponsoring the podcast, head to Dev tools fm slash sponsor apply.
Hello. Welcome to the Dev tools FM podcast. This is a podcast about developer tools and the people who make 'em. I'm Andrew, and this is my co-host justin Andrew and this is my co-host Justin.
Justin Bennett:
Hey everyone. Uh, we're really excited today to have Daniel Rowe on. Uh, so Daniel leads the next, or sorry, the nust core team. the nuxt core team, uh, next is a, is an incredible project. Been following along with that for a while.
Really love to see it. Um, so you've done a lot of things, Daniel. Uh, but instead of me reading your bio, would you like to tell our listeners more, a little bit more about yourself?
[00:01:57] Daniel's Background
Daniel Roe: well, uh, yeah, thank, thank you for the, the welcome and the, um, the job expansion as well. Um, and, uh, sure. Yeah. So a little bit about myself. So I was born at a, at a very young age and, um, basically, basically uh, didn't do any, any real programming at that point. Um, I guess, um, uh, my career path has followed a very different path, um, than I, I think even I might have expected.
So I liked lots of different things in, in, in school, um, and, and did bits of hobby programming here and there, visual basic and that kind of thing. But I, I, I went to university and I studied law, which I loved, loved arguing, debating, citing, uh, precedents and, uh, moot court, that kind of thing. Uh, and then actually I worked for a church.
I was a sort of jack of all trades, um, parish assistant. Um, I was called for, for, for a year and then actually went to, uh, seminary Theological College and studied, um, got a, degree there and then, uh, then, then became a, a church leader in, in the uk. Um, and then, um, when the, the time, uh, came to do something different, I started a, a creative agency, uh, with my dad and my wife and uh, and that was all about finding the right words.
So it was all focused on writing, which is another great love of
mine. And then we gradually started doing a little bit more coding because that was really the other half of figuring out someone's brand and messages actually to implement it. So I, I did that 'cause I could, so I was, I was doing logos and branding and sort of building people sites, um, and just gradually got, back into, into coding and, uh, and, and obviously helped out by contributing back to the projects we were using.
and then just it feels like a couple of years, uh, passed and, and, and somehow I'm, I'm, I'm, you know, uh, heading, heading up nuxt, which, which feels, feels a bit, bit crazy. I'm not, not really sure sometimes that's really true. But, uh, but tell like that's, that's a, that, that's a strange journey, right?
That's, that's, that's not what you would
Justin Bennett: Yeah. That's cool. I mean, this is the, this is the fun thing about hearing people, especially I think this is especially true of the people who get involved in open source is that there are just a lot of really interesting background stories and, and I don't know this one. Yeah, yours is really cool.
Andrew Lisowski: It's always, always inspiring to hear people that, uh, started in one place and ended up in coding somehow. I was reading a tweet yesterday where somebody was like, yeah, coding compared to like the other sciences in math is like, is like easy space. Like you could, you could study for like two years and then get into this space.
It's nothing like hardcore mathematics. So, yeah, I, I love how fun and inviting it is. It's
Daniel Roe: basically just, it's magic with thoughts
thoughts So anything you can think about, you can make true. So that's pretty, that's pretty cool and amazing. And basically from the moment you can think of it, you can make it, you can figure out how to make it real because almost everything is possible. So I, it's just, it's a sort of, I think it's very inviting because it is so immediate, like the, the, um, and, and the gap between having real, tangible reward for what you're doing is so, Um, uh, the gap is so small, so you, because almost, and particularly I think that's true with web development, you know, it's, it's harder when you're sort of building native apps and things like that.
But, but even there, like, as you say, you know, you might study for two years. I think you could have to study for two years, you know, you could, you can get real results within a matter of days or hours even. And then it's reward, a cycle of reward. So, um, you, you have something great and you wanna make something else and then you, you have to learn something to do it, but it doesn't feel like at work because you immediately get the reward of the thing that you wanted to do.
Justin Bennett: And so it's just this a wonderful virtuous cycle I think So we'd like to thank Raycast for sponsoring our podcast. If you haven't heard of raycast, it's an app for Mac that's like Spotlight, but with superpowers. You can do all the same things you do in Spotlight quickly, opening files, URLs, but also has a lot of other cool features like clipboard history, window management, schedule overview, which I personally love and a lot of other stuff.
It's also got a really, really great react based extension, a p i, which is super cool.
Andrew Lisowski: yeah, So what extensions have you been working into your workflow lately?
Justin Bennett: I've really enjoyed the scheduling extension in particular, so it has this functionality where it essentially hooks up to your calendar and you can have a key binding that basically takes you into your next meeting. And I find that super, super useful.
Andrew Lisowski: In a similar vein, I'm finding the built-in reminders extension really useful. I love that you can just like pop into the Mac OSS defaults and it feels like it's native.
Justin Bennett: Something else I've been enjoying is Raycast ai. That's their pro functionality, but it gives you access to these built-in large language model, AI features that help you summarize notes, fix mistakes, change the tone of a highlighted phrase. The thing that I really like about this over chat based aI solutions is that it's integrated directly into your workflows. So, you know, highlight something, run a, keyboard shortcut like you do for any other extension, and then it'll activate this functionality. So it's really cool. Really, really helpful.
Andrew Lisowski: To learn more, you can visit raycast.com or you can go listen to episode 38 where we talk with the C e o Thomas about the product.
[00:07:28] Design vs Dev
Justin Bennett: I am curious because you were working in an agency and you did some design work, um, and then you came into programming again through that, even though you had done some hobby programming earlier in, earlier in your life. Um, what are the, do you, do you think there are parallels between the, the design process and the like programming process from just like a purely, you know, you're talking about that like rich reward that you get of like, you know, having an idea and bringing something in life.
And sometimes I think about that from the design space. It's like, it can be hard to conceptualize something and like bring a design to life, but there is like a gratifying filling there. So do you feel like there are parallels between the two?
Daniel Roe: I should say to start with, I don't think I'm a very good designer, so I think I have, uh, I have opinions, so I, I know what I like and I sort of recognize it, um, rather than knowing how to create it. So my design process was largely, you know, playing around with curves and, you know, fixing logos until I felt that sense of recognition and this is, this is right, this looks good.
And so we got to some very nice places, but it's not, 'cause I think I was a very good designer. I think it was more because I think at some point, at least one of the things that I did was okay and, uh, and, and that was how, how we got there. So I am not the person to ask about the design process because I don't think my design process was, was the way, I mean, I, I basically, this is a thousand monkeys on, you know, a thousand keyboards.
That's, that's, that's what I exemplified. Um, but I think I do look at programmers who do have really lovely design sensibilities. People like, uh, Anthony Fu has done some really great stuff. And, you know, you think at the level of this is art. Um, and, and has a sort of similar, I do think there's a, a similarity in terms of the elegance of, um, particular kinds of, of design and coding.
That there's this sort of, uh, search for the sort of the elegant, the minimal, the like, the perfect, um, choice. Um, and which I think is similar also to the choice looking for per the perfect word or, or message. Again, you're trying to come up with something that is infinitely small, you know, like a fractal, something that is perfectly the right size to, um, do what it needs to do to express something or communicate something, or obviously encoding to, to sort of do something.
Um, and, and sort of with like with a message, it's, it's fractal because you can zoom into it so a message can take. You know, 10 seconds, but you could talk about it for 20 minutes or an hour, or you could give a day's workshop on it. Um, because it has this sort of fractal quality and I think, um, sort of identifying something like that is the same kind of thing that programmers, I think, are trying to do when they try and make something generic or reusable or, you know, not just for the specific use case, but something that might be bigger.
I think it's the same, same mental leap that's happening. I dunno if that answers your question at all, because as I said, I'm not the right, right person to speak to the same process. What, what do you, what do you find, what's, what's your take?
Justin Bennett: It's a good question. I mean, I think all creative endeavors have a similar sort of echo. it just depends on what you, you lean towards, right? Because it's like the level of effort. So you, you're talking about like programming, like yielding these rich rewards and, and this is the, the feedback cycle of like seeing what I've done come to life.
But for some people that can be really hard because there's like, there's this sort of, you know, there's a lot of steps that you have to go through. There's a lot of syntax you have to memorize. You have to do these sort of like rote rituals for this thing to work. And if that doesn't come naturally to you, then it can be a lot of friction to see something come to life.
Whereas maybe, you know, you're presented with a canvas in like Figma or something and, and that is like the world that you can really bring something to life. And, you know, I think it, it depends on for different people, but I do, I, I particularly appreciate the design developer overlap because it's such a, A, I think it's such a rare breed of person.
And the other thing that I really believe is that it's always, every time I've worked with someone who's like, can do both design and development, like pretty well, they always just have such a really creative outlook and it's just like they're, they're, I don't know, just a different breed and, and such a pleasure every time I've come across somebody like that.
I do think there's, there's something aboutthe, about what you're saying about the steps required. Um, so friction basically is the thing that makes the feedback loop longer and more tiresome, like the amount of friction, like installing a node version manager and trying to figure out how to configure, get, and like whatever levels that, like whatever the, the particular thing is, the things that are not about what you're doing.
Daniel Roe: The other things, the things that get in the way of what you're doing and stop you even from, from doing the, the basic thing that the tutorial has told you to do. Those things, I think are what, you know, stops people and the lack of, of resources or the, lack of intuitiveness of it, that kind of friction is basically the enemy of developers getting better at what they're doing.
[00:12:38] Why Vue?
Andrew Lisowski: Cool. I think that works as a really good transition into the rest of our con conversation.
you mentioned that, uh, your, your past endeavors, like with law, you enjoyed it 'cause it was a lot of arguing. Uh, the front end space is rife with arguing. Um, so let's start it off with a salient point. Uh, why do you like vue and what about vue application development speaks to you?
Daniel Roe: so I mean, it's to be boring. I think that, I mean, I think basically all of these, these different programming tools and languages and frameworks are just tools, um, in a toolbox. And so, you know, we're aspiring to be artists and, uh, crafts people. And so, you know, using one versus the other is a great thing to talk about, uh, a bad thing to make enemies, Um, why I like vue I, I like, I really, I think obviously, There's the historical reason, you know, why I picked it in the first place, but why I like it now, um, and, and why I've chosen it, um, time and time again on in lots of different projects. It's not the only thing I've I work in, but, um, I really like how vue mirrors the primitive languages of web.
So things like HTML CSS and JavaScript are sort of mirrored in a single file component in vue. So, um, again, so for example, when I had an, an agency onboarding a new, um, new developer who hadn't used a view or react or, or any, um, framework, um, I could tell them to write HTML CSS and JavaScript and, and literally there would be a little bit more work required so we could, we could wire up the HTML they wrote and simplify it, make it actually.
Clearer. Um, but basically what they wrote would be, would work, it would be the same thing. And that's a great, like immediate reduction of friction. And, and also the other way, you know, someone's who's working in vue can go back, I think, to use some of those things. So there's, I think you see a sort of tendency in view developers, for example, to pick not CSS and JSS frameworks, but frameworks that just output c ss s and there's this sort of feeling like we want to go back to the, these sort of three core, um, primitives of the web.
and I, I really like that. I think that feels, feels nice, nice to me it's, it's how I like to, to think. Um, I mean I think there are other really, really nice things about vue in terms of, of how the framework works. I like the fact that it's not a sort of perpetual re-render cycle. Um, I, I like the fact that you have component instances.
I really like the new composable architecture. Um, I also really like the community, so the vue community is, is a really positive and friendly one. Um, it's very international, so you have people, um, using vue all over the world. And I think maybe that's been the case from the very beginning. And again, this is the kind of thing that just happens by, um, sort of historical accident in terms of who picks up something and where the, the groups of, of Keen users ended up being in the early days.
Um, but yeah, the vue community is just, it's ab it's just lovely. Um, and because it's not the biggest community, obviously the React gets the, that particular, um, gold Star. but because vue isn't the biggest community, it's also therefore a little bit closer knit. And so you can, there's a, a feeling of, you know, we're, we're friends here.
I'm not by the way saying any of this is not true of other groups, but it's definitely, there's a, definitely things lack about you.
Yeah, I, I definitely agree with the community point 'cause like while React is really siloed in companies and meeting companies, needs vue isn't really attached to a company. It's more of like an open source collaboration between a lot of people. It's, I think it's pioneered, um, uh, Evan's sort of governance model for vue and trying to figure out how that, that is sustainable, um, has, has sort of shaped how other open source projects also have, have, um, sort of sought to make themselves sustainable. Um, and yes, he's not sought to commercialize it.
I'm sure if Evan had chosen to, he could have made a vue, probably much more profitable in some ways, but probably also lost this, this feeling of being a community project. 'cause because you're right, vue is not, it's not, there is no company that it's associated with. Nobody has hired Evan. Um, I'm sure he wouldn't have any difficulty with that if he wanted to, but if you has kept its independence and has kept it, sort of feel like this is a, a project, you know, of the people, uh, for the people, um, uh, by the people, you know, so it's, it's, is a, it is a nice,
Justin Bennett: yeah. when I first sort of getting in the framework scene, I had learned a little bit about React and, and, you know, I had the, the sort of like quintessential turnoff of J S X that a lot of people had in the early days of React. Um, and I, I sort of got into vue because of the template file, uh, the, the single file components also, that was a.
For me at the time, working with designers who could like prototype everything in html, JavaScript, CSS is like, you know, they, I could say, Hey, here's the general format and same thing, they'd, they'd give me the, the, the file and I can make that a component really easily. And then when I tried the, tried to talk through like a React component, they were like, what is this shit?
Like, like, don't, don't show me this. Uh, so when I moved to New York, I was actually, uh, helped organize the view J S NYC, uh, meetup for a while. And, and it is such a great community. I, I think to another point of what you said, the internationalization in a large part, you know, they had translations in their docs really, really, really early on.
You know, I think earlier than a lot of frameworks were really doing that. So that, and the good docs and the just comprehensive ecosystem out of the box, all those things were, were huge for you.
Daniel Roe: Yeah, and I do, I think there, there are, I mean, there are some other things too. I mean, you see the, um, there's, there's often a chosen, chosen way, uh, path. So there's, you know, a single vue router. There's, uh, there was ux, single store. Not that these things are, are universal, but even now, for example, there's, uh, Pena, uh, which is the successive ux.
but it's not the only one. There's Harlem, for example. You can actually vue x still works. but there is this kind of blessed path that, um, that there is, there's this sort of first party, um, it works, it, you know, fits in with the ecosystem. Um, you can choose other things, but you don't have to be paralyzed by choice when you're starting a new project.
And that is, that is, I think, talking about friction, that is one of the, the key things I think that keeps developers building quickly. and I think is one of the, the reasons Tailwind, for example, is such a, um, a loved, uh, choice that people just don't have to make choices. They don't have to, um, oh, how are we going to set up the CSS tokens for this project?
Oh, you're a new, you're new. Okay, well let's spend some time familiarizing you with the unique way we do things here. But you don't have that anymore. So, you know, tailwind just. you have, you have a, a sort of easier path in. Um, and I think you have that by default with view because of, you know, the fact that the, the routing and the, the state management, um, and there, there are lots of other libraries as well that fall into that kind of category, whereas it's a sort of, you have choice, but, um, if you, if you're not looking to do something different, there is a, a, a, a well paved road, um, going, going, um, going down whatever path you want to take.
[00:20:22] What's Nuxt?
Andrew Lisowski: I think another tool that really exemplifies that is prettier. It's like we used to argue about formatting. Now we don't, there's no configuration. We can't argue anymore. Um, So speaking of like provided workflows and tools that, uh, help pro help with that friction problem, you keep talking about, uh, what is nuxt and why would I wanna use it?
And then as a person who doesn't ever touch vue, how's it related to next?
Daniel Roe: So, well, it is, nuxt as a framework for building web apps. Uh, so, and it's based on, on vue So it uses vue for the front end, uh, part. it also has a server, a framework, uh, called Nitro that we built for it, which is now being used by other frameworks as well. Um, so there's a, an, um, angular framework, uh, meta framework called analog, which is built on, on Nitro too, and we're really eager to collaborate with, with other, other frameworks.
so, uh, nuxt is, is I guess similar to next in, in some of the things that you might look for. Uh, so it's, it's a meta framework that is so, it, it will basically, aim to abstract away a lot of the pain of working with a, building a modern web app. So, in the early days, that was the pain of configuring a web pack, your web pack, uh, installation.
That's not something people probably even remember these days. Uh, but it was, it was a real, real pain point, um, back, back in the, in the day. Um, now vite is our, our default bundler, but, but again, nuxt takes care of configuring it and making things just work. So it makes things work like server-side rendering.
Um, seo just works, um, routing. So you, you just create pages in a pages directory and that works. one of the big things for nuxt three has been just making TypeScript work. So, um, again, you have, um, things just sort of have the right type, um, type inference works with, uh, so for example, the kind of thing we can do, because it's a meta framework, you create a server route in your application.
we actually set it up so that when you are ma making a, a fetch request to that server route, you get the right type return type of that server route in the front end component where you are using it. So you, you have sort of end-to-end type safety just out of the box, um, without having to do anything at all.
Um, we do other, other things as well, sort of performance optimized things. So we, we make a lot of utilities available to you that you can just use anywhere, but rather than register those things globally, we auto import them where they're needed, which means that when you are building, um, nuxt is a kind of framework that basically evaporates out if it's, if you don't need it, it's not in your build.
and so that's, that's quite a nice sort of approach that, that really was made possible by vue three's. Pattern of, uh, of composable utilities, the com sort of a composable architecture. So, and we use that in, in not just the front end part of nuxt, but also in the server side. So basically we, we make all of the, the sort of this smorgasbord of, of what you might want to do, um, available to you and then just, just what you need is, is actually part of your, your final site.
but yes, it, it does a lot of things. it covers, everything from the, the server side to the sort of browser side to the building and bundling in between.
Andrew Lisowski: what made the TypeScript integration hard?
Daniel Roe: well, honestly, I wouldn't say it was, it wasn't super hard, but it's just a lot of glue. So, uh, stuff. And, and as much as possible, I mean, best practices, you don't want the framework to be doing, you want it to be doing as little as possible. You want TypeScript to be doing the work. So, um, some, some of the things we had, um, so our, a server framework, for example, has, uh, some really nice conventions.
So it's called H three. And, um, it's, it's like a, a modern version of express. Um, that's what I mean by sort of server framework. Uh, it, it, for, for example, if you're returning json, which is by far the normal thing to do, you just return an object and it, it handles stringing that and adding the right content type headers and sort of returning it.
But because you're directly returning an object, it actually means that the return type of, the func of the endpoint is just actually the return type of the function. So we don't have to do any magic, we just have to tell type script that the return type of the, uh, path like four slash a p I route.
Matches the return type of this function. In fact, this import. So we just, it literally, it's at one line for every file. Um, we, we also support sort of method matching. So like if you have a post endpoint, it might have a different return type from the get version of the same endpoint. So we also add that.
So basically that is pretty much all we do. And, um, then just some clever, um, types. Um, library, uh, type script is the worst kind, right? So it's, um, for, for, to get that kind of magic of you start typing and it starts inferring, oh, this route can only accept these methods. So if you put the wrong method in, it's going to be a type error that's really nice.
But the amount of code, like type code needed to achieve that is, is often quite, quite complex, but it's not specific to the route. It's just sort of generic library code that we wrote.
Andrew Lisowski: is it running in like a separate process or like, uh, is it just like, you don't, like nothing's run. It's not code gen, it's just like the code makes that possible.
Daniel Roe: So, um, basically there are, yeah, there are two, two pieces. So one is just TypeScript in your, in your i d e is, is, is doing the work. Um, the, there is a bit, which is, uh, generated types. And, uh, basically, uh, you'll, you can inspect them, you can have a look in the.nuxt folder in your project. Um, and that would be only changed, for example, when you create or remove a file, um, for, for the particular thing that we're talking about here.
So you create a new server endpoint, and then this new file is re uh, the, the file has a new line added to it, basically saying this endpoint matches this file. Um, then from that point onwards, you're making changes to the file. Nuxt doesn't have to write any changes because it's already told TypeScript to connect the two and everything else is just your editor inferring it from that point.
Um, so we, we really try to keep, keep that to a minimum. We do some, um, code, we do some, uh, generated types. So for example, when you are taking in environment variables into your app, we have a, a, a sort of convention of, uh, runtime configuration, which allows you to specify these are the variables that I care about.
and that means at runtime we don't just pull in all the environment variables that exist in that environment and sort of pipe them into your app. That is, would be a bad idea. but instead, um, only those variables get, get pulled in. Well, we type them. So if they come in as, um, because we all pass them, so you can pass Boolean and numbers and strings, arrays, all kinds of things via an environment variable, which is technically only a string.
Um, and, uh, and we can actually rewrite some code, gen, to say, when you're consuming it in your code, oh, this runtime config thing, it's a string. This one over here is an array of numbers. And so you, you can actually get that. And, and we, we generate that, but that's not really code you're touching much or shouldn't really, like, that's, you're not iterating on that.
You sort of set it up and then just consume it, um, as much as possible. We, um, but I mean, it's nice isn't it, to have that kind of type support automatic,
Andrew Lisowski: Sweet. That sounds really cool.
Daniel Roe: you've just told me that you, you don't, you're, you're sort of not, not, uh, of, of vue person. So I just want to get you, I just wanna demo, demo it for you and show you what it, what it, what it's like.
Andrew Lisowski: you want me over a little bit with that. Like, I, code gen is often like, I don't like having to manage something like that. So the more automatic it can be, the better. And like React has jumped through many a hoop to try to get end-to-end type safety. And I love that you guys just built it in. Like if you look at like, uh, next, the React server components are basically like a very long play to get like end-to-end type safety.
And you did it without having to like reinvent the wheel.
Daniel Roe: Um, well, thank you. I mean, I guess, we'll, we'll see what you say when you, when you, when you try it. but I mean, and, and it's interesting that, um, I mean next are obviously our closest. Sort of, um, peer, um, because next inspired Nuxt. So nuxt was created in the first place because next existed. So next, um, did exactly this thing.
It abstracted away the webpac config for React and Nuxt was the same for vue. Um, and, uh, it's been through a lot since then. So Next and Nuxt have both evolved in different directions. Um, but because we are in the same ecosystem as, as in we're facing the same problems, developers are trying to create performant web apps, we're trying to make it possible for, for them to have a good developer experience.
And we're solving the same kind of problems along the way. So we, we have a, an interesting sort of, of, um, of path of converging and diverging at times. Um, so one of the things that's very different between nuxt and next is the, uh, the, the extensibility of nuxt. So we have a modules ecosystem with nuxt, which means anyone can write code that hooks deeply into Nuxt and how it operates.
We have hooks that, that are called at lots of different points throughout the build process. Um, and it's poss when TypeScript support was first added to nuxt, it was added as a module. Um, when, uh, somebody wants to add a new authentication provider or they want to add a C M S or, um, any optimization, they can, anyone can do it.
It doesn't have to come from the next team because these modules are, um, can do anything. In fact, a lot of nuxt code is actually written as internal modules. Um, so it's, it's very, very, very buildable. Um, most significant changes we make to nuxt start out as modules to test them. So it's not it, like everything that we use is exposed for anyone to use.
Um, and that means that is a hu has made a huge difference just, um, uh, in terms of how Nuxt has grown and developed. So we have, uh, we have a modules website that indexes a lot of these modules. Developers can sort of submit PRS to our modules repo and just add their modules. So we've got hundreds and hundreds of modules, uh, for lots of different integrations that are maintained, many of them in, in a sort of nuxt community repository, but, uh, or organization.
But then there are lots and lots of, uh, of ones which are just fully third party or even entirely private. So within a company or organization, they'll have their own modules and configuration that they share and install from V P N. So I think that's, that's one of the, the interesting differences. Um, obviously at the moment, There's server components that, uh, next is, is, really championing, um, and sort of this move to the app directory.
That's, that's all fun and interesting to, to observe. I actually just published an article about, uh, nuxt server components. so, uh, we are obviously, uh, we actually had them before React, don't tell anybody. We had server components before React. Um, and ours are very different. They're implemented in a different way.
Um, but again, we are circling, we're in, in similar waters. Um, and so I think there's a lot, we have a lot to learn from each other.
Justin Bennett: Something that I've always loved about the vue ecosystem and, and sort of Evan's outlook is that, He always takes the best of everything that's happening in the ecosystem or the community really that's working in the view ecosystem in general. So, you know, when vue two came out, it was like there was a similar sort of like virtual dom implementation and you could write components in J SS X if you wanted to.
And there were these really interesting things and then S Felt came out and people were like, oh, disappearing framework Evan's like, yeah, we can do that too. And you know, they kind of come in and, you know, nuxt coming along and again taking a lot of these lessons and doing their own things. But you know, I remember the service side rendering story for review was sorted out long before React Service research rendering story was, and it's kind of interesting to hear about the, the server components thing being, uh, being done early.
Daniel Roe: I mean, even now, uh, the, the friction for React is so much harder, than for vue. So, um, so basically it's really straightforward to write, uh, like to write asynchronous code or to write data fetching into a nuxt app. Um, And, and also even for us to, to code it, like how, how it works in vue.
We, you just have an ay asynchronous setup function for the, for the component. We can have asynchronous, uh, sort of route navigation. It is not complicated, um, in, in a lot of ways. I mean, it's, it's very complicated with React. Like there's, there's a lot of, there's, there's a lot of interesting work being done to make it less complicated and make it work better, but it is, it is a lot, a lot harder.
Um, whereas I think that's not so much a problem in nuxt because of the, because of the fact that it's being built on vue and vue has a different approach to what a component is and how a component renders. Um, that means that, that we can have async set up and we can have async route navigation just out of the box.
[00:33:40] Nuxt vs Next
Justin Bennett: In the same vein, are there some other things that jump out to you that are different in Nuxt. That maybe like next can't even do just ' cause of framework differences.
Daniel Roe: so some of the things, uh, about, about, so we, we built this new server framework, um, uh, it's, it's like a server matter framework called Nitro, um, which is, then it builds on lots of other tools that we also built, uh, like H three, which is the express replacement. And, there's a, um, like a really convenient fetch wrapper, which still uses the fetch syntax, but does things like automatically pass json and um, and string of fire body and stuff like that.
And lots and lots and lots of other things. Um, but it, so here's, here's something. Um, we, we support. Basically zero config deployment to almost any provider you can think of. So zero config deployment to CloudFlare, pages to vercel, to netlify to Azure static web apps. Um, we offer some, uh, not zero config, like a w s is not zero config, but it's just a choice in your, your nuxt config, um, basically almost any provider that, um, you can think of, we support and if we don't support it, you can like configure it yourself.
Um, and that is, that is a lot of fun. The fact that it, that it, you just sort of push your site up and the C and when it builds in ci, um, nuxt can detects its environment and configures itself to build to that. So I don't think next has that. Um, I might be wrong, but that I think is a very, very nice thing.
Andrew Lisowski: yeah. Next is like the opposite, where I'm scared to move to any other provider because it's so geared towards their own backend in infra.
Daniel Roe: I think that is, that is a lot of, that's a lot of fun. Um, we're, we, we've, we've done a lot of work to try and make code that works in both worker type environments and node type environments. So we've got sort of support for Deno and BUN and, uh, CloudFlare and leg on, um, all on any sort of V eight isolate.
Um, and so we, we emulate quite a lot of node, uh, certain kinds of node stuff so that you can be using code, which does rely on, on node like it's looking at for a node request object. And so we sort of provide it with a sort of fake node request object, so the code still works. Um, and that's, that's fun.
so I think But I mean, I, you know, a lot of these things, it, it's just how it is at the moment. It's not like, um, these differences couldn't be, less over time. I think, what else, what else would you be able to do in next? So we do a lot of work in the compiler time. So we try and, and, optimize things, automatically.
So for example, I don't dunno, does next, next do this, you have to tell me, uh, we'll ex like extract Css that you use in your components and we'll inline it in HTML, so you get sort of, um, I think next does this, I think they just started doing this, didn't they? So you, you get, uh, sort of the critical CSS.
Required to render the page in line. And then we render subsequent CSS via just Css files. Um, what else do we do? We do stuff like, uh, early hints. We support writing early hint, view transitions. We, um, have view transitions, support and have actually since April. Um, and what else, what other kinds of things?
There are a lot. We have a lot of, we have a no scripts mode where you can run nuxt as a multi-page app with no, no JavaScript at all. Uh, we have support for, oh, um, our server components. We have a PR that's about to land that will let you use server components from any source. So you can have a single server, which is a sort of microservice rendering components for lots of different websites.
Um, which could be, could be quite a fun use case. I don't know. There's lots of cool stuff happening in the, in the ecosystem. I get to see a lot of it. Um, but really talented, uh, contributors doing, doing interesting things with next.
[00:37:38] Open Contribution
Andrew Lisowski: Yeah, I think that the open contribution model that you guys, and by extension vue has is re really just drives this growth and creativity where like, The innovation doesn't have to be siloed to a company or a team that's testing it out before it ships. Like you can actually iterate, you can ship cool features without having to worry about companies carrying.
Justin Bennett: one thing that I do want to ask, being that you are leading up the core team. I know that documentation is such a big part of the vue ecosystem as a whole, so I'm curious about how y'all talk about documentation internally when you're doing just day-to-day development. Is this like every change you're shipping, you're like, you have like a line items, like yeah, have we wrote documentation for this?
Or, you know, what is the culture like around documentation?
Daniel Roe: So, um, nuxt three particularly. Um, I think, so we, we rewrote nuxt entirely, uh, for nuxt three, which I, I may not have said that, but basically we took something like two years, um, two painful years, maybe even more than that, and we rewrote Nuxt from scratch. And at, during that time, N two was also not, uh, looked after to the same degree that people might have hoped for.
It was a, um, not, it was, it was a, it was a, uh, tricky time. Um, we're, we're, we're okay now, we're, we're sort of on, on a, on a good, good footing at the moment. But the, um, but we, we, we had to do a lot of rethinking, um, for a couple of reasons, not just because it was a big major version in view 3 was hugely different from view 2 and.
We didn't have primitives in view three that we needed on day one. We had to actually, um, wait until they were there. Um, but also we sort of pivoted to a new bundle vet halfway through. So a lot of things were changing as we went. Um, and so we were not documenting. So we had a, a moment where we needed to document everything and we're just working through lists to try and get stuff documented.
Even now, there are some gaps in our documentation, so I would not say, if you look at me, oh, there's a, there's a great culture of documentation in, in nuxt. I think we, we do have some great docs and I think that has been, but that has been largely, um, contributors. so we've had, um, people from the community who've documented things.
We have. Had, uh, so Nuxt Labs is a company that was founded by the same people who created Nuxt and actually a lot of, um, their team, um, joined in, in helping us document, um, some of the stuff in Nuxt, and that's really beneficial. but it's, it's difficult to document well as well as writing, writing the code parti, I mean, and if you don't do that, it's very difficult for other people to document it.
'cause the best people to document are probably the, the people who understand what it's doing are probably the ones who wrote, wrote the code in the first place. So it's, um, it's, it's, i 's
Justin Bennett: Yeah, they are different skills too, so it's, you know, maybe the person who wrote the code understands it the most, but they not, might not be able to explain it the best, so, you know.
Daniel Roe: Yeah. It's, it's a paradox, isn't it? Like, it's, it's a catch 22, I guess. It's, it's a, it's a. It's tricky. It's tricky.
[00:40:44] Nuxt Devtools
Andrew Lisowski: So one of the things that's, uh, interesting about the nuxt ecosystem is that you guys have, I'd say, probably the best developer tools around. So, uh, for our audience who might not know about them, can you explain what Nuxt dev tools are and like a, a small subset of the things they can do for you? 'cause there's a lot of things it can do.
It can do.
Daniel Roe: So, um, yeah. So next, yeah, next dev tools are, um, the, um, creation really of, of Anthony fu, who I mentioned him earlier as a, as a great artist and developer, and he's been active in the vue ecosystem for a while. He's also on the, the nuxt, uh, core team. Um, and they are, the next dev tools are within, they are, it's in, it's added by a module.
So one, one more thing that you can do with the module. It's added by a module. Um, And they are sort of, it's an iframe, it's sort of injected by an iframe in your, in your code, in your app that you view in the browser. And because it, it is injected that way. So it's not a sort of browser extension that's sort of inspecting your, your code.
It's actually part of your application. So you can do a lot of amazing things. So for example, you could, uh, pick up, uh, there's a button that's lets you select any, um, HTML in your page and it will highlight it. You can click it and it will take you to the line in your i d e in the source file that, that HTML comes from.
That's amazing. You know, if you're working on a project you're not familiar with and you want to change that, that thing that you see there, it is literally a click point and a click and you at the file that, that does that. Um, you can see a sort of, uh, interactive map of all the components in your project.
You can see which ones are used, which ones aren't used. You can even see a sort of, uh, representation of them visually. You can see all your, um, your roots in your app, um, your server APIs. Uh, you can actually log all of the events that happen, um, in your, your nuxt app, all of your, um, auto imported utilities, whenever any one of those is called, you can actually see the timing of it, how long it took to run, um, like the arguments that were passed to it.
Um, modules and integrations that users, um, add, um, can contribute their own dev tools. So it's all accessible in one place. And you can actually have, um, something that's, so for example, um, there's, uh, we have a sort of social image, um, OG image generator. It contributes its own dev tools, so you can play around with your social images and see what they look So it, it, it's basically really extensible and it is, it's pretty cool to explore. I probably am not doing it justice even. It's, it's, it's a lot of fun and, um, our sort of core inspiration for that was because we are doing so much for you. So, so there's a lot of magic in an nuxt project. We still need to allow people to inspect, like, what is happening, what, what is the exact magic that's taking place?
Um, you know, okay, there are auto imports, but which ones. Or you're transforming this code, but how are you transforming it? Um, and so next step tools basically gives you the ability to pull back the curtain and look to see what's going on under the hood. So you can expect, inspect, for example, all of the code transformations you do step by step throughout the, the, your code base.
Um, and you can, um, see, you know, what auto imported components are available and you know what their names would be and what module injected them. And you can even click through to the documentation for them. So it, as much as possible, it's about making, um, stuff visible and, and also getting rid of the friction.
So, you know, if you're actually in your app, clicking on the bit of your app and getting the documentation for it to tell you where that component came from and which module added it, and what you need to know about it. So, um, and then, you know, there's, there's, there's a lot more there. So I, the best thing to do is just is is check it out if you're, if you're curious, um, but it's.
It's, uh, I think it's, it's been really great. Anthony's done a fantastic and, and a lot of, uh, contributors, I should say, um, have done a fantastic job, um, to make, make it possible.
Justin Bennett: is really unique in the fact that you can actually have modules like hook into the dev tools too. So, um, just from the examples on the side, it's just like, yeah, you have Uno CSS or V test or something that's like integrated into the thing. That's, that's, that's pretty cool. It's huge.
Daniel Roe: some of it is just sort of, so you're, you can, yeah, as you said, you can run your unit tests in the dev tools in your app, which they are testing and actually use the app that they are testing to run the tests. So it's, it's actually literally, it is the exact environment that you want to test them in.
and you can do that. Like there's even an experimental VS code embed. I dunno if you saw that, but you can actually load VS code in the dev tools within your app and edit your app, which is hosting the VS code that you are using to edit it. I mean this total, total inception territory, you know, this is, this should not be possible, but it it is, it's pretty.
Andrew Lisowski: It's, it's almost like it makes it a video game almost. It's like traditional coding. It's like you don't really know where to look. It's like, oh, Webpacks transforming my code. There's tests in the project. If I'm like a newbie coder, I open up a project, I'm presented with a wall of files and don't know what to do.
This kind of just like contextualizes everything and puts it in one tool and honestly it's something I've, I've wanted for a while. So it's really cool to see that the vue and Nuxt ecosystem is actually like taking that and making, making the dream real instead of just like, I've seen similar ones for Webpac, but their scope is far, far, far, far less.
Daniel Roe: Um, yeah, that, I mean, that's, it's, it's, it's fun. It is, it is. It is fun to, to go that way as, as you say. Um, and I mean, a lot of it we were able to, to sort of try out. Um, so, uh, we, um, Anthony and a few others, Anthony started a, um, a client for Mastodon, um, and three others of us. Um, so there are four of us on the core team and a, a huge community of contributors over 150.
Um, built it, it's a, it's a, it's a client for, for Mastodon and it was, which is an alternative social network at Twitter. And we were doing that around about October, November last year. And actually a lot of the, the work on dev tools, I. Um, was able to be dogfooded with, with elk. Um, and actually, so we were able to try this.
So we had con contributors coming in, uh, jumping into a next project that they had never, they'd never used nuxt. Many of them had never used v ue Um, and so trying to make it accessible that the sort of, the point in click to get to the, the component they needed to edit, it's very real. Like these are sort of, um, use cases and problems that we faced when we were, we were doing it, which I think was a really nice way to develop something, um, actually to, to be facing the same, same issues.
I mean, I think developing a framework, it's easy to get sort of separated somehow to be a little bit further removed from a user of that framework. and so Elk was a chance not to, not to have that
[00:47:59] unJS
Justin Bennett: Yeah, elk is a really cool project. Um, so there's a lot of other tools in this space. Um, we, we had just wanted to highlight like one, I guess collection. There's a lot of, uh, tools labeled under like un jss. Um, so could you talk about what that group of tools is, uh, and sort of what the goals of, of those tool sets are?
Daniel Roe: So, um, as part of, uh, of building nuxt, uh, we, we needed to build other tools and libraries. So Nitro is an example. Um, some of the tools, for example, that we use to detect the environment you're in, whether it's vercel not the fire or whatever, um, tools to build for worker environments or others, sort of fetching tools, um, console tools, c l i, creation tools, lots and lots of things.
Um, we, um, we decided early on that we didn't want these to be nuxt, only. And we didn't want them to be just, we could. We, I mean, nuxt 2 was, we just had our sort of nuxt util package. Um, and then we had a sort of next contribute organization where we sort of put some packages up, but really it was nuxt contribute,
We decided we didn't want that to be the case. Um, and we actually, um, uh, created an entirely separate organization on GitHub called njss for Universal JavaScript, uh, utilities. Um, and, and as much as possible, we've sought to take things we've built for Nux and Open Source them. Um, and so we have lots of people contributing.
We have community, uh, community building stuff there that is really not next focused. Obviously next people are interested and contributing to, but we have plenty of people who are not n Who are from other frameworks and libraries. Um, and our aim is, is, is that this isn't just for us. We, we like the, I I guess a lot of people who are in open source, you know, we're about collaboration and building great stuff together, and nobody's trying to build an empire.
Um, so, and Andreas is really a chance to put our money where our mouth is and say, that's true. We want to build this together. We want to, you know, build something better together than we could build individually. Um, and so, um, yeah, and Andreas is, it's a GitHub organization and it's a, it's a project and it's a lot of, uh, a lot of packages, um, many of which, you know, you might already be using, um, but might not know about.
Andrew Lisowski: Um, you know, I was, I was looking at sort of one of the packages that, which one, it was just the other day, sort of 3 million weekly downloads. Is that a consola?
Daniel Roe: I think it might be, it be.
5 million. Yeah.
Andrew Lisowski: are all of these like, taken out of nuxt, or like, I feel like some people have like donated packages. It kind of feels like a, oh, we're a community of people maintaining JavaScript. Let's donate a package so that if I happen to go away, the package can live on.
Daniel Roe: Uh, so no. Yeah, I mean, you, you're, you're right. Not all of them have come, out of nuxt, and, and some, some were sort of developed alongside nuxt, but not necessarily taken from it. Um, so yeah, so for example, I built a, a library called Fontain, which aims to get rid of a font layout shift. So when you're swapping in a web font for the.
Default browser font. There's a, a flash because it's different size and shape, and Fontain basically aims, it takes a, an algorithm developed by the Katie Heins and the Google Chrome team, which was also then used in, uh, next fonts. But it's Katie's algorithm originally. And we, we, we did the same, um, in, in, in, in Fontaine.
and I originally built it as a module for Nuxt and then realized, actually this is generic, so it, it can be used in any framework even nuxt actually. Um, but, and, but, and Docus sous and, uh, you know, feet Press and Astro and any, take your pick. Um, it, it, it works universally. and I would say that wasn't, it wasn't taken from nuxt , it was just alongside, um, and stuff like Anthony Fu developed, uh, unplug in which is a way of creating builds, uh, plugins that run in any.
Uh, build environment so they can run in, in Webpac and roll up and es build, uh, vite, uh, and RS pack. And, and who knows if you can create a new bundle, um, we might be able to make, unplug and support it natively. Um, and so, uh, that huge, and that was really because of a need we had, which was we wanted to support both Webpac and vet as bundles for Nuxt.
But actually, um, the code and the, the project is entirely separate and is used by lots and lots of people who have nothing to do with Nux. In fact, probably unplugging is used much more in the VIT ecosystem than in, uh, in the next ecosystem. I'm not exactly sure about the proportions, but I think it would at least be as much in the V ecosystem as in the, in the next one.
So yeah, it's not just like they were taken out of nuxt. I think sometimes they were from problems we we're encountering there, but. You know, there are, there are plenty of people doing, doing things that are not, not max related and that's great.
Andrew Lisowski: Yeah, it's really cool to see that, that that particular package sounds very interesting. Uh, shifting fonts annoy, annoy me so much. I, I hate going to a website and seeing it render twice
Daniel Roe: Yeah.
I think that kind of thing. Um, I, I think it's, it's, uh, it's not exactly the same, but there are, there's a lot of scope for improving the experience of server rendering because the benefit of server rendering is that you have this. Instant, like from the moment you, it hits, it hits your browser, you have something that's surrendered, that tells you that you, you can see text, you can see buttons.
Um, a lot of the of bad user experiences are when that's not immediately interactive when stuff then shifts in and, you know, a banner pops down and the you click the button, but by the time your finger touches it, or the mouse clicks, a different button is in that play. You know, the, the, a lot of negatives associated with, with that.
Um, and those are things that we can really solve at the framework level.
[00:53:48] Future of Web Dev
Justin Bennett: Yeah. That's awesome. So we've, we've covered a lot of ground here. Um, you know, we started talking, uh, earlier in our conversation a lot about like the development cycles and how friction can slow down. Um, you know, this, this feedback loop that's necessary for this creative process to really thrive. And, and I feel like a lot of the things that, a lot of the work that you and the team have done in nuxt, and, and the view ecosystem has really sought to smooth a lot of that over.
Uh, you know, provide a smooth on wrap, uh, give good documentation, give a good out in the box experience, great dev tools, a lot of this stuff. So when we're looking at. Or when you're looking at kind of where we're at now and then thinking sort of about the future of the web or building websites, uh, what does that look like to you?
Do you think there are ways that we'll continue to work on reducing the friction going forward? Do you think there's something else big on the horizon?
Daniel Roe: So, I mean, I absolutely do think this is something we care like, that, that not just nuxt, but I think we care about it. So one, we care about it because we are people and we are facing friction. Um, and so therefore, individually we will all care about this as developers and we will, and, and developers, we, we, we scratch our own itches.
So we have the ability to develop tools and immediately we try and solve our own problems. So that is always going to be something I think that we focus on and implement and create solutions for. Um, I think there are a lot of interesting possibilities in terms of how we do that. Um, so, uh, G p t models, large language models are making it possible to maybe have slightly different and more outta the box solutions to some of that friction.
Um, so I joke that nuxt four is going to be fully AI generated. So you, you just describe your app and that's, that's what you're gonna get. Um, but I think there are, there are interesting possibilities there. Um, there, there are projects like, uh, Glossier, which aims to sort of deeply tie your documentation of your project with translation, which is, uh, AI generated and, but also tied into translators.
Like that kind of thing could be really, really nice. That could really improve your, your experience in terms of developing something. Um, I think, translating developer experience into good user experience is, is important. so we all can get caught up in our own, you know, Paper cuts, um, a little bit too much.
And we sometimes forget the, like, the impact of what we're doing on or not doing on our end users. And, um, and I do think we can, we can work very, we can work hard to, to make this, this possible. So I, I'm a firm believer in like deep compiler integration because as a framework can make a good DX for users and we can also optimize for like the end user experience because we have full control, like from the beginning to the end.
We in control of the bundler, we can add, uh, you know, compiler, plugins, we can actually make this work. And I think that's something that we are only scratching the surface of at the moment. So view is, um, we have an experimental vapor mode coming soon where we have different kinds of components that we can compile.
Uh, server components are not fully out of exp the experimental flag yet in nuxt, but that's a huge possibility for both DX and good user experience. Um, sort of the, uh, sort of frameworks like quick are ex like trying to think about what does sort of partial hydration look like. I don't think it's the right call, but they're interacting.
They, again, they're trying to use the compiler to make, to make things more performant on the final, um, on the, the consumption point in the browser. Um, and I think, I don't think it's going to be what qwik's done, but I think I wouldn't be surprised if there's, there are things like that that end up getting picked across different frameworks.
Um, so I think, I think, BUILD tools are going to be a huge part of that. And I think, I mean, I think I, I, I think personally, stepping aside for a moment, the things that we're going to see less of are the boring things. The things that we don't like doing, um, are those are our pain points, right? That's what we're going to be optimizing for, which is great. Like, I hope that's what AI ends up helping us with the things that we don't like and keeping the things that we do.
Keeping the magic and the, the joy of creation and the artistry.
[00:58:08] Tooltips
Andrew Lisowski: Cool. Uh, with that, let's move on to tool tips.
So first up, we have Raycast, which we've had on the podcast, and both me and Justin like a lot.
Daniel Roe: I am a total fan of Raycast, so, um, if you haven't used it, it is a, um, a sort of, uh, command space replacement for Mac OS. Um, you basically get a, like a command palette for your, your computer. Um, it comes with a lot of things that you, you might like, like fight tracking and calculator, and. Like an automatic.
The thing that got me was the automatic schedule. So, um, it shows you what your, your agenda is for the day and you actually can just press enter and it take, it like launches the, the video conference of the next appointment you're in, which is just amazing dx. Um, but you can also write your own extensions for it.
And there's a whole store with, uh, people, um, writing extensions for different things. I wrote one for my accountancy software, so I can, I can see like my bank and like for my business, like I can see bank details and incoming transactions and if I've reconciled them or not. And, you know, it's, it's cool.
You can build anything on top of it. RAYCAST is, is really nice. they have a new, um, AI integration too, so you can sort of, um, hook into chat G P T and uh, but, but really there's, there's so much there. Um, it can do window management and clipboard management and um, sort of quick linking bookmarking.
Uh, it's, it's a sort of all in one tool. It's probably one of the first I install after I install a new, if I, if I have to install a new computer.
Andrew Lisowski: Cool. So next up, uh, I found this on Twitter, I think yesterday. Uh, one, one of the, my tool tips from a past episode was Shadcn/ui, which is this like c l i for like. Adding components to your app in a templatized way. This is a way to generate a form with those components from Azod schema. So it's like very much in line with the like easy to use, fast iteration.
You just define your form and then you can generate a component, uh, a form with your components from your design system in your project. So I love seeing little tools like this that help you kinda like get an idea off the ground faster and help you iterate really quickly.
Justin Bennett: So this is a little toy that I found today. So the website is expensive.Toys. Uh, it's by, uh, developer, uh, Artur Bien uh, hopefully I didn't butcher his name. Sorry if I did. Uh, but his, his whole blog is, is very delightful. He's got a lot of little like widgets that you can play around with. So Andrew, you can like spin the ring if you just like grab it and pull it.
And if you spin it the other way, it like, they like disconnect and, yeah. Yeah, you can. I don't know. It, it's, it's really fun. He's got a lot of really interesting, uh, visualizations and just toys on there and, uh, yeah, I don't know. His site's very delightful. I definitely recommend you check it out. It's, it's so, so fun.
We were talking a lot about the joy of programming and, and when I see things like this, it makes me, I dunno, it just gives me that like the warm fuzzies that, you know, people are still being really creative on the web and, and, and building fun things.
Daniel Roe: Uh, this is amazing. So this is, do you know, I feel this should be an Anthony Fu tribute episode because, uh, this is another Anthony Fu Project. Um, it is programmable slides. So you write your slides in markdown, you can, um, inject, uh, components. So, uh, uh, view, view components. I dunno if react is supported, but, uh, you can just stick interactive, um, interactive code, uh, in your slide deck.
Um, it, it supports transitions. It can export to A P D F, you can create a static website with it. Um, you can pretty much do anything you like. I've got my own integrations that, um, like automatically pull photos from Unsplash. Um, I have, uh, um, one, one of my, uh, friends has a, a sort of interactive voting thing where people scan QR codes in the audience and you get sort of live, um, voting.
Like it's, it's hugely extensible. If you're, uh, a developer, you'll be right at home and you can, you can basically use it to create amazing slide decks, um, that are just markdown. And it's, it's, it's incredible. It's it, if you've not tried it, definitely check it out. It's, it's really cool.
Justin Bennett: Yeah, I really love this tool a lot, uh, and a lot of the other things that Anthony's written, he's so prolific. It's, it's kind of crazy. Uh, we also have episode 25 if you want to read or watch more stuff that he's done. So we had Anthony on a while back. Uh,
Andrew Lisowski: yeah,
he actually shared that too, and it looks like it's come quite a long way since then. That, uh, the, the QR code voting that sounds just like next
Justin Bennett: Yeah, just to brag on him a minute, like the level of polish that everything he does has just blows me away every time. I'm just like, how many people are doing this? And it's like mostly 90% him, and I'm just like, what? How?
Daniel Roe: I'd, I, I think there's, um, he's got a a, he is got a whole, um, raft of, of skills, but I think one of them is, is his ability to, uh, pull in teams. Um, so he's created, like, he created cite, he created, um, slide D's on the core team of view, uh, Vite of next. Um, so, and, and, and some of these projects, you know, he, he, he'll create, bring a team on board.
Um, and then he trusts them to make good decisions. You know, he is not micromanaging a project to death, uh, which is, which I think is something we all need to, to learn from. Uh, well, I mean, maybe no, no reflection on, on the current company, but I mean, I think that, that, that art of, of getting, getting a team together and, and then trusting them, I think that is,
Justin Bennett: Oh yeah,
definitely.
Daniel Roe: skill.
Andrew Lisowski: Yeah, writing the code really not the hardest part. Like once you learn how to write it, it's like it's not much hard to write more, but building community and building products, those are two very, very tough skills to come by. And it's definitely shown that
Justin Bennett: Learning to let go. An important one.
Andrew Lisowski: Okay. We got another one from Daniel here.
Uh, alacritty, I, I don't know if I said that right.
Daniel Roe: So I pronounce it alacritty, but I, uh, don't want to get in the way of any other pronunciations. It's a, it's a term, it's a rust, uh, based terminal for your, um, for your computer. It runs on, uh, Mac, uh, windows, Linux. It's across platform, very customizable. I have mine super mineral, and it is incredibly fast.
It is the fastest terminal I've used. and when I use a terminal, I want it to be fast. I don't, personally, I don't care about any features. So I've, I've got, um, I use Starship as my prompt and I have t marks, uh, for sort of like within terminal window management. And so, I mean, there's other stuff there, but the terminal, the, the window that pops up that hosts it, I think that is, should be as, as fast and minimal as possible.
Um, and so. You know, I know there's other stuff out there, but alacrity, I really love for that, for the speed, instantly responsive, and it just runs whatever I, I throw at it, which is Starship and t X and so on.
Andrew Lisowski: Okay. My last tool tip for the day is a tiny little react component that helps you add time, inputs to your app. Uh, time inputs. No fun to, to code timestamps. No fun to think about. So a component that takes both of those and takes it off my mind. I like, it's not the most customizable thing, but for like a dev focused dev tooling thing, something like this could really do the job.
You don't need a full calendar picker. Most of the time. This like multi input thing that they got going on seems, seems real usable for lots of different situations. So if you're looking for a, a simple time input to add to your app, uh, I'd give this a, a look.
Justin Bennett: I moonlight as a mechanical engineer. I am not by any means, uh, but I, I wish that I was sometimes, uh, and I love 3D printing. I love seeing, see, uh, all, all these like very physical things and one of the hardest things getting into that space can be modeling. Um, there are some great modeling tools out there.
Uh, like Fusion 360 is a very, very popular mo uh, modeling tool in the 3D printing or light manufacturing space. But, uh, they're often hard to get started with back in the day, like SketchUp was a good option. It's harder to get into. The quality's not as good as it was in the past, and I discovered Shap r3D I don't know, last year sometime.
And the really cool thing about this is it's a CAD program that works on an iPad. Uh, so I can just like go to a cafe and, you know, design a 3D print or something just like on my iPad. And it's so they, they've worked so hard on the UX of just making it very, very natural, like very easy to draw and stuff.
And, um, later this year they're actually gonna make it, uh, parametric. So it's not parametric right now. They're making it parametric later in the year. And I'm super, super excited because honestly, parametric CAD is like very necessary for doing anything sufficiently complicated and pretty much everything out there on the market that's parametric, it's really hard to use.
So I'm stoked. I can't wait. But anyway, if you want to do some like light three D printing stuff and you're like, how do I get started in modeling stuff? Shapr 3D is awesome.
Andrew Lisowski: What have you been? What have you been modeling lately?
Justin Bennett: Uh, I am working on, this is really hard to describe. Uh, a friend of mine are working on a. Like sort of this infinite scrolling paper. So it's like a big roll of paper that has like two brackets that you put on your desk and like two little server motors and it just like scrolls out. Scrolls out. So think like a webpage, but like physical.
So it's just this, this like exploration of like, what if you had just like this infinite notebook or infinite canvas on your desk that's physical, like what would that be like? How, how would that feel? So I've been iterating on like some brackets and mounting for their servos and just trying to figure that out recently.
Andrew Lisowski: That's
quite the side project you got there. Okay, last one for the day. Plash by Sindre Sorhus. Sorhus.
Daniel Roe: HEDIS comes up with amazing things, doesn't he? Uh, another incredible dev, um, plash is basically allows you to embed websites in your desktop wallpaper if you are on Macs. So, um, you can, uh, you can stick existing websites, um, you can modify their CSS and whatever. I basically, I have a, like a big, uh, desktop.
I, I hide them Mac OS menu bar. So I just really meant minimal. I thought I would really like to have a clock, um, and actually a little dashboard just with some other key bits of information. So I threw, threw it together in a nuxt project in a, a few minutes, found the plash project, uh, a plash, and then just embedded the website that I had built.
So it's, it's interactive. The clock sort of changes time. I've got sort of, uh, key stats for some, um, projects I'm maintaining that's sort of open issues, things like that. And it just beautifully blends in with my desktop. Um, it's, it's, it's really nice. Again, if you like making things, um, you can easily build your own, own dashboards, um, your own anything really.
Um, or you can display an existing website that's already built and you can have more than one site. So it's not just one. Um, you can, you can put multiple ones in and it even has a feature where you can temporarily interact with the website to sort of log in or whatever, and then make it non-interactive.
So it's just your desktop background and it's very, very cool.
Andrew Lisowski: That is quite cool. Okay, that wraps it up for tool tips. Uh, thanks for coming on, Daniel. This was a interesting conversation into a world of JavaScript that I have very, very little interaction with. So thanks for coming on and explaining all these concepts to us.
Daniel Roe: It's been so much fun
Justin Bennett: Yeah. Thanks again. I, I'm reinspired to go check out the work that y'all have done on Nuxt and, you know, it's been a long time since I've been in the vue ecosystem. Maybe it's time to, to check it back out. So really excited and definitely folks that are listening, you know, check out the work you're doing.