The workshop's title is a little clickbait, maybe,
but it's true for at least to try to hit your mind,
okay, that maybe you don't need that library.
And I know that what you're thinking, yeah, but I love React or
Angular Or Vue or Svelte or whatever library or framework you like.
I've been doing workshops like this one for a while now.
So I mentioned that I have been doing JavaScript since 1998,
okay, so that's a lot of time.
So I've seen a lot of errors in the web development world.
And maybe 10, 12 years ago, here,
that slide would say, but I love jQuery.
And this problem of overusing libraries is not new.
So it's okay if you love these libraries, okay, it's not a problem.
The problem is that when you only have a hammer,
you feel like everything is a nail, okay?
And this is currently common, I'm not sure if it's your case today here.
But it's common today that we have a lot of web developers
that have appeared in the market in the past five years,
that they have just learned to create web apps with a library or with a framework.
Now, I'm not saying that's wrong, but that's the only tool they have.
So then, when they need to create a new project,
even if it's a very basic project, I've seen even blogs, okay, that
they were creating a new blog and they use Create React App to create a blog.
That's because that's the only thing they know,
that's the only tool chain they know.
And the idea of this workshop is to show you that there is a different world
out there, that on some situations, it might be a good idea.
So I want you to have more tools, not just the hammer, okay, make sense?
So I want you to also love Vanilla JS.
And again, I'm not saying that you will start every new project
with Vanilla JS starting tomorrow, but at least you will have that tool available,
and then you will make better decisions in the future about which framework or
which technique you will use for every situation.
Today, we are in the era of microframeworks,
microservices, micro apps, this is also a new deal going on.
Instead of large apps, we have micro apps that we can deploy instantly in
the cloud with, I don't know, or with every other provider.
We have a URL immediately.
In five minutes, we have a URL that is working, so
we don't need to always create big, large applications.
Sometimes it's something very specific that we can even convert into
a progressive web app, into a PWA, the user can install,
they can work offline, it's a very specific situation.
And for those apps, for those micro apps, Vanilla JS typically is good enough.
So let's try to define first what's Vanilla JavaScript or Vanilla JS.
So it's the usage of the core language and browser APIs to create web apps
without any additional libraries or frameworks added on top.
And of course, this is not Boolean, I mean like,
this is Vanilla JS, this is not Vanilla JS.
It's actually a range of possibilities in the middle, because yeah,
maybe you're not using a big framework such as Angular or Next.js, or
you're not using a library such as React or Vue.
But you're still using some open source micro libraries,
or you're using TypeScript, so you still need double or
a TypeScript compiler to transfer it into JavaScript.
So there are still a range of possibilities in the middle.
So it's not like, I don't wanna use anything, okay?
Today, we will focus on maybe the Boolean part,
we will be just plain, plain JavaScript.
And by the way, because I don't wanna take anything for granted today,
because I'm pretty sure that a lot of people don't even ask about this.
So they have seen the term Vanilla JavaScript, but
they don't understand why Vanilla.
So let me even explain that really quickly.
So in software development, it's not just in software development, but
in particular, in software development,
we've been using Vanilla as a way to say completely plain.
And this is coming from Italian ice cream, from gelato,
where the vanilla ice cream is the base of most of the creamy ice creams.
So the gelato is vanilla with something, okay?
So that's why the base one is vanilla, and then we add flavors on top of that.
So in software development, when we say Vanilla,
something like Vanilla JavaScript, we are saying it's plain JavaScript,
we are not going to add any flavor on top of that, okay?
So that's kind of the idea.
And it's not new.
As I mentioned before, it has been a concept for
a decade now, but this is kind of a wavy thing.
And I think that we are, again, at the top of the wave,
where a lot of people is, again, talking about this.
So let me show you something, I'm going to get out of the slide for a minute,
and I'm going to show you this website, okay?
This is vanilla-js.js.com.
You can see, I mean, it's not even HTTPS, okay, the website,
so this is actually a website from 12 years ago, okay?
That at the time, it was like, wow, look at this, Vanilla JS, and at the time,
it was like a website selling a new framework, this is the jQuery era, okay?
Vanilla JS is a fast, lightweight, cross-platform framework for
building incredible, powerful JavaScript applications, okay?
And here, they were explaining the big companies using this framework,
okay, Facebook, Google, YouTube, blah, blah, blah, blah.
I think that all of them are still alive, right?
Yeah, kind of, yeah.
Anyway, and you can see here if you wanna download Vanilla JS,
the framework, you can even pick the portions of the framework that you want.
So you want AJAX, that's the Fetch API, Functions, a Math Library.
And you have even here calculation of how many bytes you will download if
you add regular expressions or animations, and everything is 0 bytes actually.
So at one point, you start feeling that something's wrong here,
what's going on with this website, okay?
Well, what's going on is that this is just JavaScript,
you don't need to download anything.
That was the point of this website,
to get into developers' mind with a new framework, with a new fancy framework.
Let's do that, it's faster than look at the libraries at the time Dojo, Prototype,
Ext JS, jQuery, YUI, MooTools, and this is actually faster than that.
I'm not saying that today with the libraries,
we are on the same kind of comparison in terms of performance.
But anyway, this is an example that this is not new,
the idea of pushing Vanilla JS, it's been for a while.
So after this, because at the time, I remember that,
when you were starting a new project, you were creating index HTML.
And the next step was to download jQuery and add the script tag for jQuery.
It doesn't matter what project were you doing at the time, you were adding jQuery.
And that's exactly the same thing that is happening today.
You start a new project, a new web app project, and you start with the library or
with the framework, okay?
So I wanted to show you this because it's just the history repeating itself.
And we are back in that same position where you always want a library, okay?
And of course, we have fancy new libraries every couple of month,
okay, libraries or frameworks or quicker, wherever, okay?
We have new terms and new names appearing all the time.
So for example, here, we have a very large table of, I don't know,
maybe 50, 60 different libraries that we can use today
with the benchmark on different situations, such as creating rows,
replacing rows, the benchmark in terms of performance.
And here is Vanilla JS, and all the rest are frameworks or libraries.
We have some different ways to do that with Vanilla, like WC, but
most of these columns are different libraries or frameworks, okay?
So we have a lot.
And yeah, in terms of performance, you will probably find that if you're
doing things correctly and you understand performance in JavaScript,
that is a whole completely different topic,
Vanilla JS will probably be faster most of the time, okay?
But because, again, the libraries on top of Vanilla JS always,
it's not changing the browser's engine,
unless we are talking about something with web assembly or things like that,
that is not the case for most of the UI libraries out there.
It's not a web assembly approach with maybe threads and workers.
Unless we're talking about that,
most of the libraries are sitting on top of Vanilla JS.
So at one point, it has to do with understanding how that works,
understanding performance, and then writing the right code.
Yeah, I know, maybe you're thinking, well, but
I need to write a lot of code sometimes, yeah, we will get there.
That might be the case on some situations, and
that's why a library might still be a good idea sometimes, but not always, okay?
So that's the point, that's what I wanna highlight right now.