DEV Community

Cover image for Why I've made "yet another UI framework"?
Arek Nawo
Arek Nawo

Posted on • Originally published at areknawo.com

Why I've made "yet another UI framework"?

#javascript #framework #webdev

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. 😅

What do you think?

So, what do you think about this whole "yet another UI framework" debate? This here is just my point of view, but I'd love to hear yours!

Also, if I've managed to get you interested in Isotope, consider checking it out and dropping a star ⭐ while you're at it!

For more Isotope and Web Development content follow me on Twitter or Facebook. Thanks for reading!

Top comments (4)

Collapse
 
areknawo profile image
Arek Nawo • • Edited

I mentioned it in the post. I know there are many UI libraries already out there, and mine is (to some degree) similar to all of them.
With that said, the main advantage of Isotope is its API. It's designed to be used comfortably without any additional tooling (pure JS), and without any performance or size penalty.
To put it in contrast to some of the other libraries you've listed:

  • Preact is basically a lightweight React alternative, thus it's most likely to be used with JSX. Sure, it's optional, but then the development experience (DX drops significantly. Also, Isotope is a tiny bit smaller than Preact.
  • Hyperapp is also reliant on JSX to improve the DX, however to a bit lesser degree. It's also smaller than the Isotope.
  • Mithril - again, JSX, but also a much bigger size (Mithril min + gzip is the same as Isotope without gzip). However, it can be justified with Mithril being more of a framework than a library (it provides e.g. routing and XHR functionalities)
  • Stencil - it's more of its own thing. It's a toolchain intended to simplify the creation of Web Components. Also, if you're interested in Web Components - Isotope should work with them just fine.

As for the performance comparison - I can't say exactly. I tested Isotope against Svelte, React and vanilla JS using this benchmark, and it landed only a bit behind Svelte. I've already opened a PR to add my library to the comparison. But, based on the results, I'd say that Isotope would certainly beat Mithril, don't know about Preact and would be a bit behind Hyperapp.

Collapse
 
chibiblasphem profile image
Debove Christopher •

Seeing the example in the Playground I don't really understand why the API is the main advantage of isotope :o
To me it seems as much difficult to read than React without JSX. In a sense, yeah it's chainable but what's the real difference between :

const container = view
    .main({
        classes: ["container", "fluid"]
    })
    .div({
        classes: ["columns", "is-centered", "is-vcentered", "is-mobile"]
    })
    .div({
        classes: ["column", "is-narrow"],
        state: {
            input: "",
            todos: []
        },
        styles: {
            width: "70%"
        }
    });
container
    .h1({
        classes: ["has-text-centered", "title"]
    })
    .text("Isotope TODO");
container.$(Form);
container.$(List);

and

const container = React.createElement('main', { className: 'container fluid' },
    React.createElement('div', { className: 'columns is-centered is-vcentered is-mobile' },
        React.createElement('div', { className: 'column is-narrow', style: { width: '70%' } },
            React.createElement('h1', { className: 'has-text-centered title'}, 'Isotope TODO'),
            React.createElement(Form),
            React.createElement(List),
        )
    )
);
Thread Thread
 
areknawo profile image
Arek Nawo •

Formatting doesn't do the justification here. 😅 However, I see your point.
IMHO, the div() like methods are better than repetitive React.createElement(), and the ability to supply classes as arrays is also a bit easier than through strings.

 
areknawo profile image
Arek Nawo •

Certainly, it's similar, but it does have state management. It just doesn't automatically handle state data passing down the node hierarchy. And it also has some additional features, like directives, and context.

Read next

paulsanjay81 profile image

From Slow to Swift: A Developer's Guide to High-Performance Web Design

Sanjay Paul -

harold_defree profile image

Month 1: The Kickoff – Building the Foundation

Harold Defree -

cp_nandani profile image

Building a Better Monorepo with TypeScript, Turborepo, or Nx

Nandani Sharma -

witcher_1001 profile image

🌐 SSH Tunneling: Securely Connect to Remote Networks Like a Pro

The Witcher -