All you should know about Flutter development • Hacker News Board

Re: All you should know about Flutter development

#81

Post by scarface74 » Sat, Feb 12, 2022, 6:14 PM UTC

mhoad wrote: post #80

scarface74 wrote: post #51

Knowing the history of Google when it comes to abandoning projects, why would I tie my horse to any Google cross platform framework?

I think a simple heuristic would be who is using it internally. It’s their payment platforms and Ads platform and a centrepiece of their upcoming operating system. It has literally billions of dollars depending on it. It’s not going anywhere.

Their cross platform mobile framework is not part of that strategy. In fact, Google has already said that they are moving toward more native development for iOS.

https://9to5google.com/2021/10/10/google-ios-apps-native/

Re: All you should know about Flutter development

#82

Post by ramesh31 » Sat, Feb 12, 2022, 6:15 PM UTC

samwillis wrote: post #10

I think developers often want to find a “one true cross platform toolkit for all cases” and I don’t believe that will ever exist. It depends so much on both your app/market but also the skills and experience within your team. No 1 priority is move quickly. Flutter is brilliant, and probably the way to go, for some apps. A great example of a successful Flutter app is the Sonos app, relatively simple and responsive ui…

>If you are building a b2b SAAS app I would probably reach for something like Ionic/Capacitor. You can share almost all you codebase with your web/PWA/desktop (electron) apps and can achieve it all with a tiny team. If you need a little more native functionality then adding in NativeScript to a Capacitor works very well.

Honestly nowadays with Expo I would never suggest doing a hybrid app anymore unless you have a large existing JS codebase you want to leverage. Expo makes React Native development so ridiculously simple from the point of scaffolding your app all the way through the app store submission process that there's really no productivity loss anymore vs. doing an Ionic app. The tooling has come so far in the last 10 years that you can just easily develop a native iOS app in Javascript like it's a web app now.

Re: All you should know about Flutter development

#83

Post by pzo » Sat, Feb 12, 2022, 6:20 PM UTC

pepalgarid wrote: post #3

I feel that Flutter raised very high interest but it has fallen behind its expectations. Not that trendy anymore.

I think they should give up on Flutter for Web and just focus on mobile and desktop (and maybe extend use on Smart Watches, Smart TV, embedded instead). Too many people still remember Java Applets, google's GWT, Flash/Flex and how it ended. They are out of focus trying to support Web as well.

I had also higher expectation regarding Dart FFI - I think with their ffigen we are still only in ctypes like python bindings territory. Nowhere near something like pybind11 [0] for c++ bindings yet.

[0] https://github.com/pybind/pybind11

[1] https://github.com/mozilla/uniffi-rs

Re: All you should know about Flutter development

#84

Post by Aulig » Sat, Feb 12, 2022, 6:32 PM UTC

scarface74 wrote: post #81

mhoad wrote: post #80

Earlier quoted context omitted.

I think a simple heuristic would be who is using it internally. It’s their payment platforms and Ads platform and a centrepiece of their upcoming operating system. It has literally billions of dollars depending on it. It’s not going anywhere.

Their cross platform mobile framework is not part of that strategy. In fact, Google has already said that they are moving toward more native development for iOS. https://9to5google.com/2021/10/10/google-ios-apps-native/

That doesn't mean they need to switch away from flutter. You can use it to have a single codebase that uses Material design on Android and Cupertino design on iOS.

Re: All you should know about Flutter development

#85

Post by ratg13 » Sat, Feb 12, 2022, 6:32 PM UTC

onli wrote: post #13

Some opinions about good choices here, over a year of app development: * Don't get confused by the myriads of state management solutions. Just use GetX, it's a sane solution that works as advertised. * There were a couple of storage plugins like hive that claimed to be better because they be native to the platform and not SQL. As with all platforms, that's bull. SQLite is available, so use that. * The routers are a c…

>Just use GetX

This is terrible advice. GetX is great for rapid prototyping but nothing more.

Once you reach a certain point you will need to re-code your entire app to get rid of this.

If you choose GetX, you are no longer building a flutter app, you are building a GetX app, and you will want GetX developers to work with the code and at some point it will becomes unsustainable and you will need to start over.

GetX is bottom of the barrel flutter development, and is only valuable for people who churn out large amounts of apps for customers that have no idea what they want.

Re: All you should know about Flutter development

#86

Post by pzo » Sat, Feb 12, 2022, 6:37 PM UTC

kkjjkgjjgg wrote: post #4

pepalgarid wrote: post #3

I feel that Flutter raised very high interest but it has fallen behind its expectations. Not that trendy anymore.

What is the current go to solution for cross platform apps?

There is no clear winner here yet. Every solution has pros and cons.

1) Need mostly cross platform desktop and using hardware extensively (bluetooth, camera, audio, nfc, sensors, etc.) -> Qt

2) Have web expertise or need easily to find well paid job and need mostly web, android, ios app -> React Native

3) Need only iOS, Android app that is mostly custom UI with some smooth animation mostly for some side project (not many jobs in the market comparing to React Native or iOS/Android Native) -> Flutter

Re: All you should know about Flutter development

#87

Post by mixmastamyk » Sat, Feb 12, 2022, 6:42 PM UTC

mikewhy wrote: post #45

slig wrote: post #17

Is there any Flutter-like alternative but using TypeScript? Dart feels too weird.

I still can't believe Google wanted Dart to replace JavaScript, and still you can't express an object's interface in it. https://github.com/dart-lang/language/issues/783

The thread has several alternatives. What problems are not solvable with dart’s class approach?

Re: All you should know about Flutter development

#88

Post by ratg13 » Sat, Feb 12, 2022, 6:48 PM UTC

sdflhasjd wrote: post #8

pepalgarid wrote: post #3

I feel that Flutter raised very high interest but it has fallen behind its expectations. Not that trendy anymore.

It's always been dart that put me off. For flutter apps supposedly compiling to native code, I don't like using a language that was apparently designed to live within the constraints as a web-based language. There are many other languages that I would rather use instead.

I am not a programmer by trade, but I do build apps occasionally.

Dart is a relatively simple language and you'll get the hang of it quite quickly.

The widget-tree framework of flutter makes it easy for you to just have small amounts of code that all chain together, and it becomes easier to find your mistakes and grow your platform.

I recommend going for it if you have an interest.

Re: All you should know about Flutter development

#89

Post by pzo » Sat, Feb 12, 2022, 6:59 PM UTC

isoos wrote: post #21

slig wrote: post #17

Is there any Flutter-like alternative but using TypeScript? Dart feels too weird.

Why is Dart weird for you? I've seen people getting to know Dart from various backgrounds (be it from Java, JavaScript, C# or Python), and so far everybody got productive in a short amount of time.

You can learn new language in short time but standard library and tools not that fast - especially if they dont exist. You will have to google e.g. how to parse Date etc. People enjoy big ecosystem of libraries and tools.

Just to give you example In many ways I prefer Ruby than Python as a language but Python is just swiss army knife and in many cases you are one PIP install away to finding library that solves your problem. Maybe Python doesn't have such a nice web framework as Ruby on Rails but ruby is not much used elsewhere.

I think people complaining about Dart as a chosen language not because of it's features but because

1) you have to learn and/or redevelop new SDK for it,

2) language doesn't have good interrop with any other languages (like Kotlin -> Java, Swift -> Objective-C, TypeScript -> JavaScript, Objective-C -> C++, Rust -> C, C++ -> C)

3) ecosystem is small

Re: All you should know about Flutter development

#90

Post by vanilla_nut » Sat, Feb 12, 2022, 7:03 PM UTC

samwillis wrote: post #68

sirius87 wrote: post #66

Earlier quoted context omitted.

For mobile, if you ask me, the only sane cross-platform strategy is what Kotlin Multiplatform Mobile [1] intends to do: portable business logic, and leave the UI aspects to each platform, keeping them native. Both Android and iOS have been making strides in simplifying DX for composing expressive UIs. It only makes sense to use those new Android Studio/XCode features as they come. [1] https://kotlinlang.org/lp/mobile…

While I agree where Kotlin is going with their multi platform tooling is great, I do think it’s just one more option in an already good bag of options. And a strong one at that. My one observation though is that for many (the majority?) of mobile apps the UI layer is the vast majority of the app, easily 70-80%. Especially for apps where the business logic is calling a http api, which most CRUD type apps are. For thes…

KMM shows promise for writing the same db/network logic for iOS, Android, Windows, and macOS. (less so on desktop, but it does work) Realized expectations give you a good way to extend that underlying layer a bit further. But you’re totally right — in the end, you still need to undetstand iOS and Android development, UI in particular, to make it work. It also doesn’t help that KMM is currently a buggy mess, Android Studio has a million issues with it, and the documentation is sparse to nonexistent for completely pedestrian use cases (good luck writing tests for anything). I hope it shapes up soon though.