Google’s Flutter = React and Java Swing
codeburst.io
codeburst.io
Right now the weak point of Flutter is that there aren't many plugins for utilizing platform specific features. This always the fault line with these cross-platform frameworks. These will come I'm sure of. It's relatively easy to write a plugin which is a great plus.
I've done native development on both Android and iOS. Tried Cordova-based development. Lastly React Native. Out of all these I like Flutter the most. You will make a beautiful app with much less work compared to native development and other alternatives. The performance is also fantastic. Flutter uses its own high-performance rendering engine to draw widgets. Almost the entirety of Flutter is written in Dart; also the lower parts. This is important for development because nothing is closed off. With everything being written in Dart it gives you a high degree of control.
My early work so far using Flutter;
https://play.google.com/store/apps/details?id=org.me.tvligen... (Danish television listings)
https://play.google.com/store/apps/details?id=dk.kjeldsen.et... (Ethereum blockchain explorer)
This is how I would like to have seen ChromeOS being implemented, a fresh revisit of the Smalltalk experience but using Dart instead.
Instead they created a browser window manager.
Hopefully it will be something like that, a nice micro-kernel OS, using a mix of C++/Rust and Dart.
But given how Google projects go, it might just be canceled or pivot into something else, e.g. Brillo vs Android Things.
I see that C++, some C, go, rust, python, yes dart and possibly other languages are being used. First I was thinking this is crazy, but then I'm reminded of how much each modern Operating System is more or less "C" based, where any non-C language has to make bindings, ffi connections, etc. to get to the low-level.
Instead, use something like mojo (called fidl), which is like protobuf, but only for IPC - e.g. much more lightweight (but doesn't support endianess handling), and use it for communication between the systems. Make fidl generate bindings for each languages, and wire everything together with it.
(mojo to my knowledge is what the chrome browser uses to communicate with it's isolated instances).
"Smalltalk Revisited" doesn't solve any problems per-se, and would be firmly stuck in the chicken and egg corner that produced way too many stillborn projects in IT.
So, Chrome OS implementing Dart might have been interesting, but on the other hand, as soon as there was talk about adding Dart to the web platform, there were all those rants about "Google is monopolizing the web!!!!11". I guess it's hard to please everyone.
(disclosure: I'm on the Chrome OS firmware team. Although while "Chrome", there's definitely no Javascript or Flutter involved. My team's code needs to run in the absence of arbitrary amounts of RAM [edit-to-add: which means I have no stake in the game of which language has a hipster-compatible garbage collector])
When they try to sell them, it is a single model on a corner of the shop with increasing discounts until someone finally takes it away, or they return the unit back.
So from European point of view those "lots of useful tools to solve problems with the computer, based on a wide ecosystem." are nowhere to be seen.
> My team's code needs to run in the absence of arbitrary amounts of RAM
Chrome's memory usage on the process system monitor shows a different reality about that code.
Very different reality in the US. My local best buy and Target have at least 4 high end chrome books each for sale.
> Chrome's memory usage on the process system monitor shows a different reality about that code.
?? I'm a bit confused by this, his team writes chrome os firmware code, nothing to do with the browser.
That's a sad reality of Google products that aren't free ("monetized through ads" if you prefer) web services: Unless you're in the US, they might as well not exist.
It's just impossible to sign up for them legitimately (ie. without using a VPN, US credit card and a forwarding mail address in the US.)
Personally I think that a plethora of the "paid" Google products (including Chromebooks!) could do pretty well in Europe if given the chance, but for reasons good or bad they never get the chance to prove themselves in the market in the first place.
> When they try to sell them, it is a single model on a corner of the shop with increasing discounts
Nevertheless, _when_ they are available, they're doing a bit better than you describe it: https://geizhals.de/?phist=1461289 https://geizhals.de/?phist=1483242 https://geizhals.de/?phist=1564920 https://geizhals.de/?phist=1378869 https://geizhals.de/?phist=1439976 are a sample of devices for the German market (limited the search to the set of devices with a DE keyboard to avoid imported models, whose prices fluctuate wildly and aren't what people typically consider regular market availability), both low-end and high-end, and the development of those price indexes looks pretty normal for notebooks.
> Chrome's memory usage on the process system monitor shows a different reality about that code.
"Chrome OS firmware team". My team's code doesn't ever show up on the process system monitor.
I am describing computer stores where people walk into, not online stores.
> "Chrome OS firmware team". My team's code doesn't ever show up on the process system monitor.
So, nothing that would have a major impact on using a more productive operating system, and wouldn't forbid the use Dart instead of the JavaScript/HTML/CSS triumvirate.
There are two major issues that make them a worse source for data points on hardware popularity than online stores:
1. Availability: it's hard to get the numbers in an aggregate form, while I just skimmed a search engine for 5 minutes.
2. Shelf space: brick and mortar stores can only ship 2 devices of a small set of major OEMs. With such constraints, they'll limit themselves to what they belive will be block busters in their (brick&mortar) market, creating a reinforcing loop.
Before the iPhone (say 2003), many stores didn't even carry Apple computers because they were "niche" and incapable of running Magix Video Deluxe.
It's too expensive to keep "one of everything" around when you pay $$$ for every square meter of shop space. That's a market distortion, not a hyper-realistic representation of customer intent.
> So from European point of view those "lots of useful tools to solve problems with the computer, based on a wide ecosystem." are nowhere to be seen.
These "useful tools" are web sites (and web apps). By providing excellent support for these, the devices are immediately useful. Much better than hoping that another ecosystem like Android's can be jumpstarted.
The average user buys a (hypothetical) Dartbook: Looks for some Dart app. Gets frustrated by the lack of choice. Returns the device.
The average user buys a Chromebook: Browses their favorite websites (and face it: 90% of contemporary computer use is _just_ _that_). Reasonably happy customer (unless they insist on installing "TuneUp Utilities" because they always do that).
That's what I meant with the availability of lots of useful tools to solve problems with the computer (in that case, a Chromebook), repurposing a wide ecosystem (the entire web, basically).
From your other comments on this site (eg about the Atom editor), you seem to be fundamentally opposed to html/js as a platform and with that sentiment, Chromebooks must look anathema to you. Alright, that's one position to take. But what use would be a Dartbook to you? You'd probably complain (with full reason!) about its inability to run emacs just the same.
Web browser app....
> The average user buys a Chromebook:
And returns it back after discovering it cannot install his/her favorute software and requires a permanent internet connection to make anything useful with the device.
> The average user buys a (hypothetical) Dartbook: Looks for some Dart app. Gets frustrated by the lack of choice. Returns the device.
The return rate of those devices running Android is quite big apparently.
> But what use would be a Dartbook to you?
The same as my tablet and mobile phone running Android.
The battery life is wonderful for that price bracket (~8-10 hours, <300€). I used crouton for a few month, which enabled me to install Ubuntu 14.04 in dual-boot. you could switch between ChromeOS and the chosen Linux window manager (i first used unity but switched to i3wm eventually).
At some point, i removed it again because I hardly used the Linux environment anymore. There a pretty fine text editors as offline chrome-extensions available (i.e. Caret) and that was the only two use-cases I had for the laptop... browsing the internet and making text notes.
BTW, a lot of webapps, or "Web browser app" as you call them, have offline support. So no, you don't need an internet connection to use them.
What I love is being able to do cloud development (Linux) on a commercial laptop.
I wish Google would push this harder as a great dev solution. My biggest gripe is small storage on most CBs. Plus no sdcard access from containers on the R11. Also all Android runs in same container.
I have bought Chromebooks for my employees. They can access business resources without me having to worry about them getting hacked and leaking proprietary information and passwords to production systems. Chromebooks are cheap, unsexy, and can't run fancy games. These are all pluses.
Chromebooks are the 3270 of the present day. They're for the average customer service representative, not for the home user.
I think Google is overall a pretty "evil" (I use quotes because the term is loaded, and the reasoning is too long to easily state) company. IMO Google is, at best, hard-to-trust, and at worst adversarial in many of the decisions they make. But I sure am excited when it produces technology like Android, Golang, Flutter etc and makes it free to use.
Personal opinions aside, what they've done here is managed to create a full-measure cross platform mobile application, and they have the resources that warrant taking them seriously. All the other options are either half measures or require such a drastic shift/ongoing support that I hesitate to use them, to list a few:
- Cordova/Phonegap (half-measure)
- React Native (Facebook is your benevolent dictator)
- Lambda Native (convince the team to go full lisp, and hope/build support as the platforms change under you)
- Native (learn all the ins and out of 2+ different platforms, and hope to be prolific, because you'll likely not be expert in either one)
I just wanna know if anyone else has this dilemma/thinks about this.
IANAL, but the license (https://github.com/flutter/flutter/blob/master/LICENSE) is basically MIT + don't put google's name in your product... Maybe I'm thinking about this too much
My approaches are C++ using a MVVM architecture with native views, Xamarin, or just focus on a single platform.
Depending on what I want to implement.
I certainly do. I asked this question before, but I get the feeling that most people here just want to take what's good from Google, and still question all their evil doings. I think that's hypocritical.
I don't see that as hypocritical. I just want the 'good parts' of my relationship with my wife while still being able to criticize her sometimes. I want the useful parts of government while still being allowed to criticize them frequently. It's not that unusual a state, really.
Personally I think it's great that people who use Google's products are still willing to take us to task. User/civic feedback is an important mechanism to keep big companies like Google in line.
But I hope you don't take it as an offense when I say that I wouldn't want to be married to the devil, no matter how good looking she is ;)
Also, I'm curious: how do you feel about banking with a financial institution that has a favorable interest rate but trades in weapons of war?
> User/civic feedback is an important mechanism to keep big companies like Google in line.
Sadly, all too often communication with Google is a one way street, from user support questions to ethical issues.
Depends, who are they trading with? Our democratic allies? Fine. North Korea? I'd have a problem with that.
That said, I'm not as hostile to big tech companies in general as your average HN commenter, as I see a bunch of advantages in having them around, and things like companies using anonymized user data for ads don't bother me as long as they're handled competently.
Sometimes I think people forget the history of how and why Google got where it is. They've had some snafus, but for the most part just been a freaking awesome company from the start who puts out amazing, free things, and push OS and CS research forward.
No, I have no guilt using anything they make.
I think you have mistaken Google for Microsoft Research, in what concerns pushing OS research forward.
They had a huge impact on .NET AOT compiler for Windows 8, .NET Native for UWP, Linux subsystem, Windows containers and secure kernel. Including asynch/await, .NET TPL, concepts now spread to other languages.
You are missing Drawbdrige, Singularity's sucessor, where pico-processes where researched and are the basis of the Linux subsystem.
Or the P language, a type dependent language, used to write the new USB stack.
And many other findings, easy to track down at their website.
Really? How do you explain Secure Enclave, end-to-end iMessage encryption and lots more? Not to mention the tough stance they publicly took against FBI wanting special OS version to crack terrorist phones?
> Secure Enclave
ARM TrustZone. My 2005-era low-end devices have that. Hardly Apple's idea.
Microsoft did ground work in that space for ~2 decades by now. It's called TPM and has a bunch of advantages by being a discrete component. It's also an industry-wide initiative and open to all.
> end-to-end iMessage encryption
Perfect for locking down the ecosystem.
> tough stance they publicly took against FBI
Posturing (on both sides: The FBI knows that they're SoL on getting such favors, with or without writing whiny op-eds on how they're incompetent).
You'd have already seen leaked versions of the "special OS versions to crack" had the other vendors budged to such demands. They might just discuss matters with the Feds without inviting the press.
Qt for mobile devices requires the use of QML (not C++ widgets) and many APIs aren't wrapped, or even fit into the OS application lifecycle.
It is easier to use standard C++ and do your own bindings to Java and Objective-C, than QML (one version for each device) + Qt/C++ + wrappers into not support APIs.
Xamarin teams take the effort to create .NET bindings for all new iOS and Android APIs, on each OS release.
Hint, the overall experience isn't like on the desktop.
(Juce, a C++ ui framework, has also been a contender, and to a degree Lispworks, possibly others, but these are the ones I'm a bit familiar).
I do and the same with a few other big company technologies and frameworks. It's not so much the support but more the fact that in the past a single person / small team could make a technology that became a staple of the industry. I always liked that it was one of the few things left that big corporations didn't have a strangle hold upon. Now however it seems that it is no longer the case and all the new frameworks, libraries and other such things are coming out of the big corporations - I guess I just enjoyed supporting the little guys.
But the platform the other tools that the GP is talking about would probably run on an OS, of which I don't think there are many which are written and maintained by small independent teams of a few developers.
Still, I was just pointing out that there are still areas that the major player is an independent developer without any backing. I'd bet that with the ease of publishing in something like NPM it's easier than ever for someone to make a good piece of software and become a dominating force in a niche area than ever before.
I would imagine they would've been happy with staying alone rather than being managed by a boss, but sadly no one bothers to donate to most projects.
I'm not talking about your average software developer, but large companies that save hundreds of man hours that would've gone into creating and maintaining the projects they use.
How's TypeScript working out?
Why?
> I think Google is overall a pretty "evil" (I use quotes because the term is loaded, and the reasoning is too long to easily state) company.
I disagree, but even if I didn't why would that make me guilty about using libre technology from them?
But if it was Polymer with native iOS/Android support, now then this would've been a different story! When I compare all the recent front-end frameworks, Polymer still is the most appealing to me, I wish it had a bit more steam behind it.
Polymer is a thin layer of sugar on top of the web platform, it's 100% web, it doesn't make sense outside of the browser because it doesn't have its own special component model, it literally just directly subclasses HTMLElement to provide sugar, that's it.
FWIW, I was able to write two small but useful program in Dart in one day, without any experience with the language at all:
- A script to convert CSV file to SELECT ... UNION ALL SELECT ... statements
- A script to parse my timesheet (in Emacs' org-mode) & insert it into my client's timesheet database
I just used these 3 resources:
[1] Dart language tour https://www.dartlang.org/guides/language
[2] Standard library introduction https://www.dartlang.org/guides/libraries
[3] Standard library reference (like JavaDocs) https://api.dartlang.org/stable/1.24.2/index.html
[4] And the pub package manager https://www.dartlang.org/tools/pub
I think you might like working with Dart. The entire ecosystem is standardized. And if you do Flutter stuff, Flutter is the only framework.
Learning the language isn't a big deal. You already know most of the syntax and its semantics are straightforward.
You can try doing some Hello World stuff over at DartPad:
As for not wanting to learn Dart, if you are currently developing mobile apps for one platform (say Android) and you want to port your apps to the other platform (say iOS) then unless you already know the languages and libraries used by that other platform (say Swift or Objective-C) then you already have to learn a new language. Wouldn't it be better to learn something like Dart that compiles natively on both platforms? Then you can just write one program. In particular, maintenance is much easier.
(disclaimer, I like Flutter so much I just joined the Flutter team)
Not to mention Elm.
It seems like one of the biggest ideas that flutter brings to the table is a different approach to component libraries. It makes sense that there is a need for this given that larger companies that invest in React tend to have their own tailored component library that people outside of those companies generally don't get to take advantage of. The startup costs to developing your own library of React components and their CSS/Native wrappers are high.
That being said, when I think of prebuilt component libraries (eg, bootstrap, swing) I generally think of components that are too familiar for users and a crutch for developers to allow them to quickly develop interface code where they may not be an expert. In a high quality app, I would expect widgets to follow the patterns that other apps on the platform follow. Won't this be difficult for a framework like Flutter which will have to re-create each of these native widgets (as apposed to React native where they are just wrapped in a JS layer)?
Regardless of these qualms, I'm excited to see more well funded frameworks enter this space because I'm sure that all users of frameworks in this space will benefit. I will be on the look out for more complex uses of this framework to see how people overcome these types of issues!
I'm kind of wondering what are the political fault lines inside Google around the Dart, Flutter and Android ecosystem.
If Kotlin gets adopted server side at Google as well (which is fairly likely considering Google is already using the JVM), then why would people bet on Dart ?
Is Dart 10x better than Kotlin ?
https://trends.google.com/trends/explore?q=%2Fm%2F0h52xr1,%2...
Interesting that there's heavy kotlin searching mainly in Russia
For many, it is. The consistency and the well-thought out API and syntax is a huge boost, and while they have similar roots, Dart is much better in these regards. Disclaimer: developed in Kotlin only for a few months, did a lot more in Dart.
I encourage you to try it and evaluate it for yourself. Your speculation about the politics in- or outside Google are just that: speculations, while a fair evaluation shows way more nuanced view of what is better and what has better chances in the long term.
Hang on, he's saying it's like Java Swing as if that's a good thing?
Unless you meant the Flutter runtime? It's about 6 MB apparently.
The entire Android OS, every part of it, including all toolings required to build apps, is still below 200MiB. This includes libraries, default apps, UI, compilers, tools, stdlib, firmware, etc.
My point is that if Electron was provided by default just like .NET or one of the apple frameworks you would not mind it that much and you will think apps built with it are lean when in fact to create a UI rich standalone executable you will require a lot of things to get up and running.
Not to mention that I rather do Swing than web development, if given the option.
I wish we had a variation of Deplhi's VCL for web/java/etc. instead of all these monstrosities that make life miserable instead of taking 5 minutes to make a solid UI.
It can be difficult to find the right place to insert your code to get what you want done, but that's the case with most UI toolkits. The easy stuff is easy and the custom stuff can be a real headache.
Same with Eclipse, which relies on native toolkit, vs. Swing.
But then if you compare Eclipse and IntelliJ - the difference is huge. Eclipse is clumsy, the widgets even though they are supposed to be native - somehow look baroque, oversized, while in IntelliJ/CLion things can be customized (Darcula+font settings) and look pretty sweet.
Same with Qt. With good stylesheet you can make an artist, a game scriptor, or level builder happy. They won't even care that you haven't used the native toolkit.
Then as it goes, it's more easier to expose/subclass/customize non-native toolkit compared to native, or even native which was wrapping internal widgets and exposing them other way. In a previous company I worked, we ported our game level editor (Radiant) from MFC -> Qt and saw burst of development going on, as people from all backgrounds were able to add more things in the UI. Collaboration was thriving, while with MFC you had to spent years learning how to do bits and pieces. Same with wxWidgets btw, as we also used in projects.
And at last, some rather specific story about wxWidgets on Windows - I think we had an editor, or a launcher of sorts, and it was tracking/showing log of operations. If you wanted to jump/search to a line it was rather slow, and limited... Turns out wxWidgets on Windows would use some native control, and the implementation of "give me the current line" in the editor would scan the log from begining to end, counting all \n\r, until it came to your buffer position and tell you the number. The GTK version, which someone else used for other tool did not had this problem... TL'DR'... Leaky Abstraction!
nuff' with ranting...
That sounds about right. I guess the conservative approach would be to wait and see if it gains any traction.
I think that's also why create-react-app is in the facebookincubator org.
This reminds me of a question I've had before: exactly what production apps does Google use Angular for? Have they rewritten Gmail to use Angular? Or Calendar? Or Docs? I'm too lazy to dig into the obfuscated source of any of these to figure it out for myself. Does anyone know what apps Google actually uses Angular for?
No Gmail, Calendar, Docs, or any other consumer app so far.
Disclaimer: I work on the Dart team.
One month ago a flutter member told me it was only used for internal apps at the moment.
I've never understood the obsession with creating a whole language around a library (R, Matlab, Magma, Javascript, Wolfram...) so that I'm essentially forced to use that.
Also as an addendum, C is a language designed around an operating system.
If it wasn't for UNIX's adoption, C would have been a footnote in the history of systems programming languages.
Also, C as a "portable assembler" kind of make sense as a lingua franka, because every language has to go through assembler before being executed at some point.
A programming language doesn't get adopted just for its grammar and semantics alone.
Regarding the benefits of C as portable Assembly, I advise you read about the programming languages and operating systems designed in the 60's, 10 years before UNIX was created.
(and fps is a pretty awful metric on mobile, what matters is the number of frame dropped)
Makes a lot of sense because reactive programming is inherently lazy. :)
Dart is a huge step up from JS, but I can see how other languages would be a nice fit too.
My second problem with Flutter is the writer's apparent biggest positive feature — Dart. (I love how he naively states that Dart was conceived as a language to transpile to Javascript; it was conceived as a replacement for Javascript with transpilation as a stopgap.) I think Javascript is a fine ("good enough") language that (a) works almost everywhere and (b) is evolving at a more-than-sufficient rate. I have no desire to drink Google's Kool-aid. (Go, OTOH, I am fine with.)
But then I get to "Building Layouts with Flutter":
https://flutter.io/tutorials/layout/#step-1
This makes the articles I've read on "thinking the React way" seem mild in comparison. In exchange for having to restrict your layout ideas to the stuff that will work in Flutter (which first entails somehow grokking what works in Flutter), you have to go from visual concept to hierarchical breakdown and then translate that into code in less than intuitive ways, and then when your graphic designer decides that such-and-such needs to be 2 pixels lower or the stars should get bigger in the middle, you're still going to be hosed or inserting fixed height shims all over the place (and how will that look on a tablet?)
This API seems too high level to produce polished products. Of course it's alpha so blah blah blah but being able to quickly produce generic stuff is not a proof of concept, especially if you can't then refine the generic stuff to the nth degree.
> This API seems too high level to produce polished products.
You can target whichever level of Flutter's APIs that you want. Almost the entire stack is in Dart, from the compositor, to the layout engine, to the animation logic, to the composition (widgets) layer, to the material widgets. If one layer is too high level, you can go down one level and work directly there instead.
The lowest level (the C++ layer) is literally just the Skia API, the Dart core APIs, a text rendering API, and a message-passing API for talking to your Java/Kotlin or ObjectiveC/Swift code. Everything else is layers you can directly poke at from Dart, written in Dart.
I guess my first objection (doesn't unify web development) stands, but that can be addressed in future (and presemably Dart will work just dandy with Web Assembly).
I assume my other objection can be addressed by simply building layouts directly and not using the autolayout stuff if you don't want.
One last comment about Dart. If you want to see the big benefit of Dart yourself, just go start up the sample Flutter app, modify it and do a (stateful) hot reload. Or introduce an error on purpose, and see how you can fix the error and then continue on from the same place in less than a second. The normal response I've seen from people who try this is to exclaim that this "is a game changer".
[disclaimer: I liked Flutter so much I recently joined that project]
How can you do that?
It will be interesting to see how it works in practice.
Looks like it's still not accessible https://github.com/flutter/flutter/issues/10562 The issue was brought up a year ago too https://groups.google.com/forum/m/#!topic/flutter-dev/xwUJ7D...
We're actively working on accessibility right now. It's one of our top priorities for the next few months.
This view amuses me. It is obviously held as an opinion, and isn't one I disagree with; but goes heavily against what everyone was aiming for with the likes of HTML. To the point that it is kind of hard to believe I'm seeing it.
I give it about 4 months before there is a UI language that is not "code" that is usable here. Pushed by the other side.
A lot of the struggle/difference between JS frameworks is this disagreement about where things fit on the document vs app scale, IMO.
And to an extent, this makes sense. However, ditching HTML and similar tech seems excessive to me. The largest problem with HTML is so many people try to appease the flow and native layout of the elements. This leads to a massive bloat of markup to create what is actually easy to describe using minimal markup and liberal usage of absolute/relative positioning.
I've never used any native widgets in React Native. Didn't even know they existed. I create and style all widgets I want from scratch so they obviously look the same on both Android and iOS. I thought that was how everyone did it. What am I missing?
> I create and style all widgets I want from scratch
This is what I hate about React Native. I don't like the custom boilerplate that goes into every new project. But NativeBase kind of solves this problems - to some extent. Using standard React Native components is like using raw HTML without a CSS framework
NativeBase is still not even close to be as good as the libraries we have on the web (ie, mdc, mdl...).
You can also integrate other native widgets not designed first and foremost for React Native https://facebook.github.io/react-native/docs/native-componen...
Most developers don't consider accessibility at all because they don't need it themselves. But there are millions of iOS and Android users who do need it, and they might be thankful that you've made their life easier with your app.
Following platform standards makes things easier for users. Users don't care if your app has distinct graphics.
https://github.com/facebook/react-native/blob/master/Librari...
if (color && Platform.OS === 'ios') {
textStyles.push({color: color});
} else if (color) {
buttonStyles.push({backgroundColor: color});
}
Generally speaking, UIButtons have important semantics that are easy to miss if one just reproduces the appearance using custom graphics. The same applies to other standard controls too.
That has been my experience at least, every time we changed something from "our" way to a more default platform way, we've seen better metrics and retention across the board. We even try to avoid platform specific things like swipe to delete etc., because the general user does not use those features, even if you "teach" them in the onboarding.
This doesn't mean that you shouldn't style your app etc to give it an identity, and there's actually a lot of room you have even when sticking to default elements.
As a user, I don't want your app to look different from all my other apps. Your app is not special enough (probably). Why go through he hassle of dealing with widgets that look and behave differently all the time, when you can just find a different app that doesn't do that?
Now, I'm not saying that everyone is going to be that irked by it... but it's definitely not an unpopular sentiment.
I don't think anyone will have a hard time understanding how to press a button just because it looks different than system default.
But for the most part, it's not about the difficulty. It's just an eyesore. Kinda like that one house in the neighborhood that has bright red fences, when everyone else has green. It might even be a very pretty bright red, but...
I'm going to be a bit pedantic with this one: this is valid to some extent. You might want to make small adjustments to accommodate for platform UX paradigms - slightly different icons, relying (or not) on the hardware back button, etc...
Most notably, touch targets seem smaller by default on iOS which makes ported designs then problematic on Android because all buttons are too small and hard to hit.
Or, will you end up with old looking interfaces and wait anxiously for someone to update the gui component library ?
Because except for creating its own ui paradigm, that will look different from both ios and android, i don't see another option.
As a plus we could consolidate all that brainpower spread across different cross platform native feature libraries to make these native features less buggy, more featureful and more maintained.
IPC is "inter-process communication". This message passing is same-process.
We haven't yet proved that it's sufficiently performant for extremely latency-sensitive work, and we currently copy the bytes for the messages when switching so it's not very suitable for high-bandwidth work like video where you're sharing the bytes between Dart and Java.