Live data from Hacker News

We're forking Flutter

flutterfoundation.dev

711–720 of 748 posts

Re: We're forking Flutter

#711

Earlier quoted context omitted.

> we do not want, or intend, to fork the Flutter community. I can't reconcile that statement with the rest of the blog post. Good intentions aside, this is exactly what they are on the path to doing. From the post: > By forking Flutter, we get to decide what gets merged. I'll allow myself to be naively blunt since I just learned of this and I don't have a stake in this battle, but it seems like a nice little coup att…

> can squash by putting more resources into Flutter So success?

This reminds me of io.js, which started as a fork of NodeJS but was eventually merged back upstream

Re: We're forking Flutter

#712
post #701

Earlier quoted context omitted.

Only on HN do I hear anyone talking about platform native controls versus unified UI across devices. I have not once heard of such a complaint in the real world and indeed, I have more often heard users wanting a unified UI over one that changes with each platform, simply because these days we have multiple devices where we expect apps to work the same.

People have multiple devices, sure, but in my experience (among non-HN people) it's iPhone+iPad or iPhone+mac dominating, with a decent contingent of iPhone+Windows, and rarely Android+Windows. (This is of course US-centric; the iPhone is more popular as a mobile platform, and that often entices people to buy into other aspects of the Apple ecosystem.) It is exceedingly rare for the multiple devices to span the UI to…

I think you made the same points twice so refer to my other reply regarding your first few paragraphs.

> For people in the Apple ecosystem, they don't want to see something that looks like it belongs on Android.

I have not seen evidence among normal people that this is true, given that the most popular apps all have custom UIs that don't necessarily follow Apple's HIG, TikTok for example. Regardless, the point is that if you're making an app for every platform like iOS, Android, Windows etc, you must make a choice lest you exclude all non-Apple users for example. ByteDance does therefore indeed use Flutter, based on this (at least in some capacity).

> mobile, tablet, and desktop experiences are often quite different

Don't conflate unified UI to mean non responsiveness. Look at Spotify, their UI is essentially the same in design except it is responsive among mobile, tablet and desktop, all while not looking native at all on any of them.

Regarding accessibility, many frameworks can be robust in that simply because they hook into the native implementation anyway, so I'm not sure where this trope of not having accessibility comes from. Here is Flutter's for example, with a dev in this thread also having talked about how they have one of the most robust implementations of accessibility that they have found among any framework: https://docs.flutter.dev/ui/accessibility-and-internationali...

Re: We're forking Flutter

#713

Earlier quoted context omitted.

on behalf of one of the Flutter founders, thank you for the thank yous. I bet they'd mean a bit more if it wasn't coupled to a lengthy thinking-out-loud post that casts doubt on it, based on how many job listings you see, for something you don't look for job listings for. Quick Google shows Dart 10th, right below SQL, right above Kotlin. https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...

> I bet they'd mean a bit more if it wasn't coupled to a lengthy thinking-out-loud post that casts doubt on it, based on how many job listings you see, for something you don't look for job listings for. Did you really just thank the guy for saying thanks, but give him a big fuck you in the same breath for not being a 100% kool-aid drinker? Speechless.

Absolutely speechless. on behalf of one of the Flutter founders, he made all of them look bad.

Re: We're forking Flutter

#714

Earlier quoted context omitted.

Casual users do care about app behaving wrong, though. If you can't copy or paste things, or if the navigation is backwards, or if the calendar looks weird etc etc - it all causes some minor frustrations, when things don't behave as user wants them to behave. They don't know what "native" means, obviously - they don't have that knowledge. They just know crappy apps from well-behaving apps, because they have a frame o…

Is there a concrete example of this? I still only hear this on HN where some mythical user gets annoyed about copying and pasting (most apps don't allow that, even, like TikTok or Instagram, which are the apps where most users spend the most time). Like the sibling commenter, I only have seen whether the app does what they want or it doesn't, most don't notice any annoyances unless they're really looking for them, wh…

> I still only hear this on HN where some mythical user gets annoyed about copying and pasting

Perhaps they're not complaining because they've just accepted that it probably doesn't work and so don't even try anymore.

My SO has stopped trying to copy/pasting stuff, I now always just get screenshots, both from mobile and her PC.

At work, almost none of the customers I interact with copy/paste stuff, they send screenshots as well. Like, "can you send me the order number?" will result in a screenshot of the order number control, or often just the whole order window.

Re: We're forking Flutter

#715

Earlier quoted context omitted.

The issue in this case is pretty plainly that the application does not subscribe to the conventions of its host UI. I'm sure there is no objective reason why we need to conform to any convention, except that there is one.

Then that is subjective too and not really worth caring about, because it comes down to a matter of taste. You like platform conventions, but most people we surveyed simply don't care, the fallacy of vocal minorities and all.

I'm sure that Soviet architects would have agreed with you.

Re: We're forking Flutter

#716

Earlier quoted context omitted.

> I bet they'd mean a bit more if it wasn't coupled to a lengthy thinking-out-loud post that casts doubt on it, based on how many job listings you see, for something you don't look for job listings for. Did you really just thank the guy for saying thanks, but give him a big fuck you in the same breath for not being a 100% kool-aid drinker? Speechless.

Absolutely speechless. on behalf of one of the Flutter founders, he made all of them look bad.

I like to just think he's passionate.

My point was you just can't count SDK downloads as developers. Is every CI/CD pipeline a developer ? The founder of Flutter who posted that stat has a startup which is heavily invested in the perception of Flutter being popular.

In the Unity community we aren't afraid to critique Unity and even suggest trying other engines. Of course Unity isn't open source so you don't get articles like this where someone claims it's time to fork.

At the same time, Unity uses C#, so you can take your skills, and even some nuget packages( with a bit of work) elsewhere if you want to switch.

Flutter requires a higher time commitment since I have to learn a language that's exclusive to Flutter. If this ship goes down I can't use Dart with anything else.

Anyway, I think job postings are a much better metric of adoption. I like Flutter, I've used it for 4 years and I want it to succeed. I don't want to go back to react native!

Re: We're forking Flutter

#717

Earlier quoted context omitted.

There's no hot reload in Android (kotlin) dev? Wow

yeah, it fascinates me - both Apple and Google started these new UI framework things after Flutter, and both didn't land it, but instead, landed some half-baked thing where individual components can render live in the IDE . That may sound more useful than it is: think "oh I can specify a dummy title and subtitle for a list view cell in code, then open a special pane in the ide to preview a source file, and then resiz…

> both Apple and Google started these new UI framework things after Flutter, and both didn't land it

For Flutter to have fully landed it, it would take more than just hot reload. I'm not familiar with the latest but what are the chances of the Flutter rendering stack "going native" (as in not drawing to a Skia canvas or similar) on at least Chrome or Android? Or, is that the wrong question?

Re: We're forking Flutter

#718

Earlier quoted context omitted.

Then that is subjective too and not really worth caring about, because it comes down to a matter of taste. You like platform conventions, but most people we surveyed simply don't care, the fallacy of vocal minorities and all.

I'm sure that Soviet architects would have agreed with you.

Perhaps so, as different cultures have different tastes anyway. That you don't like Soviet styles is no indication of whether people in the Union did or didn't like them.

Re: We're forking Flutter

#719

Earlier quoted context omitted.

yeah, it fascinates me - both Apple and Google started these new UI framework things after Flutter, and both didn't land it, but instead, landed some half-baked thing where individual components can render live in the IDE . That may sound more useful than it is: think "oh I can specify a dummy title and subtitle for a list view cell in code, then open a special pane in the ide to preview a source file, and then resiz…

> both Apple and Google started these new UI framework things after Flutter, and both didn't land it For Flutter to have fully landed it, it would take more than just hot reload . I'm not familiar with the latest but what are the chances of the Flutter rendering stack "going native" (as in not drawing to a Skia canvas or similar) on at least Chrome or Android? Or, is that the wrong question?

Yeah hot reload's just a one-off example that I think is the simplest way to relate the experience of SwiftUI vs. Compose vs. Flutter, though, the first two are long in the rear view mirror, I've been Flutter only for about a year.

Good question -- I don't think its the wrong question? Maybe? :P Tough to phrase on my end too.

I only feel native speaking in iOS or Flutter, even with the Android experience, forgive me: I guess I'd summarize it as "yeah, you're right. if you're wondering if they're ex. calling CoreGraphics on iOS, no" (well, they do, but for text rendering. Not for a red rectangle)

Generally, Flutter Web is rendering into a WebGL surface using Skia -> WASM (2.2 MB download! modern miracle). macOS, iOS, (done) Android (soon) are switching from Skia to Impeller. I think the thrust of your question is "are they still bundling the render engine?" and the answer is yes.

I find the way you phrased it intriguing, in that, before reading your post I'd say drawing to a Skia canvas is as native as you can get. But I realize now that means I was overindexing on "close to the metal", and its apex not-native to say "gimme the framebuffer and i'll take it from there"

I'm a bit picky with design stuff and I loooooove that Skia's bundled and I can rely on it cross platform

Re: We're forking Flutter

#720

The thing I dislike about Dart and some other language like Swift or Ruby is that they only have one application. With Dart you write Flutter aps. With Swift you write iOS apps. With Ruby you write Rails apps. Java, C#, Rust, C, C++, Go, Python are usable for more than one thing. I am not saying Dart and Flutter aren't nice, but for sure I would love to see Dart extending to more than just Flutter and making Dart usa…

Ruby is exactly as versatile as all those other languages you list. It was made before Rails was, and it can do everything eg Python can. It's not very popular anymore outside Rails but eg lots of people did APIs in Ruby using stuff like Sinatra. I personally did lots of CLI utilities in Ruby. It's really nice for stuff like that.

Yeah not sure why this is downvoted it is true, a lot of the open source tooling for ios is built in ruby and plenty of people build scripts and cli tools in ruby.
Post reply on HN