Check out a free preview of the full Vanilla JS: You Might Not Need a Framework course

The "Introduction" Lesson is part of the full, Vanilla JS: You Might Not Need a Framework course featured in this preview video. Here's what you'd learn in this lesson:

Maximiliano Firtman introduces the course by providing some personal and professional background. An overview of the material to be covered in this course is also provided in this segment.


Transcript from the "Introduction" Lesson

>> So my name is Maximiliano. I can go by Max, this is going to be a workshop on vanilla JavaScript and why most of the time sometimes, maybe you don't need the library that you want to use so hard. So really quickly about myself. So I'm a mobile web developer.

So I have been doing HTML and web apps since 1995 so the 96 actually. So that means that I've been using vanilla Js for a while because we didn't have libraries or frameworks like we have right now okay. So I will during the day I will explain my experience doing a lot of web apps but roughly in terms of vanilla JavaScript web apps so with different screens single page applications and.

And routing state management properly I have done more than 100 web apps for different devices like even restricted devices such as mobile phones. Even before the iPhone era, so really restricted phones and even smart TVs. And then I have started doing mobile apps as well, so I'm also a mobile developer.

And I have authored a lot of books, you can see there with a lot of translations and a lot of workshops and courses. So even here frontend masters you will find several workshops and courses that I have developed. So I'm third on Twitter on many social networks on my website is further depth.

And I'm from Argentina I currently live there so I'm from Buenos Aires. So what we're going to cover today so we will be focusing on vanilla JS if you don't know what that is give me one minute just one minute. But anyway that's actually working with the browser's API and JavaScript without libraries, okay.

And we will explain why we want that and when maybe because I'm not here to like being a really fan of vanilla JS for everything, but at least you will see that many times it's a good idea. So we're going to talk about the DOM API. So the DOM and the DOM API, sometimes it's where you're coming from libraries, such as React or Angular.

And that's the only thing you know, the DOM API looks a little scary. The DOM API, the one I don't want to deal with that. Okay, we will deal with it, that will use the Fetch API. That's probably something that you know, because it's currently available unless you're doing only Angular, where you have HTTP services there that will help you.

Probably if you're coming from react or view or other libraries, you probably have to deal with the Fetch API. We will see different design patterns am not here to advocate for one specific design pattern. So we will like mix and match different design patterns on the same web app that's typically not the case in the real world you pick like one design pattern or two.

So but here we are going to mix a couple So you will get a sense of different ways that you have with Vanilla JS to do things. So we are going to create a single-page application from scratch. The only thing that is already there for you is HTML and CSS.

So we're not going to deal with that. We will be focusing on JavaScript and making that app work. We will talk about web components and we will code web components. So we will see the standard way to create components. If you're coming from a library, probably you have heard the idea of a component.

Okay, we're going to see how the standards work today in most of the browsers. Routing, so we're going to see how to do routing without React router, [LAUGH] without a router module from your library. So we're going to just use the DOM API. You will see it's not so complicated and how to do reactive programming in JavaScript.

So things that we love frameworks and libraries. If I change my state, if I change the value of my variable, the UI will update automatically. So we're going to see how to do that with plain JavaScript, okay? So that's what we're going to cover during the rest of the day.

So prerequisites on that url, firtman, that's my last name, okay? You will find step-by-step guideline if you wanna follow along. The workshop, also there you have the slides, a copy of the slides in case also you wanna follow along or you wanna download that for later. Later I will get into that URL and we will see where we are on each step.

Also by the end of the day on that URL, you also have the final code working code, okay in case you wanna get it later, okay. Anyway, we are going to maybe 85% of the workshop will be live coding. The rest will be slides on some theory, really theory but explanations and discussions.

For the coding part, I will be pushing updates on GitHub as well, in case you want to follow along. So questions, yes, please. For those of you here, go ahead. Just ask any question, even if you feel it's a very basic question, go ahead.
>> Manipulating the DOM all the time seems like not very productive, especially when building large apps.

What's your opinion?
>> Let's say that scalability is one of the things that scare us the most when we are dealing with vanilla JavaScript. So we need to understand how you're manipulating the DOM because as I mentioned before there are many design patterns to actually work with the DOM.

And let's say that the simplest way to manipulate the DOM, it's probably not performant for large scale applications. That is like for those of you that already know what I'm talking about, it can be just like changing innerHTML. Things like that may not scale well, but we have to understand also that libraries and frameworks are not changing the browsers and shine.

So they're actually executing the same JavaScript as we can, right? So we can also write things with scalability in mind, and sometimes even simulating what libraries are doing to make them more performant. So some people think that libraries are magic and yeah they're not they're using the DOM API's behind scenes.

And they're adding design patterns to make that things better and you maybe for your case, one specific library is better. So I'm not here to tell you that you must use Vanilla JS for everything or you must manipulate in the DOM directly for every project. But after you understand at least where are the API's?

What are the possibilities? So these you can make a decision, okay? I don't wanna reinvent the wheel in this case. So I'm going to use that library, which is fine. But the problem is that when you make a decision without the knowledge, you just use the library because that's the only thing you know okay, so that's my take at this point.

Okay, but I've done web apps, as I mentioned before, that are fairly large maybe in terms of screens, let's say let's measure this in different kinds of screens. It was like a game. In terms of a screen, it was I think around 80 different screens with forms and drag and drop and everything.

That was an app with 10 million users and it was working fine. Didn't have any issues in terms of scalability and yeah, at one point you may think that I have created my own framework and yeah, maybe that's the case. Okay, maybe I created like a custom framework for that specific project.

Yeah that may be the case for some situations okay? That's my take for now.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now