0:05

Welcome

0:05

to the Cone Beauty podcast where we

0:07

talk to people on their coding journey and have helping

0:10

you on yours. I'm your host, Sirona.

0:12

And today, we're talking about the new wave

0:14

of front end developer tools with Chris

0:16

Ferdinandi. author of the Vanilla

0:18

JS Pocket Guide series and creator

0:21

of the Vanilla JS Academy Training

0:23

Program.

0:23

I can remember early in my

0:25

career when I was able to talk about

0:27

responsive web design and concerns

0:30

around mobile and best practices

0:32

and usability. There were developers who were lot

0:35

more senior than me who were lot less versed

0:37

in this sort of thing, and it put me

0:39

in a lot of conversations I wouldn't have been in

0:41

otherwise.

0:42

Chris looks back at being on the code to

0:44

be podcast in twenty twenty and what he's

0:46

learned since then. He talks about how he

0:48

sees front end development changing in the next

0:50

few years. what new tools are on the

0:52

rise, and why leaning into these new

0:54

tools might help you in your future job

0:56

search after this.

1:05

Traditional recruiting is

1:07

over. Welcome to the talent cloud.

1:09

Turing dot com is home to the most deeply

1:11

vetted developers and teams matched

1:13

by AI, easily recruit the engineering

1:16

talent, tech leads, and more you need

1:18

to scale your team or build a new one.

1:20

Try a no cost two week trial

1:22

at Turing dot com.

1:25

Advance your career with the thirty days

1:27

to learn it challenge. Complete the challenge

1:29

within thirty days to be eligible for fifty

1:31

percent off the cost of a Microsoft certification

1:34

exam. Visit AKA dot

1:36

m s forward slash c n

1:38

twenty two to learn more and get started.

1:44

Thanks

1:46

so much for being here. Saran,

1:47

thanks so much for having me on. I'm always happy

1:49

to come on the show.

1:50

Yeah, absolutely. So,

1:52

Chris, give us a little background

1:54

about yourself. I know we talked to you

1:57

before, and know that we talked

1:59

about how you change careers from being an HR

2:01

professional to JavaScript expert, which

2:03

is really, really awesome. We had that conversation

2:05

back in twenty twenty. But I'd love for you to give

2:07

just a little bit of context people who may not have

2:09

heard that episode.

2:10

Yeah, absolutely. I'm known on the web as

2:12

the Vanilla JS guy. I didn't coin

2:14

the term, but I do spend a lot of time

2:16

evangelizing JavaScript using

2:19

browser native kind of stuff.

2:21

And I help people learn JavaScript.

2:24

My whole ethos is that there's potentially

2:26

a simpler, more resilient way to make things

2:28

for the web than what a lot of modern

2:30

best practices might look like. And

2:32

so I spend a lot of my time creating courses

2:35

and ebooks running workshops. And

2:37

every weekday, I send out a

2:39

short newsletter with some developer tips.

2:41

straight to people's inboxes. You did

2:43

mention the career change thing. So I actually started

2:46

my career in human resources, did

2:48

that for the first. five or eight

2:50

years of my working life. Mhmm.

2:52

And then I made a career jump. So I've kind

2:54

of got this really weird and unique

2:56

background where I know what the

2:58

hiring process looks like behind the scenes,

3:00

and I've also gone through that process just

3:03

giving up on a career you were in middle of

3:05

to go do something totally different, which was really

3:07

fun and wild and scary. Mhmm.

3:10

Yeah.

3:10

I have that survey to describe it fun,

3:12

wild and scary. Yeah. Particularly

3:14

the scary work. Okay.

3:16

So why the focus on Vanilla

3:19

JS? What does that mean to you?

3:20

So

3:21

the focus on Vanilla JS kind of happened

3:23

by access I originally came into

3:25

JavaScript development via jQuery,

3:27

which was the way to do JavaScript

3:30

on the web at the time. but I kept failing

3:32

the JavaScript portion of front end developer

3:34

interviews. And I felt like I didn't know when I

3:36

was talking about most of the time, I had a huge

3:38

impostor syndrome. And so I decided

3:40

I wanted to learn how a lot of it worked under

3:42

the hood so that I could be more confident

3:45

going into those interviews. And along

3:47

the way, I discovered that as I was converting

3:49

a lot of stuff I had written in jQuery too.

3:51

Using this stuff baked into the browser, my

3:53

sites were also getting a lot more performant.

3:56

Things were running faster. and just

3:58

a better experience for the people who

4:00

were potentially using the things I was making.

4:02

And so that kind of really is what

4:04

hooked me in a web performance angle, which

4:06

was something I cared deeply about.

4:08

You asked what Vanilla J has means to me?

4:11

For me, it generally means

4:13

an absence of dependence fees.

4:15

So it's using the things

4:17

that are built right into the

4:19

browser. So browser native JavaScript

4:21

methods or APIs rather

4:23

than using libraries or frameworks, there's a

4:25

bit of a caveat here because a lot of people

4:27

think that means I write every single line of

4:29

code and everything I build from scratch I

4:31

do make use of a lot of different libraries.

4:33

I just tend to look for ones that aren't

4:35

dependent on another library themselves.

4:38

So you know, if I was looking for, you know,

4:40

like, a photo gallery library, I

4:42

would look for one that just stands on

4:44

its own rather than having to integrate with

4:46

something like React or View or some other type

4:48

of library. Mhmm.

4:49

Mhmm. Yeah. That makes sense.

4:51

So you had pretty strong opinions

4:53

about Vanilla JavaScript last

4:56

time you were on the show a couple years ago,

4:58

do you still have those opinions? Now,

5:00

do you still feel that VINELOJS

5:03

really benefits developers and

5:05

needs to know it should be a priority. Do you still

5:07

have those feelings today?

5:09

I do. I've probably mellowed a little

5:11

bit with age. A

5:13

big part of my passion

5:15

for Vanilla JS is

5:18

that. Well, two things. One

5:20

if you author what you

5:22

create in mostly vanilla JS, you ship

5:24

a lot less code to your end user, which

5:26

means they're using less bandwidth,

5:28

which is particularly important when you're

5:30

working in developing areas or areas

5:32

where wide access to broadband is not readily

5:34

available. But a lot of

5:36

times the actual process of

5:38

building things is easier

5:40

too, at least if you're at a certain point

5:42

in your career, know for a lot of mid level

5:44

to senior engineers, tooling

5:46

can make work a lot faster

5:48

and easier. But for a lot of people who are earlier

5:50

in their career, tooling becomes a

5:52

barrier to entry. And so for me

5:55

understanding kind of the fundamentals

5:57

and really kind of focusing on

6:00

The platform means that you can open a

6:02

text editor and open a browser

6:04

and just start coding and you don't have to

6:06

worry about opening up a terminal

6:08

window and installing a bunch of things and running a

6:10

build tool and then starting up a server and,

6:12

like, you can throw all that away and

6:14

just just start working. And

6:16

even as a more seasoned developer, I still

6:18

find that a very enjoyable experience.

6:20

I do think tools have their place

6:22

I do think they're an important part of what we do

6:24

as a profession, especially as the things we

6:26

build become more complex. But I

6:28

also think that as an industry we sometimes

6:31

over prioritize them.

6:32

Yeah. Yeah. That's very well put.

6:35

So I wanna get into the

6:37

trends that you're seeing

6:38

in the front

6:40

end world. So I know

6:42

that, you know, JavaScript tools

6:44

like view and react are

6:46

very common, very widely used.

6:48

There are definitely a list of things that people

6:50

should look into. They make that list very frequently.

6:53

but you say that there's an emerging

6:55

trend around server rendered HTML

6:57

with little sprinkles of client side

6:59

JavaScript kinda kind of sprinkled around in

7:01

there. So before we get into that trend,

7:03

let's break down kind of some of those basic definitions.

7:05

So what does it mean for JavaScript to be

7:07

on the client side? When we talk

7:09

about client side JavaScript, we

7:12

are talking about code that

7:14

actually gets shipped from a server

7:16

to the browser where it's run. All

7:18

of the front end libraries that we

7:20

use today are client

7:23

side libraries. So something like view or

7:25

react when someone opens

7:27

an app that's been built with those is

7:29

generally downloading view

7:31

dot j s into their browser or react dot

7:33

j s into their browser. and then running

7:35

a bunch of code that calls

7:38

functions that React has or supports.

7:41

Mhmm. And so the client is just a

7:43

another fancy term for the browser.

7:45

Yep. Yep.

7:46

Absolutely.

7:47

And what is server rendered

7:49

HTML? What does that mean?

7:51

So to answer that properly, I think maybe the

7:53

easiest way to answer that would be to juxtapose

7:55

it against what things like view and

7:57

react do. Okay. So with tools like view and

7:59

react, you have some

8:01

templates or some HTML that you've authored

8:04

in JavaScript. And when

8:06

your JavaScript loads, those

8:08

inject HTML into your

8:10

user interface or into the dom

8:12

as it's often called. Mhmm. The

8:14

opposite of that server rendered HTML

8:17

is where the HTML that

8:19

gets rendered into the browser just

8:22

comes that way from the server. So it's a

8:24

dot HTML file and all

8:26

of the elements that are in the UI or many of

8:28

the elements that are in the UI. they

8:30

just came that way hard coded into an HTML

8:33

file. I mean, when I say hard coded, that doesn't mean

8:35

that you necessarily have to

8:37

write dot HTML files and load them to your

8:39

server. You can do that, but there are a lot of tools that

8:41

kind of automate or

8:43

blend blend the lines a little bit here. And

8:45

I guess one other important thing to note

8:47

would be that these two are not necessarily

8:49

mutually exclusive. You can

8:51

use server rendered HTML for some

8:53

things and then layer JavaScript

8:56

rendered HTML on top of it depending on

8:58

your use case. So they're not -- Mhmm. -- you

9:00

have to pick one or the other. that can

9:02

blend together very nicely, which is I think really

9:04

the meat of what we're gonna talk about today.

9:22

For years, Turing dot com and their

9:25

talent cloud have been home to the most deeply

9:27

vetted develop upers matched

9:29

by AI. Fun fact, you can do more

9:31

than scale your existing engineering teams

9:33

with them. You can deploy full

9:35

teams. Turing teams is a dedicated

9:37

development solution for your complex engineering

9:39

problems. Their domain expertise

9:41

and AI powered deep vetting bring

9:43

together the best delivery and program

9:45

managers, tech leads, and

9:47

developers across over a hundred skills and

9:49

twenty seven unique capabilities to

9:51

deliver dedicated development

9:53

success. They build while you

9:55

ask. So go hands off with your hands

9:57

on project at turing dot

9:59

com slash

10:00

teams.

10:03

So we

10:05

talk about the trend of server

10:07

rendered HTML with sprinkles of client

10:09

side JS. What actually is the

10:11

trend that we're

10:12

seeing? For me, one of the things I've noticed because

10:14

I've been doing this for about ten years

10:16

now is every five to ten years,

10:18

we see a big

10:20

shift in the way development works. And it

10:22

never looks like a big shift at the time. It always

10:24

looks like some kind of emerging trends. And

10:26

then before you know it, it completely dominates

10:28

the industry. when I started jQuery

10:31

was the big way to do JS. And

10:33

then eventually, the browser caught

10:35

up. Mhmm. And jQuery, I don't wanna say

10:37

became obsolete leap. But lot of the things it

10:39

did, the browser could also

10:41

do without jQuery. This stuff used to be really,

10:43

really hard and suddenly it wasn't anymore.

10:46

Some stuff was still difficult and so you had this

10:48

wave of transitional tools.

10:50

Umbrella JS comes to mind and they kind of

10:52

bridge that gap and you also had tools like

10:54

low dash and underscores. And then eventually, the

10:56

browser kind of caught up to those two.

10:58

And new library started coming out

11:00

that addressed a new set of problems.

11:02

and that's when we started to see things like Angular

11:04

and then View and then React.

11:06

And there was a bunch of other tools that

11:08

didn't necessarily quite

11:10

that that rise to popularity that that showed

11:12

up at that time as well. And

11:14

I see us at the beginning of another

11:17

shift I'm starting to see a

11:19

handful of tools that

11:21

take some of the approaches or

11:23

the ways that we build interfaces

11:26

today, but

11:28

move the actual generation of

11:30

HTML from the browser

11:32

to the server. So I've seen this

11:34

happen from a few different angles. On

11:36

one end, you've got things like

11:38

next JS and

11:40

next JS. that they're like meta

11:42

frameworks that bolt on to react and

11:44

view respectively and allow

11:46

you to author your React

11:48

or View Code on a server

11:51

running node, and it'll generate

11:53

HTML on the server, ship that to the browser, but

11:55

then also ship react and

11:57

view so that once that initial page

11:59

load happens, JavaScript

12:00

can take over and handle any

12:02

additional changes that need to happen. Those

12:04

are interesting, but they also still ship a

12:06

ton of JavaScript to the browser. So

12:08

then you started to see, on the other end,

12:10

some tools that

12:12

aim to do similar things as

12:14

React and Vue but smaller. So

12:16

you've got React Evanue

12:18

who created Vue, created this thing called

12:20

Petit Vue, which is a, like, a smaller

12:22

version that's intended for

12:24

maybe progressive enhancement or just light

12:26

UI changes rather than building

12:29

the entire app in JavaScript, and that's

12:31

a lot smaller too. And so that's kind

12:33

of one other little subset. And

12:35

then for a while, you also had

12:37

kind of the rise of static

12:39

site generators. So these are tools that

12:41

kind of go in the complete opposite direction.

12:43

And rather than bothering with JavaScript

12:45

at all. You're writing some content

12:47

in markdown and you're

12:49

writing some HTML in depends

12:52

on the the tool, but sometimes

12:54

it's ruby, sometimes it's

12:56

Go, sometimes it's just plain old HTML, but

12:58

it'll take that markdown and mash it into

13:00

some templates and create some HTML

13:02

for you. And then we

13:04

started to see just in the last, I wanna

13:06

say, six to twelve months, these

13:08

hybrid tools start to come into play

13:10

that take some of what Next JS

13:12

was doing and Nux JS and

13:14

some of what the server side tools were

13:16

doing and some of what like React

13:18

was doing and and mash them all together. And this

13:20

is for me where things are starting to

13:22

get really interesting. Mhmm. On one hand,

13:24

you've got a tool like eleven t, which is a

13:26

static site generator, but because it's

13:28

run on node and

13:30

JavaScript, allows you to do a bunch

13:32

of script y stuff on the server that you

13:34

can't always do with some of those other

13:36

tools. And it can run

13:38

dynamically and, like, generate HTML

13:40

on the fly, a little bit like we used to be able

13:42

to do with PHP. So

13:45

I've seen people do these really cool

13:47

interactive apps with Eleven

13:49

t. You've also got tools like

13:51

Sveld and now ASTRO, which

13:54

allow you to write

13:56

your templates in

13:58

a JavaScript y way. So the same

13:59

kind of code you would write with React or

14:02

Vue you do with Stealth. But rather

14:04

than being a thing that runs in the

14:06

browser, it's a compiler. So once

14:08

you've finished, you you

14:10

build your files out into HTML,

14:12

and it will take that code that

14:14

you wrote and convert the mostly

14:16

JavaScript into mostly HTML

14:18

with a little bit of JavaScript to

14:20

just edit the dynamic stuff.

14:22

as needed. You know, so it'll have hooks to do things

14:24

like when someone clicks this button,

14:27

update this element. And rather than putting a

14:29

whole library behind that,

14:31

it'll spit out stuff that looks a lot like

14:33

what you might do if you wrote just

14:35

old school dumb manipulation with

14:37

some vanilla JS. Now why

14:38

would I want that? Why

14:41

do I want HTML compilers?

14:43

Yeah. The big

14:45

benefit of these tools

14:48

is performance. So

14:50

react and view and client side

14:52

libraries like that. Well, I guess there's two. It's

14:54

performance and it's also resilience. But

14:56

so those big libraries,

14:59

they'll share the, like, the minified and g

15:01

zipped size of them. And these are,

15:03

like, kind of compression techniques that you

15:05

can use to make files smaller. But so you look at something

15:07

like React and it's thirty kilobytes,

15:09

minified and g zipped. But That's

15:11

the size that gets sent over the wire.

15:13

And that's still actually quite a bit of code. But

15:15

once the browser gets it, it then has

15:18

to unpack all that code. And it ends

15:20

up being several megabytes in size, it's

15:22

pretty big. And then

15:24

to run that code, the browser has

15:26

to compile it and parse

15:28

it interpret it. There's all these like under the hood things that

15:30

happen before the JavaScript can actually

15:32

run. And then every time you

15:34

go to update the UI, there's a bunch

15:36

of abstraction on top

15:38

that makes those updates a

15:40

little bit slower. And then because you have all this

15:42

JavaScript in place, you get this

15:44

additional thing that happens where, you know, things

15:46

can break. And when JavaScript breaks, the

15:48

browser is a lot less forgiving than when

15:50

HTML or CSS breaks. Interesting.

15:52

So because it is a scripting

15:54

language, everything just stops working. And this is

15:56

like if you ever click a button and nothing

15:58

happens or you open an app and you just get that

16:00

like white screen of death where there's nothing

16:02

at all in browser. It's because

16:04

the JavaScript broke somewhere. Something's not

16:06

working. And one error caused the whole

16:08

house of cards to come crashing

16:10

down. Whereas, With HTML, if you type

16:12

an element name wrong, the browser's

16:14

like, oh, we'll just treat it like a div and move

16:16

on, and it just keeps going. And

16:18

so the benefit of these tools

16:20

is they create an output that gets

16:22

sent to your user that loads

16:25

faster, is less prone to

16:27

breaking, and still gives you

16:29

that state based UI

16:31

authoring experience if that's a thing that

16:33

you like or want. So if you're someone who

16:35

enjoys building apps the way

16:37

you would with a tool like React, You'll

16:39

get that same experience, but you'll produce

16:41

something that is less likely to break and is going

16:43

to work a lot better for your end users.

16:46

Mhmm. And then where things get really

16:48

interesting is there's this newer kid on the

16:50

block astro that

16:53

does the same thing that spelt

16:55

does But rather than having to use

16:57

like a spelt specific set

16:59

of conventions, you can pull in all of

17:01

your favorite libraries. Like, so you

17:03

could pull in a React component

17:06

and some tool that you really like from

17:08

view and a spelt file that

17:10

you were already working on and ASTRO

17:12

will compile them all together and spit

17:14

them out. into just a little bit of

17:16

JavaScript and, like,

17:18

remove the library piece and just pull out the

17:20

good parts. So actually, one of the folks

17:22

who works over at a NetLify in

17:24

developer experience, Jason Langstorf, whose

17:26

last name I'm almost certainly butchering. Jason,

17:28

I'm so sorry. He actually ran a test with this

17:30

where he took this that he

17:32

had built with React and Next and converted it to

17:35

ASTRO using ninety percent

17:37

of the same code. And the

17:39

output client side

17:41

JavaScript was ten percent of its

17:43

original size. Wow. Decreased page

17:45

load time by thirty percent. So just

17:47

huge wins all around for

17:49

the user with the same exact

17:51

authoring experience that he had

17:53

before. Very

17:53

cool. Very cool. So how

17:55

do you feel this will

17:58

affect front end

17:59

development in terms of the process,

18:02

the steps, how would it affect what

18:04

we do in front

18:05

end developer roles? yeah, there's a

18:07

few different views you could take

18:10

of this. One of them is the short term, one

18:12

of them is the midterm, and one of them is the long

18:14

term. So in the short term, I

18:16

don't expect much will change. I think,

18:18

you know, learning things like React and

18:20

Vue are still great

18:22

skills, especially if you're looking for a job you

18:24

can roll into a job with those, like, right now today. I

18:27

think tools like ASTRO make

18:29

the transition from, I know these things

18:32

to I'm doing it this new way a lot

18:34

easier because you can take the tools you're already

18:36

using, make a few changes, and go.

18:38

So they're not necessarily huge

18:40

changes. I think in the middle

18:42

kind of range looking out a

18:44

little bit, we will likely see a

18:46

few things happen. I imagine tools

18:48

like React and view

18:51

just in their raw form will become

18:53

less popular over time. I don't think they'll

18:55

ever go away. The same way that people still build

18:57

sites with jQuery today, and jQuery is

19:00

still huge presence on the web, even though it's

19:02

not necessarily the modern or new new way of

19:04

doing things. And a lot of what it does can

19:06

be done in the browser, still see a

19:08

lot of jquery. So I imagine thing reactive view. They won't

19:10

go away. So if you learn those things today, you can

19:13

continue to use them. But in the

19:15

longer term, I

19:17

expect that a lot of what we use

19:19

libraries for today will

19:21

eventually make its way into the browser. This is

19:23

a trend that we see happen kind

19:25

of a lot where the same

19:27

thing happened with jQuery, where a lot of what

19:29

jQuery could do was in the browser, and then you had these kind

19:31

of transitional tools that bridged gaps for a

19:33

little while, and then eventually the browser

19:36

kind of fully caught up and we moved on to the

19:38

next thing. And so what I'm not sure of,

19:40

I think for me the big question mark,

19:42

is are tools like spelt and

19:44

ASTRO Transitional? Or

19:46

war will they be tools that are gonna

19:48

stick around for a long time. My

19:50

hunch is they will stick around for a while,

19:53

but I'm not entirely sure. The

19:55

other angle here

19:57

because I know we have a lot of listeners who are earlier in their

19:59

career. Learning some of these

20:00

newer approaches, learning how to use

20:03

compilers like spelt and ASTRO, probably

20:05

not a huge like, I

20:07

need to know this right now for the

20:10

job I'm looking for today kind of

20:12

thing. But

20:14

potentially a very powerful

20:16

thing to know one to three

20:18

years from now. Mhmm. I remember when

20:20

I started working in the industry,

20:22

responsive web design was a

20:24

buzzword, and it was very new. And this

20:26

was the time where everybody used to have

20:28

separate mobile top

20:30

sites and they were all set to a fixed

20:32

viewport size. And if you went to

20:34

a browser on your phone, you'd get redirected to,

20:36

like, the m dot my awesome website dot

20:38

com version of the site. If you were lucky, other

20:40

times it would just be oriented for a

20:42

desktop. And I can remember

20:44

at the time every

20:46

interview I went on, I'd ask, like, you know, what's your

20:48

approach to mobile design? And

20:50

you'd get a lot of folks who they viewed

20:52

it as this thing that was gonna come

20:54

and go. remember one interviewer in particular told me, oh,

20:56

mobile's a trend in one that I think is

20:58

mostly done. Nobody wants any stuff on

21:00

their phone. Yeah. And You know, like,

21:02

they were very, obviously, very, very

21:04

wrong because mobile mobile has not only not

21:06

gone anywhere. It's exploded. Yeah.

21:08

But this shift, I think,

21:10

has the potential to be not big as mobile, I think.

21:12

But it has the potential to

21:14

be like that because I can remember at the

21:16

time I was this newer developer

21:18

who was not super

21:21

super great at the way we

21:23

were doing things today

21:25

but I had much deeper understanding

21:28

of responsive web design than a lot

21:30

of the more senior developers did.

21:33

And A couple of years down the that

21:35

put me in a really good position to

21:37

be kind of more of an expert on certain

21:39

stuff than some of my peers.

21:41

And so right now today, I think we're at

21:43

the start of another shift. And if you invest

21:46

some time into learning some of this stuff,

21:48

now you have the potential to be

21:50

seen as the expert in the room in

21:52

a year or three amongst

21:54

people who maybe have a little bit more experience than you,

21:56

but we're ignoring some of this stuff to

21:58

focus on the

21:59

way things work today. And that

22:00

was the Orsha was gonna ask next

22:02

is what time line are we

22:04

talking about, and you kinda just answered one

22:06

to three years. that the way you envision

22:08

kind of these trends really

22:11

being front and center?

22:12

Yes. Although, you know, I'm trying to think

22:14

back now to how things went with

22:16

like React and Vue. because I remember

22:19

React and in particular, Vue kinda showed up a

22:21

little bit late to the party. Angular was like

22:23

the elephant in the room for

22:25

a minute. And it was weird. It was like a trend that started to

22:27

grow very slowly, and then suddenly it

22:29

was everywhere.

22:30

But yeah, if

22:31

we're talking about from today,

22:34

one to three years feels like a pretty

22:36

good bet. I've been seeing more

22:38

conference talks around using

22:40

some of these tools and how you can work

22:42

them into your existing workflows. And so I think

22:44

it's gonna be one of these things that we'll start to

22:47

see more awareness, more

22:49

awareness, and then it's going to be like

22:51

the big thing. and it'll almost feel like unavoidable. Mhmm.

22:53

We're not there yet, but I think we're headed in that

22:56

direction. So

22:57

where does this fit

23:00

into your general thing

23:02

of being the Vidal J. S. guy.

23:04

And Yeah.

23:07

So there's a few -- Yeah. -- have set off

23:09

it in.

23:09

Yeah. So there's a few pieces here. So

23:11

a lot of my advocacy around

23:14

Vanilla JS is really

23:17

born out of a desire to prioritize the

23:19

people who consume our stuff over

23:22

bosses developers. For a while,

23:24

I used to talk about how UX

23:26

is more important than developer experience, and

23:28

it sometimes feels like we have that

23:30

backwards where, you know, we tend

23:32

to really love these tools because

23:34

they make things year us as developers.

23:37

Mhmm. And this

23:39

newer suite of tools feels

23:41

like it I don't wanna say

23:44

inverts that. but at the very least

23:46

puts the user experience back

23:48

in focus as a

23:50

priority where the

23:52

things that you're generating are

23:54

a lot smaller, a lot faster, a lot more

23:56

resilient for the end users. And so I think that's a

23:58

very, very good thing. The

23:59

other piece of this I was

24:02

literally just talking about someone with this

24:04

yesterday about how one of the

24:06

things you learn as you start to get deeper into

24:08

libraries is that a lot

24:10

of what you write in say React is

24:12

mostly Vanilla JavaScript with

24:15

some kind of helpers

24:17

and utilities and stuff thrown on top of it.

24:19

And a lot of my favorite vanilla

24:21

JS methods are things that people

24:23

use in react quite a bit.

24:25

And so I've had a lot of students

24:27

who really struggle to learn these

24:29

tools and then step back and

24:31

focus on Vanilla JS for

24:33

a little bit, and then go back to them and

24:35

find tools like React or Vue a lot easier to

24:38

pick up. because a lot of the kind of the

24:40

nitty gritty details that get glazed over

24:42

in tutorials, they suddenly have a

24:44

better understanding of. And

24:46

so For me, I think understanding

24:49

vanilla JS and also how, you know,

24:51

things like HTML and CSS work are

24:53

going to help people make transitions into

24:55

these tools. a lot easier as

24:57

well. From a bigger picture, I'm probably

24:59

someone who will still continue to just open a

25:01

text editor in a browser and go. But I think

25:03

these tools are gonna be a really great thing

25:05

for both developer teams and

25:07

the people who use the things that

25:09

we built.

25:12

Coming up

25:16

next, Chris talks about how we're gonna see

25:19

another shift in how we

25:21

build website and whether or not it makes sense to

25:23

start looking into new tools

25:25

now after this.

25:37

Achieve

25:38

your career goals.

25:41

The thirty days to learn a challenge will

25:43

help you build skills and start

25:45

your preparation from Microsoft certifications in

25:47

AI, DevOps, low code,

25:49

IoT, data science, cloud

25:51

development, and more. Complete your challenge in

25:53

thirty days and you'll be

25:55

eligible to receive fifty percent off the cost of a Microsoft

25:58

certification exam.

25:58

Visit AKA

25:59

dot m s forward slash c

26:02

n twenty two to learn

26:04

more and get started.

26:10

So I

26:11

want to leverage some of your

26:14

HR experience and kind of bring that

26:16

into this context.

26:19

you were looking for a front end

26:21

job right now and let's say you gave

26:23

yourself three months to prepare, three

26:25

months to get your stuff together, to prepare

26:27

to apply, How would you spend

26:29

your time? What would you learn? And what would

26:31

you do? Oh. Yeah.

26:32

So if I was learning this today,

26:35

if I only had three

26:37

months, I would today,

26:39

I would focus on it depends.

26:41

So Assuming

26:43

you're going for a fun and roll, Yeah.

26:45

If you're just going for blanket marketability

26:48

-- Okay. -- it's really

26:50

hard today to go wrong with

26:52

react. It is just very clearly I

26:55

don't wanna call them, like, market leader. I don't know

26:57

if that's the right word, but it is

26:59

the tool that you see come up the most

27:01

often in job descriptions, and we're

27:03

looking for someone with experience with

27:05

especially at newer

27:08

businesses or job

27:10

descriptions that are trying to attract

27:12

up and coming developers. It's just one of those phrases that

27:14

you can throw on a job description and you know you're

27:16

gonna get a large applicant pool.

27:18

So it pains me to say, but it's hard to

27:20

go wrong with React. if you're

27:22

looking for a job today. The

27:24

other kind of angle here, I think the reason

27:27

why I said it depends is

27:29

because there are still a

27:31

lot of websites and

27:33

web apps that are

27:35

built

27:35

with and use

27:38

jQuery. Mhmm. one of the things I've lot

27:40

of WordPress developers who have told me they haven't

27:42

bothered moving away from jQuery

27:44

because it's already there. It's already loaded

27:46

in the UI in WordPress and

27:48

so That's what he's used to. Yeah. They're they're

27:50

already paying the jQuery tax, so they might as

27:52

well just lean into it. So depending

27:55

on what you wanna do, if you're

27:57

someone who's drawn to, say, the WordPress

27:59

community, the WordPress ecosystem. And there

28:01

are a lot of businesses that run on

28:03

WordPress. There are also a lot of

28:05

legacy applications and I don't

28:06

use this in a bad way, but like

28:09

boring technology at boring

28:11

industrial companies would still run on

28:13

jQuery. And that can be an awesome

28:15

career choice too because they in

28:17

Paywell have really flexible

28:19

work arrangements. You know, they're not kind of the

28:21

hustle and bustle of an agency or

28:24

a startup. So work

28:25

life balance is really important to you, that's not

28:27

necessarily a bad move either. So

28:30

depending on kind of whether you

28:32

want a

28:32

lot of tech and a lot of excitement.

28:34

React,

28:35

if you're looking for something maybe

28:37

a little bit more boring and slow paced, and

28:39

I don't again, I do not mean that in a bad

28:42

way. jQuery

28:42

is not a bad choice either because

28:44

it is still very much

28:46

on

28:46

the web and very much in use.

28:49

And that's if I only had three months. And that's just from

28:51

a technology side. There are a whole slew of other things

28:53

that'd be doing, you know, in conjunction. Would

28:55

it be

28:56

valuable to learn any

28:58

of these emerging new tools,

29:01

these trends we talked about, or would it

29:03

make more sense to wait a

29:05

few years? and kinda see where

29:07

these trends land to start

29:09

learning them. So it depends

29:11

on how long you have. So if we're just talking like

29:13

I've got this three month window. Right. I

29:15

think going either deep on React

29:17

or splitting your time between React and

29:19

jQuery is, personally,

29:20

the way

29:21

to maximize your I'm

29:23

putting myself in the position of, I need a job

29:25

now -- Right. -- I need to pay the mortgage or

29:27

rent, keep the lights on, what have

29:30

you. if you had a little bit more time, if

29:32

you're giving it six months to a year,

29:34

I think learning these

29:37

emerging tools now is

29:40

a good thing to do because

29:42

I'd say sometime in the neck if your

29:44

company's not or the company you go to work for

29:46

is not already having these conversations.

29:49

they will be in the near future. And being

29:51

able

29:51

to confidently speak to

29:54

the pros and cons of different

29:56

approaches you might use to building the

29:58

new thing or updating your existing

29:59

code base is a really

30:02

great thing career wise. Like, I

30:04

can remember early in my career when I was

30:06

able to talk about

30:08

responsive web design and concerns

30:11

around mobile and best practices

30:13

and usability. There were developers who were a

30:15

lot more senior than me who were a lot

30:17

less versed in this sort of thing

30:19

and it immediately positioned

30:21

me as an expert on a

30:23

thing that put me in a lot of conversations I

30:25

wouldn't have been in otherwise. because

30:27

of that. And while it's probably I don't even

30:29

wanna say premature. I just don't think

30:31

you're seeing lots of places in

30:33

the industry immediately jumping to

30:35

these tools. But I'm seeing more and more

30:37

of it. And so I think at some point, these

30:40

conversations

30:40

are gonna come up, and it's a really great thing

30:42

to be able to speak about them.

30:45

Absolutely. So, yeah, I would, if you have the time, if

30:47

you were talking about a slightly longer term view,

30:49

I think now would be a great time

30:51

to start looking at these tools as well.

30:53

especially if you think about something like astro where you

30:56

can learn that in tandem

30:58

with React, where you can do some

31:00

React stuff and then bolt it

31:02

into ASTRO and kind of

31:04

convert your React app into an Astero

31:06

build. It provides you a way to kind of run

31:08

those things side by side and maybe learn these

31:10

two different approaches at the

31:12

same time. or at least one after the other. Yeah.

31:14

That

31:14

makes sense. So for folks who do

31:16

have the time to learn

31:18

some of these tools, Where

31:20

do you start?

31:21

Where do you begin? Right. So I

31:23

actually have not seen a lot

31:25

of tutorials around

31:29

either spelt or ASTRO

31:31

yet, which is probably a note to myself that I

31:33

should You should do it. I should

31:35

consider consider putting some stuff out

31:37

on there. For right now, the websites

31:39

for these different tools, they

31:41

do a relatively good job

31:43

of getting you started. So

31:45

spelt dot dev or spelt

31:47

or astro dot build for astro are

31:50

probably good places to start. One

31:52

other thing that folks might consider

31:55

heading over to Nellify and looking at

31:57

some of their boiler

31:59

plates and their starter demos. They have a

32:01

really robust developer experience team that

32:03

puts together a lot of

32:05

of demo projects with

32:07

these tools because they can be built and run

32:09

on their platform. They have some things

32:11

that might be worth poking around at just to kind

32:13

of if you want like a project in

32:15

progress that you can make some changes to and

32:17

break some things on, that's a good way

32:19

to go. Mhmm. But Selt in particular has a

32:21

really nice tutorial section that walks

32:23

you step by step through

32:25

going from like a very simple hello world

32:27

to adding some interactive and

32:29

it all just runs live in the browser, so you don't need to download anything

32:31

to get started. So that could

32:33

be interesting

32:33

for those.

32:37

Now

32:40

at

32:41

the end of every episode, we

32:43

ask our guests to fill in the blanks of some

32:45

very important questions. Crest, are you ready to fill in

32:47

the blanks?

32:48

Yes. Number one,

32:50

worst advice I've ever received is,

32:52

that you need to have a five year

32:55

plan. Tell me about that. Yeah. So I've

32:57

just always been bad at five year plans and

32:59

I've always been pushed heavily to have

33:01

them. But one of the really nice

33:03

things about our industry is

33:05

that things change so dramatically

33:07

in five years that having

33:09

a five year plan doesn't always

33:11

benefit you. You know, by the time you get

33:13

there, the industry you know, had potentially moved up in

33:15

a very different direction. Yeah. Yeah. So if

33:18

you're, you know, if you're someone who's like, I wanna

33:20

manage people.

33:21

Awesome. If it's more specific. Like, I wanna

33:23

work on this very specific technology. Well, that

33:25

technology might not exist in five years or have gone

33:27

in a very different direction because that's a good

33:30

point. Absolutely.

33:31

Number two, best advice I've ever

33:34

received is. To start

33:36

blogging every day. Oh,

33:38

nice. Tell me about that. Yeah. So I used to

33:40

blog intermittently, and I had

33:42

a business coach a few years back. Tell me

33:44

that I should start writing every day,

33:47

which was ridiculous because I figured no

33:49

one's like a lot of stuff from me. It

33:51

did seem like a lot. But one of the

33:53

things that happens when you start doing

33:55

that is your articles start getting shorter

33:57

just out of necessity. And it means a lot

33:59

of

33:59

stuff that you previously considered too

34:02

small to write about, you just

34:04

write about any questions. Yeah.

34:06

You discover that a lot of other folks may have had questions

34:08

or not known about this

34:12

thing that you

34:12

just recently discovered that you thought was too small to share with other people.

34:14

And it opens you up to this whole

34:17

new world of People who

34:19

are interested in a lot of, like, similar things to

34:22

you, it also creates this amazing

34:24

trove of like

34:26

brain dump stuff that you otherwise would have forgotten about. And

34:28

I've lost track now. How many times I've done a Google

34:30

search and found a thing I wrote a few

34:32

years back that I've trickled

34:34

about. Yeah. Yeah.

34:36

So writing every day has been absolutely transformative

34:38

for me. Wow. Very

34:40

cool. How long does it take

34:42

you to write every

34:44

day? It

34:44

depends. I generally try to keep

34:46

it to under a half hour, so it's like just a thing

34:48

that I do while I drink my coffee in the

34:52

morning. So I aim for about fifteen minutes. Sometimes if I have like a

34:54

a big thing that I need to share, it'll take

34:56

longer like thirty, forty five minutes,

34:58

which I know is not realistic for, like, a lot of

35:01

folks. But, yeah, I generally try to keep it to,

35:03

like, fifteen, twenty minutes. Nice. Nice. Very

35:05

cool. Number three,

35:06

my first coding project was about

35:09

It was actually an HR blog. That's what brought

35:11

me into coding in the first place. I had

35:13

this WordPress site. I wanted to have

35:15

more

35:15

control over how it looked

35:18

and worked. So I started digging into the code and that's what kind of

35:20

kicked this whole thing off for me. That's

35:22

really cool. Number

35:22

four, one thing I wish I knew

35:24

when I first started to code is that

35:27

most folks

35:28

are actually self taught and mostly figuring

35:30

it out as they go. I can remember when

35:32

I started, I was under

35:34

the impression that most people industry had computer

35:37

science degrees and knew all this

35:39

stuff and felt really, really

35:41

like I didn't belong. And

35:43

after talking to a lot of people, I learned that most folks

35:46

in our industry are actually self taught

35:48

or went through a boot camp, and

35:50

everybody's just kind of figuring out a lot of this

35:52

as they go. So there's a lot of knowledge

35:54

sharing and a lot of

35:56

asking questions and not to

35:58

feel so bad about not knowing all

36:00

the answers. Right. That was a really big light bulb moment for me that made me

36:02

feel a lot more comfortable doing

36:04

what I've do and really

36:06

kind of made it click for me that, yes, I do

36:08

belong here.

36:10

Right. Right. You do. You do belong here.

36:12

Well, thanks again so

36:13

much for joining us, Chris. Saran, thank you

36:15

so

36:15

much for having me. It was

36:17

a real pleasure.

36:25

You can reach out to us on Twitter at code newbies or

36:27

send me an email, hello at code newbie

36:29

dot org. For more info in the podcast, check

36:31

out WWW

36:33

dot code dot org slash

36:35

podcast. Thanks listening. See you

36:38

next week.