MaherSafadii · November 18, 2025 20:13
diff --git a/gistfile1.txt b/gistfile1.txt
 Flutter decorating solution

 General notes:

 - If the reason to not go with a solution is because of “we have to get used to it” or “it’s hard to get used to it”, the reason is discarded, because this can be said about anything in any framework.

    - why are we even planning to use a new solution for decorating widgets when things work fine? things currently work but there are flaws than can be improved by a lot, Flutter is always known (made fun of by Flutter haters) for the heavy nesting and tons of parenthesis and commas everywhere, you might ask, well devs can get used to these problems? This is true, I currently use Flutter and navigate and write code flawlessly, but for incoming devs, it might reduce Flutters appeal to them.

 - Flutter has a problem which is called “Everything is a widget”, it sounds like a good concept but it really isn’t, I remember when I first tried Flutter years ago when trying to apply padding, there turns out to be a specific widget that adds padding which I found odd, I saw it as a weird convention, it added an extra depth layer to the widget tree, and it wasn’t just Padding that did this, every single decoration related widget does, want to change the opacity, wrap the widget in the Opacity widget, wan to change the background color, wrap it in another widget, you can imagine how much of these common operations UI have, a lot, which result in lots of tree depth layers, this is a result of everything having to be a widget, Flutter needs to separation between actual UI components/controls and decorators, the only things that are allowed to add a depth layer are UI controls, decorating the UI which we can refer as painting them shouldn’t.


 SwiftUI modifier thoughts:



 - SwiftUI’s modifier system is overrated, lots of devs think that they’re the ultimate solution because”the big Apple” went with them, while they have benefits like improving code readability, they bring some serious issues with them like unable to see a Widgets parameters before hand is a serious DX problem, you can’t glimpse at all the customizable parameters when using a widget, you will have to learn and memorize all of them beforehand, you might think that it’s a good sacrifice to take if we’re improving code readability by a lot, well it would be someone manageable with the built in widgets, but it becomes tricky when using packages, because they bring new widgets, and you will no longer be able to glimpse at their parameters so you would have to switch to the docs every single time you want to check them, you might ask what if the package doesn’t use modifiers for their widgets, and this is true, which is the other issue that SwiftUI is suffering from, having multiple conversions like this will open doors to messy API design, some devs creating packages will go with the swiftUI modifier style for their API design and some won’t which will make things a pain working with, this personally felt when using SwiftUI. 

 - another issue with this solution is that it’s hard to know or decide what should be a modifier and what should be a parameter, you might thing Apple made common things between views as modifiers and view specific things as parameters, no, the Text view has its own modifiers like .bold() and it also has other customizable parameters which add to the confusing APIs mess that extend to packages.


 Jetpack Compose modifier thoughts:

 - Compose's solution to the decorating and tree depth problem is my favorite, they didn’t make everything a composable like Flutter, neither did they go with the pretty looking SwiftUI ones, they chose convenience other anything else, they chose a hybrid of SwiftUI’s modifiers and their own solution, which is having a fixed set of modifiers that apply to all composables, they achieve this by adding a modifier parameter to every single composable that takes a Modifier object, then you chain modifiers to this object just like you’re treating a SwiftUI view, this eliminates every single unnecessary depth layer while providing a seamless elegant API to use.
	Flutter decorating solution

	General notes:

	- If the reason to not go with a solution is because of “we have to get used to it” or “it’s hard to get used to it”, the reason is discarded, because this can be said about anything in any framework.

	- why are we even planning to use a new solution for decorating widgets when things work fine? things currently work but there are flaws than can be improved by a lot, Flutter is always known (made fun of by Flutter haters) for the heavy nesting and tons of parenthesis and commas everywhere, you might ask, well devs can get used to these problems? This is true, I currently use Flutter and navigate and write code flawlessly, but for incoming devs, it might reduce Flutters appeal to them.

	- Flutter has a problem which is called “Everything is a widget”, it sounds like a good concept but it really isn’t, I remember when I first tried Flutter years ago when trying to apply padding, there turns out to be a specific widget that adds padding which I found odd, I saw it as a weird convention, it added an extra depth layer to the widget tree, and it wasn’t just Padding that did this, every single decoration related widget does, want to change the opacity, wrap the widget in the Opacity widget, wan to change the background color, wrap it in another widget, you can imagine how much of these common operations UI have, a lot, which result in lots of tree depth layers, this is a result of everything having to be a widget, Flutter needs to separation between actual UI components/controls and decorators, the only things that are allowed to add a depth layer are UI controls, decorating the UI which we can refer as painting them shouldn’t.


	SwiftUI modifier thoughts:



	- SwiftUI’s modifier system is overrated, lots of devs think that they’re the ultimate solution because”the big Apple” went with them, while they have benefits like improving code readability, they bring some serious issues with them like unable to see a Widgets parameters before hand is a serious DX problem, you can’t glimpse at all the customizable parameters when using a widget, you will have to learn and memorize all of them beforehand, you might think that it’s a good sacrifice to take if we’re improving code readability by a lot, well it would be someone manageable with the built in widgets, but it becomes tricky when using packages, because they bring new widgets, and you will no longer be able to glimpse at their parameters so you would have to switch to the docs every single time you want to check them, you might ask what if the package doesn’t use modifiers for their widgets, and this is true, which is the other issue that SwiftUI is suffering from, having multiple conversions like this will open doors to messy API design, some devs creating packages will go with the swiftUI modifier style for their API design and some won’t which will make things a pain working with, this personally felt when using SwiftUI.

	- another issue with this solution is that it’s hard to know or decide what should be a modifier and what should be a parameter, you might thing Apple made common things between views as modifiers and view specific things as parameters, no, the Text view has its own modifiers like .bold() and it also has other customizable parameters which add to the confusing APIs mess that extend to packages.


	Jetpack Compose modifier thoughts:

	- Compose's solution to the decorating and tree depth problem is my favorite, they didn’t make everything a composable like Flutter, neither did they go with the pretty looking SwiftUI ones, they chose convenience other anything else, they chose a hybrid of SwiftUI’s modifiers and their own solution, which is having a fixed set of modifiers that apply to all composables, they achieve this by adding a modifier parameter to every single composable that takes a Modifier object, then you chain modifiers to this object just like you’re treating a SwiftUI view, this eliminates every single unnecessary depth layer while providing a seamless elegant API to use.
No results found