Do we still need JavaScript frameworks?

It’s not necessary, it’s a circumstantial choice. Some people like to use them. I prefer libraries and vanilla JavaScript, and I’m far from alone. Take Github for example, which doesn’t use a framework and just stripped its last bit of jQuery out of github.com. They primarily use libraries and web components. That doesn’t mean you should never consider a framework, it’s just an example of not explicitly needing one.

The choice to use a framework or not comes down to understanding what your options are. Some of the other answers very clearly lack the distinction between libraries, frameworks, and raw JavaScript. I strongly encourage you to review The Many Flavors of JavaScript, which differentiates between each of these. Once you can see the difference, it will be much easier to determine which option is the right fit for your scenario.

By my observations (since the late 90’s) frameworks don’t really save you time. You just spend your time at different points in the software development life cycle.

For example, this is a graph I made tracking time spent on building your own framework and using a pre-built framework. The dark line represents development time for creating your own framework. The blue line represents the time of using an existing framework.

The upfront time spent creating your own framework seems massive… and it is substantial. However; as applications evolve and needs/complexity within them increase, the frameworks may not rapidly meet needs as well as they once appeared to. Frameworks are a bit like pre-calculated answers for problems — at some point you’ll need a solution for something the framework hasn’t pre-solved.

This is when you have to start digging into the internals of a framework. I consistently see teams that run into limitations because they need to do something against the norm with a framework. Asking the framework authors to do something outside of the norm or that doesn’t serve the majority audience can be met with resistance, forcing you to hack together a solution around the framework. In other words, you have to navigate through someone else’s approach towards development instead of your own. It’s not always confusing, but it can be tough to figure out the internals of other people’s code.

Then again, some apps don’t evolve too much, so a framework could be helpful if you don’t plan to change too much over time. This is true for proof of concept apps that you know will be rewritten once the concept is fleshed out/proven. Perhaps your “framework graph” levels out right away.

I also don’t believe frameworks necessarily make development accessible to lesser-skilled developers. Frameworks merely shift complexity.

Frameworks shine in team environments where multiple people will be working on the same code base. If you have 5 people who all know React, then you have 5 people who immediately understand the same set of standards. They know how to do the same kind of work, the same way. It’s commoditization of development (which is great in team environments). It’s also a good business move for some companies. If you lose a framework developer, you can find a replacement who doesn’t need much onboarding time.

So again, there are positives and negatives to using frameworks, meaning there are circumstances where it makes sense and circumstances where it does not. Just make sure you know what your options are before judging whether your project necessitates a framework.