Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flutter looks good, but is painful

medium.com

Post reply on HN
Print view View original

71–80 of 191 posts

Re: Flutter looks good, but is painful

#71

Post by bsaul »

gitgud wrote: post #21
GeneralTspoon wrote: post #11

Earlier quoted context omitted.

React Native isn't a web wrapper. It uses a Javascript engine to render native iOS/Android components (unlike Flutter, which doesn't use native components, and instead renders everything from scratch).

Because Flutter has it's own rendering engine, it's inherently more consistent in refresh rates and UI components. Although React Native shows Native elements, they vary slightly across different; devices, platforms, OS's etc.. this can create many weird edge cases, which makes it unreliable in some cases.

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 ?

Re: Flutter looks good, but is painful

#72

Post by alex_suzuki »

krzat wrote: post #48
pcr910303 wrote: post #29

Earlier quoted context omitted.

> Some would say re-writing the same app 5 times (Windows, macOS, Linux, iOS, Android) and maintaining 5 codebases is a bad idea. Yeah, that's true. I'm looking forwards to React Native (AFAIK it uses the native JS engine + native toolkits) and libui. I'm also hoping for declarative UI frameworks like SwiftUI so that the underlying framework/runtime can generate the appropriate UI for the exact target platform.

> underlying framework/runtime can generate the appropriate UI for the exact target platform This may seem like a good idea, but it's not. What you will get is a leaky, lowest common denominator API that will break on each new OS version.

Well put.

Re: Flutter looks good, but is painful

#73

Post by vbsteven »

nicoburns wrote: post #57
pcr910303 wrote: post #17

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…

I'm hoping a cross-platform UI takes over the world. Then it will be the "native" UI's that seem inconsistent.

In a sense that already happened with the web stack. In tech like Electron developers write most of their app once and use a “shell” like Electron to interact with the host OS.

Unfortunately the web stack is very bloated with years of legacy and this requires these shell projects to embed a full browser engine making these apps bloated as well.

Flutter is an approach at making a new shell that provides rendering and host OS interaction without all the web bloat.

Re: Flutter looks good, but is painful

#74

Post by thiht »

aikinai wrote: post #60
IshKebab wrote: post #36

Earlier quoted context omitted.

I think the popularity of Electron has shown that is actually isn't very important to users to use native controls. Also on Desktop, macOS is the only one that even has a single official "native" toolkit.

Electron is popular with developers, not users.

Any data backing that up? Don't forget HN users are a bubble. I'm actually pretty sure standard users don't even notice a difference between Electron and native apps. I for one sometimes prefer Electron apps over badly designed and ugly native apps.

Re: Flutter looks good, but is painful

#75

Post by pjmlp »

nicoburns wrote: post #58
pjmlp wrote: post #42

Earlier quoted context omitted.

Only when one doesn't use a solution like having the common logic in a portable language like C++, with bindings to native UI elements. A solution used by plenty of commercial desktop software as we moved from Assembly as main application language for desktop apps during the 16 bit days.

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

An UI without logic is an useless app.

Re: Flutter looks good, but is painful

#77

Post by thiht »

nnq wrote: post #63
lovelearning wrote: post #23

I have a couple of android app PoCs in mind but didn't want to go down the Android SDK way which IMO is becoming more and more complicated and verbose with every release. Just tried Flutter and React-Native yesterday for the first time, and I'm sorry to say both were sorely disappointing. Flutter was easier to install and get working, but Dart seems to be as verbose as Java with some JavaScript style syntax mixed in.…

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"

Re: Flutter looks good, but is painful

#78

Post by Kipters »

Const-me wrote: post #67
pcr910303 wrote: post #32

Earlier quoted context omitted.

> Before Win8, most apps used native controls on Windows. Yeah, it's true but the problem is that the native controls were very limited. There was no central notification system so every Windows messaging app reinvented notifications(unlike macOS which converged to Growl and later, the Notification Center), no standard Ribbon Menu widget (at least when it was first introduced, I'm not sure about the current status) s…

> There was no central notification system… no standard Ribbon Menu widget True, but if MS wanted to, they could have added both to the old ecosystem, without jumping ship. They had mayor parts of notification system already, Shell_NotifyIcon API from Shell32.dll. They were adding more features to NOTIFYICONDATA structure with every OS version. They did release ribbon widget; it just took them a few years. Introduced…

Additional tidbits about Shell_NotifyIcon: it still works now, it gets automatically mapped to a UWP toast notification

Re: Flutter looks good, but is painful

#79

Post by Const-me »

zerr wrote: post #69
Const-me wrote: post #67

Earlier quoted context omitted.

> There was no central notification system… no standard Ribbon Menu widget True, but if MS wanted to, they could have added both to the old ecosystem, without jumping ship. They had mayor parts of notification system already, Shell_NotifyIcon API from Shell32.dll. They were adding more features to NOTIFYICONDATA structure with every OS version. They did release ribbon widget; it just took them a few years. Introduced…

They (VS team) licensed the ribbon control from the 3rd party company. The Office team didn't share the original one with them :)

I don’t work for MS but I think the reason why they did not, it was hard to do, not because they didn’t want to share.

That’s quite complex UI and UX in that control. Very likely, the office implementation is coupled too tight with the rest of the office code, i.e. very hard to refactor into a reusable control. The office is cross-platform, their implementation of ribbon has to be designed to work on OSX too, contributing to the complexity.

Re: Flutter looks good, but is painful

#80

Post by rhodysurf »

bsaul wrote: post #71
gitgud wrote: post #21

Earlier quoted context omitted.

Because Flutter has it's own rendering engine, it's inherently more consistent in refresh rates and UI components. Although React Native shows Native elements, they vary slightly across different; devices, platforms, OS's etc.. this can create many weird edge cases, which makes it unreliable in some cases.

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 share a lot of code with an SPA web app and set up a monorepo for everything pretty easily.

Flutter dev tools are incredible though and much easier to use than react native.

Post reply on HN