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

栏目: IT技术 · 发布时间: 4年前

内容简介:About a week ago, I've announced my new, open-source JavaScript UI library calledIsotope. 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

About a week ago, I've announced my new, open-source JavaScript UI library calledIsotope. 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 attop 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. :sweat_smile:

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 :star: while you're at it!

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


以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

处理器虚拟化技术

处理器虚拟化技术

邓志 / 电子工业出版社 / 2014-5-1 / CNY 109.00

《处理器虚拟化技术》针对在Intel处理器端的虚拟化技术(Intel Virtualization Technology for x86,即Intel VT-x)进行全面讲解。在Intel VT-x技术下实现了VMX(Virtual-Machine Extensions,虚拟机扩展)架构平台来支持对处理器的虚拟化管理。因此,VMX架构是Intel VT-x技术的核心。《处理器虚拟化技术》内容围绕V......一起来看看 《处理器虚拟化技术》 这本书的介绍吧!

图片转BASE64编码
图片转BASE64编码

在线图片转Base64编码工具

Markdown 在线编辑器
Markdown 在线编辑器

Markdown 在线编辑器

html转js在线工具
html转js在线工具

html转js在线工具