[HN Gopher] Flutter 2
___________________________________________________________________
Flutter 2
Author : wstrange
Score : 504 points
Date : 2021-03-03 19:09 UTC (3 hours ago)
(HTM) web link (developers.googleblog.com)
(TXT) w3m dump (developers.googleblog.com)
| singhrac wrote:
| I think a lot of people will compare React (Native) and Flutter
| in this thread, and as someone who has had a positive experience
| with Flutter, I will say that by far the biggest benefits were
| that (a) there's one way to set up a project, dependencies,
| compile, and run, and (b) it mostly just works across
| iOS/Android/macOS (and I guess Windows, which I didn't test).
|
| (a) is so, so big. It is a big part of the reason that Rust, a
| genuinely difficult language, feels inviting. The Flutter
| community is small, but the core tooling (all from Google of
| course) is at least consistent. It's obviously how to include
| packages, it's obvious how to develop, how to run. No need for
| figuring out Babel or includes or Webpack, or whatever people use
| these days.
|
| (b) is really nice because it allows you to get started. Yes,
| it's true that the experience on one platform (web) doesn't seem
| that good, it's the "new Flash" etc. But for someone wanting to
| develop high quality desktop apps, this is it, folks. It works.
| It's not hobbled or just a tech demo, the scaffolding is there.
| Will you have to write custom components? Maybe. But as a
| programmer I don't want to think about packaging and compilation
| and inconsistencies; I want incompatible code to be sandboxed and
| clear (i.e. filesystem access or sound). The runtime should be
| the same.
| stephenhuey wrote:
| Exactly - I didn't have loads of time to spend writing separate
| code for Android and iOS, so Flutter helped me ship faster (see
| my profile).
|
| It was also encouraging to know that if I ever wanted to branch
| out and deploy my app to the desktop on Windows, MacOS or
| Linux, that I would have that choice very soon.
|
| And I'm a long-time pure web guy who prefers mobile-responsive
| web apps most of the time! But if you're going to deploy native
| and don't have the budget for writing code for every platform,
| Flutter to me is a lot easier than the other toolkits out
| there.
| jzer0cool wrote:
| Needing more integration support from e-commerce perspective.
| There are some right ideas like the feel for flash but also some
| wrong ideas here. Maybe requires here a fresh look at what is
| needed which can solve developer and business needs.
| matchbok wrote:
| What a mess - just make Android better please. Nobody uses this
| or wants to learn a new way of building apps. Swift and Kotlin
| are 100x better.
| moneywoes wrote:
| Is React native the way to big for cross platform development?
| danaliv wrote:
| _> Our goal is to fundamentally shift how developers_
|
| I'm tired.
| the-dude wrote:
| There is an app for that : http://tired.com
| pvinis wrote:
| What is that?
| stephc_int13 wrote:
| The sad part of this is that the exact same thing could be done
| with real native code, much better perf and nicer footprint.
| stephenhuey wrote:
| Yes, but to ship my app to both stores, I would have had 2
| codebases if I had done what you're suggesting. It depends on
| whether your goals have a budget for spending that extra time.
| Not everyone is shipping an app that has such performance
| requirements.
| Keyframe wrote:
| I haven't really looked, apart from glancing, into flutter yet.
| Now with desktops and mobile, premise seems interesting. How and
| does it compare to Qt?
| davidkhess wrote:
| My perspective is that Flutter is positioned dead on against
| Qt's QML. I develop mobile and desktop QML applications and
| this seems to be trying to be very competitive with it.
|
| Qt also has a WebAssembly build for QML apps on the web but in
| my experience it has suffered from some of the same issues
| reported here about the Flutter WebAssembly runtime.
|
| Edit: One key difference is Flutter seems to do everything with
| procedural code. QML is based on a declarative DSL plus
| Javascript.
| nullifidian wrote:
| I'm not sure, but I think that you have to use Dart language to
| use Flutter.
|
| Incidentally, I was pretty sure that Dart was dead. Turns out
| it's alive. I'm not sure what it is currently, now that it's
| statically typed, null safe and all. What are Dart's killer
| features?
| Keyframe wrote:
| _What are Dart 's killer features?_
|
| Looks like we're discussing one - flutter?
| nullifidian wrote:
| That's a UI/App framework. I was talking about language
| features.
| ignoramous wrote:
| Interesting how Flutter has evolved from a AR/VR YC company to
| building cross-platform developer tools at Google.
|
| Anyone know the story behind that?
|
| https://techcrunch.com/2012/03/26/flutter-app-webcam-y-combi...
| russellbeattie wrote:
| I think Dart's new way of declaring variables as null safe by
| default is very interesting. If you want a variable to be able to
| hold a null, you have to explicitly say so. It seems a less
| heavy-handed version of how Golang handles nil, and much better
| than the standard way of declaring variables in most any other
| language.
|
| Maybe this is some common language thing I haven't seen before,
| but it seems an "obvious in retrospect" sort of idea.
| itoocode wrote:
| Flutter is winning the race in cross platform development. I have
| been using Flutter for past few days, and I really like the
| package on whole, tools and community. Having used Xamarin and Qt
| in the past, Flutter is a lot easier to learn.
| davidkhess wrote:
| I'm curious, when you refer to Qt, do you mean the QWidget
| application approach or QML? QML is much more like Flutter (but
| is indeed somewhat arcane to learn how to work with).
| itoocode wrote:
| I meant Qml, is much more like Flutter, but I felt the
| learning curve was steeper than flutter.
| tpmx wrote:
| Last time I tested a Flutter-built app on an iPhone X (perhaps a
| year ago) there was still obvious jank in transitions/animations.
|
| I assume most of the showcases mentioned here (WeChat, Grab,
| Yandex Go, Nubank, Sonos, Fastic, Betterment and realtor.com) are
| Flutter-based on Android only?
|
| Is there a well-built Flutter-based iOS app without jank now?
| kyrra wrote:
| (googler, opinion is my own).
|
| The (new) google Pay app on iOS[0] and Android[1] are flutter
| based. I'm on Android, so I don't know it's behavior on iOS.
|
| [0] https://apps.apple.com/us/app/google-pay-save-pay-
| manage/id1...
|
| [1]
| https://play.google.com/store/apps/details?id=com.google.and...
| [deleted]
| technofiend wrote:
| The app works fine although as of today it's still tagged
| Beta in the Google Play store, which may give some people
| pause.
|
| NFC on the other hand is so unreliable as to moot the use of
| Google Pay, which is unfortunate. I really prefer tap-to-pay
| over anything else, but not at the expense of making people
| in line behind me wait as I try various workarounds like
| toggling NFC. I realize there's nothing you can do about it -
| my grumbling is more a warning to folks who (like me) may
| have used it previously on the Pixel 2 and loved it. It's
| problematic in the Pixel 4. :shrug:
| gareim wrote:
| Google Pay on the iPhone XS had so much jank and UI lag when
| I last used it a month ago.
| eseidelGoogle wrote:
| [Flutter Eng. Dir here]
|
| I replied above as well. My team has also not been
| satisfied with the performance of the GPay app on all
| devices. We've been working with the GPay team since
| release and made many improvements in both Flutter and the
| GPay app. I expect there will be an updated GPay app soon,
| with still more performance improvements in the pipeline.
| tpmx wrote:
| Maybe publish a Flutter showcase app on both appstores?
| With Apple's store you'll probably have to jump through
| some hoops to provide some useful functionality, but it
| should be doable.
| matchbok wrote:
| Why can't y'all just fix Android development instead of
| this flutter stuff that will be deprecated and killed off
| in 2 years because nobody uses it?
| timsneath wrote:
| Disclosure: I'm on the Flutter team.
|
| According to AppAnnie, most of these are using Flutter on iOS
| too: WeChat, Alibaba, Grab, Nubank, Sonos all show up on their
| list of Flutter-powered apps on the Apple appstore. We don't
| capture analytics on apps, so our sources here are external
| sites like AppAnnie (or occasionally, direct connections with
| the development team).
| tpmx wrote:
| I tried the Sonos app since it looked very similar on both
| platforms. It's a lot smoother than my experience from a year
| ago. (Hard to really tell in the limited set of screens
| before hardware pairing.)
|
| Edit: If the signup screen in the Grab iOS app is written in
| Flutter I'm _very_ impressed. I want to believe.
|
| Edit 2: Nubank: I only evaluated the sign-in screen(s), but
| it has enough animations at what seems like a very solid 60
| fps on my iPhone X to convince me that Flutter on iOS is
| actually a real thing now. Very nice.
|
| They write about their development effort here:
| https://building.nubank.com.br/scaling-with-flutter/
|
| Edit 3: Maybe I jumped the gun here. Quote from that post:
| "We're also facing hard prioritization decisions, especially
| in flows and screens that work very well in their current
| state (native Objective-C, Swift, Java, Kotlin, or React
| Native) for which there are no near-future update plans."
| trezm wrote:
| Interesting you mention it. I've actually been working on a
| fairly fully featured app in flutter, and was shocked at how
| well it performed on iOS. Coming from the React Native world
| its miles ahead in terms of perf, at least in our case.
|
| Shameless plug, the app is https://droppod.gg, an app to find
| time to play video games with your friends!
| tpmx wrote:
| I tried it - there's some jank here and there, but the
| general experience is smooth. Image loading while scrolling
| through your game feed seems to cause skipped frames, but
| that's not necessarily the toolkit's fault.
| pvinis wrote:
| I like the idea so I just installed it. In the sign up screen
| I can swipe back and get to a second sign up screen, then
| swipe back again and I go to a loading screen forever.
|
| I don't know if that's flutter or you, but it doesn't fill me
| with confidence.
| arduinomancer wrote:
| So does rendering to Canvas imply browser extensions can't work
| with Flutter apps?
| the_duke wrote:
| Does this mean all desktop integrations have now migrated from
| alpha and are available on stable releases?
|
| The post isn't 100% clear on this.
|
| I tried out Flutter a while ago, and it's really promising as the
| only really viable alternative to the JS/browser stack for cross
| platform GUIs.
|
| Dart is not terribly inspiring and lacks the appeal of other new
| languages like Kotlin or Swift, but it's fine; as in: boring/easy
| to pick up and good enough for frontend, although somewhat
| sluggish.
|
| ps: I personally don't see the design of Flutter Web as viable
| for production apps, so if you need Browser support, a JS stack
| will remain the only solution, at least for a few years.
| csells wrote:
| Flutter 2 contains desktop support at the beta level on both
| the beta channel and the stable channel behind a config flag.
| serial_dev wrote:
| I'm a developer who uses Flutter and the thing I love the most
| about Flutter is the Dart language.
|
| It's such an easy language to pick up, and if you know
| TypeScript/Java/JavaScript, it feels immediately "home", you
| just know how to do things.
|
| Regarding Swift and Kotlin, yes, they have more features, but
| that makes those languages also harder to learn and more
| difficult to master. I think Go demonstrated that more
| simplicity is also important and more features does not
| automatically mean you'll be more productive (that's not to say
| that Swift or Kotlin is bad, I just want to express that Dart
| feels great).
|
| Extensions, null-safety are already here, and data classes are
| being worked on, so I think the Dart teams listens to the
| feedback from the community and prioritizes well.
| fakedang wrote:
| Doubt it. More likely this is Google half-assing something
| else. I doubt Flutter 2 is worth it, since they were just
| beginning expanding the Flutter team 2 weeks back
| stephenhuey wrote:
| Seems like you've been around long enough to have read In
| Search of Stupidity. Lots of great stories in there, including
| one about a super famous tech person who once said the browser
| is too slow and will not ever be a viable place for apps. :)
| oblio wrote:
| A bit later that famous dude literally wrote: "whoever can
| make HTML sing will win the API wars". About 5 years before
| people understood what he meant.
| the_duke wrote:
| Never heard of it, but it does sound like a good read!
| fakedang wrote:
| I'll only believe this is worth my time if:
|
| a.) Google fixes Flutter Web and all of its idiosyncrasies
|
| b.) Google removes the jank in iOS apps.
| [deleted]
| arpit wrote:
| I am really excited for web support! My own plans for making web-
| apps now will probably lean towards Flutter and web-sites towards
| HTML/CSS.
| fluentcard wrote:
| I've been using flutter for a while and it has been great. The
| developer experience is awesome, and the community has released
| and maintained some very useful libraries. Dart is a bit strange
| but they've made some good improvements.
|
| Flutter web last I checked was a bit strange, especially how text
| selection didn't really work. That was a showstopper for me so I
| didn't continue, but I'd definitely be interested in trying it
| again.
|
| Overall very excited to see this release.
| drewda wrote:
| Maybe just a coincidence in timing, but it's interesting to
| compare this to the just-announced Mobile Native Foundation:
|
| - https://www.linuxfoundation.org/en/press-release/new-mobile-...
| - https://mobilenativefoundation.org/
| dimal wrote:
| Am I missing something or on web does it render the entire UI in
| a <canvas/>? I'm looking on the gallery[1] and that's what it
| looks like. They say they "added" accessibility, though. Does
| that mean that every bit of functionality you get for free in
| HTML needed to be re-implemented in canvas? Can you really trust
| that that abstraction is going to be air-tight?
|
| [1] https://gallery.flutter.dev/#/
| dstaley wrote:
| Flutter for Web feels like such a wild step backwards in terms of
| functionality that I'm not sure the benefits it brings are worth
| it. I just tried a few samples, and basic interactions like
| selecting text, saving images, and opening links in new tabs
| don't work. This is the result of rendering everything to a
| <canvas> element. I'm much more interested in a React Native
| style approach, which seems to provide a consistent set of
| components that work the same on mobile, desktop, and web.
| Spivak wrote:
| I guess it's just the two ways of approaching a problem. Make
| native look like web or make web look like native. Both are
| kinda bad.
|
| The labyrinthine rats nest of absolute hot garbage to beat a
| document rendering engine into a windowing toolkit with widgets
| is horrible. It's a testament to front-end devs that with
| enough effort you really can squeeze water from a stone.
|
| And then imagine being so comfortable navigating that maze that
| you want your windowing toolkits to behave more like document
| rendering engines pretending to be windowing toolkits.
|
| And you're like "why not just have a windowing toolkit for the
| web and sites can choose their rendering engine basically so
| all the SPAs get all the nice features of stack-based GUIs and
| document people get documents. Surely that would be less work!"
| And I think you're right but I doubt anyone would agree on a
| single toolkit so now you can just bundle your own compiled to
| wasm and rendered to canvas. Woooo.
| axegon_ wrote:
| Annoyingly yes. If flutter web behaved like a true web(whether
| that be through building html elements or through canvas), it
| would have been a breath of fresh air and for once not a
| cluttered codebase of 8000 npm modules, html templates and a
| ditch full of css and no idea of figuring out which is which
| and which comes from where. I can kind of see a market for it
| in a sense that I don't want to install a separate app to track
| my shipment from a specific courier and have a web which is
| easily accessible on my phone but those are very narrow niches
| and honestly I can't think of a business that would invest into
| something like that for nothing more than accessibility. Aside
| from that I strongly stand by the statement that flutter is the
| best option for cross-platform mobile apps by a very long shot.
| refulgentis wrote:
| Things changed a lot, I observed the same symptoms as late as
| late 2020, I can't reproduce these issues now
|
| In general Flutter for Web is _amazing_ if you want to deploy
| an app.
|
| after seeing this thread, pretty clear to me its almost a
| perfect nerdsnipe - makes perfect sense if you're already
| building a Flutter codebase, sounds bonkers if you build web
| apps.
| realusername wrote:
| I have a large Flutter codebase and flutter web is still
| alpha quality in my opinion, there's way too much jank to
| make it work properly on a web platform.
| yjbanov wrote:
| Have you tried --web-renderer=auto?
| dstaley wrote:
| Check out Flutter Folio [1], built in partnership with
| Google. Right-click is actually disabled, so you can't even
| open the "Create account" link in a new tab, nor can I right
| click an input to autofill with my password manager. You
| can't inspect any image rendered to the canvas element.
| Furthermore, you also can't blur the form input (although
| that's probably application specific rather than Flutter's
| fault).
|
| [1] https://www.flutterfolio.com/#/?
| yjbanov wrote:
| (disclaimer: I work on the Flutter team)
|
| The "Create account" link isn't popping up the right-click
| menu because it doesn't use the Link widget. You'd get the
| same thing in plain HTML if you used a <div> with a custom
| click event listener instead of <a>. It's a simple bug to
| fix; totally up to the app developer. I think issues like
| that will inevitably pop-up as we have developers coming to
| the web from other platforms, where "open in new tab" isn't
| part of the toolkit. Perhaps it's fixable via education and
| platform-specific guidelines.
|
| We're aware of the input blur issue. I think the bug is in
| the TextEditable. You can write your own, of course, but
| since we offer it as part of the Flutter framework, it's on
| us to fix.
| singhrac wrote:
| > Perhaps it's fixable via education and platform-
| specific guidelines.
|
| I think this is right, but I also think it should be
| clear to everyone (i.e. in the first tutorial) that not
| using a Link widget will make this work wrong for all
| sorts of accessibility and UX reasons. And the Link
| widget should work across platforms and implement the
| equivalent of page history correctly.
|
| Maybe it's worth writing down somewhere what the
| equivalent of each tag from HTML is; what is the
| canonical way to create an h2, input, textarea, button,
| a, img, etc.
| capableweb wrote:
| > You'd get the same thing in plain HTML if you used a
| <div> with a custom click event listener instead of <a>.
| It's a simple bug to fix; totally up to the app developer
|
| This is the issue. Instead of having one codebase that
| works the same on all platforms (ios, android and web),
| you get (as a developer) the blame for not implementing
| things correctly across the different platforms.
|
| Instead of a cross-platform development environment doing
| that for you.
| capableweb wrote:
| > I can't reproduce these issues now
|
| dstaley just said that those issues happen now. " I just
| tried a few samples, and ..."
|
| I just tried the demos over at
| https://flutter.github.io/samples/#?platform=web and I
| concur, Flutter is utterly horrible for everything the web
| stands for. So not amazing and seems to actively make
| everything worse.
| yjbanov wrote:
| (disclaimer: I work on the Flutter team)
|
| We certainly don't think Flutter should replace HTML or
| other frameworks. We hope Flutter will work well for many
| use-cases, but the web is huge. There's room for multiple
| approaches. If it's not working for your use-case it's
| totally fine with us if you use something else. We welcome
| constructive feedback on what's not working so we know
| where to focus our efforts.
| capableweb wrote:
| Thanks! A great first step would be to have a "web-
| native" renderer for your web version. Meaning that it'll
| use DOM elements that the browser to handle the rendering
| of. Would fix many of the current issues with your
| implementation.
| lucasmullens wrote:
| Is that the CanvasKit renderer or the HTML renderer?
| dstaley wrote:
| I hope it's CanvasKit because if those interactions are also
| broken in the HTML renderer that's even worse!
| yjbanov wrote:
| (disclaimer: I work on the Flutter team)
|
| There's no difference between CanvasKit and HTML as far as
| interactions are concerned. The differences are in pixels
| and performance. If there are issues with interactions,
| we'd like to hear about them. Please file issues on Github.
| dhbradshaw wrote:
| They were pretty clear about the intention here: make the web
| available as a platform for running mobile and desktop-style
| apps.
|
| If you're trying to create a classical website, it's not the
| right tool. Use html and css. If you're trying to make a rich
| app, I'd bet on Flutter.
|
| I'd be interested in seeing it become easier to make a
| combination of the two -- flutter apps embedded in classical
| websites.
| rbinv wrote:
| > flutter apps embedded in classical websites.
|
| Sounds like Java applets.
| mohaine wrote:
| Which mostly died from JVM startup time (Think 30 +
| seconds). There was other issues as well (security and UI
| issues mostly) but if you knew what you were doing, Java
| applets were not bad for the time IF the JVM as already
| loaded.
| whymarrh wrote:
| > This is the result of rendering everything to a <canvas>
| element.
|
| If the accessibility story isn't rock-solid, frankly this is a
| non-starter for a lot of applications. Web apps suck in a lot
| of ways but regular HTML has pretty great accessibility
| properties.
| K0nserv wrote:
| It is far from rock-solid. It's shockingly bad in fact.
| rexelhoff wrote:
| Welp. We can kiss accessibility goodbye then, can't we?
| eseidelGoogle wrote:
| [Flutter Eng. Dir. here]
|
| Accessibility is actually a really big deal here on Flutter
| (Ian Hickson and I both worked on Accessibility in browsers
| for years). AX is something I feel we've done pretty well
| with on iOS and Android. Web is still pretty early days, but
| many AX features should work already. We have more AX work to
| do on web yet. We've not yet taken any Flutter Web apps
| through Google's accessibility testing processes similar to
| how we've done on the mobile side, but I expect we will soon.
| tshaddox wrote:
| Yeah, I haven't been following Flutter, but I'm surprised their
| approach to the web is just shipping their entire custom
| layout/drawing code in WebAssembly and drawing everything with
| canvas. I would have expected them to actually port their
| native UI components (buttons, links, text, etc.) to their
| corresponding native components on the web, and _maybe_ ship a
| custom layout engine if CSS layouts aren't flexible enough.
| Hixie wrote:
| We actually did try that as our first approach, but it really
| didn't give you the flexibility that Flutter developers
| expect.
|
| As the erstwhile editor of the HTML standard for ~10 years
| and the now TL of Flutter I must admit that it's weird to be
| creating a web framework that completely ignores all the HTML
| stuff I worked on before. :-)
|
| That said, Flutter is different from Flash in some important
| ways. Flash used the NPAPI to "break out" of the web and was
| basically "native" code you could escape to, whereas Flutter
| really is using web APIs, like Wasm, ARIA, WebGL, JS,
| WebComponents, and so on, to create true web apps that just
| happen to not use much of the control set that HTML exposes.
|
| I suspect that even outside of Flutter, the web in general is
| going to move towards this kind of framework in the coming
| years. It just gives you so much more control. It's basically
| how every other platform works -- pick your language, compile
| to machine code, don't need to be limited to what HTML and
| CSS (etc) enable.
| oblio wrote:
| Well, good luck maintaining all of that 10 years from now.
| I can bet on the web being around, well developed and
| maintained in 2031.
| Hixie wrote:
| I'm not really sure what you mean by "all of that". What
| I described _is_ the web.
| oblio wrote:
| It's painting stuff in a canvas and not using the
| standard web controls.
|
| It's the web in the sense that almost every UI toolkit
| also offers a canvas (for example Tk does this) and you
| can reimplement every control using it. That doesn't make
| your new toolkit in a toolkit Tk.
| shawnz wrote:
| > to create true web apps that just happen to not use much
| of the control set that HTML exposes.
|
| That is exactly defeating the point. Flash apps were also
| "true web apps" that only happen to use the "limited
| control set" of just <embed>.
|
| > It's basically how every other platform works
|
| That's why there has never been a UI toolkit as successful
| as the web.
| Hixie wrote:
| > Flash apps were also "true web apps"
|
| Not really. They were not portable. NPAPI was not a web
| standard in any meaningful sense (hint: the first N stood
| for Netscape).
|
| > That's why there has never been a UI toolkit as
| successful as the web.
|
| The web's success in terms of active users and in terms
| of deployed content is astounding, certainly. I think I'm
| relatively well placed to understand why, and I don't
| think it's because the web restricted developers to one
| scripting language or one set of controls. I think it is
| very much _despite_ that.
| ComputerGuru wrote:
| Really not fair to compare against flash in this way when
| wasm wasn't available and npapi was the only option. That
| is additionally an implementation detail, Adobe could
| (theoretically) revive and port flash to wasm today without
| breaking the majority of applications.
| Hixie wrote:
| I would have had much less of a problem with Flash if it
| had been a runtime built with web technologies like that.
| timsneath wrote:
| We actually have two distinct approaches: the
| CanvasKit/WebAssembly approach you mention for high-intensity
| graphics, and an HTML-based renderer for other apps. This
| article has more details: https://medium.com/flutter/flutter-
| web-support-hits-the-stab...
|
| You're right -- we do render the controls, so that existing
| Flutter code (that might itself include custom styling or
| matrix transforms) just runs without change or surprise, but
| we integrate with the underlying browser support for things
| like text autofill and accessibility.
| baybal2 wrote:
| Gtk tried the same with broadway. It went nowhere.
| agumonkey wrote:
| Well they made libreoffice run in canvas IIRC, which is
| quite somewhere :D
|
| But yeah it's not grabbing market share that's for sure.
| agumonkey wrote:
| Funny how two days ago some webdev website made a big article
| about flutter vs kotlin but didn't mention the UX side of it at
| all.
| fwip wrote:
| The example spinner ( hhttps://flutter.dev/#dartpad-landing-
| page ) also looks pretty choppy on my Macbook Pro 16. I haven't
| tried on lower-specced devices, but it doesn't inspire a lot of
| confidence.
| timsneath wrote:
| Yeah, that's running in development mode, since it's a
| scratchpad for live coding. Try something like
| https://flutterplasma.dev for an example of Flutter's web
| support when compiled in release mode.
| mkl wrote:
| I don't think that shows off Flutter's web support. There
| are no interactive widgets or user interfaces (Flutter's
| primary purpose?), and the animations are less impressive
| than demos in DOS from ~30 years ago, e.g.
| https://en.wikipedia.org/wiki/Second_Reality
| aden1ne wrote:
| This took about 30 seconds to load on a Galaxy S7 Edge
| (yes, I know, ancient technology in 2021) with Firefox. I
| briefly thought the tab had crashed.
| hobofan wrote:
| Yeah, that's still not great on a Macbook Air 2014. I'd
| even say that the spinner at the end looks even choppier.
| krasin wrote:
| Thanks for the link. To confirm the point of copying text
| being broken: try doing that at https://flutterplasma.dev/
| -- it kind of works, but not really, no.
| renewiltord wrote:
| Ah fuck me. This is awful. You have to be precisely on
| the text to select it. I frequently offset my mouse a
| little to the left of the element to ensure I select the
| whole text. Even a little bit off to the left and
| nothing.
|
| I love the idea, but this sounds like it's going to be
| unpleasant for me. Hopefully they figure out these UX
| things.
| kemayo wrote:
| Ew, you can't select across lines of text, even.
| vincnetas wrote:
| Yeah, tiny differences that would nag the hell out of me.
| For example double clicking for selecting word is
| implemented, but triple clicking to select whole line is
| not implemented ;(
| fwip wrote:
| Thanks for the tip, but the compiled version exhibits the
| same juddering/choppiness for me, most noticeably in the
| rotations.
| merrvk wrote:
| Doesn't seem to work at all for me on an iPad
| AlphaSite wrote:
| It break pinch to zoom in mobile safari, does anyone at
| google spend even a minute using anything but chrome?
| tmoravec wrote:
| iPad Safari on 200/100Mbps connection.
|
| * The page takes about 20s to load.
|
| * After pressing Run, nothing happens for 10s, then Click me!
| text appears.
|
| * On clicking the text, nothing happens.
|
| * On clicking it a few times, the page crashes and reloads.
| AlphaSite wrote:
| Also pinch to zoom is broken.
| vsmenon wrote:
| [ disclaimer: I work on the Dart team. ]
|
| As timsneath mentioned above, Dartpad is the dev
| environment. That means we ship the full Dart and Flutter
| SDK ahead of time as you can type/change anything in the
| code box. We also ship debug metadata to give better
| errors.
|
| In production mode, we do a much more expensive compile to
| remove the parts of Dart, Flutter, and packages you don't
| use and to optimize/minify the rest.
|
| It is working in Safari for me, but we've definitely
| appreciate bug reports if it's breaking for you
| (https://github.com/dart-lang/dart-pad in this case).
| merrvk wrote:
| Yep, I've been really impressed with react native on the web so
| far. Our current code base deploys across Android, iOS, web and
| windows with minimal effort.
| brobdingnagians wrote:
| I recently discovered Flutter and I love it for making mobile
| apps. The multiplatform by default with good API and stability is
| a winning combination. Lots of modern language features from Dart
| and built in support for two way binding makes GUI programming
| much easier. I much prefer it to React Native.
| masterofmisc wrote:
| What is the API story like now? When I first looked before
| version 1 was stamped you had to search for 3rd party plugins
| for features like accessing the camera and such.
| d0100 wrote:
| Whenever I see Flutter news I can't help but feel bitter about
| the death of Flash.
|
| Tomato, tomato
| open-paren wrote:
| Congrats to the Flutter and Dart teams! This is a huge
| accomplishment.
|
| However, I worry about accessibility story for Flutter
| applications. Am I naive? Should screen-reader support be a
| concern for the kind of complex visual applications that Flutter
| is built for?
| timsneath wrote:
| Screen reader should always be a concern! But we built
| accessibility as a core feature of Flutter from the start. You
| can read about our support for screen readers here:
| https://flutter.dev/docs/development/accessibility-and-local...
| including a session where a developer who is blind shows how to
| make an app accessible.
|
| Flutter 2 also supports accessibility for web apps, and you can
| use Windows Narrator, VoiceOver, TalkBack, or ChromeVox screen
| readers to navigate a Flutter web app.
| jorl17 wrote:
| It seems to me that "Flutter (2) for Web" is still mostly
| "rendering widgets/elements to a canvas", and therefore lacking
| native HTML/CSS, etc, making it pointless in many ways. Am I
| missing something or did they change this?
| sgt wrote:
| You can choose to render to Canvas or to HTML (DOM). Both seem
| to work equally well, although the canvas one may have a
| performance advantage on faster devices.
| andrekandre wrote:
| For Canonical, it is critical that they can deliver rock-solid
| yet beautiful experiences on a huge variety of hardware
| configurations. Moving forward, Flutter is the default choice for
| future desktop and mobile apps created by Canonical.
|
| --
|
| so what happens to gnome...?
| yagodragon wrote:
| We're all complaining about how js is a bad language, tooling is
| a mess, and how the web is fundamentally built for documents and
| makes it hard to create app-like experiences. Now, Google comes
| and creates a whole new UI toolkit from scratch, couples it with
| a very beautiful SDK and component framework and offers a far
| better programming language than js could ever be but we're still
| nagging. I was also pretty disappointed with the demo at
| flutterfolio.com that is supposed to show how great Flutter 2.0
| for the web is. It's not that good but it's gonna get there
| eventually, given the hype around wasm and <canvas> technologies.
| Not to mention that Flutter is already better and easier to use
| than the existing native tools for both Android and iOS. I
| believe Flutter is an extremely ambitious project and I
| appreciate that Google is really trying to give an answer to the
| problem of cross-platform UI development.
| tmpz22 wrote:
| Because Google is focused on language and tooling development,
| but forgot to create a killer app example with publicly
| available source code. Show us a minor Google property re-done
| in Flutter with code examples and people would flock to it.
|
| But. They. Won't.
| jaegerpicker wrote:
| Are you a native mobile developer? I am (was I'm moving to
| ML/AI/Data engineering) and I don't think flutter is in any way
| easier or nicer than the native toolchains for mobile. Both
| Swift and Kotlin are better languages than Dart IMO, the IDE
| and tooling is far superior for both also. Flutter is faster
| but once to deploy a substandard quality of app for sure but
| matching the quality of a native app? That takes just as long
| in Flutter as building a native app in each tool chain. I've
| built apps in React Native, Flutter, Ionic, and Swift/Kotlin.
| I'd reach of Swift/Kotlin for developer experience,
| performance, and quality of app EVERY time.
| jpsoft wrote:
| I am, and I agree, native toolchains can be better but that
| is expected, they have a lot more resources dedicated to
| their development. I also am responsible for an app built
| using flutter, it's been on production for almost two years
| with a very good rating in the app stores and over a hundred
| thousand users, isn't that what matters? that the technology
| enables you to solve problems? Flutter did that for us, keep
| happily working on Xcode if that works for you, for our
| startup this announcement is great news.
| joe_fishfish wrote:
| I am a native mobile developer, and I am presuming GP is most
| definitely not, because I completely agree with you.
| ksec wrote:
| I have seen this a lot. Most of those people are Web
| Developers. They want their Web technology to move towards
| cross platform native apps. And are frustrated with people
| bashing or stopping this progress.
|
| On the other hand you have Native Apps developers, while
| equally being excited about Cross Platform UI and toolset
| have been burned more than enough. And this didn't even
| start with Smartphone. It goes back to earlier PC history
| with Java or even further. None of them were good enough.
|
| At the same time Native Apps developers dont understand why
| Web Dev or those who has Web Dev background now working on
| cross platform toolchain constantly push and produce the
| same _thing_ years after years.
|
| You cant blame them for being skeptical.
| The_rationalist wrote:
| What do you think of jetpack compose? It has reached beta and
| there is experimental desktop support
| tofuahdude wrote:
| What are your thoughts on the business end of deciding to
| build two separate versions of the app in two languages (not
| to mention the web) vs the efficiencies of one code base?
|
| We're close to needing to make this decision and I'm real
| hesitant to introduce two additional languages (we're already
| React for the web but haven't build apps yet) vs a React
| Native app where our team can be immediately productive.
| vorpalhex wrote:
| I was with a team that went the React Native route. At
| first it was fine until we had to go slightly off the
| rails.. and I was rebuilding .so files based off random
| gists and updating linkage assemblies.
|
| React Native works until it doesn't and then you are
| getting into very detailed platform specific territory.
|
| A lot of the cross platform promises were untrue - we
| quickly learned the importance of QAing both builds and
| frequently had platform specific patches.
|
| Just bite the bullet and go native upfront.
| The_rationalist wrote:
| Or give Ionic react a try
| awesomepeter wrote:
| If you had to pick a multiplatform solution (for whatever
| reason) which one would you pick? I've been exploring this
| space a bit, and it's really hard to form an opinion on this.
| jaegerpicker wrote:
| I've been in that situation 3 times, I choose React Native
| and Flutter each once. I was forced to use Ionic. I would
| NEVER use Ionic again, terrible experience and very
| difficult to get decent quality/performance. I like
| Flutter's technology much more. I like that it is natively
| compiled. I dislike that it has it's own UI toolkit. React
| Native with TypeScript is a highly productive environment
| but I LOATHED the developer experience and any code that
| had performance goals was way harder to be successful with,
| not impossible but the threading model that RN imposes (it
| doesn't really thread at all) was hard to make the UI
| snappy and crisp as it should be. I've played with Xamarin
| also since I was a .net dev for 10+ years (I'm old in the
| industry 25 years now) and the developer experience was
| actually pretty good but the compile times and the UI
| performance were not. Though that was not a production
| level app and I might have been able to make it work.
|
| tldr; If I HAD to do cross platform I'd use the following
| logic to choice one: If I have a team of react JS/TS devs:
| React Native else if I have a .net team: Xaramin else:
| Flutter
|
| Then I'd apply for a job writing native apps in
| Swift/Kotlin and run away ;)
| rubicon33 wrote:
| > a job writing native apps
|
| Sadly, a shrinking market day by day.
| Waterluvian wrote:
| How many times has Google done this? And then gotten bored of
| their own work?
|
| JavaScript, with all its many many warts, is widely supported,
| incredibly popular, and not going anywhere.
|
| I'm not about to waste my limited weekend time learning Flutter
| 2, knowing it's going to be in the trash bin by 2023. I'd
| rather suffer through some more JS warts and get better at
| avoiding them.
| grayrest wrote:
| > How many times has Google done this? And then gotten bored
| of their own work?
|
| Google's history on this sort of thing isn't good but this
| will be much more stable than their other offerings. Dart is
| the primary language of the ads (i.e. money making) side of
| Google and Flutter is their best shot at making the language
| relevant elsewhere. I'm still not in a hurry to learn it but
| I'd be very surprised if it's in the trash bin within 5
| years.
| ttt0 wrote:
| So now every website will require enabled WebAssembly to run
| god knows what code and I will have to install an anti-virus
| for my browser? No thanks. JS might be a bad language, but it's
| even worse in how it's abused with frameworks, tracking, etc
| for no good reason.
|
| edit: funny how I can discuss extremely controversial political
| topics here and never have any of my comments killed, but
| having a negative opinion about wasm and JS frameworks is just
| a step too far lol.
| ec109685 wrote:
| WASM is still stuck within a highly protected sandbox, so you
| don't need to run anti-virus software for your browser.
| ttt0 wrote:
| Bitcoin miners?
| hnuser123456 wrote:
| better than rootkits
| dagmx wrote:
| Wasm can't do anything JS couldn't do already.
| yjbanov wrote:
| There are a few things that WASM can do that JS can't (at
| least not now):
|
| - Memory management without GC - Unboxed data structures -
| SIMD - Shared-memory multi-threading - Precompiled
| snapshots (does not need to be recompiled on page reload)
| ttt0 wrote:
| What JS can do is already bad enough.
| wruza wrote:
| Can't speak for others, but I still want a proper set of
| primitives and not yet another rightest-way-to-do-it sdk whose
| examples stutter on top hardware and will be great tomorrow.
| Time to go sleep I guess, will check it in 8 hours. All _I_
| want is untangling of the mess a css boxing model is, not just
| some buttons on canvas. I wrote gtk-flavoured widget drawing
| libs for few times in Lua+cairo ten years ago and these ran
| smoothly on a hardware than couldn't even boot an OS today,
| except some rare stop the world gc issues Lua had back then. It
| was no big deal, and strange (not really) that Google Itself
| couldn't beat that score.
| lordgroff wrote:
| Maybe it's just me but I don't remotely think JS is a bad
| language since es6. Tooling is another story entirely.
| qbasic_forever wrote:
| Extremely same feeling here. Ditching IE11 support is a total
| game-change for the web. ES module imports just work and you
| don't have to go down a complex bundler rabbit-hole. Template
| literals make constructing HTML inside JS components a
| breeze. And if you do reach for a bundler the modern ones
| like snowpack and vite make the experience incredible with
| instant hot module reload on change--the feedback loop for
| development is like nothing I've ever experienced.
| blowski wrote:
| The problem with JS is not the tooling per se but the
| constant "upgrades" for the tools that exist. Sure, this
| week's hot new thing is Vite, but by this time next year it
| will be out of date with some other thing we're all
| supposed to use. In projects from the last 10 years, I see
| Gulp, Grunt, Webpack, Browserify, and now Vite - all doing
| mostly the same thing in different ways, with different
| config files.
| qbasic_forever wrote:
| You don't have to use any tools, plain old HTML, CSS and
| javascript still work just like they did 25 years ago.
|
| Tools come and go, they serve a purpose like writing code
| in a more futuristic style and compiling it down to a
| broader browser support base. There will always be a
| treadmill like that in any language. Look at how C++ has
| evolved from its 90's roots to more modern C++11, 14, and
| 17 styles--each change also required more work for the
| tooling, compilers, build systems, etc. to learn. It's
| just in the C++ world there are far less people working
| on tools than in the web world.
| ASalazarMX wrote:
| JavaScript is 26 years old, people were calling COBOL old in
| the 90s, when it was 30+ years old.
|
| COBOL is still being updated, it even supports OOP now, yet
| it shows its age and its joints creak a little, just like
| JavaScript.
| [deleted]
| reggieband wrote:
| > couples it with a very beautiful SDK and component framework
|
| I would not call the flutter SDK and component framework
| "beautiful" nor would I ever add the adjective "very". I have
| actually found it to be very verbose compared to alternatives
| I've used in the past. In some ways I suggest it is over
| engineered.
|
| > offers a far better programming language than js could ever
| be
|
| Dart is a bit of an odd duck language to me. I think of
| interesting ideas like the cascade notation (using .. to do
| sequences of operations on the same object).
|
| Perhaps it is due to having worked a lot in Typescript and
| having my brain molded to code that fits that shape but Dart
| feels clunky in comparison. I can't put my finger on why, but
| defining and instantiating classes feels so heavy compared to
| the functional type code most Typescript seems to become. In
| Dart, I just feel like I'm creating massively indented
| component definitions with tons of properties and nested
| classes. Maybe I'm just finally accepting OOP and deep type
| hierarchies are things I want to leave to my past. I feel I can
| do 99% of what those things did with Algebraic types and
| functional composition. Nowadays I prefer that style and going
| back to heavy OOP feels bad.
|
| With the dominance of classes, massive type hierarchies and
| quirky syntax - I'd just prefer to be working with a more
| react-ish framework in a language like Typescript. My feeling
| is Dart is a step in the wrong direction.
| qbasic_forever wrote:
| History has shown us over and over again, always bet on the
| web. Sure you might not like JS as a language, you might find
| CSS confusing and full of warts, etc. but it's here and will be
| here 20, 50, and 100 years from now. We're not going to just
| sit up and throw away 25+ years of progress and history on the
| web overnight. Tech like java applets, flash, silverlight, etc.
| come and go like fads. Who knows if Google will even care about
| flutter in 5 years, let alone 25 years. A page that Tim
| Berners-Lee wrote 25+ years ago renders just fine in a browser
| today.
| dmitryminkovsky wrote:
| > History has shown us over and over again, always bet on the
| web.
|
| This is a mantra on HN. But is it true? I don't think it is
| if you're trying to build a big product mainstream people
| will use.
|
| People want native apps. No one needs the apps to work in 25
| years. The web is just part of the picture, an important
| part, but still just a part.
| amelius wrote:
| > People want native apps.
|
| Only because OS vendors made them believe that.
| dmitryminkovsky wrote:
| That is my understanding as well.
| jaegerpicker wrote:
| Or maybe because native apps are a better experience,
| nearly every time. True multi-threading, native code
| performance, latest UI implementation, more and better
| hardware access/performance, etc.... I can keep going but
| the point is that the web really is the lowest common
| denominator. That isn't bad but it also isn't how you
| build the best experience.
| amelius wrote:
| If OS vendors wanted web-apps to succeed, they could have
| done a lot more than they have done so far. E.g. better
| integration, or improved web standards to optimize for
| certain cases.
| dmitriid wrote:
| No matter how "better you integrate", there's one big
| core issue: the DOM. You simply _cannot_ make the DOM
| behave as smoothly an as reliably as a native app. And
| no, no amount of "improved web standards" can help with
| that.
| qbasic_forever wrote:
| The same engine of HTML + JS has powered entire businesses
| and industries from $0 to billions and billions of dollars
| over 25 years. Amazon.com would not exist without web
| browsers, and its entire trillion dollar+ business is an
| enormous bet on the web. I would say there's zero danger of
| the web going away when folks like that (and many, many
| more... Google, Facebook, etc.) depend on the web for every
| microsecond of their existence.
| ksec wrote:
| >Amazon.com would not exist without web browsers, and its
| entire trillion dollar+ business is an enormous bet on
| the web.
|
| Except 70% of e-commerce, 90%+ of Social Media are now on
| Mobile Apps, where they were all previously 100% Web.
|
| The problem with Tech industry is that too much thinking
| is about centralised, decentralised, Technology with
| backend front end. etc. When its users or customers dont
| give a fuss at all.
| dmitryminkovsky wrote:
| If today FAANG had to choose: shut down your websites or
| shut down your native apps: which would it be?
|
| Which platform did Clubhouse build out first? Why?
| didibus wrote:
| They can collect more metrics and have more control when
| it's a native app. My web browser is still my most used
| app on my phone.
|
| But I think betting on the web actually meant to bet on
| native for each respective platform. Bet on native for
| the web is betting on HTML/CSS/JavaScript. And then have
| a Java/Kotlin version for Android. And have a
| Swift/Objective C version for iOS
|
| I think the learning is, write once run everywhere is
| what has been tried and failed time and time again for
| user applications. Java failed many times, Silverlight,
| Flash, etc.
|
| The reason is always the same, user experience is limited
| when you go that route, and it eventually loses out to
| competitors who offer the better user experience on the
| user's platform of choice.
| qbasic_forever wrote:
| Clubhouse is targeting the middle-class silicon valley
| market right now (quite literally, those are the only
| people who got invites early on), who of course are
| infatuated with apps and have the money for fancy phones,
| tablets, etc. It's smart marketing for them to go where
| their customers are right now.
|
| The web is for everyone--I can go to an internet cafe in
| a slum and browse and buy from the same Amazon.com as I
| can from inside a $15M mansion. It's a quantum leap in
| access to the world using the web.
| dmitryminkovsky wrote:
| Not sure what personal income has to do with anything.
| Hand held touch devices have revolutionized Internet
| access. The deeper down the income scale you go, the less
| likely you are to encounter a personal computer while
| you'll still likely encounter a smart phone. Amazon will
| work on the web or as an app on that phone, but with the
| app the user experience will be better. That may be
| because Google and Apple have intentionally prioritized
| native APIs while hindering PWAs, but that's still the
| case.
|
| Anyway, I do still wonder: if FAANG had to pick between
| native and web apps, which do you think would they pick?
| ksec wrote:
| Apart from Google which has a complex answer. Most of the
| traffic from FAANG are now coming from Apps.
|
| Facebook could have shut down their Website and it
| wouldn't even have a 10% revenue impact.
| BorisEm wrote:
| For Facebook and Apple, mobile (native) is definitely the
| most important.
|
| Advertising accounts for 99.9% of Facebook revenue, with
| mobile advertising accounting for 94% [1]
|
| Not sure for the other ones.
|
| [1]https://www.businessofapps.com/data/facebook-
| statistics/
| muxator wrote:
| > People want native apps.
|
| I'll take a well done web page anytime over a native app.
| [deleted]
| peterstensmyr wrote:
| I generally agree with you, but I don't think it's
| unequivocally true. Facebook bet on the web/HTML5 for their
| iOS app, and Zuckerberg later referred to it as the company's
| biggest mistake.
| ksec wrote:
| That was because he trusted his engineers that believed in
| ideology rather than objective and rational evidence.
| someguydave wrote:
| I will gladly throw away 25 years of "progress" because it is
| just programmer busywork and monopoly lock-in.
| tamrix wrote:
| Google does have a history of ditching tech that, to them,
| doesn't work out.
| eseidelGoogle wrote:
| [Flutter Eng. Dir here]
|
| I guess I would like to think we are betting on the web. :)
| All of the Flutter founders came from Web backgrounds. After
| years of attempting to make the Mobile web awesome, we forked
| Chrome and built a new thing. Now we're bringing it back to
| the Web.
|
| The web is a big tent. I think there is a lot of room for
| innovation here. We're attempting with Flutter to push on
| some of the newer aspects of the Web. There are still some
| pieces missing from the Web to make things like Flutter
| really shine (e.g. a multi-line text measurement API could
| help get rid of a _ton_ of code in Flutter Web). As you saw
| in the keyonte today, we 're working with Chrome to continue
| to improve life for developers.
|
| I don't think Flutter will ever be the right solution for
| _all_ of the Web. Certainly not today. For example, we don 't
| even support SEO or great indexability yet (although it's
| long been planned for and will be coming soon).
|
| I just want to believe we can do better. We, developers, can
| all push development (including the web) to be better.
| Hopefully Flutter will do it's part.
| didibus wrote:
| When Chrome has become synonymous with the Web :facepalm:
| bsaul wrote:
| Read somewhere flutter canvas rendering was only a first <<
| quick n dirty >> way of rendering something on the web, but
| a true DOM renderer was the end goal.
|
| Can you give more info on that ?
|
| Another question i've always had about flutter : last time
| i explained how this tech looked promising, a friend asked
| me about performance. I said << they said it's really good
| and smooth >>. But then we tried the iOS demo app
| (something very basic about vegetables) from the app store,
| and the scrolling performance was a total disaster (on an
| iphone x).
|
| Do you have an explanation for the discrepancy between the
| official ad one can read on google blogs, and the real-
| world experience of app developped with flutter ?
| blacktriangle wrote:
| We're nagging because the apps suck and stick out like a sore
| thumb. Maybe Flutter will be the one to get there and be the
| holy grail of cross platform UI development, but the developer
| community has been burned by this promise so many times, we're
| going to have to see the final product before getting excited.
|
| Just because a project is ambitious doesn't mean we should all
| jump on board, particularly when similar projects have crashed
| and burned, and there's really nothing stand-out about Flutter
| that separates it from prior efforts.
| drewda wrote:
| On this note, I have 60% fond memories of Appcelerator
| Titanium and 40% frustrating memories :)
| throwaway123x2 wrote:
| Oof remember when PhoneGap was the next big thing? RIP
| The_rationalist wrote:
| Pure nonsense, phonegap has been renamed Cordova and is
| widely used. The Electron of smartphones is Ionic which is
| a sexy and performant superset of Cordova. PhoneGap
| (Cordova + Ionic marketshare) has a bigger marketshare than
| flutter and react native! Source:
| https://www.appbrain.com/stats/libraries/tag/app-
| framework/a... Ionic is a gift and it will only get more
| widespread, the myth that chromium is slow is increasingly
| dying. Also, did you notice the _irony /hypocrisy_ that
| flutter is using the rendering engine made by chrome
| developers for Chrome developers ?
| TheGuyWhoCodes wrote:
| I remember big corps betting on phonegap and sencha for
| mobile 7 years ago. I also remember big corps betting on
| GWT.
|
| Those were painful days...
| dmitriid wrote:
| Funnily enough, Sencha still can't be reliably recreated
| by any lib/framework/browser built-ins du jour (without
| sinking as much effort as Sencha did): https://examples.s
| encha.com/extjs/7.3.0/examples/kitchensink...
| hanniabu wrote:
| I don't understand why more resources aren't being put into
| Qt and making that easier to use or building a more "web-
| developer-friendly" abstraction layer on top.
| ryandrake wrote:
| I don't even fully understand why "cross-platform UI
| development" is such a holy grail. Is it that expensive to
| separate your business logic from UI and write the small UI
| layer in whatever the platform's "best practice" native
| language is? Is it that hard to find developers who know
| more than one programming language? With a lot of these
| frameworks and higher level abstractions, if you go off the
| toy-app happy path, you end up fighting the framework and
| tools more than you're writing your app anyway.
| avar wrote:
| And write your shared business logic in what language? If
| it's a C library perhaps you could do this on iOS and
| Android, but how is that going to run in a browser?
|
| I'm aware of things like the LLVM based C to JS
| compilers, but they're not really viable for anything
| non-trivial.
|
| That's why a lot of shops are writing the same logic N
| times in N languages and frameworks. It can actually be
| easier than having to target something these wildly
| different platforms share.
| hamandcheese wrote:
| > Is it that expensive to separate your business logic
| from UI and write the small UI layer in whatever the
| platform's "best practice" native language is?
|
| I mean... yes? There is a ton of incidental complexity
| (i.e. unrelated to the business domain) involved in
| creating nice user experiences. If dev salaries weren't
| so high then sure, more companies would probably spend
| the money to repeat the same work across several
| platforms, but right now? No way.
|
| That said, I still think I agree that you give up more
| than you gain by going cross platform, at least for now,
| but I totally get how companies look at how much it's
| costs to hire and says "you know what? I'll take a cross-
| platform compromise"
| heavyset_go wrote:
| Qt's QML + QtQuick follow the declarative and reactive
| programming paradigms and use JavaScript, and were released
| before React existed.
| qbasic_forever wrote:
| Isn't the licensing for Qt a very curious and weird
| quagmire? Maybe it's better these days but I remember about
| 10 years ago there was a weird divide and unanswered
| questions about if you could really take a bet on using Qt
| and not be violating GPL.
| heavyset_go wrote:
| It's better these days. For desktop application
| development, Qt is available under the LGPL and the Qt
| commercial license.
|
| Qt for WebAssembly is available under the GPL3 and the Qt
| commercial license, though.
| smoldesu wrote:
| QT isn't neccesarily a crowd pleaser, and in 2020 it's
| starting to look a little long in the tooth. Don't get me
| wrong though, I love QT on the desktop, and it powers some
| of my favorite software out there. Ultimately though, I
| don't think QT's fate is on the web.
| danShumway wrote:
| I don't know if they've changed their approach over the
| past year, but the last time I looked at Qt demos for the
| web, I was solidly unimpressed.
|
| At the time, they were making almost all of the same
| mistakes that Flutter is, and the devs I talked to seemed
| to be of the opinion that those problems wouldn't be fixed
| until browsers started adding brand new capabilities
| specifically for them.
|
| Looking now at the demos at https://www.qt.io/qt-examples-
| for-webassembly, a lot of the same problems are jumping out
| at me. A complete lack of accessibility features, poor
| handling of scroll events, large load times, unfocusable
| fields, lack of keyboard controls, etc...
|
| Halfway through playing with their pizza app, the page just
| froze and stopped responding to any clicks at all. Maybe
| those demos are outdated?
|
| Blazor and Rust are showing a lot of promise here, but from
| what I know about Qt I'm much less optimistic, because Qt
| is used to handling everything about rendering itself --
| and as Flutter is showing that's just not a good approach
| to building web GUI frameworks. But (again, purely from
| what I've seen) trying to layer on a system where Qt is
| actually interacting with the DOM seems like it would
| require a somewhat difficult shift in its architecture.
| Maybe I'm misunderstanding the problem though.
| 0xFluegel wrote:
| > Looking now at the demos at https://www.qt.io/qt-
| examples-for-webassembly, a lot of the same problems are
| jumping out at me. A complete lack of accessibility
| features, poor handling of scroll events, large load
| times, unfocusable fields, lack of keyboard controls,
| etc...
|
| I found that hard to believe. But, clicking that link and
| trying the pizza demo... Yikes. It's not exaggerated at
| all.
| gagege wrote:
| Whoa, yeah, none of those Qt demos are good or even seem
| to work properly. Yikes.
| stephenhuey wrote:
| Exactly - too often we see developers spending vast amounts of
| time on stuff that's "better" but by what metric? Often, it's
| better only by standards that matter to the developers, not the
| business paying the bills. In my experience, Flutter makes it
| very fast to ship a decent solution.
| capableweb wrote:
| > Now, Google comes and creates a whole new UI toolkit from
| scratch
|
| Worth remembering that this is not the first or even second
| attempt at this from Google. So I think people are fair when
| they are not just jumping along all happily as people have been
| burned before.
| mdoms wrote:
| I just visited flutterfolio.com. The very first thing I tried
| to do is enter a username and Tab to the password field. But
| Tab just catapulted my input focus to the browser address bar.
| I mean, come on.
| mgkimsal wrote:
| Strange - I didn't see that behaviour, then did on a reload,
| then didn't again on the next reload. ??
| lwansbrough wrote:
| Haha I just read your comment, totally forgot about it, then
| tried to do the same thing and it happened to me too.
| Firefox.
| hnuser123456 wrote:
| works on firefox
| pmontra wrote:
| I went there. It didn't register my first attempts to tap
| into the email field. I tapped the password and it worked
| after that.
|
| But a demo site asking to register an account to see the
| demos? I gave up. It almost like they are not interested to
| show their demos.
| danShumway wrote:
| The accessibility is a bigger concern, but flutterfolio.com
| also
|
| A) lags on my work machine when tabbing through fields
|
| B) doesn't handle HDPI screens well (the entire interface
| looks blurry)
|
| C) keeps fields visually indicated as selected even when I
| click outside of the browser (if I start typing, is it going
| to go into the field or not?)
|
| D) has a _separate_ touch mode? Touch doesn 't just work?
|
| Looked up another of their sample apps:
|
| A) doesn't respect my OS scroll direction
|
| B) lags on scroll
|
| C) mousing over any of the buttons has a 0.5 second delay
| before my cursor turns into a hand icon.
|
| And all of these sample apps take about a second to fully
| load for me, despite the fact that most of them aren't doing
| anything complicated.
|
| The "we can rebuild the browser in Canvas" idea is alive and
| well in GUI toolkits, but I have never seen an implementation
| that didn't have these kinds of basic problems. How many UI
| toolkits do we need to see that can't figure out how to do
| scrolling before we acknowledge that having one team try to
| independently reimplement decades of work on the web might
| just be a bad idea?
| eseidelGoogle wrote:
| [Flutter Eng. Dir. here]
|
| I really appreciate the feedback. We clearly have more work
| to do on the Web side of Flutter. Unlike the Mobile side
| which has shipped 100,000s of apps, the Web side may be up
| to like 1000. :) So many more issues to address as we work
| closely with more users to get their apps into production.
|
| If you'd like to track progress on any of these, I'd
| encourage you (or anyone else reading) to please file
| issues at flutter.dev/support. We read (and try to address)
| each and every one which comes in via Github.
| rektide wrote:
| The CanvasKit renderer[1] is highly concerning to the
| general health of the web. It's nice that it's easy for
| developers, but it remove all the power of the web.
|
| To an end user, their accessibiliy tools, & user
| extensions, the page might as well be VNC'ed in to some
| system. Everything is opaque. There's no HTML elements.
|
| I can not state strongly enough how immoral & unethical
| this path is. Bending the web to the developers will &
| breaking all the contracts of what a web page is a
| grevious act, is enormously harmful. This is one of the
| worst possible things that could happen to the web.
| Please for god sake don't do this to us. Don't injure the
| web like this.
|
| This will be raised again and again and again until the
| ends of time as an incredible black mark on the name of
| Flutter.
|
| Edit: constructive feedback welcome. Whether it's me or
| others, folks pointing out this peril often find
| themselves hit by downvotes as I do now. This seems like
| an existential challenge for the web, to keep humans able
| to be in the loop when browsing the internet. We would
| all love if you would defend or explain or have something
| to offer in your critiques about this crisis.
|
| [1] https://flutter.dev/docs/development/tools/web-
| renderers
| jessaustin wrote:
| _[Flutter ... here]_
|
| Currently I'm counting four or maybe five different HN
| users in this thread indicating this affiliation. I
| appreciate this open look into the organization. We're
| probably getting a more honest idea about what really
| goes into the sausage. Still, your PM might be less happy
| about this thread...
| danShumway wrote:
| I appreciate that building something that works even this
| well targeting Canvas must have been a metric ton of
| work, and I'm impressed. But that's kind of the issue --
| it cannot possibly be more work to maintain a separate
| rendering/compilation pipeline for browsers than it is to
| rebuild the entirety of Chrome's DOM engine in WebGL for
| CanvasKit.
|
| I just don't see how Flutter is going to keep pace with
| "native" web apps when the team is constantly playing
| catch up every time a new medium, input method, or
| browser feature comes up.
|
| Handling scroll is hard enough, is this going to handle
| WebVR? Can I control this web app with a voice assistant?
|
| Sorry if this is something of a dismissive answer, but
| I'm not sure what the right way is to file an issue that
| boils down to, "it seems like you picked literally the
| hardest possible way to build a web GUI toolkit, and I'm
| very impressed that you have anything that's usable at
| all, but I also don't understand why you did this."
|
| I don't know, I don't want to be overly negative here,
| but I don't have any confidence at all about the overall
| strategy that Flutter is pursuing. In order to get
| accessibility to work, you're basically going to end up
| building a DOM representation of these apps anyway. It's
| just now you have to build a DOM representation _and_ you
| have to completely reimplement the rendering stack and
| capture all of my events? How are you going to make
| something like that performant across every browser?
|
| I want to echo a few other comments I've seen here that
| this result isn't really surprising to me. I guessed
| before I clicked on the demos that they probably wouldn't
| handle scroll events well, because I know how you're
| building Flutter for the web, and I have never seen any
| GUI frameworks targeting pure Canvas on the web that
| don't have basic errors like this. If Flutter ever
| managed to be the exception, that would be very
| surprising to me. I don't know what Flutter's internal
| process looks like, I'm not going to tell you you're
| building something wrong. I only know what the end result
| looks like, and I know that end result is not going to
| radically improve any time soon.
|
| It's not my place to tell any team what to do, and nobody
| is obligated to care what I think, but... I don't know,
| the demos online do not leave me feeling confident about
| Flutter's future. I don't think the experience as it
| exists today is the result of a bunch of isolated
| issues/bugs that can be fixed one at a time.
| oscargrouch wrote:
| Its nice to have absolute control of the rendering going
| over canvas if you are a flutter platform developer and i
| think even playing the catch-up game they should get
| there eventually.
|
| But i don't think this is the real issue here.. Flutter
| is more of a Flash and GWT lineage, and that's fine if
| that's what you are looking for.
|
| But i bet on the Web every time, its the most popular UI
| (and now much more) platform ever. So while some will go
| through the Flutter and React way of doing things, most
| will just stick with the web.
|
| The web is the most sophisticated platform ever built. It
| gives you a lot of power and freedom, so i don't
| understand why some prefer to get stuck into a cubicle
| when you have so much space?
|
| Its nice to have frameworks to make things easy and
| developers more productive, but the ones that do this
| without alienating the developer from the bigger, broad
| and sophisticated framework are just better.
|
| Just let them be the new Flash, now at least open and
| over the web, and look for other approaches if you want
| to maintain real control and freedom, instead of
| delegating them to the platform developers.
| heavyset_go wrote:
| I don't understand how breaking accessibility with
| Flutter wouldn't mean that companies that use it on the
| web are violating the ADA.
| johnmaguire2013 wrote:
| I happen to be on a 1.5 Mbps connection at the moment, and
| "about a second" sounds wonderful. The demo apps I opened
| took closer to 30-60 seconds to load.
| mediaman wrote:
| On safari it doesn't do that if the contents are blank, but
| if you type something in the email box, tab directs to the
| address bar. Weird.
|
| Works fine on Firefox and Chrome.
| ledak wrote:
| It strongly reminds of mid-2000s sites written in Flash
| bliteben wrote:
| To be fair there were some flash sites I've still never
| seen anything that equals. I think the way flash marketed
| to more designers and content creators was both what made
| it awesome and maybe its downfall.
| ClawsOnPaws wrote:
| I know I do almost nothing on HN but complain about
| accessibility, but it's really important to me because, well,
| that's how I uze my tech. And so far, sadly, Flutter hasn't
| impressed either with its previous versions. Edit boxes in
| particular were a major pain point, and things like you're
| describing were also less than optimal. I never knew where
| the focus was and what it was doing. With broken markup there
| was at least ways around it. But I'm scared of things that
| render on the canvas. Most browsers actually get this right
| and have support for these things that don't require ugly
| hacks if you use the DOM. And there is no real way to
| interface with assistive tech from JavaScript except through
| it. So you have to somehow still actually represent your apps
| UI in the Dom in some way.
| SamBam wrote:
| Yup, that happened to me. Then I clicked again and tab worked
| correctly.
|
| It will be hard to overlook little details like this -- and
| there will be a million tiny details like this -- when
| decades of browser development have led us to expect a DOM
| experience that Just Works for UX like that.
| wott wrote:
| > flutterfolio.com
|
| I can't experience this problem, for my browser only displays
| for this site a beautiful, immaculate, plain white page :)
| nwienert wrote:
| Flutters model really fundamentally isn't there "right one". It
| truly is the successor to Flash, but with Google behind it.
|
| But if you want to make apps that feel actually native on their
| platforms, React has it handily beat. It's a better fundamental
| model, that even with a slower language and runtime feels
| better in the end by far.
| lostmsu wrote:
| Flutter does not offer enough to justify learning new
| programming language.
| pier25 wrote:
| Dart is extremely easy to pick up if you've written in any C
| style language.
|
| Someone in our team had a small Android TV app working in 2-3
| days with WebSockets, web views, some animations, etc.
| oblio wrote:
| Syntax, semantics, code organization and best practices,
| libraries, frameworks, debugging and debuggers, IDE support
| (preferably multiple IDEs for multiple platforms), LSP
| support, linters, profilers, disassemblers, dependency
| license checkers, dependency vulnerability scanners,
| package managers, package repository with support for
| private repos and proxying/mirroring, should I go on and on
| and on?
|
| Your toy app takes 2 days to create and then you (or worse,
| someone else) have to support the crummy Visual
| Basic/PHP/Javascript/Mongo/ColdFusion/insert easy to use
| crappy tech here, forever.
| Dylan16807 wrote:
| > crappy tech
|
| What kind of an argument is this?
|
| Not wanting to learn all those things for multiple
| languages is valid. But "it would take a while" doesn't
| tell you anything about whether a language is crappy.
|
| The odds are pretty close to 50:50 that the language you
| already know is the crappier one.
| oblio wrote:
| My main point is that developers chase shiny things and
| "easy to use" is one of the shiniest things out there.
|
| Past a certain point, being usable in 2 clicks is a
| negative signal for overall tech quality. Most of the
| really solid techs need some extra configuration. The
| classic example of crappy tech is the DB tech that
| listens on 0.0.0.0 after installation, with no user +
| pass or admin/admin.
| Dylan16807 wrote:
| > Past a certain point, being usable in 2 clicks is a
| negative signal for overall tech quality. Most of the
| really solid techs need some extra configuration. The
| classic example of crappy tech is the DB tech that
| listens on 0.0.0.0 after installation, with no user +
| pass or admin/admin.
|
| Yeah, but the post up there said 2-3 days. That's plenty
| of time to handle those important details that make a
| project non-instant.
| jamil7 wrote:
| Yeah but it's usefulness is really limited and just feels
| shoehorned into the project. Why couldn't it have been
| Kotlin or TS? Something that mobile developers or web
| developers could jump into and keep a bunch of their
| existing tooling.
| distances wrote:
| Then you would've needed to package a JVM or a JavaScript
| engine, making the app distribution a whole lotta
| different deal.
| MongooseMan wrote:
| Kotlin doesn't just run on the JVM - it can compile to
| native binaries with Kotlin Native. It compiles to WASM
| and JS too.
| blacktriangle wrote:
| It's never about the language, most any language is easy to
| pick up. However picking up a whole new ecosystem with its
| associated dev tools, build tools, packaging, and different
| libraries is where the time consuming portion of new
| languages come in.
| pier25 wrote:
| Desktop support is still in beta:
|
| https://flutter.dev/desktop
| ridiculous_fish wrote:
| Gave it a try, couldn't get the Test Drive to work due to code
| signing issues. But to be fair code signing is always painful.
|
| I filed https://github.com/flutter/flutter/issues/77173
| belinder wrote:
| So how does it run natively on desktop? Is it like electron?
| Can't tell from the linux example
| bilal4hmed wrote:
| Not like electron at all. It compiles down to a native binary
| for the OS.
| axaxs wrote:
| Eh, it's a little murky. I was playing with dart a little. It
| can in fact create a single binary, but it looks like it's
| just putting the interpreter with the code.
|
| I say that because if you strip or pack the binary, instead
| of working it shows the output of running dart with no
| arguments.
| vsmenon wrote:
| [ disclaimer: I work on the Dart team ]
|
| It depends on how you run. Dart can either run in JIT mode
| or AOT mode. In general, when you ship a production app
| (e.g., for Flutter), you are using AOT - i.e., it's
| compiling to native machine code. In this case, there is no
| interpretation or compilation at runtime. We still bundle a
| runtime for garbage collection.
| axaxs wrote:
| Which does 'compile exe' use? Essentially here is what I
| see - $ cat a.dart void main() {
| print("hello world"); } $ dart compile
| exe a.dart Info: Compiling with sound null safety
| Generated: /home/x/a.exe ~ $ strip a.exe ~ $
| ./a.exe --version Dart SDK version: 2.12.0 (stable)
| (Thu Feb 25 19:50:53 2021 +0100) on "linux_x64"
|
| If I run without --version, it prints the same thing the
| 'dart' command does.
| gtirloni wrote:
| The docs[0] are pretty good. It looks like there is a concept
| of "embedder" that does the hard work. See [1].
|
| 0 - https://flutter.dev/docs/resources/architectural-overview
|
| 1 - https://github.com/flutter/flutter/wiki/Custom-Flutter-
| Engin...
| vbsteven wrote:
| IIRC Flutter compiles your Dart source code to a native
| platform binary and uses Skia to render the UI. I assume the
| Flutter Desktop API provides abstractions for creating windows.
| endisneigh wrote:
| I long for the day when software development steps out of its
| infancy and we have one programming language that targets all
| platforms and frameworks.
|
| Kotlin is pretty great - so you're in this situation where you
| can either learn Flutter or JavaScript - at least with JavaScript
| you can also target the web (I'm aware that Flutter 2 also can
| target the web, but it's not the same thing).
|
| edit: I must clarify - I'm not saying software development must
| necessarily have only one language, but rather that there exists
| a single language that can target all environments natively. C
| was close, but then the web and mobile happened. Java was also
| close, but no dice. We're getting there, I think.
| cmrdporcupine wrote:
| Literally the easiest part of my job is learning a new
| programming language. Learning the codebase is much harder.
| [deleted]
| AlotOfReading wrote:
| This strikes me as akin to wishing for mathematics to step out
| of its infancy and adopting a single notation.
| endisneigh wrote:
| I don't understand - Math is a great example because the
| notation is bounded across all disciplines of math. Can you
| imagine if Physics used different "math" and "notation"
| compared to Chemistry or Computer Science? You don't have to
| learn a different math to understand different disciplines in
| the same way you have to learn different programming
| languages to understand different programs.
|
| Perhaps I'm misunderstanding you.
| tasogare wrote:
| Math isn't written using the same notation across human
| languages, so it's not a good counter example either.
| endisneigh wrote:
| Do you have an example? I speak another language and am
| not aware of meaningful differences in math notation in
| other languages.
| AlotOfReading wrote:
| Notation is highly variable in math. Take a look at penrose
| notation [1] as example of just how different they can be.
| Most mathematics books will have a definition section in
| the front stating their notation choices because things are
| so fragmented. Good luck trying to read something like
| Russell's PM without a notation guide open alongside it.
|
| [1]
| https://en.wikipedia.org/wiki/Penrose_graphical_notation
| jgon wrote:
| Time to post the evergreen thoughts of Alan Kay from his 1997
| OOPSLA talk: https://youtu.be/oKg1hTOQXoY?t=1491
|
| We've spend the last 25 years hacking a document renderer and
| scripting language aimed at 5 line form validation logic into the
| be-all and end-all of modern application development. Browsers
| sit at 10s of millions of lines of code, with thousands of people
| working on them. We depend on a standardization committee to have
| things like the common controls you could find in a Smalltalk-80
| UI, and these are still insufficient for many purposes such that
| developers end up cramming together a million diffs to create the
| controls they want, in the style they want.
|
| The writing was on the wall once we had a canvas element, aka a
| drawing context, and webassembly, aka a vm target you can compile
| to. We can keep building up giant garbage heap of complexity and
| saying that's what we meant to do (
| https://youtu.be/oKg1hTOQXoY?t=814 ), or we can take step back
| and ask if we can provide simpler lower level tools on top of
| that.
|
| With that said, I feel somewhat ambivalent about all of this. Of
| course the web is an open standard and has provided an incredible
| explosion of knowledge and utility for everyone. Any sweeping
| changes to that should elicit feelings of caution I think. Things
| like accessibility are important, although I think that enough
| people recognize this that we don't need to worry about it being
| left behind with this approach and I would also say the ocean of
| divs approach isn't exactly great for accessibility either.
|
| Will this take off and be the first of a new kind of application
| development? Maybe, or maybe we'll all look back on it in 10
| years and wonder what the hype was. For my part I do feel like
| some sort of change is going to happen, the current approach of
| piling more crap on top of the current html app dev paradigm
| feels unscalable, while the strengths of how it allows for app
| distribution feel like something that we can never get away from.
| Will Flutter retain those strengths and leave behind the
| weaknesses? I hope so, and it make me excited for the future of
| web development in a way I haven't previously.
| Shadonototro wrote:
| Well, with flutter they did what every other "supposed" "modern"
| languages failed to provide (rust, swift, kotlin, go)
|
| A modern UI, crossplatform, AOT compiler UI toolkit, that
| includes phones, web, and desktop
|
| Not even dotnet could achieve this
|
| Even if i'm not interested in that kind of development, let's
| hope people pick this instead of the atrocity that is electron
| darklion wrote:
| Literally none of those languages tried to provide all of those
| things. It's not a failure if that wasn't the goal to begin
| with.
| Shadonototro wrote:
| That's exactly my point, you fail to understand
|
| I said provide, not "goal"
| shock-value wrote:
| You used the word "failed" which implies they sought
| something and fell short.
| rubyn00bie wrote:
| I've been writing a desktop app using Flutter and couldn't be
| happier honestly. The widget pattern makes sense, the bloc
| library does what it's supposed to do, and just building an app
| is mostly on you. My blossoming love of Dart has also been a nice
| but welcome surprise. It has a couple weird spots and
| irritations, but so does literally everything else... It works
| well for the problem space its used in and has the necessary
| language features to get the job done without blowing off your
| feet.
|
| Writing a desktop app _on_ and for Linux, that works on MacOS,
| and Windows ... and a web browser is beyond awesome. It'll
| probably work well on Android and iOS, with little effort, but I
| haven't even bothered to try yet. Before I add a dependency I
| will check out the code and run the demos (if there are some). I
| haven't had one fail or render strangely yet on a Linux desktop
| and nearly all of the existing packages were originally
| created/intended for a mobile device.
|
| With web support, I personally have zero reason to ever write a
| line of JavaScript again. Why would I want to roll all my own
| basic widgets? I don't. Writing the logic for a performant and
| interactive list view, in JS and HTML, is woefully boring to me.
| I want a list view I can give data to and have a meaningful
| display of my data. I do not want to browse twenty different
| packages to find a list view that is the right mix of code I
| don't hate and features I actually want. I want that done because
| it's a solved problem, and takes time to solve right.
|
| I couldn't be more excited for this release and future ones
| because Flutter is providing me a solution that fucking works.
| pvinis wrote:
| Show me any flutter app you want and I'll find a problem with a
| list view.
| bsaul wrote:
| I'm still having a hard time believing any << flutter is so
| great for me >> testimonies, because my personnal experience
| with app having only the most basic list screen has always
| between a disaster. There's such a big discrepancy between
| those testimonies and my experience that i'm starting to
| become suspicious about their authenticities
| offtop5 wrote:
| Pretty sure I'm the only person on this thread who loves flutter.
| We use flutter web and Firebase for our hobbyist project, and the
| results have been simply amazing.
|
| Dart makes Typescript look like a joke. The build system alone
| makes flutter better than React Native !
|
| I'm confident in being able to build any CRUD app in dart
|
| Edit, in fact how many of you have actually built a project in
| flutter .I can't believe anyone would want to go back to react
| native after trying it
| stephenhuey wrote:
| You're not the only person. After using two decades of
| improvements to JavaScript, Dart comes out swinging and wins
| without a contest. I don't want to spend all my time playing
| with build systems and and Flutter just works, plus even though
| JS is better these days, Dart in IntelliJ (Android Studio
| version) is so straightforward you can be productive from day
| one without having ever written Dart before.
| LocalPCGuy wrote:
| We built our mobile app in Flutter, and it was pretty amazing.
| I would absolutely never suggest we create a web version of
| that mobile app and would strongly fight against it if someone
| else suggested it.
|
| I strongly disagree re: Dart vs. TS, but then, I was a JS dev
| before I worked with Dart/Flutter, so probably a bit biased.
| But I think that is a very subjective statement, not objective.
| the_duke wrote:
| Can you share any example of Flutter Web that isn't a extremely
| basic Todo app, doesn't completely break regular browser UX and
| works without being slow as molasses?
|
| I haven't seen one.
|
| I like Flutter, but I don't think the Flutter Web design is
| very viable for production apps. It renders everything in
| canvas. Dart is already sluggish on native, and cross compiled
| to JS it's usually unusable.
|
| I think Flutter will be a good choice for mobile and Desktop
| soon-ish, but for web ... maybe in a few years. Maybe.
| gman83 wrote:
| https://rive.app/ is built with Flutter. I use it a lot works
| very well for me. It's a good example imo of the kind of
| website that Flutter is a good fit for.
| tomComb wrote:
| I assume their medium term plan is to make the new wasm
| backend the default rather than continuing to rely on
| transpiling.
| the_duke wrote:
| The gallery already downloads a wasm file for me. Not sure
| if it's used.
|
| ps: for me the Gallery is extremely laggy in Firefox, but
| works decently well on Chrome. Maybe wasm is enabled on
| Chrome only.
| wootie512 wrote:
| Yea I have used Flutter for hybrid apps and love the dev
| experience. The apps have come out great, and are smoother than
| my native Android work.
|
| I am really hopeful for it and am going to keep using on it for
| hybrid apps.
|
| I try to just tell devs to try it, then judge it. Because it
| does seem weird up front, but it is such a nice experience for
| devs and can make great mobile apps.
| aliyfarah wrote:
| >Dart makes Typescript look like a joke.
|
| Dart still does not even have union types, probably the best
| feature of TS. I would hold off on that claim for now..
| okamiueru wrote:
| What is your main use case for type unions? I don't know
| typescript, but I haven't felt the dart language was not
| feature complete for all my uses. Is this something you
| cannot solve with a combination of abstract classes, and
| or/extension? https://dart.dev/guides/language/extension-
| methods
| oblio wrote:
| Let's say you get a JSON API that sometimes returns a list,
| sometimes returns an object. How do you model that in Dart?
| okamiueru wrote:
| You could create an abstract class for the base response,
| then implement this abstract class for the two cases one
| where it has a list member, and one where it contains the
| object. Then, using the return value with something like
| `if (response is listLike) { }` the IDE already knows
| that you are scoped to having only the list like
| properties, and you'd get the full help of the language.
| Something like that, I suppose.
| oblio wrote:
| Versus a sort of:
|
| my_type = my_list | my_object
|
| ?
|
| You can see why this is better :-)
| okamiueru wrote:
| All I can say is that it is certainly neat :)
| kroltan wrote:
| Not who you asked (and I just now realized I'm replying to
| you twice regarding this OP, I solemnly swear it's not some
| crude attempt at stalking).
|
| But for me the main use for TS union types is to make
| discriminated unions, which is very useful wherever you
| have some form of a state-machine: type
| AppState = | { state: "loading", progress: number
| } | { state: "selecting_level", } | {
| state: "playing", level: Level } | { state:
| "success" } | { state: "failure", wantsRetry:
| boolean } | { state: "error", reason: string }
|
| (Small excerpt from a game we're developing at $dayjob)
|
| You can switch on that and the compiler will know what
| variant you're talking about, and it will apply
| exhaustiveness checks (ensures your code will handle all
| possible states)
| okamiueru wrote:
| Haha. That's alright. That looks super neat though, I
| must admit. The only equivalent that comes to mind would
| be using an abstract class. I still might fail to fully
| understand what that code example does, but, would this
| be somewhat similar? abstract class
| AppState {} class AppLoading extends AppState {
| final int progress; } class
| AppSelectingLevel extends AppState {} class
| AppPlaying extends AppState { final Level
| level; } ...
|
| Certainly not as neat, but also, not that far off either.
| Then where you use this app state, you could switch over
| its `runtimeType`, and in each clause, the IDE will
| understand which implementation you are dealing with, and
| actually give you context sensitive help related to that
| particular state.
|
| If you instead only cared about one case, you would be
| able to do: if (appState is AppPlaying)
| { doSomething(appState.level); }
|
| Would this be somewhat analogous to the functionality you
| get with unions in typescript?
| kroltan wrote:
| Indeed, that is basically what you get from unions,
| except the exhaustiveness check.
|
| Unless I'm mistaken, if one were to later implement a new
| class that extends AppState, all existing code would
| compile, but possibly fail or misbehave at runtime,
| unless you meticulously checked every place that tries to
| determine something based on those derived types.
|
| In TypeScript, adding a new case for an union and not
| handling it everywhere is a compilation error on every
| incomplete usage site.
|
| For example, try deleting one of the arms of the switch
| in this playground: https://www.typescriptlang.org/play?t
| s=4.2.2#code/C4TwDgpgBA...
|
| I have to say, the default diagnostic isn't brilliant,
| but some tooling will give a better error and actually
| point out the missing arms, instead of complaining about
| the return type.
| okamiueru wrote:
| I suppose. In practice, I haven't experienced this to be
| a problem. Since you already check which implementation
| you are dealing with, any code that relied on any state,
| should still work without any issue. This is the same as
| with typescript unions. Any code that somehow needs to
| handle a new state hm... I suppose getting a compile time
| error is nice to immediately see all places where it is
| used... but, I mean, so would a "find all uses" search.
| It's also not all that different from the linting warning
| error you'd get from iterating over runtime types without
| handling all cases.
|
| All in all, sufficiently analogous to not consider unions
| a missing feature of the dart language? Seems nice to
| have, but, maybe not very necessary. Especially if the
| only difference is whether it is considered an error by
| the syntax, or a warning by the linter.
| svieira wrote:
| The proper analog to union types in Dart (as in Java) is
| enums and / or church-encoding [I _think_ that 's the
| term] generalized algebraic data types (GADTs). E. g.
| something like this:
| https://gist.github.com/jbgi/208a1733f15cdcf78eb5
|
| Scala 2 also had `sealed` classes that could be used in
| places where you needed enums parameterized by runtime
| values and that's been generalized in Scala 3 IIRC.
| okamiueru wrote:
| I'm certainly confused now whether or not we are talking
| about the same thing. Without delving to much on the use
| of the word "union", how would you solve the use case
| presented in the typescript examples using enums?
| vsmenon wrote:
| [Disclaimer: I work on the Dart team.]
|
| The TS code indeed looks cool. This is an area we're
| looking at.
|
| One point, though: we try to be very careful to not
| regress performance or developer iteration time (e.g.,
| type checking time) when we introduce new language
| features. E.g., structural typing can be more expensive
| in general to type check since we need to recurse.
| kroltan wrote:
| Fair enough, that is a meritable goal.
|
| Have you considered not going full-on structural-typing
| but still providing some sort of union? In fact, you
| could go for one with even stronger guarantees, like the
| sum types in Rust or F#. (with Rust going as far as to
| call them enums too)
|
| I'll admit I have the faintest notion on what causes that
| kind of complexity on a compiler, so my suggestion might
| be an even worse idea.
| plorkyeran wrote:
| All of the complaints about flutter I see here are based on
| people _using_ apps built with flutter, and not about the
| development experience. "Have you actually build a project in
| flutter?" is a total non-sequitor response to complaints about
| how even the official demo is miserable to use.
| offtop5 wrote:
| Would you not buy a screwdriver because some people with that
| screwdriver don't build chairs correctly ?
|
| Like with Unity, the power of cross-platform development
| leads many to just assume apps work across platforms
| automatically. This is absolutely not the case, you need to
| properly QA any code you write and code it to accommodate
| each platform's quirks.
| danShumway wrote:
| But these are the official demos.
|
| I would not buy a screwdriver if a salesperson walked up to
| me, said "look how great this screwdriver is" and then the
| chair they were holding as an example immediately fell
| apart in their hands. There's a difference between a dev
| community building apps that perform badly and the actual
| platform advocates showing off apps that can't perform.
| ardit33 wrote:
| This is DOA..... fine for some generic/basic app, but I wouldn't
| touch it with a ten foot pole if you are building a serious app.
|
| This is another attempt from javascript/web front end developers
| trying to unseat native apps.... with the naive promise that is
| truly build once, run everywhere...
|
| It hasn't worked since 1995.... as these frameworks get decent,
| native apps push the envelope and user expectations just increase
| over time, and apps created by these framework just look outdated
| or as toys.
| mchusma wrote:
| We have used Ionic to build once deploy on mobile and web for
| years. It works really well for us now. (I am not sure it would
| work for all usecase but my guess is 99% of non-game apps would
| be fine).
| LocalPCGuy wrote:
| Flutter for mobile apps, cross-platform across Android and iOS
| is pretty amazing. I do not like what they are doing with
| Flutter Web, but that doesn't change that it is a pretty
| amazing framework for cross-platform mobile development.
|
| Also, it isn't FE web devs driving Flutter. I know a lot of
| mobile cetric devs who really love it.
| underwater wrote:
| I don't believe that the idea is fundamentally flawed. Having
| bespoke widgets rather than stock OS ones is pretty standard.
|
| If you can render swipes, fades, blurs and transforms you can
| create premium experiences without being native.
| [deleted]
| dhbradshaw wrote:
| One question that's been in the back of everyone's mind with
| Flutter is "will Google toy with Flutter and then drop it? Or
| will they stick with it and make it the real deal?"
|
| I take this post as partial evidence that they're making this the
| real deal. It's already surprisingly good, and there's reason to
| believe that it will get a whole lot better.
| catmanjan wrote:
| There have been posts like this in the lifetime of various
| killed Google products - it would be nice if they would openly
| admit how many years of funding they've committed
| dastx wrote:
| Honest question, what's Google's angle with flutter? It's one
| thing to be develop a toolkit for platforms they have a vested
| interest in, it's an entirely different thing to create such a
| toolkit for all platforms, including their competition.
| aliyfarah wrote:
| The answer to these types of questions usually boil down to:
| Google wants to improve the web experience for everyone. They
| are the biggest benefactor of the web today, so it makes sense
| they have the most to gain the more pleasant the web experience
| is.
|
| Also I think they are looking to get revenue with their own
| Cloud services that integrate seamlessly with Flutter. For
| example Firebase is the #1 backend most Flutter Devs use.
| mdasen wrote:
| I think there's value in having a certain amount of ownership
| and control of a developer ecosystem. It's open-source, but
| Google will probably remain associated with Flutter and have
| the dominant influence on its future.
|
| I'm not totally sure what you mean by "a toolkit for platforms
| they have a vested interest in". Google has a vested interest
| in basically all the platforms out there. They might create
| Android, but they certainly make a lot of apps for iOS. I'm
| guessing they'd like to simplify things using Flutter. Mac and
| Windows might not see a huge number of native Google apps, but
| that could change over time - especially if they have a way of
| making a web version and a desktop version out of the same
| codebase. Imagine a native macOS Gmail client using Flutter.
| The same code that could compile to JS for the web could
| compile down to native for macOS.
|
| Having something be open source and widely adopted makes a
| language and ecosystem stronger. The Go authors noted that they
| open-sourced Go because it would become stronger as more people
| used it.
|
| And I wouldn't underestimate the soft power that comes from
| being in charge of one of these things. VSCode, .NET Core, and
| TypeScript are all free, but it's given Microsoft a huge amount
| of soft power in the ecosystem and a lot of credibility and
| mind-share.
|
| With a cross-platform UI kit, you can definitely end up with a
| lot of power. Maybe the experience on Android feels better and
| more native because your engineers are putting their effort
| into the Android UI and its patterns more. That's not to say
| that they'd purposefully make the iOS experience bad or
| anything, but maybe the iOS-style widgets don't get quite as
| much polish and maybe developers get encouraged or defaulted
| into shipping Android-style Material Design apps to iOS. Again,
| I'm not saying this is malicious, I'm just saying that Google
| might spend more time on the pieces that are important to them.
| Google's web docs for Flutter could easily include sections for
| "and this is how you hook it up to Google Cloud".
|
| I think it's also important to recognize that while Android has
| more marketshare globally, Apple is generally more popular in
| the US and generally more popular with upper-income folks. Apps
| like Clubhouse often launch as iOS-only. 11 months after launch
| and the Hottest New Thing(tm) is still iOS-only. If Google can
| convince developers to use Flutter for the Next Big Thing(tm),
| it guarantees that it will be available for Android.
|
| I think there's a lot of value for Google. Your teams can build
| better apps in less time cross-platform. You potentially become
| a leader in the way that Facebook has with React, Microsoft has
| with VSCode/.NET Core/TypeScript, etc. You guarantee first-
| class support for your devices. You guarantee that the new
| things you want supported will get supported since you can
| prioritize your engineers on it - and potentially even get
| supported in the way you want. And potentially some nice tie-
| ins to Google Cloud and Firebase via first-class support,
| documentation, etc.
| Grimm1 wrote:
| This looks like a great thing for people who are building web
| apps and need that app presence and want to keep a unified code
| base.
|
| That said React Native is plenty good here even if the language
| ecosystem it's in is a bit of a mess. And I think there's a bit
| of work to do here with regards to the web before I'd adopt
| Flutter 2 for my business.
|
| I tried a few different examples both on my desktop and my iPhone
| via safari and design wise the demos look really good, but the
| experience left a bit to be desired in terms of choppiness, user
| cues where pressing buttons left me wondering if anything
| happened until I saw red highlights around a text box and certain
| things not working, text highlighting is a big one for me and
| something I use all the time on my phone.
|
| I'd definitely try Flutter out for a personal application but for
| my business if I was not going to develop a native app I think
| I'd still go with React Native for now.
| xvilka wrote:
| Flutter-based apps are notoriously big. How are Flutter2-based
| apps compared to that?
| threatofrain wrote:
| > To start with, Canonical is partnering with us to bring Flutter
| to desktop, with engineers contributing code to support
| development and deployment on Linux. During today's event, the
| Ubuntu team showed an early demo of their new installer app that
| was rewritten with Flutter. For Canonical, it is critical that
| they can deliver rock-solid yet beautiful experiences on a huge
| variety of hardware configurations. Moving forward, Flutter is
| the default choice for future desktop and mobile apps created by
| Canonical.
| luplex wrote:
| Does this mean that all those apps are coming/could come to Linux
| phones like the Pinephone and the Librem 5?
| [deleted]
| andrewstuart wrote:
| How can I access AWS SDK from Flutter?
| bilal4hmed wrote:
| maybe look here https://aws.amazon.com/getting-started/hands-
| on/build-flutte...
|
| you have to use the Amplify library from AWS
| colesantiago wrote:
| This is HUGE, an absolute game changer in the cross platform
| space and in competing with electron, my congrats to the flutter
| team on this release.
|
| I anyone using Flutter in production currently?
| bloaf wrote:
| Microsoft seems to be wandering around in the same field, with
| their slow expansion of dotnet & Blazor.
| andrewstuart wrote:
| When a company releases a new technology for building desktop
| applications, the primary thing I look for is a really solid
| fleshed out implementation of a CRUD application:
|
| - sign in to some back end
|
| - create and edit data using forms
|
| - browse data in some sort of datatable/datagrid
|
| - use ajax to GET and POST data
|
| But such a demo is pretty much never there - I certainly can't
| see it in this case. But surely the vast majority of ordinary
| desktop applications people need to build are just this ... CRUD
| with auth, ajax and data browsing.
|
| It would be dramatically easier to give a new technology for
| desktop applications a try if such a demo was provided.
| opwieurposiu wrote:
| Check out https://gallery.flutter.dev/ for a CRUD sample app.
| andrewstuart wrote:
| Can you hone that down to a specific link showing the
| features listed?
| [deleted]
| bilal4hmed wrote:
| I was honestly surprised to see Microsofts name on there as a
| contributor
| bithavoc wrote:
| I'm surprised too, they now have:
|
| - MFC
|
| - WinForms
|
| - Windows Presentation Foundation
|
| - Xamarin & Xamarin Forms
|
| - Universal Windows Apps
|
| - WinUI 2 & 3
|
| - React Native fork for Windows (based on WinUI 2 migrating to
| WinUI 3)
|
| - React Native fork for Mac (based on AppKit)
|
| And now they also contribute to Flutter, wow.
| bliteben wrote:
| You forgot blaze and prob uncountable other projects
| tasogare wrote:
| Classical MS move: spending more efforts on competing
| technologies than on their own (in this case dotnet).
| mikece wrote:
| Even Microsoft realize that Xamarin is not a tool for serious
| mobile or desktop development. Sure, you can get apps that
| work but they are 2.5x larger than if you had written them in
| Java or Kotlin and offer no more features than if you had
| done a hybrid mobile app with Ionic instead. Everyone thought
| Microsoft acquired Xamarin for the mobile dev tooling? No: it
| was the only way they could get the brain trust and the core
| Mono team at Xamarin to come work for them.
| lostmsu wrote:
| That would not be a problem, if you could publish a shared
| runtime in Google Play. Phones are still really bad
| platform.
| FpUser wrote:
| I looked at their demos and was less then impressed. Would've
| probably make more sense to get some mature multiplatform GUI
| capable tool like Delphi add WASM as their compile target and be
| done with it.
| superkuh wrote:
| >Moving forward, Flutter is the default choice for future desktop
| and mobile apps created by Canonical.
|
| This is terrible news. I thought Canonical learned from it's last
| decade of painful failures to converge desktop and mobile. They
| have different needs and it doesn't work. What this means is
| another dark age for the Ubuntu desktop environment.
| oblio wrote:
| Well, Canonical is a graveyard of techs.
|
| Launchpad, Juju, Unity, Mir, Bzr, upstart, heck, I can't even
| remember them all.
| danjac wrote:
| Snap
| damagednoob wrote:
| Still disappointed that Ubuntu Edge never happened:
| https://www.indiegogo.com/projects/ubuntu-edge#/
| amelius wrote:
| The most important question imho: does Google use it for their
| own apps?
| mikkelam wrote:
| I want to love flutter, and I am personally using it in my
| startup, but issues like this one is seriously concerning
| https://github.com/flutter/flutter/issues/76180
|
| I really do believe in flutter's future though. Developer
| experience has been a blast. coming from iOS I've saved so much
| time with hot reload
| efields wrote:
| Flutterfolio.com falls flat on its face on an iPad with kbm. I
| had to toggle to "precision mode" in the upper-leftcorner to even
| make an account. Why did I have to press a toggle to register
| click events? I know ClickEvents and TouchEvents have slight
| differences on the web, but this is a demo web app that shouldn't
| need to consider those nuances to register an account.
| nindalf wrote:
| Toyota is going the Tesla way, with touch infotainment systems.
| Seems like most car manufacturers are headed in this direction.
| My gut says this is probably going to lead to an increase in
| accidents, but I don't know of any dataset that shows it. Let's
| hope this change works out.
| beaner wrote:
| > Google Pay switched to Flutter a few months ago for their
| flagship mobile app, and they already achieved major gains in
| productivity and quality.
|
| I don't know how they can claim this. The new Google Pay on
| Android was noticeably laggier the moment it was released. It
| continues to be so, and I still hate using it. Now I know the
| cause.
| dstaley wrote:
| As long as the old Google Pay app still does NFC payments, I'll
| keep using it.
|
| I was also pretty salty that the new Google Pay app was marked
| as "early release" so you couldn't leave a review on the Google
| Play Store. That's fixed now though.
| jerrycruncher wrote:
| They are likely referring to developer productivity and
| perceived code quality, not user satisfaction.
| ignoramous wrote:
| I don't auto-update _any_ Google app anymore. The amount of
| bloat keeps piling up with each new update. Google 's Product
| Managers, as great as they are, need to seriously slowdown a
| bit.
| eseidelGoogle wrote:
| [Flutter Eng. Dir here]
|
| The initial GPay Flutter release definitely had some
| performance rough spots. We've learned a lot from working with
| that team since release and have made resulting changes in both
| Flutter and the app code.
|
| GPay hasn't released since December last I checked, but I
| expect the next release should perform better on both iOS and
| Android and we will be continuing to work with them closely
| over the coming months.
| f430 wrote:
| I just wanted to commend you guys on Flutter. I've put off
| Android/React Native for almost a decade because of how
| clunky it was and I feel like Flutter finally gets the pieces
| right.
|
| It is refreshing to be able to start development quickly
| without worrying about tooling (react-native), CI, etc.
|
| Also I feel like Dart is perfect. It's a joy to use, I feel
| like this is the future. It's not es6 and it's not Java
| either.
| CyberDildonics wrote:
| How is this still such a problem in the modern era where
| major software is released that becomes unusably slow on
| multi-core cutting edge phones?
| andrekandre wrote:
| just an assumption, but probably because even though it
| comes from the same company, even on android flutter is not
| a first-class citizen...?
|
| iow, maybe they dont have access to all the internal
| implementations that give the native toolkit higher
| performance...
|
| can anyone clarify that?
| f430 wrote:
| Flutter is way more closer to native than react will ever
| be
| f430 wrote:
| What are you talking about Flutter runs butter smooth on
| most smartphones at 60fps, far better than what react-
| native and other half assed solutions on the market.
|
| go ahead and take time to downvote my comments. do you boo
| underwater wrote:
| I had wondered what had happened to this app to make it so
| slow. It takes around 10 seconds to get past the loading screen
| and show me anything useful on an S9.
|
| Those seconds are excruciating when I'm at a checkout trying to
| actually use the app, with a large line behind me and a
| checkout person staring at me.
| codercotton wrote:
| They are dependent on Flutter for Stadia, which is cancelled? The
| disparity is annoying...
| Tokiin wrote:
| Stadia has not been cancelled, they just shuttered the internal
| development studios. The service itself is still alive and
| getting new games frequently.
| meibo wrote:
| Stadia isn't cancelled. The studio is. Stadia itself won't go
| away any time soon.
| timgilbert wrote:
| Indeed, looks like it's got 989 days remaining.
| http://stadiacountdown.com/
| meibo wrote:
| If you'd have any clue of the games industry, you wouldn't
| be saying this.
|
| AAA publishers are pushing heavily for this since it makes
| piracy and hacking obsolete and they always get what they
| want - there's no way that this is not the future of
| "popular" gaming.
| zbowling wrote:
| Stadia isn't/wasn't canceled. Only Google's first party
| development studio was closed. Stadia the platform is still a
| thing.
| zaiste wrote:
| If you're new to Flutter and looking for a gentle, yet practical
| introduction, there's this (free) video tutorial on YouTube:
| https://www.youtube.com/playlist?list=PLhXZp00uXBk5TSY6YOdmp...
|
| (disclaimer: I'm the author)
| davidkuennen wrote:
| I created apps in cordova, react native and now flutter and I
| have to say flutter beats both by a lot. It's just been such a
| nice experience. I'm absolutely in love. My most successful app
| in flutter is https://stockevents.app if you want to try.
| pvinis wrote:
| I just tried your app, and like the droppod.gg app and every
| other flutter app I've tried, there are obvious broken UI
| things. In the watchlist tab, with one item in the list, I am
| able to scroll and make the one item hide behind the navbar,
| and it's happy to stay like that.
|
| These things are big obvious things that make me uninstall an
| app even if I want/need to use it. Again, I don't know if it's
| you or flutter that made this thing behave like that. But it
| makes me think flutter apps are all just one big mess.
| davidkuennen wrote:
| Haha.. Thanks for your feedback and I totally understand. In
| this case tho it's my own fault and not flutters. I wanted
| that fancy AppBar and created that mess myself. I was
| actually planning on fixing all the broken AppBars in my next
| release.
| charrondev wrote:
| The app looks nice but scrolling feels incredibly weird on my
| iPhone XS Max. Did you write some custom scrolling logic or is
| that just how scroll views are in flutter?
|
| There's a bit of chop in the scrolling and it feels completely
| linear, instead of elastic like native iOS apps feel (and
| websites).
| davidkuennen wrote:
| Oh thanks a lot for letting me know. I will investigate this,
| since I really don't know.
| stephenhuey wrote:
| I'm a long-time fan of pure web apps, but in my experience,
| it's more streamlined to develop and ship mobile apps with
| Flutter than with Cordova and some of the other tools that
| package web apps for mobile.
| davidkuennen wrote:
| Yeah I certainly wouldn't use cordova today, but it was very
| innovative when it was released and I love what it did for
| the hybrid space.
| stephenhuey wrote:
| Exactly, and for all the skeptical folks on here, I do not
| feel Flutter will the the ultimate solution, just another
| step forward like Cordoba was for abstracting some things
| and making development faster and easier and paying the
| bills by shipping more stuff sooner.
| cgb223 wrote:
| Has anyone used both React Native and Flutter recently in
| production?
|
| How do they compare?
| andrewstuart wrote:
| OT but I recently did some research on cross platform desktop
| application development for MacOS and Windows.
|
| Here's the options I found.
|
| - (language: Pascal) Delphi applications can now run on both
| Windows and MacOS.
|
| - (language: Python or C++ and QML) Qt applications work on
| MacOS, Windows and Linux..
|
| - (language: JavaScript) React native is being ported by
| Microsoft to both Windows and OSX.
|
| - (language: Kotlin) Kotlin now has "Jetpack Compose" for desktop
| targeting Windows, MacOS and other platforms. It's like "React
| for Kotlin".
|
| - (language: C#) Microsoft Xamarin applications can target both
| Windows and MacOS.
|
| - (language: JavaScript) Electron lets you run your web
| applications as desktop applications on Windows and MacOS.
|
| - (language: Dart) And now Flutter can be added to the list of
| ways to build cross platform desktop applications.
|
| - (language: Java) presumably this is Java's forte but I did not
| look into it.
|
| - (language: Kotlin) TornadoFX - JavaFX framework for Kotlin
| https://tornadofx.io/
| jkelleyrtp wrote:
| Safari doesn't work :( I have WGPU and WebGL2 enabled too...
| tobyhede wrote:
| Flutter is not for everything, but it is really worth a look.
|
| We (AU MVNO/Telco) recently converted iOS and Android apps
| (200,000 MAUs) to Flutter and it has been game changing. We had
| experimented with react native and found it just didn't deliver.
| Flutter is different. On mobile platforms the experience is super
| responsive and smooth and for your typical consumer app
| indistinguishable from the native experience. The tooling and
| developer experience are incredible. The benefits and experience
| where so clear that the whole team was onboard - including the
| most die-hard career platform specialists. Our velocity and
| ability to deliver is measurably better.
|
| We're looking at the web target as maybe "good enough". I don't
| think it could be a replacement for a well-crafted web app, but
| could be used to provide a fast alternative to the primary native
| experience, and for rapidly prototyping and experimenting. In the
| current state, Flutter Web could never replace our highly
| optimised ecommerce funnel - some things you just need to sweat
| the details. But it's definitely better than some of the CX in
| the corners of our legacy applications. Shipping fast is valuable
| - so build for native, get a good enough web for "free" and then
| spend time and attention on the web if it is warranted.
| heavyset_go wrote:
| > _We had experimented with react native and found it just didn
| 't deliver_
|
| Can you expound on why you found that React Native didn't
| deliver?
|
| I've played with Flutter a couple of years ago, and I'm
| revisiting it and React Native before building an app on a one
| person team.
| nsainsbury wrote:
| From what I've seen and has been confirmed quite a few times
| now Flutter definitely does not deliver on producing mobile
| apps that are "super responsive and...indistinguishable from
| the native experience"
|
| You can even find the director of engineering for Flutter
| confirming that's not the case on a thread on Reddit along with
| numerous devs reporting being burned by Flutter and swearing
| off using it ever again:
| https://www.reddit.com/r/FlutterDev/comments/llmkd4/ios_jank...
| randomchars wrote:
| The idea sounds very appealing, especially to an indie developer:
| being able to ship your app on multiple platforms from a single
| codebase is kind of the holy grail. Unfortunately, the result
| is....
|
| I tested this Flutter example[1], on a 16" MBP with and i7, and
| it is janky as it can get, it feels like I'm using a 15 year old
| computer. From the code it looks like the whole thing is...
| rendered on canvas? I'll pass.
|
| [1]: https://gallery.flutter.dev/#/
| ddevault wrote:
| It is very janky, and worse, totally unaccessible, rendering it
| useless (or frustrating at best) for huge numbers of the
| population. And why? It's just yet another shiny web framework.
| We've known how to build websites for decades now.
| notretarded wrote:
| Just wait until you hear about this new technology called
| HotWire! Revolutionary.... /S
| shawnz wrote:
| Agreed... How can they be proud to release such an extreme
| regression in usability and accessibility? It is entirely
| 100% inaccessible for anyone not using a visual user agent.
| And this somehow isn't considered a non-starter?
| qbasic_forever wrote:
| This site physically hurts my fingers to scroll on a trackpad.
| malkia wrote:
| If it's running on canvas, normally you would see
| "unpkg.com/canvaskit-wasm" - and even then it may not be the
| latest (supposedly more optimized) version. For example, my
| simple Super Tic Tac Toe app - uses it -
| https://malkia.github.io/tictactoe/#/ - but the gallery was
| compiled to use HTML, instead of canvas - which would be slower
| (IMHO). I think there is even mixed mode - where it can choose
| one or another ("fat" binary on the web ;)).
|
| Please look at the Source (in chrome) to compare.
| ttt0 wrote:
| It is. I have wasm disabled and it throws an error:
| Uncaught ReferenceError: WebAssembly is not defined
|
| and it includes what you mentioned, unpkg.com/canvaskit-
| wasm@0.24.0/bin/canvaskit.js:150
| malkia wrote:
| Ah, you are right - not sure how I missed it first time,
| but now I see it.
| terhechte wrote:
| Interestingly I've tried it on Brave on a M1, and it is very
| smooth. I also tried their Plasma demo and it was very smooth
| (https://flutterplasma.dev/) but that might say more about the
| M1 than Flutter.
| murermader wrote:
| I just tried it on an iPad Pro with Safari. Clicking the tiles
| does not work, scrolling does not work with the touchpad, and
| overall it feels very janky. They probably didn't care to
| optimize / make it usable with Safari.
| danudey wrote:
| Trying it on Windows 10 with Firefox. Scrolling is incredibly
| slow, in every possible way. The scroll wheel barely moves
| the content, so I have to spin the wheel ten or more times to
| get any reasonable distance down the page, and the animation
| is janky and stuttery.
|
| Works great in Chrome though, what a surprise!
| e12e wrote:
| I'm seriously considering looking at something like
| https://heaps.io/ for cross platform utilities rather than
| flutter etc. i suppose accessability is likely to still be an
| issue, as well as ciustom (not native) widgets -but at least
| the resource usage and interaction is likely to work?
|
| note that heap+haxe is pretty much "the same" as flutter/dart -
| a language, a compiler and a runtime + a rendering engine..
| mda wrote:
| Well, to give counterpoint, just tested on Chrome / Windows
| (ok-ish CPU, decent GPU) all demos are buttery smooth no lag or
| jank whatsoever.
| tigger0jk wrote:
| Just tested https://gallery.flutter.dev/#/crane in Chrome and
| Safari on Mac and if I go to another tab and then back to the
| fly tab it just shows a gray screen. Does not inspire
| confidence.
| sydd wrote:
| I've tested on my phone (1yr old pretty good Android one) and
| the whole thing is very laggy runs with like 10fps. What
| about a11y?
|
| The whole thing feels like Adobe Flex in 2010. It solves a
| great deal of problems that the web had but introduced a
| plethora of others.
| eseidelGoogle wrote:
| [Flutter Eng. Dir. here]
|
| Still relatively early days for Flutter Web, so I would not
| be shocked if it's not buttery everywhere. However, we
| would certainly love to learn more. fluter.dev/support has
| links as to how to file an issue if you're interested.
|
| https://flutterplasma.dev/ is one demo to try. We expect to
| be updating flutter.dev/web and flutter.dev/showcase to
| update more over time.
| deft wrote:
| No, I won't help you. The OP post is about how great
| flutter is and you're in the comments telling everyone it
| will actually be useable soon and asking us to test it
| for you on common browsers.
| [deleted]
| sydd wrote:
| Thanks for the reply! What about a11y? Can you navigate a
| Flutter page via keyboard? What about screen reader
| support?
| timsneath wrote:
| Yes, we consider accessibility a must-have feature. On
| the web, we have a second DOM tree called the
| SemanticsNode tree, which is generated in parallel to the
| RenderObject DOM tree. The SemanticsNode tree translates
| the flags, actions, labels, and other semantic properties
| into ARIA attributes. We've been testing Windows
| Narrator, VoiceOver, TalkBack, and ChromeVox screen
| readers to navigate a Flutter web app.
| marcusjt wrote:
| NVDA is the primary screen reader for 40.6% of them
| (swiftly followed by JAWS at 40.1%) so why aren't you
| testing with it?
| https://webaim.org/projects/screenreadersurvey8/#primary
| mwcampbell wrote:
| So why is FlutterPlasma.dev completely unusable with a
| screen reader even after pressing the "turn on
| accessibility" button? I understand that the actual demo
| presentation might not be accessible, but the intro
| screen should be fully readable, and it's not.
|
| Edit: You may want to add the NVDA open-source screen
| reader for Windows to your list. And when you test with a
| screen reader, make sure you use it the way an actual
| user would when browsing the web, e.g. using NVDA's
| browse mode with the arrow keys to move through the page.
| bsimpson wrote:
| Oooff, the edges in that demo look terrible -
| particularly the grey boxes in perspective. The demo
| boasts that it isn't a video, but the interpolation looks
| as bad as one.
| notretarded wrote:
| >Still relatively early days for Flutter Web
|
| Spoken like a true product evangelist. Good palm off with
| the "create a ticket" too.
| kuschku wrote:
| Have you ever tried one of your demos in Firefox on
| Mobile and Desktop?
|
| They're completely unusable in Firefox. For example, it
| only scrolls 3 pixels per rotation of the scroll wheel on
| Windows 10
| oblio wrote:
| Firefox is on the Google chopping block. They won't admit
| it but they're killing it by a thousand CSS cuts.
| SanderNL wrote:
| Why are you guys here on HN still using Chrome? There is
| literally not a single reason I can think of to be
| supporting this behemoth that is killing the open web.
| Firefox is excellent actually and Firebug IMO is far
| superior to Chrome's offering. I understand non-techies
| using it like they used Explorer, but come on guys.
| oblio wrote:
| Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0)
| Gecko/20100101 Firefox/85.0
| tcit wrote:
| > Firebug
|
| Which year is this ?
| sriku wrote:
| Sorry but the plasmadev demo doesn't pass muster compared
| to 60fps animations we were able to do years ago with
| html+js. Something about the renderer approach is causing
| hiccups in the animation.
|
| "Buttery smooth animations and scrolling" will be a great
| selling point for flutter ..if it actually works.
|
| (Firefox)
| sriku wrote:
| I'd say a goal of "do useful stuff extremely well and
| complex stuff reasonably well" would make for a good
| demo.
| qbasic_forever wrote:
| The plasma demo you linked runs at a stuttery 40fps on
| Firefox (ubuntu 20.10) on a quad core Ryzen 5 laptop. The
| fans immediately spin to max speed. I'm not impressed...
|
| Here's a hard question, why is this surprising to you?
| What are you missing in development--is this a gap in
| testing? Are you hamstrung without support internally to
| bake this as long as it needs? Rather than double-down on
| extolling the virtues here, it's time to double-down on
| fixing the team and the product.
| agucova wrote:
| I got 14 fps with heavy stuttering and freezing with my
| i5-9300H with 8 cores :(
| marcusjt wrote:
| FWIW the plasma demo runs at something like 50fps in
| Chrome on my 3yr old Samsung Galaxy S9, and only a bit
| worse in Firefox (perhaps 40fps) - so they are not
| buttery smooth experiences, but neither are they
| terrible.
| dbjacobs wrote:
| On my iPhone 12 mini the demo took 13 seconds to show me
| something besides a blank screen. On my desktop it was
| around 3 seconds and cpu usage went through the roof.
| skavi wrote:
| Another data point is the new flutter Google Pay app vs the
| old version. On my iPhone 11 Pro, the former is incredibly
| laggy. The latter is as smooth as you'd expect given the
| hardware.
| ROARosen wrote:
| iPhone 6s, the new Google Pay app is disastrously laggy
| to point of being unusable
| onion2k wrote:
| Is that a counterpoint? To me that tells me performance is
| going to vary between users computers, possibly due to
| something other than resources. That means the experience I'd
| be delivering won't be consistent and I probably won't be
| able to fix it, or even replicate it, reliably. Something
| that's janky everywhere can be profiled, debugged and
| possibly fixed. Something that has an unknown problem that
| only affects some users is far more problematic.
|
| That isn't a counterpoint to say the language might be worth
| considering. That's an additional data point to give me
| reasons to not use it yet.
| adam12 wrote:
| No jank in Firefox. It does take 10 scrolls to move 6 inches,
| though.
| cybuerg wrote:
| That sounds pretty janky to me...
| Dylan16807 wrote:
| Jank as in stuttering, not as in shoddy.
| anthk wrote:
| > and it is janky as it can get, it feels like I'm using a 15
| year old computer.
|
| Ironically computers 15-20 years ago with native software ran
| much, much much faster and snappier. KDE3, XFCE, even Windows
| 98SE and XP were much faster. They were crippled by disk I/O,
| true, but once the software loaded, the feedback was
| _inmediate_.
| JohnTHaller wrote:
| Really bad on Firefox on Windows 10 64-bit (latest) with an
| i7-7700k and GTX-1060 6GB as well
| ryanwhitney wrote:
| Wow, this is some of the worst scrolling I've experienced on
| the web in a long time. Incredibly weird and not smooth at all
| on both a newer iPhone and Mac. Can't copy text either.
| reddotX wrote:
| works fine on Ubuntu 20.04 / linux (4year old i5)
| gagege wrote:
| What's up with scrolling on all these demos? It feels insanely
| slow and jerky.
| etaioinshrdlu wrote:
| I think this particular demo might also just be a badly
| designed demo.
| randomchars wrote:
| Well, this was the most prominently featured demo. Is there a
| demo somewhere that's not badly designed?
| agersant wrote:
| As a hobbyist Flutter user, I would like to be excited for this
| release.
|
| However, this announcement page does not do a very good job at
| highlighting changes and new features from Flutter 1. The only
| concrete feature mentioned is the web platform being stable.
| Everything else is old news or plugging random companies.
|
| The changelog
| (https://flutter.dev/docs/development/tools/sdk/release-notes...)
| looks like a dump of the VCS history, which is also useless.
| Sample changes:
|
| - [flutter_tools] HACKTOBERFEST (cla: yes, tool)
|
| - [manual roll] Roll Engine from 1ef10b240e28 to f84e7a019663 (12
| revisions) (cla: yes, engine, team, waiting for tree to go green)
|
| - use_is_even_rather_than_modulo (a: accessibility, a: tests,
| cla: yes, f: material design, framework, team)
|
| I would strongly suggest adding editorialized release notes for
| developers.
| okamiueru wrote:
| I have to agree with you. Maybe especially as someone coming
| from using flutter exclusively for app development. Someone
| joked about this at work "wait, so flutter 1 did not enable
| developers to create beautiful, fast and portable apps for any
| platform?"
|
| I had a vague idea that flutter 1 had a desktop/server like
| backing so that it could be used to develop desktop apps. Maybe
| this was incorrect, and only possible now with flutter 2? I'm
| still confused. This app: https://rive.app/ was made using
| flutter 1, no? It runs in the browser, so maybe this is the key
| difference with flutter 2, that... it allows native apps?
| timsneath wrote:
| You're right! This isn't an exhaustive listing of the features
| in Flutter 2 or changes since Flutter 1.12 (which was our last
| stable release). For that, there's a separate article:
| https://medium.com/flutter/whats-new-in-flutter-2-0-fe8e95ec...
| zmmmmm wrote:
| Reading all the comments it sounds like Flutter is exactly what I
| feared would come out of things like WebAssembly - a trojan horse
| to bypass web standards and turn the browser into a shell for
| shipping applications that put all the power back in the hands of
| application vendors and take away the power that open standards
| give to users (portability, accessibility, customisability,
| interoperability etc etc).
|
| Of course, it will be achieved by delivering amazing developer
| experience and engineering in parity in all kinds of ways so this
| doesn't look obvious. But in the end, that is what it will be.
| Hixie wrote:
| (I was previous editor of the HTML standard for ~10 years, now
| I'm the Flutter TL)
|
| I mean... you're not wrong. But let's be honest, we never
| managed to really deliver on the web's promise here. It was
| <table> and <font> in the 90s, it's WebGL+Wasm now, but the
| reality is we've never succeeded at true portability (ever
| tried going to a non-trivial site in lynx? or a web app on your
| phone?) or accessibility (just ask anyone who uses a screen
| reader how accessible the web truly is) or customisability
| (have you _tried_ creating a user style sheet?) or
| interoperability (I spent a literal decade just trying to clean
| up the mess around HTML parsing and that was the success
| story!).
| zmmmmm wrote:
| Maybe you aren't giving yourself enough credit?
|
| I just typed this comment using a plugin that gives me vi
| bindings inside the editor, on a page where I have increased
| the font size to 110% because I personally find it nicer that
| way.
|
| All done without the permission of ycombinator and yet
| working perfectly with their web page. And this is not just
| because ycombinator has very basic HTML ... this works with
| at least 90% of web sites I go to.
|
| It may not have achieved its loftiest aims, but I think the
| open web is an absolutely amazing achievement and success if
| you compare to what we would have had without it.
| Hixie wrote:
| HackerNews uses tables for layout, inline styles, and still
| forces browsers into quirks mode. Yeah, it can handle
| slightly bumping up the font size. I can also bump up my
| font size on Windows, macOS, and Android, and that works
| for 90% of apps there too.
|
| I agree that the open web is an amazing achievement. I
| don't think Wasm and WebGL take away from that at all. It's
| just the next logical step to make the web possible for an
| even greater set of applications.
| ahmedfromtunis wrote:
| This is definitely interesting; I'm so tempted to try this.
|
| But the question that comes to mind with this kind of the
| technology from Google: is there any mandatory Google services
| that I'd have to use? Just as an example: Do I have to use
| Google's ad platform or I can use any other service?
| distribot wrote:
| I think this kind of lock in doesn't exist because you can
| create bridges to native code anywhere in the code.
| bilal4hmed wrote:
| you dont have to use any google services to work with flutter.
| DodgyEggplant wrote:
| for now
| anderber wrote:
| I've never developed with Flutter, but one of the nicest, fastest
| app I've ever used, Natrium, is built using it. Which to me makes
| me very interested in developing with Flutter.
|
| https://github.com/appditto/natrium_wallet_flutter
| reader_mode wrote:
| I'm currently 5 months into developing a mobile app for a startup
| with flutter and my experience so far is very underwhelming.
|
| Flutter as a framework is not the worst but far from best, it's
| very OO while trying to use reacts vdom model which just wants to
| be functional.
|
| The biggest limitation of the platform is Dart - it's a horrible
| language that should have died once TS and ES6 became mature
| enough. And I've used dart back when it was supposed to be a JS
| killer shipped with browsers, used dartium to build a MVP for an
| app using Angular Dart durgin the betas.
|
| Back then Dart was miles ahead in terms of tooling and JS the
| language didn't even have async/await - so I was singing it's
| praises. But the language stagnated and it's fundamentals with a
| nominal type system and a closed object model make the language
| so inflexible and full of boilerplate it's incredible. It's very
| much like Java (the language, without the powerful ecosystem) and
| people prefer Kotlin for frontend for a reason. C# is similar but
| they figured out that they need to build a lot of things in to
| the language to reduce the boilerplate so they are adding stuff
| like Records and pattern matching.
|
| If you look at state management patterns in flutter there's
| probably 5-10 competing approaches all lacking in their own way
| and all severely hampered by how unexpressive dart is. Or how you
| deal with serialisation/immutability/etc.
| xvilka wrote:
| Would have been be nice if they provided a way to use Kotlin
| Native as a language for Flutter instead. Not a JVM Kotlin of
| course, because it's too slow for the native mobile apps. Or,
| even better, Rust. That would be very impressive.
| Hixie wrote:
| If you prefer Kotlin you may find
| https://developer.android.com/jetpack/compose more to your
| tastes.
| lvass wrote:
| All the highly optimistic claims from the blog post and HN
| comments would be a bit believable if someone could just show us
| a web demo that doesn't suck hard. Or show us something
| accessible at the very least.
| symlinkk wrote:
| I don't think Flutter offers enough value over Electron to
| justify learning Dart and leaving behind the vibrant tooling and
| package ecosystem that JavaScript has.
| poppafuze wrote:
| flutter...more like stutter
| mchusma wrote:
| I will give a shout out to Ionic. We use it and love it. I think
| it accomplishes what Flutter tries to, but with web standards.
| yoavm wrote:
| The real news is buried a little towards the bottom:
|
| > Today we're announcing the beta release of Google Mobile Ads
| for Flutter, a new SDK that works with AdMob and AdManager to
| offer a variety of ad formats, including banner, interstitial,
| native, and rewarded video ads. We've been piloting this SDK with
| several key customers, such as Sua Musica, the largest music
| platform for independent artists in Latin America, and we're now
| ready to open the Google Mobile Ads for Flutter SDK for broader
| adoption.
| garrtt wrote:
| > Google Pay switched to Flutter a few months ago for their
| flagship mobile app, and they already achieved major gains in
| productivity and quality. By unifying the codebase, the team
| removed feature disparity between platforms and eliminated over
| half a million lines of code.
|
| from pay.google.com
|
| > Starting April 5, you won't be able to use pay.google.com to
| send and receive money from other people. To send and receive
| money, use the new Google Pay app.
| alfalfasprout wrote:
| Google pay is utter trash. Crashes and super slow. What quality
| are they talking about??
| [deleted]
| shepherdjerred wrote:
| The easiest way to get rid of 500,000 lines of code is to
| delete your website
| oh_sigh wrote:
| The website and the app are two different things.
| buzzy_hacker wrote:
| > the team removed feature disparity between platforms
| ewindal wrote:
| Still doesn't explain why you think removing LoC in a
| mobile application removes features from a web application.
| ComputerGuru wrote:
| The web application was deleted. That means there is no
| feature parity to factor into consideration.
| rp1229 wrote:
| The new Google Pay app on iOS is incredibly sluggish --
| animations stutter, switching pages has hesitations. I'm not
| sure what they mean by "quality" in this case.
| eseidelGoogle wrote:
| [Flutter Eng. Dir here]
|
| We were also not satisfied with the performance of the
| initial GPay release. We've been working with the GPay team
| the last couple months and have made significant improvements
| within both Flutter and the GPay app. Hopefully the next
| release of GPay will be out soon and others will be able to
| see the progress we're continuing to make with the team.
| [deleted]
| ywei3410 wrote:
| Hi,
|
| Could you elaborate on some types of applications which
| wouldn't or would be a good fit for Flutter at the moment?
|
| There's a lot of comments and links to applications both
| working and non-working; but I don't really have a good
| gauge as to what works and doesn't.
| rubicon33 wrote:
| Flutter used to be such a great experience, but something
| happened ~6 months ago that totally derailed it.
|
| It brings my late 2016 MBP to a crawl if I am building on
| iOS simulator.
|
| After reading online about it being related to Metal, and
| needing to switch flutter channels, trying that, and still
| seeing no success... I just gave up on Flutter (for now).
|
| Maybe Flutter 2 has resolved this?
| eseidelGoogle wrote:
| [Flutter Eng. Dir here]
|
| I would love to learn more about your experience. Would
| you be willing to file an issue and either post it here
| or CC me on it?
|
| flutter.dev/support
| ignoramous wrote:
| Thanks.
|
| Not related to Flutter but Google in general: I recently
| hit a hard-to-reproduce bug with Jetpack's LiveData for
| which there's already an open issue created by a third-
| party developer. I don't recall but it had been open since
| 2018 with no updates whatsoever from Google engineers on
| its progress.
|
| And therein lies a frustrating problem for engineers not
| working at Google but using Google tech. There is simply no
| alternate universe where a third-party team gets the level
| of access the way you described the Google Pay team did.
|
| Of course, it helps that the stakeholders are in the same
| company, but my point is, shouldn't there be a Flutter
| Foundation where every developer can feel at home on equal
| footing with other Googlers? Flutter is so promising, and
| yet, at the same time, I don't want to end up being slave
| to its complexities with no way out as a third-party small
| development shop.
|
| Despite that, I'm 99% porting my cross-platform app to
| Flutter after strong reviews from other developers I know.
| Hixie wrote:
| I can't speak for Jetpack, but as far as Flutter goes:
| Flutter is open source, we do all our work in the open.
| File a bug; we look at all our incoming bugs and there
| are members of the Flutter team (volunteers as well as
| people from Nevercode and Google) who try to reproduce
| each issue. We don't always have the bandwidth to fix
| everything, but last year we fixed roughly as many bugs
| as were filed, so the odds are pretty good. (And of
| course you're welcome to try to fix the bug yourself, we
| accept PRs from anyone, not just Googlers. See our
| contributor guide on GitHub.)
|
| We don't have an official foundation, but we are already
| operating more or less as openly as we would if we did.
| We have contributions from lots of companies and
| volunteers; the majority of the people who have
| contributor access in fact aren't from the Google Flutter
| team.
| distances wrote:
| Android development is like that; you hit a framework
| bug, you'll expect it will never get fixed. Just find a
| workaround and accept it's what it is.
| ROARosen wrote:
| > We've been working with the GPay team the last couple
| months and have made significant improvements within both
| Flutter and the GPay app
|
| So seriously, how can you reassure any indie dev _not_
| getting VIP support to optimize their app for laggyness,
| that they can easily produce a decently performant app?
| Hixie wrote:
| Many of the lessons we learn with GPay directly fed into
| improvements in the framework, improvements in our
| tooling to make this kind of debugging much easier, and
| better documentation to try to scale the knowledge to the
| whole community. Some of these have already shipped (see
| e.g. new features in our DevTools) and much more will
| continue to deploy over the coming months.
| bkm wrote:
| Relevant:
|
| https://www.reddit.com/r/FlutterDev/comments/jwmepu/very_po
| o...
|
| https://thomasmiddel.medium.com/flutter-its-poor-ios-
| perform...
| greatgib wrote:
| so, if I read you well, you agree that Flutter or what you
| did with it clearly sucks?
|
| But still, you don't care that the Google blog post lie by
| telling the opposite of the real dev experience and the
| application user feedbacks?
| dmitriid wrote:
| The ad:
|
| > Google Pay switched to Flutter a few months ago for their
| flagship mobile app, and they already achieved major gains
| in productivity and quality.
|
| And then, the reality:
|
| > We were also not satisfied with the performance of the
| initial GPay release.
|
| Ah, the classic false advertisement.
|
| Let me re-write the ad for you:
|
| > Thanks to several-months-long involvement of Flutter's
| development we could finally fix some of the issues
| plaguing our app that we re-wrote in Flutter. We're still
| not close to the release, and we only hope it will be
| better.
| sofixa wrote:
| On Android too. It literally takes 15-20s for it to charge
| enough for me to be able to select anything.
| jasonvorhe wrote:
| It's not clear what you're arguing for or against. Google Pay
| is a product with multiple features and one of them is being
| phased out. What's that to do with the benefits they're
| claiming from the rewrite of the mobile app?
| garrtt wrote:
| > removed feature disparity
|
| After April 5, I will have to use the app so that I can get
| back functionality that I once had on the web.
| fastball wrote:
| Let me try:
|
| > Flutter 2 supports web now!
|
| > We've re-written GPay in Flutter 2!
|
| > We're dropping support for using GPay on the web...
| dimator wrote:
| That doesn't follow. There's any number of reasons the web
| app would be shut down, usage statistics being the most
| likely.
| fastball wrote:
| Yes, exactly, it doesn't follow. You've just re-written
| your app using a framework that allows you to run one
| codebase in multiple places, including the web, and
| instead of _doing that_ , you decide that you no longer
| want to support the web at all.
| oblio wrote:
| They claim a huge reduction in source code line count.
| After they've just decommissioned their web app...
| ehsankia wrote:
| The web version isn't shut down, but losing crucial
| functionality. If Flutter let's you run the same code
| across multiple platforms, then what reasoning is there
| for one platform getting less functionality after
| switching to a framework that, if anything, should
| increase cross platform feature match.
| AlphaSite wrote:
| I think it's disingenuous to imply that the savings were
| purely from sharing a code base vs removing features.
| SamBam wrote:
| "I have a website and a mobile app. I unified my codebase
| with Tool X and saved a million lines of code!"
|
| "Didn't you simply delete the website?"
|
| "Yeah, what of it?"
| adam12 wrote:
| I have confused Google Pay with Google Play twice this week. I
| wonder how many other people get confused by this.
| kureikain wrote:
| I want to love Flutter. But once looking at it, it's a no go.
| It's the new flash. Really, you cannot copy the text anymore.
| React native is my goto solution now.
| merrvk wrote:
| Yeah I feel the same, love the idea but I'm never going to be
| able to convince a team to drop TS for dart..
| okamiueru wrote:
| I would expect you to have come from a react background then?
| When evaluating technologies 1.5 years ago for the company I
| work at, I took a good look at comparing both react native, as
| well as flutter, and we decided on flutter.
|
| Now, out of the many considerations we had, in this process,
| "cannot copy the text" is... well, I have no idea what you are
| talking about. Are you referring to not being able to do this
| in a EditableText widget, and if so, have to tried a
| `TextField` with `enableInteractiveSelection: true`?
|
| I mean, there should be hugely more important development
| concerns when evaluating these things, than... a brief
| rejection based on something as trivial as that. Then again, I
| won't presume to know your situation or the criteria you had.
| But it does strike me as a bit... shallow reasoning.
|
| I can say, that for our case, the dependency hell that you more
| easily get with React Native was what put me off completely.
| [deleted]
| kroltan wrote:
| Looks like a very developer/product-owner-sided opinion, not
| being able to select text and other "trivial" things are what
| makes software tolerable and actually usable, as listed by
| sibling post by kevincox, I'll quote:
|
| > Yup. I would also like to open links in new tabs, view
| images, copy links, search on page, use browser extensions...
|
| Throwing away all platform conventions is a very heavy-handed
| and user-unfriendly way of bringing about portability.
|
| Another triviality, for example is the behaviour of scroll
| chaining as compared to my browser: In Flutter, as soon as
| the inner scrollable hits its boundary, the outer scrollable
| takes over, while the expected behaviour for me would be for
| the outer scroll to not move until I reposition the mouse.
|
| It's exactly the same as Microsoft's Windows 8 fiasco, by
| unifying the experience across platforms every one of them
| felt broken and contrived, and this effect is even more
| notable if your application deals with a more diverse user-
| platform ecosystem. Your app will be the odd one out that
| works strangely compared to everything else in every system.
| okamiueru wrote:
| I do appreciate your point of view on this, and I hope I
| did not come across as dismissive of your choice. If it was
| a thorough evaluation of the capabilities, and it did not
| seem able to provide the user interactions you needed, I'm
| sure that is then a reasonable enough basis. My knee-jerk
| reaction however, was to think this might have been made
| without properly evaluating the capabilities of the
| platform. If I head over to
| https://gallery.flutter.dev/#/crane, I am annoyed by how
| "app-like" it feels. I'm in a browser, I should be able to
| select tings. Clicking and dragging isn't supposed to
| scroll, it's supposed to select. It feels all wrong. But
| then again, this was mostly when coming at it from a "this
| is a website" approach. If the use case is to develop an
| app, then the conventions used have not felt weird to me.
| kroltan wrote:
| Fair enough, and sorry if I seemed a bit combative too.
|
| However, I believe "this is a website" or "this is an
| app" is a perspective the user will take, despite what
| our intentions as creators were, and so, the safest bet
| would always be assume what is the norm for the platform,
| since the user would never be "disappointed" by that even
| if they expected an app-like feel. On the Web, (at least
| some, in my anecdata most) people expect to see Websites,
| even if highly interactive ones.
|
| I have not tested Flutter in a mobile application so I
| wouldn't be able to tell if it feels par to the course
| with other mobile applications, so it might be viable if
| you only need "Android<>iOS" portability.
| okamiueru wrote:
| I'm glad we can be nice, stalking and all :D. I think
| those are very valid points, and I think Flutter has a
| much more natural place as a framework for mobile apps,
| or desktop software. The gallery showcase feels like a
| half-assed attempt at creating web-site like pages, that
| as you pointed out, all feel wrong. So using flutter to
| develop something like that, I think I'd have agreed with
| you. However, from just the app side, I do feel flutter
| developers have made the UX very much in line with that
| of apps. I rarely know if an app is made using flutter,
| or pure android (as for iOS, I have no clue. The
| cupertino stuff looks like iOS to me, but I also have no
| clue).
|
| I'm also not entirely convince that native apps with
| flutter is a good thing, especially considering that I'll
| be just another attempt at providing an opinionated UX
| stack that is completely different from that of the
| native experience.
|
| So, maybe we agreed more than we thought. I also believe
| that a native experience, one that matches the otherwise
| existing UI interactions should be king. Throwing App UX
| paradigms into website or desktop app bound to feel
| terrible. Maybe it can be made more enjoyable to use with
| better configurations more in line with the respective
| platforms.
| shawnz wrote:
| Breaking common user affordances (e.g. the back button,
| bookmarks, text selection, copy and paste) is indeed a big
| concern in the apps we make at my workplace and I would hope
| that's the case anywhere that values a positive user
| experience.
| Dylan16807 wrote:
| Ability to copy text is less something I worry about as a dev
| and more something I worry about as a user, where I then hope
| nobody uses this thing.
|
| It's not trivial.
| eulers_secret wrote:
| > you cannot copy the text anymore.
|
| Isn't this a feature? Having text easy to copy and paste is a
| copyright problem for many sites. Same with being able to save
| full-resolution images. It's pretty common to see a copy/paste
| in forum comments to get around a paywall.
|
| IMO either this or some other webassembly view is the future,
| simply because it's great DRM. Sure, you can circumvent it, but
| most people cannot.
| whalesalad wrote:
| Interesting rationalization. Don't you think copying text is
| the norm and not the exception?
| eulers_secret wrote:
| I do think it's the norm, and very much dislike this trend.
|
| I should make my position more clear: I hate this stuff
| with a passion. But, big business wants better content
| protection, and big money always gets what it wants - very
| few exceptions there. I wish we could do something as
| technologists who want to keep these features of the web;
| but against trillion dollar companies I know who I'd bet
| for...
| whalesalad wrote:
| With that attitude they will continue to win!
| ttt0 wrote:
| It's the same argument as with DRM. I can just screenshot
| the text. It doesn't solve anything and only makes it
| painful for the average user.
| tvolkert wrote:
| Flutter team member here. In Flutter, the developer consciously
| decides which text should be selectable (and thus
| copy/paste'able), so while it's true that text is not
| inherently selectable in a Flutter app, text that the app
| developer decided to make selectable will be.
| onli wrote:
| Come on. Isn't this only happening because the initial text
| widget did not have text selection, the one with text
| selection came later and now we are in this bad situation?
| Just enable text selection for both/all text widgets when
| targeting the web. You could couple that with a major version
| increase...
|
| This feedback you get here will only get worse with time, and
| it _will_ block adoption.
| mdoms wrote:
| Question for the flutter devs - have you ever used The
| Internet?
| fastball wrote:
| Have you?
|
| https://developer.mozilla.org/en-US/docs/Web/CSS/user-
| select
| mdoms wrote:
| Yes I have, which is why I know text can be selected by
| default in every web environment.
| michaelmrose wrote:
| As a user I don't want the developer to need to anticipate
| which text ought to be selectable as they will inevitably
| fail to consider some use cases it ought to be the default.
| [deleted]
| wffurr wrote:
| I get that user-select was already a thing in CSS, but why is
| so much of the text in the demos at
| https://gallery.flutter.dev/ not-selectable? It's a real bad
| look.
| selykg wrote:
| This sounds awful. Like some sort of bullshit DRM in a way.
|
| Now I'm thinking of all the ways I could get screwed here.
|
| * Not being able to copy transactions from my bank account
|
| * Not being able to easily send text to a read-later service
| (not sure if this necessarily depends on selectable text, but
| who knows, maybe selectable means the text isn't visible to
| these services now)
|
| * Not being able to easily copy something that needs entering
| into another page
|
| This reminds of sites that try really hard to NOT allow
| password managers, or even allowing pasting of text into form
| fields.
|
| Pass.
| fastball wrote:
| You know devs can already make text not selectable on the
| web, right?
| capableweb wrote:
| Flutter: defaults to unselectable
|
| Web: defaults to selectable
|
| Flutter on Web: defaults to Flutter, not Web
| [deleted]
| shawnz wrote:
| I'm not happy about "user-select" not having an easy
| override. But at least it can be overridden by a user CSS
| file or a browser extension, which isn't so bad. This is
| much worse.
| SamBam wrote:
| It takes work _to_ make it non-selectable. In Flutter, it
| defaults to non-selectable.
|
| Most of the time a dev isn't thinking "I'd better make
| this selectable," because they simply aren't going to
| think of all the reasons someone might select text.
| They'll think of the obvious-to-them cases, and leave all
| the other text as unselectable.
| Hixie wrote:
| It doesn't really default to anything. There's a widget
| for selectable text and a widget for non-selectable text.
| selykg wrote:
| Was not aware of that, thanks for letting me know. In
| either case, it's a dick move and shouldn't be
| encouraged.
| catmanjan wrote:
| Flutter should pick sensible defaults, in this case most
| agree that text should be selectable
| kroltan wrote:
| Yes but on the web you can use a user-agent that doesn't
| care about what the site says should be selectable, or at
| least an extension that overrides the CSS in question.
| monkeybutton wrote:
| I use the select text -> web search feature in Chrome all
| the time to quickly look up definitions of words. Breaking
| this will be really annoying to anyone reading webpages in
| a 2nd language than their own.
| greatwhitenorth wrote:
| Why can't the default be always selectable? Let the developer
| choose which ones they don't want to be selectable. Also,
| what is the use case for non selectable behavior?
| cure wrote:
| Oh boy, that is a spectacularly bad idea.
|
| Not only is this making it easy for app developers to do the
| wrong thing ("I will just put some text here and make it
| unselectable, that is going to be great UX") but even worse,
| it is the default?
|
| There are going to be some unintended consequences here, I
| suspect.
|
| This reminds me of those websites that use javascript to
| preventing pasting into password fields "because security",
| thus breaking everyone's password managers, and making
| everyone less secure in the process ("if I have to type in
| that password every time, I'd better choose something simple
| I can remember...").
|
| So, what about accessibility? If the text is not accessible,
| how are screen readers going to work?Vision impaired people
| are just going to have to ... do what, exactly? Will they
| have to apply OCR to access the content of a Flutter app?
|
| This really reminds me of what was so sucky about Flash. I
| guess we'll get lots of little walled gardens that make basic
| interaction via text deliberately difficult. This feels like
| the opposite of the open web.
| LocalPCGuy wrote:
| In the context of the web, this seems like it should be a
| non-starter. Why should the developer be able to tell the
| user what can and cannot be selected?
| fastball wrote:
| Um. You can do this in HTML/CSS too.
| jamil7 wrote:
| Except it's opt in rather than opt out.
| themacguffinman wrote:
| They already can, CSS has a property called "user-select"
| that can be set to "none". It's pretty common to disable
| user selection on label text that isn't expected to be
| copied.
| mkl wrote:
| This is annoying, but is at least trivial to get around
| with browser debugging tools. The web developer is not
| the person whose expectations matter. Selecting label
| text is almost essential for being to explain to someone
| else how to do things, or communicate about the interface
| with the site developer.
| themacguffinman wrote:
| Depends on the label, it's not essential for plenty of
| things. I don't, for example, need to copy "Cancel" in my
| browser before I am capable of talking about the cancel
| button in the UI. You're right, user expectations are
| what matter, and users do not expect most buttons and
| controls to be text-selectable. It was never an
| expectation in native apps while users find it
| frustrating when control labels unexpectedly seep into
| blocks of text they are dragging to select.
|
| Most users don't open devtools to workaround this (Safari
| doesn't even enable devtools by default). While it's
| annoying when developers get it wrong (put "user-select:
| none" on things that should be selectable), this changes
| very little for the vast majority of web users.
| danShumway wrote:
| But it changes quite a lot for _me_.
|
| "This thing that will noticeably make your web experience
| worse won't affect John over there, so why are you
| complaining" is not the best response.
|
| I like to be able to override developer decisions about
| what text is and isn't selectable, and Flutter basically
| makes that impossible.
| tofuahdude wrote:
| Wow, that is a remarkably terrible default behavior.
| Virtually all other platforms behave in the opposite manner.
|
| If the goal of the environment is to provide a new standard
| for cross-platform development, your default behaviors are
| extremely important decisions.
| neurostimulant wrote:
| Would adblockers work on these kind of webapps? Adblocker
| typically look for specific piece of js files and DOM nodes to
| block ads, but Flutter web doesn't really work like that, no?
| kevincox wrote:
| Yup. I would also like to open links in new tabs, view images,
| copy links, search on page, use browser extensions...
|
| I can see it being useful for games and similar where there
| isn't really any UI but even then I would want dialogs and
| similar to use regular text that I can copy.
|
| I am definitely not looking forward to flutter on the web. I
| foresee a lot of websites that I will need to avoid.
| pieno wrote:
| But do you really need that as a requirement across the boars
| for all apps? How many times have you wanted to save an image
| or copy text from a UI element in a native app? (eg. a save
| icon and "Save" on a button) How many times have you been
| frustrated in a web app that when you search using the
| browser you are getting results from UI elements or "app
| chrome" instead of the actual content that the web app is
| displaying? Isn't it enough to have some fields with content
| a user actually would want to copy/search, which would be set
| based on the component type you are using and can be
| overridden per element if needed?
|
| The only thing I do get is that you'd want open in new tab
| and copyable links. However, that's hard from a developer
| perspective as you have to make sure you create links that
| store all data needed to rebuild the same UI in the same
| "conceptual" context but a different underlying data context
| (logged in user may be different, data may have changed so
| some saved context has become stale). You'll likely end up
| spending an awful lot of time to cater for all the unexpected
| things that may happen when someone just clicks a link copied
| from the address bar or a link by another user 2 days before,
| that may have been the result of that second user clicking
| through 10 levels deep in your app with all sorts of filters
| and options based on the state of data at that exact time two
| days before the first user clicks the link. Obviously you
| can't show them the data from two days ago, but what if the
| data is still there but the path to get there is different?
| Does it conceptually still make sense to show the data and
| perhaps some breadcrumbs showing the new path? Or should you
| just say sorry that data isn't here anymore? That depends
| entirely on what the data is and what you're users are trying
| to do, so you can't build one-size-fits-all technical
| solutions for this (if that were even possible). How are you
| ever going to reliably rebuild the UI and context that the
| first user intended to share by copying the link without
| spending huge amounts of time? That requires actual business
| logic and functional design.
|
| For a lot of apps, it may make more sense to just have a
| share button in some places where you actually and
| intentionally support this (and where it will be actually
| used by a substantial number of users). Less time spent on
| developing things that are hugely complex and very little
| used (on average per state for ALL your different UI states
| that you have links to somewhere in the app, even if it's a
| typical line-of-business master-detail form with some filters
| for the master list and a details segment with a dialog box
| or expanded element showing additional details of a certain
| property).
___________________________________________________________________
(page generated 2021-03-03 23:01 UTC)