You Should Try Vue.js

Welcome to Syntax.

Today, we're gonna be talking all about Vue. Js with CJ.

That's right. Wes had a baby, and he is out for a little bit. So CJ is gonna be joining us. And what better to talk about than something that Wes and I have not been able to bring to the show, which is Vue JS. So I'm really stoked. CJ just got back from VueConf. He's gonna be telling us all about why he thinks you should be paying attention to Vue. And I'm gonna be asking him some dumb guy questions about, what is what here in the modern Vue landscape. My name is Scott Tolinski. I'm a developer from Denver. With me today is CJ Reynolds, aka Node Garden. We're gonna be really getting into some Vue stuff. But before we do that, you're gonna wanna check out century@century.i0, the perfect place to really understand exactly what's happening in your application at any given point.

The best thing about Century is that I've used it for a really long time and thrown it on side projects, thrown on main projects, all that stuff. And anytime that I have people using my applications, it just helps me get to the bottom of where there could potentially be issues. So that way I can solve them before my users tell me that there's a problem. Because if your user's telling you there's a problem, that means, you know, 20,000,000,000 other of your users, if you have that many, have already had that problem and just did not tell you. The one who steps up to tell you isn't the 1st or only person who's had that problem, and you don't want that had to happen. So head on over to century.i0forward/syntax.

Sign up and get 2 months for free. CJ, what's up, my man?

Node much. Excited to talk about Vue. It's one of my favorite things that I don't get to use that often or talk about as often, so I'm super excited.

Yeah. I'm excited too. You Node, we've we've talked about this a little bit before. We had a little bit of you talk in a potluck that we recorded.

And you know what? I I've fallen out of the view landscape a bit. So I have view experience, view experience, view experience here, and, not enough modern view experience, but enough to know what's what here. I think the main thing we wanna know, CJ, throughout this whole episode JS, why should anybody be paying attention to Vue when there's so many other great options out there? So let's get into it. Let's, let's, explain us about Vue. Js.

Sure. And I guess I'll start with what it is for anybody that's completely new to all of this. But it is a front end framework just like React or Svelte or Angular. You can use it to build front end websites.

And it's been around for a long time. It's been around almost as long as React Wow. Which many people may not know. It's it definitely has gone under the radar a lot. But I started using it back in 2016.

And, back then, I even gave a talk, an overview of Vue. Js. I gave it at a at a few different meetups and conferences. So, yeah, I've been using it a long time.

And it is a front end framework, and it has evolved over the years. So, they call themselves the the progressive JavaScript framework. So one of the things about them that is pretty cool compared to even, like, React or Svelte is you can use it with just a script tag if you really want to. So you can actually just add it to your site and then get some of the the features of creating components and having templates and things like that without even needing a build process or anything like that. I mean, these days, you probably are gonna have a build process. You're gonna have a more complex site. It's gonna have routes and multiple pages. And so they have an offering for that too. They have the CLI, which is also very full featured compared to the CLIs of a lot of these other front end frameworks. But, yeah, they build themselves as incrementally adoptable and progressive. They're approachable, performant, versatile. And one of the things, first, that I like about them is if you know HTML, CSS, and JavaScript, you're gonna have a very easy time picking up Vue. JS because their template syntax is very much HTML.

But then there's a few things sprinkled on top, like directives and then some handlebars. But for a lot of people, especially that people that have that have been using React for a long time, you forget how weird JSX is. Mhmm.

And, I I have some some gripes and complaints about just working in complex React code bases with complex JSX, and I've I've never had that experience in Vue.

Yeah.

That's that's really great. You know what? You know, I'm gonna I'm gonna refrain from saying the words felt too much on this show because I I want this to be about Vue.

But I I think that is one of the things that, turned me on to 1st view and then on to Svelte JS that React does feel like you're shoehorning in HTML into JavaScript, where Vue and Svelte definitely kind of take more of the more of the historical, like, templating language flow of you're working with HTML first and then enhancing HTML, which has always resonated with me because, you know, I I got my start as just doing HTML and CSS given that that was, you know, what what I did mostly with CMS work and stuff like that, your PHP. But your your your primary core of writing things is in HTML.

And I personally like that more than my primary way of doing things JS writing JSJ. I don't know if you have any experience with Backbone. Did you ever use Backbone?

A long time ago. Yeah. Yeah. Backbone to me always

the 1st time I used Backbone, I was like, why are we doing this in JavaScript? Like, this feels like this is something we should be doing in HTML.

So that that's, yeah. I I like that little background you gave for us here. Definitely. And I guess I can start to talk about some of the things that Vue has and why I like it. I guess, first of all, you're gonna start with how to get started.

So like I said, you could have a just an HTML page. You could add the Vue script tag from a CDN.

And then if you check out their docs, there is a built in function called create app. You create yourself an app, return an object that has some data on it that you wanna use in your view, and then you just reference it in the view. And so you can do just that. They also have a a CLI though. And so if you do, let me grab the the CLI command for you. Yeah. Npm create view at latest. That'll run the CLI. And if you're watching the the video podcast, I have just an example of this on the screen here. But this is one of the things that I I like about Vue as well is I I guess the Svelte CLI does this Node. The SvelteKit CLI does this. But there's a long time where, like like, for React create React app literally just it just spits out a React app, and there's nothing more customizable beyond that. And I think even the early days of Svelte was the same way, but Vue has had a CLI for a very long time, and it's it customizes the app that it generates. So it'll ask you, do you want TypeScript or not? Do you wanna support JSX? Which I'll show an example of because pretty interesting that you technically can use JSX with Vue if you really want to. They have a built in router. So this is something I'll talk about as well. There are libraries in the Vue ecosystem that just everyone uses. Right? There's not a debate about which one is better, which one should you use. If you're gonna do routing in Vue, you just use VueRouter.

The CLI will ask you to use that. Same thing for state management. In the world of React, there is Redux, Jotai, Immer.

Zustan. All of the Zustan. Yeah. Valeto. One. Velite Veloteau, whatever that is. Do do you think and and sorry to interrupt here. Do you think that Vue. Js has less confusion over what to use Wes because the CLI is opinionated? Or do you do you do you think that is is why it became less? Or do you think they just latched on to certain projects and they became the the options?

Well, I think, I think I think it was the inverse. And and if the thing is that these libraries are from the core team. So Deno is from the the core team that works on it. It's not built into Vue. Js, but it is a separate library that you install. But people from the core view Vue. Js team are also working on Penia, which is their state management. And same thing, people from the core team are working on VueRouter. So Gotcha. All all of these kind of, like, existed, and then, like, the CLI kinda just pulls them all together. But JS for as long as I can remember, like, even back in 2016, these were the choices well, back in 2016, it wasn't Pena for state management. It was Vuex, which was, like, their equivalent to Redux. But they got a newer one. More people are adopting that in their in their newer code bases. But, yeah, I think kind of the libraries emerged out of the core team, and then that's just the thing that people use. And so with that, when you come across a Vue. Js app, there's not a lot of guesswork involved. Like, you know they're gonna be using Vue router. You know they're gonna be using Pnpm Yeah. Or or Vuex. Whereas with the React app, it's up in the air. Like, everyone I come across is, like, completely different. You have the opinions of every team embedded in the code Bos itself, which, you know, has has some pros. Right? Because we are we are developers and individualists, and we like to have our opinions and like what we use. But it is kind of refreshing to be able to jump into a code base and be productive a little, more sooner because you don't have to figure out what stack have they chosen for this React app. Yeah. And I think that's

probably one of the big reasons why Next. Js rose to prominence is because I mean, granted, besides the fact that's a full stack app, but React has always been so unopinionated on these things. Like, when a when an opinionated stack of these things becomes the way, the default, or, you know, the way to do things, I I personally prefer that myself. I want my framework to do more for me. I want my framework to have those options available that are coming from the maintainers.

The user land is great, and having freedom in user land is great. But somebody makes a package. It becomes popular. They stop maintaining it. Next thing you know, you're migrating and migrating and migrating.

And not only that, you got churn in inside of internal APIs in React. I think the Node hangover I have from working in React for so long was migrating and churning constantly.

Yeah. And another thing that I really like that comes built in with the CLI is generating an an ESLint config and Prettier config by default. These days, you're probably used to it, especially if you're using Vite, because, even if you're using, like, Vite with the React app, it's going to generate. I think it might ask you, but it'll generate an ESLint config and a Prettier config. But before that, I used to spend hours just trying to get my specific ESLint config and Prettier all working nicely together in a React app. Like, I even have a a video from, like, 2 or 3 years ago on the Coding Garden channel where it's it's an hour and a half, and it's literally me just setting up a React project. I'm not adding any features. I'm just I'm just, like, configuring the router and configuring, Redux and then configuring ESLint and Prettier. But, it is nice that that aspect of the of the CLI tool and the view world kind of leaked out into other things, especially because things are using Vite now, which originated in the Vue. Js ecosystem.

And now it gives you, like, an ESLint and a prettier configuring just ready to go. You don't have to spend so much time configuring it. Yeah. Node. Thanks. Right? Yeah. So let's kinda get into, like, why I like it Vercel, specifically, React. I'm gonna use React as an example because most people I mean, a lot of people know Node and use React, so that's probably, like, the point of reference that they'll go from. But one of the major things is less boilerplate. So when you're working in a React app and let's say you're hooking up a form, Hooking up forms is so much of what we do as web developers.

The canonical way to do this in React is to add a change listener to the input, set up some sort of state. And then when the when a change is detected, you update that state. Now you you could say there are these days, maybe you might use form data instead or maybe you're using a library that makes it a little bit easier. But the if you look in, I think even in the React docs, they show you this is how you hook up forms. And it's a lot of code. And, I mean, the amount of the amount of inputs that you have to hook up and and wire all of this up to JS a ton. And in Vue JS, there's a single directive. It's called v model.

You say v model. You specify the state variable that you wanna bind that input to. That's all you need. It stays up to date under the hood. And if you're familiar with Svelte, they have a very similar thing. I believe it's, like, bind this on an input, and then you specify the the variable name. It's bind value, by the way. Bind value. There you go. Yeah. That's nice because you don't have a bunch of, like, functions hanging around and, like, extra stuff to just to do some of the most basic things. I have some examples, I'll show for the video pod, but also kinda describe what's happening here. This example here is from, an app that's just implementing autocomplete.

One of the things I did over on the Coding Garden channel was I implemented autocomplete and, 8 different front end frameworks. And so that's all of the things, like, first of all, binding the input, which is we're talking about not talking about right Node, but also, like, making an API request and then potentially canceling that API request if a user has typed more, debouncing input, all of these things that you wanna do in in front end. I have a a repo here that does it with a bunch of front end frameworks. And so what I'm showing right now is the v model, in the in our Vue app here. So I have an input v dash model, and then I specify the state variable name that I wanna bind to. And then if you look in the script itself, I have a variable here. It's const filter.

And then I'm using ref to define this, state variable. So ref inside of Vue is not like ref inside of React, which is typically for, like, element references.

A ref is just like a a a single little state variable that you want to keep track of changes to. So I have a filter. It's a ref, starts off as an empty string, and then I just bind that with with v model. Syntax, super simple. If you take a look at how we do this with React, we have an input, we have an on change handler, we pass in, an arrow function that gets access to the event. We then are calling our set filter state function, passing in e dot target dot value. And then after that, we're binding value to be filter, which is our state variable. And if you look at the top of the component, our state variable is, from use state. So I have const filter comma set filter, and that's use state for the empty string. So even the simplest thing, just like simple little state management, keeping track of that on an input is just so much less boilerplate in in Vue. It's just Vue model. That's all you need. Yeah.

I think that is something with React specifically, and and you'll know this too because you did Angular before React.

Any of us who came from something like Angular before React, when we saw the React means of working with form state in React, I think my first impression of JS, surely, you must be kidding.

I have to write a function.

Like, my my form has state itself.

Like, I shouldn't have to, you know, automatically then hand move that into a variable. And while having that control can be really great, sometimes if you want that control, I would argue most forms don't need that level of control.

You you're typically reading the value and then you can utilize that value inside of your control flow or if statements if you want, like, dynamically stepped forms and stuff like that. But to to actually have to take the value individually individual value and set it in the state Always felt weird to me if you're not doing things like manipulating

the the text string as a user's typing. Right? Oh, I'm gonna make this so it only could be lowercase, and it's automatically lowercasing their text as they're typing or something like that. So Yeah. Yeah. That's a a big big move in simplicity is is the right right call there, I think. Definitely. And then there are also these just other little niceties that you get used to in React but you forget about. So one thing is self closing tags. So I I teach a lot of beginners, and that's one of the things Wes I'm teaching them React, they just get so hung up on JS just you need that self closing tag on, like, an input or an image.

With Vue, your template is technically, in my code example here, if I have a self closing input, but I think that's just because I write so much React code. You actually don't you don't need the self closing tag on, things in your in your Vue app because it is just HTML. And HTML, by design, is actually, like, very forgiving. Like, some things don't even need a closing tag. Like, I think is it I think an image tag in the HTML spec that that technically does not have a closing tag, but you still need it in in the React URL. So that's an a a little nicety. Yeah. Hold on. Even to jump in there real quick, did you see Rich Harris had, like, a big post about how Svelte is parsing

HTML self closing tags incorrectly because everybody kind of parses them incorrectly? I'll have to send this to you. It's really good. I'll post it in the show notes. There are some, like, really interesting self closing HTML tags about how most people have, generally, their mental model for how self closing tags works or JS completely wrong. And as somebody who had never heard of this before, I kind of Wes, shocked at how how this worked. So I'll I'll post it in the the show notes. You can go I'll give it a look for yourselves.

Yeah.

I think to that note, like, React has become so prevalent. People kind of forget how much it changed in terms of, like, how we how we do things. And and this is one of those things where, like, well, yeah, and everything's just self closing, but it doesn't necessarily have to be. Yeah. Right. Exactly.

Yeah. It's a reactism. It's not a web web thing. Yeah. Exactly.

There's some other niceties here. I I I feel like I I'm not giving a, like, a super basic introduction. We're kind of jumping around in these code examples. But another little nicety I'll show here, and maybe that's the theme of this, is just the little niceties, things you do so often that you forget about. But in Vue, when you want to add a event handler to an element, you can use the shorthand at and then the event name. So in my code example here, I'm adding a submit handler to a form. So I'm saying at submit.

And then if you look at the React example, it's on submit, and then you you specify the callback. But one of the things you do pretty often in front end React code, I think I guess things are changing now that we have, like, actions and server side codes and stuff, is you typically prevent the default action on a form submission because you wanna handle things with JavaScript.

And in Vue, you just say event name Scott prevent that automatically prevents the default action. This is something we do so often, and it's beautiful that it's kinda just built in there. There's a few other little helpers that you can just do dot on, and then you don't have to call in explicitly. So in the React code example, I get access to the event and have to explicitly call events dot prevent default. So that's another thing that Mhmm. Nice and built in in terms of, like, conditional rendering. So let's say, you wanna show something on the page. In this case, we wanna show a progress bar on the page if loading is true.

In Vue, there JS a directive called v if, and then you pass in a variable. If that variable is true, that element will render out.

If it's false, it won't.

And in React, there's nothing built in. We just use either I don't even know what this is you know what this is called where you have, like, variable

and something? I don't even know a name for it. Yeah. The when you use the double ampersand in the templating syntax, I don't know if there is a name for it. It's just like I mean, it's just exploiting conditionals in JavaScript.

It's really what it is. But yeah. I Node. That's always bugged me about React it because it's not super readable if you don't know what it is. Sure. Once you learn what it is, it is what it is and you got it. But if if you were new to React, you'd look at that and be like, why are they doing it that way? And if if statement to me is always read much cleaner. Do you want maybe wanna take a second on the word directive and and maybe explain what that is?

The way that you use them is just as, attributes on your elements. So in this case, we have a progress element. And then you see a little attribute there, v dash if equals double quotes and then the value inside of it. So, we call them directives. They really just are, like, special attributes that do something specific inside of Vue. And so earlier, that v dash model one, that's also a directive.

There's a directive v dash show, which will set display none on an element instead of actually removing it like v if would. So v if, literally removes it from the DOM versus v show adds and removes display none. And then there's also v four. So when you're iterating over lists of elements, you have v four, and you say v 4 element in elements or, like, the the list name. They're just attributes, but they're kind of, like, domain specific attributes to Wes you're working in Vue. Js.

Did you know that the word directive was first used in Angular? I didn't know that. I figured it came from something else before that.

It was my 1st exposure to it. So yeah. Same. I I just figured it existed before that.

Yeah. I think the early days, a lot of the terminology was actually stolen from Angular 1 or borrowed from Angular 1. Yeah. Like, even, like, when I first started learning Vue. Js, it was very soon after, like, having used Angular 1 a lot. And so, v if is NGIF in Angular, and, v four is NG is it NG 4 in in Angular? Yeah. Yeah. I think it is or was. Yeah. Or and then NG model is is pnpm Angular. I think it's sort of similar these days in more modern Angular, but it's like some of the stuff has changed a little bit. But, yeah, a lot of this stuff was borrowed from the early days of Angular.

Yeah. Wild stuff. Yeah.

So another thing I really like about Vue is its built in way of handling styles.

So first of all, I haven't talked about this yet, but Vue has this concept of SFC or single file components.

So everything related to a component is in that same file. And so in an SFC, you will have a template. So that's where all of your HTML goes. You'll have a script. That's where all of your your TypeScript goes. And then you'll also have a style tag, all of which are optional depending on whether or not you need those things in a component. But a typical SFC will have a template, a script, and a style. But one of the really nice things about this is this idea of scoped styles.

So if you just put the attribute scoped on your style tag, now these styles will only apply to this component.

And this has been built into Vue. Js as as long as I've been using it, which is crazy because when you get into the world of React, there's so many style solutions just to solve this Node problem. Right? Like, I wanna style a component, but I don't wanna style everything else. So you have things like styled components, CSS in JS, CSS modules, which isn't React specific, but it it is one way to do it as well. And I will die on I I will die in this this weird little hill that Tailwind

is a strategy for scoping CSS.

People find that that point to be odd, but I I will die on that hill that tailwind exists within popularity in React world because it is solving, scoping in addition to default styles, whatever. But scoping is a a big reason why people end up using it.

Yeah. It is. I mean, I mean, I guess we don't wanna get into that debate. It comes with Yeah. Yeah. The downsides of, like, duplication and whatever else. But, yeah, like, if you're gonna be putting styles everywhere you need them, they're gonna be scoped to exactly where you use them. So Exactly. Yeah.

Yeah. So that's that's one of the cool things. It's just built in. You don't have to install another library. Svelte definitely took inspiration here. So because by default, a style tag in Svelte is scoped.

Whereas in Vue, you have to you have to opt in. There's a an attribute called scoped that you specifically put on your style tag to make it, scoped. Otherwise, they're they're global by default. And then the other thing is actually just, like, working within in binding styles. So I'm gonna pull up in the Vue docs really quick their section on working with class and style bindings.

So in in the world of React, because it's just JavaScript, and I'm air quoting for all the people listening at home, it's just JavaScript, If you want to conditionally bind, like, a CSS class name, you could use, like, a ternary. Right? You could you would just, like, embed a ternary there and say, if this state value is true, then, yes, apply this CSS class name. But because we we do that so often, there are there are libraries that have popped up in the React ecosystem, like, I think it's called CLSX, or there's another library called just class names. And so, basically, when you're working with conditionally applying classes in React, you have to bring that library in, and then it makes it a little bit nicer for adding and removing classes conditionally if you need to. This is just built into Vue. Js. Nice. And it has been since as long as I've used it. So if you want to bind a specific class name, you do colon class equals. You then do, object syntax. And then every key of the object is the class name that you want to apply.

And the value is an expression if it if it resolves to true, that class will be applied. And so in this example, we have an object with the class active and, colon, and then the expression is is active. So is active would be some state variable. And if is active is true, that class gets applied. But this is really nice because if you have, like, 5 or 6 different conditional classes that are all dependent on various conditional states, the syntax is is pretty cool because it's just like an object specifying class names versus having to pull in another library or having, like, a bunch of, like, nested ternaries and stuff like that.

Sick.

Yeah. I I love that. And and for those of you wondering why you might want your style scoped, I I know we we we did cover a little bit of that. But when you scope your styles to a component, you know, it it makes it really easy to prevent writing styles in Node place that then are affecting something in a completely unexpected place of your application.

Like, for instance, you you apply an h one element. You give it a color of red inside of a component CSS somewhere.

Next thing you know, all of your h ones on your side are red, and you have no idea where that is. So you have to do command find. Wes you scope your CSS to that component, then only the h one inside of that component will be getting that color. And I really prefer hard scoping.

So I tend to even when I wrote Vue, I I tended to scope everything hard to the component, instead of trying to to work globally a little bit more. I think, personally, it it puts you into that more component based mindset.

Definitely.

And and I I guess I will add, specifically, this class, attribute for binding class names. That technically doesn't have to be scoped. It kind of, like, works outside of the scoping system, but, it is a way of conditionally applying classes as well.

Sick. Okay. So CSS sounds great. I love all that stuff. And it it is funny how much my my head nods because I like all of the stuff from Svelte as well. The view approach is just a little bit different. Right? But let's talk about state management. What's built in? What what does it do? What do you have to bring? Do you ever have to go to user land for anything in state management?

You typically don't. It's typically all built in. And I guess let's talk let's give a quick history lesson of working in, with state inside of Vue. So if you're watching on the video pod, I'm in the Vue. Js tutorial. And they have these really cool little toggles where you can toggle between the different kinds of ways of defining a component. But it it used to be that, your component would have a data property associated with it, a data method. And that data method returns an object, and any properties on that object are your Scott, and then you can access any of those things inside of your template.

So this is kind of like the options API or, like, the older way of doing this. One of the nice things about Vue is they have maintained compatibility with the older API. So even even though this isn't the, like, modern way of doing things, you can still have use the options API. Cool. But then they introduced the composition API. And so this is a little bit closer to, like, hooks in React. And so instead of having that data method, you now have these little functions where you can use to then define, your state values. And so we talked about them earlier, but one of them is ref. So if I want a, in this example, a string property called title class, I'll use the ref function, pass in a string. That'll be the default value. And then I can reference that inside of my template by name. And so that's how you define variables. You're using ref. There's also something built in called Reactive.

Reactive allows you to do this for an object. So maybe you have an object with 4 or 5 or 6 different properties. Let's say, like, you're implementing a form and you want to keep track of the the values of all the inputs on that form. You probably have 5 or 6 of those. You might create a state variable called form and use reactive, and then you can pass in an object with all of the properties of the default values of of that form. So that's how you define it. It's pretty straightforward.

But one of the things I really like about it, it is is that it is mutable. We do not have to jump through hoops to update our values. We don't have to call a a special method like set state. We can literally just reassign a value and the view automatically updates. I'll show an example in the, autocomplete UI example that I was talking about earlier. So for instance, we have a loading variable. So in view, I'm saying const loading equals ref, and then I'm passing in false. So that loading variable starts off as false. And then later on, whenever the function is called that needs to update that variable, we just say loading Scott value equals false. We don't have to call set state or anything like that. Under the hood, Vue. Js is using proxies, so it can basically know exactly when you are, setting values here and then update update the view accordingly. If you compare that to, like, React, we have, our classic little use state hook here. So we say use state, pass in the default value of false. That gives us back the variable loading, but it also gives us a function set loading that we call in order to update it.

And then, if we ever need to set that function or sorry, set that variable, we have to call the set loading variable. And so this is a very basic example. Right? It's just a it's just a Boolean. But where this really shines is in, like, deeply nested complex data.

So have you ever had, like, a, a Redux store or any other, like, Deno store in in a React app that has, like, an array, and then that array has objects inside of it, and then those objects have properties that are objects themselves.

If you ever need to update one of those deeply nested properties, you have to do so much just to do it in an immutable way. Right? You have to map the array, and then you potentially have to spread each nested object.

And then if you're doing a nested nested object, you have to spread that as well. So I don't have an example to show you right now, but things can get really, really hairy in when you're dealing with deeply complex complex and nested state. But in Vue, you don't have to deal with that because you literally just update the the property, and the and the view automatically updates. There's no need to to do immutable state updates.

Yeah. If you're if you're looking at the video pod and you're seeing these ref, functions and stuff like that, you may say, hey. This looks exactly like how Svelte is doing runs. In fact, the new runs for Svelte, I think, borrows a lot from Vue. Js in a very positive way. And I I think that would kind of rub some people the wrong way at first within the Svelte world just because alright. Now you gotta you gotta use a function to create state rather than just creating a variable. But, honestly, I think the benefits, like, you're talking about with this fine grained reactivity and unifying how state is done is is such a a it's a really power move from view from the start. I I really do appreciate the approach to state there. Anybody who's ever written Redux probably was like, why do we have to why do I have to call a thing that calls a thing, that updates a thing, that spreads a thing? Like, you know, there's 8 steps to do a thing, and Redux was fine. But, you know, most of the time, you don't need to jump through 8 hoops and create a new object full of data. You just wanna update a one one single thing and have the application respond. Right?

Definitely. And in the world of React, you typically if you're doing this at scale, you would probably reach for a library like Immer or immutable JS. Yeah. Because they do they do make it nicer to update things without having to, like, spread and map. I I think does, is it Zustan that of has that built in? Or I think you can it has, like, a plug in for Immer. But, again, you have to reach for another library. In this case, it's just built in, so every every app you come across is gonna be doing it in the same way. Yeah. I I do appreciate that for sure. And then the the last piece on state management is this idea of global state management. So we talked about it earlier, but in the world of of React, you typically are reaching for, like, Redux or Zustand or Jotai.

All of these libraries basically may allow you to have state that can be easily pulled into components at different levels within your application. The beautiful thing about the composition API here in Vue is that it's not restricted to a component. So without even using Deno, which which I'll talk about JS their global state management, you could literally define a module that declares a few of these ref variables and then just import it into any component, and it will just work. There's there's no weird issues about, like, well, did you call it in the right way? Or or where does it get instantiated? You literally can just create these refs, import them into other components, and it will just work. And so that that's a I didn't talk about this earlier, but that's another nice thing about the composition API in Vue is, like, it doesn't have all of these rules of of hooks, like, when working in React. Right? Like, with React, you they're like you can't have conditional use effects. And, also, I guess I didn't talk about this, but you have to manually specify your dependency array for, like, use effects and use memo and use callback.

In Vue, all of that's built in. So Yeah. In Vue, they have a a a composition function called computed, And this is how you would get, like, use memo, but you don't have to pass in the dependencies. It can auto track those dependencies.

They also have a function called watch. So you can specify which of these reactive variables you wanna watch and and that callback will get called. And, yeah, it's just it's just nice. A lot of this stuff is built in. You don't have to, like, manually manually do all that. Mainly do the tracking. And those same functions that I mentioned, like computed and watch and anything else built to the composition API, all of those can be used outside of component, defined to do the things the way you want, and then just import it into any other component.

Wow.

Yeah. Yeah. All this stuff will make your head spin a bit with React when you when you really start diving in there. Right? When you really start getting into complex state management or just in general with React, having to think about when is this function running, how many times is this function running, which things I actually have to to reach for to make sure this function doesn't run too many times and cause my application to slow down.

It is it is just nice, to have that fine grained reactivity right there in the app. Definitely.

And beyond that, for global state management, there's this library called Penia.

Basically, we're using those things that I talked about that are built into Vue. Js. We're using ref. We're using computed. So we can define all of our computed values, all of our state values, do whatever we need to do, also define methods that operate on those values, and then just return the things that we need elsewhere in the app.

I would argue that this is much closer to just JavaScript than the kind of things you have to do Yeah. Like, in in React. Like Yeah. These are just a few a few methods to call. You literally return an object. There's nothing

special about how to use the return value here or whatever else. So yeah. Yeah. This is the, Wes is away so we can hit on React episode.

Oh, yeah. Man, I I'd never seen pina before. This is, in in my time of using Vue, I don't think this was really widely used or a thing. So it's, it's interesting. I I didn't know this existed. So cool project. There's that's one thing that the Vue ecosystem has that the Svelte ecosystem doesn't have in the same way. And I'm not not necessarily putting Svelte down for this, but, like, the React ecosystem, what does it have? It has a lot of mature libraries and a lot of users. And the one thing that the Vue ecosystem also has, a lot of mature libraries and a lot of users, people building actual stuff.

Definitely. So I would I would say, like, if I'm trying to convince you to, like, use Vue over Svelte, that might be one point. Right? It has been around for a long time. There's a lot of maturity in the libraries that are out there. At the same time, I mean, I I I do have to go go to bat for Svelte as well. Like, a lot of times, you can just use the JavaScript version of a library. You don't need, like, Svelte specific things, which is nice. But, for certain aspects, like, maybe even, like, a a mapping library or some of these other things that you do pretty often, there very likely is an existing library that is battle tested and running in production for a while because it's been around for so long. Yeah. For sure. Okay. So we've talked about styles. We've talked about state. We've talked

about templating, all the things that you're doing when you're building your stuff.

But what about application building? Right? Next JS, whether you like it or you don't like it, it is mature.

SvelteKit, really great. Astro, really great. What's the full stack application platform for Next. JS, And how does it stack up?

Yeah. So the the Next. Js equivalent in the Vue world is a thing called Nuxt, and it's very similar. They have file based routing. They have API routes.

But in my opinion, it kind of, like, goes above and beyond what what even, like, Nuxt JS does, or sorry, next next I next Nuxt.

It goes beyond what what Next. Js does. And, I mean, you mentioned that Next. Js is, I guess, mature, but, like, the App Router is pretty new. And, like, I've I've tried to build some more complex things with, like, App Router and, like, actions, and it still feels, like, half baked. It still feels like they're trying to figure things out. Sorry. You can go back in the archives of syntax, and in within the first 10 episodes,

I'm talking about how, Next. Js is not for me. And I don't know if it it's gotten any closer to being for me. Not to put it down because it's it's a great piece of software, but it's not for me. It never has been.

And, it it's nice to hear that Nuxt just isn't a straight up clone of Next. Js or something.

Yeah. I think there there are a lot of things that Nuxt did first that, like, even SvelteKit are are have learned from and and, like, Next. Js have learned from. Though these days, it kind of feels like Next. Js and SvelteKit are kind of, like, converging to, like, very similar solutions. But one of the the things I like about Nuxt, which some people initially kind of hate, is this idea of auto imports.

Because, like, you can have a components folder, define some reusable comp components in there, and then just use those components in your pages and in and in your your other components. They are auto imported. And then there's a lot of import no. No. I like it. Okay. I I like that as well. Okay. Yeah. It's it's less boilerplate. I mean, like, if you the thing is Wes you look at, like, a a Next. Js app or a React app, I guess it's nice that you can look at the imports at the top and see everything that is being used.

But when you're working in a large application, you're gonna have 10 or 15, maybe 20 different imports.

And so that's a lot to manage, especially if you think about, okay, there are 2 different components that are slightly similar, but they all depend on those same imports. Now you have these imports all over the place. So

in a larger code base, I like the idea of auto imports. You know what? I do too. And and I used to I I did it on the syntax because I I thought Wes would kill me if I did this. But on level up tutorials, I Node a gratuitous use of them, and, I did so using SvelteKit hyphen auto import JS the Oh, does the library fit? Yeah. It's it's been it works great. I I'd used it quite frequently and really enjoy that. So if you if you're interested in that technique, it's it's nice.

Nice. But, yeah, the the the way Nuxt works is, like, it's just built on top of Vue. So it works on the idea of single file components, but it use uses file based routing. So for any page that you want, instead of having to use, like, the Vue router library, you just define these pages, as separate files, and then they'll be routed to according to their name.

And then the other nice thing built into it is, like, these, the way that it you're able to create API functions or, like, server side codes.

And I I haven't played around with it recently, but I was playing around with it when they initially came out with Nux three.

And they had already thought about this idea of of full stack type safety and being able to write fetch code once that works both on the client and the server and pulls in all of the types. So, like, you could define an API route in, like, the API folder. And it's gonna be, like, just your standard server side request handler, and you can do database stuff or whatever else you want. And then in the component, when you use fetch, if that code is running on the server side, it's not gonna make an API request. It's running within the same codebase, Bos it can actually just directly invoke that API function. And then if that code is running on the client, it will actually make make a fetch request. But I think I think SvelteKit is doing this now. They were one of the first to do it. And because of that, you get full stack type safety. So whatever is gets returned from that API function, that type is exported and and usable on the other side whenever you're calling it with fetch. Yeah. I love that. Love that full full stack type Sanity, and that's a such a huge win. Right? Yeah. Remember, we used to have to do

API calls via useEffect. You're hitting a fetch, and then you get your thing back, and then you gotta just pray and hope that that data comes in with the right TypeScript just assign it to the type and maybe cast it or something like that. And yeah. I know. I I love I love it when you can just have your data available in the component automatically.

Know that the types are gonna be accurate to what you're you're expecting.

I'm interested in the future of of you because we're seeing a convergence on the idea of compilers for our front end frameworks. I think Svelte and Solid JS really proved that the compiler is a good idea for many ways in your application.

It it it can do a lot of powerful things for your front end code.

And, now, React has introduced a compiler and, React folks are getting their eyes opened to why that's so great. What's the Vue story there? Because I have heard that there is a Vue compiler, but I don't know anything about it.

Yeah. Well, first, I'll start with, they have had a compilersque code for a long time, even before so the the thing that you're talking about is Vue Vapor. That's their their new way of having your same Vue component, but then compiling it into codes that doesn't require a virtual DOM. Cool.

But the Vue build process itself has actually had an optimizer built in for a very long time Wes if you're doing certain things that maybe, like, you you didn't maybe you have a a variable that never changes and you're rendering that in your your template, it was smart enough to remove it as even, like, a variable reference and just, like, embed it right in. And then there are other types of optimizations that it could make. So Vue itself has had, like, optimizations and, like, compiler esque things for, like, a very long time. But the idea of purely stripping away the entire runtime and virtual DOM and everything else, that's definitely a a newer thing. And Vue Vapor is the idea there. And so it's still in research mode. They're they're working on it, and they they wanna make they wanna have 1st class support for it and make it opt in. So, essentially, eventually, you'll have this vapor attribute that you can just add to your component. And once you add that on there, it's gonna get all of those optimizations and, basically, just get compiled into native JavaScript code. It won't need a a virtual DOM anymore or, any sort of view runtime to be able to run those components.

Okay. Cool. So I that is something that we didn't mention that I I think it is good to be explicit. So without this, Vue does run on the virtual DOM and not the actual DOM. And with this, it becomes virtual DOM less?

That is correct. Yes.

Cool. I I I know the virtual DOM is a cool idea, and I know it was made for reasons.

But I I I gotta say JS a web developer, I'm not using, you know, my web tech to do other I'm not building, you know, command line CLIs or whatever with React like some people are doing. I'm not I'm not using the front end framework to build things other than websites, web apps, desktop apps with a Wes view, those types of things.

The concept of a virtual DOM never made a ton of sense to me. It always felt like it was, stepping in the way. But I do get that it exists for reasons. You Node? JS a higher level, it's it's it makes it work without having to necessarily be explicitly attached to the DOM. And I get that. So I love to hear a there's a virtual DOM less world here.

Definitely.

Okay. So all of this sounds great. Vue is great. I I've been a a long time big fan of Vue, but many people out there are are still stuck in the world of, sure, but are people using it? Yes. Vue sounds great. Yes. It's easier. Yes. It will make my life less annoying when I'm working in my code.

But are people actually using it? So, CJ, are people using Vue. Js?

They are. Yeah. They absolutely are. And, I guess, Node one indicator you might look at is, like, GitHub stars. It's not the best indicator. It's kinda just a little bookmark, you know, that people are interested in this thing. But the, original Vue. Js library has 207,000 stars on GitHub. And then recently with version 3, they forked or they didn't fork. They have a new codebase called Core, and that codebase has 45,000 stars. But if you wanna look at actual usage, the Vue library on npm gets, 4,700,000 weekly downloads.

And to me, that's, that's that's huge. That means people are using it. Like, people are installing this and using it. It it doesn't get as much coverage as and as much hype as, like, Svelte and Vue does on on, X or or Twitter or whatever.

But people are using it, and they're building real stuff with it. And I guess, also, if you if you want the let's talk about the community, they have a really big Discord.

Yeah. So there are a 123,000 members of the Vue. Js Discord.

And, it's it's very active. If you ever have, like, Vue. Js questions, you can go in there, ask. We're happy to help.

That they they use the same Discord, I believe, for, like, Deno and, ViewRouter.

Maybe Pena has a separate one. But, ultimately, everybody's hanging out there in that Discord if you wanna get help. But, yes, people are using it. It's a very big community. It's just not as loud as maybe some of the other things that we're used to. Yeah. It's not wild how that that happens. I I wonder, like, why that is with how we we end up in bubbles like this or,

you Node, everyone talks about React. But, yeah, people are building great stuff with Vio. And I think this conversation has really come to a head lately with the whole Laravel discussion that's been happening somewhat recently on Twitter Wes, yeah, people are building things with Laravel. They're building things with Vue. And sometimes it does feel like people are just talking about React. Not that people aren't building things with React, but it it does you know, it's a there's a weird thing where there isn't as much dialogue, but there is quite a bit if, you know, just an absolute amount of people, like, really being productive with this this framework. So yeah. People Wes using it for sure. And I guess the one thing to add, which I didn't mention, but you brought up Laravel.

Laravel actually adopted Vue as their front end framework of choice. So Laravel is typically a PHP back end framework. But a few years ago, they made it so that if you ever need to do any sort of, like, client side JS, you actually do it with Vue. Js. So it's a it's a very, interesting relationship there. Like, Laravel's getting more press, but it is actually using Vue. So if more people use Laravel, they're potentially also but are gonna be using Vue as well.

Sick. Yeah. That's great. That's Laravel is one of those things we're gonna have to spend some serious time on on the show very soon. Cool. Well, that's it for for Vue. If you wanna learn more about the history of Vue, you can watch the Vue honeypot documentary that came out a couple years ago starring yours truly. I am in the documentary and, saying nice things about view. But it's a really it's really well made. Honeypot makes the best documentaries. They they do great stuff there and and gives you quite a bit of history on, Evan's approach to creating Vue and thinking about Vue and the community involvement. So highly recommend that if you haven't seen that and you're interested in learning more about Vue in general. And if you wanna hear we did an episode a long time ago. Scott teaches Wes Vue. If you wanna hear us talk a little bit more about view as it was, you know, a few years ago, you can hear me try to convince West that view is actually pretty good. So, thank you, CJ, for an updated version of this. I I really think it it clears up a Scott, and audience has been asking a lot for view content.

Our potluck submissions have been saying, where's the view content? So, now that we have you, CJ, I'm glad that we can bounce some of these things off of you and get a a real good opinion here. So thank you so much for that.

Definitely. Happy to. Yeah. Let's ESLint part of the show where we talk about sick picks and shameless plugs.

Sick picks are things that we think are sick, things that we like.

Things that are cool could be anything.

I'm going to sick pick a potentially controversial shoe.

And I say that because when my wife saw them, the first thing she said, these these are at home shoes. Right? As in you're not gonna be wearing these shoes outdoors. Because if you wear these shoes outdoors, you're going to be embarrassing me.

Essentially, I think what she was trying to tell me. And and I'll get these, posted up here. What they Yarn, you you you've all heard of Crocs. You know, Crocs are ugly kind of, foam shoes that are very comfortable.

I, however, I didn't wanna get Crocs, but I still wanted comfortable foam shoes. So I got the Jordan Slides.

They're called the Jordan Node. And they're essentially, what if Nike made Jordan Crocs? They are very much Jordan Crocs. In fact, wearing them right now.

They look like the or were they called Yeezy's? Like, the

They look like much less ugly Yeezy's. The Yeezy's kinda look like, these got blown up in a in a weird kind of way. These look way more like normal shoes in some kind of way. Yeah. Yeah. They look like a stylish croc for sure. And they weigh absolutely nothing. They're super cushy, super foamy.

They're $60.

So, you know, you think Jordans, you're gonna be spending $150.

No. These are just like $60, Node and foam shoes. And for somebody whose office JS, just right down the street from their house here, I'm wearing them to the office, every day here. And, unfortunately, my wife will not let allow me to wear them outside of the house, in public, but, you know, I can wear them at least into my office.

Nice.

Cool. My sick pick has to do with charging devices. I'm gonna grab it.

So I don't know why I was so late to the game, but, I was charging things with a bunch of charger blocks for the longest time. But just recently, I got a single unified interface with a bunch of, USB charging ports and also, like, power delivery ports. And, it really cleaned up my desk. So this is my pick. I don't I don't have a specific brand. If you just search for, like, multi USB port on Amazon, you'll find something interesting. Yeah. This works. It cleans up my desk, and, I don't know why I didn't get it sooner.

Yeah. That's that's a good sick pick.

Anything to to clean off your desk is, something I was just just talking to you about this before the show started. It's it's Tuesday, and my desk has somehow, in 2 days, gotten completely covered with who knows what. So having less stuff on your desk is always always a good thing. Cool. Well, let's get into shameless plugs. I'm going to shamelessly plug actually, you know what? I'm gonna shamelessly plug the syntax GitHub. You know, we we kind of plug different things, and I've never plugged the GitHub.

What's cool is that we have the website code. So if you're interested in seeing how we built the website, the codes on there.

I've recently published a theme for Zed. I also have a theme for Versus Node that I need to move into the syntax repo or the syntax organization.

We have some really interesting stuff here. I'm working on a YouTube tools app that allows you to, perform mass find and replace on YouTube videos from your own, your own, your own home here. Tools. We have our brand assets. We have a repo that's just all of our brand assets.

Some really interesting stuff. So if you want to see some of the code we're working on over here at Syntax, check out the GitHub@github.comforward/orgforward/syntaxfm.

I'll post the link in the show notes.

Nice. And I'm just gonna plug the website on that note because, you may not realize it, but Syntax. F m, you can listen to all of these episodes and search across them. So if I'm ever trying to find, like, a specific topic, like view or react, and I wanna see when it was covered, Syntax dot f m has got a really great built in search engine. And Scott has been making

so, yeah, syntax. F m. Check it out. Yeah. The latest feature that is is currently in a PR, and it's only being blocked by 1 TypeScript error. It's 1 singular TypeScript error that I have to fix JS adding play offline mode. In fact, we recorded an episode about how we built it that allows you to click save. And then what that does is it caches the m p 3 to your computer.

So that way, when you click play, it's not loading it from the network, works on your phone, works on, your your your desktop. You can cache a whole bunch of them. And, eventually, we'll be able to load up queuing like you have on a individual podcast player. So whenever you queue something, it'll automatically download it so the next one plays. You don't have to worry about network conditions and stuff like that. So a lot of updates, a lot of cool stuff coming. And, we're we're just pushing code all the time to this thing, so check it out. And, again, all this code is public available to you if you wanna see the code as well. Cool. Well, that's it. Thank you so much for watching or listening wherever you are at. If you want to watch this podcast, head on over to youtube.comforward/atsyntaxfm.

Either or, thanks for joining us today. We'll catch you in the next one. Peace.