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

#161

Post by on_and_off » Sat, Jan 04, 2020, 7:18 PM 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…

I only understood why this code is so poor when I understood what the author has been doing : trying to write flutter code on Android.

If anything, they would have had a way easier time using Compose, since its principles are reminiscent of the ones of flutter.

Or if they had just read a beginner guide or two :/

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

#162

Post by on_and_off » Sat, Jan 04, 2020, 7:24 PM UTC

arciini wrote: post #4

I think building a toy app for yourself is among the best ways to decide for yourself which framework to go with! The conclusions from the article were: > Creating the Flutter application only took approximately ⅓ of the time it took to create both native applications combined. This proves how much time you save by using cross-platform frameworks. Their Hot Reload functionality also sped up the development cycle a lo…

>his proves how much time you save by using cross-platform frameworks

not sure it proves much since the author went about this in a really really weird way.

From the snippets shown, this is extremely unidiomatic Android code, it looks a lot more Flutter code. which makes sense since the author seems like they were trying to write Flutter code on another platform.

And even if they went about it in a more productive way, I am not sure what the feedback of one beginner dev having spend 20 hours on each platform is supposed to mean about anything.

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

#163

Post by on_and_off » Sat, Jan 04, 2020, 7:26 PM UTC

bsaul wrote: post #144

CraftThatBlock wrote: post #35

Earlier quoted context omitted.

Flutter uses the Chrome rendering engine (Skia) and scrolling is fully fluid (in release mode). React native uses native views (if implemented correctly) and is usually very fluid too

I tried a flutter app i found from the sample app catalog on the iOS store on an iphone X and the scroll wasn't really good (although the views were very basic). Can you point me at an iOS app made with flutter that implements this correctly on the store ? EDIT : it's the "veggie season" app and i've tried it again on my iphone 6. it's almost unusable. The scroll stops completley sometimes and other times it just scr…

I had the same experience.

Flutter devs like to throw some wild claims like "120 fps on mobile" even though no Android phone screen support 120 frames per second at the hardware level and that all the flutter apps I have seen stutter a lot in their animations.

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

#164

Post by Benjammer » Sat, Jan 04, 2020, 9:03 PM UTC

amimetic wrote: post #154

crowbahr wrote: post #150

Earlier quoted context omitted.

I mean if you want 3 identical rows to just statically be at the bottom of a view you can always define the row in XML then put it in a vertical LinearLayout at the bottom using the tag. You maintain modularity without cumbersome code to deal with. This has the added benefit of being able to see the views without having to compile your code.

Please try out one of Flutter or React Native. I think you’ll be surprised how much nicer they are for anything like this. The code is certainly not cumbersome when compared to the equivalent XML. Also, in Flutter and React Native you don’t (typically) have to wait for your code to compile as they do hot reload.

You, and everyone else who makes this argument seems to blatantly dismiss the tooling around Android, specifically Android Studio and the layout preview panel. The person you are responding to is talking about editing UI layouts in XML, using the preview panel, without building the project at all.

Everyone loves to talk about "hot reloading" and obsess over reducing build times incrementally as if that's the only way to develop anything faster. No matter how fast your "hot reload" is, it'll never beat the layout preview panel in Android Studio, which is directly rendering your xml in real time, without compiling or building anything.

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

#165

Post by cgs » Sun, Jan 05, 2020, 1:27 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…

I was glad I found Provider after almost diving into BLoC. The less boilerplate and context switching the better.

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

#166

Post by hamaluik » Sun, Jan 05, 2020, 1:45 AM UTC

lazyjones wrote: post #86

hamaluik wrote: post #82

Earlier quoted context omitted.

That’s weird.. aside from accepting licenses (which to me is fine), Flutter has always been a buttery smooth development process for me—much more so that trying to wrangle Xcode or Android Studio.

So, you use Flutter from some other IDE and avoid Android Studio altogether? I'll probably try that next, I just did what flutter.io suggested and didn't have any other suitable IDE or editor set up for Dart etc.: Flutter relies on a full installation of Android Studio to supply its Android platform dependencies. However, you can write your Flutter apps in a number of editors; a later step will discuss that. Is the g…

I use visual studio code, it’s the editor I’m most comfortable with these days. I have android studio installed but don’t really use it except when publishing.

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

#167

Post by hardwaresofton » Sun, Jan 05, 2020, 2:03 AM UTC

novok wrote: post #152

hardwaresofton wrote: post #103

Earlier quoted context omitted.

No but it introduces a complete shim of the native platform underneath -- as in your can write and execute JS that moves native code underneath. React Native doesn't support this currently (and has no plans to). There's also the possibility of using vastly lighter weight frameworks, for example svelte-native[0] which should be quite a bit more responsive. [0]: https://svelte-native.technology/

So it will have the same issues as react native and xamarin will have. What is interesting about flutter is how it doesn't wrap native ui elements, so you don't have to become an expert in all target platforms plus your wrapper platform to fix tricky bugs. Also I think it's not responsive compared to native because it's javascript and a wrapper, not the specific javascript libraries you are using in between.

> So it will have the same issues as react native and xamarin will have. What is interesting about flutter is how it doesn't wrap native ui elements, so you don't have to become an expert in all target platforms plus your wrapper platform to fix tricky bugs.

This is definitely one of the best parts of Flutter -- the fact that they've done the tremendous work of making a framework that draws every pixel to the screen is amazing, but that's also a liability. Android/iOS has an ecosystem of things that you can

One thing I ran into during flutter development was that the SQLite library[0] did not support off-device use -- I couldn't even run tests locally without putting them on the device. Maybe that's changed in recent memory, but that really turned me off to it.

There's also the difficulty of acclimating to the BloC paradigm[1][2]. If you hear it explained it seems simple, and then you try to write some code with it and confusion ensues -- it's like flux mixed with FRP-style stream programming and that's the official answer from the Flutter team. Everyone is confused by it and it isn't the easiest thing you could do but the other answers aren't that great either.

> Also I think it's not responsive compared to native because it's javascript and a wrapper, not the specific javascript libraries you are using in between.

So that's the thing -- if you really need native performance (you don't, most of the time, especially most apps are almost web pages). You can write and integrate completely native views with Nativescript, and in fact you can build them with JS because Nativescript has shimmed the entirety of the native APIs -- you can write code like `const intent = new Intent(...);` in JS and get an android-native Intent object. Of course, you can also call native APIs easily when you need the power.

[0]: https://pub.dev/packages/sqflite

[1]: https://stackoverflow.com/questions/54114144/bloc-flutter-an...

[2]: https://medium.com/flutterpub/architecting-your-flutter-proj...

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

#168

Post by siquick » Sun, Jan 05, 2020, 6:21 AM UTC

je42 wrote: post #137

siquick wrote: post #30

Earlier quoted context omitted.

> 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…

I was part of a team who had to do two upgrades of the react native version. and every time, it was a pain taking weeks of developer productivity away. ... i wonder if React Native fixed this problem... but their track record is not the best...

The 0.6 release brought in autolinking and a better integration with Cocoapods so worth checking out.

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

#169

Post by hrkristian » Sun, Jan 05, 2020, 9:05 AM UTC

amimetic wrote: post #154

crowbahr wrote: post #150

Earlier quoted context omitted.

I mean if you want 3 identical rows to just statically be at the bottom of a view you can always define the row in XML then put it in a vertical LinearLayout at the bottom using the tag. You maintain modularity without cumbersome code to deal with. This has the added benefit of being able to see the views without having to compile your code.

Please try out one of Flutter or React Native. I think you’ll be surprised how much nicer they are for anything like this. The code is certainly not cumbersome when compared to the equivalent XML. Also, in Flutter and React Native you don’t (typically) have to wait for your code to compile as they do hot reload.

Android Native also has hot reload, what on earth are you on about?

You get both with Android Native, layout preview and hot reloading.

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

#170

Post by socceroos » Sun, Jan 05, 2020, 9:15 AM UTC

sandGorgon wrote: post #151

yuvalr1 wrote: post #136

Earlier quoted context omitted.

Flutter is also cross platform, a big advantage. No matter how well the Jetpack Compose experience is going to be, it's still only Android.

Nope. That boat has already sailed. And kotlin will most likely supersede Flutter because of the tooling. https://www.jetbrains.com/lp/mobilecrossplatform/ (That links points to Yandex , etc who are using it in production)

That's only business logic, you still have to entirely reimplement the UI layer for each platform. Cross platform business logic isn't the killer feature that cross platform Devs are looking for.