Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flutter 2

developers.googleblog.com

Post reply on HN
Print view View original

361–370 of 780 posts

Re: Flutter 2

#361

Post by mkl »

timsneath wrote: post #51
fwip wrote: post #39

Earlier quoted context omitted.

The example spinner ( h https://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.

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.

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

Re: Flutter 2

#362

Post by qbasic_forever »

randomchars wrote: post #35

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. […

This site physically hurts my fingers to scroll on a trackpad.

Re: Flutter 2

#363

Post by sgt »

jorl17 wrote: post #163

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?

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.

Re: Flutter 2

#364

Post by jpsoft »

jaegerpicker wrote: post #220
yagodragon wrote: post #112

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

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

Re: Flutter 2

#365

Post by shawnz »

fastball wrote: post #211
selykg wrote: post #137

Earlier quoted context omitted.

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

You know devs can already make text not selectable on the web, right?

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.

Re: Flutter 2

#366

Post by themacguffinman »

mkl wrote: post #342
themacguffinman wrote: post #224

Earlier quoted context omitted.

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.

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.

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.

Re: Flutter 2

#367

Post by amelius »

dmitryminkovsky wrote: post #268
qbasic_forever wrote: post #246

Earlier quoted context omitted.

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. 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.

> People want native apps.

Only because OS vendors made them believe that.

Re: Flutter 2

#368

Post by okamiueru »

kroltan wrote: post #352
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

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

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?

Re: Flutter 2

#369

Post by ywei3410 »

eseidelGoogle wrote: post #155
rp1229 wrote: post #127

Earlier quoted context omitted.

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.

[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.

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.

Re: Flutter 2

#370

Post by dmitryminkovsky »

amelius wrote: post #367
dmitryminkovsky wrote: post #268

Earlier quoted context omitted.

> 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.

> People want native apps. Only because OS vendors made them believe that.

That is my understanding as well.
Post reply on HN