Flutter looks good, but is painful • Hacker News Board

Re: Flutter looks good, but is painful

#111

Post by rhodysurf » Mon, Aug 05, 2019, 1:18 PM UTC

bsaul wrote: post #90

rhodysurf wrote: post #80

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 ?

Animation with RN is very good.

Snapchat like UI is definitely possible, but for the performance to be really good youd probably want to do something native. I consider that a good thing though. RN is better if you just treat it as the coordinator on top of native view components IMO.

Re: Flutter looks good, but is painful

#112

Post by dgellow » Mon, Aug 05, 2019, 1:21 PM UTC

jazoom wrote: post #26

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…

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

It depends what you mean by “re-writing the same app”. In general you can have the core features written in C++, thus available everywhere, then write a platform specific layer on top of this. That’s a quite common approach, and if done correctly (that’s not a trivial task though) allow you to target any platform without too much effort. But yes, you still have to maintain a bunch of stuff for each platform:

- implementation of the platform specific layer, supporting all the quirks of the target platform

- testing setup

- build system (some platforms have a lot of weird details to take in account)

The cost-benefit can be ok or terrible depending on the project. But for example for games, where you will draw your own UI anyway, that’s very common, and as far as I know that’s also what Microsoft is doing for their Office applications: common core in C++, then platform specific C#/Java/Objectice-C UIs.

Re: Flutter looks good, but is painful

#113

Post by iainmerrick » Mon, Aug 05, 2019, 1:21 PM UTC

pjmlp wrote: post #93

iainmerrick wrote: post #52

Earlier quoted context omitted.

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.

You’re right, of course! It’s amazing to think how many 8-bit and 16-bit games got ported to a whole bunch of different computers.

I was thinking mainly of the 90s and early 2000s, I guess, and for desktop apps where the main platform of interest was Windows, followed by a long tail of Mac, X-Windows, BeOS, etc... All those platforms could “easily” (i.e. with effort, but no rocket science required) be handled by a single C/C++ codebase with platform-specific #ifdefs.

I think the equivalent for today’s platforms would have to be Javascript. Unlike the C/C++ approach, you lose direct access to platform features.

Re: Flutter looks good, but is painful

#114

Post by dgellow » Mon, Aug 05, 2019, 1:24 PM UTC

Asooka wrote: post #46

jazoom wrote: post #26

Earlier quoted context omitted.

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

There is always Qt and wxWidgets. Compared to e.g. electron for cross platform UI they are super tiny.

Qt is a really good solution, but I personally always failed to build something that works with it. I find their documentation and tools really difficult to grasp.

Re: Flutter looks good, but is painful

#115

Post by IshKebab » Mon, Aug 05, 2019, 1:27 PM UTC

pjmlp wrote: post #92

IshKebab wrote: post #83

Earlier quoted context omitted.

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.

You're going to have to provide a link because "hamburger architecture" returns no relevant search results and I still don't know how you mean to make an Android GUI in C++. Unless you mean you write your core logic in C++ and your GUI with Java and link them via JNI?

That still means you have to write the GUI again for every platform, and you still have to use the Android API which is a very awkward system to make GUIs with (animation is extremely difficult, Activity and Fragment lifecycles are very complicated, etc).

Re: Flutter looks good, but is painful

#116

Post by V-2 » Mon, Aug 05, 2019, 1:28 PM UTC

thiht wrote: post #77

nnq wrote: 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"

Unfortunately the fact that TS is another layer on the top of JS makes the system more error-prone. This was one of the issues I encountered when fiddling with React Native. Too many moving elements in the stack would lead to frequent configuration problems, or the transpilation breaking debugging in weird ways, etc. And once things finally clicked in place, some component was updated, and the vicious circle would start again.

Re: Flutter looks good, but is painful

#117

Post by dgellow » Mon, Aug 05, 2019, 1:29 PM UTC

moksly wrote: post #66

aikinai wrote: post #60

Earlier quoted context omitted.

Electron is popular with developers, not users.

Then why are Discord and Visual Studio Code both so popular and well liked by their users?

Because they provide features their users care about. Not because of their choice of framework.

Re: Flutter looks good, but is painful

#118

Post by _-___________-_ » Mon, Aug 05, 2019, 1:39 PM UTC

iainmerrick wrote: post #105

_-___________-_ wrote: post #5

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

Maybe low priority / insufficient resources, or the issue didn't get triaged and brought to the attention of the right person to fix it quickly enough. The fix wasn't complicated at all once it was eventually in, so I don't think it was any deep issue with the framework.

Re: Flutter looks good, but is painful

#119

Post by stelonix » Mon, Aug 05, 2019, 1:45 PM UTC

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 agree with this 90%, but I'm not sure about the state of GUI apps after Windows 7. Up to Win7 though, most applications simply used native controls, sometimes wrapped by WPF or WFC.

I used to write for WINAPI/GDI and I used to loathe it; I mostly disliked the way messages were handled by default: huge switch statements. After switching to Linux and checking out the many "toolkits" I find myself craving for some GDI-esque toolkit. GDI was bad, outdated when I started writing it (circa 2009) but things "just worked", looks were consistent and controls would do the same across applications. The GNU/Linux counterpart is a mess: drag & drop sometimes works across toolkits, sometimes it does not; some toolkits are unwillingly to standarize with each other; the looks are all different, the functionalities too. Need an IME? Well here's one for KDE and another one for GTK. And if you use a different toolkit, chances are there's no IME for you. Right clicking on text-boxes and getting the same default options is great, so is being able to extend the same text-boxes systemwide. This is simple on Windows, but GNU/Linux requires one implementation per widget type per toolkit. It's all fragmented and no one cares. I miss GDI, I crave for a simple standard X11-wide widget system. Users do care about widgets working the same on different applications and they don't care about which toolkit is being used, specially non-tech savvy people. I believe those issues are more linked to the meme of "year of the desktop Linux" never arriving than anything else, really: UX should be consistent.

Well now I'll end my rant.

Re: Flutter looks good, but is painful

#120

Post by pjmlp » Mon, Aug 05, 2019, 2:01 PM UTC

vijaybritto wrote: post #103

pjmlp wrote: post #95

Earlier quoted context omitted.

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.

The Web means using the browser that I already have installed.