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

641–650 of 748 posts

Re: We're forking Flutter

#641

Post by rdsnsca »

poulpy123 wrote: post #572
divan wrote: post #120

> We describe Flock as "Flutter+". In other words, we do not want, or intend, to fork the Flutter community. Flock will remain constantly up to date with Flutter. That was the first fear when I saw the title - splitting community and having two incompatible versions. Good to see it addressed in the post. The second was just a fear of how it would complicate the development process, but it seems to be a drop-in replac…

> Flutter is the best thing that happened to UI development since Qt. Which programming languages have a good developer experience with flutter beside dart ?

None, Flutter is dart only.

Re: We're forking Flutter

#642

Post by jamil7 »

insin wrote: post #635
jamil7 wrote: post #628

Earlier quoted context omitted.

I noticed the SNCF Connect app for France's rail was using it in their showcase which explains why the scroll views are so weird and busted feeling. They still stutter on a new iPhone. As a native iOS developer I'm somewhat biased and a lot of people likely don't care but it still feels off to me even for apps that use a complete custom design. I hope they can optmise away those kind of issues more as it's IMO always…

You still have to deal with the Android build system, `flutter new` just generates initial config for it and all the other necessary metadata (and that config can change between versions - I ended up manually diffing the generated stuff against a new app every time I upgraded). At some point I made the mistake of not touching the code for too long and upgrading Android Studio when suggested, and I was never able to (…

Ah gotcha, I thought it was papered over a bit more with Flutter's tooling. Good to know.

Re: We're forking Flutter

#643

Post by jmull »

I think a big problem is that Flutter's approach is very labor intensive.

It takes over responsibility for the UI, which is tough when you want to be cross-platform. You need to keep up with the native UI across all the platforms. (Or, of course, you don't, in which case there are gaps, bugs, inconsistency, jank, etc.)

Beyond the UI, it needs to offer integration with platform services and conventions, which is another perpetual treadmill.

Not to mention it includes a dedicated language, which takes significant effort in its own right.

Add to that, that as a project gets larger and more complicated, it becomes harder to change and tech debt builds up.

It's not surprising to me issues are building up. I've got to wonder if a fork, while it can move forward in one respect, may just be adding more complexity in a project that already has too much.

It wouldn't surprise me if Flutter's unmanaged complexity is exponential, in which case quadrupling the number of dedicated engineers won't move the needle a lot.

Re: We're forking Flutter

#644

Post by divan »

jwells89 wrote: post #631
divan wrote: post #530

Earlier quoted context omitted.

There are plenty, though, and they work amazingly well on desktop: https://pub.dev/packages/syncfusion_flutter_datagrid

Depending on widgets external to the toolkit is a no-go for me. It unnecessarily bloats dependencies and there’s a high risk of the widget eventually being abandoned.

I totally get your sentiment and also try to instill the culture of "add dependency only if it's absolutely not possible to avoid it". For small widgets, I often just copy the code into my tree. And I absolutely hate when library authors break API for no reason (something that the Dart ecosystem inherited from the web one).

But limiting yourself only to standard widgets seems to be extreme.

Re: We're forking Flutter

#645

Post by munificent »

hadad wrote: post #230
ko27 wrote: post #74

Earlier quoted context omitted.

It's better in most ways, for example, just recently LG decided to rewrite its TV apps from RN to Flutter https://webostv.developer.lge.com/news/2024-07-15-new-and-su... > Most of our apps use React. When we first adopted React, we were pleased with the development productivity it provided, but sadly its initial performance was subpar in terms of start-up time, memory consumption, and responsiveness. After significan…

Misleading on the comment, LG WebOS is using EnactJS (Framework on top of ReactJS) + Chromium Embedded Browser, not native, just webapp on browser. But React Native is different , JS code compiled to native code using c/c++ compiler on target system. Flutter also do like this one. Embedded browser is slower than native app, because extra browser layer than native one.

> But React Native is different , JS code compiled to native code using c/c++ compiler on target system. Flutter also do like this one.

Sure, but you're compiling two radically different languages. JavaScript is dynamically typed (even with TypeScript) and Dart has a sound static type system.

It's much easier to compile Dart to efficient native code than it is JavaScript.

Re: We're forking Flutter

#646

Post by [deleted] »

devjab wrote: post #533
sterlind wrote: post #262

Earlier quoted context omitted.

Here's one source on Python very obviously not matching Node.js's perf on a simple microbenchmark: https://jott.live/markdown/nodejs_vs_python_ CPython really is inherently less performant than V8. CPython, until very recently, didn't have a JIT at all. It compiles scripts to bytecode, then runs the bytecode in a giant case statement. It doesn't have a tracing profiler-guided optimizer or an exotic garbage collector.…

I fail to see how Python 3.8.2 could in anyway be relevant in 2024.

[deleted]

Re: We're forking Flutter

#647

Post by pytness »

devjab wrote: post #533
sterlind wrote: post #262

Earlier quoted context omitted.

Here's one source on Python very obviously not matching Node.js's perf on a simple microbenchmark: https://jott.live/markdown/nodejs_vs_python_ CPython really is inherently less performant than V8. CPython, until very recently, didn't have a JIT at all. It compiles scripts to bytecode, then runs the bytecode in a giant case statement. It doesn't have a tracing profiler-guided optimizer or an exotic garbage collector.…

I fail to see how Python 3.8.2 could in anyway be relevant in 2024.

Relevant or not, python 3.13 shows the same thing:

Python 3.13.0: 799.6559143066406 ms

Node 18.20.4: 59.34080000221729 ms

Re: We're forking Flutter

#648

Post by munificent »

DeathArrow wrote: post #502

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…

I work on Dart.

Programming language popularity is hard. The network effects are absolutely massive. 99% of all programming languages are a rounding error away from having zero users. To start to compete with any of the big entrenched languages seems to require either:

1. An extremely easy migration story so the language can leverage ("parasitize"?) the existing ecosystem of another alread popular language. That's C++ for C, Kotlin for Java, TypeScript for JS, etc. This is definitely the easiest path to success.

But it means your language is significantly hampered in its design because of the need to be compatible with the language it's building on. This is why C++ is still failing to be a safe language and is a sprawling mess. It's why Kotlin has type erasure. It's why TypeScript, despite having a fantastically complex type system, is still unsound and can't use types to compile more efficient code.

2. A compelling platform or framework that developers want to be on so bad they'll learn a new language. Rails for Ruby, iOS for Objective-C and Swift. This is the harder path but it means the new language is less shackled to a previous one and can be more innovative.

Dart took the second path. I agree it would be nice if Dart had more pillars shoring up its success than just Flutter and I hope we get there one day. But one successful framework is more than most newer languages have and you have to start somewhere.

I'm obviously biased, but I think Dart is a good general purpose language and would work well for many different domains. But fighting against the network effects is hard and growth takes time.

Re: We're forking Flutter

#649

Post by epcoa »

dgellow wrote: post #427
epcoa wrote: post #204

Earlier quoted context omitted.

What's a native UI? The only thing closeish to a native UI is macOS and iOS AppKit and UIKit. Winforms aka Win32 is still a thing, but Microsoft has been undogfooding that and putting out alternatives for years, now WinUI3 will definitely kill off Winforms for good! What is native on Linux? Gtk, Qt, Motif (lol)? And then Android? Ironic then that Google is the one behind Flutter. The concept of native outside of MacO…

WinUI3 doesn’t kill WinForms… WPF, WinUI, WinForms all exist together

You missed the sarcasm. If all can exist together, which one is the “native” one? If the answer is all of the above, then the consistency argument for native doesn’t hold much water.
Post reply on HN