Learning vanilla Javascript and it's frameworks - keeping up with fast-moving web development

In the fast-moving world of front-end web development, it can be a challenge to keep up with what to learn next, even for seasoned developers with years of experience. One hot topic when it comes to learning is whether one should focus more time on learning vanilla Javascript or learning helpful Javascript frameworks such as Vue or React. There’s a lot to think about when making this decision as so many factors can affect what you spend your time on; your job/education, time, money, preference, to name a few.

Vanilla Javascript and frameworks overview

Vanilla Javascript is a term often used at different granularity levels by different people. To me it means using JS code without help of frameworks such as React or Vue, instead focusing on writing your app structure using “plain” Javascript (ES5, ES6 +).

I’ve even heard people define vanilla Javascript at a more granular level of writing your own implementation of code and not using any third party code at all - i.e. without using any libraries, no matter how small.

In my opinion, it’s important to keep up with vanilla JS, especially in recent times when frameworks like React and Vue are reached for by people very frequently. If you don’t keep mindful, you could go weeks or months without jumping into any vanilla JS code. This isn’t really bad, but from my experience, getting really deep into a framework and going back to vanilla Javascript after a long period means you may forget some basic concepts and underlying principles which are abstracted by a framework.

One other consideration is that the Javascript ecosystem is changing so rapidly - faster than it ever has I think. The next ECMAScript release is always just around the corner and new and helpful features come with it, so keeping up to date with this helps realise what is useful.

You may not always need to use a framework or library

As I mentioned, I notice people reaching for frameworks or libraries for the most basic tasks. This is understandable as frameworks help by getting a complex prototypes or production ready projects up and running quicker and easier. However if it’s only a small project, it may be best to use vanilla JS.

Obviously this isn’t something you can make and hard-and-fast rule for. I find that frameworks help for larger projects as they help with general structure and high level organisation. They also have great documentation, and many people use frameworks so after a quick Google you can pretty much always find massively efficient way to do anything with a framework.

On the other hand, I find vanilla JS great for smaller projects, and ones with less application state. Such example is the good old to-do list. You’ll often see these sorts of tiny apps used as examples in framework docs as it’s easy to show small concepts, however in reality a framework may be way too bulky and obtuse for such projects.

I think in the long run, if you’re more proficient with both options, you’ll be able to know which route to take when presented with the choice.

Don’t re-invent the wheel (most of the time)

Most of the time as web developers we reach for pre-made “things” to help us with our job. Why re-invent a UI component such as a datepicker or even a state management helper like Redux? Often, project budget and timelines prevent the need or option of making your own interpretations. Using libraries and frameworks often help get a better end user experience and development efficiency and are often more important than creating something from scratch.

Having said that, often creating your own widgets/libraries/apps from scratch rather than reaching for something pre-made is useful because it allows you to level up in whatever area you’re interested in, and may also be required if you have an uncommon use case where an off-the-shelf product won’t help. That leads to my next point…

Make random side projects

Creating your own mini projects is probaly the most helpful advice to keep up with vanilla JS development because unless you jump into things and start getting your hands dirty in code, you won’t experience what it is to create an entire project and have to think about tools, time, programming paradigms etc.

You can start by making something small and working up to making larger applications, and do it in-between working on your usual framework lead approach for your main projects. For example, going as small as making helper functions for basic data manipulation may be a good place to start. Sure, most of what you can probably imagine will have been made with something like Lodash, but it’s worth understanding how they’re constructed. These small projects can then be made public on Github and even published on NPM - it’s surprising how many people download your stuff and are willing to help by sending pull requests.

After making a few small bits, try making something more substantial - perhaps a small application with routing and different components. Depending on your level of experience, you may quickly be exposed to new parts of front-end dev such as object oriented and functional programming paradigms, as well as having an understanding of how to properly structure a front-end application.

I have recently made a few small projects such as Scrollus Pocus and Whiskr which I enjoyed developing as they’re pretty fun projects and allowed me an introduction to one or two new concepts I’ve not run into before.

Wrap it up

It’s exciting to learn new things, and whether you feel like using a framework or developing in vanilla JS, there is always a new or different way to approach a problem to help expand your understanding. Which approach you go down is up to you and probably more importantly your projects budget and timeline requirements, but I think it’s important to keep up-to-date with as many aspects of development as possible.