Why do we need to care about VanillaJS?
So why?
Why this is important today, this year?
Well, first, to add one more tool to your toolbox, so
then you don't have just a hammer okay?
So this is important.
So to understand what your library is doing.
Or if a new version of the library appears and now they have a new fancy way
to do things, you will understand, okay, it's better because of.
You will understand why that's better.
Okay, so you will understand your library.
To extend your library with plugins, add-ons, or
change your library in case you need to.
Because most of the time you need to get out of the library sometimes.
For example, if you are doing hardware access, you're using platform API's.
Sometimes you need to get out of the library for some operations.
And then you need to come back to the library.
Well, to understand how to do that properly or
to understand how to code properly that part of your app that talks to the DOM,
it's better to understand what you're doing.
Also to be a better web developer.
And this is not just because I know Vanilla JS.
Okay, so this is something that you will add to your profile on LinkedIn.
And recruiters are actually taking that in consideration when they are looking for
web developers.
If you know Vanilla JS, you have more points in your profile, okay?
Also you can mix these with libraries.
When you're using a library such as Vue or even React,
you don't need to create your whole application with React.
React or View can just be like a little
widget within Vanila JS library when you need it.
It doesn't need to be always like the whole navigation is
managed by the library, okay?
So you can mix everything.
Also, and probably the most important part here is that
FrontedMasters.com is Vanilla JS, and that's why it's so fast.
So if you have seen that it has a really fast user experience,
it's because it's Vanilla JS, okay?
Maybe we need a plugin for
the browser that will tell you when you're on a website, this is Vanilla JS.
So you get a vanilla icon or something to know when you are in a React,
application, a Vue application, or a vanilla JS application.
And also to use it.
So I don't want you to take what you will learn today just for
the theory or just for history.
So it's not for historical reasons.
I want you to use it when you can, okay?
And then you can create simple, fast web apps with no CLI, no build process.
Nothing,even if you want, you can still use the old FTP,
if you know what I'm talking about.
Because that's something that most new developers, they don't know what FTP is.
Well, you don't need a PCAP, you just do an HTML,
a JavaScript file, and you have an app up and running.
Okay, just a matter of minutes.
Yeah >> I'll just say that people write into us
constantly on our customer service or Twitter or whatever,
why is your site so fast?
And yeah, it's because we mostly rely on just server side rendering and
then with data attributes, adding any kind of behavior to the side that we need to.
>> Yeah, in fact, some of the libraries, for example, React,
I'm not sure if you haven't seen this.
Do we have any React developer here?
Let's see, so most of you, all of you actually.
[LAUGH] So React has changed its documentation lately.
I think it was a month ago or less than a month ago.
And now, they're not suggesting to you to use
React client-side without an additional framework.
So they're not saying, hey, yeah, you wanna use React,
just use create React app and do everything client-side.
That's not the recommendation anymore.
Is it still there?
Yeah, it's one possibility.
But they say, because now we have a performance issue on the web,
mostly because of the over usage of client side frameworks.
So things like Next JS or Quick or other ideas are coming back to,
okay, maybe we need to do more server side rendering.
Yeah, JavaScript is still useful, but we don't need to
rely everything on client side and adding a lot of overhead.
Mostly on the enterprise world, it's common to hear like, yeah,
we have five megabytes of JavaScript.
It's not so big.
What, five megabytes of JavaScript is not so big?
So on the enterprise world when they're doing apps in Angular or
something like that, they feel like five megabytes of JavaScript is not so big.
And that's a big problem, okay, in terms of performance.
Not just because of downloading the file, that's not the biggest problem,
but parsing and executing that file.
And mostly if that's why is rendering the UI,
because that means that you won't see anything until that part on executed.
So even this is a discussion today.
This is a tweet from yesterday, okay, from Ben.
He was saying, genuinely think that every frontend developer should build their own
framework at some point, and that's actually Vanilla JS.
Okay, building your own framework for understanding what you're doing and
why you're doing that, okay?
Because that taught him more that more JavaScript and
Web APIs in a month, than years of React.
So when you understand VanillaJS, the DOM APIs,
you understand what you're doing, how you're doing that, okay?
And Again, that will make you a better React developer as well,
because you will understand how React works and
how to do better things in React to help React use better the DOM APIs.
So main advantages of Vanilla JS,
before actually getting into some code and start coding our app.
So lightweight, because yeah, you don't have the overhead of the library.
Today, some libraries are better than that.
You have tree shaking, so
they can actually get rid of code that you're actually not using.
So it's getting better.
But anyway, any library or framework is sitting on top of the DOM API.
So it's always something on top of, that means you're adding more things.
More control and power.
And you know that with power we have more responsibilities as well.
And that's one of the disadvantages or the fears.
from some of you.
That you need to make a lot of decisions when you're doing Vanilla JS because,
yeah, you're not forced to follow the guideline from the library.
And yeah, you need to make a lot of decisions.
Maybe that's life, right.
So at least it's a good idea to know many options so
then you can make your own decisions.
Simplicity of the code.
Yeah, that might not be the case for very large solutions.
Flexibility, performance, we have already been discussing and
talking about performance.
Compatibility is main advantage and say,
I thought that that was a problem, not really an advantage.
Well, actually when you're using Vanilla JS, okay,
you don't need to think too much about compatibility or
dependencies or compatibility on your server-side framework or
even compatibility with the browser.
We will get there about what we're going to do today in terms of compatibility.
It may be a joke, but it may be true.
You won't have node modules, okay?
So you won't have thousands of files in that folder that looks like a mess.
We know it works anyway, but it's always, okay,
a joke what happens with Node modules.
So main fears of Vanilla JS that you probably have, okay, and
that's why you're here.
So routing.
That sounds like, but I like routing, I like how React router works.
Okay, in fact this is coming from a survey that I did on Twitter.
Okay, I did that a couple of times and I gathered feedback from developers.
I got, okay, what's the worst thing?
What's your worst nightmare when we are talking about Vanilla JS?
Well, lack of routing, that it's too verbose and time-consuming.
That you need to write a lot.
State management.
So how to do state management.
And sometimes we mix fears here.
For example, state management,
some libraries are not giving you actually state management.
I'm talking about global state management.
They might give you component based state management.
And they have other libraries attached that will do the same.
That means that you can still use Vanilla JS and use Redux, for example.
You don't need React to use Redux.
So if you like Redux, you can use Redux on Vanilla JS.
Okay, is it Vanilla JS?
Well, we can see, okay?
Again, this is not Boolean, being Vanilla JS or not, but I'm saying that you
don't always need to use all the libraries that are like friends.
You can just pick what you need for that specific project.
Templating.
That's typically one of the biggest fears when we get here,
like JSX, lack of JSX, or something similar.
Templates in Angular, where where I can have ng attributes in the middle
of the HTML, and do something about that.
Complexity.
People think that it gets more complex, but
I think that that fear has more to do with ignorance.
Okay, that if you don't know something, it looks complex.
Not having reusable components.
I'm not making a statement here, this is just a list of fears from developers.
How to maintain that in the future looks like a problem.
The learning curve.
It's funny to you see that some people think that the learning curve of
Vanilla JS is much higher than the learning curve of Angular, for example.
And I've been playing with both and I've been teaching on both.
And i think that's exactly the opposite.
The amount of concepts that you need to understand from Angular,
just for using one example, it's probably 5x compared with vanilla JS.
Browser compatibility, that's typically a fear.
But React is helping me solving browser compatibility issues on the DOM.
I've heard that a lot.
Okay, that if you don't have React or Angular or Vue, okay,
your app will stop working on some browsers because some browsers,
I'm talking about modern browsers.
I'm not even talking about Netscape.
People think that maybe maybe your app will not work in Safari if you're not
using React because there is like a magic idea going on.
That React is actually like wrapping the DOM API
with tweaks for Safari or things like that.
I'm not saying that false or true yet, but that's the feeling.
And the freedom that we are going to reinvent the wheel every time.
That's probably one of the fears that we have.
Okay, and scalability.
We already mentioned that.
I'm not saying that we will solve all the fears, or we will solve all these
challenges, but at least we will see what's true by the end of the day.
What's true?
What's actually an over reaction?
What's false, okay, in this list, >> What level
of experience should I have coming into this workshop with JavaScript itself?
>> Just to understand the language, so if you know how to write the class and
you are confident writing Code, JavaScript code, that would be enough.
And even if, I mean, if you know TypeScript but
not JavaScript, it's going to be the same.
Things like that.
Anyway, most of the code that I will write is also ready for
copy and paste, if you want, in the URL in the GitHub URL.
So even in case you don't wanna write the whole code,
the code is there if you wanna follow along or things like that.
Okay, so.
>> We're going to learn the tool and you'll see when it's the best option.
I already said that a couple of times, but we want advocate here for
using binaries on every project.
Well, I won't advocate that.
I want you to understand what it is.
You have a working sample, using different techniques
is going to be little count, yeah, little chaos there.
But the idea is to show you different patterns that you can use with this.
And yeah, there will be more to see.
When you have a complex application where you're managing large amounts of data,
mostly for example, when you have a large list of things like that,
that will need a special attention.
But we'll start from scratch.
So we're going to see the basics first.