Live data from Hacker News

Flutter looks good, but is painful

medium.com

91–100 of 191 posts

Re: Flutter looks good, but is painful

#91
post #45

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

Hence why explicitly left Forms out.

For me having to deal with Dart, a programming language without any other purpose than Flutter, it rules out any advantage over Xamarin.

With Xamarin I have C# and the whole .NET ecosystem available.

Re: Flutter looks good, but is painful

#92
post #45

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

The same way that Dropbox, Microsoft and plenty of other companies do.

You use a JNI generator and follow the so called hamburger architecture.

Microsoft and Dropbox have several sessions done at CppCon.

Re: Flutter looks good, but is painful

#93

Earlier quoted context omitted.

IMO it really depends. There's a lot of big companies that have more than enough resources to be able to pay multiple dev teams to build and maintain apps across operating systems. From a few years ago, Twitter and Facebook were famous examples. They pushed so hard to try and build their apps using web technology but kept running into performance issues (thanks to infinite scrolling). After spending fuck knows how mu…

people overestimate how complex it is to build multiple native apps in parallel. I agree, although there are now more platforms to deal with than back in the days when it was just Mac and Windows: add iOS, Android, desktop web, mobile web. I think it also helps when it's easy to share code between platforms, which again, used to be easier when you were just targeting the desktop (just use C or C++). Now it's a bit ha…

I remember the days of Apple II, TSR-80, Commodore 64, Commodore 128, ZX Spectrum, ZX Spectrum 128K, ZX Spectrum 128K +2A, ZX Spectrum 128K +3A, Atari, Atari ST, Amiga 500, Amiga 600, Amiga 1200, PC CGA, PC EGA, PC VGA, PC PS2,.....

Platform fragmentation exists since ever.

Re: Flutter looks good, but is painful

#95

While 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!

What success?

It helps when sometimes there isn't any options to start with.

I use Slack as job requirement, outside work I keep my PC Electron free.

Same applies to VSCode, only because of TypeScript and Rust, otherwise it wouldn't be on my computer.

Re: Flutter looks good, but is painful

#96
post #77
post #63

Earlier quoted context omitted.

Yep, React Native has horrible dev experience... this is what drove me to Flutter. Dart may be ugly but after you get used to it it's mostly "Typescript done right" imo ;)

I'm pretty sure Typescript is already "Typescript done right"

...ok, tbh TS has a much more powerful and expressive typesystem then Dart, otoh it also works with the constraint of being a superset of JS hence some things are forced to be the way they are since they sit on the foundation they sit.

I don't really like Javascript as a foundation so I'd almost be inclined to throw away a superior type system in order to have the bedrock be something else, opinions might vary though, I know.

And probably we'd all have loved to have Kotlin instead...

Re: Flutter looks good, but is painful

#97
post #75

Earlier quoted context omitted.

A lot of mobile apps are almost entirely UI...

An UI without logic is an useless app.

Often you can offload the business logic to the backend. That way you don’t have to implement it multiple times for each platform and you can change it “immediately” even if users don’t update their apps.

Re: Flutter looks good, but is painful

#98

For those who are looking for an alternative to Flutter/React Native, please check out Nativescript @ https://docs.nativescript.org ! It's different in a few key ways: - Draws native components (Flutter draws every pixel) - Pure JS native (i.e. JNI powered) shim layer (you can write stuff like `const intent = new Intent()`) - Typescript as first-class (not quite so with React Native, and IMO Typescript > Dart as far…

They are running JS code on Main thread. Thank's but no.

Re: Flutter looks good, but is painful

#99
Tip: For anyone trying out Flutter, please remember to evaluate it based on release builds of your app. Scrolling and animations can feel a bit "off" when running the default debug builds. The 60 FPS butter is only really applied when that `--release` flag gets tacked on.

Not using Android Studio, so not sure how easy it is to miss the massive performance difference of optimized vs. debug builds in that workflow.

Re: Flutter looks good, but is painful

#100
post #90

Earlier quoted context omitted.

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 ?

Yes
Post reply on HN