My problem with Flutter is that it requires the developers to track and maintain parity with native widgets on both platforms; this is a massive undertaking and one that is prone to bugs and subtle mistakes. This is especially a problem for something backed by Google. This downside is not a problem for e.g. React Native which utilizes the platform's native widgets.
Flutter 2
561–570 of 780 posts
Re: Flutter 2
#562Earlier quoted context omitted.
I don't understand how breaking accessibility with Flutter wouldn't mean that companies that use it on the web are violating the ADA.
I don't know what that is but I assume it's some kind of American nonsense I don't care at all about.
Multiple countries around the world have legal standards around accessibility. Then you have the ethical, DE&I, and business reasons to enable disabled users equal access to the web platform and apps through screen readers and other assistive technologies, i.e., accessibility.
It’s certainly not a uniquely American concern.
Re: Flutter 2
#563Earlier quoted context omitted.
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…
I am a native app developer. I have only built one small app with Flutter. Here's where I disagree: - I've used Xcode since version 2 and like it, but in my opinion it's a worse developer experience than Flutter. Refactoring and code navigation were much better in both Android Studio and VS Code. - Flutter's hot reloading is fantastic. Meanwhile, SwiftUI previews seem to be built on the same technology as IBDesignabl…
> but UIKit doesn't even have a standard button class
Doesn't anyone else use UIButton? Granted, the native iOS app I developed was intended primarily for blind people, so I didn't really make it visually polished.
Re: Flutter 2
#564Earlier quoted context omitted.
>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.
That's because the current mobile platforms were engineered from the ground up specifically to kill the web in favour of walled garden app stores. We'll have to see how long this approach will stand up for, both legally and technically. With real open source phones and antitrust developments we might see a revival of mobile web eventually.
Even in the extreme unlikely case of opening up Apps without App Store. People will still be using apps. Even if they are Web Apps or Apps with WebView. It will still be Apps. Simply because accessing a button is easier than typing in a link.
Web is still great for Discovery though.
Re: Flutter 2
#565I 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.
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.
I think the selection some improvement improvements needed reach a native-feel. For example, interactions like triple-click to select a line.
However I think the decision to make text selection opt-in makes sense from the context of an application that targets web.
For example, if you open up your mail app or Slack, you will find that a lot of text on the screen isn't selectable. For example, you can't select the text of the tabs on your browser.
If all text was selectable by default for an app, it may cause unexpected results rather than having the develop opt-in to deciding what is selectable. We have many widgets in our app that we wouldn't want selectable for UX reasons.
In practice, it hasn't been much effort for us to make things selectable. Just need to replace a Text widget with a SelectableText widget.
Re: Flutter 2
#566It 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?
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.
Reading through this thread makes me think the canvas approach has a performance advantage on faster devices (the demos load instantly and feel snappy to me on a Razer Blade Stealth from 2-3 years ago) but probably also has a performance _disadvantage_ on slower devices (people complaining things taking 10-20 seconds to load), etc.
Is that a reasonable assumption?
If so, I wonder if there's anything that could be done to help match the right rendering strategy to devices that handle it better (e.g. DOM on slower devices). Seems easy enough on Android/iOS where you know the device specs (mostly) and can target them, but the web is a huge beast of variance.
Re: Flutter 2
#567We'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 disapp…
> Not to mention that Flutter is already better and easier to use than the existing native tools for both Android and iOS.
Flutter is not better or easier than SwiftUI. Especially in accessibility or native performance.
Re: Flutter 2
#568We'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 disapp…
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 wil…
> History has shown us over and over again, always bet on the web.
For what it's worth, people had the exact same mantra about internal combustions engines for decades any time someone brought up electric cars.
You're absolutely right that entrenched systems are hard to change and attempts to change them mostly fail... until one succeeds.
Re: Flutter 2
#569We'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 disapp…
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.
> 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.
Can you think of a "minor Google property" that is open source?
Re: Flutter 2
#570Earlier quoted context omitted.
[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.
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.
> Have you considered not going full-on structural-typing but still providing some sort of union?
I work on Dart. The terminology gets really confusing here. "Discriminated unions" and "union types" are two quite different things, though they get a little blurry in TS.
The short answer is, yes, we're investigating pattern matching with exhaustiveness checking and making the language more graceful at expressing algebraic datatype-style code. The last half of that sentence sounds weasely because any object-oriented language can (except for exhaustiveness checking) model an algebraic datatype using subtyping. The parent comment using an abstract base class is how you do it.
So there isn't anything really fundamental that Dart can't express already. It's mostly a question of giving users syntactic sugar to make code in that style look more terse and familiar. I personally really like pattern matching and ADTs and I also particularly like multi-paradigm languages, so this is a subject close to my heart.
The language team has been pretty busy with null safety, but now that that's out the door (woo!), we can start working on the next batch of features, which with luck includes pattern matching. Here's an in-progress proposal:
https://github.com/dart-lang/language/blob/master/working/05...