Yet another MVVM framework (uxjs) is born. By why? I keep writing my own frameworks. For years, I've wondered if there was any value in writing them?
Here's what I think:
- Learning - When I first started programming, It all seemed to be like magic to me. For me to demystify this magic, I had to build it myself.
- Control - When I am tasked with developing things for clients, I get to control everything!
Do you build your own frameworks?
if so...
what is the value for you?
Top comments (4)
Great question. My answer is No. I have tried writing my own frameworks (especially for APIs) multiple times. I find that frameworks which require extending or plugging into its abstractions are a road to pain. Code ends up coupled to the framework. Changes to frameworks tend to be breaking. But it always happens that I later run into a use case that the framework I wrote doesn't quite cover, requiring breaking changes. And frameworks tend to be the leakiest of abstractions. You often can't use them properly unless you understand how they work internally. And usually the framework abstractions require you to learn specific details about them that doesn't transfer to anything else. For example, something valuable could be taking the space in my brain that Angular 1 directive knowledge currently occupies. That's probably why I haven't liked any UI frameworks I've ever used up until Elm (MVU pattern).
Libraries where you can choose to use or not use its specific functions are the nicest to work with.
I will always build new frameworks. But for fun and learn only.
For real projects, I will use an existing (and reliable) framework.
Framework will structure your code and improve readability.
They save a lot of time and will probably even be faster.
And if you pick the good one, you will always stay in control of what's happening.
I see no good reason for not using a framework to be honest.
I think there's a glut of frameworks and it causes a lot of confusion.
But there have been a lot of cases where a framework got updated and caused huge problems on production sites.
Case in point: When Angular went to... I think it was v2? Anyways, it was a major update. I had a friend and a client, both using the previous version of Angular heavily and big sites worth a lot of money. The move to the new version meant their current version had an end of life and they had to move along. It forced them to spend a lot of money on the update.
A custom framework feels like it can avoid that issue because you maintain what you need and you are in charge of breaking or not breaking your site.
That comes with trade-offs and it's not always worth it.
There's some use in a custom framework, for sure, if not for anything else but for not having someone else put a gun to your head, so to speak.
Though not a framework, I have written a couple of JavaScript libraries (Winwheel.js most notably) and learned a lot in the process about HTML canvas - this has been the main benefit.
In my case there was nothing else out there doing that sort of thing at the time, so I though what I had created for a fun project might be useful to others and turned it in to an open source module.
I would caution about creating your own framework for client projects, this creates some risk to them that they will not be able to find other developers who can maintain or add new features to their site / product if you are no longer available.
Many years ago I worked for a web development agency who created their own CMS framework and one of the clients with a site still on it can't find anyone who wants to work on the codebase to make changes the client needs to one of the calculation tools.
Fortunately I am still around and willing to make the changes, but I'm 1 of only about 2 people in the entire world who understands how the thing works. Also great that the client is finally considering a rebuild of the tool in a modern framework.