What the case against a nostr UI component library?

(built on ndk of course)

I'm blinded by the benefits.

#nostrdesign

Reply to this note

Please Login to reply.

Discussion

1. Making things looking/acting alike too much

2. Hiding the possibilities of new UX paradigms (albeit it’s very unlikely that the architecture of nostr has consequences all the way to UI components)

I’m much more persuaded by 1 than 2.

FWIW, there is an ndk components library, it’s just unstyled and very non-exhaustive (yet)

1. Yup, it's probably even less confusing for newcomers to get the interoperability part when the interoperable apps look and feel completely different.

2. I guess we shouldn't underestimate that neither

Thanks, needed that!

1. True. I’m not a fan of picking on too many battlefronts at the same time, but I philosophically dislike component libraries that make everything look the same, but I think this is downstream of a million different things so attacking this problem right now is not sensible.

To me the balance is in having unstyled components with very basic functionality, but maybe I’m wrong

"I’m not a fan of picking on too many battlefronts at the same time" 😹

You might not be interested in battlefronts, but battlefronts seem to be enormously interested in you then #infinitePabloApps

Oh shit, I didn’t see that one coming

😂😂😂😂

Here: 👑

It's not as interesting if you make them to be a drop-in as the main UI of a client. I tried to port Amethyst's components from a Phone to a Tablet and even that little difference made the ready-made components not that great to be used. It was easier to just redesign/recode them. I can only imagine how off it would look when you consider mouse vs touch UIs.

However, It could be interesting if it had a simpler goal. Users will mention an nevent inside a kind 1 note all the time. That nevent can be anything, any event type. Because of that, there is a strong need to render any event kind inside the kind1 note. And that could be a very powerful base UI library that devs would use before they develop their own custom components.

💯💯💯💯💯

This composability is 90% of the reason behind me writing this component library. My aim is for this library to be able to render all renderable event kinds because of exactly what you mention here.

🤝🤝🤝🤝🤝🤝🤝🤝

Thank you sirs!

That's the insight my brain needed to put the puzzle together.

Seems like a convenient library for something like njump to use then?

Exactly. Thats the goal

Too many use cases requiring ungodly number of components. I think our time is best spent laying a good foundation and helping existing clients level up as much as possible.

What about ndk svelte components?