I am unaware of how to use Flutter widgets inside a React app. But to address your other concerns,
So I want to share as much code between those platforms, to avoid maintaining different codebases as much as possible.
Given no other restrictions, this leads to a single Flutter app for both web and native. For a team as small as three we still found it easier than having multiple projects.
The key factor in merging our initial projects to one was the notion of mobile browsers. In a mobile browser you website should reduce itself to the look of your mobile app, unless they have different purposes. And this automatically happens with Flutter projects if you derive your layout breakpoints from screen size. Otherwise you would code your same narrow design twice: in Flutter for native apps and in React for web.
Same goes for native apps for tablets in landscape mode. They call for a layout that resembles your desktop browser version, and you automatically get it with Flutter.
Also in web version you may have more tools than in a native app, just because your screen allows it. Naturally, you would code this logic in JS. But then you get an order to migrate this to native apps. Would you then replace your JS logic with Dart logic compiled to JS and embedded into frames? This is a messy road.
Lastly, think of Mac, Linux and Windows platforms that will come to Flutter soon. Should you ever need a desktop native app, you would want the same layout as with web.
I want my website to feel like a web site more than a single page app.
The difference in feeling between a website and a single page app lies mostly in state management and URL handling. You may do the following to reduce it:
- Introduce URLs for your pages. By default, in Flutter every piece of action can happen under a single URL of
example.com/#/
. The window then feels fragile as there is no URL to copy and get back to. Flutter's Router API, released in Oct 2020, allows you to generate URLs on any change in your app's state and parse the state back from URL. If you do it right, then everything on your screen becomes a function of the URL, just like in traditional websites.
- Use
url_stragegy
package for your URLs to be example.com/path
rather than example.com/#/path
which immediately feels fake.
I have not found any other way of doing this than embedding them into iframes, which does not seem like a good idea, or does it ?
No, it does not. Mostly because you get too narrow a channel of communication of messages between JS windows. How would you listen to Flutter's BLoC's stream in another frame? It would take too much boilerplate code. Also I cannot think of easy debugging process.
To me, Flutter Web still has drawbacks:
- It takes awhile to load.
- Many specific JS APIs are not implemented yet.
- Many services you integrate with may not have Dart SDK, while having JS SDK. For instance, I struggled to get
Ably
working.
- No search engine optimization.
- You cannot use
em
as a screen unit, so scaling elements may get tricky.
Still with limited resources a single codebase outweights everything else.
To be clear, my team has been working on a web+native project the whole 2021. It now has passed most of the testing, but not yet released. For a sense of scale, it is a marketplace of 40+ screens.