Graphical User Interface Using Flutter in Embedded Systems [pdf]
static.sched.com
static.sched.com
I am curious why they went with Weston as their Wayland compositor as opposed to Mutter, if only because it seems to be the most popular due to Gnome. I'm not familiar enough with the trade-offs between the two. Anyone care to theorize why?
Depending on the OEM you work for and how vertically integrated your organization is, you may also have a large and complex supply chain catering towards your products, with complicated RASIC matrices for who supplies you want and vendors held to KPIs for their BSP and their hardware. Due to various factors Weston may be what they already have patches in hand for, e.g. for proprietary buffer integration, etc.
(I work on KDE Plasma, including its Wayland support, and am a system architect for a large automotive OEM making Wayland-based infotainment systems, neither of which use Weston however.)
flutter channel dev
flutter upgrade
flutter config --enable-linux-desktop
Unsurprising because it's not the first time Sony bet on an unusual language (https://news.ycombinator.com/item?id=1938652) and people on HN were similarly excited. Days later the initiative was put on hold and the domain doesn't even resolve today. I think it's safe to say that their initiative did not end up as a huge success.
Surprising because according to their own presentation they want to use an alpha version technology created by a company which is known to be cancelling projects on a whim and which is not really using said technology for anything important.
A decade later one things remains clear: you can count on HNers to jump on any obscure programming language and praise it to the skies.
Pros:
- The toolkit feels fairly mature and not too hard to parse. I think there's a lot of "this class works with defaults and breaks otherwise" feeling, though the core components are robust enough that this isn't a huge concern.
- It was super easy to build for Android, iOS, and Mac all at the same time. Everything Just Worked (so far).
- It was very performant
- Very easy to add your own painting code if you wanted a custom component.
- The debug view is so so useful for figuring out painting and layout issues.
- I didn't understand Futures very well (and honestly still don't); this might be an issue with people working with modern Python/JavaScript/whatever.
- Because of the above, interacting with a database / JSON on disk felt a little contrived. In particular JSON parsing felt very non-obvious, even though it feels like at this point is should be a first-class feature.
- It still produced relatively fat binaries, though not sure how much of that was debug/release mode.
- My computer ran hot while running Flutter, though not sure how much of that is debug/release mode.
- Testing can still be improved in my opinion, there's no mutation testing yet and it's still pretty verbose. If you are coming from the JS world, that's clearly superior, if you are coming from the Ruby world however, you will be disappointed a little bit on that level.
- I really don't like the navigation system, it's pretty hard to know the current route and you have to go out of your way if you need to interact with the current route dynamically.
- Webviews are kind-of alpha, which means no tab support, that's a killer for any kind of oauth using webviews.
Debug mode is easily 5-10x slower/more resource-intensive than release on devices I've tested on.
1. One of the biggest problems with flutter is the IDE integration for the design aspects. In my opinion, the development experience is much worse than Xamarin, .NET/Mono, Delphi, Lazarus etc.
2. The documentation is not very good and can be quite out of date.
3. The components are mostly all UI/layout related. There aren't good components for DB integration etc.
4. I have noticed is that between version upgrades of flutter, there can be multiple problems - but this is not surprising that flutter is still quite new.
"everything is a widget"
For embedded, drm/kms is IMO better level of abstraction to base on. It only takes couple pages of code to get yourself a full-screen DRM-backed EGL context. I did it a few times for various Linuxes using Broadcom and Mali GPUs.
I’ve evaluated Flutter couple years back, chose not to. I picked NanoVG (later on I’ve patched it a bit improving fonts https://github.com/Const-me/nanovg ), compiled a shared library, consumed from .NET Core, and implemented a GUI in C#, with animated transitions and such. Both me and my client were happy with the outcome.
Here’s why I was reluctant to choose Flutter.
1. New programming language with Flutter being the only use case. The language looks nice by itself. However, this means no library ecosystem, and non-trivial chances to waste lots of time working around bugs in language, compiler and runtime.
2. I don’t like Skia underneath, too much legacy and overall CPU-centric design. Marketing materials tells how they using GL and Vulkan for performance. Source code tells opposite story, they’re doing a lot of graphics on CPU. Unless the stuff is already implemented by some knowledgeable people outside ad. tech, e.g. MS Direct2D or nVidia’s NV_path_rendering. To be fair, Skia appears to be able to consume either of them, but none was available for my Linux target.
It depends. In this particular case, the demo seems to contain a launcher which allows to start multiple apps and switch between them. A window manager sounds preferable in this case.
Also, Flutter handles all of the Wayland/X11 implementation details. In this case it's less work to just use the already-existing backend.
If the count of apps is small, and all of them are written by you, it's not terribly complicated to pass exclusive access to display across processes.
Only becomes too complicated if you want many apps updating their windows at the same time, or support third-party apps.
> it's less work to just use the already-existing backend.
Short term, yes. Short term, a desktop OS and Electron is even less work.
Long term, desktop environments are huge, and you'll be dealing with long tail of issues related to their features. Each time they break something, you might need to pay hundreds of dollars just to ship the equipment to you for repairs and back.
When a desktop environment is physically missing from the system, along with all related GUI software, services, and libraries, it leaves much less things to break. Users can connect a USB/BT keyboard or mouse, no one gonna handle the events. They can do rude multitouch gestures on the touch screen, nothing unexpected gonna happen either.
You're just starting to re-invent the Wayland protocol. You need to pass input too… and more of Wayland re-invented.
>desktop environments are huge
Weston or Cage doesn't really qualify as huge.
Also, I think you underestimate the work to write a program using KMS and libinput. It's pretty easy to write a toy app, but writing a solid framework is something else.
I think the main feature of WL is simultaneous multi-tasking. If you don't need that, a desktop is redundant. That's why Google made their own proprietary DM for android instead of adapting what Linux had.
> You need to pass input too
I haven't tried but I think multiple processes are fine reading from the same /dev/input/event[n] at the same time, they'll just get the same events. Therefore they may process or ignore these based on whether they rendering or not.
> I think you underestimate the work to write a program using KMS and libinput
I did it several times, both for hire and for lulz: https://github.com/Const-me/Vrmac/ drm/kms pieces are in C++ and not in that repo, but raw input is there, was easy: https://github.com/Const-me/Vrmac/tree/master/Vrmac/Input/Li...
> writing a solid framework is something else
Depends on the scope. If you only need left to right languages, couple keyboard layouts out of the 204, etc., it's reasonable.
"Warning: While in development, web support is available in the beta channel"
What is your experience? Is it OK to use this is in production app. Right now I need a web and desktop app and curious to know if Flutter can be used. But I see the Flutter web is beta quality and Flutter desktop is alpha quality as of now
That alone should kill it for most production use unless it's an internal tool.
("should" because many apps sadly just don't care)
edit: I was wrong, see below. Glad to be wrong actually, because Flutter is great.
But I think Flutter is probably the best hope out there right now for the ever elusive dream of write once and run anywhere with native performance.
And just like Delphi, it will suffer that although Dart is a general purpose language, its only reason for existence will be Flutter applications.
Our experience matches Sonys in that it works very well for embedded devices.
On high-dpi monitors you must use GPU to offload rasterization of drawing primitives from CPU to GPU. Otherwise the only job your will do is drawing at 100% load - say "hi" to batteries and other apps on the desktop.
That's why I am supporting in Sciter as plain pixmap targets as GPU based ones: Direct2D/DirectX, Skia/OpenGL/Vulkan + the ones used by OS -CoreGraphics and Cairo.
Disclosure: I am one of the authors of the Flutter Embedder API.
It's the best parts of C# plus real dynamics. The Flutter ecosystem is already above and ahead of React Native , a big part of it is it doesn't have the baggage of npm, Babel and JavaScript.
For a friend's side project I've been using Flutter Web and I couldn't be happier with it
We actually use plain standard HTML and ARIA attributes for accessibility. If you don't see them, try enabling a screen reader (e.g. TalkBack on Android, VoiceOver on iOS/macOS), then you'll be able to enable accessibility in the app. If you are having problems with a11y, please file a github issue. A11y is very important to us.
https://api.flutter.dev/flutter/material/SelectableText-clas...
I personally expect this trend to continue, as in most desktop native apps text is not selectable either. In fact, in many web apps (those that are really _apps_, not just static web-sites) there's lots on non-selectable text. Case in point, I just checked Gmail's landing screen, and I failed to find a single piece of selectable text.
Does selectable text have a performance penalty? In iOS UILabel is far faster to render than UITextView, but only UITextView is selectable. I wouldn't mind if many of my UILabels were selectable, but I'm forced by performance constraints to not let it happen.
Maybe put forward making SelectableText the default and renamed to Text and Text is renamed to UnselectableText and becomes the non default if there isn't a perf penalty? It would need an automatic migrator for that to happen although.
For example, pressing "f" with Vimium should enumerate things that can be clicked(think anchor elements and button elements) but it enumerates nothing on https://gallery.flutter.dev/#/. This is a pretty good proxy for accessibility too i.e. things that can be clicked look like they can be to the machine. A quick document.querySelectorAll('a') and document.querySelectorAll('button') in the console verifies that there are no such elements.
Another one, basic browser features like backswipe on the trackpad to go back just doens't work.
Custom user agent stylesheets is another accessibility/power user feature that will not work
You cannot select any text as far as I can tell
Reader mode doesn’t work, not even on the news demo which is a prime example of where it should work
You cannot copy or preview link URLs
You cannot copy image URLs
Navigating by landmarks(such as headings) probably also doesn’t work(I haven’t tried this yet)
Vimium is an interesting use-case. I've never heard of this extension. We have in the past enabled accessibility DOM all the time, but due to performance concerns changed it to be opt-in. If you use the standard screen reader (e.g. VoiceOver on iOS/macOS, TalkBack on Android, etc) you will get a way to enable accessibility DOM with ARIA tags, etc. Perhaps we should reconsider it (may need to optimize it a little though). I'd be curious whether Vimium works when accessibility is enabled.
Some features you list we either should support or already do: backswipe (good feature request), text selection (use the SelectableText widget), links (in the works), image URLs (good feature request). Not sure what navigating by landmarks is, but perhaps something we could support too.
Stylesheets are a non-goal. We do allow embedding plain HTML/CSS (called "platform view"), where you can use CSS, but Flutter's own widget system uses its own styling/theming.
Reader mode makes sense for "documents" (think news sites, wiki, documentation, etc), but it's unlikely to work out of the box in dynamic apps (think email, calendar, maps, graphics editor, etc) which is the kind of apps Flutter is going for. There's a similar issue with Ctrl + F (Cmd + F) to find text on page, which is not helpful in dynamic apps. Dynamic apps are better off implementing their own app-specific "reader mode" and "search bar", one that takes the nuances of the app into account. But never say never, maybe that's doable too, perhaps using our accessibility tree, at least for static document use-cases.
I am strongly in favor of static, coming from C.
Also worth noting that Dart now also includes fully sound null safety https://dart.dev/null-safety
A sufficiently rich type system (with tuples, union types, traits, generics, higher-kinded types, etc) can lessen the need for a dynamic escape hatch. In the end though, the occasional use of dynamic typing can be easier to reason about.
I’m delighted that people who seem to know what they’re talking about also continue to like it.
Sony has recently stated that it wants to enter the automotive industry but Google is a direct competitor with Waymo and their Nest product has a pretty firm standing in the smart home appliance environment. Is it wise to basically become dependent on a large competitor for such an integral component of your next generation products? What if Google decides to give up maintenance of Flutter to the community and use an internal, better fork? I guess it's the same thing with Microsoft using Chromium to implement Edge and how we're converging towards a complete Google monopoly.
I was an early adopter and proponent of Flutter but that's just not the case anymore. The ecosystem has become inundated by what you might get if you forced copulation between the JS and Android ecosystems. There's a ton of low-substance spam articles, excessive usage of libraries reminiscent of NPM-madness, and just a general obnoxious colorful-emoji-fueled atmosphere. I don't want to be misinterpreted: there are plenty of good Flutter developers and the core engineering team is certainly brilliant. But they're largely overshadowed by a community who continues to drive a good technology into being associated with bloat, poor security, and puerility.
Is this a good business decision?
The slide deck could have just said "We don't want to pay $10/unit for a Qt license" and saved us all the time. If you have half a gig of SDRAM and a playstation-class CPU, awesome. A lot of us don't.
What if Google decides to give up maintenance of Flutter to the community and use an internal, better fork?
I will never touch another Google-generated embedded project again. You will get burned. Just don't do it.
Qt has it's share of problems too. And someone is free to decide against depending on an oracle-like company.
> If you have half a gig of SDRAM and a playstation-class CPU, awesome.
Flutter is AOT compiled in release mode and is pretty efficient.
For example we use anywhere from good ole MFC, wxWidgets, WPF, Qt, imgui, Telerik and who knows what else...
React Native works on Sony PS4 using youi.tv: https://www.youi.tv/build-for-ps4-using-react-native-and-you...
React Native works on Ubuntu: https://github.com/CanonicalLtd/react-native
React Native works on Linux via Electron https://dev.to/evanbacon/making-desktop-apps-with-electron-r...
Not strictly speaking aimed at embedded systems but you'd think React Native would deserve at least a consideration?
I've used both Flutter and React Native. Hands down, Flutter is the more enjoyable experience. Everything from the language, to the toolkit, to the IDE, to the final product, is just BETTER.
React Native is a bloated, hacky, slow, garbage pile by comparison.
1. Value types
2. Tuples
3. Key paths
4. Checked exceptions (could be more powerful in Swift, but they are there, and when not used in excess they are actually pretty nice, and Swift's `try` syntax is excellent)
5. Swift's enums and `switch` feel both more straightforward and more powerful than Kotlin's sealed classes and `when` (I'm not sure about this, but I think there are situations where you get better coverage checking with Swift's pattern matching.)
6. Reified generics (I know that opinions on this vary, and it doesn't often matter, but I've been just writing some code where it's been nice to be slightly more type safe with Any values)
7. More principled null handling (Optional is just an enum, although with some extra syntactic support)
8. `if let`, `if case`, `guard let` and `guard case` allow for simpler handling of multiple values than Kotlin's `?.let` and null checks
I like Kotlin being more expression oriented, but in the end I often find my Swift code to be less contorted due to the more powerful conditional constructs. GC vs ARC isn't much of an issue, both work for me.
I see so many rave reviews.
But I personally tried it and strongly disliked it. The toolkit and Android Studio run horribly slow - like really slow. And the output is basically this generation's flash. Some of the samples I tried on their gallery are mediocre. Very slight, but noticeable sluggishness. Some are just terrible; the 2d transformations moves at like 7fps. Plus there are so many other small things like issues with scrollbars, things that take time to sort out that native and web have had time to figure out. Also dart is a real PITA coming from typescripts which is basically c#.
Actually, the issue with dart is it's own whole thing. It was meant to be an alternative to js, but not ts has taken over with much greater success. I am not talking about aot or stuff like that - just the dev experience for app dev. Now it's in this really weird spot.
I just don't know. I would honestly have thought that flutter is dead in the water - every personal experience I've had with it has been bad, there are objective facts about it that are bad, and yet so many people love it.
I'd be interested to hear your experience about why that is.
https://github.com/dotnet/designs/blob/main/accepted/2020/fo...
- The performance of production builds is really good, better than any other cross-platform solution including web apps, PWAs, react native. I've got flutter apps running great on my cheap, old (circa 2015) phone with android 6.0. That's also a huge benefit of flutter, it can target older phones because it doesn't have many dependencies on native widgets etc, it just need a canvas to render.
- Dart not being a successful alternative to js(dart2js compiler), doesn't mean it's a bad language. In fact, Dart 2.0 was a serious update and the language now is great, with sane defaults and a nice standard library. I can't imagine any serious developer who knows at least one popular programming language like java,js,c# that would have problem with Dart. It's very easy to get used to it a couple of hours
> there are objective facts about it that are bad, and yet so many people love it.
can you elaborate more about those facts?
- The production builds of RN apps can be on par with fully native applications as well. Discord for iOS is entirely React Native and is probably the most performant app that I use on a daily basis.
Just like Common Lisp and Smalltalk, and now being added to WPF/WinUI, SwiftUI, Jetpack Compose,....
> Also dart is a real PITA coming from typescripts which is basically c#.
That's surprising to me. Coming from Ruby Dart was great. Not better, but when you are expecting a tuned up javascript Dart was such a nice surprise. I'd have expected it'd be the same for someone coming from C#. You worked with a current version and gave it a fair shot?
I'm in the Flutter is great camp. The UI you produce with it work great, and the whole process is great. Very powerful and at the same time manageable, a smart small concept at its core, with much around it that makes it powerful. Combine it with GetX and the code you get can also be really nice.
But for Linux? No way, not until they have got a proper beta that is not tied to snap. But maybe Sony is working on that and showing it here? Or I'm just not aware that this is not a real requirement, despite the website making it sound that way?
Eventually I hope to bring Flutter to C#, Haxe, and (maybe stretching it) eventually Kotlin, Java and Scala.
When I started to learn the language, it was being hyped as a viable alternative for Android apps (which has been abandoned since 2.10, IRCC).
Kotlin seems nice, but after getting used to a stronger type system, it's hard to go back.
Like this? https://pub.dev/packages/starflut
"A new flutter plugin project, which supports flutter to interact with other scripting languages such as python, java, ruby, golang, rust, etc. It is easy to use, supports android and ios platform."
Full warning, I have zero experience with this plugin and zero experience with Flutter.
As far as I can tell, starflut appears to offer basic script running with pass through of primitive types from Dart -> guest languages.
Hydro-SDK strives to offer far deeper integration between Dart -> guest languages up to and including extending from Dart classes in guest languages, and passing instances seamlessly back and forth with little overhead.
But this is exactly what happened to Angular. There is a TypeScript version (fairly popular) and a Dart version (barely used outside of Google but is used for some of their biggest money making projects like AdWords).
I’ve only recently discovered Dart having come from Ruby land for the last 8 years and I could easily see Dart becoming my new go-to language in the future.
I think it’s currently criminally underrated and sadly doesn’t have a huge amount of adoption outside of Flutter at the moment but I’m looking to build my next serious web backend with it.
If you’re looking for a good introduction as to why I think it’s such a good language this video does a decent job of explaining the benefits https://youtu.be/J5DQRPRBiFI
I'm doing everything Flutter related with vim + CLI, so one doesn't have to work with android studio, even did so when trying a native Windows build (out of interest) a bit ago.
> And the output is basically this generation's flash.
I did some flash quite a while ago, and no that does not compare at al, similar to that it is not like Java. The closed comparison is possible Qt, from a built output.
> Some of the samples I tried on their gallery are mediocre.
That's true, and I never understood why they don't improve that, it hurts their publicity.
> I would honestly have thought that flutter is dead in the water - every personal experience I've had with it has been bad, there are objective facts about it that are bad, and yet so many people love it.
I thought about roughly the same a year and a half ago, a coworker then did some small private stuff with it, and we talked here and then, as the base premise still sounded interesting. Comparing it now to then it just shows how much improved and gives a glimpse to what more will be possible, and I now could imagine that it will stay and even become rather useful.
tldr; It's IMO far from dead in the water, but there's also quite a bit of work to do.
I used to think the same of React Native a couple years ago but this year I picked it up again and was shocked how far its come - incredibly smooth experience, far better ecosystem, and it's hard (impossible?) to beat Chrome DevTools + VSCode. Runs fast, too.
The thing is, Flutter is a no-go for the web as of now, it delivers a huge bloated bundle that's not accessible or performant. But with React Native you can build an app that shares 90% of the code across all native platforms and the web, and feels/is more native on each of the three platforms.
When you think about it, the way the Web does GUIs is pretty ass backward.
If it ever gets a strong set of cross-platform libraries for doing things like file system access, it's going to be huge. But I'm not even sure that's possible with how locked down the mobile OSes are these days.
One codebase to build apps on iOS, Android and for the web (as soon as they improve the web one to the release version) is great, and Flutter is fun to use.
The drawback could be the many states of management... But that is not a deal breaker
Even if it's not the fotm, I'm very happy with BLoCs for global state and not shying away from using classic stateful widgets and forwarding data between screens where intermediate states are needed.
If there is something I learned from being a web dev for my entire life it's to not always jump on the latest bandwagon. It's cool when things move quickly, but you must be careful to not get motion sickness.
See: https://github.com/c-smile/sciter-js-sdk (screenshots are there too)
Some stats:
Binary size : 3.7 Mb (RPI version)
HTML: HTML5 level of markup language + "HTML Window" extensions, see: https://sciter.com/html-window/
CSS 2.1 + selected modules of CSS3, see: https://sciter.com/docs/content/css/cssmap.html
JavaScript: full ES6 specification + extras like built-in JSX, see: https://github.com/c-smile/quickjspp
Again, Sciter.JS uses time proven and well known technologies in a fraction of size.
Arm32
Does that mean open-sourcing Sciter is off the table for now?
[1] https://www.kickstarter.com/projects/c-smile/open-source-sci...
Let's put it this way: I am still looking for options.
I guess one is Dart is a safer language than C++.
It could very well be PEBKAC, client-side decorations make being coordinate system aware much more important. If your code assumes everything's in drawable coordinates, it'll work in a top-level window on X11, but may break when Wayland w/CSD shifts things.
That slide is potentially quite damaging to GTK+'s reputation, to not even provide a way for us to independently verify the results is frustrating.
How so?
On an x86 Linux desktop, Flutter apps can run pretty well and very fast. I hope that holds true on embedded/mobile.
1. Dart is garbage-collected; and
2. Dart has optional typing, which is to say it supports type hints but is essentially dynamically rather than statically typed.
This presentation claims low overhead so I'm open to be proven wrong here. I wonder how much of that (if true) is Flutter and how much is Wayland (over X). I'd really like to see some nontrivial apps in this, React Native, Qt, GTK and the like.
But GC isn't just about overhead (although that is a concern). It's about predictability of performance. It's about tuning the VM and the characteristics of STW GC pauses (if any).
Embedded includes things with GUIs, like fridges. We're not dealing with 128k of RAM. These can run basic GC'd apps just fine. Pauses really aren't any more of a concern than on desktop, or even less so.
I've never seen an embedded app with GC.
And embedded is usually dog slow processor running at minimum clock, to save power. So pauses are 10X or more the issue re: desktop.
It used to be like this for a long time, but nowadays the market is moving towards stronger embedded CPUs, either just because they are affordable (raspberry pi), or the power is actually wanted for something (e.g. nvidia jetson for video processing and AI)
It includes anything from thinks like (home) routers and TV set-top boxes to <8MHz 8bit processors.
Embedded devices which have a UI which is not just some simple segment display (e.g. touch screen) are today not seldomly comparable with low end smartphones and tend to not be battery based.
I mean think about how cheap a 1+GHz ARM chip has become today.
Independent of fancy algorithms, GC complexity, cost, and latency are straight-forward functions of the number of managed objects. It's not uncommon to use a "glue" language like Lua in a manner where the runtime only juggles a small number of objects, which in turn encapsulate and manage most of the application data independent of the garbage collector. Even in applications with complex, cyclic object graphs (i.e. the ones were GC makes sense), you can usually push the problematic edges into a small number of GC'd objects. Language GC (mark & sweep, reference counting, etc) can at least in principal provide a zero marginal cost benefit.
Java, JavaScript, and Python reflect poorly on the usability of GC because they're extremely object heavy and weren't designed with embedding in mind. Scalars and aggregates didn't figure prominently into their design, including C FFI (to the extent C FFI was even a consideration of their original language semantics). And they're too liberal with heap allocation in both their semantics and implementation, inducing unnecessary object churn.
Back when I was a game developer at EA, Madden and many other sports console games all shipped using Flash (!) interpreters with full GC. These were games running on PS2, NGC, XBox, etc.
LOL, this explains why every embedded GUI I encounter in these "smart" devices is awfully sluggish and a pain to use, delivering 5fps at most. Thx for the clarification!
One only has to pick the same app, implemented natively on comparable iPhone and Android hardware to see that the underlying language runtime, that’s NOT garbage collected, is the one with the buttery-smooth UI. With JS “native” or web whatever, it’s even more pronounced on the SAME hardware.
Dart has not been optionally typed since Dart 2 (released in 2018).
> 1. Dart is garbage-collected;
Yup. Most languages used for UI programming these days are. JS and C# are probably the biggest two. UI programming is at a really interesting intersection between two difficult constraints:
* Much of the work is subjective, exploratory, and frequently-changing. It's hard to evaluate whether a UI looks and feels right until you code it up and try it. When you do, you often realize you need to change things. Also, product people really like to "refresh" application UIs frequently so there's a ton of churn. All of this means that developer productivity is absolutely paramount. You need to be able to make small iterative changes quickly to evaluate them, and you need to be able to do sweeping re-writes efficiently. That means you want a high-level language and GC is a big part of that.
* At the same time, the program is real-time interactive software running on user hardware that you don't control. So just like games, execution performance and latency is critical. A slow language implementation can degrade the application's appeal in ways that materially affect its success.
Balancing those is hard. Fortunately, people have been hacking on GCs for decades and have gotten really good at them. The Dart VM's garbage collector has been designed from day one for soft-realtime interactive performance. It's generational with a very fast nursery allocator and collector, doesn't stop the world, and (I believe) can do a full collection in the background.
Also, the language itself was somewhat designed to be GC friendly. Unlike dynamically typed languages like JS, object shape doesn't change at runtime so an instance is only ever a single allocation.
> 2. Dart has optional typing, which is to say it supports type hints but is essentially dynamically rather than statically typed.
As my colleague mraleph said, this hasn't been true for a couple of years, though it tends to take a long time for knowledge about this to percolate through the world. Dart is now a typical statically-typed language very similar to C# and Scala.
> But GC isn't just about overhead (although that is a concern). It's about predictability of performance. It's about tuning the VM and the characteristics of STW GC pauses (if any).
Exactly right. The Dart VM was always intended for client-side applications, so it's designed around low latency performance.
This question is usually the end of my evaluation of most UI toolkits for serious professional work.
Large fonts
Render text widgets with user-specified font sizes
Screen readers
Communicate spoken feedback about UI contents
Sufficient contrast
Render widgets with colors that have sufficient contrast"
via
https://flutter.dev/docs/development/accessibility-and-local...
And I tend to agree with this. I can foresee an initial counter-push for the first year or so after google pulls out, but then the project will die its own death.
However, with Flutter specifically, I have a strong feeling that Google won't pull out. Esp given how Dart was kind of a big flop for years after the initial release, and Google still kept it around until Flutter came into existence, and then made a hard push to continue with Dart. At the moment, Dart is the best and most popular it has ever been.
Ad Words is what keeps Flutter alive.
It'll be interesting to see how much Wayland can remain lighter weight once it has accounted for all the "not working right" cases.
The Android version of this would be "Android Things" which would be perfect for this use-case (and some Googles own hardware is running Flutter on Android Things), but that platform has been completely discontinued. So booting up a thin Linux until you get a Flutter canvas just makes way more sense.
See e.g. https://qiangbo-workspace.oss-cn-shanghai.aliyuncs.com/2019-...
The implementation includes some interesting projects like Sommelier, a Wayland protocol proxy used as part of a setup to virtualize host resources safely: https://chromium.googlesource.com/chromiumos/platform2/+/HEA...
https://source.android.com/devices/graphics/surfaceflinger-w...
That's something I wish they'd replaced with Wayland these days for better affinity with the rest of Linux.
You might like GNU/Linux phones: Librem 5 and Pinephone.
Same reason Ubuntu dropped Mir - synergy.
Wayland is perfectly capable of handling mobile concerns.