Wrapping Up

[00:00:00]
>> Today we've covered Vanilla JS in general with, I know, different techniques. But I didn't want to push my way of work, but to follow me in the flow of thoughts and how to solve problems so then you can create your own framework. We've seen the DOM API.

[00:00:17]
Not the whole DOM API, it's huge, but the most important part. The fetch, that was actually simple. Some design patterns we've seen, for example, how you can broadcast your own custom events and then how you listen to those events. Single page applications, how to do the routing things.

[00:00:34]
Web components and the three parts of web components, custom elements, the template element, and shadow DOM. And some ideas on how to use reactive programming in Vanilla JavaScript. Again, you have small libraries that will solve each of these issues differently. At the end, they're using Vanilla JavaScript also.

[00:00:58]
So you can take ideas from those frameworks, from those libraries, you can use those libraries if you want. So let's go back to the main fears of Vanilla JS, and let's try to see where we are, okay? Routing for single page applications. We've seen that that's not really a big problem.

[00:01:16]
Yeah, the one that we have is really concentrated in our project. We didn't use regular expressions, but adding that part is not really so difficult. It's too verbose and time consuming. Yeah, maybe, it's up to you. And that brain icon I have there, it means that it has to do with how you think, how do you want things to be done?

[00:01:41]
And maybe you can create your own mini-framework, mini-library, so you don't have that part, okay? So by default Vanilla JS is not forcing you into doing things in this way. State management, we've seen that you can do things with arrays, global things, you can have different patterns here.

[00:02:04]
And again if you wanna use Redux or any other design pattern for that, fine. At the end it's just design pattern, abstractions, layers. Templating, we've seen basic templating, how to use a template string. But for those of you that are coming from React or Angular, you're expecting more from the template, and there are ways to do that.

[00:02:26]
So we've seen the basics, but using, for example, literal strings, you can use tagged literal strings to make things really, really useful. I'm not sure if you have heard about lit-html, for example. lit-html is, it's a quick framework that is, let me explain quickly how that works. The idea is that when you are, for example, defining a template string like this one, let me add this on the app.js.

[00:02:55]
We don't get rid of that. So you can do something like this. I'm not saying this will work because I'm not doing it fully. But you can have things like, okay, have a paragraph. And I want the paragraph to have a style. And I want this style to have, here, something coming from an object.

[00:03:17]
This is not JavaScript, it's not React, I'm not actually doing this, I'm doing this. And you say, okay, this is not gonna work, but I can pass this template string to a tag. What's a tag? For example, something like this, frontendmasters. And you say, okay, what's that? It's not a function.

[00:03:43]
I'm not using parentheses, okay? So it doesn't look like a function call, but it's actually a function. It's called a tag for template strings. The tag is going to function with that name. Again, I'm not explaining this fully, I'm just giving you an idea of what you can do.

[00:04:01]
And this function will receive portions of this string that you can process. So you can find with regular expressions, for example, parts of that string and do something with that. So with this technique, lit-html is one, there are many that are doing that, yeah?
>> In some of our highly dynamic components we started using lit-html cuz not only can you do the kind of like click handlers and these kinds of things inside the template, but it also has the intelligent updating.

[00:04:41]
So if you throw it a very giant template literal at, for instance, a table or a row, and only one part of it changes, it will intelligently only update that one part. And you can use things like repeat, which is kinda like React where you can keep things in order so you're not doing unnecessary DOM-

[00:05:05]
>> Yeah, sure, so it's doing some of the things that other libraries are doing, but it's lightweight. And it's just focusing on this part of the problem, not the whole thing that React is solving. But if you look at how it looks like, it looks like this. It has that html prefix to the template string.

[00:05:24]
And that's the one that's doing the magic, such as reading this and making an event listener for the click with that clickHandler, okay? So that magic that you can do with tagged little strings is, I mean if you wanna do it manually on your own, you have like an abstraction layer there, not really so difficult.

[00:05:50]
But it's a way that you have to improve your templates if you don't like how the template work by default, okay? And, again, this workshop was not really to be against libraries, is to understand how things work. So you can decide when to use a library or a framework, and when to use mini libraries for specific reasons.

[00:06:13]
So then we can discuss forever, if you add lit-html into your toolbox, is that Vanilla JS or not? It doesn't matter actually, okay? So it doesn't matter. If it solves your issue, and it's not adding performance penalty as you can have with full React client-side application, it's fine.

[00:06:36]
Again, if not, you're reinventing the wheel. So that's okay, we don't want you to reinvent the wheel. But if you find a wheel that solves your problem, it's fine. The problem with some frameworks is that it's not a wheel, right? It's a whole plane that you're adding, just for a wheel, okay?

[00:06:58]
That's the problem of a big framework or library. So that was for the fear of templating. Complexity, I mean, I know what you feel right now, was it so complex? I mean, if you look at the code right now, is it complex? I'm not sure if complex is actually what's going on.

[00:07:21]
The problem is that when you don't know the stuff, everything looks complex. And I know a lot of developers that were developers when I started that didn't make the shift or they stopped working as web developers. And they feel like React is complex. Because that has to do with ignorance.

[00:07:40]
I mean, if you're ignorant of something, it looks complex. It has to do with that. Reusable components, well, we saw how to create web components. Yeah, you can decide it's better, worse, but we can create reusable components these days. Even you can export from Angular, React, or Vue, web components as well.

[00:08:00]
And you can use them as web components in a Vanilla JavaScript. Fine, that's possible. How to maintain this also has to do with your design patterns, how your way of thinking works. So it has to do with your work. Learning curve, well, you did the workshop, you're still here, you didn't get away.

[00:08:25]
So, I mean, I don't think it's bigger than learning a framework, actually. Browser compatibility, everything that we've seen today works everywhere. Maybe one specific part that is not in Safari, but everything that we have already implemented works everywhere. The only X that we have there, so it's not really a big issue.

[00:08:49]
The only problem is still, if you have some banks, corporate governments, they're still on IE 11. Well, you need to be very careful. The same will happen with React. So it's no different than React, Angular, or Vue, okay? So it's not really, really a big deal. Reinventing the wheel every time, again, that has to do with yourself, are you going to create your own framework?

[00:09:15]
Are you going to add abstractions layers to what we have done today? Because it has to do with that. I have created, as I mentioned, more than 100 web apps in Vanilla JS. And, yeah, I wasn't reinventing the wheel every time. I was using my own ideas, again, my own code, my little framework, my little utility functions to avoid reinventing the wheel.

[00:09:42]
But it's up to you, it's not something that the platform will give you. It's up to the usage of best practices and design patterns. Scalability is still, again, something that it depends on how you're doing things. By default, if everything is chaos in your code, yeah, it's going to be a problem.

[00:10:06]
And that's why I know that some companies when they decide to, we're going to use, and I'm hearing this a lot, we're going to use Angular. Because we have TypeScript, it is forced. And it will force developers to do things in this way, because if we give them freedom, okay?

[00:10:27]
Everything is chaos. Well, it has to do with that, with following rules, guidelines. So, yeah?
>> We've never seen any large React or Angular code bases that are performant, right?
>> Yeah, that's a performance, yeah.
>> I'm just saying, in general, yeah, a lot of code bases can, no matter what tool you use-

[00:10:55]
>> Exactly, no matter what tool you use, it will get the mess at one point, yeah. Yeah, that's true. So again, now that you know Vanilla JS, you can decide to use lightweight libraries tools one by one, based on your needs. That's okay, okay? You wanna use Redux because you like it, go ahead.

[00:11:14]
You don't need React, you can use Redux. You wanna use lit-html, that's okay. You wanna use a router. There are a lot of routers that will give you more power without another UI framework. You need the UI framework because you feel like you will have a lot of reactivity and data.

[00:11:33]
Well, go ahead, use the framework. The problem is to decide a framework or a library based on, that's the only thing I know and that's why I'm picking it. That's the problem, okay? So now it's time for you to define design patterns you prefer for everything that we have seen, and create your own unique library for your needs.

[00:11:55]
Maybe that's the way. And decide when to use that and when not to use that.
>> I'll just say, in general, leading this company I find having small modules that will live for a decade plus. That I'm not gonna have to NPM update and then have everything break.

[00:12:18]
I just find that it is a good use of development resources, and granted I lead the company so I can say, hey, we're building this in a certain way, right? Not only me coding but our developers, but I do enjoy the fact that, well, if there's a new paradigm.

[00:12:34]
So, for instance, right now if you have an SPA React app, now everybody's saying, hey, now you have to rewrite it in Next, or whatever. And then there's a continually, as you've been in the industry for 20 plus years, you've seen the churn from everybody was on AngularJS and then everybody moved to this, and then moved to that, and it's a constant cycle.

[00:12:56]
Which is great, keeps us employed, we can keep building new things and new styles which I appreciate. But yeah, as an owner of a business that's been in existence for over a decade, I appreciate that we can just open up a module and it works. And if anything, JavaScript has gotten better over the years, we can just swap out, a different way of doing things with a new feature that does the same thing, it's just clearer code or whatever.

[00:13:26]
So yeah, that's my perspective, and I wish more organizations would look at that as a potential path-
>> Yeah, talking with many organizations, what they say right now sometimes is that it's difficult for them to hire Vanilla JS developers. So it's difficult to find developers that knows or even wants to work with Vanilla JS.

[00:13:47]
But mostly it has to do with they don't know it. Because all the bootcamps and all the new stuff from education point of view in the past five years were basically React.
>> I'd agree there's definitely a stigma around that. But from that perspective of hiring and that kinda thing.

[00:14:07]
But yeah, [LAUGH].
>> Okay.
>> I'd say it's been a major win for us in terms of paying off in terms of performance maintainability, etc., so.
>> Any final question, online or here? No? Well, that's all then, thanks.
>> [APPLAUSE]