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

We're forking Flutter

flutterfoundation.dev

Post reply on HN
Print view View original

431–440 of 748 posts

Re: We're forking Flutter

#431

Post by lolinder »

malkia wrote: post #418
lolinder wrote: post #400

Earlier quoted context omitted.

If Flutter is a car, Python is at least four different models of car, plus three models of light truck and one airplane. The scope of Python's standard library is just enormous.

true, but still - these libraries can be updated independently, one from each other - with a framework, things have to be orchestrated.

In general in PLs this is not true—the standard library is usually very carefully designed and all of its interactions are well-considered—but Python's libraries do seem to be more independently-updated than most.

Even so, isn't that an argument for a smaller, integrated team for the framework, rather than a large one made of ~1000 volunteers? A tightly-knit framework is much more likely to suffer from too many chefs than a disparate collection of library functions.

Between the parallelization problems inherent in a tight framework and the fact that its total surface area is also smaller than a PL that's maintained by about the same number of people, it sure doesn't sound like Flutter's problem lies in developer headcount.

Re: We're forking Flutter

#432

Post by toast0 »

zerr wrote: post #90
droideqa wrote: post #85

Earlier quoted context omitted.

The power of Erlang.

Modified Erlang. Genuine one didn't scale.

The whole point of running an opensource OS/vm/runtime/etc is that you can tweak things here and there when you need them.

Yeah, we had to make changes, some changes to FreeBSD too, but mostly little changes here and there. Erlang and FreeBSD were both lovely to work on.

Re the sibling's question about what was changed, I don't remember everything, Rick Reed's presentations at Erlang Factory / Elixir describe most of them though (although those ended in 2014, I think). Many or most of the changes got into upstream one way or another. But most of it were things because AFAIK, we had much larger Erlang clusters than the rest of the community; I remember seeing advice about large clusters of 50 when we were running 300 nodes in a cluster, and I'm pretty sure we had dist clusters above 1000 later when we also had separate cross cluster messaging. We also had huge mnesia tables, other people said don't use mnesia over 2GB, and we had nodes with more than 512GB of data in mnesia. I don't really remember much that we had to do with dist, although pg2 needed help and our replacement became pg in OTP, mnesia did need some help to scale. We changed the ETS hash kernel to avoid everything hashing the same way, I don't know if that made it out.

We also needed to do things like timer wheel improvements, but OTP also did timer wheel improvements and we dropped ours. Not so many people were running quite so many timers.

Then there were things that I don't think are upstreamable. Adding a way to drop a process's message queue. Adding a way to add a message to the front of a process's message queue. Those two are very not in line with OTP, but handy for operations if you use them carefully.

Re: We're forking Flutter

#433

Post by owaislone »

Sounds like Flutter core teams hold contributors to a high standard and the Javascript bros can't deal with real Software Engineering so they're having a party of their own.

In all honesty, good luck. It might be useful if it never breaks compatibility with Flutter.

Re: We're forking Flutter

#434

Post by croemer »

sgt wrote: post #26

Key statement: "As Flock ships important bug fixes and features, the Flutter team can then choose to add those to Flutter, on their schedule. " I see a lot of negative comments but I think this will be a net positive over time to the Flutter community and to the technology itself. I think it will also give Google a reality check on the needs of the community.

Wouldn't it be good to launch with at least a few bugs fixes? The launch is a bit thin, just mirroring, nothing to offer?

Re: We're forking Flutter

#436

Post by kevin_thibedeau »

lolinder wrote: post #403
FredPret wrote: post #394

Earlier quoted context omitted.

But those are modules added on by developers other than the 50 core devs.

The standard library alone has a huge scope which includes a (mediocre) GUI toolkit.

It includes another scripting language with a GUI toolkit. The Python part is just a shallow wrapper over third party code.

Re: We're forking Flutter

#437

Post by drilbo »

no_carrier wrote: post #351
flawn wrote: post #59

Earlier quoted context omitted.

If you have an Android phone, get FlutterShark and check which of your installed apps use Flutter. It's a surprising amount actually. For example, I just recently discovered that Supercell uses Flutter for their Supercell-ID flow.

I have a pretty limited understanding of mobile sandboxing, but how does FlutterShark have access to analyse all the apps on my phone?

>android.permission.INTERNET

>android.permission.QUERY_ALL_PACKAGES

>com.google.android.gms.permission.AD_ID

>android.permission.ACCESS_NETWORK_STATE

>android.permission.WAKE_LOCK

>android.permission.FOREGROUND_SERVICE

seems like imo the type of thing you should be prompted for but what do I know

Re: We're forking Flutter

#438

Post by ivm »

ClassyJacket wrote: post #256
textlapse wrote: post #39

If someone could do the same with Xamarin/Maui that would be awesome! It’s going down the same path unfortunately as Flutter did. Microsoft has de-staffed and deprioritized Xamarin/Maui to a point most of the folks are in Aspire-dotnet and related efforts?

It's such a shame mobile development with C# isn't more viable. I want to make some apps, and I hate JavaScript, but from everything I've read Maui just isn't practical.

The native approach is quite viable: my MvvmCross-based app has been on both stores since 2018 with almost zero MAUI/Xamarin-related issues, even with hundreds of thousands of installs.

Not gonna lie though: building the UI twice for both iOS and Android feels somewhat masochistic. But in the end, it "just works" with shared View/ViewModel logic on both platforms.

Re: We're forking Flutter

#439

Post by 1oooqooq »

wruza wrote: post #393
nox101 wrote: post #280

Earlier quoted context omitted.

flutter's custom canvas render on web means so much of the web stops working or is slow. type anything non ASCII like an emoji or CKJ and eat while it downloads a font. No other pages do this. Text fields are missing all the standard context menu options like define, translate, etc... Things that would be selectable on any other page are not, etc....

This. They can have all the deviations they want, but “input core” must be native. If a framework ignores it, users will notice and frown upon it immediately. When flutter came out publicly, first I thought no way it can get away with custom everything. But it turned out some developers don’t care about that at all.

you know that zero texting apps nowadays use native input anyway right? even native apps will implement their own input and it's always awful, but the pm needs those style previews... (you're still right thought)

Re: We're forking Flutter

#440

Post by jonas21 »

hyperhopper wrote: post #358
dotancohen wrote: post #208

Earlier quoted context omitted.

Is the complete lack of accessibility still the giveaway? Last I looked Flutter was a complete nonstarter for accessibility.

I worked on the GPay flutter rewrite and our standard for accessibility was higher than almost any other app I've seen, and was a significant amount of effort spent on that. What accessibility shortcomings does flutter have?

This may be a silly question, but how do I install the Google Pay app on my iPhone?

I'd like to try it out since it's the first app listed in the Flutter Showcase, people keep mentioning it in this thread, and it probably works as well as a Flutter app can, given that it's first-party from Google.

But when I search for it on the App Store, it's nowhere to be found (or at least not in the first 20 results).

Post reply on HN