Live data from Hacker News

Flutter 3

docs.flutter.dev

91–100 of 453 posts

Re: Flutter 3

#91
post #49

What are big and highly used apps that use Flutter?

Philips Hue is fully Flutter since a while now (v4). There were issues with (pre-rendering of) animations but those have been resolved in Flutter.

Re: Flutter 3

#92
post #56

Earlier quoted context omitted.

> While that's great, I was hoping it would be like in Rust, where each enum variant can declare its own state components, but unfortunately it seems to be more like Java: same state for all variants. As much as I like Rust’s enums, I think they messed up on the naming. Java (and according to your comment, Dart) gets enum rights. What Rust has under this name is sum types, which is a separate (more expressive) concep…

There is no real reason to have basic enums if you have ADTs , since those can easily provide everything a plain enum gives you. I guess the name was just a historical artifact.

no the feature you're looking for is sealed classes, see e.g. Kotlin. Rust enum variants cannot be externally defined classes

Re: Flutter 3

#93

Earlier quoted context omitted.

Or have you, and you just couldn't tell? (I personally don't know if it's this good, but it's plausible)

Not OP - but almost all of the Flutter work I've ran into is mobile-centric. If you're looking for cross-platform on the desktop it really hasn't been a popular option vs. Electron/Qt.

Given that "Today, we are excited to announce that Flutter is now stable for macOS and Linux, in addition to Windows!" thats not surprising

Re: Flutter 3

#94
post #47
post #33

Does Flutter have a complete Material UI components implementation? I'd prefer to use Flutter for multi-platform support over learning new Android Compose and figuring out what to do for other platforms later.

Does anything have a complete Material components implementation? I always got the vibe from Material that it's just a bunch of designers pumping out docs for an ideal world, and then the various libraries try to implement a bunch of those things as they change faster than they can be implemented.

Indeed. It wasn't that long ago that Material components for Android finally got proper support for Material 2 in a stable release of the library. But everything started too look too nice and consistent, so now we're getting steamrolled with Material 3.

Re: Flutter 3

#95
post #11

I was hoping to see better HTML rendering. Using a single canvas to render web apps was my one turn off. Flutter is the right choice for many apps, but not for apps primarily accessed over the Web.

What’s wrong with using a single canvas? It can be faster. Google Docs and Figma, for example, use canvas rendering

no canvas are slower for UIs. The difference is between immediate vs retained mode rendering, and the later is order of magnitude more energy efficiency and is more performant, for well behaving not chaotically changing content.

Re: Flutter 3

#96

Earlier quoted context omitted.

There is no real reason to have basic enums if you have ADTs , since those can easily provide everything a plain enum gives you. I guess the name was just a historical artifact.

no the feature you're looking for is sealed classes, see e.g. Kotlin. Rust enum variants cannot be externally defined classes

That's completely orthogonal to ADT vs enum.

Re: Flutter 3

#97

Despite many maturity issues in practice Flutter is the only realistic option for true cross platform UIs that run everywhere. Apart from Qt , but the licensing issue is a hindrance. And yes, the web backend isn't ideal, but it will improve over time. I just wish Google had built Flutter on a low level core that isn't tied to Dart, so it would be usable from other languages. Dart isn't horrible and is getting better,…

I thought I would hate Dart since it seems like such a bland language but after working in it for a year and a half its easily one of my favorites. Its straightforward and tailored directly for Flutter's use-cases. It feels like it doesn't come with a lot of the baggage you get with other, longer-lived languages. It is also incredibly readable without hiding how it works behind decades of syntactic sugar. All that to…

> It feels like it doesn't come with a lot of the baggage you get with other, longer-lived languages.

Doesn't this mean that you are currently simply in the sweet spot where the language is usable but also not bloated yet? As in, it could all change in a decade and therefore isn't an intrinsic quality of the language itself, but merely the passage of time.

I recall this blog post exploring the possible correlation between the age of any programming language and the developers' disposition towards it: https://earthly.dev/blog/brown-green-language/

Re: Flutter 3

#98
post #3

did they fix the scrolling on iOS?

From their What’s New: “ Flutter now supports variable refresh rate on iOS devices with ProMotion displays, including iPhone 13 Pro and iPad Pro. On these devices, Flutter apps can render at refresh rates reaching 120 hz, which were previously limited to 60 hz. This results in a smoother experience during fast animations such as scrolling. See flutter.dev/go/variable-refresh-rate for more details.”

can does not mean it will.

Re: Flutter 3

#99
post #80

Despite many maturity issues in practice Flutter is the only realistic option for true cross platform UIs that run everywhere. Apart from Qt , but the licensing issue is a hindrance. And yes, the web backend isn't ideal, but it will improve over time. I just wish Google had built Flutter on a low level core that isn't tied to Dart, so it would be usable from other languages. Dart isn't horrible and is getting better,…

> I just wish Google had built Flutter on a low level core that isn't tied to Dart, so it would be usable from other languages. Any chance that someone will build a transpiler from e.g. Go or even Rust to Dart? Or is Dart too exotic to be used like that in a practical way?

Flutter and Dart have co-evolved to the extent that separating them would be difficult.

One problem would be expressing the Flutter API as a Go API. For example, Flutter has lots of constructors with lots of keyword arguments. Flutter is doing things with keyword arguments that would be expressed as props in a React-style UI. A similar thing happened with JavaScript and JSX - while you can write a React-style UI without JSX, you probably wouldn't want to.

Maybe you could define props using structs in Go, but the result would be awkward, particularly because Go doesn't have an easy way to bulk-copy fields from one struct to another, like you do with spread arguments in JavaScript.

Also consider that Flutter uses class hierarchies extensively and Go doesn't have inheritance.

Maybe look at how web development is done in Go when it's compiled to WebAssembly. Is that how you'd want to do web dev?

Re: Flutter 3

#100

We have a react native app and sometimes it fails to build. We go to lunch, and come back no code change now it builds. I'm just sick of the NPM/Javascript bullshit. Does Flutter avoid all of these kinds of issues? I'm this close to scrapping the whole thing.

I never coded React Native, but I have a lot of experience with Flutter. You can definitely run into build issues, but it's almost exclusively when doing precarious things like upgrading third party packages, SDKs or Flutter versions. As soon as you've traversed the depths of dependency hell and it builds, it builds without a hitch repeatedly in my experience.

As the framework is maturing there have been some major transitions between APIs and project structure. My main app that was scaffolded two years ago has had no shortage of duct tape fixes and tweaks to especially Gradle/Cocoapods config to keep it building.

I guess it's a fair price for what has otherwise been a fantastic developer experience. All in all I'd strongly recommend it.

Post reply on HN