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.