Kamran Bekirov@kamranbekirovyz
Story: I made a set of Flutter widgets that aren't Material or Cupertino.
I use Flutter for web and desktop a lot. And if you do too, you probably know the pain: Material works fine for mobile, but on web and desktop it screams Google. Cupertino doesn't even make sense on larger screens. So, if you want your app to look like your own brand, you're building everything from scratch.
I've done that for 2 years at @UserOrient: it has a web dashboard built entirely with Flutter. Our designer made a clean, neutral design for it, I implemented it, and people kept saying it looks good. At some point I looked at all these widgets I built and thought: "I keep reusing these across projects anyway, why not let others use them too?"
But I didn't want to make a package. See, these are widgets, pixels, and if you import a package, you can't change how a button works inside without forking the whole thing. Then remembered, a friend told me once about shadcn in the web world and how it just gives you the component as a file. That felt right.
Decided to start with CLI: activate it, run a command, and it drops a plain Dart file into your lib folder. That file is yours. Edit it, move it, rename it, whatever.
That's Orient UI. It gives you two things:
1. style.dart: colors, typography, radii, durations, breakpoints. One file. Works with or without Material.
2. Widgets: buttons, toggles, navbars, toasts, popups, search fields, tabs, more. 25+ of them. All tested. All responsive.
One thing I didn't expect: style.dart became useful way beyond Orient UI's widgets. In my apps, I started putting all custom colors and typography there. It's now basically my whole app's design tokens in one place, and it doesn't fight Material's ThemeData at all.
Here's how it works:
> dart pub global activate orient_ui
> orient_ui init // creates lib/style.dart
> orient_ui add button // creates lib/button.dart
You don't replace MaterialApp either. Keep your Scaffold, your Navigator, everything. Orient UI sits next to it. Use its button but Material's TextField. Mix however you want.
Here's some questions I got and decisions I made along the way:
- Is this a design system?
Not really. It's foundational building blocks. You can use Orient UI's button next to Material's TextField and they won't fight each other. Use what you need, ignore the rest.
- Why plain files, not a package?
If it's a package, you can't change a button's internal logic without forking the whole thing. With plain files, you open button.dart and change whatever you want.
- Will there be Orient UI v2, v3, breaking changes?
No. There won't be. These are neutral, foundational widgets. A button is a button. A toggle is a toggle. You get the file, it's yours forever.
- Why not OrientButton, OrientApp?
I almost did. Then I realized that's annoying. Nobody wants to type a prefix on every widget. So the button is just Button. The theme is just Style. Simple names, no conflicts with Material's ThemeData.
- How do widgets know light/dark mode?
I could do Theme.of(context).brightness but that ties you to Material. What if someone uses CupertinoApp or just a plain WidgetsApp? So I made Style an InheritedWidget. You wrap your app with Style(), pass brightness, done. And if you don't wrap, it defaults to light. So wrapping is optional too.
- How does the CLI work?
It fetches templates from GitHub. No code generation, no build runner. You run a command, you get a file. That file imports style.dart for colors and typography. You point that import to wherever you put style.dart and you're set.
Also, Flutter team recently separated Material and Cupertino into their own packages. Maybe there's room for a third option. Maybe this is it.
Links in the first comment 👇🏻
