AuraUI v1.0 Roadmap: How can we make these components more performant? #12
-
|
Hello everyone! 🚀 I’ve been building AuraUI, a component library focused on high-fidelity aesthetics and smooth interactions. As the library grows, I want to ensure it isn't just "pretty," but also highly optimized, accessible, and developer-friendly. I’m opening this discussion to gather feedback on how to refine the existing architecture and where to focus our optimization efforts. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 4 replies
-
|
User: Dev_Optimize "This is a great initiative. I’ve been playing with the current build, and while the aesthetics are top-tier, I’m seeing some high GPU usage when multiple glassmorphic components are layered (especially in the Safari/Finder-style windows). My Suggestion: We should look into will-change: transform or backface-visibility: hidden for the animated containers to force hardware acceleration. Also, for the 'Genie effect' or window resizing, are we using requestAnimationFrame or letting Framer Motion handle the heavy lifting? Moving to a more 'lazy' rendering approach for hidden windows in the background would be a massive win for performance." |
Beta Was this translation helpful? Give feedback.
-
|
User: JS_Architect "Excited for v1.0! Regarding the architecture, I’d love to see a more modular approach to the bundle. Right now, if I only want the 'Dock' component, I feel like I'm importing a bit of overhead from the internal utility folder. My Suggestion: Can we ensure Nexa UI is fully tree-shakeable? Specifically, moving toward a sub-path export strategy (e.g., import { Button } from '@nexa-ui/core/button'). Also, standardized TypeScript interfaces for common props like size, variant, and color would make the developer experience much smoother across different components." |
Beta Was this translation helpful? Give feedback.
-
|
this looks really clean 👀 the glass + typography combo feels premium, not overdone for performance, I’d mainly look at:
also maybe worth standardizing glass values as tokens instead of hardcoding everywhere overall already looks solid, just need to be a bit careful with blur + motion since that’s usually where things slow down |
Beta Was this translation helpful? Give feedback.
-
|
"The UI looks incredible, but for a v1.0 roadmap, we have to talk about accessibility. High-fidelity UI often struggles with screen reader support and keyboard navigation—especially custom components like the 'Game Center' or 'Dynamic Windows. |
Beta Was this translation helpful? Give feedback.
-
|
That's a solid point, @Dev_Optimize! I’ve noticed the same lag on systems without dedicated GPUs. I’m currently experimenting with a 'Low-Power Mode' toggle that simplifies the backdrop-blurs. @JS_Architect, tree-shaking is definitely on the v1.0 list. I'm looking into how we can restructure the /src folder to make that possible without breaking the current API. |
Beta Was this translation helpful? Give feedback.
-
|
yeah good point on accessibility 👍 custom UI like windows can easily break keyboard nav + screen readers (looks cool, but users stuck 💀) |
Beta Was this translation helpful? Give feedback.
this looks really clean 👀 the glass + typography combo feels premium, not overdone
for performance, I’d mainly look at:
also maybe worth standardizing glass values as tokens instead of hardcoding everywhere
overall already looks solid, just need to be a bit careful with blur + motion since that’s usually where things slow down