[HN Gopher] Flutter 3
___________________________________________________________________
Flutter 3
Author : tosh
Score : 566 points
Date : 2022-05-11 19:50 UTC (1 days ago)
(HTM) web link (docs.flutter.dev)
(TXT) w3m dump (docs.flutter.dev)
| cercatrova wrote:
| I like and use Flutter myself, I recommend others use it as well
| if you see other comments in my profile, but one thing that
| annoys me is that it feels as if the major updates are coming too
| fast, in a way. As in, they say things like Flutter Web are now
| "stable" but if you actually use them, you'll find that they are
| clearly not stable. Windows was mentioned to be stable in the
| last release, but it too has issues. I am now wary of just how
| "stable" these macOS and Linux versions really are.
|
| I think the marketing is getting ahead of the actual development
| of the framework. If parts are truly not stable, why call them
| stable, if not for wanting Flutter to be in the news cycle every
| so often?
| 5cott0 wrote:
| Figure out JSON de/serialization yet?
| tylergetsay wrote:
| Just make a class and generate helper methods /s
| LocalPCGuy wrote:
| I know this was sarcasm, but sadly, it is one of the better
| ways to handle this.
| [deleted]
| mekkkkkk wrote:
| What do you mean? Dart has decent support for encoding/decoding
| JSON, with revivers or to Maps.
| 5cott0 wrote:
| strongpigeon wrote:
| In case any Flutter engineer/PM is watching this thread, any
| update on when the Material 3 components will be released?
|
| I have an iOS Flutter app that's getting pretty popular in its
| niche, but I'm waiting on the Material 3 components to be there
| to release an Android version.
| [deleted]
| darrenaustin wrote:
| For a list of what is currently available in Flutter 3, as well
| as a roadmap of upcoming features, see the M3 umbrella issue:
|
| https://github.com/flutter/flutter/issues/91605
|
| Feel free to upvote any issue that you would like to see
| prioritized, as it helps us with planning.
| mhoad wrote:
| That was part of the release today I believe.
| strongpigeon wrote:
| Maybe I missed it? It seems like they got some working but
| got a bunch on their roadmap still [0]. I just talked to
| someone over there and all he could say is that they're
| working on it.
|
| [0] https://github.com/flutter/flutter/issues/91605
| jasfi wrote:
| Flutter is great for cross-platform UIs.
|
| I found it a bit difficult to work with, and I also wanted to
| code my UIs from the back-end. So I wrote DocUI which will be
| released in the next month or two. https://nexusdev.tools
| sfshaza wrote:
| This works for me: https://docs.flutter.dev/development/packages-
| and-plugins/ha...
| scrame wrote:
| croes wrote:
| https://en.m.wikipedia.org/wiki/Flutter_(software)
| mike10921 wrote:
| Cross-platform mobile dev language that uses native widgets as
| opposed to react-native that uses a wrapper around JS.
| Klonoar wrote:
| Errr... hang on there. Last I checked Flutter draws their own
| controls, they're no different than React Native in this
| context.
| dabeeeenster wrote:
| React native controls are native to the mobile platform
| they are running on.
| bogwog wrote:
| There's so much conflicting information in this thread
| Klonoar wrote:
| IIRC this doesn't hold true for everything - e.g, List
| View types aren't backed by a UITableView or
| UICollectionView, so they're subtly different.
|
| Otherwise, yeah, I think you're right. It's been a bit
| since I dug around in RN internals.
| potatoman22 wrote:
| Platform-agnostic applications built with Dart. Kinda like
| Xarmin
| sfshaza wrote:
| Where is that bad link? I'll fix it.
| sfshaza wrote:
| The link is fixed. Thanks
| snickmy wrote:
| Sorry for the very newbie question. Can someone compare this with
| let's say an Electron + React approach ?
| lazypenguin wrote:
| I have an irrational annoyance when projects claim to support
| "desktop UI" but then only have the most trivial of widgets
| commonly used in desktop applications. Where is my tree view?
| Data grid view? Charts? Native file dialog window?
|
| From my perspective, while I'm sure Flutter is wonderful, it fits
| squarely in the "mobile" UI toolkit and "basic" desktop
| application category.
| liquidise wrote:
| With limited resources you have to choose. If flutter focused
| on UI elements before Mac OS + Linux stability, the top comment
| would be "Flutter is a solid option for Windows but without
| Linux or Mac support it is useless."
|
| The flutter team has proven generally capable of developing UI
| elements on mobile across iOS/Android. Getting platform
| stability is a welcome step and i trust them to continue to
| build out the desktop element set.
|
| Flutter has been my go-to for mobile app dev for years and i
| haven't considered returning to react native, pure native or
| cordova since i swapped.
|
| All that being said, i have spent my afternoon debugging an
| issue with Flutter's first-party camera plugin, so it isn't all
| roses.
| kitsunesoba wrote:
| This is a big gripe I have with WinUI. How on earth do you
| create a desktop UI framework that lacks something as basic as
| a tableview/data grid... it's only slightly less bad than a UI
| framework not having a button widget. One should not need to
| import a third party dependency or write your own for something
| so basic.
| gman83 wrote:
| Well I think all of these widgets are available on pub.dev. For
| example, I'm using the charts_flutter plugin:
| https://google.github.io/charts/flutter/gallery.html
| cbracken wrote:
| Hey there! I work on Flutter for desktop. I'm happy to provide
| a little background.
|
| We made a decision early on to focus where those of us who work
| on Flutter could deliver the most value, and for Desktop that
| meant getting the runtimes and platform integration for each of
| the desktop OSes in good shape (international text input,
| accessibility support, rendering performance, etc.) as well as
| core integrations like the menu bar, file chooser dialogs, etc.
| These are things that need to land in the runtime itself and
| are significantly more painful for the community to contribute,
| or author and publish on pub.dev.
|
| We're working on filling in the gaps for widgets that are part
| of the Material spec, and I expect the community to make and
| publish widgets on pub.dev that continue to surprise me; I'm
| blown away time and time again at the beautiful widgets and the
| community continues to produce either in packages or as pull
| requests. You should be able to find community-authored
| packages for treeview, datagrid, and charting on pub.dev today
| in the meantime.
| pavlov wrote:
| I'd love to see a "Back to the Future" desktop UI toolkit that
| has roughly the capabilities of AppKit circa 2003 but in a
| modern language, clean unified API, cross-platform, with
| seamless native UI integration, and of course not carrying
| hundreds of megabytes of Chromium gunk in each app like
| Electron does.
| kitsunesoba wrote:
| That would be wonderful. AppKit is the closest to perfect
| I've found in desktop UI frameworks. If it took some of the
| improvements found in UIKit and was cross platform I'd never
| use anything else.
| SemanticStrengh wrote:
| not carrying hundreds of megabytes of Chromium gunk in each
| app like Electron does. this problem has been solved multiple
| times, see e.g. Tauri
| [deleted]
| nickstinemates wrote:
| who builds desktop applications anymore? it feels weird to say
| but i am starting to like them again after transitioning to
| basically 100% thin client/cloud services for the past 15
| years.
| danans wrote:
| What qualifies as a "desktop application" these days?
|
| Is it any application designed primarily to work on a laptop
| or desktop form factor? A web application like SketchUp would
| qualify.
|
| Is it an application whose code is only stored locally, even
| if they don't work well with a laptop/desktop form factor?
| Any number of native mobile apps would qualify.
|
| What about a PWA that is cached locally but initially loaded
| via a URL?
| nickstinemates wrote:
| I don't consider electron apps or any thin veneer over some
| javascript to be a desktop app.
|
| I also don't consider native phone/tablet apps to be
| desktop apps
| bowsamic wrote:
| I'm confused, do you not use desktop apps?
| TillE wrote:
| How many _new_ desktop apps do you use (first released in
| the past ~5 years or so), and how many of them aren 't
| Electron?
|
| Desktop GUI software is a pretty small niche. The web has
| eaten nearly everything, and games don't use native UI
| stuff.
| SemanticStrengh wrote:
| yes, the only market for new apps would be CLI, games and
| scientific computing/technical niches
| bowsamic wrote:
| The post I replied to implied that the rate of production
| of them is decreasing, and you are claiming this too. I'm
| not convinced about that.
| nickstinemates wrote:
| I did in the early days when the web sucked, then dhtml and
| web2.0 started and I completely swapped. Now I'm starting
| to again. I like them more the web apps. But no one is
| making them anymore
| edko wrote:
| I think a tree view was promised (listed on a presentation)
| when Flutter 2.0 was released, but no details were provided,
| and I haven't heard of it ever since.
| cbracken wrote:
| You might be thinking of this package, authored by Google,
| mostly by people on the Flutter team but it's not an official
| Flutter project (as far as I know):
| https://pub.dev/packages/flutter_simple_treeview
|
| (Disclaimer: I work on the Flutter team.)
| Austin_Conlon wrote:
| Even Apple's own declarative SwiftUI framework looks like it
| trails far behind covering rich, comprehensive AppKit apps: htt
| ps://developer.apple.com/documentation/swiftui/building_a....
| rahkiin wrote:
| You can integrate appkit components into a swiftui app
| though.
| the_duke wrote:
| Despite many maturity issues in practice Flutter is the only
| realistic option for true cross platform UIs that run everywhere.
| Apart from Qt , but the licensing issue is a hindrance. And yes,
| the web backend isn't ideal, but it will improve over time.
|
| I just wish Google had built Flutter on a low level core that
| isn't tied to Dart, so it would be usable from other languages.
|
| Dart isn't horrible and is getting better, but it is still a
| somewhat awkward mish mash of Java and JavaScript, and I don't
| really enjoy using it.
|
| The only reason to use Dart is Flutter, which really hurts
| ecosystem health / library availability and prevents code sharing
| with the backend.
| LocalPCGuy wrote:
| I still maintain that Flutter Web is not production ready. It
| could have a nice niche, like games. But for real apps, it's
| just not as good as web. They are still re-implementing things
| that have existed in the web for ages, and are not going to be
| able to keep up. It's basically good for an applet style usage
| IMO. I'll keep trying it out, I think Flutter is pretty great
| for mobile, even desktop, but every time I use a web app
| example I find issues and just shake my head at what they did.
| mekkkkkk wrote:
| The way it atleast used to be framed is that web is a
| fallback target. Meaning if the target device isn't running
| Linux, Windows, macOS, iOS or Android (unlikely), then hey,
| you can atleast build a _passable_ version that will run in a
| browser.
|
| I don't know if this has changed, but I know only a mad man
| would try to build a proper website in Flutter. It's not the
| tool for the job.
| chrismorgan wrote:
| I've encountered a Flutter web app exactly once,
| https://app.travellerdeclaration.govt.nz/. It was very
| painful. (Part of the pain was related to them using a
| selectable-button style for radio buttons, which isn't
| entirely Flutter's fault, though I bet it contributed to
| that misguided decision; but when there's no scrollbar and
| the Yes/No button you clicked is at the very bottom of the
| visible page--well, that was the position.) When I filled
| it out last year, they had an alternative, vastly better
| accessible version that I think didn't even _require_
| JavaScript, though good luck finding it, since it was
| accessed by an invisible button that Flutter event handling
| made unfocusable. Now that button sets a flag in
| sessionStorage and reloads, and on startup checks for the
| flag and sets flutterWebRenderer = "html", so that at
| least the content is in the accessibility tree, even if
| they still badly reimplement half the stuff the browser
| provides manually (links, focus, scrolling, they even
| damage bits of IME).
| mekkkkkk wrote:
| That was painful indeed! Why you would use Flutter for
| something that seems to be web-only, and on a govt
| website that presumably values accessibility, is beyond
| me.
| LocalPCGuy wrote:
| No, it is 100% being framed as "You can build your app once
| and deploy it everywhere" with everywhere including web.
| It's sorta maddening, IMO. There are certain types of apps
| I could see using Flutter for (basically, ones that would
| lean heavily on canvas anyways, games, drawing, etc.)
| mekkkkkk wrote:
| It's hard to quantify exactly what "everywhere" means,
| but for the vast majority of end-user devices, you'll
| have a more efficient Flutter build target than web.
|
| You're probably right in that they are pushing the "first
| class web target" narrative a bit far, though.
| LocalPCGuy wrote:
| Just to be clear, I used the word everywhere. I believe
| they are quite a bit more explicit in framing it for all
| platforms, including web specifically. It's possible
| we'll see it get there, but I think there is a lot of
| things to do (and undo) to do that.
| mhoad wrote:
| FWIW I kind of agree and I'm a big fan of both Flutter and
| the web in general.
|
| There are a couple of web platform technologies that I think
| are going to take Flutter web from ok to great in the next
| year or two including.
|
| WASM Garbage Collection is going to allow them to move from
| compiling to JS to WASM. They have already built a WASM
| compiler ready to go when it lands.
|
| WebGPU is another obvious one. Flutter is by definition a
| canvas optimised framework rather than strictly DOM based
| (although they support that too as a target). But they should
| be able to get blazing fast canvas rendering with those two
| technologies alone.
|
| The other big one that I think will help them is going to be
| AOM. Lots of the built in browser accessibility stuff was
| built for a DOM based world, the web platform needs better
| primitives to support canvas frameworks too.
| kaba0 wrote:
| Isn't Dart a very JS-like language? I really don't believe
| that compiling to JS would cause any bottlenecks at all,
| like compiling Java to JS is also possible with Google's
| own Closure compiler which produces crazy fast JS output.
|
| Sure, JS is not a good compilation target but if you have a
| sufficiently similar language it is not too hard, and with
| the man-hours spent on JS JIT-compilers these won't be slow
| at all.
|
| Though surely the render codepath could use wasm, but that
| could be written natively as well without a need for GC.
|
| As for WebGPU, I don't think a web app would be okay with
| the latency of compiling shaders. Not sure whether it will
| be needed, or if it can be cached but it is not a trivial
| win either.
| mhoad wrote:
| For the record Dart has something extremely similar to
| the Closure compiler built with the same ideas and
| similar performance AFAIK.
|
| It's totally fine, impressive even and currently runs the
| code producing the majority of their revenue via Ads
| which is all Dart.
|
| But they also recognise (same with Google's Java teams)
| that as the platform landscape is changing WASM with
| garbage collection should be the "next generation" of
| compile targets for the web for those languages for
| performance reasons. Both Java and Dart teams already
| have compilers ready to go once WasmGC is finalised and
| both of those teams are heavily involved in the standards
| team driving the broader effort.
|
| I saw some hints at I/O about them building something
| called "managed languages" into the browser that covered
| both Dart and Java as well which seems to build on top of
| that.
|
| I think this has some broader implications for the JS
| community as a whole for what it's worth where "compile
| to JS" is no longer the only game in town in the near
| future.
|
| As for WebGPU I don't know enough about the internals to
| get real deep on the topic but they already have all
| those problems today but just with WebGL. This too as I
| understand things is just the "next generation" target
| for that code.
|
| They (Flutter team) are also rewriting their entire
| shader pipeline engine from scratch as we speak to take
| advantage of everything they have learned to date.
|
| In short, I believe them when they say it's going to be
| fast and like native.
|
| Edit: I missed your point initially about they could use
| WASM today. They do that also for parts of the code
| already (underlying graphics engine is C++ not Dart) but
| this allows them to move all of the Dart code to WASM now
| too.
| kaba0 wrote:
| Thanks for the informative answer!
| SemanticStrengh wrote:
| > Flutter is by definition a canvas optimised framework Not
| really, flutter has not the resources to develop their own
| 2D renderer so they use the chromium renderer for drawing.
| (Skia). It is canvas-like, everything is canvas-like at low
| level. But flutter like browsers implement retained mode
| rendering which is necessary for being jank free and have
| low energy consumption. Flutter on web canvas cannot
| properly do retained mode rendering.
|
| spoiler, flutter non-web is generally slower than Ionic
| LocalPCGuy wrote:
| CanvasKit still renders to canvas (maybe that's what you
| meant by "canvas-like", but it is still directly drawing
| to an HTML canvas), it just enables Flutter to utilize a
| more advanced feature set than the DOM canvas API. It
| also comes with a 2MB or so download (which is why by
| default it's off on mobile last I checked).
| SemanticStrengh wrote:
| you did not understand my point, canvaskit is skia but
| slower, over wasm. It output to an HTML canvas and HTML
| canvas are immediate mode, they do not have retained mode
| rendering (display lists, occlusion, caching, etc).
| Besides I don't think canvaskit is faster than regular
| HTML canvas. Even if canvaskit might avoid some compute
| that would normally be done at the HTML canvas level,
| canvaskit could implement retained mode rendering but 1)
| it does not 2) it would not really be appropriate because
| of the unstructured API (unlike DOM), 3) the final HTML
| canvas would still behave immediately. As I said, it's
| important to realize that you are rendering skia (html
| canvas) on skia (canvaskit wasm) the amount of overhead
| and rendering duplication is in theory crazy.
| LocalPCGuy wrote:
| Yah, this is a pretty solid list of things that, if they
| all hit and work as we hope they do, it could enable
| building things with tech like Flutter and having it work
| well. I think that's why I generally say FlutterWeb isn't
| production ready and not that it'll never be. I don't care
| for the path they took originally, it feels like a bandaid
| and has a lot of issues. They may get there eventually, and
| I'll be happy to adjust my position when/if they do.
| mhoad wrote:
| I'm betting on Flutter web across a 2-3 year timeframe
| but none of the things I've listed there are conceptual
| ideas that are only going to land in the distant future.
|
| WebGPU and WasmGC are both already implemented in most
| browsers and are currently just behind a flag as far as I
| know.
|
| It doesn't feel like magical thinking to me at all, it's
| a pretty clear path forward IMO.
| LocalPCGuy wrote:
| Oh, I do mostly agree with you that it isn't magical
| thinking. I do think there were some choices made that
| might make it a bit more difficult to switch, but the
| Flutter team has been willing to make big shifts in the
| past.
|
| Personally, I'm not willing to be on Flutter Web right
| now, and as you can see, I still actively dissuade it's
| use as I don't think it's good for the web as it is. But
| that doesn't mean that in a few years I'll think
| differently.
| shroompasta wrote:
| SEO is important for web apps, how do canvas based
| applications deal with that.
| cercatrova wrote:
| Important for web _apps_ or web _sites_? There 's a
| difference, a product's landing page will need SEO,
| definitely, but the app itself, ie app.example.com,
| likely does not need SEO. For example, an easy example is
| Figma. The landing page is built with HTML, CSS and JS,
| but the actual app itself is actually built with WASM
| [0], very similar to the canvas based implementation of
| Flutter apps.
|
| https://www.figma.com/blog/webassembly-cut-figmas-load-
| time-...
| shroompasta wrote:
| I'm not sure there's a good distinction between web apps
| or websites today.
|
| Would you consider Instagram or Twitter a website or a
| web app?
|
| If I type 'IG ${username}' or 'Twitter ${username}' or
| '@${username}' in a search engine, you should expect what
| is to be expected within the first result.
| cercatrova wrote:
| True, if the app needs SEO, then yes it should be built
| with HTML, CSS and JS, and not Flutter which uses a
| canvas element. However, there are many apps where SEO is
| unneeded, such as Figma above (no one will search for
| your company's design files on Google) or other such
| corporate apps, and that's where Flutter comes in handy.
| mhoad wrote:
| SEO is important for websites which for the record you
| 100% should not use Flutter for.
|
| Flutter is a great fit for applications which (and I say
| this as someone who did SEO for fortune 500s for many
| years) aren't really all that relevant for SEO purposes
| and are difficult to index at best.
|
| But the short answer to your question is the
| accessibility object model API is what gets used to
| surface relevant information that could be used by search
| engines along with all the other things that have nothing
| to do with the stuff that sits inside your body tags.
| Like it wouldn't actually be that different IRL.
| jonahx wrote:
| > Despite many maturity issues in practice Flutter is the only
| realistic option for true cross platform UIs that run
| everywhere.
|
| What are your thoughts on flutter vs react native?
|
| (assuming you're only targeting phones)
| mhoad wrote:
| One anecdote that I find compelling here is looking at how
| each of the parent companies think of them.
|
| The majority of Google's revenue is directly tied to their
| Ads platform.
|
| Their mobile app is written in Flutter and the web interface
| is written in Dart (not flutter as flutter web support is
| like around a year old).
|
| Facebook uses React on the web and abandoned react native on
| mobile.
|
| Both are responsible for billions of dollars but only one
| passed the test.
| hunterb123 wrote:
| > Facebook uses React on the web and abandoned react native
| on mobile.
|
| That's not true, FB very much still uses RN on mobile.
| mhoad wrote:
| The Facebook app is not written in React Native. They
| tried it and famously abandoned it no?
| robertoandred wrote:
| No, they abandoned the Facebook app written in html.
| shroompasta wrote:
| If React Native is good enough for Discord, it's good
| enough for a lion's share of applications out there.
| hunterb123 wrote:
| The Marketplace tab in the FB app is written in React
| Native.
|
| The Ads Manager app is written in React Native.
|
| The Instagram app is written in React Native.
|
| The entire FB app is not written in React Native yet, but
| overtime I'd expect more things to be.
|
| The statement that FB "abandoned react native on mobile"
| is demonstrably false.
| toephu2 wrote:
| I don't think the entire Instagram app is written in
| React Native. Only parts of it.
|
| Someone currently on the Instagram team can correct me if
| I'm wrong.
| mhoad wrote:
| If I'm wrong then I'm happy to admit it. I don't follow
| that ecosystem closely and was only going off a few old
| blog posts I remember and everyone making a big deal of
| it at the time.
| kllrnohj wrote:
| It seems unlikely that FB would give up on Litho, which
| is extremely performance focused, to use react native
| instead. Not for their bread & butter flagship news feed
| anyway https://fblitho.com/
| hunterb123 wrote:
| First, both Litho and React Native build on Yoga so
| there's a fair amount of code sharing.
|
| Second, they serve different purposes. Litho will be used
| for FB scale optimization of certain intensive views.
| React Native is used for fast developer productivity. I'd
| wager that RN will be used in most places and Litho is
| used in hot spots sparingly.
| hunterb123 wrote:
| Not GP but my comparison is here:
|
| https://news.ycombinator.com/item?id=31346887
| criddell wrote:
| > Flutter is the only realistic option for true cross platform
| UIs that run everywhere.
|
| Do you really want cross platform _everywhere_? You might want
| it but what you inevitably get is something that is huge and
| just okay everywhere instead of something truly great anywhere.
| Is that a trade off you are happy with as a user?
|
| That said, I do happily use a couple of cross platform
| applications. PyCharm and SublimeText which are great and
| Fusion 360 which is powerful but awful to use.
| SergeAx wrote:
| We really want cross platform on Android and iOS. Windows and
| MacOS are nice to have, why not?
| criddell wrote:
| Who is "we"? As a user I want highly polished, efficient
| apps. That pretty much rules out anything built with a
| cross platform toolkit. (Games are a major exception.)
|
| As a developer, I personally want to make those kinds of
| programs too. I periodically check into the state of the
| cross platform toolkits and frankly they really aren't any
| better than they were a decade ago.
|
| Separating out a UI layer that is unique in each platform
| helps and writing with native toolkits helps, but there are
| still fundamental differences that you can't really
| abstract away.
|
| I think the biggest market for these toolkits is in
| enterprise software. There, lowering development costs
| seems to be more important than anything else.
| mhoad wrote:
| I think this assumption that cross platform UI solutions
| can't be extremely fast is a very strange one.
|
| There have been some bad efforts at this in the past
| which is maybe how you arrived at the conclusion but the
| concept of Flutter is pretty straightforward and not
| dissimilar to games in some sense where you just need to
| push pixels to a screen.
|
| They even have a some game engineers who used to work at
| EA on the team. One even wrote a popular book on it
| https://gameprogrammingpatterns.com/
|
| Like in short, Flutter is going to be fine. It compiles
| to native code that just needs to push pixels to a
| screen, it has a bunch of smart people on it and some
| extremely heavy incentives to get this right.
| criddell wrote:
| They can be fast, but a well written browser based
| solution will usually be slower, use more memory and CPU
| than a well written native app.
|
| Of the toolkits I've looked into (which admittedly are
| mostly on the desktop), Qt is probably the best on that
| front.
| SergeAx wrote:
| As a user, I want native apps with some added value
| compared to web apps. I don't actually care about
| "polished", 60fps and things like that. So we are in a
| different camps.
| mattsolle wrote:
| I thought I would hate Dart since it seems like such a bland
| language but after working in it for a year and a half its
| easily one of my favorites. Its straightforward and tailored
| directly for Flutter's use-cases. It feels like it doesn't come
| with a lot of the baggage you get with other, longer-lived
| languages. It is also incredibly readable without hiding how it
| works behind decades of syntactic sugar. All that to say, I
| definitely see how it can be disliked and I also disliked it
| when I started working with it but it definitely grew on me.
| KronisLV wrote:
| > It feels like it doesn't come with a lot of the baggage you
| get with other, longer-lived languages.
|
| Doesn't this mean that you are currently simply in the sweet
| spot where the language is usable but also not bloated yet?
| As in, it could all change in a decade and therefore isn't an
| intrinsic quality of the language itself, but merely the
| passage of time.
|
| I recall this blog post exploring the possible correlation
| between the age of any programming language and the
| developers' disposition towards it:
| https://earthly.dev/blog/brown-green-language/
| mhoad wrote:
| This might not be obvious in anyway if you're not pretty
| deep in the Dart ecosystem but I've never seen anyone pay
| as much attention about building a good long term language
| as that team.
|
| They put crazy amounts of thought and effort into how they
| evolve it.
|
| Their entire strategy as far as I know was to intentionally
| aim for "boring and predictable" so that no matter how
| large or complicated your application got that you would
| never outgrow it.
|
| Then they built a bunch of really nice tooling and DX on
| top of it.
|
| It's genuinely a pleasure to work with in my experience.
| clumsysmurf wrote:
| I was enjoying the frog book (The Dart Programming Language,
| Gilad Bracha & Erik Meiker) but that was 2015, and now very
| out of date. Its strange to see there is no up to date book
| from major publisher, like the Rust book at https://doc.rust-
| lang.org/book/
| munificent wrote:
| The incentive structures around technical books are pretty
| weird.
|
| Most major publishers pay quite small royalty rates, so
| even a popular tech book won't actually make the author
| much money. And the effort to write a good technical book
| is pretty huge. Also, the set of people who _will_ actually
| finish writing a book is quite a bit smaller than the set
| of people who aspire to. (An editor at O 'Reilly told me
| once that only about 1/3 of the authors they sign deals
| with actually end up finishing the book.)
|
| So for a book to appear, you need to find someone who:
|
| 1. Knows this particular topic in depth.
|
| 2. Is interested in spending a lot of time writing a book
| about it.
|
| 3. For relatively little money in return.
|
| 4. And actually has the discipline to finish it.
|
| Not a lot of people in that set. It's also particularly
| hard for technologies that are in flux since the quicker
| the book gets out of date, the less value there is in
| writing it.
| gnat wrote:
| Former O'Reilly editor here: story checks out. The 1/3
| might be a bit low -- I had some surprises (one guy
| joined the Peace Corps and moved to South America, plus
| usual divorces and deaths and job changes) but it felt
| more like 80% completed. This might be the rosy glasses
| of memory, though.
|
| There's also a weird difference in incentive between
| writing the first edition and working on updates: if the
| author was just after "I wrote a book!" then they already
| have that, and won't be so interested in updating.
|
| If they were made famous and now have a lot of work as a
| result of the first book, they may not have time for it.
| It's quite the delicate dance to get someone else to
| update the book: without the update, sales will drop, but
| 1st edition authors feel weird giving a lot of their (not
| sizable) royalties to someone who didn't write most of
| the text.
| tomrod wrote:
| That is fascinating. As someone who has writing a
| technical book as a life goal, I'd love to ask--do you
| have any insights you'd be willing to share regarding how
| to get started?
| auggierose wrote:
| Pick a topic you know a lot about, or are willing to
| learn a lot about. Start writing.
| munificent wrote:
| Are you already blogging? If not, I would start doing
| that. Writing short form technical articles and sharing
| them is like bootcamp for longer form writing. You'll
| learn the mechanics of organizing thoughts into a linear
| narrative, the discipline to finish, and you'll get
| feedback from readers about what works and what doesn't.
|
| I blogged for a few years (and wrote thousands and
| thousands of comments on Reddit, which was also helpful)
| before I wrote a book.
| FpUser wrote:
| Alternative to (3) - Company that owns a language and is
| willing to pay decent money for someone qualified to
| write a book in order to increase popularity
| munificent wrote:
| Yeah, this is viable, but the cost is quite high if
| you're paying a skilled software engineer for their time.
| The company driving the language can probably spend that
| budget better elsewhere. (For example, on online
| documentation that is more easily incrementally
| maintained and grown.)
| [deleted]
| askonomm wrote:
| There's ClojureDart, which means you can now do Dart and
| Flutter development in Clojure:
| https://github.com/Tensegritics/ClojureDart
| ducktective wrote:
| Anyone has used this? Opinions?
| askonomm wrote:
| It's very new, like, a month or so old, but I'm seeing
| quite a few people experimenting with it already in the
| Clojure community. Roam Research
| (https://roamresearch.com/) has their mobile apps built
| with it.
| asiachick wrote:
| It's not remotely a realistic option. CJK is all second class
| citizen. I just tried their latest demos. Tried to enter Ri Ben
| . It utterly failed. First it's still trying to draw on it's
| own so you get to see some placeholder # while typing. Then, it
| effup and typing n-i-h-o-n kept producing Nihon on this example
|
| https://gallery.flutter.dev/#/demo/cupertino-text-field
|
| As long as they keep insisting on rendering everything
| themselves instead of relying on the OS/DOM Flutter will always
| be a poor choice for UI
| cbracken wrote:
| Thanks for reporting this. IME-based input is super important
| to me -- we only speak Japanese at home. I've filed a bug
| [1].
|
| I manually tested on each of Windows, macOS, Linux, and iOS
| (where I've done a lot of work specific to CJK input) and was
| able to correctly input Japanese, Chinese, and Korean text
| [2], so looks like this is likely an issue specific to
| Flutter's web runtime. I work on Flutter's desktop embedders,
| but if there isn't someone who's a heavy IME user on the web
| team, I'll gladly give em a hand to help get this fixed.
|
| [1] https://github.com/flutter/flutter/issues/103645
|
| [2] https://www.youtube.com/watch/0Bt-c9-h92c
| jackosdev wrote:
| I've had to bounce around from Mac, Windows and Linux for work,
| the main programs I use everyday are all Electron based
| (Postman, VS Code, Spotify etc), they all behave basically the
| same just everything is slower in Windows on my laptop. Egui
| (immediate mode GUI) and Tauri (like Electron but Rust backend)
| have worked well cross platform just messing around with them,
| but I haven't used any big apps yet to know for sure.
| perfopt wrote:
| I tried Flutter in 2020 for a side project but decided not to
| use it. It felt clunky and slow. I later ditched the side
| project also since I decided to not build any mobile Apps for
| now. Maybe I'll revisit Flutter if I ever consider building a
| mobile front end for any side-projects.
| NtGuy25 wrote:
| There's definitely competitors opening up and realizing the
| space is worth the investment. C# Maui for example, especially
| with Blazor, is extremely cross platform as well(including
| web), but it has full party support in C#.
| folkhack wrote:
| > Dart isn't horrible and is getting better, but it is still a
| somewhat awkward mish mash of Java and JavaScript, and I don't
| enjoy using it.
|
| All anecdotal:
|
| I've only met one person who was excited to work with Dart,
| huge Google fanatic/fanboy. Otherwise it's sorta seen as a
| unique language choice that makes other devs go, "oh..."
|
| The Java/ECMA ergonomics are weird, it's hard to find devs who
| have experience with the lang, and due to the language
| popularity there's a lot less community/3rd party deps
| available.
|
| I really tried hard to give it a fair shake back in the day but
| I just ended up sticking with Node (and now +Deno), Typescript,
| or Go if I need performance/types. There are way better
| ecosystems around these and I find the tooling/ergonomics much
| less awkward. Also, if/when I need to hire devs onto my teams I
| will have a _much_ easier time.
|
| Also, I can actually write a serverless function in these tools
| (GCP Functions, AWS Lambda) - as far as I know there's nothing
| like this available for Dart.
|
| ---
|
| EDIT: It's worth mentioning I've only had Dart jammed down my
| throat on the backend (API's, data transforms, jobservers,
| etc). It may be a fine tool in regards with Flutter, but it
| felt like a _really_ awkward tool for where it 's come up in my
| career.
| mhoad wrote:
| Here's one from Google
| https://pub.dev/packages/functions_framework
| folkhack wrote:
| > Google Cloud Functions does not currently provide an
| officially supported Dart language runtime, but we're
| working to make running on Google Cloud Run as seamless and
| symmetric an experience as possible for your Dart Functions
| Framework projects.
|
| It's not natively supported - runs on Google Cloud Run
| instead.
| mhoad wrote:
| I'm not sure what you think cloud functions runs on under
| the hood? But it's cloud run.
|
| You said there were no good backend solutions for
| serverless functions and I'm telling you that is
| incorrect.
|
| I've done a bunch myself, it was actually really
| pleasant.
| sofixa wrote:
| IIRC you can transpile Dart to JavaScript, so technically you
| _can_ deploy it as serverless functions.
| heavyset_go wrote:
| As an early Flutter adopter, the ecosystem was a big problem,
| and while it seems to have progressed, it's still pretty
| anemic compared to other language's ecosystems.
| JyB wrote:
| I may be missing something, but why would you want to build a
| serverless function in Dart? you want a common
| backend/frontend language?
| mhoad wrote:
| This is the entire reason for Node's existence no? Nobody
| who was in the backend space prior to it's arrival was in
| anyway excited about JS running in their servers. Node
| however allowed people with only front end experience to
| make that transition and start writing backend apps / logic
| / functions using the same language and now it's an
| insanely popular project.
|
| Wanting a common backend / frontend language seems like a
| perfectly reasonable goal especially on smaller teams.
|
| Dart has a LOT of catching up to do when it comes to the
| overall size of the ecosystem here to be fair because in
| reality as of right now 90% of the Dart community is just
| Flutter and nothing else.
|
| However, from a straight up language perspective it has a
| lot of big advantages over JS when it comes to writing
| backend code but close to zero momentum / adoption.
|
| It's a space I am currently very interested in personally
| because I feel like I see a path here that is currently
| more or less undiscovered. I would say the "secret" I have
| discovered to making it work thus far is very heavily tied
| to finding the right abstractions / entry points and
| caveating it with just like Node and any other backend
| stack it clearly isn't the right choice for all solutions.
|
| Where I ended up landing was basically:
|
| ===Front End===
|
| Flutter for applications and Lit (different project not
| related to Dart / Flutter but TypeScript is VERY similar
| and a small team can handle both no problems) for websites.
| Flutter in particular if you are looking to do anything
| that isn't JUST web otherwise Lit might be a better choice
| currently for just web but I expect that calculus to
| possibly change in 2-3 years as Flutter's web support
| matures.
|
| ===Backend===
|
| Went all in on Google Cloud stack, skipped K8s and instead
| went with Cloud Run. Only create a gRPC interface in my
| code but take advantage of the API gateway product to pick
| up the following benefits:
|
| - Natively integrates with Google's core service
| infrastructure so my code gets run the exact same way and
| with the exact same benefits as when I use a native Google
| API. This gets me all the same security, monitoring,
| tracing, serving, deployment etc out of the box with zero
| effort on my behalf.
|
| - Working with gRPC over handrolling JSON interfaces is
| night and day when it comes to both performance and
| developer experience. It's just better in every conceivable
| way. I don't write any manual glue code between my front
| and backend. Everything is autogenerated and typesafe.
|
| - Just to continue the gRPC story in general for a second,
| it also addresses one of the bigger limitations of Dart on
| the server which is that small ecosystem. The majority of
| things I need to integrate with now are other Google
| services which is supported both through an official
| autogenerated library (HTTP / JSON transport) but also I
| can just use the proto files Google provides to do a native
| gRPC integration if I wanted to.
|
| It does however also let me think about 3rd party
| integrations in a different way now. Let's take an example
| like Stripe. No native Dart library, no gRPC interface etc.
| One option is to just just HTTP and do it manually but I
| don't want to maintain that. Another low cost idea I have
| found for this kind of scenario is that it doesn't feel
| like a big deal to just break out that functionality into
| it's own service and take one of their well supported
| integration options like Node as an example. Take advantage
| of the fact that the SDK code continues to be maintained by
| Stripe and I only have to pick whatever calls I want and
| drop a gRPC interface on top of it that aligns with
| whatever functionality I want using a well established
| pattern so I don't have to do too much cowboy coding and I
| keep a clean separation of concerns in the process
| (https://martinfowler.com/articles/gateway-pattern.html) in
| practice I haven't had to do this much but if you have a
| lot of 3rd party services you are using that would be
| something to consider.
|
| - Also worth mentioning that making use of Google Cloud's
| API gateway (https://cloud.google.com/api-gateway) also
| get's me a free JSON / REST <-> gRPC gateway for web along
| with a free gRPC-web <-> gRPC gateway which is a necessary
| feature until WebTransport (https://web.dev/webtransport)
| makes native gRPC in the browser a viable option.
|
| - Because I am intentionally aligning myself against
| Google's native service infrastructure (it's pretty similar
| to the K8s one which is where it comes from but the key
| difference here is I don't touch any of the complexity
| myself) I pick up an amazing resource in terms of how to
| actually write and structure my APIs here
| https://google.aip.dev/ which gives me a totally coherent
| set of standards and patterns no matter what I am writing.
| This keeps my entire backend horizontally scalable and
| aligned with all the relevant "cloud native" best practices
| by default.
|
| - Cloud Run and Cloud Native Buildpacks
| (https://buildpacks.io/) get me a incredibly slick CI/CD
| pipeline that takes less than an hour to set up. The
| experience is basically Heroku where I just push code to
| the dev / non-dev / prod branch and everything just works.
|
| - The images I run are tiny, they are just a single binary
| compiled to native x86 code and placed inside a blank
| Docker image thanks to Buildpacks. Google maintains the
| image best practices for me so I never am touching
| Dockerfiles for example. Not only is start up time
| incredibly quickly (meaning I can now safely do scale to
| zero) but runtime performance is also great because
| again... it's native x86 code.
|
| - Managed services for everything else such as Firestore or
| managed Postgres for a DB, managed redis for caching etc..
|
| - The security story is also amazing. Because Dart is a
| Google project and I am staying pretty strictly in the
| Google ecosystem I get signed binaries, signed images, a
| secure build environment, I get SBOMs
| (https://www.cisa.gov/sbom) in my container image (thanks
| to Buildpacks) so I know exactly what is running at any
| given point across time. The Google Build platform and Dart
| are also both converging on the SLSA standard
| (https://slsa.dev/) and will allow me to hit level 4
| compliance by the end of the year. I rarely need a lot of
| 3rd party code dependencies (the difference here between
| Dart and Node in particular is absolutely wild).
|
| - The overall developer experience is also incredible. Dart
| and Flutter's tooling is genuinely first class. As I
| mentioned elsewhere a few times in this thread, Google's
| primary money making venture (Ads) is all Dart and as a
| result they have put a LOT of effort in at this level to
| keep things smooth and predictable. For example when new
| versions of the language roll out I just run a single
| command `dart fix` (https://dart.dev/tools/dart-fix) and it
| just upgrades my code for me with no work on my behalf to
| the latest best practices. There are a whole range of
| features like this that is just one of them but it helps
| demonstrate the kind of thing I am talking about.
|
| - Also keeping with the overall security / DX theme the
| developer onboarding story is also great. I don't have
| Flutter or Dart SDKs on my machine. I set up a VSCode
| devcontainer to create reproducible dev environments that
| just work. That clears up another whole set of potential
| problems for me if I want to do local development but it
| also allows me to sit down at ANY computer now and take
| advantage of Github's Codespaces and without any setup
| required I have a fully remote secure development
| environment.
|
| ===Wrap Up===
|
| That's what fullstack Dart looks like for me currently as a
| solo developer. It get's me an incredibly slick setup that
| rivals most companies out there today. I didn't mention
| this in the post but I was also very intentional about
| building sensible escape hatches if I need to escape the
| GCP ecosystem for some reason. The upgrade path out of
| there is basically all of this can transfer to plain K8s if
| that is your thing and you have the resources to support
| it. I picked open source projects / standards wherever
| possible despite that initially reading as an incredibly
| Google focused stack which it also is to be fair.
|
| Also not covered here is the tension I guess between
| "microserves" and monoliths. I'm doing solo dev work so
| microservices don't make sense to me and I think are also
| just a dumb place to start in general. This let's me
| basically write this super nice combination between the two
| where I have a single API binary that contains multiple
| entry points "services in gRPC lingo" (roughly equivalent
| to "a group of routes in HTTP lingo") that really cleanly
| abstract out into their own thing as required. So for
| example let's say you were building a SaaS application the
| path to go from a single server / deployment running
| multiple "services" that covered everything from the apps
| core functionality to billing to admin stuff and to then
| split them back out into their own independent set of APIs
| (app-api, billing-api, admin-api) is really pretty trivial
| (mostly copying and pasting, no big code changes) and
| because I am using that native GCP service infrastructure
| the integration setup is tiny and not meaningfully
| different to say I wanted to bring in any other Google API
| to my codebase.
|
| But the important part to me here is that it gives me the
| time and space to find those abstractions as needed and not
| have to start there. My previous observations around people
| going from monolith to microservice is that it usually
| means a total rewrite and it's never feasible until things
| are seriously on fire and then it becomes a rush job and
| you end up with even more problems. This keeps the
| conceptual alignment from the start without needing to take
| on the risk and the complexity from day 1. It's a path that
| I think makes sense for everything from start ups to many
| companies doing serious growth numbers and let's you build
| consistent tooling / workflows around that.
|
| Honestly, it's worth exploring. Like I said, this is NOT at
| all a well documented path at the moment but I hope I find
| the chance to write about this more in the future because
| what I found so far has been nothing short of amazing.
| igouy wrote:
| Thank you for taking the time.
| folkhack wrote:
| I don't.
|
| It is one of my arguments against devs trying to bring Dart
| into solutions. Historically, I have had colleagues push to
| use Dart for backend/cloud/automation work which I
| personally disagree with.
| ClumsyPilot wrote:
| > Dart isn't horrible and is getting better, but it is still a
| somewhat awkward mish mash of Java and JavaScript
|
| Sounds like they should have used TypeScript?
| maxloh wrote:
| TypeScript isn't a language that can compile to machine code.
| It must be converted and distributed as JavaScript bundle,
| which is slow compared to Dart.
| michaelbrave wrote:
| I was thinking MAUI(rebranded Xamarin) might be somewhat useful
| with .NET6 coming out. I've been playing with it the last week
| or so, it's quite nice.
| heavyset_go wrote:
| Pretty sure it excludes Linux as a GUI target.
| JamesSwift wrote:
| It has a Skia target (in Microsoft.Maui.Graphics) which is
| theoretically very similar to how Flutter does UI.
| boondaburrah wrote:
| Did they give up on GTK? I remember Suse Linux Enterprise
| in particular shipped with a bunch of nice .NET/GTK apps
| that seemed to work well.
| pjmlp wrote:
| They did. Gtk# hasn't seen updates in ages.
| mhoad wrote:
| For what it's worth Dart is hands down the nicest OOP language
| I've ever used in my opinion.
|
| It's like they took all the good things about JS and Java and
| cut out all the bad parts. What's left is basically Dart.
| toastal wrote:
| > nicest OOP
|
| That's the thing. Dart is useless for my preferred style of
| programming. A modern language without ADTs and pattern
| matching is not even meeting my bare minimum for acceptable
| to use. Not just this, but the docs explicitly said the _don
| 't_ want these basic features.
| mhoad wrote:
| They are building pattern matching as we speak for what
| it's worth. One of the main people designing it is in this
| thread talking about it.
| mhoad wrote:
| Thought this link might actually be more helpful by the
| way if you're interested but Dart team does all of their
| language design in the open on Github which is pretty
| cool and also gives you a lot of context about how things
| end up the way they do.
|
| I also mentioned elsewhere in the thread how impressed I
| was just watching that repo in general for a year. They
| clearly give a shit on a such a deep level about building
| a solid long term language in a way that I was totally
| unfamiliar with say coming from a Ruby background
| previously.
|
| Here is the section on pattern matching specifically
| https://github.com/dart-
| lang/language/tree/master/working/05... and this is the
| design spec itself https://github.com/dart-
| lang/language/blob/master/working/05...
| SemanticStrengh wrote:
| People being pleased with Dart is only because they have not
| tasted better, everything is relative. Kotlin is miles ahead.
| mhoad wrote:
| Yes, of course, everyone who disagrees with me is just an
| idiot who doesn't know better. Excellent discourse.
| SemanticStrengh wrote:
| That's right, my discourse has no argumentative value. I
| do not advance any substance allowing you to agree or
| disagree. It's just a difference at the premise level, I
| have experienced dart and I have experienced Kotlin.
| Learn boths properly (reading the kotlin guide is
| sufficent and can be done in an afternoon) and then you
| will be able to judge if I was wrong or not. From
| experience, the difference is huge and affect every
| aspects/features of the language, without even talking
| about the JVM ecosystem interop.
| mhoad wrote:
| You seem to have a lot of very strongly held opinions in
| this thread that aren't backed up by any evidence other
| than your personal opinion.
|
| It's clear that Flutter wasn't for you for whatever
| reason and you seem to love Iconic which is great but
| obsessively hanging out on this thread and just trying to
| shit all over it at every opportunity you get without
| citing any evidence is weird.
|
| Just go an enjoy Iconic. I don't know why you keep trying
| to pick arguments with everyone here.
| danielvaughn wrote:
| Someone else told him he should disclose that he works
| for Ionic and he's claiming that he doesn't work there. I
| don't buy it, because the CEO of Ionic himself responded
| to me in this thread with some equally dismissive
| comments. Really weird behavior and it makes the Ionic
| team look super thin-skinned.
| SemanticStrengh wrote:
| No, the ionic CEO yesimahunan often comment on HN and
| give generally neutral statements.
|
| I am sick of people ignorance in GUI rendering engines
| and the religious myths they build over native, so I
| actively comment too because online GUI conversations are
| still on a middle age like era. If I wzs tied to Ionic I
| would try to please people, which I don't. In fact Ionic
| communication has often self victimized itself by
| corroborating the native rendering myth in lany of their
| blogs. The internet and HN indeed is a small place and
| seeing the Ionic CEO and one of the only person with
| expertise in 2D GUI renderers (me) on thr flutter 3.0
| announcement is actually, not unlikely. But it surprises
| because on average on the internet, people don't care to
| push depth/accuracy into discussions.
|
| BTW I am capable of pointing flaws in Ionic, the
| documentation on the web is often not up to date, and inn
| general I would much prefer a Kotlin based GUI framework
| (such as jetpack compose) over a JS framework (ionic). I
| am in fact the only person on HN to have an actual
| argument to defend a true Ionic competitor, based either
| on fastuidraw, piet-gpu or gecko but there's no point in
| discussing this given no one could contribute to the
| discussion.
| danielvaughn wrote:
| fwiw I totally agree with your other comment on the
| insanity of CanvasKit. I'm just digging into low-level
| rendering myself, and immediately thought...wait, so
| you're writing in Skia, only to be compiled into WASM,
| feeding into a 2D canvas context, which is rendered
| by...Skia? tf?
| SemanticStrengh wrote:
| Sometimes people must be protected from themselves and
| from the delusions of misinformation. See a recent
| example of people having their lifes ruined because they
| have been fooled by the promise of a crypto stablecoin
| here https://www.reddit.com/r/TerraLuna/ I mean yes
| flutter or newShinyFrameworkX does not cause as much harm
| and it is much more subtle. But the platform does matter.
| We are building user experiences, things that people will
| experience, a LOT. Any non-web solution is much inferior
| in terms of feature completeness/expressivity, and
| conteary to popular belief, is inferior in performance
| and energy efficiency. So yes I might have commented too
| much in this thread but that is a political act in
| essence, trying to advocate for the serious trustable
| solution that receive the most human resources.
| Mertax wrote:
| I think the decision of which cross platform technology to
| use mostly depends on a team's preferred tech stack.
|
| C++ -> QT
|
| C#/.NET -> MAUI/Blazor
|
| JS/Web -> React.Native/Electron
|
| Dart -> Flutter
|
| This is what I think is holding back Flutter -- that it
| wasn't built on an incumbent technology. Because Dart doesn't
| have quite the following, it has to evangelize itself a bit
| more than the other options.
| orthecreedence wrote:
| Rust -> ='[
| nu11ptr wrote:
| gtk-rs
| sharno wrote:
| https://iced.rs/
| ogoffart wrote:
| Rust -> Slint? https://github.com/slint-ui/slint/
| heavyset_go wrote:
| Qt has some pretty good bindings for other languages other
| than C++.
| francisl wrote:
| Kotlin -> Jetpack Compose
|
| > Native Android, Native iOS (KMM) and soon Desktop+Web
| (Compose Multiplatform)
| [deleted]
| SemanticStrengh wrote:
| note that many languages credibly interop with JS/TS
| nowadays
| qalmakka wrote:
| I've used PySide6 recently and I must say it's great, so
| you can also add Python to Qt's side.
| no_wizard wrote:
| What about .NET with MAUI / Xamarin?
| ttcbj wrote:
| I have been developing in Flutter for a few years now, and I
| really enjoy the ecosystem. It is the only mobile development
| environment I have every really enjoyed using.
|
| When I started, flutter worked on mobile, and web support was
| in beta. Now, my app works on iOS/Android/MacOs/Web. If you are
| a small developer with limited resources for cross-platform
| development, its an amazing environment.
|
| As for Dart, it is actually one of the things I like most about
| flutter. I really like the parameter passing/naming syntax. It
| is flexible and expressive. If you are looking for something
| that will challenge all your basic assumptions about what a
| language should be, you'll be disappointed. But if you come
| from any c-syntax background, you will pick it up almost
| instantly, and find a lot of nice ways to make code more
| concise and maintainable that previous languages.
|
| In my experience, Flutter is a great environment for getting
| things done with limited resources.
| busymom0 wrote:
| Is the Web version of Flutter still using canvas? I tried it
| a while back and it was just a canvas rendering everything.
| That makes SEO impossible. It's also useless for
| accessibility/screen readers. Please correct me if I am
| wrong.
| mhoad wrote:
| The answer to both of these things is the accessibility
| object model.
|
| You weren't wrong historically but you aren't right
| currently.
|
| Flutter web including the canvas rendering option has
| proper accessibility as of today AFAIK.
| kevincox wrote:
| But can I copy text? Search the page? Right-click to open
| a link in a private window?
| eloisius wrote:
| But you're still SOL if you want to use an ad blocker,
| right?
| coolspot wrote:
| That's a feature, not a bug. (From Google's perspective)
| divan wrote:
| https://docs.flutter.dev/development/platform-
| integration/we...
| mattste wrote:
| I'm curious if anyone can comment on their experience
| using the HTML renderer.
| CrimsonRain wrote:
| Very slow. Not yet ready for production.
| NonNefarious wrote:
| "I just wish Google had built Flutter on a low level core that
| isn't tied to Dart, so it would be usable from other
| languages."
|
| Exactly. Dart is a deal-breaker. I was tasked with choosing a
| cross-platform development solution, and rejected Flutter
| because nobody at my company (including me) knows Dart or has
| time to learn it. Nor would any contractors we were likely to
| find know it.
|
| After quite a bit of research on other potential solutions, I
| determined (as did a crowded and lengthy thread in this forum)
| that Qt was the only viable one for now.
|
| The recent proliferation of languages has been pretty annoying.
| Google should have at least used Kotlin. Alienating their own
| community of Android developers and making Flutter a pain in
| the ass to integrate into a development organization was dumb.
|
| The other problem people cited with alleged cross-platform
| solutions is the need to write native code anyway if you need
| access to system/hardware resources (Bluetooth, USB, what have
| you).
| CrimsonRain wrote:
| I wrote extensive amount of Dart without even reading
| documentation and any prior Dart experience. Knowing dart is
| never an issue if you know basic Java/Php/JavaScript.
|
| The only thing I really hated about Dart was poor enum
| support. Now that's fixed.
| nmfisher wrote:
| I think that's pretty short-sighted. Dart is hardly an
| esoteric/niche language like Haskell or Futhark, anyone
| familiar with Java/Javascript/TypeScript should be able to
| pick it up in a day or so.
|
| Flutter's performance issues, on the other hand, is a
| separate story.
| tasuki wrote:
| Knowing nothing about Dart, I'd guess learning the language
| itself is not much of a task, but learning the libraries,
| build tools, and the whole ecosystem would take a while.
| busymom0 wrote:
| > Flutter's performance issues, on the other hand, is a
| separate story.
|
| Can you expand on that? I know react native has performance
| issues but does Flutter have it too? Why?
| wiseowise wrote:
| React native has less performance issues, since it uses
| native toolkit.
|
| Flutter draws whole ui by itself: welcome to blinking
| cursor that consumes 5-15% CPU in idle.
| chakkepolja wrote:
| > welcome to blinking cursor that consumes 5-15% CPU in
| idle.
|
| Citation? Flutter draws its own UI but game engines do
| that too.
|
| All code in flutter compiles down to native code.
|
| > React native has less performance issues, since it uses
| native toolkit.
|
| In theory.
| fauigerzigerk wrote:
| _> Citation?_
|
| https://github.com/flutter/flutter/issues/59327
|
| This has been a long-standing issue that has completely
| ruled out Flutter for us. E.g, the Flutterfolio idle
| login screen uses 14% CPU on my Mac. For a while it
| sounded like Google was saying that it can't be fixed.
| But I think they have done some work to address this
| issue. I'll be very interested in finding out whether it
| has been fixed in Flutter 3.
| mhoad wrote:
| I think this might be a bit of an outlier honestly.
|
| Reading the bug report my takeaways were the following:
|
| 1. Here is a specific issue we ran into which to be fair
| is unacceptable in terms of perf but a blinking cursor in
| an otherwise idle application has crazy high CPU usage
| numbers trying to run the animations associated with the
| blinking cursor.
|
| 2. They tried the same thing on Linux and CPU usage was
| 0% so already it appears this is more of a specific mac
| bug rather than some general widespread thing.
|
| 3. Further in the thread a number of potential solutions
| get mentioned and were under development including just
| writing a custom shader to handle the blinking cursor (so
| a solution looks possible)
|
| They just made Mac desktop support stable as of less than
| 24 hours ago for the first time. None of this strikes me
| as that egregious. A whole number of major perf
| improvements have landed since then and it's not even
| clear if this is still an active problem in Flutter 3.
|
| I think trying to extrapolate this one bug into some
| widespread disaster scenario is a mistake.
| fauigerzigerk wrote:
| I don't know if there is a larger issue because this show
| stopping "outlier" has stopped me from exploring Flutter
| any further. I'll give it another try now that a new
| major version has been released.
|
| The question in my mind is whether Flutter is
| consistently and significantly more resource efficient
| than web technologies for my particular use cases.
| busymom0 wrote:
| I don't think that's accurate. Seems like native apps
| have the best performance but Flutter comes a close
| second. React native on the other is much slower:
|
| https://medium.com/swlh/flutter-vs-native-vs-react-
| native-ex...
| Larrikin wrote:
| Flutter and Dart seemed to have been internal tools built by
| engineers looking for an interesting project to spend their
| time on while at Google.
|
| Kotlin swelled up around the limitations of Java 8 in outside
| organizations and took over the ecosystem so Android devs
| could be productive while Google was fighting with Oracle
| kaba0 wrote:
| Java was already open-source at the time so the court
| fight's outcome was meaningless from the view of what
| language to choose.
|
| And Android would have been much better off if they didn't
| fork the whole ecosystem and just used OpenJDK, perhaps
| with an added low-memory GC.
| the_duke wrote:
| To be fair: Dart is relatively straight forward and simple to
| learn.
|
| You should have decently qualified developers be productive
| within a week.
|
| But forcing a new language on people usually doesn't go well.
| NonNefarious wrote:
| Sure, I'm not trashing the language, because I know nothing
| about it.
|
| Our whole dev team is C/C++, with random people who know
| Python and a few other things. I'm the only one who knows
| Swift. They're bright people and not hostile toward new
| ideas, but they're already overtaxed and can't cater to an
| outlier project written in a language no one knows and
| built on a framework no one knows.
| Okawari wrote:
| Speaking from personal experience I found the process of
| using dart to be VERY painless. I'm mostly a web
| developer, but have taken some Java courses in college
| and have dabbled in a bit of C# outside of my normal
| PHP/JS work.
|
| We decided to take on an app project at work. We had made
| one using nativescript-vue, but the experience left much
| to be desired and I wanted to look for alternatives.
|
| A friend had talked favorably about Flutter so I decided
| to install and check it out. Within a few hours, I had a
| pretty good looking MVP of the app we were building (it
| was very basic to begin with). The experience developing
| a Flutter app was really good.
|
| It felt like I already knew the language from the get go.
| It worked pretty much as expected. I only had to google
| things like async/await because dart writes their
| functions like `(arg) async => expr` while javascript
| puts the async before the function `async arg => expr`.
|
| YMMV if you're not using the languages which Dart draws
| inspiration from I guess. But I'dd be surprised if you
| feel you would need to spend significant amount of time
| learning Dart.
| postalrat wrote:
| adwn wrote:
| I really dislike C and C++, but I think your comment is
| needlessly hostile and insulting to C and C++ developers,
| and it doesn't add anything of value to this discussion.
| Please consider rewriting or deleting it.
| curuinor wrote:
| they got clojuredart now, which is still kind of a fly-by-night
| thing but those Roam Research peeps are apparently using it in
| production
|
| https://github.com/Tensegritics/ClojureDart
|
| (and in turn, clojure itself is a highly opinionated thing
| which isn't gonna turn into a blub that everyone uses...)
| qalmakka wrote:
| > Apart from Qt, but the licensing issue is a hindrance
|
| Qt is LGPLv3, which is really a problem only if you plan to
| develop embedded software.
|
| Sure, there are a few GPL v3 modules here and there, but it's
| mostly very specific stuff (virtual keyboards, Wayland
| compositors, ...)
| NonNefarious wrote:
| How is it not a problem if you want to sell closed-source
| software? I guess you can dynamically link desktop
| applications (although I'm not sure how this works in Apple's
| Mac app store), but you can't do that with mobile apps.
| kevin_thibedeau wrote:
| You can use LGPL with closed source so long as you provide
| object files to relink against.
| pjmlp wrote:
| If you to sell closed-source software be a good boy/girl
| and give part of the money pile to Qt developers, so that
| they keep working on Qt.
| jcelerier wrote:
| LGPL is not about dynamic linking, and there are plenty of
| LGPL (and even GPL) apps in the Apple, Android, Mac and
| Windows app stores. Like, Chromium itself is mostly LGPL
| and it's never an issue for electron apps, why would it be
| for Qt ones
| qalmakka wrote:
| I have never seen anyone statically linking Qt anywhere,
| even with a commercial license. The main issue is iOS,
| where it's basically impossible to ship anything (L)GPLv3
| on the app store, but that's due to Apple's lock-in
| policies.
|
| Also, JNI requires you to use DLLs/shared objects, so you
| definitely can use them on Android.
| jcelerier wrote:
| > I have never seen anyone statically linking Qt
| anywhere, even with a commercial license.
|
| from a quick grep on my hard drive, Telegram and
| QBittorrent statically link against Qt on Windows ; my
| own software also does, on all platforms. I assume there
| are others.
| samwillis wrote:
| > Flutter is the only realistic option for true cross platform
| UIs that run everywhere.
|
| I understand that argument but 100% disagree. The _web_ is
| _the_ cross platform that runs everywhere (as in in a browser
| or webview). True it has many issues and some forms of it
| (electron) are not ideal for some use case but I believe it's a
| better platform than flutter in almost every way.
|
| You say "true" cross platform and could argue that the web
| isn't "true" cross platform. But really is anything?
| rplnt wrote:
| > The web is the cross platform that runs everywhere (as in
| in a browser or webview).
|
| I understand that argument but 100% disagree. Development is
| horrible, it's anything but standard, comes with a lot of
| baggage, the performance is atrocious. It doesn't even run
| anywhere, it runs in a browser. A huge, bloated, hungry
| browser.
|
| You say Electron is not ideal, I say it's the worst thing
| that had happened to desktop computers ever. It's bad for the
| planet too. Some argue that without "js on desktop" we
| wouldn't have these amazing apps. I think it's not worth it
| to have those apps if they are built using those
| technologies. They make me miserable every single day. It's
| the only thing that forces me to upgrade my computer. It's so
| bad. Things that were possible 20 years ago are suddenly an
| unachievable goal. Stop it.
| Agentlien wrote:
| I may have very different uses for my PC than you (I use it
| primarily for gaming and my job as a game developer), but I
| find the notion of having to upgrade your PC to run a
| browser-based application very strange.
|
| I am not saying that electron-based apps are generally good
| or efficient. Most of them are frustratingly slow and
| awkward. But this inefficiency rarely seems to be
| constrained by local resources: the apps often stand still,
| consuming barely any resources (CPU time, memory, etc.) and
| taking ages to load each page. At the same time you can
| often visit the same page in Chrome and it will load almost
| instantly.
|
| It is frustrating and I have no idea what is going on, but
| it doesn't seem like upgrading the PC would solve the
| issue.
| chakkepolja wrote:
| Other than what sibling comments said, I have to add that
| flutter is much more approachable for new developers than web
| is. Most widgets are built-in, and development workflow is
| also simpler. This is what I heard from college students.
| radium3d wrote:
| I came here to say this too. Build your app as a website,
| then just use a simple browser window of an app that loads
| your site. Then you only develop in one place, and have
| nothing to compile or build. Hardly ever have to update your
| "app" builds even. This won't replace every app of course
| depending on what you're trying to do and if it requires
| specific hardware features, but I'd say about 99% of apps
| don't need to be native.
| johnywalks wrote:
| This is also how you lose customers.
| radium3d wrote:
| If done properly your customers won't even know.
| MonaroVXR wrote:
| Why? Amazon did this, back in the day, not sure how they
| do it now.
| [deleted]
| mekkkkkk wrote:
| I have yet to see a world in which local file access,
| background services, local notifications, timers, alarms,
| native media controls, etc, works as well on web as in native
| apps. A lot of it is there "in theory", but web tech has the
| achilles heel of only allowing stuff that would be safe to
| have in a random website that some asshat links you on
| twitter.
|
| Of course this is only relevant if that deeper plumbing into
| the OS is needed, and of course it's quickly changing.
| Perhaps the day comes when web apps can truly be first class
| citizens in all major OSes, but it ain't here yet.
| SemanticStrengh wrote:
| You have yet to see a world where people update their
| beliefs more than once per decades. Hybrid native web apps
| are trivial, see e.g. Ionic capacitor plugins
| mekkkkkk wrote:
| I'm well aware of hybrid apps and Ionic. I wouldn't call
| those solutions properly "web" though. They're basically
| only using web tech as a presentation layer, and
| deferring to native plugins to do the heavy lifting when
| required. Very similar to how Flutter does it.
|
| So if your claim is simply that CSS/HTML/JS is capable of
| creating good _user interfaces_ , I'm not arguing against
| it.
| SemanticStrengh wrote:
| > a presentation layer, and deferring to native plugins
| to do the heavy lifting when required
|
| bruh it's not just UI, the JS/TS code is where the
| business logic code is. And anyway the UI is the whole
| point, we are debating UI libraries. But most importantly
| native plugins are _niche_ , you use them very rarely and
| for very specific needs, they occupy generally less than
| 1-5% of the code base. e.g. when you need to access the
| camera or sensors, which you usually don't need and most
| apps don't actually benefit from plugins. I'm not even
| talking about the fact that most of those niche needs are
| generally covered by equivalent modern web APIs (e.g. web
| share) but since plugins are trivial to use, people often
| use them even when a web api already exist.
| miohtama wrote:
| "Everything" working in a web app is unlikely to happen any
| time soon. The security model is so different, though less
| different between mobile and web than mobile and desktop.
| Also the Apple/Safari ecosystem is the new IE and dragging
| down some of the innovation.
|
| However, I believe it might not matter. 95% apps can be
| done as web apps today, especially what comes to boring
| business applications. 5% we can wait for some time.
|
| What comes to Flutter, it can never integrate well within a
| browser as it sufferes from the same issue as Java applets.
| It does not use the web browser native rendering engine and
| widgets will always feel kludgy, have accessibility issues
| and so on. Not a big deal for some apps like games. And
| Google Docs is already using Canvas based rendering so
| seems like Flutter canvas based apps might have hope.
| kaba0 wrote:
| > And Google Docs is already using Canvas based rendering
| so seems like Flutter canvas based apps might have hope.
|
| Well, isn't it the Java applets model as you call it as
| well? But is a colored div that much better of a button?
|
| Though I don't disagree with you, indeed most apps can be
| web-based.
| chrischen wrote:
| That plumbing is there and easily doable, but up to
| Apple... just like how the proliferation of QR codes in
| America didn't happen until Apple decided to include it in
| the camera app. It (QR codes) was widely used for maybe
| almost a decade in China due to inclusion in the ubiquitous
| Wechat app.
|
| However given the app store is a cash cow for Apple I
| highly doubt they'd want to integrate web more deeply.
| busymom0 wrote:
| Notifications is the main one which is still missing (at
| least on iOS, not sure about android). If notifications are
| possible for websites, then it would make web dev so much
| better for vast majority of apps.
|
| Local storage already does a lot of needed data storage
| (though apple has recently made this complicated with their
| auto delete after certain period). Local file access for
| uploads is also now possible on iOS using the Files app.
| rkangel wrote:
| > The web is the cross platform that runs everywhere (as in
| in a browser or webview)
|
| Yes, but the web is crappy system for designing UIs in.
|
| As a community we've got good at designing UIs with web
| technologies (HTML+CSS), because we have no other choice if
| you want to build web-apps. But the level of experience we've
| gained with those tools has hidden the fact that they have
| some real issues - mostly due to the fact that they've
| developed piecemeal over many years. Getting the layout of
| your page to behave correctly under all the circumstances it
| needs to requires a lot of experience with CSS, a lot of
| simple page behaviour we'd now expect as users require adding
| JS sprinkled around (and I'm not talking app logic, just UI
| logic).
|
| I freely admit that I'm not great with CSS - I'm not a web
| developer although I have done some web development. If I do
| any at work (e.g. web UI for embedded device) I need a pro to
| come along and make things look nice. But when I did app
| development in Flutter it took about 2 days to be able to
| build screens that looked good, did complicated dynamic
| behaviour, and behaved reliably regardless of screen size and
| shape.
| geekster777 wrote:
| Interesting, I've had the opposite experience. I'd love to
| develop in native with something like Flutter or React
| Native, but I find CSS to be much easier and more flexible
| to use. The base components always /seem/ flexible enough
| until I want to do something visually complicated like add
| an animation that blurs an image on hover. I know CSS is
| horrendous in consistency, but it's piecemeal development
| has led to it having every UI feature I could really
| want/need now that I've paid the price and met its learning
| curve.
| mhoad wrote:
| For what it's worth CSS is all I knew prior to Flutter so
| the learning curve was a bit weird initially but once you
| start matching concepts you already know like Flutter
| also has "flexbox" for example it was pretty easy from
| there. Also having a strongly typed language with great
| docs is a huge help.
| LocalPCGuy wrote:
| This 100%. Also, Flutter Web is still pretty much an
| abomination (right now), IMO. Sure, it "works". So did Flash.
| (edit: Just wanted to add, I love Flutter for mobile, even
| think desktop might work. Just don't think it's for web.
| Maybe for very specific app types.)
| FpUser wrote:
| >"The web is the cross platform"
|
| Nope, The web is The Platform. And while it offers numerous
| benefits it has plenty of flaws / inability to do some things
| as well.
| bodge5000 wrote:
| I wish this were true, but in my (admittedly limited)
| research I'm not sure it is.
|
| For one, you mention Electron. That targets all desktop
| platforms, but not mobile. Mobile development from webapps is
| absolutely possible, but you need to use something else for
| that. Meanwhile, on the flutter side of things, if you want
| to target desktop platforms, you use flutter. If you want to
| target mobile platforms, you use flutter. There isn't a need
| to learn a whole new framework to target a new platform.
|
| Aside from that, local file storage and offline use can also
| be a bit finnicky with Electron. Absolutely possible, but its
| another thing you have to figure out that Flutter just does
| by default.
|
| If I'm wrong on any of this, please do let me know, I know
| web dev far better than I know Flutter so it'd make my life a
| lot easier, but the above reasons are why flutter hasn't
| budged from my todo list
| hunterb123 wrote:
| I disagree, Flutter is probably the worst choice. React Native
| is the all around best choice for targeting all platforms
| natively, otherwise use pure web tech (Ionic + Electron)
|
| The desktop and web targets for Flutter are laughable in their
| current state. Completely unusable so I consider Flutter to be
| a mobile only platform at this time.
|
| Another downside is Flutter's emulated UI, it doesn't bridge to
| native controls like React Native, it's noticeable on iOS
| especially and will be hard to maintain the fake physics /
| styling.
|
| React Native is ready for production now for all platforms,
| including Windows & Xbox via react-native-windows, Web via
| react-native-web, MacOS via react-native-macos or Catalyst.
|
| Then there's the question as to why would you choose a Google
| only language and framework with their track record.
|
| With React you can use TypeScript or JS, you don't have to
| learn a new language or get locked into a framework.
| the_duke wrote:
| Every experience I had with React Native was truly horrible.
|
| Gigantic, messy JS dependency tree. Constant build breakages
| after minor version updates. Random flakiness. Unmaintained
| or buggy native plugins. Questionable support for issues that
| didn't affect FB.
|
| I wouldn't touch it again.
| terandle wrote:
| Highly recommend trying expo.dev sometime they have come a
| long way in providing support for native modules and take
| care of all that underlying "mess" for you.
| TotempaaltJ wrote:
| I absolutely agree with this. At this point I don't
| really think there's much reason to _not_ use Expo. I
| found setting up RN without Expo absolutely awful, and
| switching to Expo was the only reason I didn't start
| rebuilding my app in Kotlin+Swift.
| hunterb123 wrote:
| There's Expo if you don't want to setup your own stack.
|
| You certainly don't need it though, I have no issue with my
| React Native stack.
|
| Flutter has its share of similar tooling issues, most of
| the time its native things like CocoaPods that affect both
| projects.
|
| RN has a huge amount of plugins, a lot that are very good
| quality. It's up to the dev to pick quality dependencies.
| realusername wrote:
| That's the story with Javascript in general, the tooling is
| just terrible.
|
| This is one of the underappreciated part of flutter, 4
| months of upgrade take me 30min of work and the hot reload
| just works, good luck with that in the JS world.
| hunterb123 wrote:
| I never really have issues with the JS side of things,
| care to elaborate on what specifically is "terrible"?
|
| Generally what breaks RN is the same stuff that breaks
| Flutter, native tooling like CocoaPods, Gradle, etc.
| realusername wrote:
| > I never really have issues with the JS side of things,
| care to elaborate on what specifically is "terrible"?
|
| Packages are usually poorly tested (and the fact that
| it's dynamic language does not help), upgrades are often
| and painful, the tooling is not very stable in my
| opinion.
|
| Before settling for Flutter, I've made a limited version
| of my app in both ecosystem to try both and on the RN
| one, I already had upgrade issues only after a month...
|
| > Generally what breaks RN is the same stuff that breaks
| Flutter, native tooling like CocoaPods, Gradle, etc.
|
| You need much less native tooling in Flutter since almost
| everything is canvas based. Broken stuff on the native
| part is very rare, I can't really remember anything like
| this from the past 3 years. I had to upgrade the graddle
| version once but that's about it.
|
| I have ~30k lines of dart excluding tests and about 15
| lines of Kotlin (and zero in ios), that's the kind of
| ratio we're talking about.
| hunterb123 wrote:
| > Packages are usually poorly tested
|
| Just in general? I don't know of any packages in my app
| that are poorly tested. Simply do not choose dependencies
| that don't meet your standard, whether it's TS or Dart.
|
| > and the fact that it's dynamic language does not help
|
| Most packages nowadays are written with TypeScript or
| Flow. JS itself is fast and stable thanks to the billions
| put into the VMs.
|
| > upgrades are often and painful
|
| You don't have to upgrade. In the early days things were
| more painful, but I've upgraded the past few major React
| and RN versions with no hassle.
|
| > the tooling is not very stable in my opinion.
|
| Seems stable to me since the last couple years.
|
| Personally the apps that Flutter makes are of worse
| quality vs RN apps. Emulated native will always feel
| cheap compared to real OS controls.
| realusername wrote:
| > Just in general? I don't know of any packages in my app
| that are poorly tested. Simply do not choose dependencies
| that don't meet your standard, whether it's TS or Dart.
|
| In general, it's not really part of the js culture. Sure
| you have those very nice packages which have stellar dev
| practices (such as react) but that's far from the norm.
|
| The testing story also feels better with Flutter to me,
| one nice thing about the canvas based rendering is that
| you have very good and useful screenshot testing.
|
| > You don't have to upgrade. In the early days things
| were more painful, but I've upgraded the past few major
| React and RN versions with no hassle.
|
| If you don't upgrade, you're left behind and it will
| become more and more painful to upgrade later. Upgrade
| policies of languages also have to be taken into account
| for the dev time.
|
| > Personally the apps that Flutter makes are of worse
| quality vs RN apps. Emulated native will always feel
| cheap compared to real OS controls.
|
| No mainstream app is using native controls anyways.
| Facebook doesn't, Twitter doesn't, Whatsapp doesn't...
|
| Additionally, if you have a terrible phone, this is where
| Flutter stands out in terms of speed. That's why it's so
| popular in developing countries. On my Galaxy J3 (bottom
| of the barrel of samsung), my app is the fastest app I
| have installed.
| hunterb123 wrote:
| > In general, it's not really part of the js culture
|
| As opposed to the Dart culture? Quite a sweeping
| generalization. There's bad packages in every ecosystem.
| There's really good packages in every system. Pick the
| right ones.
|
| > one nice thing about the canvas based rendering is that
| you have very good and useful screenshot testing.
|
| React you can snapshot test the component tree, as well
| as diff images on each platform.
|
| > If you don't upgrade, you're left behind and it will
| become more and more painful to upgrade later. Upgrade
| policies of languages also have to be taken into account
| for the dev time.
|
| Sure, I update major versions every year or so. Past 2
| years of React Native have been easy.
|
| > No mainstream app is using native controls anyways.
| Facebook doesn't, Twitter doesn't, Whatsapp doesn't...
|
| That's plain false, they for sure do.
|
| > Additionally, if you have a terrible phone, this is
| where Flutter stands out in terms of speed. That's why
| it's so popular in developing countries. On my Galaxy J3
| (bottom of the barrel of samsung), my app is the fastest
| app I have installed.
|
| React Native performs well on older devices as well.
| realusername wrote:
| > As opposed to the Dart culture? Quite a sweeping
| generalization. There's bad packages in every ecosystem.
| There's really good packages in every system. Pick the
| right ones.
|
| Not every ecosystem is created equal, they are better
| testing cultures than dart (such as ruby for example) but
| they are also worse ones and javascript is definitely
| worse at that. Packages you install will be on average
| less tested and less care will be put into the dev
| experience than in some other languages.
|
| They are exceptions of course such as RN & React but they
| are far outside the norm.
|
| > Sure, I update major versions every year or so. Past 2
| years of React Native have been easy.
|
| As with any other JS project, RN and React are not the
| main issue but everything around it is and you certainly
| need extra packages.
|
| > That's plain false, they for sure do.
|
| Have a look at those apps and tell me if they look
| Material (they don't).
| realusername wrote:
| > React Native is ready for production now for all platforms,
| including Windows & Xbox via react-native-windows, Web via
| react-native-web, MacOS via react-native-macos or Catalyst.
|
| All platforms ... except Linux. React-native-gtk is abandoned
| as far as I know.
| hunterb123 wrote:
| You can wrap the React Native Web target in Tauri or
| Electron for Linux.
|
| There's also https://github.com/valence-native/valence-
| native that can use either wxWidgets or Qt.
|
| All in all it's better than the current Flutter web /
| desktop implementation.
| realusername wrote:
| > There's also https://github.com/valence-native/valence-
| native that uses Qt.
|
| There's been more than a year without a commit in this
| project, I'm not going to say it's abandoned yet but
| that's not that far off I guess, good luck with the
| issues you'll encounter.
|
| > You can wrap the React Native Web target in Tauri or
| Electron for Linux.
|
| That's one of the only realistic solution for now in my
| opinion.
| hunterb123 wrote:
| > There's been more than a year without a commit in this
| project, I'm not going to say it's abandoned yet but
| that's not that far off I guess, good luck with the
| issues you'll encounter.
|
| Or it's stable? Look at the codebase, it's a pretty dead
| simple bridge. Make your app open source and all those
| Linux devs you're supporting can help you out!
|
| > That's one of the only realistic solution for now in my
| opinion.
|
| Yup, and you get it for free with if you build your app
| with RN and React Native Web.
| realusername wrote:
| > Or it's stable? Look at the codebase, it's a pretty
| dead simple bridge. Make your app open source and all
| those Linux devs you're supporting can help you out!
|
| Even the simplest bridge needs upgrades, unless you want
| to be stuck with react 16.
|
| > Yup, and you get it for free with if you build your app
| with RN and React Native Web.
|
| That's better than nothing I'd say yeah. That's kind of
| the issue with react native, you need platform-specific
| rendering code and since companies don't really care that
| much about linux desktop it's not really there.
| mhoad wrote:
| Politely, I would point out that the makers of Ubuntu
| have said that as far as they are concerned Flutter is
| the future of desktop app development on Linux and all
| their projects moving forward will be using it by default
| because they believe in it so much.
|
| They just started in Ubuntu 22.04 by rewriting their
| installer (I.e the very first thing users see when coming
| into contact with Ubuntu) to be a Flutter app.
|
| It has proper first class support rather than the hacky
| and unofficial (and possibly poorly maintained)
| workarounds you suggested to do cross platform
| development.
| booi wrote:
| Don't forget native targets for TVs (well android TV at
| least)
| amelius wrote:
| > I just wish Google had built Flutter on a low level core that
| isn't tied to Dart, so it would be usable from other languages.
|
| Any chance that someone will build a transpiler from e.g. Go or
| even Rust to Dart? Or is Dart too exotic to be used like that
| in a practical way?
| skybrian wrote:
| Flutter and Dart have co-evolved to the extent that
| separating them would be difficult.
|
| One problem would be expressing the Flutter API as a Go API.
| For example, Flutter has lots of constructors with lots of
| keyword arguments. Flutter is doing things with keyword
| arguments that would be expressed as props in a React-style
| UI. A similar thing happened with JavaScript and JSX - while
| you _can_ write a React-style UI without JSX, you probably
| wouldn 't want to.
|
| Maybe you could define props using structs in Go, but the
| result would be awkward, particularly because Go doesn't have
| an easy way to bulk-copy fields from one struct to another,
| like you do with spread arguments in JavaScript.
|
| Also consider that Flutter uses class hierarchies extensively
| and Go doesn't have inheritance.
|
| Maybe look at how web development is done in Go when it's
| compiled to WebAssembly. Is that how you'd want to do web
| dev?
| irq-1 wrote:
| > Go doesn't have an easy way to bulk-copy fields from one
| struct to another
|
| FYI, In Go you can embed one struct in another and the
| embedded fields are accessible from the top/parent struct.
|
| https://go.dev/doc/effective_go#embedding
| johnywalks wrote:
| > Dart isn't horrible
|
| Dart is horrible and the sole reason i don't touch Flutter
| zeroc8 wrote:
| What's so horrible about it? It's pretty much on par with
| Java and C#, but feels lighter, generates native Code and
| makes it easier to talk to C libs.
| neoberg wrote:
| not op but Java and C# are horrible, too.
| eweise wrote:
| I don't know the history, but wouldn't Kotlin be a saner
| approach? Better language and at least native to android.
| NonNefarious wrote:
| SemanticStrengh wrote:
| nowadays you can do web programming in KotlinTS
| robertlagrant wrote:
| I quite like Dart. I can't remember what they're called, but I
| remember it has something that lets you declare a stream
| (actually, maybe that's what it's called) that I thought was
| pretty ergonomic.
| fmakunbound wrote:
| > I just wish Google had built Flutter on a low level core that
| isn't tied to Dart
|
| Why did they tie Flutter to Dart anyway?
| mhoad wrote:
| Take a look at this video from the team that talks about this
| exact topic. After watching it initially it became very
| obvious to me why and I agree it was the right choice
| https://youtu.be/J5DQRPRBiFI
| sph wrote:
| I keep hearing this, but none of the cross platform apps I run
| use Flutter. It's all Electron and Qt.
|
| I don't think I've ever seen Flutter in the wild.
| brundolf wrote:
| Or have you, and you just couldn't tell?
|
| (I personally don't know if it's this good, but it's
| plausible)
| folkhack wrote:
| Not OP - but almost all of the Flutter work I've ran into
| is mobile-centric.
|
| If you're looking for cross-platform on the desktop it
| really hasn't been a popular option vs. Electron/Qt.
| qaq wrote:
| Given that "Today, we are excited to announce that
| Flutter is now stable for macOS and Linux, in addition to
| Windows!" thats not surprising
| folkhack wrote:
| Of course, and to be clear I'm excited there are more
| cross-platform options even though I've had a reluctant
| history with Dart.
| brundolf wrote:
| I read "I don't think I've ever seen Flutter in the wild"
| to include mobile, but maybe I misinterpreted
| skybrian wrote:
| They just launched cross-platform desktop support today. Who
| would be using it for desktop apps like Electron?
| epse wrote:
| It has been out for a serious while though, just in a very
| high quality beta. I've personally been using it just fine,
| though for nothing too complicated
| rvz wrote:
| > ever seen Flutter in the wild.
|
| So what is this made in then? [0] Hint it is not Electron.
|
| [0] https://rows.com/download
| jbigelow76 wrote:
| Xamarin?
| topogios wrote:
| The referenced "Rows" application seems to be the
| showcase app "Rows" listed at
|
| https://flutter.dev/showcase
| rvz wrote:
| Exactly.
| sarmasamosarma wrote:
| I have a few apps out there and you can't tell them apart
| from native. They are insanely snappy. Flutter is the bomb.
| wiseowise wrote:
| How's the startup time?
| epse wrote:
| Very limited anecdotal evidence: about the same as native
| apps on my android phone. (measured by counting out loud
| and trying some random apps)
| vesche wrote:
| https://flutter.dev/showcase
| heavyset_go wrote:
| > _Apart from Qt , but the licensing issue is a hindrance._
|
| Most of Qt is available under the LGPL. Some application
| specific libraries are available under the GPL, but there's no
| reason you'd need to use them unless you have special use cases
| that their libraries would make easier to handle.
|
| > _I just wish Google had built Flutter on a low level core
| that isn 't tied to Dart, so it would be usable from other
| languages._
|
| Agreed, I figured that was the direction Flutter was going to
| go, with wrapper APIs for other languages, but it seems it
| never happened.
|
| Dart is okay, but it's not a language I'd choose to write
| anything in. The only reason to use it is because of Flutter,
| as you've said.
|
| In practice, it isn't just UI code that ends up getting written
| in Dart + Flutter, but the entire application and client code,
| excluding things like REST backends.
|
| With Qt's QML, you're very much just writing UIs in QML and
| JavaScript, leaving a clean separation between the UI, core,
| and application and client code.
| NonNefarious wrote:
| We just built a desktop app with QML in a CMake-based Qt
| project, and I've been pleasantly surprised by the
| experience.
|
| Our brief experimentation with Qt Widgets, on the other hand,
| revealed a shocking level of dysfunction in basic UI-layout
| implementation, in what is supposed to be a very mature UI
| toolkit. But it seems that they're basically abandoning
| Widgets at this point, so -\\_(tsu)_/-.
| jcelerier wrote:
| So interesting, even after years of doing QML, layouting
| with widgets makes for me much simpler to get what I want
| adwn wrote:
| > _Our brief experimentation with Qt Widgets, on the other
| hand, revealed a shocking level of dysfunction in basic UI-
| layout implementation, in what is supposed to be a very
| mature UI toolkit._
|
| That matches my experience. Getting Qt Widgets to resize in
| an even remotely sane way proved to be just about
| impossible.
| SemanticStrengh wrote:
| > is the only realistic option for true cross platform UIs that
| run everywhere
|
| wtf.. Ionic/electron is the true cross platform, no debate.
| Flutter web is dog shit.
| danielvaughn wrote:
| Ionic is pretty awful too, though I can't fault them. It's
| just that papering a web interface on top of a native app is
| gonna be a poor experience no matter what.
| SemanticStrengh wrote:
| sounds very unsubstantiated. please examplify, Ionic
| capacitor native support is excellent, in fact you can
| arbitrarilly call the android/IOS SDKs, with or without
| nativescript. You do understand there is no native
| difference between Ionic and flutter right?
| danielvaughn wrote:
| Not sure what kind of substantiation you're looking for,
| but I've been working with Ionic and Capacitor for over 6
| months now, as part of an ongoing client project.
| Previously, I worked with Cordova way back in 2015/2016.
| So I'm familiar with the technology. My comment addressed
| the fact that I'm not criticizing the tech, I'm
| criticizing the overall concept - rendering an
| application inside of a web view as if it's a native app.
| SemanticStrengh wrote:
| I fail to see the issue here > rendering an application
| inside of a web view as if it's a native app.
|
| That doesn't mean anything. A native app doesn't mean
| anything. Native is a ad-hoc property of being the UX
| framework shipped by default on the OS On chromium OS,
| chrome _is_ native. Who cares? What matters are the
| merits of framework x vs framework y. As for the
| graphical charts 1) material design is as well supported
| on the web 2) most apps should not be in material design
| if they want to have a personality.
|
| You said the word awful, don't you have concrete pain
| points?
| the_duke wrote:
| Just a hint: if you work for Ionic it's customary on HN
| to disclose that fact.
|
| Also: what makes a framework "native" for me is that it
| has it's own rendering stack. With webview solutions you
| are still facing cross platform inconsistencies between
| Safari/iOS, Android and Electron.
| SemanticStrengh wrote:
| I am not an Ionic employee, I have zero affiliation. I am
| a hobbyist in GUI rendering libraries technologies, which
| include Skia, blend2d, pathfinder, webrender, piet-gpu,
| etc
|
| > what makes a framework "native" for me is that it has
| it's own rendering stack
|
| lel, the point of react native is exactly that it doesn't
| have its own rendering stack, it defer rendering to
| external rendering stacks (android native lib, swift
| native lib) Flutter and the web are not native and are
| not different. They both have their own custom rendering
| stack, which allow them to improve it. flutter has not
| created its own 2d renderer btw, it uses the chromium 2D
| renderer named skia, in fact android native use the
| chromium 2D renderer since a few versions already. Simply
| because its the fastest to exist.
|
| > With webview solutions you are still facing cross
| platform inconsistencies
|
| crazy how reversed with reality your argument is. React
| native is by design inconsistent, it uses a separate
| library for each platform which result in an impedence
| mismatch of features, performance, and bugs. A webview
| has no inconsistencies between android and electron, it's
| the same chromium behind. Safari is slighly inconsistent
| (webkit) but order of magnitudes less than using a
| completely different library.
| yesimahuman wrote:
| I don't think that's how Ionic developers would describe it
| today. Have you actually used it or Capacitor recently? The
| quality of apps being built on the platform has never been
| higher. (one random example: https://reflect.app)
| danielvaughn wrote:
| I have been working with it recently, yes. Again, I'm
| _not_ criticizing their tech, moreso the underlying idea
| - rendering a webview as if it 's a native app.
| yesimahuman wrote:
| Seeing the quality of apps coming from the community
| especially with the latest updates in Ionic 6, I can't
| agree with your framing at all. The team is highly
| receptive to specific feedback if you have anything we
| should improve or GitHub links
| vially wrote:
| For what it's worth I'm an Ionic developer and I find the
| grand-parent's description pretty accurate. I do like
| Capacitor though, but I think that's mostly because I've
| had to deal with Cordova before.
| SemanticStrengh wrote:
| Please pin point the relevant DX issues so that it can
| get recognition and get fixed
| vially wrote:
| I feel like I'm having a deja-vu. I remember having a
| similar discussion in the past and it turns out it
| happened exactly one year ago when Flutter 2 was
| released:
| https://news.ycombinator.com/context?id=26336657
|
| Every framework has bugs and feature requests that are
| fighting for resources. And the ones affecting you
| _always_ seem more important than the ones that don't.
|
| That being said, the fact that memory leaks in widely
| used components (e.g.: `<ion-img>` [1]) go mostly
| unnoticed both by Ionic developers and by the community
| [2] just doesn't give me confidence in Ionic being a
| framework used to build quality apps. [1]
| - https://github.com/ionic-team/ionic-
| framework/issues/19242#issuecomment-556182556 [2] -
| the issue linked above has 5 upvotes in 3 years and no
| one even bothered to report a separate issue for the
| memory leak in `<ion-img />`, which seems even more
| serious and the developers have been made aware of it
| SemanticStrengh wrote:
| welcome back, about the issue you mentioned, one of the
| original author wrote a blog in how to address it and how
| the issue is related to angular.
| https://github.com/ionic-team/ionic-
| framework/issues/25283 It does make a significant
| difference in profiling though
| SemanticStrengh wrote:
| > the issue linked above has 5 upvotes in 3 years and no
| one even bothered to report a separate issue for the
| memory leak in `<ion-img />`
|
| It looks like you answered yourself, this issue does not
| seem to affect people. Either it is a rare intermittent
| or only happen in very specific configurations, either
| there is a leak but it is negligeable, or shortlived. OR
| maybe this leak cause suboptimal performance but it must
| not be "feelable" although you did a great find, this
| issue has been overlooked and its severity should be
| better investigated. I'd like to remind you that Ionic is
| not the point, Ionic is simply a packaging of good
| practices and optimized components (because yes ion-img
| implement important optimizations over a normal img tag).
| Some might have leaking issues but the point is that you
| can trivially use a standard img tag, or a regular
| react/angular image lazy loading library or even better
| https://chromestatus.com/feature/5637156160667648 The web
| BTW will probably be the first ecosystem to provide
| support for JPEG XL images, which are a significant
| evolution in performance. Compare the discussed
| underinvestigated suboptimality with e.g. this 50% CPU
| increase over a trivial GIF, and mostly ignored/delayed
| https://github.com/flutter/flutter/issues/88858 or even
| https://github.com/flutter/flutter/issues/94205
|
| > Every framework has bugs and feature requests that are
| fighting for resources. relativism has its limits,
| chromium has thousands more human resources than flutter
| and react native devs combined
| gcanyon wrote:
| > only realistic option for true cross platform UIs that run
| everywhere
|
| Depending on your needs, Livecode has you covered.
| https://livecode.com
|
| Runs on Mac, Windows, Linux. Delivers on all three, plus iOS
| and Android. The underlying language is patterned after
| HyperTalk and people either love it or hate it, but I haven't
| seen any other tool where you can open the new installation and
| within 2 minutes deliver single-file executables for three
| platforms. (Disclosure: I build a developer tool for Livecode)
| aa-jv wrote:
| > realistic option for true cross platform UIs that run
| everywhere
|
| I switched from Flutter to JUCE and haven't looked back. Its a
| far better user experience, and a far better developer
| experience too.
|
| People often overlook it, because its pitched as a framework
| for Audio developers, but the work to make a truly operational
| cross-platform GUI has pushed it into 'suitable for normal
| application' territory, imho.
|
| Anyone looking to solve the platform issue would be very wise
| to do a few workbench sessions with JUCE, and to a lesser
| degree, the Godot gaming framework as well. These are perfectly
| cromulant ways to build high-performance, cross platform,
| accessible applications...
| ipnon wrote:
| I was hoping to see better HTML rendering. Using a single canvas
| to render web apps was my one turn off. Flutter is the right
| choice for many apps, but not for apps primarily accessed over
| the Web.
| LocalPCGuy wrote:
| It is not production ready for web and I don't have much hope
| it ever will be. I love it for mobile, even desktop apps. But I
| feel they chose the wrong direction at the beginning for web
| and it's just trying to dig back out of that hole since then.
| amelius wrote:
| Couldn't they just embed Chrome, like Electron did?
| IceWreck wrote:
| For desktop and mobile, Flutter renders over OpenGL, why do
| they need to embed chrome ?
|
| The websites that are exported from Flutter use the HTML
| canvas (used for games, animation, etc) instead of trying
| to generate HTML. This means accessibility and SEO are on
| existent for those sites. GP is complaining about this.
| potatoman22 wrote:
| IMO it's most useful for more compute intensive web apps like
| an image editor.
| simulate-me wrote:
| What's wrong with using a single canvas? It can be faster.
| Google Docs and Figma, for example, use canvas rendering
| slibhb wrote:
| I just checked and Google Docs is not a single canvas. It
| uses a canvas for the text but all the tools and so on are
| good old html.
| mhoad wrote:
| Believe it's a work in progress
| https://workspaceupdates.googleblog.com/2021/05/Google-
| Docs-...
| kevincox wrote:
| Because it destorys native browser features. For example
| find-in-page, hove to see where a link goes. Right click a
| link to bookmark, open in private window or copy the URL. If
| the page has anchors I can get a link to them. If I save or
| print the page it is an image rather than text (with all of
| the above features).
|
| Some of these can be reimplemented easily, some of them with
| effort, but some just aren't possible. Plus the exact
| behaviours depend on what browser you are using, so you can't
| reimplement them because you don't know how the user's
| browser behaves.
|
| For games or image editors this is probably fine. But for
| most apps this is a huge depredation in usability.
| SemanticStrengh wrote:
| no canvas are slower for UIs. The difference is between
| immediate vs retained mode rendering, and the later is order
| of magnitude more energy efficiency and is more performant,
| for well behaving not chaotically changing content.
| dmitriid wrote:
| > What's wrong with using a single canvas
|
| You can't even select and copy text. And canvas is
| inaccessible to screen readers
| wildrhythms wrote:
| FYI there is a SelectableText widget included in Flutter[1]
| but the developer has to explicitly make text selectable
| just like iOS and just like Android apps. Desktop is a
| different story... many text selection paradigms that I'm
| familiar with on desktop (like double-click and hold and
| drag to select whole words) simply don't work right. It's
| not a great experience, but neither is the vast majority of
| non-Flutter mobile apps when it comes to selecting text
| too.
|
| wrt accessibility, Flutter does actually generate elements
| with aria attributes for screenreaders to consume[2].
| You're right that the canvas is inaccessible, which is why
| the aria labels have to be generated adjacent to that.
|
| We're using Flutter for mobile development at my workplace.
|
| [1]
| https://api.flutter.dev/flutter/material/SelectableText-
| clas... [2]
| https://docs.flutter.dev/development/accessibility-and-
| local...
| the_duke wrote:
| For accessibility they create a separate DOM tree just for
| screen readers.
| steve_adams_86 wrote:
| Are there declarative and performant ways to synchronize
| a canvas with a DOM tree? Maybe the answer here is
| obvious but this seems like quite a bit of overhead, both
| for developers and the browser.
| 10000truths wrote:
| Do they need to be synchronized? I can't imagine that a
| screen reader would be sensitive to millisecond-level
| discrepancies between canvas updates and DOM updates.
| steve_adams_86 wrote:
| I'm not concerned about the delay between updates, it's
| the correctness of the DOM and the canvas and managing
| interactions between the two. I might be misunderstanding
| the problem (or lack thereof) because I haven't dealt
| with accessibility and canvas.
|
| When it comes down to it, I have no idea how you'd
| indicate something is selected in the canvas and have a
| screen reader correctly read out the current selection
| from the DOM. Would DOM events communicate to the canvas
| how to modify state, functions to call, etc?
|
| How would you manage focus between the canvas element and
| the rest of the DOM? Apologies if I'm not making sense;
| maybe there's a well known pattern people use for things
| like this.
|
| My understanding of accessibility relies heavily on the
| DOM behaving as a single document, and the idea of a sort
| of meta-document within it which coordinates pieces of
| the documents seems very complex and hard to get right.
| SemanticStrengh wrote:
| at this point you'd better get rid of the canvas
| LocalPCGuy wrote:
| This right here should tell you why you shouldn't use
| Flutter for Web. The Web is pretty great for
| accessibility out of the box until us devs mess it up, we
| shouldn't use a technology that needs to completely build
| it from scratch to get it to work.
| mhoad wrote:
| Just as an FYI that is how the official web spec works
| https://wicg.github.io/aom/spec/
|
| I'm going off of memory here but I think it's
| approximately correct. They were playing around with the
| idea for a while of creating "virtual trees" to handle
| accessibility and ultimately had to abandon it for
| privacy reasons because you would be able to imply that
| anyone who was using the virtual tree was differently
| abled and that was a whole can of worms that couldn't be
| resolved.
| LocalPCGuy wrote:
| I believe the spec you link is a future proposal at the
| moment. And I trust a consortium of folks from a variety
| of browser vendors along with folks from other interests
| over a single product, when it comes to trying to figure
| out a better way to make things more accessible. And
| maybe Flutter can just use AOM in the future when it's
| available in browsers.
|
| As of Feb, 2022:
|
| > While still in draft form within the Web Incubator
| Community Group, the Accessibility Object Model (AOM)
| intends to incubate APIs that make it easier to express
| accessibility semantics and potentially allow read access
| to the computed accessibility tree.
| gitgud wrote:
| Although it may render faster, it comes at a cost, as it
| completely circumvents what browsers are good at.
|
| Flutter is basically just painting pixels on a canvas
| manually, meaning no CSS, no text selection, no text
| wrapping, no responsive elements, no elements without JS
| enabled. Many accessibility tools rely on CSS and text in
| HTML in order to work too.
|
| It's a huge trade-off to make, and something to be aware of.
| LocalPCGuy wrote:
| Heavy emphasis on HUGE tradeoff. Too much for most web
| apps, IMO.
| kolanos wrote:
| Both are pretty disastrous accessibility-wise.
| busymom0 wrote:
| Canvas has accessibility issues for screen readers as well as
| for SEO purposes.
| strix_varius wrote:
| Both Google docs and figma _use_ canvases, but neither of
| them renders the whole app through a canvas.
|
| This is easy to verify - just open up dev tools and look at
| the DOM structure.
| godmode2019 wrote:
| Question: can you write a de-googled flutter app?
|
| Or does it require google services or call home monitoring
| orangecat wrote:
| _Question: can you write a de-googled flutter app?_
|
| Yes, there's several in F-droid. Flutter doesn't use any Google
| services by default.
| smcleod wrote:
| I actively avoid apps built on Flutter - they don't feel or act
| like a native app.
| mleonhard wrote:
| Google Flutter Team: You launched Flutter Desktop and got your
| promotions. Now can you please go back and finish Flutter Mobile?
| Specifically, please add:
|
| - Integration testing [0, 1]
|
| - Location [2]
|
| - iOS dark mode [3, 4]
|
| - iOS keyboard dismiss decoration [5]
|
| - iOS keyboard scroll-to-dismiss mode [6]
|
| - iOS NavigationLink widget [7]
|
| - iOS checkbox widget [7]
|
| - Android camera that doesn't randomly crash (unfixed for 3
| years) [8]
|
| - Android date-time picker (Requested in email to Flutter Team.
| They refused.)
|
| - Usable documentation for Navigator 2.0 [9, 10]
|
| - Debugger visibility into Dart async tasks
|
| - Stop HTTP requests on timeout [11]
|
| - Testing on physical devices for apps that use flavors [12]
|
| - UI inspection tools that don't randomly stop working
|
| EDIT: Added bug links.
|
| [0] https://github.com/flutter/flutter/issues/88549
|
| [1]
| https://github.com/flutter/flutter/issues?q=is%3Aissue+comme...
|
| [2] https://github.com/flutter/flutter/issues/31453
|
| [3] https://github.com/flutter/flutter/issues/48438
|
| [4] https://github.com/flutter/flutter/issues/80860
|
| [5] https://github.com/flutter/flutter/issues/45076
|
| [6] https://github.com/flutter/flutter/issues/57609
|
| [7] https://docs.flutter.dev/development/ui/widgets/cupertino
|
| [8] https://github.com/flutter/flutter/issues/70751
|
| [9] https://github.com/flutter/flutter/issues/69315
|
| [10] https://github.com/flutter/flutter/issues/81610
|
| [11] https://github.com/dart-lang/http/issues/424
|
| [12] https://github.com/flutter/flutter/issues/99607
| [deleted]
| [deleted]
| radiKal07 wrote:
| so much this
| throwawaycuriou wrote:
| How not to get what you want
| mleonhard wrote:
| The only way I will get what I need from Flutter Team is if
| Sundar fixes the company's incentive structure to align
| employee incentives with long-term profitability. I do not
| expect that will happen. But if it did, I would probably
| immediately go back to work at Google and buy Google stock.
| mattsolle wrote:
| I think a lot of these comments are not necessarily valid or
| have been addressed already and we've lost the actual
| productive feedback in the mess.
|
| - Integration testing - This exists and is very commonly used:
| https://docs.flutter.dev/cookbook/testing/integration/introd...
|
| - Location - This 100% should be a core offering, its crazy
| that its not for mobile application.
|
| - iOS dark mode - Flutter supports Dark Mode -
| https://api.flutter.dev/flutter/material/ThemeMode.html
|
| - iOS keyboard dismiss decoration - Not sure on this.
|
| - iOS keyboard scroll-to-dismiss mode - This is trivial to
| setup, just listen on scroll and hide keyboard. You could even
| create a generic handler that can be reused everywhere for
| this.
|
| - iOS NavigationLink widget - Not familiar with this construct
| but easy to build yourself.
|
| - iOS checkbox widget - Totally agree but also easy to build
| directly.
|
| - Android camera that doesn't randomly crash (unfixed for 3
| years) - We've got a couple application that use camera and
| never had this issue.
|
| - Android date-time picker - This has been in for a long time:
| https://api.flutter.dev/flutter/material/showDatePicker.html
|
| - Usable documentation for Navigator 2.0 - I think the updated
| docs on navigation have addressed this issue largely.
|
| - Debugger visibility into Dart async tasks - You can 100%
| debug async tasks.
|
| - Stop HTTP requests on timeout - This exists in Flutter
| https://stackoverflow.com/a/51489701
|
| - Testing on physical devices for apps that use flavors - We do
| this regularly across 5 different flavors on both iOS and
| Android.
|
| - UI inspection tools that don't randomly stop working - Never
| had this happen.
| mleonhard wrote:
| Integration testing supports only running tests inside the
| device. If your test needs to start an API server, then you
| must use the deprecated and broken flutter_driver module. See
| the bug I linked.
|
| Flutter's Cupertino dark mode support is broken. Some text is
| invisible. Some widgets are unusable. Cupertino Dark mode
| theme support is completely absent. See the bug I filed, with
| a comprehensive reproduction with screenshots. It's like the
| dev who added it just decided to stop half-way.
|
| > - iOS keyboard scroll-to-dismiss mode - This is trivial to
| setup, just listen on scroll and hide keyboard. You could
| even create a generic handler that can be reused everywhere
| for this.
|
| Please use an iOS device and notice how nicely one can
| dismiss the keyboard in iMessage, FB Messenger, Instagram,
| etc. Getting that behavior in Flutter requires using a third-
| party package.
|
| The Material date picker is not a date-time picker. Letting
| the user pick a date & time requires a lot of extra code. For
| example, I spent many hours writing a widget that displays
| the date & time and lets one click to change it, like in
| Google Calendar.
|
| See the bugs I linked about Navigator. The docs have multiple
| omissions. I lost a day and a half on them.
|
| Yes, you can debug tasks with a breakpoint. You cannot see
| which async tasks are running. You cannot pause a task. I
| needed to debug concurrent RPC problems and tried using
| print. Unfortunately, print provides no visibility into tasks
| running in standard library code, like timed-out HTTP
| requests that continue running.
|
| You can timeout waiting for an HTTP request to finish, but
| the request still continues in the background. If it's a
| large upload then it can continue for minutes, draining the
| device's battery and transferring data. See the bug I linked.
|
| > - Testing on physical devices for apps that use flavors -
| We do this regularly across 5 different flavors on both iOS
| and Android.
|
| How do you install on iOS? I tried `flutter build --flavor
| staging --release` and then `flutter install` which fails
| saying that I must supply `--flavor`. But when I supply
| `--flavor` it says the parameter is not supported. See the
| bug I linked. I spent a few hours and figured out how to
| first do a Flutter build and then use XCode to build again,
| then use Devices & Simulators to manually install the
| archive. But this requires that I remove the app from the
| device first, which destroys the app state. This makes manual
| testing extra slow. The process is noxious.
|
| Flutter Inspector in Android Studio on macOS breaks 1 out of
| 5 times I try to use it. I often waste a few minutes trying
| to figure out why my code changes did not have the desired
| change on the widget tree. Then I finally realize that the
| widget tree pane is broken and I need to restart Android
| Studio. It's been like this since 2018 through multiple
| upgrades of Flutter, Android Studio, and macOS.
| onli wrote:
| Just an additional note: Integration testing was indeed
| completely broken for a while, with the docs stating
| otherwise. They reworked it a few releases ago and since then
| it works well for us (limited usage, but completely stable
| for what we do with it).
| mleonhard wrote:
| Do you have tests that run on your host machine, can start
| an API server and interact with it, and also drive the
| Flutter app? Or do your tests run on the mobile device?
| onli wrote:
| The tests run on the mobile device, or rather mostly the
| emulator. No API server to interact with (and I would not
| know why?). The shop uses integration tests for three
| things: 1. Testing some migrations 2. Click through the
| app, as part of a release checklist 3. Run crypto
| operation to check multiple plugins for continued
| compatibility.
| sergiotapia wrote:
| We have a react native app and sometimes it fails to build. We go
| to lunch, and come back no code change now it builds.
|
| I'm just sick of the NPM/Javascript bullshit.
|
| Does Flutter avoid all of these kinds of issues? I'm this close
| to scrapping the whole thing.
| mattsolle wrote:
| I worked with React Native for 3 years before jumping over to
| Flutter and this was the biggest reason why I made the switch.
| Its exponentially better on Flutter. The only time builds break
| for the team are when we made a code change that broke it. Its
| consistent and non-flaky (looking at you RN). Not that you
| won't run into the occasional issue but with React Native
| easily 20% of my time developing was "this just stopped working
| and there's no reason why". React Native was configuration
| hell. With Flutter, I haven't struggled with that at all past
| the initial setup.
| V-2 wrote:
| This has been my experience with RN too (admittedly, a few
| years back). So much time wasted on troubleshooting random
| glitches that occur for seemingly unrelated reason. Some
| minor library version update? Boom, your breakpoints no
| longer work. Why? Noone knows. The "turn it off, turn it on"
| approach seems to be the go-to fix in this environment. And
| there's always another surprise around the corner. I can't
| really contrast it with Flutter, because I only toyed with it
| a little bit, but at least the docs were of much better
| quality - and this being a few years back as I said, the fact
| that Flutter was the newer framework (and still provided
| better quality at least in this area) was even more
| pronounced.
| JyB wrote:
| > I'm just sick of the NPM/Javascript bullshit.
|
| Amen
| sgt wrote:
| For mobile apps (not web), I think yes - Flutter solves a lot
| of these kinds of issues. As with any project, don't just
| blindly add a lot of dependencies as they may vary in quality
| and stability, but overall you deal with two things; Dart and
| Flutter, and it's quite refreshing.
|
| Not as good as native, but if you're going to go cross platform
| due to various reasons such as development costs, then it's the
| way to go.
| mekkkkkk wrote:
| I never coded React Native, but I have a lot of experience with
| Flutter. You can definitely run into build issues, but it's
| almost exclusively when doing precarious things like upgrading
| third party packages, SDKs or Flutter versions. As soon as
| you've traversed the depths of dependency hell and it builds,
| it builds without a hitch repeatedly in my experience.
|
| As the framework is maturing there have been some major
| transitions between APIs and project structure. My main app
| that was scaffolded two years ago has had no shortage of duct
| tape fixes and tweaks to especially Gradle/Cocoapods config to
| keep it building.
|
| I guess it's a fair price for what has otherwise been a
| fantastic developer experience. All in all I'd strongly
| recommend it.
| strongpigeon wrote:
| As someone with a lot of Flutter experience, I can second
| this. It usually works pretty reliably until someday you
| upgrade and cocoapods keeps complaining even when you clean
| everything and rebuild.
| radiKal07 wrote:
| Flutter is miles ahead of React Native at least in this regard
| akmarinov wrote:
| No, use native if you want to avoid that
| sergiotapia wrote:
| Dude I'm close trust me.
| matchbok wrote:
| It's easier. Start with iOS.
| MrDresden wrote:
| There is no framework that never has issues.
|
| Flutter has its fair share (and to be fair, so do the native
| toolchains).
| zinclozenge wrote:
| Did dart eventually add sum types? That's basically the one thing
| holding me from trying flutter.
| esprehn wrote:
| Not yet but they're apparently working on it:
| https://news.ycombinator.com/item?id=31346426
| jimip6c12 wrote:
| Is Flutter beginner friendly? (Coming from an advance python
| background)
| kumarvvr wrote:
| Yeah, fairly beginner friendly.
|
| However, it doesn't hurt to know a bit about reactive UI
| concepts.
| livinglist wrote:
| I have been working on a Hacker News client using Flutter, if
| anyone is interested:
|
| https://github.com/Livinglist/Hacki
| mnorris wrote:
| Thanks for sharing! The design looks really slick.
|
| As a hobbyist Flutter developer who hasn't figured out how to
| make Flutter apps look remotely appealing yet, it's been cool
| poking around your code and trying to learn from it. Bloc and
| Cubit look especially interesting.
| livinglist wrote:
| thanks! here's another Hacker News client made with Flutter
| from another dev that has a much better looking UI, but it is
| only available on FDroid. (though you can build it yourself
| for iOS):
|
| https://github.com/Mosc/Glider
| tomatowurst wrote:
| so...anybody using it to build web apps in lieu of react?
| msoad wrote:
| What are big and highly used apps that use Flutter?
| mhoad wrote:
| Google Ads uses it on mobile which is responsible for literally
| billions in revenue.
| mattsolle wrote:
| They have a showcase page that details large brands that use
| Flutter: https://flutter.dev/showcase There's also there own
| website: https://itsallwidgets.com/
| strongpigeon wrote:
| My app [0] isn't big, but it's highly rated and uses Flutter
|
| [0] https://apps.apple.com/us/app/five-three-one/id1560266240
| justinmc wrote:
| Do you have an Android version?
| strongpigeon wrote:
| Not yet. I'm waiting to use the Material 3 components which
| hopefully should be out soon.
| LocalPCGuy wrote:
| Doesn't appear to based on the website, which is just sad
| considering it's almost zero effort to create an Android
| build as well. I'd consider using this app also.
| strongpigeon wrote:
| I could indeed build it for Android, but since I'm using
| the Cupertino components, it would look and feel like an
| iOS app. As I said replying to the parent comment, I'm
| currently waiting on the Material 3 components to be
| available before I do that.
| LocalPCGuy wrote:
| Sounds good, although a bit sad I can't try it out, even
| if it felt more iOS-like. But you gotta prioritize your
| app and what's best for it. Good luck!
| samwillis wrote:
| I believe the Sonos mobile app is Flutter.
| hermanb wrote:
| Philips Hue is fully Flutter since a while now (v4). There were
| issues with (pre-rendering of) animations but those have been
| resolved in Flutter.
| discreteevent wrote:
| Canonical have specified it as the default development tool for
| their apps (e.g. the Ubuntu installer)
| davidkuennen wrote:
| My app[1] has 5 figure daily users (if that's considered
| somewhat big) and is written in Flutter.
|
| I love Flutter. It made all this so much easier.
|
| [1] https://stockevents.app
| terandle wrote:
| Just trying to be honest here, but using this as an example
| on my iPad Pro with magic keyboard... flutter apps do not
| feel great on iOS IMO. Animations have an initial low
| fps/jerkyness to them. Lot of weirdness when trying to use an
| the iPad trackpad, horizontal directions seem to be inverted.
| Scrolling inertia and feel just feels off in general to me.
| I'm sure flutter is great on Android and all but it still
| feels like they have a bit of work to do on iOS in order to
| really cross that uncanny valley gap.
|
| Regardless I'm sure what you have is a great app here so hope
| you don't feel like I'm targeting you or your app directly
| here, and at the end of the day if flutter allows you to make
| your customers happy more power to you and hope it works out
| the best for you.
| strongpigeon wrote:
| Your app looks good! I'm curious, what did you use for the
| charts?
| SebastianKra wrote:
| This is really nice for testing. It uses most of the pretend-
| native components I was interested in.
|
| Right off the bat, I notice stuttering animations everywhere:
| Scrolling, swiping back, etc... This is on an iPhone 13.
|
| In one section, the keyboard opened on top of a text-field so
| I couldn't see what I was typing.
|
| The components are _just_ different enough that I feel
| something is wrong, but for the most part, I can't tell what
| it is.
|
| Then there's a bunch of minor stuff. Switches become slightly
| larger when they change. You cant swipe down modals. You
| can't drag & release over options in the sheet. I feel like
| I'm missing buttons more often.
|
| Overall, I get a vague cheap feel. Not so bad that I would
| outright dismiss the app as a customer, but I would
| definitely look for alternatives.
|
| This isn't a critique of the app. I think all of these issues
| are flutter-related.
| trey-jones wrote:
| Google Home is the first thing that comes to mind.
|
| See here: https://flutter.dev/showcase
| merrvk wrote:
| Home is so buggy on my iPhone, it's strange that it's part of
| the showcase.
| msoad wrote:
| From all those apps Google Home is the only I had to use for
| my Google Wifi router and it crashed a bunch of times!
| trey-jones wrote:
| It's very spotty connecting to my Chromecast as well, but
| the UI is cool!
| strix_varius wrote:
| Google home is my most-hated mobile app. It's slow, janky,
| buggy, and has terrible UX.
| nexus7556 wrote:
| Every action requires waiting. Its so frustrating. Open the
| app, spinner. Click themostat, spinner. Change the
| temperature, spinner. Its so frustrating. I use Home
| Assistant now as my primary home control app.
| msoad wrote:
| I just noticed that. Opening the Settings menu shows a
| spinner! Are they downloading the list of settings items
| from the internet?!!
| kolencherry wrote:
| Nubank's mobile apps are built using Flutter. They're the
| largest neobank in LATAM (>50MM customers).
| lwansbrough wrote:
| Our app probably falls into those categories. Millions of
| downloads between iOS and Android, and has upwards of 50
| different pages.
|
| iOS: https://apps.apple.com/us/app/tracker-network-
| stats/id128769... Android:
| https://play.google.com/store/apps/details?id=network.tracke...
| jzer0cool wrote:
| +1 for Flutter 3 supports the Apple Silicon Mac (aka M1).
|
| I could not get this to run on a Ubuntu VM (arm64) - anyone know
| if this is also working?
| orangecat wrote:
| Works fine for me in Asahi Linux, both Flutter 2.x and after
| upgrading to 3.
| digisign wrote:
| Really using Asahi as a daily driver? Thought it didn't have
| video acceleration yet?
| orangecat wrote:
| Ha nope, just occasionally playing around with it. No video
| acceleration, but still usable for web browsing and
| development. It's amusing to drag a window around and see
| all the CPU cores spike to 100% as they frantically pretend
| to be a GPU.
| fareesh wrote:
| Flutter is great, hope the update doesn't break too much!
| kringo wrote:
| I still can't find, in the docs, there is an open bug/feature
| request to NATIVELY copy/paste from web?
|
| Do they support copy / paste on the web app without using a
| special widget?
| justinmc wrote:
| I'm not aware of any planned/possible way to do copy exactly as
| you would an HTML page with HTML tags, but there's a big
| project to make selection and copying much simpler and more
| powerful (design doc [1], in progress PR[2]).
|
| With that PR it should be easy to just add one SelectionArea to
| the root of your app in order to make everything selectable,
| like it would be on a web page. You don't need SelectableText
| widgets. There's an example of this in the PR [3]. No built-in
| support for multimedia or rich text copying yet though.
|
| Text input fields should already do copy/paste pretty much the
| same as native.
|
| [1] http://flutter.dev/go/global-selection [2]
| https://github.com/flutter/flutter/pull/95226 [3]
| https://github.com/flutter/flutter/pull/95226/files#diff-a90...
| matchbok wrote:
| Kind of crazy all this effort is being put into just
| recreating something that has been around, and works fine,
| for 20 years. What a waste of resources.
| kringo wrote:
| Great initiative. Wondering why can't Google make this a
| priority and make it fast instead of focus on desktop and
| other device support.
|
| Do they know that a ton of devs are not jumping in because of
| this one simple issue and sticking to other frameworks?
| brabel wrote:
| Flutter 3 comes with an upgrade to Dart 2.17 [1], which has quite
| a few improvements as well... including state on enums.
|
| While that's great, I was hoping it would be like in Rust, where
| each enum variant can declare its own state components, but
| unfortunately it seems to be more like Java: same state for all
| variants.
|
| Well, at least there's quite a few other small but useful
| improvements... and they showed how they really listen to the
| community by implementing the new syntax for passing on
| constructor parameters to a super-class... and by improving the
| docs of the 200 most popular packages with lots of examples, as
| requested by the people.
|
| I like how they're listening to the community as well to
| implement meta-programming (like macros) [2] to solve the main
| pain point, currently, in Dart, which is how verbose it is to
| generate code for things like serialization and data types.
|
| Once they get that, Dart will be a really good language to work
| on (it's already quite ok IMO, despite most people, usually those
| who don't actually use it much, hating on it).
|
| [1] https://medium.com/dartlang/dart-2-17-b216bfc80c5d
|
| [2] https://github.com/dart-lang/language/issues/1482
| kaba0 wrote:
| > While that's great, I was hoping it would be like in Rust,
| where each enum variant can declare its own state components,
| but unfortunately it seems to be more like Java: same state for
| all variants.
|
| As much as I like Rust's enums, I think they messed up on the
| naming. Java (and according to your comment, Dart) gets enum
| rights. What Rust has under this name is sum types, which is a
| separate (more expressive) concept and the two only correspond
| with each other in the case of a sum type where each component
| is of a zero-arity type.
| yen223 wrote:
| Rust isn't alone though - Swift's `enum`s are essentially the
| same as Rust's enums.
| the_duke wrote:
| There is no real reason to have basic enums if you have ADTs
| , since those can easily provide everything a plain enum
| gives you.
|
| I guess the name was just a historical artifact.
| SemanticStrengh wrote:
| no the feature you're looking for is sealed classes, see
| e.g. Kotlin. Rust enum variants cannot be externally
| defined classes
| the_duke wrote:
| That's completely orthogonal to ADT vs enum.
| SemanticStrengh wrote:
| Enums enable two things: check current type from union of
| types and exhaustivity check in switch
|
| The former is solved by reflection, the latter by sealed
| classes.
| kaba0 wrote:
| I agree (that's what I meant under the more expressive
| part), though it is a bit more complex with identity in the
| way. Java's enums are also the singleton pattern.
|
| Java recently got ADTs as well in the form of sealed
| classes and records, here an enum would look like this:
| sealed interface Color permits Red, Blue, Green {
|
| } record Red() {} record Blue() {}
| record Green() {}
|
| You can now create as many Red instance as you want, they
| will be "equals" only under equals(), not under ==, while
| the latter is also true for the enum case.
| IshKebab wrote:
| I disagree. "Sum" and "product" types are really really
| unclear names that only make sense if you've studied some
| advanced CS and even then they're bad names - not descriptive
| at all.
|
| Enum is much better - you just enumerate all the values the
| type can be (plus optional associated data).
| munificent wrote:
| _> While that 's great, I was hoping it would be like in Rust,
| where each enum variant can declare its own state components,
| but unfortunately it seems to be more like Java: same state for
| all variants._
|
| Yes, the enhanced enums we shipped in 2.17 are like Java enums.
|
| We are also working on support for pattern matching and
| algebraic datatype-style programming: https://github.com/dart-
| lang/language/blob/master/working/05...
|
| I say "style" here because object-oriented languages like Dart
| can already mostly model sum types using subclasses. What you
| need to get the rest of the way there is basically just:
|
| 1. Sealed types so that the compiler can check for
| exhaustiveness when you match over all of the subclasses.
|
| 2. A nice pattern matching syntax to let you discriminate
| between the subclasses and destructure them.
|
| 3. Ideally, a nice lightweight syntax for defining a sum type
| family as a superclass and set of subclasses, though this is
| relatively less critical.
|
| We're hard at work on this, but pattern matching in general is
| a pretty large feature and retrofitting it into a language
| whose syntax wasn't initially designed around it is a
| challenge.
|
| I'm very excited about macros too. That's another large,
| difficult feature, but one that I hope will provide a _lot_ of
| power to users and make the entire ecosystem more valuable over
| time.
| cercatrova wrote:
| Any thoughts on the freezed package [0]? That's what I use
| currently for ADTs and exhaustive pattern matching on them,
| would be cool to see similar syntax in the official
| implementation.
|
| [0] https://pub.dev/packages/freezed
| munificent wrote:
| It won't be that exact syntax, but, yes, the goal is to
| offer that kind of functionality but integrated more into
| the language.
| IshKebab wrote:
| That feels like quite an awkward way to squash tagged unions
| into a class structure... But maybe it will work. I would say
| special syntax for it probably is critical because defining
| an entire class for each variant does not sound like fun!
| munificent wrote:
| _> That feels like quite an awkward way to squash tagged
| unions into a class structure... But maybe it will work._
|
| It's what Scala and Kotlin do and I think it's a fairly
| natural mapping. (Swift takes a different approach with
| their enums).
|
| _> defining an entire class for each variant does not
| sound like fun!_
|
| If you come at it expecting the brevity of ML, yes, it's
| not. But if you accept that those variants are real classes
| and may also have their instance methods, documentation
| comments on the fields, etc. then the overhead starts to
| feel less onerous.
| tokumei wrote:
| I haven't really had a great experience with Flutter in the past,
| in my opinion I think React Native provides a better user
| experience. Developer experience is okay.
|
| The best experience for users would be a library that handles
| business logic, as well as describes how the UI should be laid
| out, then building native clients that use that library.
| dj_mc_merlin wrote:
| @tosh submits a great amount of posts. Most do not reach a great
| audience but a number do, and he has gained a large amount of
| points in a short time (despite being from 2010 he has only
| started this mass-posting recently). What's that about?
| obert wrote:
| Happy paths not found...
| https://docs.flutter.dev/development/platforms-and-plugins/h...
| sfshaza wrote:
| Fixed! Thanks
|
| It's: https://docs.flutter.dev/development/packages-and-
| plugins/ha...
| smm11 wrote:
| Something Google V3 actually exists?
| umangsh wrote:
| Coming from a django/python background, flutter/dart was easier
| to understand than react/js. It has been fun to work with, esp.
| with Vscode and extensions, on a side project.
|
| Flutter is a mature option for mobile development, esp. for small
| teams developing for multiple platforms.
| mikhael28 wrote:
| I was recently tasked to build a mobile app at my work, that
| would have maybe 5% of the feature-set of our gargantuan web
| product. However, this 5% was mission critical. Coming from
| React-TS, building with Flutter was a bit weird at first (where's
| my CSS???) but the productivity gains came quickly. The Pub
| ecosystem is fairly mature, in that all the third party packages
| are pretty high quality and address most common use cases. Unlike
| npm where there are 10+ solutions for the same problem, there
| will only be one - maybe 2 in Flutter land.
|
| I was very pleased to find out, that Flutter supported web as
| well. Now, it's not as good as mobile yet - some of the
| animations are render blocked by the JS main thread - but it is a
| very nice 'middle' solution to somebody who needs to use the app
| who doesn't have iOS or Android (for example, Surface tablet).
| Also great for internal testing - push up the latest changes to a
| dev web environment, and everyone can test without installing
| APKs or using TestFlight.
|
| In my use case, I was actively discouraged against making
| something that looked beautiful or pretty - the software is
| designed to be spartan, minimalist and essential. Flutter is
| perfect for that.
|
| All in all, Flutter is awesome. Is it the right answer for
| everything? No. But when you only have one developer to spare
| whose job it is to build a mobile app, it's perfect for that. The
| web support is a nice bonus - haven't tried any of the desktop
| stuff yet.
|
| Dart, as a language, is nice. Not spectacular, but certainly
| tidier than Java or JavaScript. I've gotten used to functionality
| programming, so writing everything in classes was jarring at
| first.
| sgt wrote:
| Having used Flutter web in production, I would overall advise
| against it. It can be brilliant for building forms with
| elaborate validation logic - and quickly so, but once the site
| gets heavier and you add more complexity to it, the more issues
| will pop up. There are still major issues they haven't sorted
| out yet like occasional odd behavior with input fields and
| autofocus on Safari etc.
| bugeats wrote:
| I'm also used to functional programming. The only thing I can
| not stand about Dart is that types are coupled to classes. If
| you want to use stateless functions and typed data shapes,
| you're out of luck. Compare this to TypeScript that truly
| allows both paradigms and has a very expressive type system.
| ushakov wrote:
| did they fix the scrolling on iOS?
| scarface74 wrote:
| Yet another reason to avoid cross platform frameworks. They are
| always catching up to the vendor's capabilities.
| discreteevent wrote:
| That is a reason to avoid cross platform frameworks. But
| there are big reasons in favour of using then as well. It's a
| trade-off depending on your use case.
| LocalPCGuy wrote:
| For the vast majority of (mobile) apps, the benefit of being
| able to be built from a single code base outweighs being
| slightly behind vendor capabilities. Particularly things like
| there where it doesn't come up in some apps and relatively
| few people actually notice/care about it in those it does.
| scarface74 wrote:
| Google doesn't think it's own cross platform framework is
| good enough for its own applications
|
| https://9to5google.com/2021/10/10/google-ios-apps-native/
| mhoad wrote:
| This wasn't anything to do with Futter for the record and
| they even called it out in a quote saying that they
| continue to recommend Flutter in that article.
| scarface74 wrote:
| They continue to recommend it for other developers. But
| it isn't good enough for them?
|
| And typical Google
|
| > As part of this shift, Google in July put Material's
| iOS libraries in "maintenance mode."
|
| Who is to say Flutter isn't next? Google has the
| attention span of a coked up teenager.
| LocalPCGuy wrote:
| > The company's official guidance to past developer users
| is to "follow Apple's Human Interface Guidelines and
| consider using modern UIKit components or SwiftUI
| instead." That said, it also plugged Flutter as the way
| to "get a Material look and feel across all platforms."
|
| Doesn't seem like the article you linked accurately
| represents your statement.
| akmarinov wrote:
| Not yet, but they have a beta thing that you can enable to
| smooth that out
|
| > Impeller precompiles a smaller, simpler set of shaders at
| engine build time so that they won't compile while an app is
| running; this has been a major source of jank in Flutter.
| SemanticStrengh wrote:
| if they disable the shader jit it will result in much worse
| performance overall
| karlmdavis wrote:
| From their What's New: " Flutter now supports variable refresh
| rate on iOS devices with ProMotion displays, including iPhone
| 13 Pro and iPad Pro. On these devices, Flutter apps can render
| at refresh rates reaching 120 hz, which were previously limited
| to 60 hz. This results in a smoother experience during fast
| animations such as scrolling. See flutter.dev/go/variable-
| refresh-rate for more details."
| SemanticStrengh wrote:
| can does not mean it will.
| butz wrote:
| Does Flutter have a complete Material UI components
| implementation? I'd prefer to use Flutter for multi-platform
| support over learning new Android Compose and figuring out what
| to do for other platforms later.
| vogtb wrote:
| Yes, there are two default widget packages, Cupertino and
| Material.
|
| https://docs.flutter.dev/development/ui/widgets/material
| mhoad wrote:
| It's built right into it. Both material 2 and 3.
| tylergetsay wrote:
| I'm not sure I can say it's complete but it's better than
| Android in my experience. There's also more built for you
| already, like button styles and page layouts.
| hbn wrote:
| Does anything have a complete Material components
| implementation?
|
| I always got the vibe from Material that it's just a bunch of
| designers pumping out docs for an ideal world, and then the
| various libraries try to implement a bunch of those things as
| they change faster than they can be implemented.
| trulyrandom wrote:
| Indeed. It wasn't that long ago that Material components for
| Android finally got proper support for Material 2 in a stable
| release of the library. But everything started too look too
| nice and consistent, so now we're getting steamrolled with
| Material 3.
| oldgradstudent wrote:
| Any plans to make it possible to embed Flutter in existing
| desktop applications?
|
| Especially for use in plugins to existing said that do not
| control the main event loop?
| sgammon wrote:
| as an early and aggressive adopter of Google tech it was
| completely infuriating to watch them announce Flutter + Firebase
| integration as if it was new or interesting.
|
| that should have been working day 1. maybe day 2. flutter has
| been out for years, and the fact that you can't successfully use
| Google software with Google's other software is starting to be a
| wart they can't excuse because of internal build chain
| differences.
| mekkkkkk wrote:
| Congrats! Flutter is such an amazingly crazy concept that when I
| started my current job it was on the condition that I could learn
| and use it for our app. I'm not regretting it in the slightest.
| In fact I get more impressed with it the more I use it. Great
| job!
| baisq wrote:
| Does anybody know of any good Flutter for Windows applications
| that are worth looking at?
| SemanticStrengh wrote:
| and rendering benchmarks
| cercatrova wrote:
| Rows [0], a spreadsheet app, has its Windows and macOS versions
| built in Flutter. It's quite fast from my usage. The marketing
| video they did for Flutter [1] goes into a little detail as to
| how they did it but they also have a tech talk that goes into
| more detail [2]. Their spreadsheet engine is open source as
| well [3].
|
| [0] https://rows.com/download
|
| [1] https://www.youtube.com/watch?v=OEdQXBUPYOE
|
| [2] https://www.youtube.com/watch?v=fv_mzbEtUmU
|
| [3] https://github.com/rows/swayze
| onphonenow wrote:
| Same question, do they have a reasonable component library on
| windows?
| redsolver wrote:
| There's https://pub.dev/packages/fluent_ui
| robertlagrant wrote:
| Shout out to the Net Ninaja's Flutter tutorial:
| https://youtube.com/playlist?list=PL4cUxeGkcC9jLYyp2Aoh6hcWu...
|
| Just the best. No affiliation.
| Rapzid wrote:
| Can Flutter/Dart dynamically load code yet for apps that need
| plugins?
|
| Love the concept but eyeing it for b2b style apps that need
| extensibility.
| xster wrote:
| Depends on what you mean exactly. But you can split dynamically
| load code (all uploaded at once to the Play Store) via
| https://docs.flutter.dev/perf/deferred-components
| endisneigh wrote:
| Honestly I think browsers (desktop and mobile) will implement
| native apis faster than these things will implement native apis.
|
| TLDR: JavaScript and browser apis will win in the end.
| sarmasamosarma wrote:
| SemanticStrengh wrote:
| It's already the case, Cordova/Ionic has much more native
| plugins than react native and flutter combined!
| https://www.npmjs.com/search?q=ecosystem%3Acordova It's only a
| matter of time before people realize how superior Ionic is, and
| I can't wait for people to realize Ionic is faster and more
| energy efficient too! https://ionicframework.com/blog/ionic-vs-
| react-native-perfor...
| farmin wrote:
| I use Flutter as a way to host a sqlite and business logic and
| render all UI in a local webview for this reason. Just testing
| now, but works OK.
| bschwindHN wrote:
| People are talking about a better developer experience, but
| hardly anyone is talking about the user experience with apps
| built with this tech.
|
| I don't feel it's great, especially on older devices. Take google
| pay, a showcase flutter app. It's a laggy mess on an iPhone SE
| 2016, whereas the "old" google pay ran perfectly fine. On top of
| that, many google apps I use these days will just freeze and stop
| accepting touch inputs. I have no idea if it's all flutter, or
| just the weird stuff google does on mobile platforms, but other
| apps don't suffer from this.
|
| I think flutter is good for a resource-scarce team trying to
| create mobile apps for multiple platforms, but otherwise it
| creates an inferior end product compared to a native app (let's
| please not get into the definition of "native", for iOS and
| Android you know what I mean). For google, who has enormous
| developer resources, I'm not sure why they would ever use it
| themselves unless it's for apps they don't care about.
|
| https://flutter.dev/showcase/google-pay
| Bilal_io wrote:
| Is this really Flutter's fault or is it Google's?
|
| Google doesn't even support its own devices from 2016, so I
| doubt they'd optimize their apps for the iPhone SE 2016.
| retSava wrote:
| Keeping the baseline/core running smooth and efficient helps
| every device and every app, so they don't need to optimize
| for iphone se 2016 per se.
| nexus7556 wrote:
| Its equally bad on Google's flagship Pixel 6 Pro. There are
| three tabs in the gPay app and its about 2FPS as it animates
| between the tabs. Scrolling is janky.
| OmahaBoy69 wrote:
| I'd just like to chip in with my (opposite) experience:
|
| I semi-recently developed an app using Flutter and used an
| iPhone 6, a 6s, and my old Redmi Note 5 as a baseline for
| performance testing. While I'll admit I wasn't doing anything
| particularly graphics heavy (at most: sliding modals and some
| animations), I wasn't able to get things to dip under 60fps on
| either platform.
|
| As for the GPay app, the only performance issue I could notice
| from testing just now was a dropped frame while quickly
| scrolling through the "explore" page. Otherwise it works
| perfectly on my Z Flip 3.
|
| On the other hand - have you considered upgrading devices? I
| always hate whipping out the iPhone 6s (same A9 CPU as your SE)
| because it runs like hot garbage in most cases... a recurring
| theme in the iOS space.
| bschwindHN wrote:
| > I semi-recently developed an app using Flutter and used an
| iPhone 6, a 6s, and my old Redmi Note 5 as a baseline for
| performance testing. While I'll admit I wasn't doing anything
| particularly graphics heavy (at most: sliding modals and some
| animations), I wasn't able to get things to dip under 60fps
| on either platform.
|
| I think that's great if you're testing for performance on
| older phones! Many of them are still quite capable devices. I
| suspect google isn't doing much of this.
|
| > As for the GPay app, the only performance issue I could
| notice from testing just now was a dropped frame while
| quickly scrolling through the "explore" page. Otherwise it
| works perfectly on my Z Flip 3.
|
| That's a pretty modern phone, right? Have you tried it on
| your 6 or 6S?
|
| > On the other hand - have you considered upgrading devices?
| I always hate whipping out the iPhone 6s (same A9 CPU as your
| SE) because it runs like hot garbage in most cases... a
| recurring theme in the iOS space.
|
| I haven't, because I think the OG SE is one of the best
| phones ever made. And I'm not a phone power user in the sense
| that I'm gaming on it, or doing lots of graphically intensive
| things. I just replaced the battery on it after using it for
| 5 years, and it runs everything I want to do perfectly...with
| the exception of google pay and some of google's other apps.
|
| The issue I have with these basic CRUD apps running with tons
| of jank is that they're essentially just a UI with some text
| labels and buttons. For google pay, I want to open it up,
| navigate a list of people, select one, enter a number, and
| press "Pay". A computer from the 80s could do this no
| problem, it's not a graphically or computationally demanding
| thing. Certainly a computer from 2016 (iPhone SE) is up to
| the task, and before the google pay transition to flutter, it
| totally was.
|
| Creating this software that runs slower, with no tangible
| end-user benefits, is simply pushing us towards more e-waste
| as people upgrade their devices unnecessarily.
| kyrra wrote:
| Googler, opinions are my own.
|
| Interesting thread from a year ago may interest you:
| https://news.ycombinator.com/item?id=26333973 (it's a flutter
| lead talking about Google pay).
|
| I'd be interested to know how much the team tests with an
| iphone that old.
| deergomoo wrote:
| I find Google's iOS apps to be thoroughly mediocre and
| frustrating to use, whether they're Flutter or not. They just
| don't behave like iOS apps.
|
| It's even worse when you're in a less common set up, like using
| an iPad with a keyboard case. I can't even use the arrow keys
| to move between search results in the YouTube app.
|
| I know most people don't care, but it's the endless little
| details that make me thoroughly dislike cross-platform
| toolkits.
| [deleted]
| 999900000999 wrote:
| On one hand, I'm excited, on the other hand, I'm using a Flutter
| app right now as essentially a utility for my own personal use.
|
| I'm horrified if I upgrade it everything will break and I'll have
| to commit to fixing it.
|
| Still, I'm very excited about this, I'd argue flutter is what
| react native wanted to be.
| mhoad wrote:
| Not sure if you're new to the Flutter / Dart ecosystem but one
| of the nice advantages that comes as a side effect of having
| "Google scale" backing it is how nice the upgrade experience
| is.
|
| Generally you just run a single command of dart fix and it will
| statically analyse the code and automatically rewrite anything
| that's outdated to use the latest syntax for you.
|
| https://dart.dev/tools/dart-fix
| 999900000999 wrote:
| I'll consider it, but I really really don't want to invest
| more time into fixing things.
|
| Like it's essentially finished. Then again, I can always
| branch it and see what happens.
___________________________________________________________________
(page generated 2022-05-12 23:02 UTC)