What if you click an action in a popup and closed the popup or navigate to another page in the SPA all-together. Without a toast you have no way of knowing if an async action failed.
I agree though that we should try to put the info closer to the user's attention, but still Toasts should be used as a fallback.
This is a core VS Code vulnerability, the remote development extension is mentioned because this vulnerability can be used to "take over the computer of a Visual Studio Code user and any computers they were connected to" using the remote development extension.
AOT compiled to native code that uses the native instruction set - no interpreter/vm involved.
Uses custom rendering engine based on Skia.
Can write UX just once for all platforms if you don't mind fixing the widget set.
Custom widgets work on all supported platforms.
Can in theory be ported to Desktops also, assuming someone writes flutter engine bindings for Win/MacOS/Linux. If this occurs, then you will truly have a modern, cross-XP, write-once-run-anywhere, compile-to-pure-binary, reactive UX framework
React Native is already ported to desktops but you need to write N times for N platforms. In flutter, you can write just once after choosing a widget set, assuming you don't mind the same widgets everywhere.
So it's like Xamarin -- there's UI for iOS, UI for Windows, UI for Android, but you can also use "Xamarin Forms" and have a similar appearance everywhere. But there's nothing stopping there from being a "React Forms" or whatever that does the same thing, is there?
Flutter has MUCH better performance than Xamarin Forms though. React could theoretically have something just as good for a cross platform UI toolkit, but given that Flutter took several years to even get to a beta, I think that would probably be a long and expensive project for Facebook and they're likely just not interested in it. That sort of thing sort of runs against the core philosophy of React Native anyways.
> being a "React Forms" or whatever that does the same thing, is there?
Nothing stopping it, nope. I'm surprised there isn't something currently.
That said, it isn't so bad using different render functions for different platforms. The state management and event handling should be 100% consistent.
Besides, going all in on a single render engine limits you to creating special "holes" to utilize controls native to the platform. Im not sure if flutter supports this, but I doubt it.
- Flutter renders the UI itself rather than using native components, so you get the same experience on both iOS and Android.
- Flutter uses Dart, which can be compiled AOT, rather than relying on an interpreter.
- Flutter is completely open source, tools, engine, all of it. You can go a long way down before hitting iOS platform code, for example, that you don't have source access for.
> -Flutter renders the UI itself rather than using native components, so you get the same experience on both iOS and Android.
I thought this was an antipattern in modern mobile device Dev, since you're supposed to make your app "look and feel native" by always using native widgets where possible (and was a major argument for why, eg. Cordova was inferior to react native). Has the collective agreement turned on this, or it is simply contentious?
My personal opinion has definitely shifted, maybe partly because I'm tired of inferior Android experiences of the same app, but also because the looks of Android and iOS seem to be converging anyway.
While maybe they couldn't before, many apps seemingly can now get away with one UX for both platforms - that is a strong simplifier and gives a potential branding advantage.
It may be a good idea to still implement some "platform sensitive" widgets (some behaviors are still slightly different), but the demand for them seems to have drastically gone down.
They seem similar in intent and application, however Flutter skips the Javascript-to-native bridge and instead appears to compile to native code for the targeted platform directly, making it faster. In practice, React Native still _feels_ native because it is native and most devices are fast enough for most applications, but the Javascript that operates the native components has a performance penalty due to the bridge between javascript and native.
Dart still has a huge hill to climb for mindshare. The staggering amount of community and documentation around react makes it difficult to carve out a competing solution without the same size of community to write documentation, examples, and answer questions on Stack Overflow.
> React Native still _feels_ native because it is native
A lot of React Native isn't "Native", but that term is hard to define. They certainly display plaform-own widgets, but afaik they use their own layout functions and such.
