Sorry for causing confusion about components vs component sets. I did not mean to state anything against the idea of _component_. What I called an element (probably after DOM Elements) and what you call a component are very similar if not the same thing. My point was against the idea of "here is a _predefined set_ of components, and we call it a UI library". Such predefined sets limit the use of the library to someone's personal/pet project and don't attract professional users. When designing/building a library, if the developer is spending most of their time on implementing those things, then it shows: abstractions are not properly designed, things that could have been separate pieces are coupled, etc.
So, in short, I totally agree with you on the idea of React components. However, bootstrap and tailwind are completely different things that are attractive to a different set of users. React is a UI library, the others are just that set of components, maybe with some level of customizability, and they are all awful. If you are building an application, you wouldn't touch Tailwind or Bootstrap, but if you are a cheap agency spitting out websites like a printing press, then you might love those predefined sets which help you build cheap things for cheap. Regarding accessibility, many people limit the idea to assistive technologies, probably imagining a blind person browsing the web using a screen reader. Although that's very important (I have visually impaired family members and even if I hadn't, I would still care about this a lot), limiting the understanding of accessibility to AT is just wrong. There are a lot of aspects to cover, and a UI library can be very helpful to developers with its design, guiding the user toward building more accessible interactions. Most UI libraries do the very opposite as most are designed and implemented with full focus on implementation details and a lack of understanding of the human side of the communication mechanism an application delivers. A good example of awful accessibility is PDF: funny enough, a PDF document with two-column letter/A4 pages could be as accessible to a blind person on a phone as well as on a desktop, but you cannot say the same for the majority of consumers who can read visible text without assistive technologies: One needs to zoom in and keep scrolling in every direction to be able to follow the text due to the completely unfitting layout. Accessibility is another reason for most people jumping on Electron (or native widgets), but I think, for a UI library designer, there's no excuse for not diving into this. If you're going to spend many days, if not months, on having your fonts rendered nicely and efficiently on the screen, you better spend some time on how the consumer will actually _access that beauty_. Leaving things to the monopoly of a few systems/libraries/products is probably one of the worst things about the state of the art today. It is vital to have more people who are willing to dive deep and tackle hard things in new ways if we don't want to be using Electron-based desktop environments (MS UWP!?) in an upcoming OS update. About being composable and allowing users to utilize your library in different ways (without starting library vs framework wars :), I think the signal/slot idea that you want to adopt is on good track. It should be easy for the user to define _events/signals_ that their _components_ could emit as well as completely replace that mechanism when they don't need it or when they want to control things in their own way, in their own loop. It mostly falls onto the API/DSL design to make the process as convenient and intuitive as possible. The box type is not limited, really. It defines the layout and appearance, and everything comes with _sensible defaults_ (sensible to me, at least :D). The default renderer has various features like shape, fill, and border. A box's content (child elements) would be centered horizontally and vertically _by default_. The definition has separate parts exactly the way HTML and CSS work but with a design for user interfaces rather than scientific papers and notes _—the web is a collection of documents and every single web application is a hack using a technology for something outside its design aim_. Basically, I'm looking at what we have, mostly the web, and then removing things that are completely unfit, such as almost every element accepting text as its content and all that flows, reflows, spans... then flex boxes and grids... All the patchy solutions to make something that it is not. But I steal the basic idea of having separate places to define what a button is, how it behaves, and what color its shadow will be. As a concept, CSS is great: I do not mean the disaster called cascading, but simply the idea of attaching a set of definitions to an object in a separate place, with a separate syntax, as it makes things much clearer, manageable, and convenient.
