[HN Gopher] Flutter for Linux
___________________________________________________________________
Flutter for Linux
Author : CSharpRon
Score : 262 points
Date : 2020-07-08 16:26 UTC (6 hours ago)
(HTM) web link (snapcraft.io)
(TXT) w3m dump (snapcraft.io)
| olingern wrote:
| I haven't dug into this, but I wonder what compatibility this
| will have with window managers, like i3
| l3s2d wrote:
| Just tested on sway, it draws the title bar, but otherwise
| seems to work.
| knotty66 wrote:
| I've just tested on regular i3 (no Sway).
|
| Works pretty well until you start moving or resizing the window
| but once I did it crashed the app a couple of times.
|
| I also couldn't start the app fullscreen on a 4K display - it
| just displayed a small black rectangle. Other than that it felt
| fast and smooth.
|
| It is an alpha though, so I thought it was promising
| nonetheless.
| heavyset_go wrote:
| Having recently chosen a Qt stack for cross-platform desktop
| development over Electron, I'm happy to see that Flutter is now a
| real contender in this space.
|
| I'm curious about Flutter and Dart bindings and calling
| interfaces for other languages. If you can integrate a Flutter
| front end with a back end language of your choice, that would
| change a lot of things for the better. The only reactive UI
| offerings for cross-platform desktop development with multiple
| language bindings are QML, which is great, or Electron with
| React, which is not so great if you want to use anything but
| JavaScript for your back end.
| colesantiago wrote:
| What is the off chance that Google will drop Flutter?
| sudhirj wrote:
| This matters only if Flutter is a closed source project - but
| it's not. You can fork it on Github right now and continue
| working on it even if Google pulls its engineers off. I'd
| assume that those of us (and there seem be a lot of people)
| invested in it will continue working on it.
| IshKebab wrote:
| > This matters only if Flutter is a closed source project
|
| Nonsense. Even though it is open source, if Google drops it
| it will be effectively a dead project since the vast majority
| of the work is done by Google, and Flutter still isn't a
| mature project.
| dathinab wrote:
| It might make it even more interesting for some people ;-)
| heavyset_go wrote:
| > _This matters only if Flutter is a closed source project -
| but it 's not_
|
| It certainly matters. Without a team of dedicated developers
| maintaining the project, the APIs it depends on will become
| deprecated, and it'll slowly become unusable.
|
| Flutter touches a lot of APIs across many platforms. It's a
| complicated project that needs to support virtually every
| popular operating system in a visually and behaviorally
| consistent way.
|
| Flutter also depends on Dart's maintenance, which is another
| project without significant open-source contributor activity
| outside of Google employees.
|
| > _I 'd assume that those of us (and there seem be a lot of
| people) invested in it will continue working on it._
|
| Having contributed fixes to Flutter and Dart, Google does not
| go out of their way to build an open-source contributor
| community around the projects. I would be surprised to learn
| that any significant support is provided by open-source
| contributors to Flutter or Dart.
| skc wrote:
| Google not too long ago released Jetpack Compose which has some
| overlap with flutter so it's anybody's guess.
|
| https://developer.android.com/jetpack/compose
| ryuukk_ wrote:
| compose is JAVA, and android only, since it's JVM, you'll
| need a big and slow runtime
|
| flutter is dart, and compiles to native, AOT and statically
| linked tiny executable
|
| flutter is the winner
| cxr wrote:
| If the Vala folks and Gnome in general could be convinced to
| drop Vala in favor Dart, or move valac in the direction of
| accepting a language that looks like (a subset or a complex
| supersubset of) Dart, it could be an effective hedge against
| Google pulling out. It would also be an instance of Gnome and
| the various commercial vendors who rely on it being ahead of
| the curve--particularly for mobile, while proprietary vendors
| are still left dealing with the legacy of Android, Dalvik, and
| Java.
| dathinab wrote:
| > Gnome in general could be convinced to drop Vala in favor
| Dart
|
| I would be _very_ surprised if that happens.
|
| The last time I checked it seems that if anything changes
| then that bit-by-bit _some_ components get replaced with new
| ones written in rust.
|
| Also I honestly would be very surprised if Gnome would move
| from gtk-based UI to a flutter based UI interface.
|
| I mean besides political reasons the amount of rework you
| would have to do is probably in a degree which makes it
| unpractical.
|
| And in context of libre5 and some other developments there
| was a lot of effort to make gtk-based UI ready to be used
| with handheld devices.
| pjmlp wrote:
| Gnome is already adopting Rust, and GJS has been the Vala
| alternative for ages, so no luck for Dart.
|
| Also Gnome has had multiple language bindings since the early
| days, most of them have more use across Gnome apps than Vala.
| cxr wrote:
| > Gnome is already adopting Rust
|
| That's not accurate. There are some Gnome contributors
| opting for Rust. Gnome is not adopting Rust.
| pjmlp wrote:
| GUADEC Rust meetings and the GStreamer improvements show
| another picture.
| [deleted]
| dathinab wrote:
| Only iff they drop Fuchisa.
|
| And if they drop Fuchisa and flutter has enough (relevant) apps
| using it in the Android Ecosystem they probably would keep it
| still around.
|
| But my guess is that one long play Google want's to keep open
| for them is to start replacing Android with Fuchisa and push
| for a ecosystem where they have control more similar to apple.
| I.e. directly push updates to phones without the phone
| manufacturer as middle man. As this is a source of a lot of
| problems with Android making it less competitive against iOs.
| mikece wrote:
| "Only if they drop Fuchsia."
|
| I hate to say it, but this is beginning to look like a real
| possibility. It looks like Google has been implementing into
| Android a lot of the modular, "make the system easier to
| update" aspects of Fuchsia with each release of Android. I
| think Oracle's continuing fight to make Google pay
| financially for using Java is doing more to keep Fuchsia
| alive anything else. If Oracle relents then it's possible
| that Nest devices (the only Fuchsia-based products currently
| shipping afaik) could eventually switch to an IoT version of
| Android... but since Oracle is a litigation firm that also
| happens to sell databases I don't see them ever stopping the
| lawsuits.
| The_rationalist wrote:
| If Android switch to openjdk like everybody else, they'll
| be lawsuit proof
| kllrnohj wrote:
| They did: https://arstechnica.com/tech-
| policy/2016/01/android-n-switch...
|
| The _runtime_ remains ART, though, but that wasn 't the
| issue in the lawsuit.
| The_rationalist wrote:
| I had read that too and I do not understand at all. What
| is openjdk beyond a runtime VM ? They do not use what
| truly qualify as openjdk otherwise they would have C2 and
| G1 and therefore true java 8+ support, for free.
| plq wrote:
| My hunch is that Google is trying to migrate away from Android.
| Flutter is both the abstraction layer to do that and the new
| SDK for the new platform.
|
| If that's the case, it's higly unlikely.
| dakna wrote:
| I think Google realized they needed a compelling cross-
| plattform solution because React Native started to gain so
| much traction.
|
| In terms of migrating away from Android, I think they will
| use the newer AndroidX packages as the future abstraction
| layer, which would enable them to replace the underlying
| runtime with something more native for each platform. It
| would be a compilation target for Kotlin as well as Dart. All
| while not deprecating the massive amount of production code
| out there. But, this is also just a guess.
| izacus wrote:
| That's a really wierd take if you actually look at what
| AndroidX is - it's a set of utility libraries to complement
| Android so it being some kind of abstraction layer is
| rather nonsensical. It's like saying boost is an
| abstraction layer for Linux and it allows its replacement.
| It's an orthogonal thing that doesn't stand alone.
| dakna wrote:
| Yes, it's a set of libraries under one package name. With
| Google's massive investment in refactoring it has a
| pretty big surface already, from persistence to UI and
| almost everything in between.
|
| https://developer.android.com/reference/androidx/packages
|
| It's current implementation uses classes that are part of
| the Android layer, mostly the old support library plus
| some new abstractions like LiveData and Room and
| Navigation. I see no reason why you could not use the
| public interface of that library as a compatibility layer
| for application level code and let it run on a different
| platform.
|
| Not today, but given the fact that you can't just kill
| the worlds most used operating system, you either use
| virtualization like Apple now does again for ARM (and
| before when replacing Motorola with Intel) or you change
| the underlying dependencies of the libraries used and
| compile again.
| adonese wrote:
| I think being used with Fuschia is a good sign
| sgt wrote:
| Does this work well on RPi 4?
| me551ah wrote:
| The future of cross platform desktop development looks bright.
| Microsoft is coming up with .NET 6 and Google has flutter. I just
| hope that these frameworks can replace bulky electron apps.
| k__ wrote:
| Revery also looks nice.
|
| I wish they had more funding, tho. I find Reason/OCaml more
| compelling than Dart.
| thomasfortes wrote:
| There's a guy that managed to compile and run revery on
| android, I would love to have that as an option since I'm
| already familiar with ocaml/reason and only barely literate
| in Dart (and also prefer functional languages over object
| oriented ones)...
|
| https://github.com/EduardoRFS/reason-mobile
| k__ wrote:
| Pretty cool!
|
| They have mobile platforms on their roadmap for quite some
| time now, but somehow the project doesn't seem to get much
| traction.
|
| I guess, Dart would be dead by now, if it wasn't for Google
| pushing it with Flutter.
| sly010 wrote:
| How is OCaml's multithreading story? Google says it's
| basically GIL-ed.
| blandflakes wrote:
| Simultaneously in a state of having-been vaporware and
| making real progress towards being merged to master:
|
| https://discuss.ocaml.org/t/multicore-ocaml-june-2020/6047
| WorldMaker wrote:
| The "Next" and "Next + 1" versions of React Native are starting
| to look quite exciting too. The Microsoft-backed full C++/WinRT
| rewrite of the Windows desktop support seems to be making good
| progress. With the Office team supposedly backing React Native
| as their preferred cross-platform toolkit moving forward,
| Microsoft looks like they'll be investing in RN for the long
| haul.
|
| It seems good for everybody that Microsoft seems to be putting
| so much work into cross-platform dev in both .NET 6 and RN.
| awill wrote:
| Google needs to release desktop apps in Flutter (Youtube Music,
| Chat, Meet etc..). a Webapp is fine for occasional use, but
| Google Chat can't compete with Slack without a real app.
| spankalee wrote:
| Totally. You definitely can't compete against Slack's desktop
| app with web technologies: https://slack.engineering/building-
| hybrid-applications-with-...
| dahfizz wrote:
| Personally I can't tell the difference between the slack app
| and slack open in my browser. It is literally identical. In
| Firefox, I can even go "full screen" but still control the
| size and location of the window, so I don't have to look at
| the tab bar. Side by side, I can't tell them apart visually
| or functionally.
|
| Maybe the Linux version of electron is neutered in some way?
| I read article you linked and I don't know what bouncing the
| dock means, maybe that's an important native feature for mac
| users?
| jeffbee wrote:
| Slack in the browser is visibly superior to the slack app.
| When I close the tab it's really dead. Great feature.
|
| The slack "app" is just their web site and a web browser
| zipped together in such a way that it doesn't actually quit
| when you tell it to quit. Why anyone wants that I cannot
| begin to imagine.
| kelnos wrote:
| I uninstalled Slack's desktop "app" a long time ago and never
| looked back. The browser version is much better, and doesn't
| require me to have an extra (often buggy, in my experience)
| browser instance open in order to use it.
|
| Calling it an "app" is somewhat laughable, since it's just
| their website packaged up in a standalone web browser, plus a
| minimal amount of platform-specific glue.
| judge2020 wrote:
| Their focus seems to be full-on installable PWAs for
| everything, which YT Music and YT TV already having them (and
| PWAs are only marginally better than Electron since they all
| share the same parent chrome process).
| thomascgalvin wrote:
| Does Flutter have a native HTML widget yet? It didn't when I
| first started poking around with Flutter, and a quick Google
| doesn't reveal anything first-party.
| grizzles wrote:
| WebView is such a _core_ component.
|
| In the interests of completeness, Flutter.dev really ought to
| bundle an android-like webview component in the core libs.
|
| It really breaks the WORA value prop if you need to if-elif
| your way around platform specific impls.
| mnazim wrote:
| A number of packages provide webview, which can be used to
| render html pages.
| ellsthrow wrote:
| These still aren't "production" ready yet though
| unfortunately e.g. they don't currently support keyboard
| input
| armytricks wrote:
| Having used Flutter extensively since I was first introduced to
| it 9 months ago, I can say that it is an absolute joy to use and
| build interfaces with. An easier way to install the Flutter SDK
| on linux is only good news and I hope it gets more developers to
| adopt it.
| programmarchy wrote:
| Agree, Flutter is top notch. I've had trouble pitching it as a
| technical solution, though. For one, I think word is out that
| Google will kill projects mercilessly, and there's an odd
| dynamic between the promotion Flutter and Kotlin/AndroidX.
| Generally, Kotlin comes out on top as the "safer" choice.
|
| It's a shame, though, because the primary advantage I see with
| Flutter is its superior UI framework. It's leagues better than
| the AndroidX compatibility lasagna, in terms of architecture
| and DX. So it really stands out as a cross platform solution
| not just across iOS and Android, but especially across the
| Android ecosystem itself.
| threatofrain wrote:
| Google has been timid in promoting Flutter, so it's clear
| that Google's not ready to put the weight of their brand
| behind it yet.
| kelnos wrote:
| > _Canonical is making it very easy for application developers to
| publish their apps for Linux users via the Snap Store, the app
| store for Linux._
|
| Ugh. No, Canonical, no matter how much you'd like it to be, the
| Snap Store is not, and will never be, "the app store for Linux".
| The last thing the Linux community wants or needs is a closed-
| source[0], walled-garden approach to distributing applications.
|
| [0] For the pedants out there: yes, you can create Snaps with
| open tools, but the only Snap server implementation is closed.
| fungos wrote:
| Flutter: yay!
|
| Snap: nope!
|
| Anyway, hopefully this will cause a push for flutter support on
| other distros that are snap free.
| Andrex wrote:
| I'm still excited because when Canonical backtracks on Snap in
| a few years (like they seem to always do when trying to push
| some homegrown aspect of Linux), their Flutter work will still
| be there and will have seen years of improvements.
| timsneath wrote:
| It's worth noting that Ubuntu support and Snap support are
| orthogonal. The Flutter work here generates standard ELF
| binaries that can be distributed outside of Snap, and
| Canonical's contributions to create a high-quality desktop
| embedder for Linux are applicable across all distros.
| etse wrote:
| What are some high quality non-Material, non-Cupertino themes
| that any Flutter (mobile) developers can recommend?
|
| Material is well done, except I really don't like the actual
| design. Cupertino looks more like iOS 7 than iOS 14 and lacks
| something...
| reddotX wrote:
| flutter on Ubuntu 20.04
| https://www.youtube.com/watch?v=MnXKtwKNAB4
|
| flutter create flutter run
|
| done
| avilesj wrote:
| I'm excited to have another contender on multi platform apps
| space but in the case of Flutter for desktop I just wonder about
| the RAM consumption compared to Electron.
| programmarchy wrote:
| Dart compiles to native machine code, so unlike Electron
| doesn't need to host an interpreter, which tends to
| aggressively allocate memory. Should be much friendlier on RAM.
| skratlo wrote:
| Yay, Macromedia Flash for desktop is here, made in Google, Dart
| instead of ActionScript, wow, just wow.
| yjftsjthsd-h wrote:
| I assume that this is meant as a criticism, but Flash was quite
| good at easy-to-make portable graphical apps; they had massive
| security issues and some lack of polish, but there's a reason
| why Flash dominated its era. (Also, "Macromedia Flash for
| desktop" was already a thing, no?) So yeah, "Flash but modern
| and safe" would be a pretty strong selling point.
| Apocryphon wrote:
| There was just a thread bemoaning the lost art of Flash games
| last week:
|
| https://news.ycombinator.com/item?id=23705174
| akie wrote:
| You're not wrong.
| Spivak wrote:
| I think they're mostly wrong. I think we put too much stock
| into the default UI toolkits on each platform since this
| really isn't much different than how GTK and QT work. They
| have their own rendering engines and have to draw all their
| widgets from scratch just like this. The only difference is
| that GTK and QT are blessed.
|
| I think there's a case to be made for sticking to the
| defaults for consistency's sake but Flutter is just as native
| as any other UI toolkit on Linux.
| topspin wrote:
| Interesting that Flutter "Desktop support" exists for macOS and
| Linux, but not Windows.
| kjksf wrote:
| It does exist for Windows (i.e. I compiled and ran Flutter app
| on Windows).
|
| It's just slightly behind macOS and Linux in maturity.
|
| In general desktop support is "early alpha" quality.
|
| I'm hoping that in a year or two Flutter will be a solid option
| for mac/linux/windows desktop apps.
|
| For now we have to accept that it's an alpha quality software.
| Dowwie wrote:
| see the flutter-rust ffi: https://github.com/brickpop/flutter-
| rust-ffi
|
| Is anyone considering writing flutter + rust desktop apps in
| linux?
| oaiey wrote:
| Microsoft really has to speed up the Xamarin.Forms / Maui
| development. The omission of Linux is a really a pity.
| [deleted]
| ryuukk_ wrote:
| MAUI sucks, it is xamarin bis, uses 654654 different renderers,
| uses C# and compiles with a JIT, enjoy your 100mb MINIMUM apps,
| even for hello world
| jayd16 wrote:
| They said they'll have a preview by the end of the year. I'm
| excited to see it but I'd rather they do it right instead of
| right now.
| CSharpRon wrote:
| TIL about Maui. From my light researching, it looks like any
| Linux implementation of Maui will be community-led instead of
| Microsoft led like the Windows and MacOS implementations.
|
| https://github.com/dotnet/maui
| CSharpRon wrote:
| Great news for sure. There's a React Native application that I am
| maintaining; it's not too complex but I would love to give a
| rewrite a try with Flutter and see how it does on Ubuntu.
| mixmastamyk wrote:
| Good to see. I've been wanting to use Flutter for a Linux-based
| appliance but it still needed a lot of work on that front until
| recently. If there was a bittorrent library in Dart as well I'd
| be off to the races.
|
| Up until this time I've been using Kivy for the application, but
| it has a ton of issues and doesn't seem to receive much
| investment or support, even if you wave money around.
| axegon_ wrote:
| I'm actually a great fan of flutter and imo it is the best cross-
| platform solution out there. Probably except for web: though it
| produces very good result performance-wise, the end result is
| never really "web" and doesn't act like traditional web. As for
| desktop applications(whether it be windows, linux or mac), it
| seems like it's too mobile-oriented. I see great potential for
| simple solutions like self-service operations where you need a
| basic UI and it would be great if it could easily target
| platforms like raspberry pi (arm processors running Linux). But
| at the moment, while possible, it is a very painful thing to
| tackle and I wouldn't rely on something like that for an end
| product. I would assume that this is why google is working on
| fuchsia but way too few devices are supported. And neither of
| them is cheap(which is what could be a game changer, going back
| to the raspberry pi).
| RivieraKid wrote:
| I've been using Flutter in the last few months and agree. It's
| the best multi-platform solution for _mobile_ , although it
| still doesn't match native behavior and performance, it only
| gets close.
|
| On the web it's DOA for most use cases - it's just a canvas, so
| scrolling, text selection, shadow rendering, etc. is custom,
| doesn't feel native and must be downloaded and compiled.
|
| It can have a future on desktop. One "cultural" obstacle is
| that the de facto default widget system is Material, which is
| simply a wrong approach to desktop UI.
| bepvte wrote:
| Flutter only falls back on the canvas, it avoids using
| anything but html elements if it can. Fancy animations tend
| to resort to the canvas
| akerro wrote:
| >It's the best multi-platform solution for mobile
|
| They announced beta version for Windows in the last few
| weeks, so what to expect? I've been using it on linux desktop
| for 4 months so far, there were many problems, but it's
| absolutely the best framework so far. It's miles ahead of Qt
| (which I've been programming in since 2010). Dart and flutter
| are just years ahead of Java, C#, Qt and React Native in
| terms of positive programmer experience, productivity, good
| looking UI. There are so many bad things to say too, but all
| I can think about are only due to immature ecosystem, but
| that's changing literally daily.
| rowanG077 wrote:
| Dart is the reason I don't like flutter.
|
| Why do you feel C# is worse then Dart?
| satvikpendem wrote:
| Dart is...fine. The real value comes in its code
| generation features, which enable packages to add
| whatever language features they want even if the language
| maintainers don't (yet), such as algebraic data types,
| functional programming features, etc. You can argue this
| as being good or bad for future maintenance but it's nice
| to have the ability to add to the language.
| brnt wrote:
| Hoe is it ahead of Qt (on desktop)?
| muth02446 wrote:
| I wish the dart/flutter team would focus on improving dart
| for web (e.g. by updating/fixing the JS bindings) instead of
| chasing flutter for web which seems like a long shot and
| rather hacky (referring to using the canvas for rendering
| content)
| vesinisa wrote:
| > using the canvas for rendering content
|
| This sounds like Flash all over again. Let me guess - no
| native text select, copy & paste supported? Scrolling is
| "wrong" in a subtle way?
| timsneath wrote:
| We haven't reached perfection yet (that's why we're still
| in beta), but our goal is to be _very_ different to Flash
| in these kinds of areas.
|
| Here's an example of text fields:
| https://gallery.flutter.dev/#/demo/text-field
|
| Right-click and you have access to the browser context
| menu; choose Inspect and you can see a <textarea> or
| <input> control.
| spiderfarmer wrote:
| Tie it in with AMP and you have the webdev cocktail from
| hell.
| blandflakes wrote:
| Dart actually has a lot of characteristics that make it
| appealing for a lot of the areas I'd have (begrudgingly) used
| Go - command-line tools or local utilities. It "can" be
| scripted, but also AOT compiles, has a saneish type system with
| generics, and doesn't have pointers to deal with. It's hard for
| me to want to use it on the web, but I keep watching it and
| wishing good things for it.
| wstrange wrote:
| Dart produces surprisingly small docker images for server
| code. I recently created small Cloud Run web service with
| Dart - the docker image is 5.2MB compressed, 12.9 MB as
| reported by docker.
|
| I'm not even sure Go would do better on image size. Tree
| shaking does wonders here.
| [deleted]
| vetinari wrote:
| > command-line tools or local utilities.
|
| FFI is quite a PITA, though. Soomer or later you will have to
| interface some platform libraries, and Dart doesn't make that
| easy.
| timsneath wrote:
| Curious what platforms you're interested in integrating
| with. We're experimenting here and looking for feedback. As
| a fun demonstration of the effectiveness of FFI, you can
| now build Petzold-style native Windows code with Dart: http
| s://github.com/timsneath/win32/blob/master/example/hello...
|
| And here's a 500-line version of the Kilo console text
| editor built with Dart: https://github.com/timsneath/dart_c
| onsole/blob/master/exampl...
|
| Unlike the original, it runs on both Windows and UNIX-based
| operating systems.
| malkia wrote:
| Tim, it should be possible that the main .exe (or binary
| on linux/osx) to export functions, and they can be found
| back through the flutter_engine.dll/.so, right? (At least
| on windows it's possible for the exe to
| __declspec(dllexport) things, not sure on Linux).
|
| But even if not, if there is a way to (given might be
| slow and tedious) to compile what would've been
| flutter_engine.dll statically linked to your main (host)
| app, and maybe somewhat hinting here is how to find the
| "GetProcAddr/dlsym/etc." functions - if one is to look
| for them.
|
| Further on, the generated from dart .so file can be
| embded (as resource? or slapped at the end of the
| binary/.exe?) + slapping all other resource - resulting
| in single app :)
|
| I know it's possible, just not so easy to support it (I
| guess). It's similar to have java/python can be packed
| into one executable with all C/C++ ffi functions they
| call (at cost of some build time and effort to achieve
| so).
|
| Then you'll have killer platform for video conferencing
| (zoom, bluejeans, etc.), messaging (slack, etc.) - and
| just single binary to deploy.
|
| (Oh, on top of that slap a web server into it, and make
| it that if called with specific command-line option, now
| it acts as web-server, and the app is visible through the
| web).
| vetinari wrote:
| I'm actually more interested in Linux side of things.
| That doesn't prevent me from looking how things are done
| on Windows, of course.
|
| To be fair, last time I looked into dart, the idea of FFI
| was ports, which was too overcomplicated and
| undercapable, if you needed something like Gtk or Vulkan.
| Looking into it now, I see the dart:ffi package is
| shaping up nicely, so I will have another look at dart
| again.
| jamil7 wrote:
| > FFI is quite a PITA
|
| This is what made me nope out of it last time I
| experimented with a Flutter module in my app. I'm still
| watching it closely though as it could be a great fit for
| other projects.
| kjksf wrote:
| This might be outdated opinion (hard to tell without OP
| explaining what he finds "a PITA").
|
| dart:ffi (https://dart.dev/guides/libraries/c-interop) is
| a recent addition to Dart and from where I stand it's a
| decent FFI system.
|
| Maybe not as good as PInvoke in C# or ffi in luajit but
| better than, say, jni in Java (and any other FFI system
| that requires you to write glue code in C i.e. python,
| ruby, nodejs).
| mikece wrote:
| Flutter's ability to "compile to web" was something that
| confused me at first as well, but on second thought it's
| genius. It makes it easier to ease managers into selecting
| Flutter since deployments and updates are done via a web
| browser. If that works for them then maybe there's never a need
| to go fully native though that option exists if they want to --
| and the ability to go back to compiling for web gives managers
| a sense of "this isn't a one-way, I'm screwed if something goes
| wrong" journey.
| anonms-coward wrote:
| > and the ability to go back to compiling for web gives
| managers a sense of "this isn't a one-way, I'm screwed if
| something goes wrong" journey
|
| It wouldn't be a good idea to believe that though. Flutter
| website are just canvas paintings, and have nothing to do
| with the web. You can't add new html or js to it easily.
| can't make much use of new improvements in the web world.
|
| Most importantly, if you are running a business, flutter web
| isn't really accessible, so please don't use it for any non
| internal tools
| kllrnohj wrote:
| My experience with Flutter was that making the UI itself was
| pretty great. But making the rest of the app sucked. FFI
| support is bad. Platform channels are miserable. Doing it all
| in Dart is awful because there's no cheap concurrency - it's
| the same multi-heap with expensive "IPC" shittiness that you
| get with webworkers, but way less justified since you're nearly
| always on platforms with native threads. It's a huge pain to
| try and migrate piecemeal too, so if you have an existing
| app/codebase you're looking at a re-write.
|
| UI performance was fine (not any better than native though),
| but RAM usage was pretty bad, a lot higher than native.
|
| Really fantastic iteration workflow, though.
| eklavya wrote:
| I am so excited about flutter ecosystem. Hopefully linux gets
| first class beautiful native apps now. I also hope against hope
| that qt is officially supported as a backend so KDE is not left
| out.
| andrepd wrote:
| Judging by the example in TFA, we must have very different
| conceptions of what "beautiful" means. That is an atrocious
| application.
|
| * Ungodly amounts of whitespace (seriously, look at that
| sidebar, look at that search bar. WHY? too much optimisation
| for what "looks good on a screenshot", maybe?)
|
| * Undecipherable symbols where there's _plenty of f#cking space
| to write labels god damn it_
|
| * I bet bad/nonexistant keyboard support (remember alt-* to
| navigate menus?)
|
| * Ugly to look at (subjective)
| Spivak wrote:
| You do know that none of that is really do do with Flutter,
| right? Like you're just taking it out on the designers of
| Flock.
| ocdtrekkie wrote:
| This isn't true: Google preloads their design conceptions,
| namely Material, into Flutter at the ground level, and
| Material is a terrible set of UI patterns, such as the ones
| the parent comment was complaining about.
| RivieraKid wrote:
| I wouldn't call Material UI on the desktop beautiful. Mac OS is
| beautiful. Gnome 2 too relative to other Linux DEs. It won't
| use Qt but Skia.
| rst wrote:
| So, this makes Flutter apps available through Canonical's Snap
| store... which is Ubuntu-mostly right now, and controversial
| enough that the top item on the HN front page as I write is about
| an Ubuntu derivative (Linux Mint) explicitly dropping support for
| it. https://news.ycombinator.com/item?id=23771847
| topspin wrote:
| "Canonical's Snap store"
|
| Correction: it's "the app store for Linux".
|
| /s
| simosx wrote:
| Other distributions also use the Snap Store.
|
| See the stats for the Skype snap package for the range of Linux
| distributions, https://snapcraft.io/skype
| canada_dry wrote:
| Until SNAP gives me full control (and not just: you can opt-
| out) over updates/upgrades they're a non-starter.
| kelvie wrote:
| Also it's ridiculously annoying debugging issues with them,
| or finding out what source code compiled into a particular
| snap.
|
| Even with docker hub I can find the sourcecode easily linked
| 99% of the time.
| lallysingh wrote:
| Does snap not let you manually do those?
| ric2b wrote:
| No, it updates by itself, sort of like Windows 10.
| timClicks wrote:
| Many snaps provide channels so that you an pin your locally
| installed version to a specific upstream version. That way
| you have full control over when you upgrade.
| haolez wrote:
| For my usage, Flutter is a no-go for web development for the same
| reason as Qt: it's just a canvas, so text selection,
| accessibility, etc doesn't work nicely or at all.
| paulcarroty wrote:
| Good news, but all depends how much Google interested in Linux
| desktop support in Flutter. I'm highly skeptical due to their
| "hyper activity" in Linux desktop niche.
| harikb wrote:
| I have a request for all the Flutter folks/fans - it would be
| great if you all can say something about how you can get over /
| stay sane with the staircase looking nesting of code blocks and
| how you manage to keep it all in your head to navigate the code
| base.
|
| I started my career writing single threaded Palm OS apps (64k
| limit) - there was like 10 possible widgets with 5 possible
| events on each widget and rest of it was application code. Mobile
| app development is a different beast now. Yes, I sound like old-
| man-yelling-at-cloud. Is this table-stakes for all UI and App
| development?
| Lionga wrote:
| You just don't throw everything in a big build method, but make
| small functions for every logical unit instead. Simple, easy,
| clean and maintainable.
| gladimdim wrote:
| You can also use Flutter Inspector - a UI tree representing
| your runtime layout. It allows to quickly jump between widgets
| liquidise wrote:
| I have [self-diagnosed] Code Style OCD. Like you, the Flutter
| nesting levels was a major fear entering the space. It feels
| both ugly and inelegant.
|
| I found i was over this fear in days if not hours, and
| continued to improve with my ongoing discovery of helpful UI
| components. Furthermore, defining your own components and
| breaking out inline functions into proper functions in your UI
| classes goes a long way, too.
|
| Android Studio, if you use it (i didn't), auto-appends closing
| bracket comments to keep you visually aware of your nesting.
| For the reasons i stated, i don't think it is as important as
| you might think.
|
| If you haven't tried Flutter, particularly for syntactical
| reasons, i would urge you dip your toes in.
| heavyset_go wrote:
| > _it would be great if you all can say something about how you
| can get over / stay sane with the staircase looking nesting of
| code blocks and how you manage to keep it all in your head to
| navigate the code base._
|
| The same way you would in any other code base, with the ample
| use of names and modules, and breaking nested components and
| logic into their own classes and functions.
|
| The problem is that it requires discipline, or at least a
| standard style guide, to adhere to. It's similar to JavaScript
| in that regard, where bad practices can seemingly be ignored or
| even encouraged.
| tarkin2 wrote:
| Smaller staircases. Split your component into functions.
|
| I've seen some horribly large components that would be much
| better if split up.
|
| Google should really advise this.
___________________________________________________________________
(page generated 2020-07-08 23:00 UTC)