[HN Gopher] Graphical User Interface Using Flutter in Embedded S...
___________________________________________________________________
Graphical User Interface Using Flutter in Embedded Systems [pdf]
Author : timsneath
Score : 260 points
Date : 2020-10-28 16:49 UTC (6 hours ago)
(HTM) web link (static.sched.com)
(TXT) w3m dump (static.sched.com)
| amelius wrote:
| But how hard is it to port Dart to a new architecture?
| marta_morena_28 wrote:
| Flutter, or in other words: Will Google abandon this product
| before or after my company managed to migrate to it?
| izacus wrote:
| 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.
| louiechristie wrote:
| I'm surprised React Native didn't get a mention on page 9?
|
| 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?
| ledak wrote:
| Also, the new Xbox store written in React Native:
| https://twitter.com/reactnativemsft/status/12903403919679569...
| phendrenad2 wrote:
| 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.
| hcal wrote:
| 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.
| mhoad wrote:
| There is indeed an official path for full linux support or at
| least in the sense that is outlined here
| https://medium.com/flutter/announcing-flutter-linux-alpha-wi...
| stefan_ wrote:
| 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.
| newbie578 wrote:
| 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
| haarts wrote:
| 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.
| anderspitman wrote:
| 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.
| rubicon33 wrote:
| 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.
| preommr wrote:
| I can't figure out flutter.
|
| 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.
| [deleted]
| ironmagma wrote:
| 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.
| The_rationalist wrote:
| 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
| acoard wrote:
| Ionic just wraps the web browser on mobile devices. So
| you still have to target two browsers, Safari and Chrome.
| ozyx wrote:
| Were you running debug or release builds? Your experience
| with sluggishness is very atypical.
| onli wrote:
| 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.
| alexandr1us wrote:
| 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
| r_police wrote:
| > The toolkit and Android Studio run horribly slow
|
| Stopped reading right there. That's how Android Studio always
| has been, but, more importantly why are you using it for
| Flutter development when VSCode was almost built solely for
| it, you could say.
| onli wrote:
| 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?
| yagodragon wrote:
| - 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.
|
| can you elaborate more about those facts?
| hokumguru wrote:
| - 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.
| chgibb wrote:
| 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.
| proverbialbunny wrote:
| >Eventually I hope to bring Flutter to C#, Haxe, and (maybe
| stretching it) eventually Kotlin, Java and Scala.
|
| 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.
| mhoad wrote:
| 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
| JD557 wrote:
| As a Scala dev, having flutter support would be awesome.
|
| 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.
| okareaman wrote:
| 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.
| ulucs wrote:
| If Flutter had a Bolero/F# analogue, that would be a very
| quick adoption reason for me
| thomasfortes wrote:
| 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.
|
| https://www.outrunlabs.com/revery/
| apta wrote:
| > and I think by that comparison, Flutter wins hands down.
|
| I'd be interested to hear your experience about why that
| is.
| okareaman wrote:
| 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
| tlamponi wrote:
| > 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.
| young_unixer wrote:
| 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.
| nwienert wrote:
| 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_.
| notsureaboutpg wrote:
| Any tips for getting into Flutter? I've been working with React
| Native for over 2 years straight now, and I'm hesitant to move
| on from an ecosystem I know really well and a toolkit that
| finally feels comfortable.
|
| But I also know React Native is hacky, slow, constantly has
| changes and breakages, sometimes stupid styling things are
| nearly impossible, etc. And if Flutter is as much better as
| people say, then I'd love to try it. Any plusses/minuses I
| should know before diving in?
| jamil7 wrote:
| 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.
| The_rationalist wrote:
| Off topic but regarding language design, what are some pros
| about swift that Kotlin hasn't?
| infinityplus1 wrote:
| I think he's probability talking about not wanting to
| rewrite existing apps which are working fine already in
| Swift.
| jamil7 wrote:
| 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)
| blinkingled wrote:
| 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.
| izacus wrote:
| 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.
| blinkingled wrote:
| 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.
| izacus wrote:
| 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.
| offtop5 wrote:
| Dart is easily my favorite programing language.
|
| 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
| yagodragon wrote:
| 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.
| jimbob45 wrote:
| Agreed. I've wondered why it hasn't caught on. Implicit
| interfaces for every declared class is a genius idea.
| haolez wrote:
| 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.
| realusername wrote:
| 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.
| yjbanov wrote:
| (disclaimer: I work on Flutter Web)
|
| 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.
| novok wrote:
| 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
| mixmastamyk wrote:
| Anyone know of a dart library for bittorrent? I've been looking
| for one but haven't found one yet.
| ZeroCool2u wrote:
| 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.
| manuelaljibes wrote:
| Not to mention that it's actually cross-platform, you don't
| have to deal with random quirks as shadow*/elevation in RN
| TheMagicHorsey wrote:
| 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.
| DerDangDerDang wrote:
| 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.
| beckler wrote:
| Well, Flutter is open source, so even if Google dropped support
| (extremely unlikely), it will likely continue on.
| skratlo wrote:
| It will likely not continue
| byeager wrote:
| Do you mean Google's support will likely not continue or
| that the project will not continue if Google pulls its
| support.
| filoleg wrote:
| 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.
| ludwigvan wrote:
| Corrected headline: An employee at Sony says Flutter and Wayland
| is the best practice in embedded systems using Linux.
| Const-me wrote:
| 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.
| emersion wrote:
| >Embedded doesn't need wayland nor X.org
|
| 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.
| nsm wrote:
| 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.
|
| I guess one is Dart is a safer language than C++.
| nsajko wrote:
| As-in-beer freedom.
| jeffbee wrote:
| "Embedded" system needs only four cores and half a gigabyte to
| run trivial demo app. Progress?
| slezyr wrote:
| Wow, I thought that was a joke.
| c-smile wrote:
| Just in case, I've published yesterday demo build of Sciter.JS
| that also has binaries for Raspberry Pi (ARM32).
|
| 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.
| monocasa wrote:
| > Raspberry Pi (AMD32)
|
| Arm32
| c-smile wrote:
| Yeah, fixed, thanks.
| alex_reg wrote:
| Sadly the recent Kickstarter [1] failed.
|
| Does that mean open-sourcing Sciter is off the table for now?
|
| [1] https://www.kickstarter.com/projects/c-smile/open-source-
| sci...
| moralsupply wrote:
| Sony knows that XORG is dead...
| shmerl wrote:
| Too bad Android diverged too far from the rest of the Linux world
| and isn't using Wayland.
| CraftThatBlock wrote:
| 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.
| shmerl wrote:
| _> If Android has a solution before, why would it need to
| migrate to Wayland?_
|
| Same reason Ubuntu dropped Mir - synergy.
|
| Wayland is perfectly capable of handling mobile concerns.
| mixmastamyk wrote:
| What is it using?
| shmerl wrote:
| Its own compositing stack. SurfaceFlinger:
|
| 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.
| fsflover wrote:
| > That's something I wish they'd replaced with Wayland
|
| You might like GNU/Linux phones: Librem 5 and Pinephone.
| izacus wrote:
| For Flutter it doesn't really matter because all it needs is a
| canvas to paint on.
| sho_hn wrote:
| Interestingly, Wayland is used to some extent in Chrome OS,
| including for bringing Android apps into the windowing system.
|
| 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...
| shmerl wrote:
| Yeah, I've seen that. I wish Android would close that gap and
| switch to standard Linux stack.
| AnIdiotOnTheNet wrote:
| 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.
| shmerl wrote:
| There is no reason today, besides historic ones.
| srameshc wrote:
| I have used React Native and now using Flutter. It's a bit of
| learning again , but I am not going back to RN since Flutter is
| far better.
| hapless wrote:
| Living proof there's at least one (1) flutter user outside Google
| singhrac wrote:
| 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.
| realusername wrote:
| 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.
| r_police wrote:
| Futures are very similar to JS Promises. They even have similar
| APIs and can also be worked with the "async/await" of Flutter
| cletus wrote:
| 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).
| kettro wrote:
| 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.
| layoutIfNeeded wrote:
| >These can run basic GC'd apps just fine
|
| 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!
| JoeAltmaier wrote:
| My experience is not this.
|
| 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.
| wahern wrote:
| 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).
|
| I made this point recently on the Lua mailing-list. Some
| people were wondering why Lua's default pairs() table
| iterator helper doesn't return a closure that encapsulates
| state, which would have provided some [minimal]
| optimization potential. Lua's iterator interface (it's for
| statement semantics), as exposed to both Lua code and C
| extension code, only requires three scalar values for
| iteration state--function (e.g. a C function), state (e.g.
| Lua table or userdata object being iterated on, but could
| be a simple, opaque C pointer), and control (e.g. index,
| which can be replaced each iteration). These can be more
| complex types (you could even return only a closure,
| without the other values), but the fact that they don't
| need to be is useful and important for when you're trying
| to avoid excessive heap allocation and garbage creation. Of
| course, the pairs() function is an _auxiliary_
| _convenience_ interface, one that C extensions wouldn 't
| normally use, but the Lua creators have always been good
| about paying attention to the small details. A simple and
| common for-loop pattern like for k,v in
| pairs(t) do done
|
| doesn't do _any_ dynamic memory allocation nor induce any
| GC churn.[1] In the above code, assuming t is a regular
| table and lacks a __pairs metamethod, pairs() returns an
| internal C function--a simple scalar in Lua--the table t as
| the state, and a special scalar (nil) as the initial
| control variable, which will be updated with pre-existing
| table keys during iteration.
|
| Just because people use GC doesn't mean they can't or
| shouldn't worry about memory allocation. It's just that
| they often don't, unfortunately, because GC makes it easier
| to ignore these details. And unfortunately language
| designers rarely do a great job at creating language and GC
| semantics convenient for fine-grained control over memory
| management. Even Rust has this problem--it's so darned
| convenient to _assume_ heap allocations are free and easy,
| or otherwise can be "optimized away", they many early
| developers convinced themselves that OOM is unrecoverable,
| which is the excuse one needs to justify ignoring some of
| the thornier questions related to allocation semantics that
| can be important even for those of the panic-on-OOM
| persuasion.
|
| I'm not familiar with Dart so can't opine on how amenable
| its language and memory semantics are to minimizing GC
| object load in the VM. I just know that in principle good
| semantics and APIs can make for excellent characteristics
| in this regard.
|
| [1] One might be skeptical whether it really matters if a
| for loop has to allocate a single object for the duration
| of the loop. But loops are often evaluated within other
| loops, directly or indirectly.
| dathinab wrote:
| Embedded is a _very_ wide field.
|
| 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.
| JoeAltmaier wrote:
| 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.
| black3r wrote:
| > 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)
| dathinab wrote:
| 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 12EUR.
| munificent wrote:
| I work on the Dart team.
|
| _> 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.
| dathinab wrote:
| 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.
| mraleph wrote:
| > 2. Dart has optional typing, which is to say it supports type
| hints but is essentially dynamically rather than statically
| typed.
|
| Dart has not been optionally typed since Dart 2 (released in
| 2018).
| Memosyne wrote:
| 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.
| beckler wrote:
| I think it's a side-effect of wider adoption. NPM/Node suffers
| the most from this. I would also argue that Rust is
| experiencing a little of this.
| ezconnect wrote:
| 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.
| joezydeco wrote:
| Fellow contrarian here.
|
| _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.
| pengaru wrote:
| 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.
| mahkoh wrote:
| GTK doesn't need Sony to damage their reputation. Trying to
| force CSD on everyone is damaging enough.
| pengaru wrote:
| The vast majority of app developers use toolkits and don't
| care where the window decorations come from.
| Longhanks wrote:
| Your ignorance is ironically proving his point.
| pengaru wrote:
| > Your ignorance is ironically proving his point.
|
| How so?
| zachruss92 wrote:
| 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).
| rajeevk wrote:
| I see this on dark.dev for web
|
| "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
| alex_reg wrote:
| Flutter Web does it's own rendering via canvas, so
| accessibility is off the table for now and there is no easy
| path to get there.
|
| 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.
| mhoad wrote:
| 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.
| discreteevent wrote:
| Apparently this is not true. It does support accessibility.
|
| https://news.ycombinator.com/item?id=24922849
| ZeroCool2u wrote:
| 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?
| sho_hn wrote:
| 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.)
| fmntf wrote:
| Is the IVI shell deprecated? I work in the automotive and
| that's what we are currently using.
| ZeroCool2u wrote:
| That makes a lot of sense, thanks for the insight!
| DonnyV wrote:
| 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.
| cbsmith wrote:
| I always like the notion of "it's lighter weight and has fewer
| dependencies... but it doesn't work right". ;-)
|
| It'll be interesting to see how much Wayland can remain lighter
| weight once it has accounted for all the "not working right"
| cases.
| [deleted]
| andrewmd5 wrote:
| We were early adopters of Flutter at Rainway[1] and absolutely
| love it. We even recently ported it to Apple TV.
|
| 1: https://rainway.com/blog/2019/08/06/flutter/
___________________________________________________________________
(page generated 2020-10-28 23:00 UTC)