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)
There are so many things to discuss on this chapter, things got crazy in the last 5 years.
And now we reached a stage where
Even the fact that the expression "vanilla JS" exists states that the ecosystem has a huge identity issue.
But ... this statement has 2 sides
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 the company developed more then a few of (100s files) websites you already built another framework.
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.
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.
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!
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.
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.
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.
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.
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"
"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.
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.
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.
We all have to realize that the programming language itself is an API. There is nothing wrong about using that API.
Use frameworks only for what they are designed for, and hook your own code there.
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 :)
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.