Flutter is a pretty nice framework and has a lot of fans, but the web version indeed has issues. The web wants to be the high level framework and doesn't provide low level APIs, Flutter wants to be the high level framework and tries to do that on top of the wrong abstraction level, the result isn't ideal.
There are a few ways to tackle this:
1. Try to improve Flutter Web.
2. Try to improve browsers, so people can use non-HTML frameworks without compromise.
3. Escape the browser.
It doesn't seem likely that (1) or (2) are going to yield much fruit. Flutter already works well on mobile and has picked up a surprisingly large proportion of mobile apps in the app stores. The obvious path is therefore to do the same on the big screen and distribute as desktop apps. The UX can be better than you'd think, especially as internet connections get faster.
This approach solves a lot of the problems the article complains about. Desktop apps can export proper accessibility trees, do keyboard focus properly, they can start really fast and so on (and flutter apps do start fast).
I talked about this path and why it's getting easier on the It's All Widgets podcast [1]. We've added support for Flutter apps to Conveyor [2] so the packaging and deployment aspect is now much better for people who choose to use it. But there's still work to do, to make all that work really well:
• Flutter Desktop has some native code to start and load the VM, which you're expected to customize and compile. That's a pity because the actual code is all Dart bytecode, so this complicates compilation without much justification. It could be made to work the same way as Electron or the JVM where you have pre-made binaries.
• Signing. Conveyor can sign for any OS from any OS so the technical pain goes away, and you can also do self-signing. But "proper" signing is not ideal.
• Sandboxing.
You could have a browser-like thing that provides sandboxing, caching and so on whilst exposing low level APIs, whilst doing a much better job of being 'semantic' than the web ever did. Actually I wrote up a proposal for such a system [3] and sent it to Ian Hickson who runs Flutter, but as he observed, the problem is incentives. Developers generally don't pay for platforms outside of cloud services and game engines, so, nobody is incentivized to build out the infrastructure to solve those problems. For as long as that's the case, people will try to hack the browser into submission.
Comments
Flutter is a pretty nice framework and has a lot of fans, but the web version indeed has issues. The web wants to be the high level framework and doesn't provide low level APIs, Flutter wants to be the high level framework and tries to do that on top of the wrong abstraction level, the result isn't ideal.
There are a few ways to tackle this:
1. Try to improve Flutter Web.
2. Try to improve browsers, so people can use non-HTML frameworks without compromise.
3. Escape the browser.
It doesn't seem likely that (1) or (2) are going to yield much fruit. Flutter already works well on mobile and has picked up a surprisingly large proportion of mobile apps in the app stores. The obvious path is therefore to do the same on the big screen and distribute as desktop apps. The UX can be better than you'd think, especially as internet connections get faster.
This approach solves a lot of the problems the article complains about. Desktop apps can export proper accessibility trees, do keyboard focus properly, they can start really fast and so on (and flutter apps do start fast).
I talked about this path and why it's getting easier on the It's All Widgets podcast [1]. We've added support for Flutter apps to Conveyor [2] so the packaging and deployment aspect is now much better for people who choose to use it. But there's still work to do, to make all that work really well:
• Flutter Desktop has some native code to start and load the VM, which you're expected to customize and compile. That's a pity because the actual code is all Dart bytecode, so this complicates compilation without much justification. It could be made to work the same way as Electron or the JVM where you have pre-made binaries.
• Signing. Conveyor can sign for any OS from any OS so the technical pain goes away, and you can also do self-signing. But "proper" signing is not ideal.
• Sandboxing.
You could have a browser-like thing that provides sandboxing, caching and so on whilst exposing low level APIs, whilst doing a much better job of being 'semantic' than the web ever did. Actually I wrote up a proposal for such a system [3] and sent it to Ian Hickson who runs Flutter, but as he observed, the problem is incentives. Developers generally don't pay for platforms outside of cloud services and game engines, so, nobody is incentivized to build out the infrastructure to solve those problems. For as long as that's the case, people will try to hack the browser into submission.
[1] https://itsallwidgets.com/podcast/episodes/46/mike-hearn
[2] https://hydraulic.software/blog/10-flutter.html
[3] https://docs.google.com/document/d/1oDBw4fWyRNug3_f5mXWdlgDI...