Live data from Hacker News

Flutter looks good, but is painful

medium.com

101–110 of 191 posts

Re: Flutter looks good, but is painful

#101

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…

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

BMW seems happy with flutter and are opensourcing some of their flutter libs.

Quote from CTO Connected Company at BMW

“By combining Dart and Flutter we have the first true cross-platform mobile toolkit; we feel it is a game changer to ensure feature parity for digital touchpoints and IoT. By moving forward with world class tooling, automation and modern functional programming patterns we can improve feature cycle time, security, and cost of delivery of features for the business.”

https://www.youtube.com/watch?v=80pRyn7fZRk&feature=youtu.be...

Re: Flutter looks good, but is painful

#102

Earlier quoted context omitted.

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

Good idea, thanks.

Please note that the links in the issue you submitted need to be changed because you copied the link text, which are only partial, rather than copying the link target URLs.

Re: Flutter looks good, but is painful

#103
post #95

Earlier quoted context omitted.

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.

Success as in being the UI for a multi billion dollar company like Slack. It's undeniably terrible but what other options do we have? I don't think any tech is gonna withhold against the web! I'm actually willing to switch to any platform that can offer amazing development experience at the same time being super performant.

Re: Flutter looks good, but is painful

#104

Earlier quoted context omitted.

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)

Exactly!

Re: Flutter looks good, but is painful

#105

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

What was the holdup, though? This should have been almost a trivial feature to implement (just make an APK with multiple .so files in separate directories).

It must have been either low priority (except the Play Store has been strongly encouraging fat binaries for some time now) or there were additional complications (which makes me more suspicious about the stability of the framework).

Re: Flutter looks good, but is painful

#106

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…

You yourself said > Stories like these are mostly only macOS; since Windows apps usually just re-invent all kinds of UI elements, while Linux's GUI toolkits are super-fragmented. (GTK vs Qt is one thing, and there are lots of other options!) and on next line you say > Adding Flutter or any other UI library that draws everything from scratch is a bad idea. The first thing you said is the reason why we need something l…

> Flutter at least gives the hope that we will see consistent UIs across multiple platforms while maintaining same code base

well, no, it just adds another standard. QtQuick already allows the exact same thing that Flutter (one UI, shared across all platforms both in terms of code and looks). (QtWidgets instead is more geared towards applications that fit in the host platform's guidelines).

Re: Flutter looks good, but is painful

#107
post #3

Flutter is young, and there are bugs, but velocity is high and it is advancing the state of the art. It is a huge leap in accessibility and productivity. I really don't understand the complaint about setup. If expanding an archive and setting an environment variable are that daunting, wait til you try mobile development... Snark aside, remember phonegap/cordova? Pine for those glory days of low friction?

> it is advancing the state of the art

in what ways?

Re: Flutter looks good, but is painful

#108
post #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.

I wouldn’t necessarily write this off. Doing UI-related work directly in the main thread has a lot of benefits -- your click listeners can take effect immediately and make all the necessary UI updates before the next event is processed. With event handling in a separate thread, it can be harder to make things robust (filtering out double taps, preventing flashes of unfinished/unstyled content, etc).

Of course you do need to make sure that everything that could be even slightly expensive is shipped out to a background thread. JS is weak in that respect.

Moving everything to a background thread does fix that problem, but I think it’s overkill. A lot of mobile apps would be faster and more responsive if they used the main thread more. You just have to use it right.

Re: Flutter looks good, but is painful

#109

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…

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

If you’re talking about macOS, then I agree with you, that’s something I cared about when I was using Apple’s OS. Recently I moved to Windows for my personal machine, on this system you really don’t have coherence between applications, even between things developed by the same company or for applications tightly coupled with the OS! It’s just a big mess where each interface has its own set of rules incompatible with others. I would understand if people more familiar with Windows don’t care at all about the overall coherence given how random things seems to be.

Re: Flutter looks good, but is painful

#110
Flutter is not that bad. It is a step in the right direction but there are some paradigms that makes simple things hard. Animations are harder than necessary and building non default layouts requires a bit of thinking to get right.

My biggest issue is that there is still this "uncanny valley" feeling when using a flutter app. It feels much better than a react native or Cordova app, but something still feels off.

Right now it seems great for prototyping. For iOS however, I've been playing around a bit with SwiftUI which currently (even in its beta state) provides an astronomically better dev experience and user experience.

Post reply on HN