Live data from Hacker News

Google's cross-platform Flutter UI toolkit goes 1.0

techcrunch.com

191–200 of 343 posts

Re: Google's cross-platform Flutter UI toolkit goes 1.0

#191
post #74
post #67

Writing plugins/bindings for native code in flutter doesn't look fun. Almost 100 lines of code to write binding for function that doesn't take any parameters and returns simple 'int' (int getBatteryLevel()). This just looks even worse than JNI to me. Don't want to even thing how long time it would take me to write bindings for function that do image processing. https://github.com/flutter/flutter/blob/master/examples/…

> We are on the verge of VR and AR and I don't see how flutter can help e.g. processing >100fps Video Feed using OpenCV library. The demo they presented on stage with ML and smile detection had quite big latency. I wouldn't call it real time. I can't find any claim from Flutter team that 100fps video processing is even their goal. So that's a strange metric to measure it by - especially since it's competing against J…

> On mobile? Qt really isn't pleasant or usable on mobile.

Can't confirm. We've been using QML (part of Qt) and C++ to write cross-platforms applications (Android, Windows, Mac) for many years now without any major hiccups.

Re: Google's cross-platform Flutter UI toolkit goes 1.0

#194
post #83

Cross-platform frameworks that don’t use native controls have suffered from problems... - They inevitably don’t look or work like native apps in ways both big and small, frustrating and annoying users. (... the spell-checker doesn’t work right or text selection is janky or unavailable where it should be, certain short-cuts work differently or have different gestures or keys, etc.) - they don’t get updates to native c…

These seem like valid concerns at first glance, but I feel these are not really issues in practice (only in theory). >> - They inevitably don’t look or work like native apps in ways both big and small, frustrating and annoying users. (... the spell-checker doesn’t work right or text selection is janky or unavailable where it should be, certain short-cuts work differently or have different gestures or keys, etc.) as `…

> as `coldtea` points out below, this is not really an issue in today's ecosystem. Branding themes are more prevelant on most apps people are using than not.

On iOS, the extent of "branding themes" end up is often limited.

> Flutter renders all of its fonts itself natively, using the same way Chrome does it. Has this been a problem?

There is no Chrome on iOS. So Flutter is different from everything else out there.

> Is this a remark on an incomplete cross platform framework (i.e., flutter needs more features) and that it hasn't reached enough popular usage, or that cross platform frameworks have this problem? If not, it feels like the alternative to not using a cross platform framework is to write everything for each platform in a platform-specific way, which might be considered much worse. What's the issue at hand here?

Flutter, and almost every other cross-platform framework, have this problem.

Re: Google's cross-platform Flutter UI toolkit goes 1.0

#195

It's sad that this thought had to cross my mind, but how long until Apple prohibits or penalizes the use of this toolkit?

Why would they? I don't see any guidelines it violates, other than the loose suggestion to have your app be reasonably designed.

Re: Google's cross-platform Flutter UI toolkit goes 1.0

#196
For those who don't know: The app on the first screenshot is inkino [1] which had two Show HN in the past months:

- https://news.ycombinator.com/item?id=16818170 (42 comments)

- https://news.ycombinator.com/item?id=18399542 (version 2.0, 2 comments)

[1]: https://github.com/roughike/inKino

Re: Google's cross-platform Flutter UI toolkit goes 1.0

#197
post #60

Unless they force Flutter upon Android devs, I will let it pass, not eager to learn Dart.

It's strange to me that after all this time, every time a thread about Flutter reaches Hn or proggit, there are multiple comments about the choice of the Dart language. I think they've made it pretty clear by now that they don't have intentions of switching from Dart. Heck, they've published an entire "Why Flutter uses Dart" article explaining their reasoning. It's like beating a dead horse. Besides, you could always…

Because there are a ton of 'good' programing languages and it's tiring to switch around for barley any practical benefits?

I already jump between a few languages on a daily basis but it's getting ridiculous especially when it's related to fairly mundane UI work

in reality it's yet another x-platform 2d ui framework, who cares.

Re: Google's cross-platform Flutter UI toolkit goes 1.0

#198
post #182

I don't understand why Apple is the only one left that uses a strongly typed pre-compiled native programming language. It really isn't hard to use Swift compared to other programming languages. And it's a really nice to use, safe and if you want it to be also a language that allows you to write really fast algorithms.

Dart is strongly typed and pre-compiled, at least when packaged. It can run in interpreted mode in development for live/hot reload: a major advantage over Swift. Flutter also provides a first class Reactive UI story: something sorely lacking in native iOS (or Mac) development. PS Java (or Kotlin) are AOT compiled in all recent versions of Android.

> Dart is strongly typed and pre-compiled, at least when packaged. It can run in interpreted mode in development for live/hot reload: a major advantage over Swift.

Ah, that's how they do it. That's neat! But the language still has to deal with JavaScript compatibility.

> PS Java (or Kotlin) are AOT compiled in all recent versions of Android.

But it's still a mess to call native code. And still has Java garbage collection.

Re: Google's cross-platform Flutter UI toolkit goes 1.0

#199
post #91
post #83

Cross-platform frameworks that don’t use native controls have suffered from problems... - They inevitably don’t look or work like native apps in ways both big and small, frustrating and annoying users. (... the spell-checker doesn’t work right or text selection is janky or unavailable where it should be, certain short-cuts work differently or have different gestures or keys, etc.) - they don’t get updates to native c…

> - They inevitably don’t look or work like native apps in ways both big and small, frustrating and annoying users. We're way past that in the mobile world, where both Google, Facebook, and other top dogs use non-native cross platform frameworks and looks (e.g. Material UI).

To be fair, just because bigs use their own frameworks doesn't mean they produce great UX. There's an added learning curve to any non-native app that users incur when this happens - things are out of place, don't work as expected, features don't exist, etc. For example:

- Facebook doesn't use standard share sheets or web views. So if you're viewing an article, you can't use reader mode and you lose the (considerable) power of share sheets to do things like sending an article to another app or take an action on it.

- Gsuite doesn't register left swipe as back even though 99% of apps on iOS do. Icons for common actions are subtly different and make you double-take while you understand what they do. Accessibility options like larger text do not work, so if you're vision impaired good luck trying to figure out what you're looking at. And there's a ton of other quirks that have existed over the years including scaling to new resolutions/ipads, problematic text selection, performance, etc. It's not as bad as it used to be, but it's still not a pleasure to use Gsuite or any material design on iOS.

While many apps may use cross-platform frameworks solely for saving developer/designer time, the bigs use them for an additional strategic purpose that is detrimental to users.

- Google wants you to be familiar with their apps regardless of platform, so that its easier to get you to switch to Android or Chromebooks.

- Facebook wants to keep you in the app as long as possible, limit social sharing outside of their app, and spy on your browsing activity, so they add friction and don't use modern iOS web views that prevent that.

I wouldn't take cues from the bigs and just assume because they do it, it's the best course of action.

Post reply on HN