Live data from Hacker News

Flutter 3.47

flutter.dev

121–130 of 231 posts

Re: Flutter 3.47

#121

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.

Ah, that's a shame to hear. I would only like to add that at least for Android apps that I've been "hanging around" (my team never really worked on them), the teaching materials that are provided have generally made them a lot more pleasant compared to the RN stuff.

Re: Flutter 3.47

#122
post #81

I still prefer React Native with Expo over Flutter, mostly for practical reasons: * Language and hiring: TypeScript has a much larger developer pool. Dart is a solid language, but finding experienced Flutter engineers is harder. * Platform model: React Native maps much more naturally to native platform concepts. Flutter owns much more of the rendering stack, which is powerful, but also creates another abstraction lay…

You should try Dart/Flutter again, they've improved a lot. - Dart. It's richer than JS/TS with stronger type safety, and seems purpose-built for UI. Fewer Dart developers than JS, but I'd argue those JS developers cannot be immediately effective coding React Native (Expo) anyway. - Emulated components vs. real native components. For multi-platform apps, this is actually desirable. These kinds of apps have their own d…

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.

Re: Flutter 3.47

#123
post #118

> Linux and Windows now support popup windows, allowing you to build native context menus and utility palettes. How does such a basic feature only get added so late?

flutter started as a mobile framework, and mobiles didn't support multi windows back then

Re: Flutter 3.47

#124
post #118

> Linux and Windows now support popup windows, allowing you to build native context menus and utility palettes. How does such a basic feature only get added so late?

flutter started as a mobile framework, and mobiles didn't support multi windows back then

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

Re: Flutter 3.47

#125

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 was forced to migrate from pure native development to React Native and Redux is one of the stupidest things I ever witnessed. Or at least the way the previous devs setup that thing, because it’s so easy to make costly mistakes with it. I lost so many days of my life profiling and debugging to figure out why hundreds of components were re-rendering when a tiny thing changed somewhere completely unrelated

> figure out why hundreds of components were re-rendering when a tiny thing changed somewhere completely unrelated

Could you explain how this comes from React Native and/or redux?

I have used Angular with redux (ngrx) and redux made it quite obvious what changed what and why

Re: Flutter 3.47

#127
post #78

Earlier quoted context omitted.

Native was always the best. It was just time consuming, requiring a bigger team. Now with AI helping out, it's probably the best option by far. I still like Flutter a lot though because you can get stuff done fairly quickly and even apply Material design to the iOS apps or vice versa if you want to (if it's a business app where the design doesn't matter too much). Or if you e.g. target win32

In most cases yes but if you don’t want native elements and you want your app to look exactly the same on android as on iOS then flutter is a better choice. Assuming you don’t have any performance limitiations.

Why would you want apps on different os look exactly the same?

Re: Flutter 3.47

#128

how's Dart for back end development? is anybody using it to build APIs? the syntax doesn't look too bad

While the server side is still growing and obviously not as huge as Java etc., Dart definitely is being used on the backend. For instance, https://pub.dev/ itself is written in Dart: https://github.com/dart-lang/pub-dev . :)

The language, like any other, does have some weaker parts, but in general is _very_ nice to write in - thanks to both the language itself and the toolchain built around it.

The apps compile to native binaries for production and are run in Dart VM during development. The SDK is multi purpose. You can write "scripts", you can write CLI apps, servers and with Flutter - the rest of them.

Re: Flutter 3.47

#129

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 was forced to migrate from pure native development to React Native and Redux is one of the stupidest things I ever witnessed. Or at least the way the previous devs setup that thing, because it’s so easy to make costly mistakes with it. I lost so many days of my life profiling and debugging to figure out why hundreds of components were re-rendering when a tiny thing changed somewhere completely unrelated

Redux is great and it solves exactly that problem.

You create a selector. You use the selector in a React component.

The component re-renders when the selector outputs a different value, with the usual reference equality caveat.

Does it get any simpler than that?

However, yes, I have seen most developers use Redux incompetently.

They would use actions like "setOrder" instead of "itemAdded", defeating the purpose of a state machine from the start.

Post reply on HN