UniUI Component Framework
1. Why I Started Working on It
I was exhausted by heavy 150KB UI libraries that dragged down page load speeds and forced complex CSS resets in university and production projects. I wanted a zero-runtime, accessible, and mathematically proportional component primitive.
2. What I Originally Imagined
A unified cross-framework UI library that works natively in React, Vue, Svelte, and vanilla HTML with zero bloat and sub-5ms render benchmarks.
3. First Version & Realities
A fragile collection of 12 unstyled CSS modules and button components written late at night on a budget laptop in my university dormitory.
4. First Users & Reaction
Three close university coursemates and two developers from an online Discord group who tested the initial alpha build.
5. Failures & Technical Obstacles
Initially attempted to build a custom CSS-in-JS runtime from scratch, which caused terrible hydration mismatches in Next.js Server Components. Scrapped 3 weeks of code and rewrote using pure CSS variables and utility primitives.
6. Technical Problems
Complex focus-trap accessibility for modal dialogs and nested dropdown menus across Safari iOS and mobile Chrome.
7. Business Problems & Commercial Reality
Realizing that open source developers do not pay for UI components unless there is a dramatic workflow acceleration and pre-built templates ecosystem.
8. Lessons Learned
- Simplicity of consumption beats cleverness of architecture every single time.
- Documentation and copy are 60% of an open source project’s adoption.
- Never build runtime complexity when standard CSS variables can solve the problem.
9. People Who Helped
Chinedu (early testing), Alex K. (accessibility feedback), Sarah M. (API review)
10. What I Would Do Differently
I would have started with the public documentation and component playground on day one before writing complex internal AST parsers.