Live data from Hacker News

Flutter 2

developers.googleblog.com

401–410 of 780 posts

Re: Flutter 2

#401

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.

Isn't the licensing for Qt a very curious and weird quagmire? Maybe it's better these days but I remember about 10 years ago there was a weird divide and unanswered questions about if you could really take a bet on using Qt and not be violating GPL.

It's better these days. For desktop application development, Qt is available under the LGPL and the Qt commercial license.

Qt for WebAssembly is available under the GPL3 and the Qt commercial license, though.

Re: Flutter 2

#402

Earlier quoted context omitted.

The accessibility is a bigger concern, but flutterfolio.com also A) lags on my work machine when tabbing through fields B) doesn't handle HDPI screens well (the entire interface looks blurry) C) keeps fields visually indicated as selected even when I click outside of the browser (if I start typing, is it going to go into the field or not?) D) has a separate touch mode? Touch doesn't just work? Looked up another of th…

[Flutter Eng. Dir. here] I really appreciate the feedback. We clearly have more work to do on the Web side of Flutter. Unlike the Mobile side which has shipped 100,000s of apps, the Web side may be up to like 1000. :) So many more issues to address as we work closely with more users to get their apps into production. If you'd like to track progress on any of these, I'd encourage you (or anyone else reading) to please…

I appreciate that building something that works even this well targeting Canvas must have been a metric ton of work, and I'm impressed. But that's kind of the issue -- it cannot possibly be more work to maintain a separate rendering/compilation pipeline for browsers than it is to rebuild the entirety of Chrome's DOM engine in WebGL for CanvasKit.

I just don't see how Flutter is going to keep pace with "native" web apps when the team is constantly playing catch up every time a new medium, input method, or browser feature comes up.

Handling scroll is hard enough, is this going to handle WebVR? Can I control this web app with a voice assistant?

Sorry if this is something of a dismissive answer, but I'm not sure what the right way is to file an issue that boils down to, "it seems like you picked literally the hardest possible way to build a web GUI toolkit, and I'm very impressed that you have anything that's usable at all, but I also don't understand why you did this."

I don't know, I don't want to be overly negative here, but I don't have any confidence at all about the overall strategy that Flutter is pursuing. In order to get accessibility to work, you're basically going to end up building a DOM representation of these apps anyway. It's just now you have to build a DOM representation and you have to completely reimplement the rendering stack and capture all of my events? How are you going to make something like that performant across every browser?

I want to echo a few other comments I've seen here that this result isn't really surprising to me. I guessed before I clicked on the demos that they probably wouldn't handle scroll events well, because I know how you're building Flutter for the web, and I have never seen any GUI frameworks targeting pure Canvas on the web that don't have basic errors like this. If Flutter ever managed to be the exception, that would be very surprising to me. I don't know what Flutter's internal process looks like, I'm not going to tell you you're building something wrong. I only know what the end result looks like, and I know that end result is not going to radically improve any time soon.

It's not my place to tell any team what to do, and nobody is obligated to care what I think, but... I don't know, the demos online do not leave me feeling confident about Flutter's future. I don't think the experience as it exists today is the result of a bunch of isolated issues/bugs that can be fixed one at a time.

Re: Flutter 2

#403
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…

It's not clear what you're arguing for or against. Google Pay is a product with multiple features and one of them is being phased out. What's that to do with the benefits they're claiming from the rewrite of the mobile app?

> removed feature disparity

After April 5, I will have to use the app so that I can get back functionality that I once had on the web.

Re: Flutter 2

#404
post #375

I created apps in cordova, react native and now flutter and I have to say flutter beats both by a lot. It's just been such a nice experience. I'm absolutely in love. My most successful app in flutter is https://stockevents.app if you want to try.

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.

Re: Flutter 2

#405

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…

Can’t speak for others, but I still want a proper set of primitives and not yet another rightest-way-to-do-it sdk whose examples stutter on top hardware and will be great tomorrow. Time to go sleep I guess, will check it in 8 hours. All I want is untangling of the mess a css boxing model is, not just some buttons on canvas. I wrote gtk-flavoured widget drawing libs for few times in Lua+cairo ten years ago and these ran smoothly on a hardware than couldn’t even boot an OS today, except some rare stop the world gc issues Lua had back then. It was no big deal, and strange (not really) that Google Itself couldn’t beat that score.

Re: Flutter 2

#406

Earlier quoted context omitted.

The same engine of HTML + JS has powered entire businesses and industries from $0 to billions and billions of dollars over 25 years. Amazon.com would not exist without web browsers, and its entire trillion dollar+ business is an enormous bet on the web. I would say there's zero danger of the web going away when folks like that (and many, many more... Google, Facebook, etc.) depend on the web for every microsecond of…

If today FAANG had to choose: shut down your websites or shut down your native apps: which would it be? Which platform did Clubhouse build out first? Why?

They can collect more metrics and have more control when it's a native app. My web browser is still my most used app on my phone.

But I think betting on the web actually meant to bet on native for each respective platform. Bet on native for the web is betting on HTML/CSS/JavaScript. And then have a Java/Kotlin version for Android. And have a Swift/Objective C version for iOS

I think the learning is, write once run everywhere is what has been tried and failed time and time again for user applications. Java failed many times, Silverlight, Flash, etc.

The reason is always the same, user experience is limited when you go that route, and it eventually loses out to competitors who offer the better user experience on the user's platform of choice.

Re: Flutter 2

#407
post #348
post #178

Earlier quoted context omitted.

Dart is extremely easy to pick up if you've written in any C style language. Someone in our team had a small Android TV app working in 2-3 days with WebSockets, web views, some animations, etc.

Yeah but it’s usefulness is really limited and just feels shoehorned into the project. Why couldn’t it have been Kotlin or TS? Something that mobile developers or web developers could jump into and keep a bunch of their existing tooling.

Then you would've needed to package a JVM or a JavaScript engine, making the app distribution a whole lotta different deal.

Re: Flutter 2

#408

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…

How many times has Google done this? And then gotten bored of their own work? JavaScript, with all its many many warts, is widely supported, incredibly popular, and not going anywhere. I'm not about to waste my limited weekend time learning Flutter 2, knowing it's going to be in the trash bin by 2023. I'd rather suffer through some more JS warts and get better at avoiding them.

> How many times has Google done this? And then gotten bored of their own work?

Google's history on this sort of thing isn't good but this will be much more stable than their other offerings. Dart is the primary language of the ads (i.e. money making) side of Google and Flutter is their best shot at making the language relevant elsewhere. I'm still not in a hurry to learn it but I'd be very surprised if it's in the trash bin within 5 years.

Re: Flutter 2

#409

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.

Or maybe because native apps are a better experience, nearly every time. True multi-threading, native code performance, latest UI implementation, more and better hardware access/performance, etc.... I can keep going but the point is that the web really is the lowest common denominator. That isn't bad but it also isn't how you build the best experience.

Re: Flutter 2

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

Thanks for the tip, but the compiled version exhibits the same juddering/choppiness for me, most noticeably in the rotations.
Post reply on HN