Live data from Hacker News

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

blog.codemagic.io

151–160 of 186 posts

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

#151

This whole commentary will change in about 6 months when Jetpack Compose goes live. Compose is basically android-native SwiftUi equivalent - a reacty way to write apps. Officially sanctioned and tuned by the core Android team

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)

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

#152
post #94

Earlier quoted context omitted.

How is it different from being the angular / vue.js edition of react native? Does it implement its own render & view layer in c++ like flutter does?

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.

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

#153

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?

The sad but true reason is because people aren't generally making rational decisions on here. They'll claim a reason, but it's usually really based on pre-conceived notions. "Google kills projects so I won't use Flutter, but will definitely go all in on GoLang" is a great example of this.

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

#154

Earlier quoted context omitted.

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

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.

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

#155

Earlier quoted context omitted.

Dart on the web frontend too, since start of the project. If you already had a substantial part of the project in JS, then Typescript would prob be better choice. Dart is pretty mature at this point, with a very solid type system and getting better with extension methods just added and NNBD coming soon. It doesn't have as many packages, but it's pretty good. > native macOS app — not sure also if Flutter will work for…

To me "not enough packages" out there means it's an instant competitive disadvantage to do production-ready apps, at least for Web — which at for us at Standups is a critical platform, especially given we're B2B. Hopefully, it catches up soon though, as I do think Flutter is better than React Native in most fronts.

Tough call though, since # of packages is a poor metric.

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

#156
post #68

Earlier quoted context omitted.

Flutter isn’t going to get shelved. It is the UI framework for Fuchsia. I agree Dart is its biggest problem but Fuchsia prides itself on not having a single system language so I’m sure you’ll be able to target the flutter framework from kotlin and swift and rust and go soon. Also Dart isn’t hard.

Flutter is just a cheap Google copy of React just like now shelved Google Plus was a cheap Google copy of LinkedIn/Facebook. It can and will be discontinued.

It’s not cheap at all. It does things the right way. It’s the closest thing UI engineers have to a “write once”, deploy everywhere framework. Try it out if you haven’t. It’s definitely not cheap.

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

#158
post #128

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…

I love SwiftUI, rewrote my side project in it and hope it takes off. That being said I don't think it's anywhere near ready for mainstream use and therefore wouldn't be particuly helpful in a comparison like this. The requirement of iOS13 alone means it's a non-starter for a lot of business cases.

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

#159

That's some admirable persistence by the author... I gave up on Flutter (for now) right after installing, having to accept (and supposedly read first) about 10 licenses during the process and then failing to start basically the default app in the Android emulator with obscure error messages. What a terrible UX developers have to put up with these days... At least it was funny to let Android Studio analyze the code (t…

I had some similar initial issues getting it working (also suffered from the comedy issues with not being able to run Android Studio on modern JDK/JRE versions due to JavaFX stuff being removed).

After I'd faffed about and made it all work I must say that Flutter itself felt very nice. The hot-reload alone is enough to make you massively more productive. Dart is a perfectly reasonable language too, much nicer and better thought out than JavaScript, even with Typescript on top. Integers that are, for a start...

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

#160
post #158
post #128

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…

I love SwiftUI, rewrote my side project in it and hope it takes off. That being said I don't think it's anywhere near ready for mainstream use and therefore wouldn't be particuly helpful in a comparison like this. The requirement of iOS13 alone means it's a non-starter for a lot of business cases.

Well if iOS 13 adoption keeps growing like this I think any project released mid 2020 could use it - unless every % of missed users really means a lot of missed income.
Post reply on HN