"Vanilla JavaScript" is just the basics of the language, and learning some of the more advanced abilities. Frameworks, libraries, etc. all build on the basics. You don't need to know everything, but it helps to understand how JS works behind the scenes.

lol

The ephemeral nature of many js frameworks is indeed a problem. Something that was hot 3 years ago may be forgotten now and you barely can find anyone interested in working with it. But you have to pay the initial fee of spending a lot of time reinventing certain wheels, but if it's worth it in the long run... Then it maybe is? It depends on the context. I am happy that people are voicing opinions like yours out as it may encourage devs, especially those who are newer to the js ecosystem, to discover the language itself.

I went back to a website I’d made for my mom a couple years later to update something. I couldn’t figure out how to get the environment set up even though it was a dirt simple site.

I’ve been on the vanilla train ever since for basic things like this.

There are so many things to discuss on this chapter, things got crazy in the last 5 years.

• the ecosystem got a huge infusion (as %) of new developers that jumped directly to frameworks skipping Computer Science, OOP and vanilla JS
• the frameworks got more and more abstract
• the base JS/CSS problems are getting fixed by the users not by the ECMAScript, browsers and others

And now we reached a stage where

• "react devs" do not realize that that "Shadow DOM" are actually JS objects and "redux reducers" are actually plain functions.
• for a simple boilerplate I had to get a few frameworks that downloaded 1300 NPM packages (webpack, react, SCSS, Babel, JSlint)

Even the fact that the expression "vanilla JS" exists states that the ecosystem has a huge identity issue.

But ... this statement has 2 sides

We can't hire someone so tightly bound to a technology, it is too restricting and not future-proof.

This means your company will develop its own methodologies and styles, which probably are not found anywhere else. The company and the devs will have to lose resources (devs will learn these, and cannot reuse that knowledge), lose-lose.

if we wanted to build a huge and complex multi-engineer project then a framework might be necessary

If the company developed more then a few of (100s files) websites you already built another framework.

Has anyone had a chance to check out Svelte, it seems like it could be an interesting compromise between pure vanilla JS and very abstract/heavy/opiniated/complex/bloated frameworks? svelte.technology

While I'll agree that not every app needs a full-blown framework and, a lot of uses I've seen for Vue/React/Angular are just ridiculously over engineered, building a decently-sized app without one, just because you can, doesn't really make sense, either. Unless you're just doing simple DOM manipulation, most decently-sized CRUD apps can benefit greatly in developer productivity alone from a framework. You're only limiting your applicant pool for future positions if you're approaching these frameworks as anything other than vanilla JavaScript. When I hire a front end developer, I test them on their knowledge of JavaScript, not framework A or B, because if their knowledge of the actual language is sound, they should be able to easily pick up any decently written framework.

This is no different than in other positions - if you're hiring a Node back end dev, you should be testing them on JavaScript, not Express, Koa, Hapi, Sails, etc. The same could be said for a Python dev and Django, Flask web2py, etc. - PHP with Laravel, Symphony, Yii, etc. - Java with Spring, Grails, Strut, etc. The only two mainstream languages I can think of with a singular go-to web framework are C# (ASP.NET) and Ruby (Rails - though, I suppose there's also Sinatra). Hiring someone only with experience in your given framework is silly. Their ability to learn and adapt should be a better indicator of their success on your team than their prowess with whatever framework is currently popular.

I had an interesting conversation one time with another developer and he said he was going to push using Nim for something at his company. He liked using Nim but also because it would mean long term employment there would be secured because it's still an esoteric language and they would have to keep him on in order to continue maintaining whatever he built.

Some day, we'll reach a state where all those frameworks and libraries rely on other frameworks and libraries instead of a plain language, ie Vanilla JS.

Also, it certainly is maintainable - if you're disciplined enough to do it right. Otherwise we'd still not have those frameworks and libraries.

There's a more important reason to prefer not to use vanilla JS: you don't have to reinvent the wheel. Those libraries are saving your time that you can use better.

However, there will be situations in which vanilla JS will be simply the best choice, for example pages without too much Interactions or landing pages that perform better without first loading and parsing 200k of JS just for the libraries the code is based on.

So please, use it as the tool it is instead of being one yourself.

We all have to realize that the programming language itself is an API. There is nothing wrong about using that API.

You don't have to use third-party module for every single line of your code base!

Use frameworks only for what they are designed for, and hook your own code there.

The framework you are using should depend on your code, not the other way around.

And, yes, you do have to learn as much as possible about the language and the inner workings, otherwise you will be floating somewhere high up on the stack, not knowing how you got there :)

"Dependency hell" === "Faster project to market speed"

Hey John, please I would really need your help in getting video tutorials or books on vanilla Js, any suggestions?

A good article, reminding us of what should be obvious, but even so, one or two of the responses seem to miss the point.

The people who are tasked to maintain your product are disadvantaged by not having been there during development, and they have less opportunity to develop the skills that were in play at that time. This presents a challenge to you, the developer, to minimise complexity wherever possible. Bear in mind at all times

"It's easy to make things complicated but it's hard to make them simple"