It is great to point out things that need improvement, but going so far as saying 'it isn't there yet', seems extreme.
If your use case requires these specific issues to be sorted, then it is great to know about them in advance. Nothing is perfect and every single app across every single framework is going to need to make trade offs.
If I needed text selection to be faster than what the built in component offers, I'd just develop my own component or spend some time debugging why the existing component is slow. Flutter itself doesn't prevent you from doing this.
If I needed multiple monitor support in my app, I'd probably not write it in Flutter because I looked at my app requirements in advance and realized that it doesn't support that.
The rest of the post seem to revolve around not having enough built-in ways of doing things. Again... you can't expect someone else to write your code for you and then call the whole framework lacking.
I’m sorry, but not supporting multiple windows (not monitors!) in a single process, and not supporting bog-standard desktop features like context menus, rightfully qualifies as “not there yet”.
It really depends on what the app you're developing requires. My app is just a few buttons for inputting data. I don't need context menus, multiple monitors or text selection. Thanks for the downvote though.
Although true, HTML doesn't let you customize context menus or (easily) open multiple windows either, and UI interactions frequently lag, but it's used for general desktop development all the time. These issues seem to be more that describing something as for desktop development raises the bar fairly significantly in terms of expected feature set. That's reasonable, but we should be careful in describing something as unsuitable because it lacks things HTML also lacks.
FWIW, I don’t consider web applications to be a suitable replacement for native desktop applications, not the least because they lack support for desktop UI conventions, which do exist for a reason; although it is true that many people nevertheless make do with web apps.
If your use case requires these specific issues to be sorted, then it is great to know about them in advance. Nothing is perfect and every single app across every single framework is going to need to make trade offs.
If I needed text selection to be faster than what the built in component offers, I'd just develop my own component or spend some time debugging why the existing component is slow. Flutter itself doesn't prevent you from doing this.
If I needed multiple monitor support in my app, I'd probably not write it in Flutter because I looked at my app requirements in advance and realized that it doesn't support that.
The rest of the post seem to revolve around not having enough built-in ways of doing things. Again... you can't expect someone else to write your code for you and then call the whole framework lacking.