You don't need a javascript framework

In my last article I taking about The myth of cross platform software and recommended people to just exclusively target the web for most projects.
Sadly the web is still far from perfect, and a major reason for this is the "javascript ecosystem" and most importantly javascript frameworks. What's so bad about frameworks you might ask? Let's find out!

Less secure

Frameworks objectively make your webapp less secure because they increase the code footprint and thus the potential exploitable surface area. If you've ever tried to update an old project that pulls packages from npm you've probably seen many warning pop up in your console about outdated libraries with security vulnerabilities. One could argue that through the power of open source software these issues will automagically be fixed before they affect you, but clearly this is not the case since these bugs managed to slip into production software. So you should start asking yourself this: Which is more important, security or whatever benefits the framework gives you?

Inconvient level of abstraction

I've never experienced a framework that didn't get in my way at some point. Some frameworks (Anglular) are too high level to the point where you have to write more code than in vanilla javascript to hack your away around the abstractions. And others (React) are not abstract enough, so you end up writing the exact same code as you would in vanilla javascript.
The first is great if you're creating a business application where nothing unique is going on, but for anything outside of that it's borderline unusable. The latter might sound a bit better but it's really not since you expect you can just write good old javascript and get it to work when this is rarely the case.

Slow

Most Javascript frameworks have absolutely no regard for performance whatsoever, pulling in way more dependencies than neccesary for the job and relying on terrible abstractions like a virtual dom.
What's the deal with virtual doms anyway? They make your app way slow and you're still manually triggering re-renders with the deceptively named setState function.
And don't forget that this framework slowness isn't something you can optimize later down the line. You've chosen the framework, and the framework has chosen slowness. The only way to improve performance is to ditch the framework and rewrite your app in something that isn't slow. Good luck :-)

Less cross platform

This one is huge because it affects the entire web development space. Frameworks create vendor lock-in for your application, once you start using a framework there's no way to switch to another without doing a major rewrite.
This isn't so bad for end-user applications, but what about libraries?
If authors create a framework specific library it can only be used by developers using that specific framework.
If authors create a vanilla js library the developers using it will likely spend hours fighting their frameworks to properly integrate it and realistically they will fail, creating a buggy experience for the end user.
If authors create a library that explicitly supports many different frameworks they've just increased their workload by 10x. Keep in mind that this is an invented problem. It wouldn't exist if everyone just used plain old javascript.

If this doesn't sound bad enough already, fragmenting the "community" like this has deeper implications. Since we now need to write dozens of different implementations of the same UI component for all the different frameworks the competent programmers will be split between all these libraries. So instead of having seven talented developers that are passionate about the one and only colorpicker.js You might only have a single talented developer maintainging his react-colorpicker.
And what if a color picker doesn't yet exist for your frameworks of choice? This scenario might incentivise a mediocore programmer to create a port of an existing one, poor performance and security vulnerabilities included!
Now that mediocore programmers are writing libraries the libraries will no longer be lightweight, causing bundle sizes and node_modules to bloat. The most hilarious example of this i've personally found was a markdown to pdf converter that was neither a markdown parser nor a pdf converter. The markdown part of the equation wasn't so bad, they just used an off the shelf markdown library. For the pdf part howerver they decided to use puppeteer, a headless Google chrome.
That's right, a selfproclaimed "simple" markdown to pdf converter that pulls in an entire google chrome into its dependencies.

We've now reached a point where libraries I try to find are dependent on javascript frameworks, rendering them completely useless.

And while we're at it, what's the deal with javascript related stack overflow questions huh? Someone asks a perfectly reasonable question only to get a dozen jquery-using idiots in the replies. Is there anyone that appreciates this behaviour? Answers like that should get you insta-banned!

"Just write your own framework lol"

Yes. Unironically.
Don't know where to start? Grecha.js is a good example of homebrewed javascript done right. The entire framework is just 69 lines long, provides minimal syntax for dynamically generating html and even has a router.
Don't like something about their approach? Just change it! The entire thing is 69 lines long.