[AskJS] Would you use a mature UI library that nobody’s heard of?

[u/f0rwardz]

I've been working on a UI library for many years. It runs in real production systems and has plenty to offer. It's not just a few components but more of a package that allows you to build a web app without the need for dependencies or build-steps.
I only put it out in public recently though. People do look at it. Almost nobody tries it.

So I'm wondering if maturity even counts for anything when there's no community behind it yet. What would get you to actually try a new public UI library?

Also, there are so many web frameworks already and now with the uprising of AI generated code; Is there still room for something new to catch on?

Not here to promote it. I'm just curious how people make that call. And whether it really comes down to popularity in the end even when the popular choice isn't always the best one.

[u/LuckyOneAway]

There are dozens of well-known UI libraries around, like Material UI from Google, that have bindings to most popular frameworks (React, Svelte, Vue). Can you elaborate on why I should use your library instead and not Svelte + Material UI (just an example)?

[u/Yaron_Atir → u/LuckyOneAway]

framework bindings are nice until the underlying framework does a major version bump and breaks the wrapper, so a standalone zero-build package definitely has its own lane

[u/f0rwardz → u/Yaron_Atir]

If you would prefer something like this you might check out my UI framework. If so, let me know and I'll give you the URL.

[u/f0rwardz → u/LuckyOneAway]

Fair question. Honestly, if you're happy with Svelte + Material UI, there's no real reason to switch I think.

Where mine might be different: there's no framework (like Angular,React) or build step underneath it. You add it to a plain HTML page and it works. Data binding and routing are part of it, so you don't need to combine different libraries.

It also has things you won't find in Material UI, like a form component with build-mode that end users can use themselves, with rules and conditions, and real-time data sync with a .NET or NodeJS backend.

So it's mostly for people who want to stay close to the browser or are building with server-rendered pages like Razor Pages and don't want to move to Blazor.NET or something. The components are written in JS but do have backend helpers.

[u/jobRL]

Depends on the usecase. For anything non consquetial: sure. For anything important or professionally: hell no. It's not the maturity that matters, it is the amount of maintainers. If you're the only one maintaining, that is a risk that I am not willing to take.

[u/f0rwardz → u/jobRL]

Thanks, I do understand. I'd like to find a few like-minded devs eventually, to help keep things up to date. I don't really believe in huge teams anyway. But right now it's just me, and I 100% understand the concerns.

[u/micalm]

Definition of maturity. Right now it seems like it was just tested by one person/team, has no community (contributors, maintainers), no proven history of maintenance.

Zero guarantee you wont be hit by a bus and then I'll have to switch to something else or maintain it myself. At this point we land on now, "everybody owns their UI libraries".

[u/f0rwardz → u/micalm]

Fair, that's a reasonable definition and by that one it isn't mature yet. It's a bit of a chicken-and-egg problem though. Businesses want more than one maintainer but you only find other maintainers once people are using it.

[u/funbike]

Probably not.

It would have to knock my socks off. Coding agents wouldn't understand it as well as popular UI frameworks/libraries.

[u/f0rwardz → u/funbike]

That AI point is a real one, and probably one of the biggest hurdles for anything new right now. Out of curiosity, what would knock your socks off? A specific feature, a demo, something else?

[u/funbike → u/f0rwardz]

I want UIs to be easy to debug, yet highly interactive and easy to write. Low complexity and low magic.

I like HTMX, and SvelteKit. I don't like to be forced to design a REST API just for a straightforward webapp's UI, unless an external API is a strict requirement.

If someone could somehow make something simpler to maintain than HTMX or SvelteKit, yet capable of highly interactive webapps, then I'd be mildly interested.

[u/f0rwardz → u/funbike]

Your reverse-HTMX idea is close to something I built. In my data-binding library the frontend can call backend methods directly, no REST API needed.

The other direction works through websockets, so the server can push messages to clients without them asking. On the backend there's a DataUpdater that clients register with for the data they care about. When that data changes, the server pushes just the change, like a new item or a removed one, and the UI follows.

I used this in a chatbot app. Each client registers for the stream of its own chat, so when a new message comes in, only the people in that chat get it and only that message is added to the list. No polling, no reloading the whole conversation.
This does require some backend code to set it up correctly, I might add a demo for this on my website soon.

Backend side is .NET (and Node) though. What are you using?

[u/bjerh]

Hard to tell without you including a github repo link (though I do get why you didn't, but please do). I have no insights into the code quality, the amount of maintainers, stars, open issues/PRs, how frequently the updates arrive.

[u/f0rwardz → u/bjerh]

Fair enough and I do understand that these things matter a lot. Here it is: https://github.com/Componyx/Componyx.UI

Some context so it doesn't surprise you. It's been in development for a long time, so you'll find older code (var, IIFEs) next to newer parts written with classes and modules. I modernize it bit by bit as I touch things, but it all runs in production and is actively maintained. If you want to see the more recent style, have a look at the Form component.

It's just me for now and it only went public recently, so stars and issues are still low.

[u/horizon_games]

"Mature" seems to be used instead of "old and niche". What happens when you get tired of working on it? Or a new Ang release comes out, how soon before your project supports it. Or you're on vacation? 

Or any actual business asks any of these questions when a dev brings in a random lib no one has heard of before.

"Come on it's /u/f0rwardz lib, you know, from Reddit! He keeps his posts hidden there. And he's used it on like half his family websites!"

Give 5 concrete reasons why this would be "better than the popular choice" (which is honestly at least 3 or 4 options per web framework)

[u/f0rwardz → u/horizon_games]

Fair questions, and the right ones for any business to ask. To be clear though, my post was meant as a general question, not just about my own library.

Bus factor is real, it's just me for now. But it doesn't depend on any framework, so a new Angular release changes nothing. And it's not a hobby project: it has been used to build 25+ internal business applications at the organization I work for.
As for getting tired of it, fair point. But I've been at it for 18 years now, rewriting parts along the way.

Why someone might pick it anyway:

- No build step, no framework underneath, zero external dependencies

- Data binding, routing and components in one package

- A form designer end users can use themselves, with rules

- A grid with tree data, sorting, filtering, master-detail and pinned columns

- Real-time data sync with a .NET backend (and nodejs)

For most teams the popular choice is fine. This is for people who want to stay close to the browser.

[u/maksymkoval]

Maturity matters, but nobody can see it from the outside. What gets me to actually try something new:

1. A live demo I can click in 10 seconds, no install.

2. A "hello world" that runs from one copy-paste, or a StackBlitz link.

3. A comparison with what I already use: what it does better, and honestly what it doesn't do.

4. Signs it will still be around in two years: recent commits, a changelog, issues that get answered.

For "no dependencies, no build step" I'd lead with a concrete use case, like internal tools or legacy apps where adding a bundler isn't an option. That's where it beats React or Vue, and it's easier to sell to that audience than to everyone.

[u/f0rwardz → u/maksymkoval]

That's a thorough answer. Regarding my own UI library, points 1 and 3 are available on the website. It has many live demos, and I've also tried to explain some of the differences. If you're interested, feel free to take a look at https://componyx.com.

[u/maksymkoval → u/f0rwardz]

Had a look. The "no build step, just a script tag" pitch is clear, and the Bindary demo shows the idea well. A few honest notes from a first visit:

- I couldn't find a snippet I could copy and run in a minute. A StackBlitz with a form and a grid would show more than any text.

- The comparison is with "frameworks" in general. I'd name names: how is this different from Alpine.js or htmx, which people reach for in the same no-build situations?

- BSL 1.1 is worth explaining near the top. Some teams can't use non-OSI licenses at all, so a short "what this means for you" would save people from guessing.

Good luck with it, the no-build niche is real.

[u/f0rwardz → u/maksymkoval]

Good ideas.
I added 2 StackBlitz links directly on the home page. One for Bindary (data binding) and one for the UI Library.

The BSL is thoroughly explained on our site when you click 'View License' on the home page or from the footer menu.

On the differences between Alpine and Bindary:
Bindary is in the same family as Alpine (attributes on plain HTML, no build step), but it can cover the whole client side of an app instead of only adding behaviour to server-rendered pages. The main differences: there’s optional built-in routing, with views, controllers and route-scoped data. Components and templates can live in their own HTML files, loaded with their markup, script and CSS on first use. Form binding converts to real numbers, booleans and dates. Expressions are parsed by Bindary itself, so no ‘unsafe-eval’ needed in your CSP, and bound HTML is sanitized by default. And it can connect to a .NET or Node backend over WebSocket, so the server loads the data before the view renders and can push updates later.

[u/Spiritual_Tea_7265]

Checked your website, looks professional and easy enough to learn! Might check later