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...
For further actions, you may consider blocking this person and/or reporting abuse
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.
Also it's fast!
lol
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"
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.
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
"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.
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.
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 :)
Hey John, please I would really need your help in getting video tutorials or books on vanilla Js, any suggestions?
there are some useful links at the end of this amusing but true article vanilla-js.com (thanks to
tux0r
Thanks for your response John
Also I read "JavaScript the good parts" but it's not really a beginners book
"Dependency hell" === "Faster project to market speed"