Great presentation. Also, really not surprising at all. Anyone that has tried getting a sample Flutter app running on a desktop will quickly find that it's shockingly easy and on almost all platforms will "just work" despite being in Alpha. The development experience in Flutter is great too. Anything that can help with that when developing for embedded systems is likely very tempting.
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?
Weston has better support for some things embedded developers care about, e.g. fallback codepaths for multi-plane buffer formats doing the blend in a shader, support for certain deprecated protocols (e.g. ivi-shell) and partial support for using hardware overlay planes for power-conscious compositing. It also doesn't have any of the Gnome dependencies. These are blanket statements; the devil is very often deep in the details.
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.)
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.
Does that mass-market consumer product have proper accessibility support, e.g. for blind users? If so, is that somehow implemented within the Flutter UI, or parallel to it (e.g. as a separate voice interface)?
I think the parent comment was talking about Nest Hubs / Google Homes, which are arguably voice first via the Google Assistant. I can only imagine but if I had, much more significant, vision issues then I think I'd use it even more.
I wouldn't say its shockingly easy to get a desktop app running. Its buried under a tag and sometimes doesn't compile on Windows. Unless something recently has changed.
sometimes you may need to recrate the "linux" folder - either by "flutter create ." or "rm -rf linux", "flutter create ." (same for other folders, like "web", "windows", etc.) - ideally there should not be code there that can't be auto-generated (but not always)
I also, independently, started writing an app in Flutter for fun (no experience in mobile/desktop GUI work, several years since I've worked in front-end web). I can give a list of pros/cons that probably overlaps what you've heard:
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.
Cons:
- 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.
Overall I'm very very happy with it. It was the kind of project where when I had time to work on it, after work, I had a list of things I wanted to do, and I could quickly check off feature after feature instead of fighting the system. That made me add more desired features, etc., but very enjoyable.
Some of the drawbacks I have noticed with flutter:
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.
I would add a few cons to the list (I agree with all the pros):
- 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.
I thought we'd agreed on hating parenthesis.
The example on Flutter's landing page shows 9 lines of square, rounded and curly braces with some sprinkled commas and semicolons.
Embedded doesn’t need wayland nor X.org. These two things implement desktop managers. Why would you run a desktop manager on a computer that runs one program only?
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.
> the demo seems to contain a launcher which allows to start multiple apps and switch between them.
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.
> it's not terribly complicated to pass exclusive access to display across processes.
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.
> You're just starting to re-invent the Wayland protocol
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
Totally agree with your view. "It only takes couple pages of code to get yourself a full-screen DRM-backed EGL context." - interesting, I've been wanting to get rid of the X server and use opengl or vulkan on a mali GPU fullscreen without needing X or wayland. do you have example code online somewhere for this?
I think as Flutter matures it will change the game for native development. I'm building an app now for a well known startup and are converting their native codebases to Flutter. What is interesting is that I was able to compile the app to web with no extra work and now use that as an easy way to demo things to my client. From a cross-platform perspective that changes the game for me along with being able to build desktop apps easily and relatively efficiently (compared to Electron).
"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 isn’t true and hasn’t been for a while. It’s nowhere near “web native” still but it is yet to even get a non beta release so I will give it some slack.
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.
One of the main bonuses of Flutter is also its underlying design - it really just needs a Canvas to render to and not much else. This makes it easy to port to other platforms (even web) and it allows you to have a very lightweight embedded system running a builtin app. This makes debugging easier as well, since you can just write the app on desktop, test in emulators and then deploy.
Our experience matches Sonys in that it works very well for embedded devices.
If Canvas means pixmap/bitmap (2D array of pixels) then unfortunately that's not enough in modern world.
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.
You're right but that is not how Flutter works. Flutter supports rendering using multiple client rendering APIs (OpenGL, Metal, Vulkan) and the embedder gets to pick one. Based on that decision, the embedder then has to handle WSI to provide the Flutter Engine a render target. In the case of OpenGL, it is a framebuffer object that passes all completeness checks. The engine will render directly to it. This way, the framebuffer backing stores are completely under the control of the embedder and the engine does not have to do unnecessary render to texture passes. The engine will never allocate an array of pixels in host memory when a GPU backend is selected. As you said, that would be slow and inefficient. We typically go to great lengths to minimize the device (and host) allocations and render target switches when rendering.
Disclosure: I am one of the authors of the Flutter Embedder API.
Flutter has a Skia-based backend with GPU acceleration. A bitmap/pixmap solution would be the worst-case scenario and probably only occur on an esoteric platform where GPU support is absent.
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
Couldn't agree more. For me Dart is basically a better version of js + java. Flutter is also the greatest GUI framework right now and their tooling is excellent. Every time i'm working on a flutter project i feel at home because i can be sure everything is gonna work out of the box. I only care about my code and nothing more.
Absolutely. Sound null safety is very exciting too! Using Dart/Flutter client side with sound null safety and then a few backend API's in Rust, would likely prove to be an extremely reliable system.
A perfect static type checker would distinguish between valid and invalid programs in all cases. In practice, static type checkers are conservative and occasionally reject valid programs. Gradual typing gives you a way out in these situations -- just like how macros in C can provide type-generic functionality.
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 took a gamble selecting Flutter overreact for an outsourced app. I basically didn’t know anything about either, but it landed on flutter because at sea developers that looked a lot more familiar to us.
I’m delighted that people who seem to know what they’re talking about also continue to like it.
It's unfortunate that the web mode uses a canvas and won't work with native browser accessibility stuff. That was the show stopper for me last time I've tried 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.
How about stuff like being able to select text in the UI? I tried a couple apps in https://gallery.flutter.dev/#/ and none of the text was selectable like in web and desktop interfaces
Flutter's Text widget (which is generally the default for most devs when displaying text) doesn't allow for text selection. There's a SelectableText widget that does, though:
While Flutter makes text selection an explicit choice for developers, Text vs SelectableText, for some reason Text ended up being most used. This is likely because SelectableText came after Text and because of Flutter's mobile background. Most mobile apps use non-selectable text, and so this ended up on Flutter developers' default path.
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.
Huh I never noticed that with gmail. I'm guessing it's because if I wanted to copy some sort of text, you could do it with the email detail page. And most text is selectable there, from the email name, actual emails, document content, etc. In mobile devices, text selection is such a pain so the desire to do it is less.
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.
Proper links and mapping of navigation to browser history are also important for any content-focused webapp. Keyboard navigation is incomplete too (some elements like dropdowns).
I hear you. There's a link widget coming, multiple browser history models (we've only supported URL fragments, but are adding pushState, and custom URL strategies, as well as navigation API improvements). Keyboard navigation is being actively improved. Bug reports are always welcome: https://github.com/flutter/flutter/issues/new/choose
That has been worked on, they do use proper tags instead of a canvas so accessibility now works fine. The next issue is performance / scroll jank though and that will be tough to solve since the rendering model is very different from the web.
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.
Do give `--dart-define=FLUTTER_WEB_USE_SKIA=true` a try (`flutter run` and `flutter build` take this option, which we hopefully will rename to something more reasonable soon). If that doesn't perform well, please file an issue: https://github.com/flutter/flutter/issues/new/choose
I'll be the contrarian: Is this a good business decision?
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.
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.
AOT maybe slower in certain cases. This topic discusses it - https://github.com/dart-lang/sdk/issues/39367 (it's not relevant only to dart, but other languages/runtimes like it too)
Sony offer solutions and experience. They have lots of experience doing that. I am sure changing the technology behind their solution will not be a problem as users don't see it at all.
This is just a single engineer from a company that not only makes TVs, console, but tons of other electronic (and possibly non-electronic) equipment. Inside every company, even inside every project, and every team in a any company there might be competing ideas, research and whatnot.
For example we use anywhere from good ole MFC, wxWidgets, WPF, Qt, imgui, Telerik and who knows what else...
Somewhat of an aside, since this article is about Flutter on embedded systems where React Native isn't even a consideration but...
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.
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.
- Flutter has built-in hot reload that enables fast iterations when designing an app. When you need to reset state though you have to reload the app which takes some time but it's not horribly slow.
- 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.
- React native has fast refresh as well, and they recently (4-6 months ago) rebuilt it to be much faster and more stable
- 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.
> - Flutter has built-in hot reload that enables fast iterations when designing an app. When you need to reset state though you have to reload the app which takes some time but it's not horribly slow.
Just like Common Lisp and Smalltalk, and now being added to WPF/WinUI, SwiftUI, Jetpack Compose,....
You do not have to use Android Studio. Use it with Visual Studio code or your FOSS variant of it with the Flutter plugin. That works really well.
> 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?
I've been following Dart since it's first release in 2012. I was able to be productive with right away back then. The JavaScript community freaked out because some Google exec in an email said Dart was a JavaScript killer. That did a lot of damage to it's acceptance. Dart was written with 2 things in mind afaik: 1) Replace Java based Google Web Kit used to write JavaScript (GMail circa mid 2000's) and 2) to serve as a backup language in Google lost the Java lawsuit with Oracle. Dart wasn't designed to be a shiny new thing like Swift, Rust or Kotlin, but more of a working language for day to day needs at Google. By those measures, Dart has succeeded admirably with Flutter taking off in popularity. Dart drew a lot of inspiration from C#, so I don't understand that complaint. C#, TypeScript and Dart are similar languages. Finally, Flutter/Dart should be compared to Blazor/C# and I think by that comparison, Flutter wins hands down.
I really like C# and .Net for getting the job done but Balzor runs Mono .Net in Wasm and the startup time is brutal for the public internet. 2 to 3 seconds. This leads me to believe Blazor is targeted at corporate intranets on high speed networks where you have a ready supply of C# programmers
I developed a fairly complex site using Blazor, starting back in the earliest releases. It was easy to deveolp for and having the depth of .Net (more and more features became available each release) was nice. I also found the build size to be an issue and wouldn't suggest using it for general purpose website. Microsoft really needs to focus on reducing the binary sizes.
ReveryUI seems like a nice project that works similarly to flutter, unfortunately they aren't sponsored by a giant company, but I would love to use reasonml/ocaml instead of dart (which is in no way a bad language, I just prefer to code in functional languages) to write apps.
Please don't hesitate to file bugs on any performance issues you see. We care very much about getting excellent performance. There are some specific hardware configurations that we are aware don't behave as well as we'd like (though nothing as bad as you're describing), but that's usually limited to pretty low-end phones where honestly even the OEM software doesn't perform that well...
Issues with/dislike of Dart is a pretty common refrain. This project is still very early days but the intent is to bring Flutter into Typescript https://github.com/chgibb/hydro-sdk
Eventually I hope to bring Flutter to C#, Haxe, and (maybe stretching it) eventually Kotlin, Java and Scala.
I genuinely don’t get the Dart hate, especially when TypeScript is the alternative. They are so similar.
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
"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.
Thanks for the link! I actually haven't seen that project before.
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.
Very typical for debug builds though. It's really surprising how big the difference is! Especially on slow hardware. The last app I tested went from almost unusable sluggish to buttery smooth when changing from debug to profile/release mode.
Flutter is just for people who need to get something basic done without too much trouble, I think. It's been over a decade of mobile UI iteration and we still don't have something that does everything for all OSes in a declarative way, so I think we are just doomed to writing a native app for each platform if you want performance, correctness in terms of UI, and productivity.
And on the other side there is Ionic which is has no real performance issues (contrary to flutter), has the biggest ecosystem (the web) and is elegant, expressive, simple ->
The thousands of powerful web APIs, Angular and typescript
> The toolkit and Android Studio run horribly slow
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.
100% my experience. Everything feels backwards. Dart is huge turn off, there are too many widgets, non native views, horrible native view support. Flutter devs brag about how fast their apps are but honestly I have yet to find Flutter app which isn't sluggish
Can you point to some really well done, larger Flutter apps in production? Especially ones that run across multiple platforms but feel good in each?
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.
Took me a while to get on board with Flutter, only really started enjoying it after I gave it a few goes. Coming to Dart after Swift and Kotlin feels like a big downgrade but languages aren't that important, as you said the whole environment is so much more streamlined than Android dev. I'm using it for Android only however and keeping my existing iOS app in Swift.
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.
Ah my comment wasn’t that clear. What I meant was as nice as flutter is dart felt like a downgrade after working with kotlin and swift (both of which I like a lot)
I didn't like Flutter because I don't like deeply nested code, especially when you have to care about parentheses, braces, brackets and commas, and the standard indentation is only 2 spaces.
Currently working on a product in Flutter. I can tell you, it is extremely productive and easily learned when compared to React Native for mobile applications (when you consider programmers who don't already have React web experience). For your typical computer science student it just makes more sense than Javascript (web-based) GUI systems.
When you think about it, the way the Web does GUIs is pretty ass backward.
I really enjoyed writing flutter code when I played with it. Google seems to be backing it strongly and they have lots of great learning videos.
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.
Flutter is awesome! I truly believe it is a game changer for startups pushing an MVP as fast as possible.
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
The state management is THE headache of Flutter IMO. There are many options now and I expect Google is following this development closely. Sooner or later they'll either endorse a solution or come up with something better.
They have endorsed solutions, but as it's still quite new it's a moving target. Originally they pushed for BLoCs, and now I think Provider is the preferred state management solution. There will probably be another one soon. At the end of the day they all work, but with different pros and cons.
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.
What is the advantage of this over the more popular embedded solution which is AFAICT Qt? It was quickly glossed over in the slides without any explanation.
We need source for that GTK+ example used to imply GTK+ is broken on Wayland.
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.
I love this - Flutter seems like the ideal (for embedded UIs, like automobiles and household appliances). The rich UI capability of a web-based platform without running an actual browser. As far as I can tell, the only major dependency is Dart.
So far I've only been able to find Flutter on Linux with ARM cpus as an initial proof of concept project someone did specifically on a raspberry pi. Is there now an official path for full Linux flutter support on ARM? I'm learning Flutter now and would love to start writing some useful apps for my Pinephone and Pinebook.
On an x86 Linux desktop, Flutter apps can run pretty well and very fast. I hope that holds true on embedded/mobile.
Honestly I don't get the appeal of Dart/Flutter for this use case for two major reasons:
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).
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.
Embedded devices which have a UI are by now normally so fast that garbage-collection doesn't matter at all. Similar you tend to not need to turn the GC at all for writing UI applications like that, the defaults are just good enough. Lastly while dart can be dynamically typed (EDIT: it's opt-in dynamic typing instead of opt-in static typing) it's typed statically "good enough". I love static typing (e.g. rust, scala) but in difference to type script I haven't run into any major gotchas when using dart. It feels very Java-ish just without the bad parts of java tbh.
An important distinction is Embedded and Real-time. Embedded is the all-encompassing tent, while Real-time is a subset thereof.
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.
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.
Yep. Last week I had the joy of checking the infotainment system of my friend’s new car, for which Renault thought it was a good idea to use this Android fork or whatever, with a touchscreen interface of course. It was comically bad! The latency, the framerate, the whole user experience was utter crap. If they had literally glued a 2G iPhone from 2007 to the dashboard it would have been better than this embedded Android GUI. And I refuse to believe that the hardware in a 2020 executive car is less performant than a phone from 13 years ago, so the culprit has to be the software...
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.
I program complex color displays, wifi on devices with 1GHz clock. Still on batteries; still slow and speed/latency matter. A lot. Embedded is always the smallest device possible for the application. Else the designer made a mistake. So its always critical speed/space.
> And embedded is usually dog slow processor running at minimum clock, to save power.
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)
Yes I mean I just did some quick price research and I (as a private person) can buy a Quad core Cortex-A53 for just 5.20$... And a Raspbery PI Zero (no WLAN) for 12€.
"Embedded" means different things to different people.
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.
Sure it does. But if its possible to choose a cheaper hardware chipset and not do GC then that's likely the correct choice. Or the designer has made a mistake (BOM cost higher than it needs to be).
Is it always a mistake for the BOM cost to be higher than it hypothetically could be? Can't a designer reasonably trade off some BOM cost for other things such as development cost?
Lua is not uncommon on embedded devices, even the slow industrial kind, as opposed to "embedded" devices with desktop- and server-class processors.
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.
I would have thought embedded generally meant a bit more streamlined than running Dart as well. Something like https://lvgl.io (which I just heard about yesterday, thanks HN!)
Not sure why they are even still using Wayland; if all you want to do is display a full-screen EGL surface, you are better off just talking to libEGL and the kernel atomic DRM yourself.
"Flutter is committed to supporting developers in making their apps more accessible, and includes first-class framework support for accessibility in addition to that provided by the underlying operating system, including:
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"
Flutter looks great, and I seriously considered it for my next project. In the end I decided the possibility of Google getting bored and ending support was enough to tip me to using Qt Quick instead - even though I kinda dislike Qt and js, and will have to pay for it.
The way I read it, it looks like OP is saying that in case Google pulls out, then it will likely not continue.
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.
So for some reason they can't just use Android as the base OS /Display Manager and use Flutter for Android so now they have to use X11 or Wayland? They may have their reasons but I skimmed over the PDF and it doesn't address why.
Bringing up Android on a platform is significantly harder than booting up a thin Linux distribution. Android is also a rather fat cow.
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.
I think for extremely limited capability embedded devices it makes sense to have Linux kernel + Wayland - but anything modernly new Android will do fine. Honda uses it in their in-dash entertainment systems for example.
What do you gain with Android on a small device (that's not a computer screen like a head unit) though? You just add a significant maintenance burden because you need to tear out all the phone parts from the OS which make updating and patching it really hard.
There's a reason it doesn't use the standard Linux stack: the standard Linux stack is a garbage fire. Throwing away the userspace of Linux Desktop and replacing it is what allowed Android to thrive.
Android pre-dates Wayland by a while, so from my understanding, if Android has a solution before, why would it need to migrate to Wayland? Also mobile use-cases and concerns are fairly different from desktop.
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?