About a week ago, I've announced my new, open-source JavaScript UI library called Isotope. Overall, the launch wasn't anything spectacular, but I've gained enough feedback to know what to improve upon.

Open-source is a very specific niche, and when comparing Isotope to my previous open-source project for handling regular expressions in JS (ReX.js), which boomed in terms of the GitHub stars only to go down to the point where it is today, I think I prefer the slower, more stable approach that my new project has taken (currently at about 30 stars).

But, it's not the stats nor GitHub stars that I want to talk about today. No. Instead, it's the feedback that I've got, and more specifically, one question that you might have heard before: "Why another UI framework?"

UI frameworks landscape

The JavaScript ecosystem has never been in better shape than it is today. There are literally thousands of open-source JS projects and libraries with more coming up every day. And of all these libraries, the most popular are still - you've guessed it - UI frameworks.

I mean, that's all pretty obvious - just look at top GitHub repos that have most starts, or NPM packages that are downloaded most often, and you'll most likely see the top 3 contenders for the title of the best UI framework - React, Vue and Angular.

All 3 of these frameworks have years of development behind them, vast ecosystems of third-party tools and huge communities. They're popular among all kinds of developers - ranging from freelancers to ones working for huge companies. They're also actively maintained and don't seem to slow down.

But even with all of this, people are still creating new libraries and frameworks that are meant to do the very same thing - why?

Two sides of the coin

Having spent almost 4 years in the Web Development industry, I think that I only now get to understand both sides of the coin - the framework's users and the developers behind it.

Users

From an average user's perspective, a new framework (if it's any good) is only yet another option to choose from. Although most people will be picking from the top 3, there are some more adventurous developers, who want "something more from life". That's why they end up searching for other solutions.

I can say from experience that the whole decision-making process isn't anything one would enjoy. It takes a lot of time and usually leads to nothing. It leaves developers with a negative feeling towards anything new and makes them go back to picking from the top 3.

Developers

With that said, the perspective of framework developers is arguably more interesting.

First off, why do they even want to create their own framework in the first place? I can't speak for everyone, but, in my opinion, the most common reasons are:

Just to create something new that you could share with the world with potential hopes of it "taking off".
Being tired of choosing between all the already available options.
Having a truly revolutionary idea that may potentially change Web Development as a whole.

Notice how different all these reasons are from each other. The first one is just a casual "I want to make something" type of approach. I think there's nothing wrong with people making new stuff, even if it's just "a copy" of something that has come before. And if they decide to share it - fine! Naturally, it's going to make the decision-making process even harder for other developers (if they decide to include this new library as their potential choice), but that's just how it works.

The second reason is surely a bit funny, but I think it's logical that this necessity to choose pushes some people to just throw all existing options out of the window, only to make their own (in their opinion the best) tool of all.

The last reason is probably the rarest one, given that many new tools only feature improvements to the same concepts that were already present in the Web Development, potentially even for years now.

Status quo

Finally, I think we shouldn't be against creating new tools that serve the same purpose, as they help push the status quo. For example, when designing Isotope (which took 3 iterations and 1 year of development), I explored many different, lesser-known UI frameworks and libraries, only to learn what interesting techniques they're using to speed up the performance or improve the quality of their APIs. In this way, it really feels like one tool helps improve the other, constantly building up to something truly incredible.

Why Isotope?

With all that said, I wanted to do a quick "case-study" of everything I've just said, based on my experience with Isotope.

So, the reason I created it was mostly a mix of the two first listed. It's not like I've had any "revolutionary idea" that I wanted to bring to life. I simply wanted my own tool to accommodate my own projects nicely and comfortably. In the end, I decided to open-source it in hopes of building a potential community around it in the future.

But such a framework (or rather a library, as Isotope is leaning more towards this end of the spectrum), won't appeal to anybody if its only advantage is that it's "made by you". So, here, I also wanted to make Isotope stand out in a good way:

It's written in TypeScript for autocompletion in modern editors.
It's JavaScript-focused so that you don't require any additional tooling to get it up and running (future-proofing it for potential buildless future)
It has a nice and simple API to allow you to enjoy the development process even more.
It's fast and very lightweight.

I know that some of these "pros" might sound a bit generic, as every library is advertising its speed and small footprint. And thus, I decided to focus more on the API, making it feel nice and smooth, without any additional tooling like JSX, or template-based components. Just pure ECMAScript-compliant JavaScript! And I think I've achieved this goal, but you can check out this example and decide for yourself:

Marketing

Overall, all I've just presented is entering a bit into the open-source marketing territory. Yes, it's important even here. And if you're making your own library - you have to pay close attention to it. I did, but it seems like I should have given it a second thought, as my "statically-dynamic" catch-phrase turned out to be a bit confusing and simply unnecessary. 😅