Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment • Hacker News Board

Re: Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment

#121

Post by dep_b » Sat, Jan 04, 2020, 10:21 AM UTC

siquick wrote: post #30

braindongle wrote: post #28

Looking at Flutter vs React Native, the only comparison of interest for, perhaps most of us, Flutter for the win! Lower dev resources and way lower cpu usage. Dart is lovely, the docs are great, wide array of great UI widgets, and easy animation. As for hot reloading, well, you just have to experience the difference.

> Lower dev resources Learning a completely new language in Dart to even get started with Flutter doesn't seem like low dev resources. With React Native you are using: - Javascript which most devs have a grasp on in 2020 - JSX which really isn't much different to HTML - Styling is practically just CSS with slightly different property formatting and naming If you've decided to go down the RN then theres a decent chanc…

- A million packages that never really seem to be in sync

- A ton of different ways to do the same thing (Expo or not for example)

- Documentation is always outdated

- You still have to deal with the most annoying part of native apps, namely compilation and certification. If it was a book it would have the title: "Native apps: the shitty parts"

- Doing the same thing twice with this package management and build system (or ten times...) can yield a different result

- JavaScript is an awful language, TypeScript makes it more tolerable but you can't really escape the problems JavaScript has

Re: Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment

#122

Post by Abishek_Muthian » Sat, Jan 04, 2020, 10:29 AM UTC

tessting wrote: post #73

Abishek_Muthian wrote: post #60

I'm really interested in learning Flutter for future app development as I could really use the time saved in development. But, one thing which really concerns me is the volatility of Google w.r.t products which doesn't get enough adoption i.e. in other words 'I'm afraid Google will kill Flutter'.

I know this happened with Angular 1, but I am curious why I never hear this sentiment for GoLang which people seem nuts for. Is it because Google is responsible for maintaining the actual UI Widgets in this case?

I use GoLang regularly and so consider this my personal opinion for your question;

•GoLang filled up a need gap of simple yet high performant server side language which could scale up with the developments in the compute power.

•By the time GoLang stable release was made, it was widely used by Google itself within its production infrastructure. Docker, Kubernetes, Youtube using Go was a huge confidence booster.

•Of course it's been a decade since release, so it has stood the test of time even though there are criticisms regarding language design and Google's oversight on language development; even though major development comes from Google, I don't think there is a chance that they will pull it off just because they are heavily invested in it.

As for Flutter,

• It's been just two years, so we cannot compare it directly with current GoLang reg adoption and also this is a framework. I think Flutter didn't really fill any need gap Google had, it just seems like they waited to see if Cross-platform app development would still be a thing by the end of the decade and rushed in with a framework to compete with Xamarin/React Native.

• Google already has two first level language support for its android development Java, Kotlin but Flutter requires one to use Dart which wasn't originally created to be used in such a framework. So both android and iOS developers need to learn another language to build cross-platform apps using Flutter.

• Google claims it uses Flutter for some part of Google Assistant for Google Home devices and it is expected that Fuchsia uses Flutter as primary development framework; that's all in the future, if Google wants to inspire confidence they need to release a major app written using Flutter for android/iOS.

In short, I don't see Google loosing much in stopping development on Flutter as much as it stands to loose if stops development on GoLang and lately that's how Google has treated its projects. Of-course both are open-source, may be if Google stopped development on Flutter, the UI-widgets can still be developed by the community but I doubt whether the core-framework can be developed by just the community.

Re: Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment

#123

Post by fulafel » Sat, Jan 04, 2020, 10:38 AM UTC

braindongle wrote: post #28

Looking at Flutter vs React Native, the only comparison of interest for, perhaps most of us, Flutter for the win! Lower dev resources and way lower cpu usage. Dart is lovely, the docs are great, wide array of great UI widgets, and easy animation. As for hot reloading, well, you just have to experience the difference.

I think React Native had hot reloading before. At least the ClojureScript + React Native stuff did.

Re: Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment

#124

Post by verttii » Sat, Jan 04, 2020, 10:44 AM UTC

dickjocke wrote: post #48

jrs95 wrote: post #25

I've been considering trying out Flutter, but mainly due to my frustrations with React Native and I'm not entirely sure if others have had similar experiences or if Flutter would be any better. I have all kinds of issues with React Native tooling stability: code randomly reverts back to previous versions with hot reloading, things only partially update when I make changes, the same styles sometimes have inconsistent…

Please, please try Flutter. I had literally the same issues with React Native and gave Flutter a test run late last year. I will never go back. Flutter is so stable and honestly my frustrations with Flex made consider giving up on mobile development. I think as a backend dev i really struggle with the layout aspects of mobile dev and flutter makes it so easy for me. I'd say spend two nights playing with flutter. It t…

My experience is similar with yours. With React Native I had to fight just about everything on Android just to get everything working bearably. Hell, even some things like the profiler didn't work in Android when I was writing RN.

For now I'll stick to Flutter, it has simply awesome tooling. Everything just works. Dart, while not my favorite language, is also no more difficult than typescript to grasp, and they're inherently similar.

Re: Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment

#125

Post by amimetic » Sat, Jan 04, 2020, 10:59 AM UTC

crowbahr wrote: post #52

Benjammer wrote: post #42

This is super interesting, but the problem I have is that this guy's eye for design leaves a lot to be desired. When was the last time someone built a clunky table directly into the UI and added fully styled table rows dynamically? Why not modernize the design, and use a styled list view with a data adapter and try this again on each platform? It didn't surprise me at all that he struggled with the table in basically…

As an Android developer I looked at the code he wrote and felt bad for him. Of course it was painful trying to set all your styling up programmatically for the table! Use a viewholder pattern and a recyclerview/adapter then throw your data into the adapter. Make a simple xml file for your rows and inflate those into the viewholder then you're good to go! None of these clumsy declarative attempts to do what xml does w…

This is exactly the kind of thing that is unnecessarily hard in non-React-like UI frameworks. XML definitely does not do this well!

In React Native or Flutter I can just declaratively go from an array to rows of UI. It will be a few lines of code and will be incredibly clear (and easy to change).

In Android or iOS I can either do something procedural (which is messy, hard to reason about etc) or do something horrifyingly boilerplate-y (as you suggest), spreading things across multiple files and greatly increasing cognitive load.

I've worked with native Android, native iOS, React Native and (a tiny bit) with Flutter. I really wouldn't use vanilla native Android or iOS (even for a single platform app) unless there were some particular requirements around perf or whatever; so much more tedious, slower and (this one is subtle and will be missed by simple comparisons) so, so much harder to go back and make changes or additions to.

SwiftUI and Jetpack compose look promising for the future. But neither are ready for mainstream (enterprise?) use today.

Re: Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment

#126

Post by happa » Sat, Jan 04, 2020, 11:11 AM UTC

pjmlp wrote: post #111

braindongle wrote: post #28

Looking at Flutter vs React Native, the only comparison of interest for, perhaps most of us, Flutter for the win! Lower dev resources and way lower cpu usage. Dart is lovely, the docs are great, wide array of great UI widgets, and easy animation. As for hot reloading, well, you just have to experience the difference.

Hardly impressed with hot reloading, having done GUIs in Lisp, Smalltalk and Oberon. Plus the competition is stepping up, with Swift UI, Xamarin, Jetpack Compose hot reload support.

It's one thing to have hot reload and another to have it also preserve the whole app state like Dart/Flutter does.

Re: Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment

#127

Post by rhlsthrm » Sat, Jan 04, 2020, 11:12 AM UTC

latchkey wrote: post #53

OP mentions the Provider package [1] wasn't around when they did the Flutter version. That is really too bad, because it is absolutely the best way to manage state in Flutter. It makes things so much easier and cleaner than the other methods. [1] https://github.com/rrousselGit/provider Edit: I probably would have even gone back and refactored the app to use Provider before publishing the article. =) That would have b…

Looks like lots of things didn't exist then for each framework which made a lot of the issues he encountered easier: SwiftUI, React Hooks/useContext, Jetpack. I'd like to see a revisit of this whole project.

Re: Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment

#128

Post by dep_b » Sat, Jan 04, 2020, 11:17 AM UTC

It's a pity both Jetpack and SwiftUI / Combine weren't available / release worthy enough at the time of writing. Not sure about Android but a lot of the problems on the native iOS side would be fixed with that. The only difference is the cell reuse, which can be a real head scratcher indeed for a starting developer. It's definitely a part where you will find the performance vs ease of use decisions of early iOS. Got to say I often work around it by creating new ViewControllers and adding/replacing them every time a cell gets (re)used but this might not always work in places where performance is still a constraint.

Re: Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment

#129

Post by jpincheira » Sat, Jan 04, 2020, 11:21 AM UTC

jpincheira wrote: post #29

If you’re a small startup, just like we are doing at ours [1], you want to share as much code as possible between your web and mobile apps, and also backend, so sadly due to Dart, I don’t see us anywhere in the future using Flutter. [1] https://standups.io

Funny how this got many upvotes and then lots of downvotes through the hours.

I state again here: full stack Flutter is not ready for prime time. It needs more time to mature, and for small product startups I will not recommend it, not even if you’re starting from scratch.

Re: Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment

#130

Post by jpincheira » Sat, Jan 04, 2020, 11:25 AM UTC

hardwaresofton wrote: post #79

eerrt wrote: post #39

Was hoping to see a comparison with https://www.nativescript.org/

This needs to be higher up -- Nativescript is Flutter's biggest competition and IMO it's better than Flutter, because it doesn't require investing in Dart and switching to the Flutter "ecosystem" completely.

Exactly. Seems here that there’s tons of Dart fanboys in this thread forgetting that most people code to solve a business problem in the most efficient way.