I am not sure if users care about controls being "native". Examples from desktop: Photoshop used non-native controls, and nobody cared. MS Office always had non-native looking menus. DAW (digital audio workstation) apps all look non-native.
Flutter looks good, but is painful
81–90 of 191 posts
Re: Flutter looks good, but is painful
#82I simply love Flutter for Android and iOS development and have been using it since alpha. I haven't tried the web application part; I'm pretty sure I never will. Here's my opinion. I've created several apps with Flutter and every time I enjoy it. The UI is easy to make beautiful and the resulting code easy to read. It feels like all what the current Android SDK is missing. The current Android SDK is old and quite fra…
@tobiaswk - good job with your apps! I completely agree with Android and UI design which is painful. Flutter is far from perfect but a non designer can create something pretty decent. Users appreciate the experience.
Re: Flutter looks good, but is painful
#83I still don't see any big advantages over Xamarin Native, Qt or plain C++ with native views, when going through this route. All of the with the bonus that C#, JavaScript and C++ actually have lots of market demand, Dart remains a possible CoffeScript.
The biggest advantage is easy GUI creation, especially with animations and custom styling. Stuff that you can do with Flutter is basically impossible with native Android. You also don't have to deal with the insanity of Activities and Fragments.
Qt is pretty good, and QML has decent animation support but I think their mobile implementation is still very alpha, and since being acquired (again) they've kind of refocused on embedded devices like cars where they actually make money. Also it's not free. And QML is a bit less elegant than Flutter. It practically forces you to write spaghetti code.
I don't know how you'd use "C++ with native views" on Android, and I've only heard bad things about Xamarin Native.
Re: Flutter looks good, but is painful
#84While this has little relationship to the original article... We really should be trying to use the native GUI toolkit (or cross-platform native UI libraries like libui), not using Flutter-esque libraries that draws everything from scratch. Coherent UI is a very important point to users IMO. Users can assume that some special feature from App X will also work on App Y. For example, in macOS Cocoa, textboxes have univ…
The massive success of Electron apps shows that users don't really care about native controls. Even though electron is terrible in resource usage it enables unmatched development speed for teams. If libui or other libraries can give this experience then most teams won't hesitate using it!
I liken Electron to McDonalds. Gets the job done in a pinch but is awful in every single way. (edit: spelling)
Re: Flutter looks good, but is painful
#85While this has little relationship to the original article... We really should be trying to use the native GUI toolkit (or cross-platform native UI libraries like libui), not using Flutter-esque libraries that draws everything from scratch. Coherent UI is a very important point to users IMO. Users can assume that some special feature from App X will also work on App Y. For example, in macOS Cocoa, textboxes have univ…
Author here. Never expected it to reach here. 24k views and it's been ~14 hours since I wrote it. I agree with you. There is currently a competition between kotlin multiplatform and flutter, a shared backend vs a shared UI. Guess what, exactly what you said, it's a lot easier to share the backend than recreate the full UI like a game does. I'm not against flutter, but it feels too immature for now and the pains really show up. Apple showed up their new UI toolkit for developers, which does animations in the best way possible, Flutter team reaction was "you can make a library to improve it if you want" and "we should improve our docs" but no one will recognize there are issues in the framework that could be improved.
Re: Flutter looks good, but is painful
#86> it took them almost a year to add support for 64 bit in APK While the author's confusion is understandable, because most of the people posting in the linked Github issue have the same confusion, it's always been possible to build a 64-bit APK (and a 32-bit APK). The linked issue is actually about building a single "fat" APK with both 32-bit and 64-bit native libraries in it, which Google Play Store then repackages…
Author here, I'm sorry for the confusion. I'll correct the article with what you said.
Re: Flutter looks good, but is painful
#87While this has little relationship to the original article... We really should be trying to use the native GUI toolkit (or cross-platform native UI libraries like libui), not using Flutter-esque libraries that draws everything from scratch. Coherent UI is a very important point to users IMO. Users can assume that some special feature from App X will also work on App Y. For example, in macOS Cocoa, textboxes have univ…
>Adding Flutter or any other UI library that draws everything from scratch is a bad idea. Some would say re-writing the same app 5 times (Windows, macOS, Linux, iOS, Android) and maintaining 5 codebases is a bad idea.
> draws everything from scratch is a bad idea.
> re-writing the same app 5 times (Windows, macOS, Linux, iOS, Android) and maintaining 5 codebases is a bad idea.
So probably React Native's approach (the approach itself, not React Native) is a really good idea, where you can:
1. Sharing code if you don't like re-writing n times. 2. Not sharing code if you want to have different native stuff for different platforms. 3. Mix 1 and 2 at any percentage as you wish. Typically reuse all the business logic, and separate view components.
Re: Flutter looks good, but is painful
#88I still don't see any big advantages over Xamarin Native, Qt or plain C++ with native views, when going through this route. All of the with the bonus that C#, JavaScript and C++ actually have lots of market demand, Dart remains a possible CoffeScript.
Speaking strictly to the Xamarin here... as someone who has worked professionally w/ Xamarin, Xamarin.Forms, and Flutter: Flutter knocks it out of the park. My experience with Xamarin was so buggy as to be nearly unusable (on Stable no less!). The documentation, _especially in Xamarin.Forms_, was sooo lacking! I wanted so hard for it to be "the next great thing", but there were just too many gotchas and pain points. In contrast, Flutter "just works", has great documentation, great community, great tooling. My development in Flutter, especially with the hot reload they support, has sped up immensely. I can pause the debugger, change code on the fly, continue the debugger, no hiccups. It has been nothing short of wonderful. My anecdotal two cents.
Re: Flutter looks good, but is painful
#89Earlier quoted context omitted.
Sorry maybe the homepage is better to start on (I linked to the docs page): https://www.nativescript.org/ Here's a talk from 2 years ago: https://www.youtube.com/watch?v=ELemwZXJZVg I personally prefer Nativescript-Vue and I find their docs to be very good: https://nativescript-vue.org/en/docs/introduction Some more video resources: https://www.youtube.com/watch?v=DcCSq2Y9bow https://www.youtube.com/watch?v=qR1ESQTAL…
> NativeScript Installed the Playground app. When I try to open any of the examples from https://market.nativescript.org/?tab=samples&framework=all_f... , Safari says “Safari cannot open the page because the address is invalid”. For example, https://play.nativescript.org/?template=play-js&id=h9CNcL&v=... tries to open nsplay://boot?pKey=pub-c-a303d41e-5c6b-4030-8151-c056278a7944&sKey=sub-c-2d2f1312-4f78-11e7-ab90-02e…
This sounds like an excellent bug report for their playground feedback[0] repository, I'll make a ticket for you[1], please feel free to go in and fill out more information to help them help you.
[0]: https://github.com/NativeScript/playground-feedback/issues
[1]: https://github.com/NativeScript/playground-feedback/issues/1...
Re: Flutter looks good, but is painful
#90Earlier quoted context omitted.
I'm actually investigating getting some skills on react native, but i've got the suspicion it isn't all sunshine and rainbows. From what i've seen so far, a real-world stack has many more dependencies other that react native itself, and becomes a convoluted mess. However, i'm surprised that i haven't found a similar post to OP detailing real-world React Native pain points. Do you have more info ?
RN pain points are upgrading more than anything else. Also as a native dev I don’t understand why the JS dev ecosystem is full of disjointed tooling instead of just making the process more streamlined. I have also developed a production flutter app for a client and am now working on a RN app for another. I like RN so much more just because I can create custom native views that use the platform toolkits. You can also…
how is the view animation / vc transition story on RN ?
Say you’d like to implement a snapchat-like UX with RN, would that be possible without relying heavily on native custom components ?