Don't Build Your Own Framework

In 2019, I wanted to create a website that closely followed our custom design and had smooth animations and interactions. I looked at UIkit(opens in new tab), but I didn't pick it for two reasons:

• It had its own opinion on design
• It didn't meet my requirements for "smoothness"

This lead me to search for other frameworks that, unlike UIkit, provide just the basic JavaScript functionality, allowing you to style and animate as you wish. I didn't find anything. So, naturally, I decided to make my own thing(opens in new tab).

I was developing the framework in parallel with the website I was working on and it was wonderful. I was able to make the code just right and implement just the features I need. I took some inspiration from UIkit, but stuck to my main idea.

Later, I noticed that things weren't very efficient, so I decided to refactor. But because I was developing that framework and simultaneously using it, I had to rework not only the framework, but the website as well. Apart from that, I was trying to make this work for as many use cases as I could. What if you use React? What if you don't? What if you use jQuery? What if you don't even know JavaScript that much?

At this point, my enthusiasm slowly started to fade away. Without realizing it, I had put myself in a position where I wanted to solve problems that don't yet exist and solve them perfectly. But I still believed that in the end, it'd be "worth it".

Then, our team started to grow. I was no longer the only one working on that website. Since it used my framework, I had to onboard new people with it. This meant that I had to write up a README, then documentation, example usage, etc. Despite that, we still had to clear up some stuff in Slack.

Because our team grew, so did our workload. This caused work on the framework in parallel with the website to transition in work on the framework during the weekends and early mornings.

I carried on, though. I had (and to this point, still have) the habit of abandoning projects, so I was determined to at least boil the framework down to small organized JavaScript snippets that you could download via npm. But do I use Custom Elements(opens in new tab) or even go simpler than that and use just ES6 classes?

Recently, I started getting more and more into the React ecosystem. Late to the party, I know. I also started noticing more websites with <div id="__next"> or __nuxt or ___gatsby. So no matter how I build my framework, it wouldn't work with the way most people build for the web. Since I want to start using these tools as well, my framework won't work for me either.

Unrelated to this, I had slowly started to pay more attention to my health and well-being. I changed my eating and sleeping habits, started to exercise and stretch more, I even started reading books… This made the weekends and early mornings much more packed and valuable.

And now I'm here. I had made something that nobody really uses, but still represents a solid part of our workflow. What do I do? Well, I think I've learned some lessons in the past 3 years.

Code Doesn't Matter

Unless you're building software for aircraft or medical equipment, nobody really cares about your code, and neither should you. Especially in web development. At the end of the day, you want a bunch of boxes with text and images in them. You can have a hellish codebase and still get the job done. A perfect codebase doesn't exist. At least not for a very long time, in large projects, or with many people involved. Things will get messy and you should be ready to accept that.

Maintenance Is a Burden

Let's say you've built something and it works perfectly. That won't last long. Bugs will appear, new people will join and documentation will be needed, features will be requested. Who's going to handle that? If you're doing this as a side project, are you prepared to be distracted by these things while working? If not, are you prepared to do them in your free time?

Even if people start contributing with pull requests and taking some of that load off of you, you'll still have to review and approve of what's going on.

Third-Party Is Fine

If you find someone else who has done the work for you, use it. There might be things that you don't like, but compared to the hidden costs of maintaining something yourself, they won't matter. If that third-party code has been out for a long time, chances are that most common bugs and edge cases would have already been handled. Doing things yourself should be your last resort, because you'll slowly discover the same issues as well and waste time on solved problems.

Launch Early

On the off-chance that you really want or have to build something, launch it as soon as you can. As David Heinemeier Hansson said on episode "Launch Now" of the Rework podcast(opens in new tab):

If you're not uncomfortable by the time you're launching, it's way too late.

I never really launched my side project. It wasn't "ready". At the same time, it became a bigger and bigger dependency in our main projects. That's an issue, because you're building on top of something that isn't validated by other people. If I had shared it, maybe people would have helped out and given ideas for improvements. Or, maybe people would have critiqued it and made me question whether it's valuable.

And that's what I was most afraid of — that the project isn't valuable. But no matter how much effort you put into something, you still can't know for sure if it's valuable until other people give their own points of view. That's why it's better to launch as soon as possible:

• If you've built something valuable, you'll get more like-minded people to help you out with it

• If you've built something pointless, you'll save time and probably learn about new and better approaches

Conclusion

I will archive my project. These problems have already been solved by many people, many times. We all know that every day, a new JavaScript framework is born(opens in new tab). This happens because people like me think they've got the silver bullet and can solve a certain problem once and for all. But that's impossible and delusional. It's like that xkcd comic about standards(opens in new tab):

We should work on solving new problems, not existing ones. If you find an issue with someone else's code, report it or directly submit a pull request and fix it. Not just for yourself, but for everybody else! Your contributions will be nicely welcomed! Don't create something new with its own set of problems.

It's impossible to build something entirely by yourself. At some point, your "pristine" code will have to interact with other people's "messy" code. Sure, you might not use third-party code on your website, but its existence still depends on it. The operating system it runs on is not built by you. The browser that your viewers use to see it is not built by you. The protocols that carry your data across the wire are not designed by you.

You will always depend on other people's work. Embrace that!