IMO Flutter should have used the DOM for web. Right now it's reimplementing (and shipping) tons of stuff that the browser already solves: layouts, styles, text editing, spellchecking, etc.
I want my browser extensions to work. I want screen readers to be able to understand the webpage and read aria tags. I want to be able to copy+paste content. I want platform-native controls and input boxes, which support all of my OS's keyboard shortcuts for scrolling and moving the cursor around. I want the browser's dev tools to work, so I can delete unreadable color combinations and take a look at what fonts you're using. And use reader mode if I need to.
There's probably a shining hill on the other side of this mountain, where we have a nice cross-platform UI toolkit thats not electron. But there's an awful uncanny valley to cross along the way. In the valley nothing works quite right and apps are a bit ugly on every platform. The valley is a graveyard of good intentions and failed ambition. WxWindows. Java's Swing. In its own way, Qt. And Phonegap, and probably React Native, though that still has some life left in it. I hate using software in this place. Notion is dog slow. Java Spring apps were always ugly and weird. Apps made with Phonegap have halfbaked javascript replacements for iOS controls that look native but break when you try to use them like their native equivalents. Does Google Blogger still load so much GWT it needs a loading animation?
Maybe I'm letting my cynicism show. I hope Flutter succeeds. I worry that it won't, and its only legacy will be another wave of half broken apps that subtly break platform conventions.
Flutter's rendering may be fast and efficient on native code, its performance sucks when I try to use it in my browser. A website bringing its own javascript-based DOM tree to my browser engine is just ludicrous.
Flutter for the web feels like a "we made an app, might as well create a web version of it because it's one click anyway" kind of solution in the same way Electron is a "we made a website, might as well make it an app" solution. Comfortable for developers, but terrible for end users, unless you're willing to give up most of the developer comfort to work out the performance issues.
That's going to apply _again_ here: I really cannot visualize what you mean, beyond the comparison to Electron, which you nail. Flutter is "electron done right" for people like me building cross platform apps, it's a cross platform rendering engine, not a browser engine.
Presumably, this is immensely frustrating in your experience, but I really can't name a web app that uses Flutter - Flutter Web apps are/should be distributed like Electron apps. What's the Flutter Web app that frustrated you, I'm intensely curious, I didn't know people were trying to attempt that..
It works, but it feels off. It consumes loads of CPU, it's not close to the normal responsiveness of a real application and the whole feel is that of a video game UI, something alien to the rest of the system.
Putting Flutter Web into Electron honestly sounds like it would just produce slower Electron apps. One of the strengths of Flutter is that it can target multiple native systems with no code changes, so if you're going to provide a native download, just make a native executable and be done with it.
The state of Flutter Web is quite sad because it could easily become the de facto standard for web app development for platforms that would otherwise not allow your app (say, an app that wouldn't pass Apple's stringent requirements).
I don't blame the developers using Flutter to make apps for the shitty Flutter (and Flutter Web) performance, Google made the choice to drop all native components and render their own either through OpenGL or through a web canvas, and the usability problems that stem from that choice are Google's problem. Even after a few hours of messing around with Flutter, I could see its potential for app development. I'll still prefer a "real" native app any time, but I accept that not every dev shop has the resources to maintain separate code bases for the different platforms they support.
"Non-native" is not always a bad thing.
Setting aside the non-native look and the non-native feel, one reason it's almost always a bad thing in practice is because developers who re-invent everything rarely match the accessibility support of the native platform.
I've seen people attempt to create their own (oftentimes poorly documented and poorly tested, as well as poorly supported) web frameworks even in large projects far too often.
It seems that for any project that needs to be supported and maintained for years if not decades, the argument could be extended to: "Non-native and non-standard is usually a bad thing."
Of course, there's nothing wrong with using bleeding edge technology and writing your own frameworks and libraries, however that should only be done when and where it makes sense.
If I understand the code samples here correctly, Compose for Web enables someone to write basically standard HTML/CSS components (in the "React" sense) and the hope is that higher level components wrapping the platform-specific components will be written:
> Use and build Compose widgets that work on Android, Desktop, and Web by utilizing Kotlin's expect-actual mechanisms to provide platform-specific implementations
While layout will be handled in-house (not via traditional HTML layouts?)
> Experiment with a set of layout primitives and APIs that mimic the features you already know from Compose for Desktop and Android
This seems a much nicer approach than Flutter's default ("we render everything in a canvas")
But can this really pan out? Layout being handled in-house, non-native UI elements on iOS/Android (from what I have read) are strong signals the "higher level components" approach doesn't work in practice