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

171–180 of 191 posts

Re: Flutter looks good, but is painful

#171

Post by WorldMaker »

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

Earlier quoted context omitted.

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

Given just what was visible to Office Extension Developers ("RIBBON XML", the giant pile of C++ MACROS, etc), the original Office Ribbon control was probably quite a complex beast.

On the other side: the new "Simplified Ribbon Control" that is in now in OneNote (the real one, not 2016) and Outlook (and eventually the rest of Office) is supposed to be the exact same code as the UWP/Fluent Ribbon that is eventually going to be open sourced into the WinUI library.

Re: Flutter looks good, but is painful

#172

Post by chrismorgan »

vijaybritto wrote: post #41
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…

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!

Depends a little on what you mean by “native controls”. The web platform doesn’t provide all of the controls the underlying OS provides (e.g. a list view), but it does provide some of the most important and common ones. A text box, for example, has the native look-and-feel by default—and feel is the most important part of that, for things like caret behaviour, keyboard shortcuts and touch behaviour; and you can customise its look easily. It’s not the native implementation, but what the browser implements matches the native implementation.

Re: Flutter looks good, but is painful

#173

Post by paulddraper »

obliviousonions wrote: post #140
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.

UWP is actually pretty easy to use and looks great & native on Windows.

Yes Windows framework #935 has actually turned out to be pretty good.

Re: Flutter looks good, but is painful

#174

Post by dragonwriter »

dgellow wrote: post #117
moksly wrote: post #66

Earlier quoted context omitted.

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.

Proving that features are important, native controls...not so much.

Re: Flutter looks good, but is painful

#175

Post by hardwaresofton »

ex3ndr wrote: post #98
hardwaresofton wrote: post #24

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.

Nativescript has supported the web worker paradigm for multi-threading for a while now[0]. Also, I'd like to point that for a lot of applications (especially the ones that are basically informational without much interaction or client-side work, this actually isn't an issue early in the development process.

I've used Nativescript on client projects, and it is fantastic for prototyping, with well demarcated paths to performance optimization. Since you can easily use native screens/controllers/etc with it, at the very least you can use it for fast prototyping then drop all your custom code in.

Do you know of any hybrid frameworks that are not running JS code on the main thread by default? And by JS code I assume you mean display-related code, because Flutter suffers from this same issue, do too much hard work on the main thread and it stalls (as anything would). Even on android itself[1] you need to do some extra work to make sure your UI-related heavy lifting happens off the main thread:

> However, when the main thread’s messaging queue contains tasks that are either too numerous or too long for the main thread to complete the update fast enough, the app should move this work to a worker thread

[0]: https://docs.nativescript.org/core-concepts/multithreading-m...

[1]: https://developer.android.com/topic/performance/threads

Re: Flutter looks good, but is painful

#176

Post by hardwaresofton »

codetrotter wrote: post #102
hardwaresofton wrote: post #89

Earlier quoted context omitted.

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.

Thanks for pointing that out, just fixed it in the issue (thanks also for letting them know how to reach you if they have questions).

Re: Flutter looks good, but is painful

#177

Post by jillesvangurp »

krzat wrote: post #137
piokoch wrote: post #131

The question is: if Flutter will not get traction that Google expects, what will happen with the project? The space of multi-platform mobile apps toolkit is already occupied by several well established players (React Native, Qt, Xamarin and a dozen of other more or less popular tools, sometimes well entrenched in their niches, like Unity for games). Flutter comes with rather obscure language and is late in the game,…

The strength of Flutter is it's architecture. Nothing comes close. Web is too slow. Xamarin/React Native is too restricted by native layer. Qt is C++. Popularity of Flutter increases steadily: https://trends.google.pl/trends/explore?cat=31&date=today%20...

IMHO the architecture is actually it's weakness. I know a lot of Android developers who don't want to go near it because they have to give up a lot (language, nice frameworks, etc.). Marying Flutter to Dart in an age where everything has been trending towards LLVM based compiler tool chains on native for well over a decade seems misguided.

Yet Flutter fills an important gap in the market: pure native experiences are slowly dying because native look and feel is increasingly meaningless now that so many apps use non native UI kits. Also, supporting multiple UI teams developing for different platforms is a huge risk for small companies and a lot of hassle even for those teams that can afford it. We need more cross platform stuff but I don't believe Flutter is the solution here because of its architecture, which is a combination of "our way or the highway" and vendor lock in. I'd say there is a big risk of Apple doing something smart with Swift on Android and web. I actually know of a few Android developers using Swift on Android already. This is becoming a thing. Like Kotlin, Swift is perfectly positioned to start targeting cross platform via LLVM. Also WASM is becoming a thing. IMHO, Google needs to make U turn here and rip out whatever it is that prevents Flutter from being driven from Kotlin (jvm and native) and other llvm languages.

All that's missing is a proper cross platform UI toolkit that actually works properly in that ecosystem. Things like QT and GTK are obviously usable in that space but a bit clunky/ugly on mobile.

Re: Flutter looks good, but is painful

#178

Post by amw-zero »

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.

I do get that, but one is bad for developers and the other is bad for users. It’s up to you to decide which is more important for your project. Most projects I’ve worked on, the user experience was more important to the business, in which case native apps are better.

Re: Flutter looks good, but is painful

#179

Post by amw-zero »

iaml wrote: post #124
Cthulhu_ wrote: post #47

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…

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

It’s not built into any frontend web framework by default that I know of. It’s the default approach on Android on iOS.

Re: Flutter looks good, but is painful

#180

Post by amw-zero »

pjmlp wrote: post #42
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.

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.

You don’t want to write the predominate amount of app logic in C++. I’ve been there. The portability isn’t worth it.
Post reply on HN