Flutter 2 • Hacker News Board

Re: Flutter 2

#571

Post by munificent » Thu, Mar 04, 2021, 2:45 AM UTC

oblio wrote: post #269

okamiueru wrote: post #241

Earlier quoted context omitted.

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

Let's say you get a JSON API that sometimes returns a list, sometimes returns an object. How do you model that in Dart?

Yes, union types are really nice for data like that.

But, in practice, a language's type system tends to optimize for the data structures that are idiomatic in the language. TypeScript is a heavily structural type system because idiomatic JavaScript often throws together unrelated types in this way (which makes sense when you're coming from dynamic types).

In a language that is built more strongly on objects and static types, it's less common to see APIs that "return one of these, or one of these, or on Sunday one of these things". So there is relatively less use for union types.

In other words, because people express unions at runtime less frequently in Dart (and other languages like Java and C#), there's less value in supporting them statically. Still some, definitely, but I don't think it's as critical of an omission as you might expect coming from TS/JS.

Re: Flutter 2

#572

Post by signal11 » Thu, Mar 04, 2021, 2:47 AM UTC

hackerfromthefu wrote: post #559

hamandcheese wrote: post #458

Earlier quoted context omitted.

> 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 severa…

Companies are too efficient for that, even if dev salaries were cheaper they would still want to fund just one version and pocket the difference, and eventually market competition will make that the norm.

Counterexample: banks started with shitty cross-platform UI type apps, but those received low customer satisfaction figures so most of them have now switched over to native apps. A similar thing happened with Facebook.

Re: Flutter 2

#573

Post by theanirudh » Thu, Mar 04, 2021, 2:47 AM UTC

rp1229 wrote: post #127

garrtt wrote: post #41

> 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 receiv…

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.

It was buggy as well. I was locked out of receiving and sending payments for about a month. After some updates, had to relink my bank account and the app created a new UPI ID by appending a -1 ie. myname-1@okhdfc! It's like creating a new email ID to resolve the issue.

Re: Flutter 2

#574

Post by unityByFreedom » Thu, Mar 04, 2021, 2:51 AM UTC

CGamesPlay wrote: post #557

Hixie wrote: post #435

Earlier quoted context omitted.

It doesn't really default to anything. There's a widget for selectable text and a widget for non-selectable text.

OK, but the Flutter gallery has zero selectable text, as far as I can see. Seems like a great case of where developer decided "doesn't need selection, let's let the user drag to scroll with their mouse instead".

Why even make it a 50/50 choice? I hate apps without selectable text and they're everywhere. Translating something becomes a nightmare and that hurts useability.

It's like if you made spoiler 50/50. Do you want to see this without clicking?

I think we really overlook the thought that had gone into making js, and other open tech.

Re: Flutter 2

#575

Post by _-___________-_ » Thu, Mar 04, 2021, 2:51 AM UTC

iainmerrick wrote: post #550

buu700 wrote: post #536

Earlier quoted context omitted.

I'm not commenting on any other platforms, but I maintain a few C/WebAssembly libraries and they work exactly as expected without being unreasonably large. C-in-JS has been viable for a number of years now.

I realise it works, I just don’t think it’s really useful for what was asked for, a way to write common cross-platform business logic for a platform-specific UI. Unless there are some great new tools I’m not aware of, C on WebAssembly seems about the same as C on Android. You can compile stuff just fine, and run it, but actually connecting it up to any substantial UI written in JS/Java is going to be incredibly tedio…

Generally speaking the "connecting it up" between c/wasm + js or C + java/kotlin on android can be completely automated with codegen. It's really not tedious at all.

Re: Flutter 2

#576

Post by groby_b » Thu, Mar 04, 2021, 2:52 AM UTC

ryandrake wrote: post #436

hanniabu wrote: post #301

Earlier quoted context omitted.

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.

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,…

Working on an app that's running on... 6 different OSs/UI toolkits on last count, yeah, that "small UI layer" is costly. And yes, finding devs that know more than one language/one UI toolkit is hard. (Heck, for some UI toolkits, finding developers is hard period)

Re: Flutter 2

#577

Post by leppr » Thu, Mar 04, 2021, 2:53 AM UTC

reader_mode wrote: post #316

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…

That corresponds exactly to my experience when I tried it a few years ago. Very disappointing to learn nothing changed on that front. The "just works" aspect of Flutter is what attracted me to it initially, and it took me a few weeks before realizing React-Native, as much of a clusterf*ck as it was, was still a more pleasant development experience.

Re: Flutter 2

#578

Post by danShumway » Thu, Mar 04, 2021, 2:56 AM UTC

themacguffinman wrote: post #503

danShumway wrote: post #463

Earlier quoted context omitted.

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.

Sure but presumably many developers who are deciding whether to adopt Flutter aren't only targeting a population of you and other people in this thread. The fact remains that this is not a significant issue for most users and rational developers will weigh it as such against potential benefits that Flutter provides.

I guess but... I don't think that changes anything about the complaints that people have about this. What you're saying is a fact, but I don't think it's a relevant fact.

I'm looking over this thread, nobody has said that they're in a majority. We're just saying that Flutter's default behavior is bad for us, and that it encourages developers to make bad choices about text, and that it's pretty demonstrable that the average Flutter app has less selectable text than the average web app in general.

The fact that many companies will not care about this when weighing the technology is exactly why we're complaining. Because we don't want the web to suddenly become unusable for us just because we're in a minority of users.

It still doesn't make me feel any better or make me any less likely to complain to hear that my problems don't affect everyone else. It's not addressing the criticism, or explaining why I shouldn't be upset about Flutter's decision, or explaining why the current situation on the web is equivalent. It's just a polite way of saying, "yes this will affect you, but we don't care because we don't think you can do anything about it."

And yeah, it's probably true that this issue in specific is not going to cause Flutter to fail (there are plenty of other problems with Flutter on the web that will do that), but does that fact change anything about whether or not widespread Flutter adoption would make my web experience worse?

Re: Flutter 2

#579

Post by okamiueru » Thu, Mar 04, 2021, 2:57 AM UTC

okamiueru wrote: post #441

svieira wrote: post #411

Earlier quoted context omitted.

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.

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?

Reading more about it, it could seem that we are talking about the same thing, except that it was so far over my head, that I didn't realise it.

Re: Flutter 2

#580

Post by signal11 » Thu, Mar 04, 2021, 2:57 AM UTC

rtpg wrote: post #551

ryandrake wrote: post #436

Earlier quoted context omitted.

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 release feature X. The first person writes it for the web. The web version was easy, because the feature relied on URL deeplinking, which is nice and easy with browsers. You then realize that Windows doesn't really offer such a concept as easily. You think about application URLs. That mostly works, but it takes a couple weeks for the Windows team to get it working. You implement the feature over on Macs as well c…

While I realise you’re just providing an example, Windows has supported deep linking in one form or another since Windows 3.1 (DDE, specifically topics), but also HTTP-style application URLs (eg app://command?options=opts) ever since ActiveDesktop and WebView.