Live data from Hacker News

Flutter 3.47

flutter.dev

211–220 of 231 posts

Re: Flutter 3.47

#211
post #2

Of all the myriad projects from Google, how is Flutter/Dart the one that survived the axe? I’m not saying I hate them - I think they’re both really neat - I just don’t understand why Google keeps these limping along with weak support and no clear vision within their broader web ecosystem.

People don't get how important it is to have control over the basically the whole programming ecosystem of a particular language. Google services dominate Flutter. Look at all the services Google provides. You'll find first class support in Flutter. Compare that to AWS, Azure, etc and these usually have wip features or simple adapters. So if you like and use flutter/dart, for whatever reason really, chances are you'll use any of Google's services because their integration into the framework is much better, and the libraries are better maintained.

I am convinced they did some proper analysis in-house and continuously find that investing the flutter/dart yields returns across all other services. The language/platform is the gateway.

Re: Flutter 3.47

#212
post #155

Earlier quoted context omitted.

As someone who used all these frameworks professionally for years, I highly agree. Although, I do not prefer Expo due to it's highly annoying build system and dependency hell, but React Native itself in that case. While I understand Google wants a horse in this race, Flutter doesn't feel like a horse to bet on. - Dart is a really _ugly_ language with lots of tiny annoyances. Its as if someone took worst parts of Java…

Completely opposite experience for me. I love working with Dart (which IMO is _not_ "worst parts of Java and Javascript (...) turned (...) into a language" , "Terrible to write, terrible to read, terrible to use" - quite the opposite, actually) and its toolchain, including Flutter. I find the architecture simple to follow, no need for "either print apps as fast as possible or to emulate some Clean Code like behavior"…

What state management solution(s) do you prefer?

Re: Flutter 3.47

#213
post #155

Earlier quoted context omitted.

Completely opposite experience for me. I love working with Dart (which IMO is _not_ "worst parts of Java and Javascript (...) turned (...) into a language" , "Terrible to write, terrible to read, terrible to use" - quite the opposite, actually) and its toolchain, including Flutter. I find the architecture simple to follow, no need for "either print apps as fast as possible or to emulate some Clean Code like behavior"…

What state management solution(s) do you prefer?

I started with https://pub.dev/packages/flutter_bloc and then migrated to https://pub.dev/packages/state_beacon for my app, and so far I've settled on it. But when I publish libs to pub.dev, I stick to built-in SDK stuff.

Re: Flutter 3.47

#214

Earlier quoted context omitted.

While all of the points you brought up are valid, I've hated every react native app I've ever had to work on. Not because of react native itself, but because they usually take random react developers to work on these apps and the structure they create is absolutely horrible to work with (compared to, for example, native apps). What was your experience on that aspect with Flutter?

I agree. RN has historically attracted a lot of web developers who treat mobile like a React website, and the result can be terrible. But I've seen exactly the same architectural problem in Flutter: huge widgets, mixed responsibilities, state everywhere, and very little separation of concerns. The framework doesn't protect you from bad engineering.

No framework prevents bad engineering. If a tool is rigid enough to make messy code impossible, it becomes too limited to build anything non-trivial.

Aren't you conflating framework design with dev discipline? You can write a monolithic disaster in React, native iOS, or Flutter with equal ease. Bad architecture usually happens when devs copy-paste habits from web or imperative paradigms without adapting to a declarative model.

Flutter actually gives you great primitives for clean code. UI components are lightweight config objects, so breaking a huge screen into tiny, modular pieces has virtually zero performance penalty. Its state model naturally separates logic from rendering, making it easy to isolate business logic into testable layers. Plus, the built-in analyzer catches anti-patterns like memory leaks at compile time.

all the tools to enforce separation of concerns are there, imo

Re: Flutter 3.47

#216
post #124

Earlier quoted context omitted.

This doesn't help, desktop support was added 5 years ago, so that's longer than the age of flutter before that

Most of the team was laid off a few years ago.

This is not true on many levels:

  * Most of the team stayed at the company.
  * The layoffs hit mostly DevOps and infra people in Flutter team.
  * At least part of the laid off roles were moved offshore to Germany, India etc.

Re: Flutter 3.47

#217
post #214

Earlier quoted context omitted.

I agree. RN has historically attracted a lot of web developers who treat mobile like a React website, and the result can be terrible. But I've seen exactly the same architectural problem in Flutter: huge widgets, mixed responsibilities, state everywhere, and very little separation of concerns. The framework doesn't protect you from bad engineering.

No framework prevents bad engineering. If a tool is rigid enough to make messy code impossible, it becomes too limited to build anything non-trivial. Aren't you conflating framework design with dev discipline? You can write a monolithic disaster in React, native iOS, or Flutter with equal ease. Bad architecture usually happens when devs copy-paste habits from web or imperative paradigms without adapting to a declarat…

The case of RN is different: it's made from a web point of view and applied to mobile. Therefore, it's not per se about the framework, but rather a coincidence that mobile and web are two completely different worlds. Hence, it's quite normal to see abominations when you allow people who are used to the web to do mobile development.

Re: Flutter 3.47

#218
post #56

great for mobile apps, fine for desktops, basically unusable for browsers unless you do wasm, if web can be revamped/improved it can be the best option for cross platform GUI

You are in luck then, use jaspr.

I love this framework! It offers all the benefits of Dart and the Flutter widget paradigm on the web, while still providing access to the DOM. I'm using Jaspr for all of my marketing sites. It's beautiful, and I can ship in minutes.

Re: Flutter 3.47

#219
post #66

Earlier quoted context omitted.

Third-party analysis ( https://appfigures.com/top-sdks/development/all ) has Flutter used in 16% of iOS apps and 24% of Android apps (free) Archive link: https://archive.is/IIUaj I really don't understand how/why people deny reality so hard when it comes to Flutter. Reminds me a bit of years ago when people were still scoffing at the idea of anyone actually adopting JavaScript to write web servers with while Node.js…

It eats the market indeed, and also presents business opportunities for folks like myself, jumping in writing C++ addons, or completely replacing it with Java, .NET, Go, Rust,....

All the more reason why it's important to have an accurate read on the market! I for one also know a few people who've made a pretty penny writing native integrations for React Native and now Flutter apps.

Re: Flutter 3.47

#220

Earlier quoted context omitted.

They still haven't got native scrolling perfect for iOS. I used a big name app just today and I could instantly tell without looking it up that it was a flutter app, because the scrolling felt non-native.

This is fixed in the past few versions of Flutter, they likely haven't updated their SDK.

If that's the case I might reappraise flutter!
Post reply on HN