0:00

Welcome to Syntax. Today, we're

0:03

gonna be talking all about View.js

0:05

with CJ. That's

0:07

right, Wes had a baby and he is out

0:10

for a little bit. So CJ is gonna be

0:12

joining us. And what better

0:14

to talk about than something that Wes and

0:16

I have not been able to bring to

0:18

the show, which is View.js. So I'm really

0:21

stoked. CJ just got back from ViewConf. He's

0:23

gonna be telling us all about why he

0:25

thinks you should be paying attention to View.

0:28

And I'm gonna be asking him some dumb guy

0:30

questions about what is

0:32

what here in the modern View landscape. My

0:35

name is Scott Tolinski. I'm a developer

0:38

from Denver. With me today is CJ

0:40

Reynolds, aka Coding Garden. We're gonna be

0:42

really getting into some View stuff. But

0:44

before we do that, you're gonna wanna

0:47

check out Sentry at sentry.io, the

0:50

perfect place to really understand exactly

0:52

what's happening in your application at

0:54

any given point. The

0:56

best thing about Sentry is that I've

0:58

used it for a really long time and thrown

1:00

it on side projects, thrown it on main projects,

1:02

all that stuff. And anytime that

1:04

I have people using my applications, it

1:07

just helps me get to the bottom of

1:09

where there could potentially be issues. So that

1:11

way I can solve them before my users

1:14

tell me that there's a problem. Because if

1:16

your user's telling you there's a problem, that

1:18

means 20 billion other of your

1:20

users, if you have that many have already had

1:23

that problem and just did not tell you. The

1:25

one who steps up to tell you isn't

1:27

the first or only person who's had that problem.

1:30

And you don't want that to happen. So head

1:32

on over to sentry.io/syntax, sign up and get two

1:34

months for free. CJ, what's

1:36

up my man? Hello. Not

1:39

much, excited to talk about View. It's

1:41

one of my favorite things that I don't get

1:43

to use that often or talk about as often.

1:45

So I'm super excited. Yeah, I'm

1:48

excited to, you know, we've talked about this a

1:50

little bit before. We had a little bit of

1:52

View talk in a potluck that we recorded. And

1:55

you know what? I've fallen

1:57

out of the View landscape a bit.

1:59

So I have View. experience view, experience,

2:02

a view experience here and,

2:04

uh, not enough modern view experience, but

2:06

enough to know what's what here. I

2:08

think the main thing we want to

2:10

know CJ, uh, throughout this

2:12

whole episode is why should anybody be

2:14

paying attention to view when there's so

2:16

many other great options out there? So

2:19

let's get into it. Let's, uh,

2:21

let's, uh, explain us about a

2:23

view JS. Sure. And

2:26

I guess I'll start with what it is for anybody that's completely

2:28

new to all of this, but it is a front end

2:30

framework, just like react or Svelte or

2:32

angular, you can use it to build

2:34

front end websites. Uh, and it's

2:36

been around for a long time. It's been around almost as

2:38

long as react, which many people may not know. It's,

2:41

it definitely has gone under the radar a

2:43

lot. Uh, but I started using it back in 2016. And,

2:47

uh, back then I even gave a talk, an overview of

2:49

UJS. I gave that at a few different

2:51

meetups and conferences. So yeah, I've been using

2:53

it a long time and it is a front

2:56

end framework and it has evolved over the years. So,

2:58

uh, they call themselves the

3:00

progressive JavaScript framework. So one of the

3:02

things about them that is pretty cool

3:04

compared to even like react or

3:06

Svelte is you can use it

3:08

with just a script tag if you really want to. So

3:10

you can actually just add it to your site and then

3:13

get some of the features of

3:15

creating components and having templates and things like

3:17

that without even needing a build process or

3:19

anything like that. I mean, these days

3:21

you probably are going to have a build process. You're

3:23

going to have a more complex site. It's

3:26

going to have routes and multiple pages. And so they

3:28

have an offering for that too. They have the CLI,

3:30

which is also very full featured compared to the CLI's

3:32

of a lot of these other front end frameworks. But

3:35

yeah, they build themselves as incrementally adoptable and

3:37

progressive. They're approachable, performant, versatile. And one

3:39

of the things first that I like

3:41

about them is if you know HTML,

3:44

CSS and JavaScript, you're going to have a

3:46

very easy time picking up a view JS because

3:49

their template syntax is very much

3:51

HTML, but then there's a

3:53

few things sprinkled on top, like directives

3:55

and then some handlebars. But for

3:57

a lot of people, especially that people that have been using.

4:00

React for a long time, you forget

4:02

how weird JSX is. And

4:06

I have some gripes and complaints about just

4:08

working in complex React code bases with complex

4:10

JSX. And I've never had that experience in

4:12

Vue. Yeah, that's

4:14

really great. You know what? I'm

4:17

going to refrain from saying the words Svelte too much

4:19

on this show, because I want

4:21

this to be about Vue. But I

4:23

think that is one of the things that turned

4:26

me on to first Vue and then on

4:28

to Svelte, is that React

4:30

does feel like you're shoehorning

4:32

in HTML into

4:34

JavaScript, where Vue and

4:37

Svelte definitely kind of take more

4:40

of the historical templating language

4:42

flow of

4:46

you're working with HTML first and

4:48

then enhancing HTML, which

4:51

has always resonated with me

4:54

because I got my start

4:57

as just doing HTML and CSS,

4:59

given that that was, you know,

5:01

what I did mostly CMS

5:03

work and stuff like that, your PHP,

5:06

but your primary core of writing things

5:08

is in HTML. And

5:11

I personally like that more than

5:13

my primary way of doing things is writing JS.

5:15

I don't know if you have any experience with

5:18

Backbone. Did you ever use Backbone? A

5:20

long time ago, yeah. Yeah, Backbone to

5:22

me always, the first time I used Backbone,

5:24

I was like, why are we

5:26

doing this in JavaScript? Like, this feels

5:28

like the something we should be doing in HTML. So

5:31

that's, yeah, I like that little background you gave for

5:34

us here. Definitely, and I guess I can start to

5:36

talk about some of the things that Vue has and

5:38

why I like it. I guess, first of all, even

5:40

start with how to get started. So

5:42

like I said, you could have a, just

5:45

an HTML page. You could add the Vue script tag from

5:47

a CDN. And then if you check out

5:49

their docs, there is a built-in function

5:51

called create app, create yourself an app,

5:54

return an object that has some data on it that you

5:56

wanna use in your Vue, and then you just

5:58

reference it in the Vue. And so you can

6:01

do just that. They also have a CLI though. And

6:03

so if you do, let me

6:05

grab the CLI command for you. Yeah,

6:07

npm create view at latest. That'll run

6:09

the CLI. And if you're watching

6:11

the video podcast, I have just an example of this

6:13

on the screen here. But this is one of the

6:15

things that I like about Vue as well is

6:18

I guess the Svelte CLI does

6:20

this now, or the Svelte Kit CLI does

6:22

this. But there's a long time where like

6:24

for React, Create React app literally just, it

6:26

just spits out a React app and there's nothing more

6:29

customizable beyond that. And I think even

6:31

the early days of Svelte was the same way,

6:33

but Vue has had a CLI for a very

6:35

long time and it customizes the app that it

6:37

generates. So it'll ask you, do you want TypeScript

6:39

or not? Do you want to support JSX? Which

6:41

I'll show an example of, because it's pretty interesting

6:43

that you technically can use JSX with Vue if

6:46

you really want to. They have a

6:48

built-in router. So this is something I'll talk about as well.

6:50

There are libraries in the Vue ecosystem that just everyone

6:53

uses, right? There's not a debate about which one is

6:55

better, which one should you use. If you're gonna do

6:57

routing in Vue, you just use Vue router. The

6:59

CLI will ask you to use that. Same thing

7:02

for state management. In the world

7:04

of React, there is Redux, Jotai,

7:07

Immer, all the, Zustand,

7:10

yeah. There's a million and one.

7:12

Velleto, whatever that is. Do you

7:14

think, and sorry to interrupt here,

7:16

do you think that Vue.js has

7:19

less confusion over what to use

7:21

where because the CLI is opinionated

7:23

or do you think that is

7:25

why it became less or do

7:27

you think they just latched onto

7:29

certain projects and they became the

7:31

options? Well, I think

7:34

it was the inverse. The thing is

7:36

that these libraries are from the core team. So

7:38

PNIA is from the core team that works on.

7:40

It's not built into Vue.js, but it is a

7:42

separate library that you install, but people from the

7:44

core Vue.js team are also working on PNIA, which

7:46

is their state management. And same thing, people from

7:48

the core team are working on Vue router. Gotcha.

7:52

All of these kind of existed and then the CLI

7:54

kind of just pulls them all together. But for as

7:56

long as I can remember, even back in 2016, these

7:59

were the... Well, back in 2016, it wasn't

8:02

PNIA for state management. It was

8:04

Vuex, which was their equivalent to Redux. But they

8:06

got a newer one. More people are adopting that

8:08

in their newer code bases. But yeah, I think

8:11

the libraries emerged out of the core team.

8:14

And then that's just the thing that people use. And

8:16

so with that, when you come across a Vue.js app,

8:19

there's not a lot of guesswork involved. You know they're

8:22

going to be using Vue.Router. You know they're going to

8:24

be using PNIA or Vuex. Whereas

8:26

with React app, it's up in the air. And

8:28

everyone I come across is completely different. You have

8:30

the opinions of every team embedded

8:32

in the code base itself. Which

8:35

has some pros, right? Because we are developers

8:37

and individualists. And we like to have our

8:39

opinions and like what we use. But

8:41

it is kind of refreshing to be able to

8:43

jump into a code base and be productive a little

8:45

more sooner. Because you don't have

8:47

to figure out what stack have they chosen for this

8:49

React app. Yeah, and I think that's probably

8:52

one of the big reasons why Next.js rose

8:54

to prominence is because, I mean,

8:57

granted, besides the fact that it's a full

8:59

stack app. But React has always been so

9:02

unopinionated on these things. Like

9:04

when an opinionated stack of

9:06

these things becomes the

9:09

way, the default, or the way

9:11

to do things. I personally

9:13

prefer that myself. I

9:15

want my framework to do

9:17

more for me. I want

9:19

my framework to have those

9:21

options available that are coming from

9:23

the maintainers. That user

9:26

land is great. And having freedom in user land

9:28

is great. But somebody makes

9:30

a package. It becomes popular. They

9:32

stop maintaining it. Next thing you

9:34

know, you're migrating and migrating and

9:36

migrating. And not only that,

9:38

you got churn inside of internal APIs

9:40

in React. I think the one hangover

9:42

I have from working in React for

9:45

so long was migrating and

9:47

churning constantly. Yeah,

9:51

and another thing that I really

9:53

like that comes built in with the CLI is

9:56

generating an ESLint config and prettier config

9:58

by default. probably used

10:00

to it, especially if you're using Vite, because even

10:03

if you're using Vite with a React app, it's going

10:05

to generate, I think it might ask you, but it'll

10:07

generate an ESLint config and a prettier config. But before

10:09

that, I used to spend hours

10:11

just trying to get my specific ESLint config

10:13

and prettier all working nicely together in a

10:16

React app. Like I even have a video

10:18

from like two or three years ago on

10:21

the Coding Garden channel, where it's an hour and

10:23

a half and it's literally me just setting up

10:25

a React project. I'm not adding any features, I'm

10:28

just configuring the router and

10:30

configuring Redux and then

10:32

configuring ESLint and prettier. But it

10:35

is nice that that aspect of the CLI tool

10:38

and the Vue world kind of leaked out

10:40

into other things, especially because things are using

10:42

Vite now, which originated in the Vue.js ecosystem.

10:44

And now it gives you like an ESLint and a prettier config

10:47

and you're just ready to go. You don't have to spend so

10:49

much time configuring it. Yeah, no thanks, right?

10:51

Yeah. So let's kind of get into

10:53

why I like it over, specifically React. I'm

10:55

gonna use React as an example because most people, I

10:57

mean, a lot of people know and

10:59

use React, so that's probably like the point

11:02

of reference that they'll go from. But one

11:04

of the major things is less boilerplate. So

11:06

when you're working in a React app and let's say

11:08

you're hooking up a form, hooking

11:10

up forms is so much of what we do as web

11:12

developers. The canonical way to do

11:14

this in React is to add a change listener

11:17

to the input, set up

11:19

some sort of state, and then

11:21

when a change is detected, you

11:23

update that state. Now, you

11:25

could say there are these days maybe you might use form

11:27

data instead or maybe you're using a library that makes it

11:29

a little bit easier, but if

11:32

you look in, I think even in

11:34

the React docs, they show you this is how you

11:36

hook up forms. And it's a lot of code. I

11:38

mean, the amount of inputs that you have to hook

11:41

up and wire all of this up to is a

11:43

ton. And in Vue.js, there's a single directive, it's called

11:45

V model. You say V model,

11:47

you specify the state variable that you wanna

11:49

bind that input to, that's all you need.

11:51

It stays up to date under the hood.

11:54

And if you're familiar with Stelts, they have a very similar

11:56

thing. I believe it's like bind

11:58

this on an input. and

12:01

then you specify the variable name. That's one of

12:03

the things. It's bind value by the way. Bind

12:05

value, there you go. Yeah. That's nice because you

12:07

don't have a bunch of functions hanging around and

12:10

extra stuff just to do some of

12:12

the most basic things. I have some

12:14

examples. I'll show for the video

12:16

pod, but also describe what's happening here. This

12:19

example here is from an app

12:21

that's just implementing autocomplete. One of the things I

12:23

did over on the Coding Garden Channel was I

12:26

implemented autocomplete and eight

12:29

different front-end frameworks. That's all of

12:31

the things like, first of all, binding the input

12:33

which is we're talking about right now. But

12:35

also making an API request and then potentially

12:38

canceling that API request. If a user has

12:40

typed more, debouncing input, all of these things

12:42

that you want to do in front-end, I

12:44

have a repo here that does it with

12:46

a bunch of front-end frameworks. What

12:48

I'm showing right now is the V model in

12:51

our Vue app here. I have an input V-model, and

12:54

then I specify the state variable name that I want to

12:56

bind to. Then if you look in

12:58

the script itself, I have a

13:00

variable here is const filter, and

13:03

then I'm using ref to define

13:05

this state variable. Ref

13:07

inside of Vue is not like ref

13:09

inside of React, which is typically for

13:11

like element references. A ref is

13:13

just like a single little state variable

13:15

that you want to keep track

13:18

of changes to. I have a filter.

13:20

It's a ref, starts off as an empty string, and

13:22

then I just bind that with V-model. Syntax,

13:24

super simple. If you take a look

13:26

at how we do this with React, we

13:29

have an input, we have an onChange handler, we

13:32

pass in an arrow function that

13:34

gets access to the event. We

13:36

then are calling our setFilterState

13:38

function, passing in

13:40

e.target.value, and then after that

13:42

we're binding value to be filter, which is our

13:44

state variable. If you look at the

13:46

top of the component, our state

13:49

variable is from useState. I have

13:52

const filter, setFilter, and that's useState

13:54

for the empty string. Even

13:56

the simplest thing, just like simple little state

13:58

management, track of that on an input is

14:00

just so much less boilerplate in, in V

14:03

it's just V model, that's all you need.

14:05

Yeah. I think that

14:07

is something with react specifically and you'll

14:09

know this too, because you did angular

14:11

before react. any of us who

14:14

came from something like

14:16

angular before react, when

14:18

we saw the react means of

14:20

working with form state and react,

14:23

I think my first impression of

14:25

is surely you must be kidding.

14:27

Uh, I have to write a

14:29

function, like my, my form has

14:31

state itself. Like I shouldn't have

14:34

to, you know, automatically

14:36

then hand move that into a

14:38

variable and while having that control

14:40

can be really great. Sometimes if

14:42

you want that control, I

14:44

would argue most forms don't

14:47

need that level of control. You're

14:49

typically reading the value and then you

14:51

can utilize that value inside of your

14:53

control flow or if statements, if you

14:55

want like dynamically stepped forms and stuff

14:57

like that, but to, to actually have

15:00

to take the value individually, individual value

15:02

and set it in the state always

15:04

felt weird to me. If

15:07

you're not doing things like

15:09

manipulating the text string as

15:11

a user's typing, right? Oh, I'm going to

15:13

make this so it only could be lowercase

15:15

and it's automatically lower casing their text as

15:17

they're typing or something like that. So

15:19

yeah, that's a big, big move in simplicity is,

15:21

is the right, right. Call there, I think. Definitely.

15:23

And then there are also these just other little

15:26

niceties that you get used to and react, but

15:28

you forget about. So one thing is self-closing tags.

15:30

Uh, so I teach a lot of beginners and

15:32

that's one of the things when I'm teaching them

15:34

react, they just get so hung up on is

15:36

just, you need that self closing tag on like

15:38

an input or an image with you,

15:41

your template is technically in my code example here,

15:43

if I have a self-closing input, but I think

15:45

that's just cause I write so much react code.

15:47

Uh, you actually don't need, you don't need the

15:49

self closing tag on, uh, things

15:51

in your, in your view app, because it is

15:53

just HTML and HTML by

15:56

design is actually like very forgiving. Like some

15:58

things don't even need a closing tag. Like

16:00

I think is it I think an image tag

16:02

in the HTML spec that technically does not

16:04

have a closing tag But you

16:06

still need it in the React world. So that's

16:08

a little nicety. Yeah, hold on even to jump

16:11

in there real quick Did you see rich Harris

16:13

had like a big post about how svelte is

16:15

parsing? HTML self-closing tags

16:17

incorrectly because everybody kind of

16:20

parses them incorrectly I

16:22

didn't have to send this to you. It's

16:25

really good. I'll post in the show notes

16:27

There's some like really interesting self-closing HTML tags

16:29

about how most people have Generally

16:32

their mental model for how self-closing

16:34

tags works or is completely wrong

16:36

And as somebody who had never heard of this

16:38

before I kind of was Shocked

16:42

at how how this worked so I'll post it

16:44

in the show notes. You can go. I'll give

16:46

it a look for yourselves Yeah,

16:50

I think to that note like react has

16:52

become so prevalent people Kind

16:54

of forget how much it changed in terms of like how

16:56

we how we do things And

16:58

this is one of those things we're like, well,

17:00

yeah, and everything's just self-closing, but it doesn't necessarily

17:02

have to be Yeah, right. Exactly. Yeah, it's a

17:05

reactism. It's not a web web thing. Yeah, exactly

17:08

There's some other niceties here. I feel like I'm

17:10

not giving a like a super basic introduction We're

17:13

kind of jumping around in these code examples, but

17:15

another little nicety I'll show here and maybe that's the

17:17

theme of this is just the little niceties things you

17:20

do so often that you forget about but In

17:22

view when you want to add a event

17:24

handler to an element You can use the

17:26

shorthand at and then the event name. So

17:29

in my code example here I'm adding a

17:31

submit handler to a form so

17:33

I'm saying at submit and then if

17:35

you look at the React example,

17:37

it's on submit and then you

17:39

specify the callback But one of the

17:41

things you do pretty often

17:43

in front-end react code I think I guess things

17:45

are changing now that we have like actions and

17:48

server side codes and stuff is you

17:50

typically prevent the default action on a form submission

17:52

because you want to handle things with JavaScript and In

17:55

view you just say event name

17:58

dot prevent that automatically prevents

18:00

the default action. This is something we do so

18:02

often, and it's beautiful that it's kind of just

18:04

built in there. There's a few other little helpers

18:06

that you can just do dot on, and then

18:08

you don't have to call them explicitly. So in

18:11

the React code example, I

18:13

get access to the event and have to explicitly

18:15

call event.preventDefault. So that's another thing

18:17

that's nice and built in. In

18:20

terms of like conditional rendering. So let's say

18:22

you wanna show something on the

18:25

page. In this case, we wanna show a progress bar

18:27

on the page if loading is true. In

18:29

view, there's a directive called vif, and

18:32

then you pass in a variable. If that

18:34

variable is true, that element will render out.

18:37

If it's false, it won't. And

18:39

in React, there's nothing built

18:42

in. We just use either, I don't

18:44

even know what this is. You know what this is

18:46

called where you have like variable and something? I don't

18:48

even know a name for it. Yeah, when you use

18:50

the double ampersand in the templating syntax, I

18:53

don't know if there is a name for it. It's just like, I

18:55

mean, it's just exploiting conditionals in JavaScript.

18:58

It's really what it is. But yeah, I

19:00

know that's always bugged me about React because

19:02

it's not super readable. If you don't know

19:04

what it is, sure. Once you learn what

19:06

it is, it is what it is and

19:08

you got it. But if you were new

19:10

to React, you'd look at that and be

19:12

like, why are they doing it that

19:14

way? And if statement

19:17

to me is always read much cleaner, do

19:19

you maybe wanna take a second on the

19:21

word directive and maybe explain what

19:24

that is? The way that you use

19:26

them is just as attributes on

19:28

your elements. So in this case,

19:30

we have a progress element and then you see

19:32

a little attribute there, V dash if equals double

19:34

quotes and then the value inside of it. So

19:37

we call them directives. They really just are like

19:40

special attributes that do something specific inside

19:42

of view. And so earlier that V

19:44

dash model one, that's also a directive.

19:47

There is a directive V dash show

19:49

which will set display none on

19:51

an element instead of actually removing it like

19:53

VIF would. So VIF literally removes

19:55

it from the DOM versus V

19:57

show ads and removes display none.

20:00

And then there's also v4. So

20:02

when you're iterating over lists of elements,

20:04

you have v4 and you say

20:06

v4 element in elements, or

20:09

like the list name. They're just

20:11

attributes, but they're kind of like domain specific

20:14

attributes to when you're working in Vue.js. Did

20:17

you know that the word directive was

20:19

first used in Angular? I didn't know that. I figured

20:21

it came from something else before that. It

20:24

was my first exposure to it, so yeah.

20:26

Same, I just figured it existed before that.

20:29

I think the early days, a lot

20:31

of the terminology was actually stolen from

20:33

Angular 1, or borrowed from Angular 1.

20:37

Like when I first started learning Vue.js, it

20:39

was very soon after having

20:42

used Angular 1 a lot. And

20:44

so vif is ngif

20:46

in Angular, and v4 is

20:49

ng. Is it ng4 in

20:51

Angular? Yeah, I think it is. It

20:53

was. Yeah, or then ngmodel is in

20:55

Angular. I think it's sort of similar

20:57

these days to when more modern Angular,

20:59

but some of the stuff has changed a

21:01

little bit. But yeah, a lot of this stuff was borrowed

21:03

from the early days of Angular. Yeah,

21:05

wild stuff, yeah. So

21:08

another thing I really like about Vue.js

21:10

is its built-in way of handling styles.

21:12

So first of all, I haven't talked about

21:15

this yet, but Vue.js has this concept of

21:17

SFC, or single file components. So everything related

21:19

to a component is in that same file.

21:21

And so in an SFC, you will have

21:23

a template. So that's where all of your

21:26

HTML goes. You'll have a script. That's

21:28

where all of your TypeScript goes. And

21:30

then you'll also have a style tag, all of

21:32

which are optional, depending on whether or not you

21:34

need those things in a component. But

21:37

a typical SFC will have a template, a script, and a

21:39

style. But one of the really

21:41

nice things about this is this idea of

21:43

scoped styles. So if you just put the

21:45

attribute scoped on your style tag, now these

21:48

styles will only apply to this component. And

21:51

this has been built into Vue.js as

21:54

long as I've been using it, which is crazy, because when

21:56

you get into the world of React, there's

21:58

so many style solutions just to make it work. just solve this

22:00

one problem, right? Like I want to style a component, but I

22:02

don't want to style everything else. So you

22:04

have things like styled components, CSS and

22:06

JS, CSS modules, which isn't

22:08

React specific, but it is one way to do it

22:11

as well. And I will die on, I will

22:13

die in this weird little hill

22:15

that Tailwind is a strategy

22:19

for scoping CSS. People

22:21

find that point to be odd, but I

22:24

will die on that hill that

22:27

Tailwind exists within popularity in React

22:29

world because it is solving scoping

22:32

in addition to default styles, whatever. But scoping

22:34

is a big reason why people end up

22:36

using it. Yeah, it

22:39

is. I mean, I guess we

22:41

don't want to get into that, David. It comes with

22:43

downsides of like duplication and whatever else. But yeah, like

22:45

if you're going to be putting styles everywhere you need

22:47

them, they're going to be scoped to exactly where you

22:50

use them. Exactly. Yeah, so

22:52

that's one of the cool things. It's just

22:54

built in. You don't have to install another

22:56

library. Svelte definitely took inspiration here because by

22:58

default a style tag in Svelte is scoped.

23:01

Whereas in Vue you have to opt in. There's

23:03

an attribute called scoped that you specifically put on

23:05

your style tag to make it scoped.

23:08

Otherwise they're global by default. And

23:10

then the other thing is actually just like working within

23:12

in binding style. So I'm going to pull up in

23:15

the Vue docs really quick. There's

23:17

section on working with class and

23:19

style bindings. So in

23:22

the world of React, because it's just JavaScript

23:24

and I'm air quoting for all the people listening at

23:26

home, it's just JavaScript. If

23:29

you want to conditionally bind like a CSS class

23:31

name, you could use like a ternary, right? You

23:33

could just like embed a ternary there and say,

23:36

if this state value is true, then yes, apply

23:38

this CSS class name. But because

23:40

we do that so often, there are libraries that have

23:42

popped up in the React ecosystem, like

23:45

I think it's called CLSX, or there's

23:47

another library called just class names. And

23:50

so basically when you're working with

23:52

conditionally applying classes in React, you

23:55

have to bring that library in and then it makes it a

23:57

little bit nicer for adding and

23:59

removing classes. conditionally if you need to. This

24:01

is just built into Vue.js, and

24:03

it has been, since as long as I've used it. So

24:07

if you want to bind a specific class name,

24:09

you do colon class equals, you

24:11

then do object syntax, and then every

24:13

key of the object is the class

24:15

name that you want to apply. And

24:18

the value is an expression. If

24:20

it resolves to true, that class will be

24:22

applied. And so in this example, we have

24:24

an object with the class active and

24:27

colon, and then the expression is active. So

24:29

is active would be some state variable. And

24:31

if is active is true, that

24:33

class gets applied. But this is really

24:36

nice because if you have five or six

24:38

different conditional classes that are all dependent on

24:40

various conditional states, the syntax is pretty cool

24:42

because it's just an object specifying class names

24:45

versus having to pull in another library or

24:47

having a bunch of nested turnaries and stuff

24:49

like that. Tick. Yeah,

24:51

I love that. And for those of

24:54

you wondering why you might want your

24:56

style scoped, I know we did

24:58

cover a little bit of that. But

25:00

when you scope your styles to a component, it

25:03

makes it really easy to prevent writing

25:06

styles in one place that

25:08

then are affecting something in a

25:10

completely unexpected place of your application. For

25:13

instance, you apply an h1

25:15

element. You give

25:17

it a color of red inside of

25:19

a component CSS somewhere. Next

25:22

thing you know, all of your h1s on your site are red,

25:24

and you have no idea where that is. You

25:27

have to do command find. If you scope your

25:29

CSS to that component, then only

25:31

the h1 inside of that component will

25:34

be getting that color. I

25:36

really prefer hard scoping. So

25:39

I tend to even when I wrote Vue, I tended

25:42

to scope everything hard to the component

25:45

instead of trying to work globally a

25:47

little bit more. I think

25:49

personally, it puts you into

25:51

that more component-based mindset. Definitely.

25:55

And I guess I will add specifically this

25:57

class attribute for binary. that

26:00

technically doesn't have to be scoped. It kind

26:02

of like works outside of the scoping system, but

26:05

it is a way of conditioning applying classes as well. Sick.

26:08

Okay, so CSS sounds great. I love all that

26:10

stuff. And it is funny

26:12

how much my head nods because I like

26:14

all of this stuff from Svelte as well. The

26:17

view approach is just a little bit different, right? But

26:20

let's talk about state management. What's

26:22

built in? What does it do? What do you

26:24

have to bring? Do you ever have to go

26:26

to user land for anything in state management? You

26:29

typically don't. It's typically all built in. And I

26:31

guess let's give a quick history lesson of

26:33

working with state

26:36

inside of view. So if

26:38

you're watching on the video pod, I'm in the Vue.js

26:40

tutorial. And they have these really cool little toggles

26:42

where you can toggle between the different kinds of

26:44

ways of defining a component. But it

26:47

used to be that your component

26:49

would have a data

26:51

property associated with it, a data method. And that

26:53

data method returns an object.

26:56

And any properties on that object are your state.

26:59

And then you can access any of those things

27:01

inside of your template. So

27:03

this is kind of like the options API or

27:05

like the older way of doing this. One

27:07

of the nice things about Vue is

27:10

they have maintained compatibility with the older API. So

27:13

even though this isn't the modern way of

27:15

doing things, you can still use the options

27:17

API. But then they introduced

27:19

the composition API. And so this

27:22

is a little bit closer to hooks in React.

27:24

And so instead of having that

27:26

data method, you now have these little

27:28

functions where you can use

27:30

to then define your state values.

27:33

And so we talked about them earlier, but one of them is

27:35

ref. So if I want, in

27:39

this example, a string property called title

27:41

class, I'll use the ref function, pass

27:43

in a string. That'll be the default value. And

27:45

then I can reference that inside of my template

27:47

by name. And so that's how you define variables.

27:50

You're using ref. There's also something built in

27:52

called reactive. Reactive allows

27:54

you to do this for an object. So

27:58

maybe you have an object with four different functions. four

28:00

or five or six different properties. Let's

28:02

say you're implementing a form and you want to

28:04

keep track of the values of

28:06

all the inputs on that form. You probably have

28:08

five or six of those. You might create a

28:11

state variable called form and

28:14

use reactive and then you can pass in an object

28:16

with all of the properties of the default values of

28:19

that form. So that's how you define it. It's pretty

28:21

straightforward. But one of the things I really like about

28:23

it is that it is mutable. We

28:26

do not have to jump through

28:28

hoops to update our values. We don't have to

28:30

call a special method like set state. We

28:33

can literally just reassign a value and

28:35

the view automatically updates. I'll

28:37

show an example in the autocomplete

28:40

UI example that I was talking about

28:42

earlier. So for instance,

28:44

we have a loading variable. So in

28:46

view, I'm saying const loading equals ref

28:48

and then I'm passing in false. So

28:50

that loading variable starts off as false.

28:53

And then later on, whenever the function

28:55

is called that needs to update that variable,

28:57

we just say loading.value equals false. We don't

28:59

have to call set state or anything like

29:01

that. Under the hood, Vue.js is using

29:03

proxies. So it can basically know exactly when

29:06

you are setting values here

29:08

and then update the view accordingly. If you

29:10

compare that to React, we have our classic

29:13

little use state hook here. So we say

29:15

use state, pass in the default value of

29:17

false. That gives us back the variable loading,

29:19

but it also gives us a function set

29:22

loading that we call in order to update

29:24

it. And then if we

29:26

ever need to set that function or sorry,

29:28

set that variable, we have to call the

29:30

set loading variable. And so this is a

29:33

very basic example. It's just a Boolean. But

29:35

where this really shines is in deeply

29:37

nested complex data. So

29:40

have you ever had a Redux store or any

29:42

other deep store in

29:47

a React app that has an array and

29:49

then that array has objects inside of it

29:51

and then those objects have properties that are

29:53

objects themselves? If you ever need

29:55

to update one of those deeply nested properties,

29:58

you have to do so much. just to do it

30:00

in an immutable way, right? You have to map the

30:02

array, and then you potentially have

30:04

to spread each nested object. And

30:06

then if you're doing a nested nested object, you have

30:09

to spread that as well. So I

30:11

don't have an example to show you right now, but things

30:13

can get really, really hairy. And when

30:16

you're dealing with deeply complex and

30:18

nested state, but in view, you

30:20

don't have to deal with that because you

30:22

literally just update the property and the view

30:24

automatically updates. There's no need to

30:27

do immutable state updates. Yeah,

30:29

if you're looking at the video pod

30:32

and you're seeing these ref functions and

30:34

stuff like that, you may say, hey,

30:36

this looks exactly like how Svelte is

30:39

doing runes. In fact, the new runes

30:41

for Svelte, I think borrows

30:43

a lot from Vue.js in a very

30:45

positive way. And I think that would

30:47

kind of rub some people the wrong

30:49

way at first within this Svelte world,

30:52

just because, all right, now you gotta

30:54

use a function to create state rather than

30:57

just creating a variable. But honestly, I think

30:59

the benefits like you're talking about with this

31:01

fine-grained reactivity and unifying how state

31:03

is done is such a, it's

31:06

a really power move from Vue from

31:08

the start. I really do

31:10

appreciate the approach to state there.

31:12

Anybody who's ever written Redux probably

31:15

was like, why do I have

31:17

to call a thing that calls a thing, that updates

31:19

a thing, that spreads a thing? Like, there's

31:22

eight steps to do a thing. And Redux

31:24

was fine, but most of the

31:26

time you don't need to jump through eight

31:28

hoops and create a new object full of

31:30

data. You just want to update

31:32

one single thing and have the application respond, right?

31:36

Definitely. And in the world of React,

31:38

you typically, if you're doing this

31:40

at scale, you would probably reach for a

31:42

library, like Imer or immutable.js, because

31:44

they do make it nicer to update things

31:46

without having to like spread and map. I

31:49

think does, is it Zustan that kind

31:51

of has that built in? Or I think you can, it

31:53

has like a plugin for Imer. But again,

31:55

you have to reach for another library. In this case, it's

31:57

just built in. So every app you come across is gonna

31:59

be doing it. in the same way. Yeah,

32:01

I do appreciate that for sure. And

32:03

then the last piece on state management is this idea

32:06

of global state management. So we talked

32:08

about it earlier, but in the world of React, you

32:10

typically are reaching for Redux or

32:12

Zustand or Jotai. All

32:14

of these libraries basically allow you to have state

32:16

that can be easily pulled into components at different

32:18

levels within your application. The beautiful

32:20

thing about the composition API

32:22

here in Vue is

32:25

that it's not restricted to a component.

32:27

So without even using Pina, which I'll

32:29

talk about is their global state management,

32:31

you could literally define a module that

32:33

declares a few of these ref variables

32:36

and then just import it into any component and it will just

32:38

work. There's no weird

32:40

issues about like, well, did you

32:42

call it in the right way or where

32:44

does it get instantiated? You literally can just

32:46

create these refs, import them into other components,

32:48

and it will just work. And

32:51

so I didn't talk about this earlier, but that's

32:53

another nice thing about the composition API in Vue

32:55

is it doesn't have all of these rules of

32:58

hooks when working in React. With

33:01

React, you can't have conditional

33:03

use effects. And also,

33:05

I guess I didn't talk about this, but

33:07

you have to manually specify your dependency array

33:09

for use effects and use memo and use

33:11

callback. In Vue, all

33:14

of that's built in. So in Vue, they

33:16

have a composition function called computed, and this is

33:18

how you would get use memo, but you don't

33:20

have to pass in the dependencies. They can auto

33:23

track those dependencies. They also have a function

33:25

called watch, so you can specify which of these

33:28

reactive variables you want to watch and that callback

33:30

will be called. And

33:32

yeah, it's just nice. A lot of this stuff is built in.

33:34

You don't have to like manually do all

33:36

of that, mainly do the tracking. And

33:38

those same functions that I mentioned, like computed and

33:40

watch and anything else built into the composition API,

33:42

all of those can be used outside of a

33:45

component defined to do the things the way

33:47

you want and then just import it into any other component. Wow.

33:50

Yeah. Yeah. All

33:52

this stuff will make your head spin a bit with React when

33:55

you really start diving in there, right? When you

33:57

really start getting into complex

33:59

state management. management or just in general

34:01

with React having to think

34:03

about when is this

34:06

function running, how many times

34:08

is this function running, which

34:10

things I actually have to reach for to make

34:12

sure this function doesn't run too many times and

34:14

cause my application to slow down. It

34:17

is just nice to have that fine

34:19

grained reactivity right there in the

34:22

app. Definitely. And

34:24

beyond that, for global state management, there's this library

34:26

called Pina. Basically we're using

34:28

those things that I talked about that are built into

34:31

Vue.js. We're using ref, we're using computed, so we can

34:33

define all of our computed values, all of our state

34:35

values, do whatever we need to do,

34:37

also define methods that operate on those values and

34:39

then just return the things that we need elsewhere

34:41

in the app. I would

34:43

argue that this is much closer to just JavaScript than

34:45

the kind of things you have to do in React.

34:47

These are just a few methods as you call it.

34:51

You literally return an object. There's nothing special

34:54

about how to use the return value here or

34:56

whatever else. Yeah, this is

34:58

the Wes is away so we can

35:00

hate on React episode. Oh

35:05

yeah, man, I'd never seen Pina before.

35:07

This is in my time of using

35:09

Vue. I don't think this was really

35:11

widely used or a thing. So

35:14

it's interesting. I didn't know this

35:16

existed. So, huh, cool

35:19

project. That's one thing that the Vue ecosystem

35:21

has, that this fault ecosystem

35:23

doesn't have in the same way. And

35:26

I'm not necessarily putting Svelte down for

35:28

this, but the React ecosystem, what does

35:30

it have? It has a lot of

35:32

mature libraries and a lot of users. And

35:34

the one thing that the Vue ecosystem also

35:36

has, a lot of mature

35:38

libraries and a lot of users,

35:41

people building actual stuff. Definitely.

35:44

So I would say, if I'm trying to convince

35:46

you to use Vue over Svelte, that might be

35:48

one point, right? It has been around for a

35:50

long time. There's a lot of maturity

35:53

in the libraries that are out there. At the same

35:55

time, I mean, I do have to go to bat

35:57

for Svelte as well. A lot of times you can

35:59

just... use the JavaScript version of a library. You don't

36:02

need like Svelte specific things, which is

36:04

nice. But for certain aspects, like

36:06

maybe even like a mapping library or some

36:08

of these other things that you do pretty

36:10

often, there very likely is an existing library

36:12

that is battle tested and running in production

36:14

for a while because it's been around for

36:16

so long. Yeah, for sure. Okay,

36:18

so we talked about styles,

36:20

we talked about state, we talked about

36:23

templating all the things that you're doing when you're

36:25

building your stuff. But what

36:27

about application building, right? Next.js,

36:29

whether you like it,

36:31

or you don't like it, it is mature. Svelte

36:34

kit, really great. Astro, really

36:37

great. What's the full

36:40

stack application platform

36:42

for Next.js? And

36:44

how does it stack up? Yeah,

36:46

so the Next.js equivalent in the view world

36:48

is a thing called Nuxt. And

36:51

it's very similar. They have file based routing,

36:53

they have API routes. But in my opinion,

36:55

it kind of like goes above and beyond

36:57

what even like Nuxt.js does, or

37:00

sorry, Next. It

37:04

goes beyond what Nuxt.js does. And I

37:06

mean, you mentioned that Next.js is, I

37:09

guess mature, but like the app router is pretty new.

37:11

And like, I've tried to build

37:13

some more complex things with like app router and like

37:16

actions, and it still feels like half baked,

37:18

it still feels like they're trying to figure things out.

37:20

Sorry, you can go back in the

37:23

archives of syntax. And within the first

37:25

10 episodes, I'm talking

37:27

about how Next.js is

37:29

not for me. And I don't know if it's

37:31

gotten any closer to being for me not to

37:33

put it down because it's a great piece of

37:35

software, but it's not for me, it never has

37:37

been. And it's

37:40

nice to hear that Nuxt

37:42

just isn't a straight up clone of

37:44

Next.js or something. Yeah,

37:47

I think there are a lot of

37:49

things that Nuxt did first that like

37:51

even SvelteKit have learned from and like

37:53

Next.js have learned from. Though these days, it

37:55

kind of feels like Next.js and SvelteKit are

37:57

kind of like converging to like very similar

37:59

solutions. But one of the things

38:01

I like about Nuxed, which some people initially

38:03

kind of hate, is this idea of auto

38:06

imports. Because you

38:08

can have a components folder to find some

38:10

reusable components in there, and

38:12

then just use those components in

38:14

your pages and in your other components,

38:17

they are auto imported. And then there's

38:19

a lot of other- You said you hate that? No, no,

38:21

I like it. Okay, I like that as

38:23

well, okay. Yeah, it's less boilerplate. I mean,

38:26

the thing is, when you look at an XJS app

38:28

or a React app, I guess

38:30

it's nice that you can look at the imports at

38:32

the top and see everything that is being used. But

38:35

when you're working in a large application, you're gonna have

38:37

10 or 15, maybe 20 different imports. And

38:42

so that's a lot to manage, especially if you think

38:44

about, okay, there are two different components that are slightly

38:46

similar, but they all depend on those same imports. Now

38:48

you have these imports all over the place. So in

38:51

a larger code base, I like the

38:53

idea of auto imports. You know what, I do too. And

38:56

I used to, I did it on syntax

38:59

because I thought Wes would kill me if I did

39:01

this. But on level up tutorials, I've made gratuitous use

39:03

of them. And I did

39:06

so using sveltkit-autoimport is

39:08

the comparable package. Yeah,

39:10

it works great. I

39:12

used it quite

39:14

frequently and really enjoy that. So if

39:16

you're interested in that technique, it's nice.

39:19

Nice, but yeah, the way Nux works is like

39:21

it's just built on top of you. So it

39:24

works on the idea of single file components, but

39:26

it uses file-based routing. So for

39:29

any page that you want, instead of having to

39:31

use like the view router library, you just define

39:33

these pages as separate files and then they'll be

39:35

routed to according to their name. And

39:37

then the other nice thing built into it is like these,

39:40

the way that you're able to create API

39:42

functions or like server-side codes. And

39:45

I haven't played around with it recently, but I was playing

39:47

around with it when they initially came out with Nux 3. And

39:50

they had already thought about this idea of

39:52

full stack type safety and

39:54

being able to write fetch code

39:56

once that works both on

39:59

the client and the server. and pulls in

40:01

all of the types. So you could define

40:03

an API route in the

40:05

API folder, and it's gonna be just your standard

40:07

server-side request handler, and you can do database stuff

40:10

or whatever else you want. And then

40:12

in the component, when you use fetch, if

40:14

that code is running on the server side,

40:16

it's not gonna make an API request, it's

40:19

running within the same code base, so it

40:21

can actually just directly invoke that API function.

40:24

And then if that code is running on the

40:26

client, it will actually make a fetch request. But

40:28

I think SvelteKit is doing this now. They

40:31

were one of the first to do it, and

40:33

because of that, you get full stack type safety.

40:35

So whatever gets returned from that API function, that

40:38

type is exported and usable on

40:40

the other side whenever you're calling it with

40:42

fetch. Yeah, I love that. Love that full

40:44

stack type safety. And that's such a huge

40:46

win, right? Remember, we used to

40:48

have to do API calls via

40:50

a use effect. You're hitting a fetch, and

40:53

then you get your thing back, and then you gotta just

40:55

pray and hope that that data comes in with the right

40:57

types. You just assign it

40:59

to the type and maybe cast it or something like that. And

41:02

yeah, I love it when you can

41:04

just have your data available in the

41:07

component automatically, know that the types

41:09

are gonna be accurate to what you're expecting.

41:12

I'm interested in the future of Vue

41:18

because we're seeing a convergence on

41:20

the idea of compilers for

41:22

our front-end frameworks. I think Svelte

41:24

and SolidJS really proved that

41:26

the compiler is a good

41:29

idea for many ways in

41:31

your application. It can

41:33

do a lot of powerful things for your

41:35

front-end code. And now React

41:37

has introduced a compiler, and React

41:40

folks are getting their eyes opened to why

41:42

that's so great. What's the Vue

41:44

story there? Because I have heard that there

41:46

is a Vue compiler, but I don't know

41:49

anything about it. Yeah,

41:51

well, first I'll start with, they

41:53

have had a compiler-esque code for a

41:55

long time, so the thing that

41:57

you're talking about is Vue vapor. That's their

41:59

new- way of having your same view component,

42:02

but then compiling it into codes that doesn't

42:04

require a virtual DOM. Cool. But

42:06

the view build process itself has actually

42:09

had an optimizer built in

42:11

for a very long time, where if you're

42:13

doing certain things that maybe you didn't, maybe

42:16

you have a variable that never changes and

42:18

you're rendering that in your template, it was

42:21

smart enough to remove it as even a

42:23

variable reference and just embed it right in.

42:25

And then there are other types of optimizations that it could

42:28

make. View itself has

42:30

had optimizations and compiler-esque things for

42:32

a very long time. But the

42:34

idea of purely stripping away the

42:36

entire runtime and virtual DOM and

42:38

everything else, that's definitely a newer

42:40

thing. And view vapor is

42:42

the idea there. And so it's still in

42:46

research mode. They're working on it, and

42:48

they want to have

42:50

first-class support for it and make it opt-in. So

42:53

eventually, you'll have this vapor attribute that you

42:55

can just add to your component. And once

42:58

you add that on there, it's going to

43:00

get all of those optimizations and basically just

43:02

get compiled into native JavaScript code. It won't

43:04

need a virtual DOM anymore or any

43:07

sort of view runtime to be able to run those components. OK,

43:10

cool. So that is something that we

43:12

didn't mention, that I think it is

43:14

good to be explicit. So without this,

43:17

view does run on the virtual DOM

43:19

and not the actual DOM. And with

43:21

this, it becomes virtual

43:23

DOM less? That

43:25

is correct, yes. Cool. I

43:29

know the virtual DOM is a cool idea, and

43:32

I know it was made for reasons. But

43:35

I got to say,

43:37

as a web developer, I'm not using my

43:40

web tech to do other times.

43:43

I'm not building command line

43:45

CLIs or whatever with React, like some people

43:47

are doing. I'm not using

43:49

the front-end framework to build things

43:51

other than websites, web apps, desktop

43:54

apps with web view, those types

43:56

of things. The concept of

43:58

a virtual DOM never made a ton of sense. to me,

44:00

it always felt like it was stepping

44:02

in the way. But I do get

44:04

that it exists for reasons, you know, as

44:07

a higher level, it's it's it makes

44:09

it work without having to necessarily be explicitly

44:11

attached to the DOM. I get that. So

44:13

I love to hear a there's

44:15

a virtual DOM less world here. Definitely.

44:19

Okay, so all of this sounds great view

44:22

is great. I've been a long time big

44:24

fan of view. But

44:26

many people out there are still stuck

44:28

in the world of sure,

44:30

but are people using it? Yes, view

44:33

sounds great. Yes, it's easier. Yes, it

44:35

will make my life less annoying when

44:37

I'm working in my code. But

44:40

are people actually using it? So CJ, are

44:42

people using VJS? They

44:45

are. Yeah, they absolutely are. And I

44:47

guess one one indicator you might look at is

44:49

like GitHub stars. It's not the best indicators, kind of

44:51

just a little bookmark, you know, that people are interested in

44:53

this thing. But the original Vue JS library has

44:56

207,000 stars on GitHub. And then recently

45:00

with version three, they forked or they didn't for

45:02

they have a new code base called core. And

45:05

that code base has 45,000 stars.

45:07

But if you want to look at actual usage, the

45:10

view library on NPM gets

45:12

4.7 million weekly downloads. And

45:15

to me, that's, that's that's

45:17

huge. That means people are using it like people are

45:19

installing this and using it. It

45:21

doesn't get as much coverage and as much hype

45:23

as like Svelton view does on on X or

45:25

Twitter or whatever. But people are using it and

45:28

they're building real stuff with it. And I guess

45:30

also if you if you want to talk about

45:32

the community, they have a really big discord. Yeah,

45:35

so there are 123,000 members of the Vue JS discord. And

45:39

it's very active. If you ever have like

45:41

Vue JS questions, you can go in there, ask,

45:44

are happy to help that they use the

45:47

same discord, I believe for like Pina

45:49

and view router. Maybe

45:51

Pina has a separate one. But ultimately, everybody's

45:53

hanging out there in that discord if you want to get

45:55

help. But yes, people are using it. It's a very big

45:58

community. It's just not as loud as some

46:00

of the other things that we're used to. Yeah,

46:02

it's not wild how that happens. I wonder

46:05

why that is with how we end

46:07

up in bubbles like this or

46:11

everyone talks about React, but yeah, people are

46:14

building great stuff with Vue and I think

46:16

this conversation has really come to a head

46:18

lately with the whole Laravel discussion that's been

46:20

happening somewhat recently on Twitter where yeah,

46:23

people are building things with Laravel. They're

46:25

building things with Vue. And sometimes it

46:28

just feel like people are just talking

46:30

about React, not that people aren't building

46:32

things with React, but it

46:34

does, you know, there's

46:36

a weird thing where there isn't as much

46:38

dialogue but there is quite

46:40

a bit if, you know, just

46:43

absolute amount of people like

46:45

really being productive with this

46:47

framework. So yeah, people are

46:49

using it for sure. And I guess the one thing to

46:51

add, which I didn't mention, but you brought up Laravel. Laravel

46:54

actually adopted Vue as their front end

46:56

framework of choice, so Laravel is typically

46:58

a PHP backend framework, but a

47:00

few years ago they made it

47:02

so that if you ever need to do any sort of like

47:04

client side JS, you actually do it with Vue JS. So it's

47:06

a very interesting relationship.

47:09

Laravel is getting more press, but it is actually

47:11

using Vue. So if more people use Laravel, they're

47:14

potentially also gonna be using Vue as well. Sick,

47:17

yeah, that's great. Laravel

47:19

is one of those things we're gonna have to spend some serious

47:21

time on on this show very soon. Cool,

47:23

well, that's it for Vue. If you wanna

47:25

learn more about the history of Vue, you

47:28

can watch the Vue honeypot

47:30

documentary that came out a couple of

47:32

years ago, starring yours truly. I am

47:34

in the documentary and saying nice things

47:36

about Vue, but it's a really, really

47:38

well-made, honeypot makes the best documentaries. They

47:40

do great stuff there and gives you

47:42

quite a bit of history on Evan's

47:45

approach to creating Vue and thinking about Vue

47:47

and the community involvement. So highly recommend that.

47:49

If you haven't seen that and you're interested

47:52

in learning more about Vue in general. And

47:54

if you wanna hear, we did an episode

47:56

a long time ago, Scott teaches WestVue, if

47:58

you wanna hear. Let's talk a little bit

48:00

more about Vue as it was, you know,

48:03

a few years ago. You can hear me

48:05

try to convince Wes that Vue is actually

48:07

pretty good. So thank you, CJ,

48:09

for an updated version of this. I really

48:11

think it clears up a lot. And the

48:13

audience has been asking a lot for Vue

48:15

content. Our potluck submissions have been

48:18

saying, where's the Vue content? So now

48:20

that we have you, CJ, I'm glad that we can bounce

48:22

some of these things off of Vue and get a real

48:24

good opinion here. So thank you so much for that. Definitely.

48:27

Happy to. Let's get into the part of

48:29

the show where we talk about sick pics

48:32

and shameless plugs. Sick pics are

48:34

things that we think are sick, things that we like,

48:37

things that are cool, could be anything. I'm

48:39

going to sick pick a potentially

48:42

controversial shoe. And

48:45

I say that because when my wife

48:47

saw them, the first thing she said, these

48:49

are at-home shoes, right? As

48:51

in you're not going to be wearing these shoes

48:54

outdoors because if you wear these shoes

48:56

outdoors, you're going to be embarrassing me.

48:59

It's essentially, I think, what she was trying to

49:01

tell me. And I'll get

49:03

these posted up here.

49:05

What they are, you've all heard

49:08

of Crocs. Crocs are ugly

49:11

kind of foam shoes that are

49:13

very comfortable. I, however,

49:15

I didn't want to get Crocs, but

49:18

I still wanted comfortable foam shoes. So

49:21

I got the Jordan Slides. They're

49:24

called Jordan Rome. And they're essentially,

49:26

what if Nike made Jordan Crocs?

49:28

They are very much

49:31

Jordan Crocs. In fact,

49:34

we're in them right now. They look

49:36

like the, were they called Yeezys? Like the...

49:39

They look like much less ugly Yeezys. The

49:42

Yeezys kind of look like these got blown

49:44

up in a weird kind of way. These

49:46

look way more like normal shoes

49:49

in some kind of way. Yeah. They

49:51

look like a stylish Croc for sure. And

49:54

they weigh absolutely nothing. They're

49:56

super cushy, super foamy. They're

49:59

60 bucks. you think Jordans, you're

50:01

going to be spending 150 bucks. No, these are just

50:03

like 60 bucks, nice

50:05

and foam shoes. And for somebody whose

50:07

office is just right

50:10

down the street from their house here, I'm wearing them

50:12

to the office every day

50:14

here. And unfortunately, my wife will not allow

50:16

me to wear them outside of the house

50:19

in public, but you know, I can wear them at

50:21

least in my office. Nice.

50:25

My sick pic has to do with charging devices. I'm going to

50:27

grab it. So

50:29

I don't know why it was so late to the game, but I

50:32

was charging things with a bunch of charger blocks

50:34

for the longest time. But just recently I got

50:36

a single unified interface with a bunch of USB

50:39

charging ports and also like power

50:42

delivery ports. And it really cleaned

50:44

up my desk. So this is my pick. I don't have

50:46

a specific brand. If you just search for like multi USB

50:48

port on Amazon, you'll find something interesting. But yeah, this works.

50:50

It cleans up my desk and I don't know why I

50:53

didn't get it sooner. Yeah, that's,

50:55

that's a good sick pick. Anything

50:57

to, to clean off

50:59

your desk is something I was just just

51:01

talking to you about this before the show

51:03

started. It's, it's Tuesday and

51:05

my desk has somehow in two

51:07

days gotten completely covered with who knows

51:09

what. So having less stuff on

51:12

your desk is always, always a good thing. Cool.

51:14

Well, let's get into shameless plugs. I'm

51:17

going to shamelessly plug. Actually, you know

51:19

what? I'm going to shamelessly plug the

51:21

syntax GitHub. You know, we, we kind

51:23

of plug different things and I've never

51:26

plugged the GitHub. What's

51:28

cool is that we have the website

51:30

code. So if you're interested in seeing how

51:32

we built the website, the codes

51:34

on there, I've recently

51:36

published a theme for Zed. I also

51:38

have a theme for VS code that

51:41

I need to move into the syntax

51:43

repo or the syntax organization. We have

51:45

some really interesting stuff here. I'm working

51:48

on a YouTube tools app that allows

51:50

you to perform mass

51:52

find and replace on YouTube videos from

51:54

your own, your own, your

51:57

own home here tools. We have our brand assets.

51:59

We have a. repo that's just all of our

52:01

brand assets. Some really interesting

52:03

stuff. So if you wanna see

52:05

some of the code we're working

52:07

on over here at Syntax, check

52:09

out the github at github.com,/orgs,/Syntax FM.

52:12

I'll post the link in the

52:14

show notes. Nice,

52:16

and I'm just gonna plug the website on that note

52:18

because you may not realize it,

52:20

but syntax.fm, you can listen to all of these

52:22

episodes and search across them. So if I'm ever

52:24

trying to find like a specific topic, like view

52:26

or react, and I wanna see when it was

52:28

covered, syntax.fm has got a really great built-in search

52:30

engine, and Scott has been making updates to the

52:32

site. So the built-in player

52:34

works a little bit nicer, like keeps track

52:36

of when and where you were watching and

52:39

like what episode you're on and stuff like

52:41

that. So yeah, syntax.fm, check it out. Yeah,

52:43

the latest feature that is currently in a

52:45

PR, and it's only being blocked by one

52:48

TypeScript error, it's one singular TypeScript error that

52:50

I have to fix, is adding

52:53

play offline mode. In fact, we recorded an

52:56

episode about how we built it, but allows

52:58

you to click save, and then what that

53:00

does is it caches the MP3 to your

53:02

computer, so that way when you click

53:04

play, it's not loading it from the network, works

53:07

on your phone, works on your

53:09

desktop, you can cache a whole bunch of them,

53:12

and eventually we'll be able to load up queuing

53:14

like you have on an individual podcast player. So

53:16

whenever you queue something, it'll automatically

53:18

download it, so the next one plays, you

53:20

don't have to worry about network conditions and

53:22

stuff like that. So a lot of updates,

53:24

a lot of cool stuff coming, and we're

53:26

just pushing code all the time to this

53:29

thing, so check it out, and again, all

53:31

this code is public, available to you if

53:33

you wanna see the code as well. Cool,

53:35

well that's it, thank you so much for

53:37

watching or listening wherever you are at. If

53:39

you want to watch this podcast, head on

53:41

over to youtube.com/at syntax FM, either

53:43

or, thanks for joining us today, we'll catch you

53:45

in the next one, peace. Peace.