I'm having an hard time following your criticism at this point.
It is true that I value being able to avoid business logic/interface separation altogether in small projects, but I also know it is important to split respinsabilities in medium/big sized applications. What I really don't like is having two separate languages for this purpose (e.g. Java/Xml or C#/Xaml) when one of them is already powerful enough to express both UI and behavior.
In this regard Flutter is perfect, as I can personally choose where to draw the "separation" line (if at all) while working with a single syntax.
This bit was poorly explained in the article; then again it's just a line in the introduction, not the main topic of discussion.
The purpose of my writing was to experiment around the slightly cumbersome interface of the StatefulWidget. I don't think I need to debate the fact that using a Widget class is more bloated than a simple function: it requires more lines of code and there were many other developers with my same concern in the quoted Github issue. I'm not saying that StatefulWidgets are impossible (or even hard) to use, mind you; functions are just a little bit better code-wise.
I agree on the fact that there are other reasons to use Widgets in Flutter. I also concede that I should have more clearly specified their inherent optimization importance - and I edited my essay to fix this.
Do you think I should be more careful when writing about certain topics, especially with small amounts of experience to back it up? I'll take that advice for sure.
Why did I publish an article when I knew I wasn't very qualified? This is not just advice or teaching material. it is mainly a report about some personal exercises.
It's not a compendium of best practices or a tutorial on how to get started: the title says "Functional bits in Flutter", as in a sprinkle of functional programming for the Flutter framework.
At times I even spell out loud that I'm being picky and tedious. My tone is clear and if, given these premises, the article were to be "read and consumed" as something that it's not I would write it off as a misunderstanding of the reader.
Even so, if someone followed my advice and eventually crashed against a laggy UI fixing the problem would not be hard - the warning about rebuild optimization was always there. I stand by my message, with all the clarifications that it required.
We are talking about two short articles with some code in them. There are personal opinions here and there, but I would say that's to be taken for granted when reviewing original work. I did not write a textbook.
Perhaps you mean I should avoid writing altogether in fear that someone might not get my message exactly how I envisioned it?
On the other hand, if this is about OOP vs FP I'll happily admit it is an hill I'm willing to die on.
“...you should opt out of Classes and Objects in favor of modules and functions.”
This is, in general ("most of the times"), good advice. The fact that the Flutter Widget tree is based on classes does not change that they are a convoluted construct and I wanted to highlight this. Again, my articles were not focused on implementation details (but they were mentioned regardless).
As a note, I did not submit my work to the Medium Flutter Community (from which much of its popularity comes from). I published the first article as independent author; a few days later, someone from the Flutter Community account reached out to me asking if it was okay to add it to the publication. Apparently they did not think my work was relaying harmful concepts to new developers.
