DEV Community

John Kazer
John Kazer

Posted on

In defence of vanilla JavaScript

As I began to learn web site creation, I often heard statements like "vanilla JavaScript is only for beginners". As I began to learn JS I certainly mainly stuck to vanilla, fulfilling the stereotype. Frameworks were mysterious and confusing concepts.

But, crucially, I work for a consultancy not a software company. They are interested in three things:
1. Getting an effective app
2. Maintainability
3. Maintainability

It is of no value to have an app that no one else in the company can update or that require outside skills that are too specific. We can't hire someone so tightly bound to a technology, it is too restricting and not future-proof.

So vanilla JS is great for making effective (adequate) apps, useful for training others in the company and if we need outside support then we aren't restricted.

Plus the same (more-or-less) vanilla JS and any packages will always (??) work in various different scenarios: web front-end, mobile, NodeJS, Chrome extensions, Electron etc. and with fewer version compatibility worries.

Now, if we wanted to build a huge and complex multi-engineer project then a framework might be necessary - but if so we'd likely hire a specialist agency to do that. Which of course means we lose control of the app... Not so attractive!

Top comments (22)

Collapse
 
bgadrian profile image
Adrian B.G.

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.

Collapse
 
damien_perkins profile image
Damien Perkins

"react devs" do not realize that that "Shadow DOM" are actually JS objects and "redux reducers" are actually plain functions.

I have a hard time with this sort of statement; seems like a difficult one to measure. I know lots of devs that are very aware that reducers are plain functions. I also know lots of devs that know precisely zero about the shadow DOM, because React means that they don't have to.

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.

Absolutely agree with this - using libraries like React and Redux in my workplace have made it much easier to ensure all devs are on the same page, and most issues are pretty trivial to find answers about.

Collapse
 
johnkazer profile image
John Kazer

I tend to agree with the view that if your code reached a level of complexity where you begin to develop your own framework, then you should just use an existing one.

Hopefully the knowledge gained getting to this point also means you now know enough to pick the right one!

Collapse
 
bgadrian profile image
Adrian B.G.

When you reach that stage there is no going back to a framework, the change would be too costly with minimal ROI. Its a decision you should make before writing code.

Thread Thread
 
johnkazer profile image
John Kazer

Which is fine when you already know why you want to choose a particular framework and that it will do the job you need.

I also hate being locked in to an approach which means your future options may be constrained.

There may be benefit in us refactoring as a training process and because the early apps really have some weaknesses!

But I get your point, maybe in the end we'll just switch to "the final solution" for the next iteration of development.

Collapse
 
ben profile image
Ben Halpern

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.

Collapse
 
danielkaczmarczyk profile image
Daniel Kaczmarczyk

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.

Collapse
 
gtanyware profile image
Graham Trott • Edited

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"

Collapse
 
ozzyogkush profile image
Derek Rosenzweig

"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.

Collapse
 
johnkazer profile image
John Kazer

it is true that we can't survive without open-sourced libraries for specific tasks... but other than a smattering of jQuery most are by our selective approach are just JS too.

Collapse
 
snowfrogdev profile image
Philippe Vaillancourt • Edited

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

Collapse
 
dinsmoredesign profile image
Derek D • Edited

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.

Collapse
 
simov profile image
simo

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 :)

Collapse
 
missingno15 profile image
Kenneth Uy

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.

Collapse
 
lexlohr profile image
Alex Lohr

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.