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

Flutter 3

docs.flutter.dev

Post reply on HN
Print view View original

371–380 of 453 posts

Re: Flutter 3

#371

Post by zeroc8 »

johnywalks wrote: post #367
the_duke wrote: post #42

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

> Dart isn't horrible Dart is horrible and the sole reason i don't touch Flutter

What's so horrible about it? It's pretty much on par with Java and C#, but feels lighter, generates native Code and makes it easier to talk to C libs.

Re: Flutter 3

#372

Post by hunterb123 »

realusername wrote: post #356
hunterb123 wrote: post #353

Earlier quoted context omitted.

I never really have issues with the JS side of things, care to elaborate on what specifically is "terrible"? Generally what breaks RN is the same stuff that breaks Flutter, native tooling like CocoaPods, Gradle, etc.

> I never really have issues with the JS side of things, care to elaborate on what specifically is "terrible"? Packages are usually poorly tested (and the fact that it's dynamic language does not help), upgrades are often and painful, the tooling is not very stable in my opinion. Before settling for Flutter, I've made a limited version of my app in both ecosystem to try both and on the RN one, I already had upgrade i…

> Packages are usually poorly tested

Just in general? I don't know of any packages in my app that are poorly tested. Simply do not choose dependencies that don't meet your standard, whether it's TS or Dart.

> and the fact that it's dynamic language does not help

Most packages nowadays are written with TypeScript or Flow. JS itself is fast and stable thanks to the billions put into the VMs.

> upgrades are often and painful

You don't have to upgrade. In the early days things were more painful, but I've upgraded the past few major React and RN versions with no hassle.

> the tooling is not very stable in my opinion.

Seems stable to me since the last couple years.

Personally the apps that Flutter makes are of worse quality vs RN apps. Emulated native will always feel cheap compared to real OS controls.

Re: Flutter 3

#373

Post by Okawari »

NonNefarious wrote: post #275
the_duke wrote: post #246

Earlier quoted context omitted.

To be fair: Dart is relatively straight forward and simple to learn. You should have decently qualified developers be productive within a week. But forcing a new language on people usually doesn't go well.

Sure, I'm not trashing the language, because I know nothing about it. Our whole dev team is C/C++, with random people who know Python and a few other things. I'm the only one who knows Swift. They're bright people and not hostile toward new ideas, but they're already overtaxed and can't cater to an outlier project written in a language no one knows and built on a framework no one knows.

Speaking from personal experience I found the process of using dart to be VERY painless. I'm mostly a web developer, but have taken some Java courses in college and have dabbled in a bit of C# outside of my normal PHP/JS work.

We decided to take on an app project at work. We had made one using nativescript-vue, but the experience left much to be desired and I wanted to look for alternatives.

A friend had talked favorably about Flutter so I decided to install and check it out. Within a few hours, I had a pretty good looking MVP of the app we were building (it was very basic to begin with). The experience developing a Flutter app was really good.

It felt like I already knew the language from the get go. It worked pretty much as expected. I only had to google things like async/await because dart writes their functions like `(arg) async => expr` while javascript puts the async before the function `async arg => expr`.

YMMV if you're not using the languages which Dart draws inspiration from I guess. But I'dd be surprised if you feel you would need to spend significant amount of time learning Dart.

Re: Flutter 3

#374

Post by mhoad »

hunterb123 wrote: post #359
realusername wrote: post #357

Earlier quoted context omitted.

> React Native is ready for production now for all platforms, including Windows & Xbox via react-native-windows, Web via react-native-web, MacOS via react-native-macos or Catalyst. All platforms ... except Linux. React-native-gtk is abandoned as far as I know.

You can wrap the React Native Web target in Tauri or Electron for Linux. There's also https://github.com/valence-native/valence-native that can use either wxWidgets or Qt. All in all it's better than the current Flutter web / desktop implementation.

Politely, I would point out that the makers of Ubuntu have said that as far as they are concerned Flutter is the future of desktop app development on Linux and all their projects moving forward will be using it by default because they believe in it so much.

They just started in Ubuntu 22.04 by rewriting their installer (I.e the very first thing users see when coming into contact with Ubuntu) to be a Flutter app.

It has proper first class support rather than the hacky and unofficial (and possibly poorly maintained) workarounds you suggested to do cross platform development.

Re: Flutter 3

#375

Post by realusername »

hunterb123 wrote: post #372
realusername wrote: post #356

Earlier quoted context omitted.

> I never really have issues with the JS side of things, care to elaborate on what specifically is "terrible"? Packages are usually poorly tested (and the fact that it's dynamic language does not help), upgrades are often and painful, the tooling is not very stable in my opinion. Before settling for Flutter, I've made a limited version of my app in both ecosystem to try both and on the RN one, I already had upgrade i…

> Packages are usually poorly tested Just in general? I don't know of any packages in my app that are poorly tested. Simply do not choose dependencies that don't meet your standard, whether it's TS or Dart. > and the fact that it's dynamic language does not help Most packages nowadays are written with TypeScript or Flow. JS itself is fast and stable thanks to the billions put into the VMs. > upgrades are often and pa…

> Just in general? I don't know of any packages in my app that are poorly tested. Simply do not choose dependencies that don't meet your standard, whether it's TS or Dart.

In general, it's not really part of the js culture. Sure you have those very nice packages which have stellar dev practices (such as react) but that's far from the norm.

The testing story also feels better with Flutter to me, one nice thing about the canvas based rendering is that you have very good and useful screenshot testing.

> You don't have to upgrade. In the early days things were more painful, but I've upgraded the past few major React and RN versions with no hassle.

If you don't upgrade, you're left behind and it will become more and more painful to upgrade later. Upgrade policies of languages also have to be taken into account for the dev time.

> Personally the apps that Flutter makes are of worse quality vs RN apps. Emulated native will always feel cheap compared to real OS controls.

No mainstream app is using native controls anyways. Facebook doesn't, Twitter doesn't, Whatsapp doesn't...

Additionally, if you have a terrible phone, this is where Flutter stands out in terms of speed. That's why it's so popular in developing countries. On my Galaxy J3 (bottom of the barrel of samsung), my app is the fastest app I have installed.

Re: Flutter 3

#376

Post by IceWreck »

amelius wrote: post #216
LocalPCGuy wrote: post #133

Earlier quoted context omitted.

It is not production ready for web and I don't have much hope it ever will be. I love it for mobile, even desktop apps. But I feel they chose the wrong direction at the beginning for web and it's just trying to dig back out of that hole since then.

Couldn't they just embed Chrome, like Electron did?

For desktop and mobile, Flutter renders over OpenGL, why do they need to embed chrome ?

The websites that are exported from Flutter use the HTML canvas (used for games, animation, etc) instead of trying to generate HTML. This means accessibility and SEO are on existent for those sites. GP is complaining about this.

Re: Flutter 3

#377

Post by SemanticStrengh »

mekkkkkk wrote: post #317
SemanticStrengh wrote: post #164

Earlier quoted context omitted.

You have yet to see a world where people update their beliefs more than once per decades. Hybrid native web apps are trivial, see e.g. Ionic capacitor plugins

I'm well aware of hybrid apps and Ionic. I wouldn't call those solutions properly "web" though. They're basically only using web tech as a presentation layer, and deferring to native plugins to do the heavy lifting when required. Very similar to how Flutter does it. So if your claim is simply that CSS/HTML/JS is capable of creating good user interfaces , I'm not arguing against it.

> a presentation layer, and deferring to native plugins to do the heavy lifting when required

bruh it's not just UI, the JS/TS code is where the business logic code is. And anyway the UI is the whole point, we are debating UI libraries. But most importantly native plugins are niche, you use them very rarely and for very specific needs, they occupy generally less than 1-5% of the code base. e.g. when you need to access the camera or sensors, which you usually don't need and most apps don't actually benefit from plugins. I'm not even talking about the fact that most of those niche needs are generally covered by equivalent modern web APIs (e.g. web share) but since plugins are trivial to use, people often use them even when a web api already exist.

Re: Flutter 3

#378

Post by hunterb123 »

realusername wrote: post #375
hunterb123 wrote: post #372

Earlier quoted context omitted.

> Packages are usually poorly tested Just in general? I don't know of any packages in my app that are poorly tested. Simply do not choose dependencies that don't meet your standard, whether it's TS or Dart. > and the fact that it's dynamic language does not help Most packages nowadays are written with TypeScript or Flow. JS itself is fast and stable thanks to the billions put into the VMs. > upgrades are often and pa…

> Just in general? I don't know of any packages in my app that are poorly tested. Simply do not choose dependencies that don't meet your standard, whether it's TS or Dart. In general, it's not really part of the js culture. Sure you have those very nice packages which have stellar dev practices (such as react) but that's far from the norm. The testing story also feels better with Flutter to me, one nice thing about t…

> In general, it's not really part of the js culture

As opposed to the Dart culture? Quite a sweeping generalization. There's bad packages in every ecosystem. There's really good packages in every system. Pick the right ones.

> one nice thing about the canvas based rendering is that you have very good and useful screenshot testing.

React you can snapshot test the component tree, as well as diff images on each platform.

> If you don't upgrade, you're left behind and it will become more and more painful to upgrade later. Upgrade policies of languages also have to be taken into account for the dev time.

Sure, I update major versions every year or so. Past 2 years of React Native have been easy.

> No mainstream app is using native controls anyways. Facebook doesn't, Twitter doesn't, Whatsapp doesn't...

That's plain false, they for sure do.

> Additionally, if you have a terrible phone, this is where Flutter stands out in terms of speed. That's why it's so popular in developing countries. On my Galaxy J3 (bottom of the barrel of samsung), my app is the fastest app I have installed.

React Native performs well on older devices as well.

Re: Flutter 3

#379

Post by mhoad »

fauigerzigerk wrote: post #363
chakkepolja wrote: post #341

Earlier quoted context omitted.

> welcome to blinking cursor that consumes 5-15% CPU in idle. Citation? Flutter draws its own UI but game engines do that too. All code in flutter compiles down to native code. > React native has less performance issues, since it uses native toolkit. In theory.

>Citation? https://github.com/flutter/flutter/issues/59327 This has been a long-standing issue that has completely ruled out Flutter for us. E.g, the Flutterfolio idle login screen uses 14% CPU on my Mac. For a while it sounded like Google was saying that it can't be fixed. But I think they have done some work to address this issue. I'll be very interested in finding out whether it has been fixed in Flutter 3.

I think this might be a bit of an outlier honestly.

Reading the bug report my takeaways were the following:

1. Here is a specific issue we ran into which to be fair is unacceptable in terms of perf but a blinking cursor in an otherwise idle application has crazy high CPU usage numbers trying to run the animations associated with the blinking cursor.

2. They tried the same thing on Linux and CPU usage was 0% so already it appears this is more of a specific mac bug rather than some general widespread thing.

3. Further in the thread a number of potential solutions get mentioned and were under development including just writing a custom shader to handle the blinking cursor (so a solution looks possible)

They just made Mac desktop support stable as of less than 24 hours ago for the first time. None of this strikes me as that egregious. A whole number of major perf improvements have landed since then and it's not even clear if this is still an active problem in Flutter 3.

I think trying to extrapolate this one bug into some widespread disaster scenario is a mistake.

Re: Flutter 3

#380

Post by SemanticStrengh »

the_duke wrote: post #251
SemanticStrengh wrote: post #232

Earlier quoted context omitted.

I fail to see the issue here > rendering an application inside of a web view as if it's a native app. That doesn't mean anything. A native app doesn't mean anything. Native is a ad-hoc property of being the UX framework shipped by default on the OS On chromium OS, chrome is native. Who cares? What matters are the merits of framework x vs framework y. As for the graphical charts 1) material design is as well supported…

Just a hint: if you work for Ionic it's customary on HN to disclose that fact. Also: what makes a framework "native" for me is that it has it's own rendering stack. With webview solutions you are still facing cross platform inconsistencies between Safari/iOS, Android and Electron.

I am not an Ionic employee, I have zero affiliation. I am a hobbyist in GUI rendering libraries technologies, which include Skia, blend2d, pathfinder, webrender, piet-gpu, etc

> what makes a framework "native" for me is that it has it's own rendering stack

lel, the point of react native is exactly that it doesn't have its own rendering stack, it defer rendering to external rendering stacks (android native lib, swift native lib) Flutter and the web are not native and are not different. They both have their own custom rendering stack, which allow them to improve it. flutter has not created its own 2d renderer btw, it uses the chromium 2D renderer named skia, in fact android native use the chromium 2D renderer since a few versions already. Simply because its the fastest to exist.

> With webview solutions you are still facing cross platform inconsistencies

crazy how reversed with reality your argument is. React native is by design inconsistent, it uses a separate library for each platform which result in an impedence mismatch of features, performance, and bugs. A webview has no inconsistencies between android and electron, it's the same chromium behind. Safari is slighly inconsistent (webkit) but order of magnitudes less than using a completely different library.

Post reply on HN