You can and should build one yourself, but you would benefit from using a framework in production.
Modern JavaScript and Browser APIs
Today you can achieve most of the features with "simple" JavaScript (TS) to update your state, have routing, a bundler with code splitting, maybe JSX, templating and even getting different components like a calendar or emoji picker you can do in many ways like copy an example from the web and make it your own or use an OSS web component.
Browsers and the JavaScript community have came pretty far from the old days of IE6. You have many ways to implement UIs and a ton of libs to do the small thing you want. jQuery and other major APIs were added to the library and our bundlers are plentiful with many features out of the box for all your CSS, HTML and JS needs.
Issues
Developers complain about speed, JS bundle size, react-dom weighs too much. Well if you think of these frameworks and their components as abstractions, you should try to understand the payoff. These known frameworks have been tested on many edge cases your own code wasn't even ran that many times. So many bugs were fixed and though you might not have the edge cases their fixes are in your framework. Is this a good thing? depends on your opinion, like best practices, would you want them implemented from the start for the chance you'll need them and enable extending your apps or prefer to keep it small and to the point.
A good reminder from OSS and from work is that everything you write will one day be legacy and will be passed to someone else to maintain potentially and in the worse case it will be you. IDK about you but I don't remember every line I wrote 5 years ago, who am I kidding, 3 months ago 😅. My point is that someone will have to deal with what you write and they will need docs and examples like StackOverflow or ChatGPT to maintain that shit you called the best thing ever. For me TypeScript helps with keeping things maintainable when paired with tests to ensure I don't break everything.
I recently updated my library Jstates and had to refactor the majority of the code after 2 years of not touching it, and it's a super simple library with 1 function. Having tests and types are a huge benefit, and I did go to many documentations for rollup, vite, vitest and other tools I used to update my code base.
Build your own Vanillajs framework
I like to breakdown tools to understand how they work to see how I could build the same and then understand the choices the author made and how things work underneath. I always try to create examples and enjoy the challenge (when it works). For the example, I worked on creating a frontend app without any framework, I used my Jstates library to have updating values and a lib for JSX and vite for bundling and the rest was pretty ok without a framework but with all the base features I need from any framework.
The repo
Including TypeScript, JSX, State updates, Templating, Routing, code splitting.. What else do you need?
Ok.. go ahead and add tailwind or another CSS lib, but IMO modern CSS is enough 🤷
I would recommend trying to build one yourself for learning, and maybe you'll find a use case to actually use it. For example, if you're unfamiliar with SPA routing, doing something like this could give you insights into what you need to do to trick the browser to do what you want and not redirect and refresh your frontend app on every click. There are also vanillajs libs for this just like anything else, the point it you can try and make things different and make your own.
I know there are many frameworks, some say too many, but I think it's a good thing. There are many use cases out there and it's great to find a battle tested, production ready framework that fits your needs that someone else is maintaining for free. The more we share our tooling the better they usually are by having more people contributing to the ecosystem with plugins, complimentary tooling, design libraries on top, creative ideas, articles and "How to" guides and more..
Frameworks are helpful to abstract away a lot and get something production tested very quickly off the ground if you know them already. Animations, pre built components and more and more features and capabilities.
More issues
Lots of people say they don't need all the new features in react because they don't have the needs of fb, well they might need all the goodies from the react community or they might need a new developer to get up and running fast in the new job, and they know react because it's the hottest thing right now. That's how the abstractions helps. Also in the job market, it's hard to find positions that don't require you to know one of the frontend frameworks for a frontend role.
This standardization, also around the frameworks features are there to help us abstract noise away and make us more productive. Many junior developers that I worked with had an easier time starting with a framework than Vanillajs, I started with jQuery. The issue for many is added features on top which they feel they don't need, and they might be right, even though you often don't have to use them in order to use the framework. Back in the early days of react, I met teams which used react for rendering and and older framework for their state management, this was before redux even and I think it was Backbone or something, anyway..
The real issue for many developers are the other developers on their team that would want to use these new features and abstract the code even more. I believe this is actually good as it would bring up the discussion of the benefit of the features and weighing their benefits. I was in some teams that were not using library features because of a bug or because the team decided not to. Only issue there is you go away from the main usage of the library, which might be harder in the future.
Final works (before everyone attacks 🫣)
Go build your own Vanillajs framework, learn from it, understand the frameworks you use better as a result and share the knowledge. And remember, if you think of open sourcing your framework or library, don't expect people to use it, and if they do, now you'll have to maintain it and hear their complaints like the lovely framework maintainers 🙇🙏
Some great examples are Solidjs and preact
Top comments (2)
I actually agree with this premise. I use a UI binding library instead of a framework. It’s smaller and easier overall. Actually, I just posted an article on it yesterday. peasy-ui article
Learned a lot from creating a small JQuery alike library and a few other packages/modules.