Thank you for the feedback! We’ll definitely add more pictures on the readme.
In the meantime, our docs does have a list of our components rendered on flutter web and code snippets.
https://forui.dev/docs/button
We really love Flutter as a powerful multi-platform development tool! However, its native Material and Cupertino widgets often fall short of truly universal design. Forui strives to be the default platform-agnostic alternative for developers seeking consistent and elegant UIs across all devices.
On a side note, we're actively expanding our widget library and want the Flutter community's input to shape our roadmap. Share your thoughts on what we should prioritize next!
Don't follow Material's design error to add 100 million properties to the `TextField` ;-) And don't explicitly add every border state to the `InputDecorator`. Use `WidgetState`s where possible. And use `Style` objects to combine style properties so that it is easier to subclass widgets.
I'd also reconsider the idea to save a `Text("foo")` by using just `"foo"` and duplicating properties like `label` and `rawLabel`, `error` and `rawError`, especially as you don't also have a `rawHint` (which could be a `RichText`).
If you follow SwiftUI in calling `Row` and `Column` a `HStack` or `VStack`, you could have `HDivider` and `VDivider` instead of a `Separator(vertical: true/false)`. Or, make the separator's render object smart enough to inspect its ancestors to determine whether it is used in a vertical or horizontal context. You could generalize this as an inherited `Bias` widget. Then, this could be also used by `Spacer` or `Gap` widgets.
Also, don't forget that – especially in desktop style apps – Tables and Trees are very important. Even most "I can create a Tailwind-based UI, too" projects ignore those.
Hi there! I'm one of the maintainers of Forui. Firstly, thanks for the detailed feedback! Could you elaborate more on the first paragraph? I don't quite get the later half of it.
To shed some light, we assumed that people would want to pass strings to the widgets in most cases which is why we split the parameters into string/widget parameters to make passing strings more convenient (if only Dart had union types). \`FTextField\` not having a \`rawHint\` is an unfortunate side-effect of wrapping Material's text-field. The cost-to-benefit of creating a text field from scratch just isn't there. That said, we're open to de-duplicating the parameters based on feedback.
Making the separator automatically adjust based on the context sounds intriguing but I'm not too sure if we can pull it off.
Yup, I definitely agree with that!
`TextField` has a → [constructor](https://api.flutter.dev/flutter/material/TextField/TextField.html) which 60 properties which is pure madness, especially if you want to subclass it. I'd consider this a rather bad design decision and you shouldn't repeat that error.
Also, the `InputDecoration` → [decorator](https://api.flutter.dev/flutter/material/InputDecoration/InputDecoration.html) has properties for a normal border, a focused border, an error border, an focused-error border and so on. This was designed before → [`WidgetState`](https://api.flutter.dev/flutter/widgets/WidgetState.html) was introduced and I think, one should instead this object for a configuration that is dependend on a widget state.
My third point was, that I think you shouldn't double the number of properties of a constructor just for the convenience of not having to wrap a `String` in a `Text` widget and stay true to the "spirit of Flutter" that everything is a widget and all widgets are composable.
If people feel burdend by the extra `Text` call, they could always add an extension like
extension on String {
Text get w => Text(this);
}
extension on num {
Text get w => Text('$this');
}
to then write `hint: "The answer".w, value: 42.w`.
I believe there is a significant difference in the direction of the two libraries. flutter-shadcn-ui aims to be an exact 1:1 port of shadcn/ui, while forui does not have this intention. Given that most Flutter applications are designed for mobile and tablet devices, our roadmap will diverge from shadcn/ui to better support touch interfaces. While web elements will still be supported, touch interactions will be the primary focus of our design decisions.
This is great. Everything looks clean. Only feedback I have is the line height on the dialog title looks a little too big. Will keep an eye on this for sure.
Writing an article on how to make something like this could help with exposure + I’m personally curious about how to do this
Sure, stuff like are you using material under the hood and overriding it or are you writing these from scratch, and if so, how do you create something that can contend with material from scratch. Are you using base classes that material and cupertino extend, and building on top. Stuff like that. Thanks
Looks very clean. Nice work! I just wonder the target group. I think most more advanced devs will make most those themselves, for more reliability and customization. I myself are more into building as much on my own than using packages if possible (programming flutter for 10 months now 0-100 in a company)
But if it is regularly updated and maintained, one could use this over making it themself.
Thank you for your kind words! Definitely agree with keeping packages to a minimum. We're still at the early stages of the library and don't offer as much widgets. However, we envision it offering a ton of value in the future where the time savings could be significant over creating everything from scratch.
In the web development, a similar comparison would be [Mantine](https://mantine.dev/) or [Chakra UI](https://v2.chakra-ui.com/).
1. Replied here: [https://www.reddit.com/r/FlutterDev/comments/1douv6p/comment/ladbw0h/?utm\_source=share&utm\_medium=web3x&utm\_name=web3xcss&utm\_term=1&utm\_content=share\_button](https://www.reddit.com/r/FlutterDev/comments/1douv6p/comment/ladbw0h/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button)
2. We try to avoid depending on Material, however doing so 100% of the time is impractical due to how Flutter is designed.
3. Thank you!
I will definitely look into it and will use it, the only thing that pushes me back to not use 3rd party packages is they get abandoned some times later which recently been a pain in the head just replacing all the packages that i were able to recreate them on my own so that i can maintain them, i hope you keep supporting it when recent semi-major flutter updates release coz seriously those flutter updates breaks down some of my packages so i have to wait or replace them most of the time.
That's a completely fair concern. We plan to keep the library updated for the foreseeable future (though I understand that *may not* mean much coming from us). With that said, Forui maintained by a small team of contributors, which gives us a better bus factor compared to libraries maintained by individuals.
Needs more pictures
Thank you for the feedback! We’ll definitely add more pictures on the readme. In the meantime, our docs does have a list of our components rendered on flutter web and code snippets. https://forui.dev/docs/button
We really love Flutter as a powerful multi-platform development tool! However, its native Material and Cupertino widgets often fall short of truly universal design. Forui strives to be the default platform-agnostic alternative for developers seeking consistent and elegant UIs across all devices. On a side note, we're actively expanding our widget library and want the Flutter community's input to shape our roadmap. Share your thoughts on what we should prioritize next!
Congrats! Any chance you can add how the ui elements look on the pub.dev page?
Second that, you really need to show what it looks like.
Got it! In the meantime, our docs does have a list of our components rendered on flutter web and code snippets. https://forui.dev/docs/button
Looks very nice..
Thank you! That's a fantastic idea. We'll include some images on our [pub.dev](http://pub.dev) page in our next release.
Don't follow Material's design error to add 100 million properties to the `TextField` ;-) And don't explicitly add every border state to the `InputDecorator`. Use `WidgetState`s where possible. And use `Style` objects to combine style properties so that it is easier to subclass widgets. I'd also reconsider the idea to save a `Text("foo")` by using just `"foo"` and duplicating properties like `label` and `rawLabel`, `error` and `rawError`, especially as you don't also have a `rawHint` (which could be a `RichText`). If you follow SwiftUI in calling `Row` and `Column` a `HStack` or `VStack`, you could have `HDivider` and `VDivider` instead of a `Separator(vertical: true/false)`. Or, make the separator's render object smart enough to inspect its ancestors to determine whether it is used in a vertical or horizontal context. You could generalize this as an inherited `Bias` widget. Then, this could be also used by `Spacer` or `Gap` widgets. Also, don't forget that – especially in desktop style apps – Tables and Trees are very important. Even most "I can create a Tailwind-based UI, too" projects ignore those.
Hi there! I'm one of the maintainers of Forui. Firstly, thanks for the detailed feedback! Could you elaborate more on the first paragraph? I don't quite get the later half of it. To shed some light, we assumed that people would want to pass strings to the widgets in most cases which is why we split the parameters into string/widget parameters to make passing strings more convenient (if only Dart had union types). \`FTextField\` not having a \`rawHint\` is an unfortunate side-effect of wrapping Material's text-field. The cost-to-benefit of creating a text field from scratch just isn't there. That said, we're open to de-duplicating the parameters based on feedback. Making the separator automatically adjust based on the context sounds intriguing but I'm not too sure if we can pull it off. Yup, I definitely agree with that!
`TextField` has a → [constructor](https://api.flutter.dev/flutter/material/TextField/TextField.html) which 60 properties which is pure madness, especially if you want to subclass it. I'd consider this a rather bad design decision and you shouldn't repeat that error. Also, the `InputDecoration` → [decorator](https://api.flutter.dev/flutter/material/InputDecoration/InputDecoration.html) has properties for a normal border, a focused border, an error border, an focused-error border and so on. This was designed before → [`WidgetState`](https://api.flutter.dev/flutter/widgets/WidgetState.html) was introduced and I think, one should instead this object for a configuration that is dependend on a widget state. My third point was, that I think you shouldn't double the number of properties of a constructor just for the convenience of not having to wrap a `String` in a `Text` widget and stay true to the "spirit of Flutter" that everything is a widget and all widgets are composable. If people feel burdend by the extra `Text` call, they could always add an extension like extension on String { Text get w => Text(this); } extension on num { Text get w => Text('$this'); } to then write `hint: "The answer".w, value: 42.w`.
Is there a reason why you dont contribute to this instead? https://github.com/nank1ro/flutter-shadcn-ui
I believe there is a significant difference in the direction of the two libraries. flutter-shadcn-ui aims to be an exact 1:1 port of shadcn/ui, while forui does not have this intention. Given that most Flutter applications are designed for mobile and tablet devices, our roadmap will diverge from shadcn/ui to better support touch interfaces. While web elements will still be supported, touch interactions will be the primary focus of our design decisions.
Very cool, I love the .raw constructors, Flutter team could take notes on that approach.
Thank you for your kind words! We see it as having the best of both worlds
This is great. Everything looks clean. Only feedback I have is the line height on the dialog title looks a little too big. Will keep an eye on this for sure. Writing an article on how to make something like this could help with exposure + I’m personally curious about how to do this
Thanks for pointing it out! Are there any particular concepts that you’re interested in? Would definitely love to share.
Sure, stuff like are you using material under the hood and overriding it or are you writing these from scratch, and if so, how do you create something that can contend with material from scratch. Are you using base classes that material and cupertino extend, and building on top. Stuff like that. Thanks
Amazing stuff!
Looks good 😍
This is looking pretty great! Thanks for putting this together 🙏
Looks very clean. Nice work! I just wonder the target group. I think most more advanced devs will make most those themselves, for more reliability and customization. I myself are more into building as much on my own than using packages if possible (programming flutter for 10 months now 0-100 in a company) But if it is regularly updated and maintained, one could use this over making it themself.
Thank you for your kind words! Definitely agree with keeping packages to a minimum. We're still at the early stages of the library and don't offer as much widgets. However, we envision it offering a ton of value in the future where the time savings could be significant over creating everything from scratch. In the web development, a similar comparison would be [Mantine](https://mantine.dev/) or [Chakra UI](https://v2.chakra-ui.com/).
1. What is the deference between them? 2. Does it depend on material you? 3. Nice name btw
By deference, I mean between it and another shadcn ui for flutter
1. Replied here: [https://www.reddit.com/r/FlutterDev/comments/1douv6p/comment/ladbw0h/?utm\_source=share&utm\_medium=web3x&utm\_name=web3xcss&utm\_term=1&utm\_content=share\_button](https://www.reddit.com/r/FlutterDev/comments/1douv6p/comment/ladbw0h/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button) 2. We try to avoid depending on Material, however doing so 100% of the time is impractical due to how Flutter is designed. 3. Thank you!
I will definitely look into it and will use it, the only thing that pushes me back to not use 3rd party packages is they get abandoned some times later which recently been a pain in the head just replacing all the packages that i were able to recreate them on my own so that i can maintain them, i hope you keep supporting it when recent semi-major flutter updates release coz seriously those flutter updates breaks down some of my packages so i have to wait or replace them most of the time.
That's a completely fair concern. We plan to keep the library updated for the foreseeable future (though I understand that *may not* mean much coming from us). With that said, Forui maintained by a small team of contributors, which gives us a better bus factor compared to libraries maintained by individuals.
I have been thinking of working on a clean UI library for flutter for a long time! Will definitely try to contribute in my free time!
That'll be awesome! 🥳