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

751–760 of 780 posts

Re: Flutter 2

#751

Post by sgt »

drusepth wrote: post #566
sgt wrote: post #363

Earlier quoted context omitted.

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.

Reading through this thread makes me think the canvas approach has a performance advantage on faster devices (the demos load instantly and feel snappy to me on a Razer Blade Stealth from 2-3 years ago) but probably also has a performance _disadvantage_ on slower devices (people complaining things taking 10-20 seconds to load), etc. Is that a reasonable assumption? If so, I wonder if there's anything that could be don…

I have one Flutter web app in production, and for predictability's sake it is set to only use the web renderer (DOM), not canvas. O have not noticed any issues so far and it's fairly fast on even slow Androids.

Re: Flutter 2

#752

Post by Hixie »

BystanderX wrote: post #541
Hixie wrote: post #520

Earlier quoted context omitted.

> What do you think of the loss of opportunities for learning and customization that moving to an opaque system running "in" the web (flutter) implies? Not sure what you really mean. If you mean the loss of "View Source" then I think we lost that a long time ago for anything but the most trivial of pages. I used to say that view source was why the web was successful, and maybe it did help at the start, but I think we…

Thanks for your reply. > Not sure what you really mean. [...] sites are too complicated for anyone to pick out what's going on from the original source let alone the actual served source... I agree, View Source itself has become less and less useful. The Devtools in most browsers have kept up fairly well though. They provide a lot of methods to understand, debug, and modify behavior of whatever you're running using H…

I mean, I try to use Devtools on other sites, but I haven't really had any real success with that for years. I don't know how many of the rest of the web's ~4 billion users try to use DevTools but I can't imagine it's anything close to a majority. Or even a large minority.

FWIW Flutter isn't trying to replace the web. We're trying to offer a way of writing web apps that aren't really possible today. For example, something like the Flutter Folio demo, which works on multiple platforms including web, was written in a few weeks. I cannot fathom how I would do that without Flutter.

Re: Flutter 2

#753

Post by NOGDP »

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…

> 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

All of these things, more or less, already exist in great variety in the JS ecosystem (angular, react, vue, redux, webpack, etc.). Many people have also already adopted other languages such as TypeScript, which is easier to learn for someone coming from JS, and superior to Dart imo.

Re: Flutter 2

#754

Post by themacguffinman »

danShumway wrote: post #750
themacguffinman wrote: post #710

Earlier quoted context omitted.

It's true of course that as a cross-platform toolkit independently built on top of another platform, Flutter will have to consider new controls, gestures, and changes in many platforms. You could say the exact same things comparing Android/iOS/Windows to the cross-platform web: it's very hard to do and there are plenty of compromises, but it's still very valuable. There's been far more handwringing over the web's def…

> You could say the exact same things comparing Android/iOS/Windows to the cross-platform web: it's very hard to do and there are plenty of compromises, but it's still very valuable. The difference is that the web efforts aren't being headed by one team in one company, they're a giant effort with a huge amount of funding, shared resources, and attention from multiple companies and communities. Flutter doesn't have th…

I can't say that matches my generally nice experience with the demos on desktop, although mobile scrolling was pretty bad.

As you mention yourself, Flutter Web already implements some things using the DOM and is clearly capable of doing so, it's just a matter of degree. I can believe that Flutter would benefit a lot from using the DOM more, but that could change any time by some Flutter contributor saying "hm the custom tab ordering impl doesn't work too well, let's render a DOM tree for tabs" or something similar for ARIA attributes, text inputs, etc. It's hardly a fatal or intractable issue with the architecture.

Many of these complaints are real issues that Flutter should tackle but they feel pretty overblown. There's a general tenor that jumps from "there are still many issues" to "what's even the point of Flutter Web if it can't get everything right". Flutter Web has to start somewhere and good desktop browser support (which is hardly unusable) is good enough for many real use cases. I don't think anyone is selling it as a mature second iteration which seems like a misunderstanding of the v2 semantic version which applies to the core framework, not Flutter Web that just left beta. If there's any org I trust to do the difficult work of cross-platform support, it's Google which already provides the lion's share of funding, standards design and implementation development to the web. IIRC Flutter's dev team also has Chrome engineers on it. I expect it to attract the attention of more orgs as it matures and hopefully becomes more popular, the core framework has already received open source contributions from Microsoft and Canonical.

> they're not building an entirely new render engine from scratch

The web platform builds an entirely new render engine from scratch. Native OS platforms give you a lot for free too and you see the exact same complaints about the web's independent behavior proven irrelevant again and again as the web/Electron continue to demonstrate incredible value despite reinventing many wheels.

Re: Flutter 2

#755

Post by cachvico »

danShumway wrote: post #360
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 know if they've changed their approach over the past year, but the last time I looked at Qt demos for the web, I was solidly unimpressed. At the time, they were making almost all of the same mistakes that Flutter is, and the devs I talked to seemed to be of the opinion that those problems wouldn't be fixed until browsers started adding brand new capabilities specifically for them. Looking now at the demos at…

These demos remind me of Flash..

Re: Flutter 2

#756

Post by danShumway »

themacguffinman wrote: post #754
danShumway wrote: post #750

Earlier quoted context omitted.

> You could say the exact same things comparing Android/iOS/Windows to the cross-platform web: it's very hard to do and there are plenty of compromises, but it's still very valuable. The difference is that the web efforts aren't being headed by one team in one company, they're a giant effort with a huge amount of funding, shared resources, and attention from multiple companies and communities. Flutter doesn't have th…

I can't say that matches my generally nice experience with the demos on desktop, although mobile scrolling was pretty bad. As you mention yourself, Flutter Web already implements some things using the DOM and is clearly capable of doing so, it's just a matter of degree. I can believe that Flutter would benefit a lot from using the DOM more, but that could change any time by some Flutter contributor saying "hm the cus…

> it's just a matter of degree

Well, no, I'm claiming that it is a matter of approach, not just degree. There are two ways you can go about syncing the DOM to your rendering. Tabbing is a good example of that:

A) you can build a DOM tree, listen to a focusin event, and then when an input/link element gets focus, you can update your Canvas to match the state of the DOM. This means that you listen to one event and (with some exceptions) your rendering engine mostly just has to worry about rendering. Or

B) you can build a Canvas, reimplement tabbing, mouse selection, touch events, and everything else... and then when your new implementation decides that focus is changing, you can update the DOM to match your Canvas. In short, you can choose to have the Canvas drive the DOM, rather than having the DOM drive the Canvas.

What I'm arguing is that approach B, which Flutter seems to be using, is fundamentally much, much harder, buggier, and less performant than approach A -- and my evidence for that is that GUI frameworks surrounding Rust, Silverlight, and C# that are following similar approaches to A are almost all much more mature than Flutter is, despite having fewer corporate resources devoted to them. I'm arguing that path B is an high-level architectural decision that is not going to yield performant, high-quality results.

> The web platform builds an entirely new render engine from scratch.

Right, but again, the web platform at this point has spent over 20 years doing that, and for the majority of that time it would not have been realistic to build a project like Electron. A lot of this seems to come down to, "is the Flutter team big enough to handle this". I don't think they are, but maybe I'm wrong.

I mean, we can debate this endlessly, or next year Flutter v3 can start releasing demos that can handle smooth scrolling and don't lag in Firefox. My prediction is that Flutter is not going to turn into a performant, good quality target for the web any time within the next couple of years. But again, maybe I'm wrong, and luckily it will be very easy to verify if I am. I'll check back in January 2022 and see if anything has changed.

Re: Flutter 2

#757

Post by nmfisher »

ignoramous wrote: post #682
nmfisher wrote: post #620

Earlier quoted context omitted.

I think that's just coincidental naming, the Flutter mobile framework was founded by Eric Seidel, the Flutter AR company was founded by Navneet Dalal and Mehul Nariyawala.

Interesting. I wondered why flutterapp.com (the AR/VR app) redirected to flutter.dev (the UI framework)... It led me to believe it was the same team. Apparently not. Thanks.

Yeah, flutter.io is the same. Given Google acquired the Flutter (AR) team, I assume it was just easy for them to reuse the domains when they launched Flutter (framework).

Re: Flutter 2

#758

Post by pvinis »

davidkuennen wrote: post #404
pvinis wrote: post #375

Earlier quoted context omitted.

I just tried your app, and like the droppod.gg app and every other flutter app I've tried, there are obvious broken UI things. In the watchlist tab, with one item in the list, I am able to scroll and make the one item hide behind the navbar, and it's happy to stay like that. These things are big obvious things that make me uninstall an app even if I want/need to use it. Again, I don't know if it's you or flutter that…

Haha.. Thanks for your feedback and I totally understand. In this case tho it's my own fault and not flutters. I wanted that fancy AppBar and created that mess myself. I was actually planning on fixing all the broken AppBars in my next release.

that's cool to hear! I wish you luck

Re: Flutter 2

#759

Post by flohofwoe »

iainmerrick wrote: post #743
flohofwoe wrote: post #686

Earlier quoted context omitted.

The interaction between C and Javascript offered by Emscripten is a lot better than JNI on Android. I wish the Android NDK would steal a few ideas from Emscripten, but all the Android teams at Google don't seem to be able to look outside the nice comfy bubble they've created for themselves. With Emscripten, you can embed Javascript source code directly into the C code and then call the embedded JS function from the C…

Not bad! Sounds like the tooling has improved since I last looked. How about debugging? Is it possible to step through a mix of C and JS stack frames?

The Chrome devtools have added experimental DWARF debugging support, but for big projects that's still a bit of a hassle:

https://developers.google.com/web/updates/2020/12/webassembl...

The embedded Javascript can be debugged as usual.

In my case I usually debug the platform-agnostic code compiled natively in IDEs like Visual Studio or Xcode, and for the HTML5 specific code (which is just a few hundred lines) traditional "printf-debugging".

Re: Flutter 2

#760

Post by mraleph »

silisili wrote: post #732
mraleph wrote: post #719

Earlier quoted context omitted.

[I work on Dart VM team] `dart2native` just concatenates two binaries together: AOT runtime binary and AOT snapshot binary. AOT snapshot is an ELF binary which contains native code generated from your original Dart code. The approach is not pretty but was chosen as an implementation shortcut. That's why `strip` does not actually do good things to the binary. There is no reason to run `strip` on such binaries - becaus…

Thanks. Also noting that upx has the same behavior. I didn't inspect the binaries, just try to see how/if they compress.

We are planning to fix it some time in the future, we really only expected moderate usage of `dart2native` and only on Linux. Turns out that there is demand for using it all over the place, which includes Mac and Windows and requires things like signing support... And to make executable signable we need to make them real Mach-O / PE executables and not weird concatenations of bytes.
Post reply on HN