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

421–430 of 780 posts

Re: Flutter 2

#421

Post by amelius »

jaegerpicker wrote: post #409
amelius wrote: post #367

Earlier quoted context omitted.

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

If OS vendors wanted web-apps to succeed, they could have done a lot more than they have done so far. E.g. better integration, or improved web standards to optimize for certain cases.

Re: Flutter 2

#422

Post by Hixie »

ROARosen wrote: post #344
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.

> We've been working with the GPay team the last couple months and have made significant improvements within both Flutter and the GPay app So seriously, how can you reassure any indie dev not getting VIP support to optimize their app for laggyness, that they can easily produce a decently performant app?

Many of the lessons we learn with GPay directly fed into improvements in the framework, improvements in our tooling to make this kind of debugging much easier, and better documentation to try to scale the knowledge to the whole community. Some of these have already shipped (see e.g. new features in our DevTools) and much more will continue to deploy over the coming months.

Re: Flutter 2

#423

Post by BorisEm »

dmitryminkovsky wrote: post #292
qbasic_forever wrote: post #286

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?

For Facebook and Apple, mobile (native) is definitely the most important.

Advertising accounts for 99.9% of Facebook revenue, with mobile advertising accounting for 94% [1]

Not sure for the other ones.

[1]https://www.businessofapps.com/data/facebook-statistics/

Re: Flutter 2

#424

Post by marcusjt »

timsneath wrote: post #147
sydd wrote: post #106

Earlier quoted context omitted.

Thanks for the reply! What about a11y? Can you navigate a Flutter page via keyboard? What about screen reader support?

Yes, we consider accessibility a must-have feature. On the web, we have a second DOM tree called the SemanticsNode tree, which is generated in parallel to the RenderObject DOM tree. The SemanticsNode tree translates the flags, actions, labels, and other semantic properties into ARIA attributes. We've been testing Windows Narrator, VoiceOver, TalkBack, and ChromeVox screen readers to navigate a Flutter web app.

NVDA is the primary screen reader for 40.6% of them (swiftly followed by JAWS at 40.1%) so why aren't you testing with it? https://webaim.org/projects/screenreadersurvey8/#primary

Re: Flutter 2

#425

Post by Hixie »

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…

I can't speak for Jetpack, but as far as Flutter goes: Flutter is open source, we do all our work in the open. File a bug; we look at all our incoming bugs and there are members of the Flutter team (volunteers as well as people from Nevercode and Google) who try to reproduce each issue. We don't always have the bandwidth to fix everything, but last year we fixed roughly as many bugs as were filed, so the odds are pretty good. (And of course you're welcome to try to fix the bug yourself, we accept PRs from anyone, not just Googlers. See our contributor guide on GitHub.)

We don't have an official foundation, but we are already operating more or less as openly as we would if we did. We have contributions from lots of companies and volunteers; the majority of the people who have contributor access in fact aren't from the Google Flutter team.

Re: Flutter 2

#426

Post by heavyset_go »

tobyhede wrote: post #416

Flutter is not for everything, but it is really worth a look. We (AU MVNO/Telco) recently converted iOS and Android apps (200,000 MAUs) to Flutter and it has been game changing. We had experimented with react native and found it just didn't deliver. Flutter is different. On mobile platforms the experience is super responsive and smooth and for your typical consumer app indistinguishable from the native experience. Th…

> We had experimented with react native and found it just didn't deliver

Can you expound on why you found that React Native didn't deliver?

I've played with Flutter a couple of years ago, and I'm revisiting it and React Native before building an app on a one person team.

Re: Flutter 2

#427

Post by agucova »

qbasic_forever wrote: post #378
eseidelGoogle wrote: post #98

Earlier quoted context omitted.

[Flutter Eng. Dir. here] Still relatively early days for Flutter Web, so I would not be shocked if it's not buttery everywhere. However, we would certainly love to learn more. fluter.dev/support has links as to how to file an issue if you're interested. https://flutterplasma.dev/ is one demo to try. We expect to be updating flutter.dev/web and flutter.dev/showcase to update more over time.

The plasma demo you linked runs at a stuttery 40fps on Firefox (ubuntu 20.10) on a quad core Ryzen 5 laptop. The fans immediately spin to max speed. I'm not impressed... Here's a hard question, why is this surprising to you? What are you missing in development--is this a gap in testing? Are you hamstrung without support internally to bake this as long as it needs? Rather than double-down on extolling the virtues here…

I got 14 fps with heavy stuttering and freezing with my i5-9300H with 8 cores :(

Re: Flutter 2

#428

Post by pmontra »

mdoms wrote: post #197
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…

I just visited flutterfolio.com. The very first thing I tried to do is enter a username and Tab to the password field. But Tab just catapulted my input focus to the browser address bar. I mean, come on.

I went there. It didn't register my first attempts to tap into the email field. I tapped the password and it worked after that.

But a demo site asking to register an account to see the demos? I gave up. It almost like they are not interested to show their demos.

Re: Flutter 2

#429

Post by tofuahdude »

jaegerpicker wrote: post #220
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…

Are you a native mobile developer? I am (was I'm moving to ML/AI/Data engineering) and I don't think flutter is in any way easier or nicer than the native toolchains for mobile. Both Swift and Kotlin are better languages than Dart IMO, the IDE and tooling is far superior for both also. Flutter is faster but once to deploy a substandard quality of app for sure but matching the quality of a native app? That takes just…

What are your thoughts on the business end of deciding to build two separate versions of the app in two languages (not to mention the web) vs the efficiencies of one code base?

We're close to needing to make this decision and I'm real hesitant to introduce two additional languages (we're already React for the web but haven't build apps yet) vs a React Native app where our team can be immediately productive.

Re: Flutter 2

#430

Post by okamiueru »

kroltan wrote: post #391
okamiueru wrote: post #368

Earlier quoted context omitted.

Haha. That's alright. That looks super neat though, I must admit. The only equivalent that comes to mind would be using an abstract class. I still might fail to fully understand what that code example does, but, would this be somewhat similar? abstract class AppState {} class AppLoading extends AppState { final int progress; } class AppSelectingLevel extends AppState {} class AppPlaying extends AppState { final Level…

Indeed, that is basically what you get from unions, except the exhaustiveness check. Unless I'm mistaken, if one were to later implement a new class that extends AppState, all existing code would compile, but possibly fail or misbehave at runtime, unless you meticulously checked every place that tries to determine something based on those derived types. In TypeScript, adding a new case for an union and not handling i…

I suppose. In practice, I haven't experienced this to be a problem. Since you already check which implementation you are dealing with, any code that relied on any state, should still work without any issue. This is the same as with typescript unions. Any code that somehow needs to handle a new state hm... I suppose getting a compile time error is nice to immediately see all places where it is used... but, I mean, so would a "find all uses" search. It's also not all that different from the linting warning error you'd get from iterating over runtime types without handling all cases.

All in all, sufficiently analogous to not consider unions a missing feature of the dart language? Seems nice to have, but, maybe not very necessary. Especially if the only difference is whether it is considered an error by the syntax, or a warning by the linter.

Post reply on HN