Live data from Hacker News

Flutter looks good, but is painful

medium.com

121–130 of 191 posts

Re: Flutter looks good, but is painful

#121
post #92

Earlier quoted context omitted.

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

I did provide the information for it, Dropbox and Microsoft talks at CppCon, easy with some Google fu.

CppCon 2014: Zaika Antoun "Microsoft w/ C++ to Deliver Office Across Different Platforms, Part I"

https://www.youtube.com/watch?v=3HROqnw-nf4

CppCon 2014: Zaika Antoun "Microsoft w/ C++ to Deliver Office Across Different Platforms, Part II"

https://www.youtube.com/watch?v=MGMoRu5yrVc

CppCon 2015: Jacob Potter & Andrew Twyman “Bridging Languages Cross-Platform..."

https://www.youtube.com/watch?v=K-k-axW2utc

CppCon 2017: Stephen Spann “Cross-Platform Apps with Dropbox’s Djinni...”

https://www.youtube.com/watch?v=ssqhz_1pPI4

CppCon 2014: T. Grue & S. Kabbes "A Deep Dive into 2 Cross-Platform Mobile Apps Written in C++"

https://www.youtube.com/watch?v=5AZMEm3rZ2Y

Naturally the native UI has to be used.

Are we talking about having a good user experience here, or having the easy lazy path for the developer?

Re: Flutter looks good, but is painful

#122
post #96
post #77

Earlier quoted context omitted.

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…

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

For what it is, I quite like Kotlin (particularly when placed against Java, of course), but I would not want to give up structural typing for much of anything in 2019. It makes writing obviously-correct code significantly easier.

Re: Flutter looks good, but is painful

#123
post #75

Earlier quoted context omitted.

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.

In such cases that same backend can send an XML (or JSON if you will) DSL payload that generates such UIs on the fly using the native widgets.

Pretty easy to create such framework in something like C++ or having a scripting language that drives the native UI widgets, something like JavaScript.

Re: Flutter looks good, but is painful

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

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…

> performance issues (thanks to infinite scrolling)

This problem is already solved by virtualized lists available in any decent framework. Why people don't use it is beyond me.

Re: Flutter looks good, but is painful

#125
post #93

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.

[deleted]

Re: Flutter looks good, but is painful

#126
post #26

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.

Not true.

I'm working with C++/Qt/QML/Javascript. No need to maintain 5 codebases.

Just a single codebase compiles to at least 9 platforms: Linux, Windows, macOS, iOS, Android, *BSD, Raspberry, QNX and WebAssembly.

Re: Flutter looks good, but is painful

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

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

The expectation level for UIs on mobile devices has been set very high. There is a lot of detail to get right in order to deliver the experience that people expect. That UI specific work is very time consuming.

It doesn't really matter what else is going on in your app, if that work can be done more efficiently to produce a more consistent result, then that's the decision you make.

Re: Flutter looks good, but is painful

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

Not true. I'm working with C++/Qt/QML/Javascript. No need to maintain 5 codebases. Just a single codebase compiles to at least 9 platforms: Linux, Windows, macOS, iOS, Android, *BSD, Raspberry, QNX and WebAssembly.

Right, but QT apps are QT apps -- they're not really native on any platform which is the same problem you run into with Flutter an Electron.

If you want an app that has platform semantics on every major platform then you need separate code bases. If you want an app that has the same semantics on every platform then you go with a cross-platform toolkit.

Re: Flutter looks good, but is painful

#129

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…

> We really should be trying to use the native GUI toolkit

Yes.

The problem with that is that it requiere experience * each toolkit and that is pain-full for many.

This cause a FORCED split (when multi-platform):

- You want easy to use and fast iteration. You NOT use native UI. Reach for mediocre options

- You want the BEST of the BEST of the BEST. You pick native UI. However sometimes that toolkit is nuts (Windows API, Android, Linux. Ok like all of them?) Or if lucky you know the other alternative (Windows -> Delphi, Android -> Kotlin, Linux -> ????)

----

This is not a fair fight. UI is too hard everywhere. C++ toolkits are nuts.

And it not need to be this way.

I think today we already have a good idea in how truly a good toolkit must be done: https://www.reddit.com/r/rust/comments/9bapwt/thoughts_on_wh...

- A lot can be actually cross-platform: Layouts, Units, colors, fonts calculation...

- Widget definition with a DSL (like SwiftUI) This allow:

- Real-time drawing of widgets AND easy drag-drop UI creation like Delphi or HyperCard (this is where HTML beat almost everything)

The above are candidates for cross-ui then you need:

- Rendered by each toolkit. With native controls

- Some way to communicate the backend to this front-end

I think this is alike a game engine:

1- You define the UI:

     
2- You have a driver that launch the UI:

    UI derived from BaseUI..

    //customize it for my project or create a new platform

    UI.register(UIButton...
    UI.register(UIWindow for "Window"
    //Attach listeners..
    UI.listen(...)
    //Run the UI
    UI.run(the UI directory)  
When using a "no namespaced" control like "Button" it work like Flutter: The engine chose whatever it want. When use a specific control "UIButton" it trust the launcher to handle it. Or fallback if to the generic.

---

To be clear:

This is almost the same as usual. Except it work like a interpreted language: It have a monolithic core but is possible to code a specific version per platform (if desired). The critical component is the ability to register to the engine (very easily!) new widgets, listeners, behaviors. etc.

Re: Flutter looks good, but is painful

#130
> Why should someone ever need to offer a bug-fix bounty!?

Author expects bugs in open source projects to get fixed for free, by someone else.

We need to support open source maintainers instead of shaming them. I'm excited about Open Collective and made a monthly donation to a project I use.

Post reply on HN