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).
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.
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.
I wrote it's more pleasant to be used by programmers by giving better experience, then I wrote it's ecosystem is immature, but growing. As of now, it has its better and worse sides.
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.
> The real value comes in its code generation features, which enable packages to add whatever language features they want
Got any eamples of ADTs, pattern matching, immutable collections, data classes, named parameters, etc.?
Coming from Scala and TypeScript the Dart language is pretty unappealing wrt syntax and functionality, kind of archaic actually. Flutter looks amazing and have been hoping that Dart would evolve more quickly than it has.
You commented this elsewhere too without elaboration. I'm curious as to what you mean by 'widget hell'.
I founded the nested tree of widgets syntax good after getting over the (short) initial learning curve. Some basic good programming practice over shared bits and it was very maintainable even for complex screens.
This is a wonderful answer and much better than what I was about to write.
Flutter Widgets, like HTML are declarative. They're just hierarchical information. This works in HTML, and it works in Flutter - there's nothing to get confused about.
Nested control flow (if statements, loops etc.) obscures the actual behaviour and so good practice is to break it up until it is clear and understandable.
Widgets are declarative, like in HTML, the nesting is additional information. With callback hell, you nest logic, and actually obfusc information about the control flow.
Flutter for web feels like going back to the .net "webforms" days, where you could supposedly build a web app the same way as a desktop one and the whole client-server thing was abstracted away. Except it sucked, I still have nightmares about viewstate. Seeing Flutter apps that render everything to canvas feels similar.
Developing once for iOS and Android seems obvious and doable, but extending that to the web is a different game.
I think the goal of running native speed compiled-ish code on the browser in a sandboxed way would be great if it worked. CSS and HTML for "apps" has always seemed like a hack to me. The problem is every single attempt to do this in the past has resulted in a bloated mess. Maybe this time will be different...
The irony is that with WebAssembly maturing, we will have the revenge of plugins, and stuff like Flash is already being brought back, but hey now it is a standard browser feature.
> Developing once for iOS and Android seems obvious and doable
After shipping an app in it this year I've become a big fan of Kotlin Native, you can do enough code sharing to take the edge of doing two apps as a solo dev while having very little friction to access native views and APIs. The two apps feel like platform citizens on each OS but I have networking, persistence, utils and state management shared between them.
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)
Frankly that feels exactly like a Flash page. Natively selecting text content isn't supported on either Firefox or Chrome on Android (apart from within inputs). Scrolling is broken ("yanky").
Flutter for Web further feels like a nightmare for accessibility. I tried enabling the native Google screenreader on my device. It only says "No text found at that location" when I try to read any of the Flutter demo pages in either Chrome or Firefox. In addition to being extremely hostile to people with disabilities, it will soon actually be illegal to build new products with accessibility-hostile tech like Flutter for Web for large parts of the European public and private sector:
About accessibility, you need to find the "Enable accessibility" button and press it first. It's not visible on screen, but you should be able to find it with your screen reader's navigation commands (e.g. swiping left and right on a touch device). Yeah, it kind of sucks that the user has to turn accessibility on, and for that reason alone, I will never willingly develop a web application with Flutter. But at least it does support accessibility.
Right, to be fair I was able to enable the accessibility mode with your instructions. This way, the text content is indeed accessible to a screen reader. However, navigation in any of the demo apps with a screen reader was completely broken. So a user might be able to read a single page but not discover further content. With normal web pages we usually have <a> elements that enable navigation regardless of visual gimmicks.
Don't kid yourselves. Web target is very much early alpha for Dart.
There are so many obvious problems with it:
- Everything relies on 1500 nested custom elements with hardcoded transforms to put them in place
- This breaks default browser interaction with the page entirely. Because what may look like a page is actually a bunch of absolutely positioned controls with absolutely positioned canvas inside them.
- Scrolling, one of the most important things in a browser, is broken. It's janky and slow (manually re-implemented?). I'm guessing containers have to be explicitly marked as scrollable with correct sizes, because resizing the browser window does not make content scrollable (try it with the demo you linked).
- Text is broken. Because it's rendered onto a canvas. So, all text interactions + accessibility is broken. Fonts are rendered incorrectly. I mean, on the demo page you can't even copy code other than through the "Copy All" button.
- Navigation is broken. Navigating the demo apps (which have more than one page) is not reflected in the url, so the back/forward buttons are broken
- Keyboard navigation is broken. Nearly none of the elements can be tabbed to. Except some buttons in demo pages. I guess they are explicitly marked as such?
- When elements can be navigated to by keyboard, they can only be activated by Spacebar. Even though Enter also exists. I'm pretty sure forms cannot be submitted by pressing enter, either.
- iOS-style date pickers are clipped in Safari
- 2D transformations demo is broken in Safari
It's just me spending five minutes on the demo site.
That's really cool but I think all text, such as "Please enter only alphabetical characters", should be selectable. For example someone may want to copy & paste it into a bug report.
Yea, Flutter Web isn’t viable and likely never will be. The approach will require re-implementing browser primitives (like copy paste) which means you’re always going to need to ship a ton of JS to clients which makes it antithetical to the PWA approach.
EDIT: thanks for the downvote. But you don’t have to take my word for it, this sentiment is (privately) shared by Googlers themselves working on Chrome and PWAs.
Om The flip side, modern javascript frameworks seems to like to reinvent the basic primitives as well (based on how often my back button is broken), so I'm not certain that will be a deal-breaker.
+1 on this one. I've fiddled with angular dart for instance and tbh as someone who is horrible with doing frontend and hates js with a passion, this was enjoyable. Yet the release of the newer version[0] is taking forever.
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.
> 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
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.
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.
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:
https://github.com/timsneath/win32/blob/master/example/hello...
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.
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).
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.
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).
good thing to have in an FFI system is ability from one language to call another from callback, and back and forth (if it need to). I believe Dart allows for that. That to be said, stack walking is going to be painful to decode (probably), best I've seen is C#/C++ on Windows - where it flows naturally from one to another.
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.
ya, I hear you. It's a very common annoyance. We've been adding some support in the form of https://pub.dev/packages/pigeon to make the interop calls and data class passing more "direct".
What I found ironical with flutter was, besides everything being a 'widget' in flutter it doesn't actually support creation of android widgets or iOS widgets[1].
And that I'm worried that Google might just pull the plug as I feel the community is not in the position to continue development without Google's involvement unlike React Native.
Also, I'm not entirely sure about the future of Dart language now that we have TypeScript. Overall I feel flutter to be a risky investment, I personally would rather develop PWA in-spite of Apple's explicit hurdles(which I think may change after couple of anti-trust litigations).
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
Flutter announced support for Linux. Canonical announced that they'll help the Flutter team in making Flutter a great option to do app dev on Linux. They also published Flutter SDK to the Snap store, the preferred app store for Canonical. None of this means that people cannot package and publish Flutter to Debian, Ark or Fedora repositories. It'll still support Linux as a whole as long as the dependencies are present on the system. Canoncal is just investing resources in making sure it works for their distribution of Linux as well as possible, not to ensure that it only works on Ubuntu.
The snap store support is a small part of what is announced here. The team developed a GTK+ based host for flutter, which works regardless of the packaging method you use.
The end of the blog post talks about modifications to the snapcraft build tool to fully support flutter.
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.
Yeah, it would be useful to have a metadata field "packaging repository" or something.
Snaps built from GitHub with snapcraft.io include a manifest and the build recipe in the `meta` folder in the root of the snap. This includes all the info about the source code and allow you to reproduce it. Publishers can enable this on their own build infrastructure using an environment variable.
Many snaps also link to the source repository in the "contact <publisher>" link.
Not if I can help it on fedora, and all things I ever tried form there did not work properly.
> See the stats for the Skype snap package for the range of Linux distributions, https://snapcraft.io/skype
Most of those are recycled Ubuntu. Still don't get how the reasoning there works: ah look a garbage distro, let's fork it and make it better? Pick literally anything else.
My first thought when seeing this post links to snapstore was "ugh, not that garbage again". Every time I tried using Snappy on fedora it did not work and was so horrible I reverted to immediately removing snappy from my computer afterwards.
Canonical makes garbage software that is superficially easy to use but flimsy and flaky.
> Ubuntu is clearly good software made by Canonical
I can only speak for my own experience but if I had to choose between using Ubuntu for the rest of my life and losing a finger, I think I would lose a finger.
There is no worse operating system I have ever used. It is Linux made by people who never bothered to open a manpage, software engineered by people who think engineering is waste of time. It is basically the Robert McNamara of operating systems, I can just hear him now, "there is no such thing as planning or engineering, just crisis management". Funny thing is they probably think crisis management is too big an ask.
One of my biggest gripes with Windows is that many parts of it feels like it was created by people who never even tried it because it should be obvious to anybody who ever tried it that it is a horrible user experience.
Ubuntu is basically the dumpster fire version of this. It's like someone read about dumpster fires and thought "wow, that sounds nice, how can we make an operating system like that".
This comment adds no value to the discussion; it's "Ubuntu bad, Canonical bad" stretched over 4 paragraphs. Yes, it's clear that you don't like them. HN discussion are expected to be more substantial than this.
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.
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.
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.
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.
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?
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.
Slack is behaving in the same way as innumerable instant messaging clients in the past, because they consider themselves in that category rather than perhaps in an IRC sort of category which is maybe where you see them?
And there's an option to turn that behaviour off, if you don't like it.
But I would prefer if it wasn't all Electron because it really does feel like the resource overhead is unnecessary. But if it wasn't done with this tech, we probably wouldn't have a Linux client at all, and maybe not a Mac one either, and personally I prefer it to feel like an application instead of having to run it inside a browser.
Kind of hoping Flutter helps advance the situation of cross-platform desktop/web things in a positive way.
"""By default, your app is set to keep running in the notifications area even when the window is closed. Choosing not to leave the app running will remove the Slack icon and badges from your notifications area."""
But that's normal for all apps on OS X. Closing their window doesn't mean quitting them. I'm not sure why you'd fault Slack for following the OS's conventions here.
To quit it, choose that from it's menu or use the cmnd-q shortcut IIRC.
You mean hiding the browser chrome? Becuase I've been looking for a decent way to do this for years. Do you use a profile for every app? My rationale against this is that I'd like to share the plugins and settings.
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).
If they share the same process then they are better by orders of magnitude in terms of memory usage. Although not everything should be a PWA, you can still write good PWAs if you want to.
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.
Flutter implements a bespoke renderer called Skia. It is its own backend. For Qt to be compatible with Flutter you'd have to port Qt to Dart. There's nothing wrong with running Flutter apps and Qt apps simulatenously.
It would be an interesting project for someone to create a KDE type of desktop environment in Flutter. Can it be done?
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?)
You can style the widgets however you like. You don't have to use the default Material toolkit, the same way you can design Qt widgets in QML and don't have to use those default 1990s-style gray box widgets.
> remember alt-* to navigate menus?
I do, but most people reading this probably won't, or there will come a time shortly when most people won't remember. I think most people are used to everything being a web/Electron app. Users do not expect a standard design language (like Win32/Swing/Qt) for desktop apps anymore (and indeed a Win32-style desktop app will soon look as foreign as a webapp since even the Windows shell looks like a webapp now).
Flutter lets you create "webapps" (which is the new standard) but with native performance and ability to make syscalls (being native).
The only alternative tech stacks to this end are QML/QtQuick, JavaFX, an embedded WebView, or embedded Chromium (e.g. Electron or Chromium Emebedded Framework)--all of which having some sort of baggage. Flutter's baggage is you have to use Dart. The alternatives all also require that you use some sort of DSL (QML (Qt), FXML (JavaFX), JS (Electron)) so that's not a unique disadvantage. (It really isn't a disadvantage--imagine the hell if there weren't a DSL for the View layer and every language had to have bindings.)
GUI programming is downright suffering no matter which way you slice it. There are no interesting problems to solve, unless you're working on the GUI framework itself. Flutter makes this suffering slightly better. I don't see how it's not an absolute good.
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.
You don't have to use the material design stuff, you can just make your own components, all custom, just as you would on the web. Just replace MaterialApp with WidgetsApp at the root of the application tree.
You don't have to, but it is the default, which means it sets the standard of design there. Unsurprisingly, most things you see made with Flutter tend to either be or be similar to Material.
> I also hope against hope that qt is officially supported as a backend so KDE is not left out.
Unlikely (GNOME market share) and I can't see why it'd be that important. Platform protocols can be implemented around GTK and as far as I understand GTK is just a vehicle for getting X11/Wayland compatibility, the rendering itself will always be done by Flutter's engine anyway.
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.
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)...
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.
I'm looking forward to the first stable version of Blazor, and a way to combine it with proper native mobile bindings to device APIs. Currently working on a version combined with CapacitorJS and I am in love with the possibilities.
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?
> 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.
I gotta say that I miss some from of let-binding, so I don't have to choose between (a) local variables plus newline-separated statements, including "return", wrapped in {}, and (b) the lovely syntax of `Widget build = (context) => ...`.
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.
> Android Studio, if you use it (i didn't), auto-appends closing bracket comments to keep you visually aware of your nesting.
So does VS Code. I stared writing my first Flutter app a couple of weeks ago. I’m using VS Code and I have to say the IDE support is pretty great.
Regarding syntax and nesting levels, what I don’t is the `git diff` from wrapping the top-most expression in a new class, thus causing everything inside/below it to be indented further, even though only a single class was added. So e.g. wrapping an outer Column in a SingleChildScrollView causes everything inside the column to change in the diff because of added indentation.
From the screenshots and gifs over there I can tell that someone is again forcing people to look at
1) animations
2) grey fonts instead of black
and they are even bragging about it being beautiful.
These also tend to enormously waste screen space.
Are especially those two things configurable by user? I mean - there has to be no animations at all (why does anyone insist on animating theme change? that is just ridiculous), and black text, not grey. If not, that is complete deal breaker. Please tell me I'm wrong and one can configure everything there.
Single word: accessibility.
More words: normal accessibility without needing to re-set whole system to be "accessible" just because one app developer can't behave.
Non-animated changed are offensive to me. Humans are built to track moving things, not a thing instantly disappearing at one point and another, similar looking thing instantly appearing at another place, with no context telling you whether it's actually the same object. This gets worse the larger the state change is.
Similarly information overload is an issue, but of course too little information is as well. That's on the designers, though, you can certainly build information dense apps with Flutter if you want to.
From what I can tell there seems to be a platform multiplier for animations to enable slow motion mode (an important tool for developing good transitions), which I suppose you could just set to 0. And if it doesn't it's just on the developer again.
Basically: I won't deny that it can certainly influence decisions (actually I think it's an important thing to consider), but ultimately it's not really the plattform's fault if a developer decides to make an app you don't like.
Yes, animations really influence decisions. Mainly about using the particular piece of software at all (animations are no go for me and a lot of other people).
Some folks do not have the luxury to spend hundreds of miliseconds to seconds each time they do some action (and believe me or not, they do A LOT of actions per day).
Some people are actually using computers to do stuff as fast as possible so they have fast computers. Having fast computer doesnt automatically mean someone is willing to spend those resources on some eye candy.
Stuff moving around actually increases information overload as it adds to state one needs to track (moving object). To some folks this this even causes problems from medical reasons.
When it comes to information density, this should actually be up to user as well (lets call it compact mode for example) but at least to me it is not as critical as movements. Best would be being able to set "margin sizes" or something like that. And even that should be completely trivial given that no one should really write fixed-widget-position applications these days (i havent done so in ages, i'm using vertical/horizontal containers and spacers).
As should be application color theme as we are/were used to for a loooong time. But I understand that it isn't something Windows users are aware of, since each and every program there forces you to look at completely different interface that behaves in other way and has other ux logic.
I do think we can both agree that being able to stop all and every animation (including fading and whatever else in this category) is very important for user inclusion and accessibility. And since (as you said) slowing those down is needed for their development, "disabling" that feature should already be trivial. It just has to be available to user. Otherwise it's just an arrogant negligence and showing over-supremacy by "i know better what you like to look at".
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
That seems like it would be great, except for that it would still be Canonical's work and with everything they do it would probably be better for everyone if they did not bother.
That's not true, their upstream work for Gnome shell after ditching Unity is very appreciated.
Their announcement also pointedly remarks that the Flutter work will benefit "most distributions" of Linux. That's another good sign that this work won't be too tied up in Canonical's fiefdom.
Really wish Dart was more useful for server development. There’s a lot of missing packages that no one seems to be interested in writing right now though.
I'm a huge fan of Flutter for a number of reasons, but I just tried the demo app Flokk and it doesn't work at all on vanilla Ubuntu 20.04 running Wayland. They actually had this working over a year ago on desktop, not sure how such a massive regression like this made it through.
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.
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.
You do have Webviews but it's stil in an alpha state right now, they have poor keyboard support, no multiple tab support and are not available on anything else than Android & iOS.
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.
You mean the GStreamer bindings? And it would matter—some contributors could choose Rust, but Gnome as a project isn't moving to Rust. What aren't you getting here? Are you going to point at people using C++ or C# next? I'm done with this conversation.
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.
> 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.
> 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.
I like the architecture that Flutter has chosen where the only thing you need from the OS is a canvas and everything is painted by Flutter. It gets you a good programming model and predictable results regardless of target.
The downside is that in order to produce iOS or Android looking UIs someone needs to create every iOS and Android standard widget, with the same behaviour. If those widgets change in future versions of the OS, or new ones are created then more work needs to be done.
This is fine in the current project setup - the work is worth it to Google, but without a corporate backer that's the sort of thing that will fall behind.
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.
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.
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.
javax.* is copyrighted and is now copyleft if you use the jakarta.* namespace instead.
as for java.* I don't see how one could have issues, for example Kotlin use and extend the java standard library without any lawsuit. I believe that the issue was that Android devs copy pasted copyrighted code and putted them in their own reimplementation of the jdk without respecting the original authors. Their reimplementation (dalvik & ci) is the root of all evil and is technically a mess with antic java support. It's such a shame that we can't have ZGC or senandoah on android...
> I believe that the issue was that Android devs copy pasted copyrighted code and putted them in their own reimplementation of the jdk without respecting the original authors.
Your belief is firmly incorrect. The "copied code" claim was for a 9-line rangeCheck function and was otherwise dropped. The main claim is entirely that the java.* API definitions are copyrighted, and therefore Google's clean room re-implementation of the APIs still violates the copyright of the API itself.
The open question at this point is whether a clean-room re-implementation of a copyrighted API for the purposes of compatibility is considered fair use or not. Which so far Oracle has been winning. Which means approximately everything is in copyright violation in the tech world. POSIX, for example, took the API from commercial Unix OS's of the time. The current owners of Unix, Micro Focus, could sue approximately everyone if Oracle wins.
I stand corrected yet while the legal implications are interesting and important the point still is that Android should totally switch to openjdk, end of story.
> important the point still is that Android should totally switch to openjdk, end of story
Not "end of story" at all - why should Android switch? You mentioned ZGC & Shenandoah, but why do you think that would be a benefit? Have you actually tried benchmarking your app in ART vs. OpenJDK? Do you have any clue at all if ZGC would even be an improvement in your workloads, or the workloads of a typical Android app for that matter? There's a lot of really cool work going on in that space, but for example ZGC's NUMA awareness won't do diddly shit for your Android app, so things like that are pretty moot.
Similarly OpenJDK's startup time & memory usage is historically quite bad, because it's just not a primary use case for them in the same way it is for ART. OpenJDK finally got some improvements in those areas very very recently ( https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.ht... ), but it's still not good and far from being obviously superior on all metrics to ART. And ART isn't standing still, either, with new improvements like even faster incredibly fast FFI support: https://android-review.googlesource.com/c/platform/art/+/132... Which is important for achieving things like 120hz 2D UI rendering while also running on incredibly slow in-order non-speculating power saving little cores. Which is a use case & scenario OpenJDK has never been asked to deal with nor optimized to handle.
OpenJDK isn't the end-all be-all excellent-at-everything pinnacle here. After all, nobody ever accused a Java desktop application of being fast & responsive.
> OpenJDK isn't the end-all be-all excellent-at-everything pinnacle here.
Indeed, that is why since around 2000 there are multiple JVM implementations, including plenty of them with AOT and JIT cache capabilities.
The now gone WebSphere Realtime JVM already supported importing profiles for their AOT/JIT compilers.
And in what concerns phone devices, Microsoft did it first with their Cloud compiler for MSIL on Windows Store, first with MDIL/Bartok taken from Singularity for Windows Phone 8.x, followed up by the .NET Native toolchain on Windows 10.
Google's marketing is good, but not very influential for those that actually know the Java eco-system and the offerings available across all major vendors.
Also here is the confirmation that they will carry on cherry picking OpenJDK features instead of full compatibility.
" u/dessert_maker: We pick additional OpenJDK APIs for each Android release based on inputs from our developers. Android 11 will support additional APIs from OpenJDK 9. Everyone that is developing in Java and Kotlin should be able to take advantage of these newer additions.
In addition, we have added library desugaring to the build toolchain in Android Studio to make a wide variety of APIs across OpenJDK 8, 9, 10, and 11 available regardless of what version of Android your app runs on.
We expect to add support to the platform for more modern APIs (11,13,14) based on the level of adoption we see from our broader developer community in future versions. As mentioned in last year's AMA, making the overall runtime updatable is something we are thinking about as part of Project Mainline."
So thank you Google for Android Java and like J++, forcing Java library authors to code specifically for Android, or just ignore it and focus on the myriad of JVM compatible implementations instead.
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.
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.
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.
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.
Except that Android team hasn't got the memo, hence Jetpack Composer, and increased adoption of Kotlin multiplatform as a defensive reaction against Flutter hype.
It's not so much that they will drop it but they may loose interest in it and let it die off naturally. It all depends if they can convince enough people to use it. I've not actually seen or used any flutter apps yet. I'm sure they exist if you go looking for them but it's early days. Most stuff out there is not flutter based.
Google needs to work on untangling it from Dart and start actively working on Kotlin support. Dart is actually compiled to native code and the most of the UI stuff is basically written in C++. Kotlin has a native compiler already, so that's not necessarily a show stopper. And given the huge amount of Android Kotlin developers out there, it's kind of an obvious thing to do. Yet they choose not to work on this.
Fixing this would result in a lot of existing developers having an easy transition to flutter that are currently not planning to go there.
The reasons they are not doing this are entirely political and can be summarized as "not invented here".
Kotlin is a problem for them because it's 1) popular 2) the main language for Android development and 3) controlled by a company that is not Google.
Flutter is their attempt to fix this. They can't kill Kotlin because it's popular but they can try to replace it and nudge developers away from it. The problem for them is that Dart is not good enough. It's a hard sell and effectively a downgrade if you are used to Kotlin. They've been trying to fix that by adding features to Dart that are clearly intended to narrow the gap.
Fuchsia exists for the same reason. Yes there are technical reasons for it as well but the real reason is control over the ecosystem. The combined strategy is risky and dependent on the success in the market of their pixel phones. So far this is not looking great. Google convincing OEMs to jump on the bandwagon is going to be very dependent on them being able to launch a fuchsia phone. I'm pretty sure none of the OEMs is keen of having more Google control and oversight. So effectively, Google would have to launch a Fuchsia phone, make sure it becomes popular, and then twist the arms of all their OEMs to abandon Android. Failing to do that would result in a new phone platform with tiny marketshare that users, developers and OEMs can safely ignore. The mere prospect of that is the reason I expect it will never make it to market.
Flutter may or may not survive that decision. What's going to be interesting is what everybody else does. Flutter and react native are so far the two dominant cross platform approaches. React native could get a lot more interesting with things like wasm opening up that space for Kotlin and Swift developers. A lot of Kotlin developers favoring React Native over Flutter would be a big problem for Google.
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.
Flash remains the most productive UI development environment I have had over the past twenty years. Getting graphical apps working on all major platforms is a fabulous achievement by the Flutter folks.
I have no love for what Android has become and where Kotlin is going. The web today feels like a PDF...huge amounts of movement but not necessarily progress.
I hope more than anything that Flutter continues to gain traction. To my mind it is perfectly reasonable for next generation tech to write to the canvas with the latest widgets as long as there is good accessibility support.
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.
