Glad to see WASM support landing in Flutter, it always was a pain to have Flutter web apps load fast but if you needed a fully cross-platform (non-web-technology-based like Cordova or Ionic) solution between web and mobile, Flutter was essentially the only option. Yes, React Native Web exists but it is basically only developed as a third party solution by one developer. Expo for web is also fairly janky.
In my experience trying to find more alternatives to Flutter (due to "Flutter is going to die" rumors recently), I must say that Compose Multiplatform is quite far behind Flutter and it will take years for them to even catch up to Flutter as it is now, much less surpass it. Their iOS version just entered beta from the experimental phase a few weeks ago, and only Android and desktop (which is pretty niche as most developers aren't making desktop apps) really work, with web working just okay (and is still in the "experimental" phase) but doesn't have the optimizations that Flutter does today via WASM and Impeller (they still use Skia and will quickly realize why Flutter devs abandoned it in favor of writing a more performant engine).
This is not even to add that you can only create Compose Multiplatform apps on JetBrains IDEs and even their free (for now) Fleet editor is very buggy such that it was a struggle to get it even running properly on my MacBook. In fact, only Fleet currently has the view where you can see the UI change as you type code (and not even fully, it only renders the UI, not the logic, while in VSCode with Flutter, it will literally run the entire emulator view right inside the editor as a side panel).
So what's even the point? I might as well just use native frameworks or use Flutter, which has a better DX via hot reload that preserves state, as well as being able to be worked on in any editor you choose, not the one the creator of the framework locks you down to.
Call me back when Flutter can have an always-on accessibility system that doesn’t tank performance[1] (self-admitted!) and we can talk about potentially being ready for use in a production system.
I wonder how native iOS and Android solve it, wouldn't they also have a similar performance problem? I haven't delved too deep into the problem however so not sure myself.
A screen-reader user (or Braille display, any assistive tech that engages with the accessibility tree) deserves access to both an automatic system that doesn’t require them to engage a specific mode, and to a system that is as fast as any other. If your production system can’t do that because of your tech decisions then you’ve made the wrong decisions, given the plethora of other choices you could have made that don’t make that sacrifice.