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

531–540 of 780 posts

Re: Flutter 2

#531

Post by vendiddy »

ignoramous wrote: post #231
eseidelGoogle wrote: post #155

Earlier quoted context omitted.

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

Thanks. Not related to Flutter but Google in general: I recently hit a hard-to-reproduce bug with Jetpack's LiveData for which there's already an open issue created by a third-party developer. I don't recall but it had been open since 2018 with no updates whatsoever from Google engineers on its progress. And therein lies a frustrating problem for engineers not working at Google but using Google tech. There is simply…

We are using Flutter at our company and it's far from a black box if you get stuck.

For example, try going to a TextField widget and use go-to-definition view the source source code. You can go very far down the go-to-definition hole. Even to the point where you can see where the blinking cursor is being rendered.

For several "blockers" we did have, we were able to copy/paste the Flutter implementations, rename them, and modify them to fit our own needs.

Re: Flutter 2

#533

Post by refulgentis »

capableweb wrote: post #244
yjbanov wrote: post #129

Earlier quoted context omitted.

(disclaimer: I work on the Flutter team) The "Create account" link isn't popping up the right-click menu because it doesn't use the Link widget. You'd get the same thing in plain HTML if you used a with a custom click event listener instead of . It's a simple bug to fix; totally up to the app developer. I think issues like that will inevitably pop-up as we have developers coming to the web from other platforms, where…

> You'd get the same thing in plain HTML if you used a with a custom click event listener instead of . It's a simple bug to fix; totally up to the app developer This is the issue. Instead of having one codebase that works the same on all platforms (ios, android and web), you get (as a developer) the blame for not implementing things correctly across the different platforms. Instead of a cross-platform development env…

I have to be honest, not trolling at all, genuinely curious to me: I have the same opinion for the completely opposite reason! _without_ "Skia everywhere", Flutter for Web was annoying, because then there was this autogenerated CSS/JS and it might be _close_ to other Flutter platforms, but it often couldn't be 100% of what it was

I think its because we might be seeing it from two different points: i.e. you see Flutter Web using Skia is not consistent with _other websites and thus traditional webapps_, I see that Flutter Web using JS/HTML made it _not consistent with deployments of the same Flutter code to Android/iOS/Mac_

Definitely see that viewpoint and why it's problematic, would argue as an independent dev, would care much more about 100% self-consistency across my product line up for ease of support than whether people open the app in a web browser, you can right click on anything that looks like an image and download it.

Understand that viewpoint _also_ sounds like sacrilege, but as someone raised on iOS dev, reminds me of when Mac devs being upset over years as "iOS-isms" made their way to the desktop. I love that this approach is an example of solving hard problems over years, fixing a industry-wide yak shave that ended with you having 50 copies of chromium. solves the same problem Electron is solving with none of the downsides

Re: Flutter 2

#534

Post by iainmerrick »

buu700 wrote: post #524
avar wrote: post #478

Earlier quoted context omitted.

And write your shared business logic in what language? If it's a C library perhaps you could do this on iOS and Android, but how is that going to run in a browser? I'm aware of things like the LLVM based C to JS compilers, but they're not really viable for anything non-trivial. That's why a lot of shops are writing the same logic N times in N languages and frameworks. It can actually be easier than having to target s…

I'm aware of things like the LLVM based C to JS compilers, but they're not really viable for anything non-trivial. emscripten/WebAssembly is pretty viable.

Well, if “viable” means “doable but really fiddly”.

C/C++ is fine on iOS (at least when interoperating with Obj-C, Swift is trickier).

C/C++ is “doable but really fiddly” on Android, same as web. There’s a compiler toolchain but not much IDE support, and you have to do all the JNI marshaling yourself.

So C/C++ is only barely usable for common cross-platform code, and yet it’s the best option. What other language are you going to use?

It’s kind of ridiculous, but that’s the way it is. Programming languages are all the same in principle, but in practice they don’t interoperate well and they can’t easily be used everywhere.

Re: Flutter 2

#535

Post by mixedCase »

lostmsu wrote: post #146
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…

Flutter does not offer enough to justify learning new programming language.

Flutter does not offer enough to justify tolerating such a terrible programming language*

Going from Kotlin, Swift or TypeScript (let alone more powerful languages) to Dart is like going back to the dark ages without something as basic as algebraic data types.

Re: Flutter 2

#536

Post by buu700 »

iainmerrick wrote: post #534
buu700 wrote: post #524

Earlier quoted context omitted.

I'm aware of things like the LLVM based C to JS compilers, but they're not really viable for anything non-trivial. emscripten/WebAssembly is pretty viable.

Well, if “viable” means “doable but really fiddly”. C/C++ is fine on iOS (at least when interoperating with Obj-C, Swift is trickier). C/C++ is “doable but really fiddly” on Android, same as web. There’s a compiler toolchain but not much IDE support, and you have to do all the JNI marshaling yourself. So C/C++ is only barely usable for common cross-platform code, and yet it’s the best option . What other language are…

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.

Re: Flutter 2

#537

Post by mixedCase »

lordgroff wrote: post #183
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…

Maybe it's just me but I don't remotely think JS is a bad language since es6. Tooling is another story entirely.

What other languages have you been exposed to?

Re: Flutter 2

#538

Post by ryandrake »

tiborsaas wrote: post #485
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,…

> Is it that expensive to separate your business logic from UI and write the small UI layer Not sure what apps you've built, but usually that business logic is the minority of the codebase. The rest of the stuff is boilerplate, like drawing boxes, describing layouts, handling events, managing state. All this has nothing to do with business logic. Ideally, I want to write it once that I want a row of buttons what colo…

Last major one I worked on that needed to be cross platform was a GPS navigator, which had massive functionality in C and C++ under the hood, called from the platform-specific UI/event handling code through Objective-C-to-C++ on iOS, through JNI on Android, and directly on PC native platforms. It worked pretty well. The ratio of platform-specific to platform-independent code was very small, so it was not like writing the app N separate times. Major engineering savings AND each platform's build had its own UI idioms that users of those platforms were accustomed to. Guess I never realized this was a controversial approach to take!

Re: Flutter 2

#539

Post by rubyn00bie »

bsaul wrote: post #443
pvinis wrote: post #380

Earlier quoted context omitted.

Show me any flutter app you want and I'll find a problem with a list view.

I’m still having a hard time believing any « flutter is so great for me » testimonies, because my personnal experience with app having only the most basic list screen has always between a disaster. There’s such a big discrepancy between those testimonies and my experience that i’m starting to become suspicious about their authenticities

What was the actual problem with your list? The default list worked really well for me, even when not correctly building the child. What platform were you using it on or building for? I'm not asking to be a prick or prove you wrong, my experience is just limited to my own and haven't had any of the issues you describe.

I can say, because I've read quite a lot of code Dart and Flutter code over the past few months, that my experience does seem to be a newer one. I'm sure up until recently (past year or two) it was probably pretty awful at times because of constant flux and a myriad strangely broken shit.

Right now though, it's fucking great. Let me tell you a story even:

Hokay, so, there is this fucking "null-safety migration" going on and I'm thinking to myself, "oh shit, this is going to be fuckin' awful. Every package has to be updated or it doesn't work. This is gonna end up like Scala 2.11... Heat death of the universe or my obscure flutter dependency updates, which could happen first?"

Turns out, almost zero time, the Dart/Flutter team built a tool to automate it... the tool has a built-in "migration UI" with it to make the process super obvious and easy.

It was so easy, and generally correct, I proceeded to make PRs to add null-safety support to my dependencies because I realized I could do them ALL, myself, with a couple of hours of work.

What that says to me, is that Google's tooling is pretty fucking mature and that my quality of life is likely to only get better. I have never had an experience even remotely close with anything except Swift and that only works on and for Apple's specific platforms. I'd be worried of Google abandoning it if it wasn't for Flutter and Dart being what Fuchsia uses for its UI.

Re: Flutter 2

#540

Post by gaaclarke »

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.

[flutter developer]

Hi, I audited the performance of the GPay app. Almost all of the performance issues in GPay are related to its use of vector graphics libraries which make Skia spawn many new shaders that have to get compiled. The suggestion was given to move to raster graphics but since GPay ships in many locations that are sensitive to app size, like India, they made the tradeoff to keep raster graphics.

That said there are some longer term initiatives to address this problem on Flutter's side and Skia's side since the problem can show up outside of vector graphics, it's just more unlikely.

Post reply on HN