Live data from Hacker News

Google's cross-platform Flutter UI toolkit goes 1.0

techcrunch.com

271–280 of 343 posts

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

#271
post #204

Earlier quoted context omitted.

There's one place where none of this matters: Games engines. Games have the same, consistent (hopefully) easy to use interface across every platform they support. They either accomplish this, or they simply don't survive on the market. It has to be said that most modern UI frameworks ARE game engines, anyway. Or maybe its a tautology: game engines eventually become platforms, which become "OS's on other OS's". Which…

Game engines are a place where it makes sense to roll your own UI framework many times, so on that point I agree with you. The purpose of a game is generally immersion and escape, so makes sense to remove users from their device's UI in many instances. Game UIs tend to have their own conventions so frequent players don't have much of a learning curve. But in general players accept some learning curve because games ar…

There are so many aspects of modern UI that are not functional, and serve only to distinguish one platform from another in the wider market-place - so I feel that your statement that the OS-provided UI is a 'tool' is misguided. There is nothing tool-like about making me wait for a swipe scroll to complete - this is a game mechanic designed to entertain.

And in that sense, its quite possible to make a non-native UI that is more productive than the OS-provided UI - you merely have to take responsibility for the user experience, obviously.. So yes, its about the user. One reason for going non-native and rolling-your-own, is to ensure that your user has a positive experience, no matter what platform they are using - and this directly competes with the platform-vendors ability to woo new users with fancy, game-like, UI elements.

So I don't think this point is quite correct:

>Companies that choose to use their own UI frameworks or avoid the platform's guidelines are doing so to the detriment of their user experience.

Developers that choose to use their own UI framework win or lose on the basis of how responsible they are for making sure the user has a good time with their UI. This has nothing to do with whether the app is a game or a tool or whatever. Its a matter of competence.

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

#272
post #162

> One of the challenges that React Native developers face, or have reported in the past — one challenge is that native React Native code is written in JavaScript, which means that it’s run using the browser’s JavaScript engine, which immediately kind of move this a little bit away from the native model of the platform. Calling React Native “not native” while eschewing platform UI widgets is a bit thick. I’d actually…

> React Native team doesn’t need to try to emulate system controls. The solutions for push navigation across Android and iOS using React Native were pretty poor and didn't emulate system controls the last time I used them. Has that changed?

I’m building my first RN app right now and I feel like the navigation animations are native (modals, etc).

(I’ve been doing native iOS since 2009)

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

#274
post #204

Earlier quoted context omitted.

Game engines are a place where it makes sense to roll your own UI framework many times, so on that point I agree with you. The purpose of a game is generally immersion and escape, so makes sense to remove users from their device's UI in many instances. Game UIs tend to have their own conventions so frequent players don't have much of a learning curve. But in general players accept some learning curve because games ar…

What sort of "other purposes" would it serve for the UX to be worse? Do you have any IRL examples of this happening?

Sure I wrote them in another comment here: https://news.ycombinator.com/item?id=18604613

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

#275
post #181

Look at how many comments on this, or any other Flutter thread, mention hot reload. What I take from that is this: if your toolchain makes rapid iteration easy people will figure out how to work around almost anything else. Language/framework/tool creators rarely put enough time into the developer experience. And by that I mean the experience of a developer working with your tool for 8 hours a day. I can get more don…

I believe rapid iteration (and learning curve) is what made php and javascript (and delphi, anyone?) that popular.

I'm happy there's another platform but they really should use some existing language with mature tools and libs. Why reinvent everything again? Unless their real intent is to lock you to their own ecosystem and then mildly steer you to using or preferring to integrate with their own products.

BTW: Is dart really open? Publishing sources does not mean a thing, is Google making choices?

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

#276

Earlier quoted context omitted.

What? Qt is mostly LGPL. You don't need a lawyer.

Try to download it from qt.io. You will have to go through several screens saying "Are you sure you are able to comply with the LGPL? Wouldn't you rather get the commercial version for peace of mind?". If that isn't an implied threat, i don't know what is.

Yum install epel-release

Yum install qt5-

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

#277
post #178

Earlier quoted context omitted.

Maybe that's not that bad, considering the fraction of Java libraries that used simultaneously in Android and Java ecosystems isn't very large. OTOH if Fuchsia wins, we loose the open source mobile OS, the major one, the only one, with tons of apps and ways to ungoogle.

On the other hand, we'll finally have an empirical resolution to the Tanenbaum-Torvalds debate!

Intel already did that for us with the Management Engine.

And if you squint a bit through how modern Treble drivers work, Google has turned their Linux usage into a kind of micro-kernel OS flavour.

https://source.android.com/devices/architecture/hidl

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

#278
post #248

Earlier quoted context omitted.

> Unsurprising consistent behavior is a value. Looking at the last 30 years of software development, it's pretty clear that users don't care very much.

They do care. Try writing a DOS or Blackberry-style app today and see what happens. Software today has internalized the idioms so much that its developers don't even realize it. "My app is a snowflake and needs a custom design language and UI." You're vim or Photoshop or AutoCAD or Excel: you're targeting dedicated users who are prepared to invest in learning a specialized UI. Fair enough. But if you're not one of th…

>They do care. Try writing a DOS or Blackberry-style app today and see what happens.

Nothing much. Some of the most downloaded and bought apps (desktop and mobile) have horrible custom UIs. As long as the app has the crucial functionality, few care. And I'm talking for average users.

As for pros? Well, vim and Emacs are DOS style apps (well, in that they use curses and totally un-native GUI paradigms), and they're still strong.

UI concerns of that level only matter when apps otherwise have marginal utility and small other differences with competitors.

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

#279
post #123

Earlier quoted context omitted.

Which is irrelevant to my point, which is that it's also used where it's not native.

So Cocoa is missing from your list given iTunes on PC.

Sure, and many others are also missing. I gave some examples, not an exhaustive catalog.

This is hinted at where I say "Google, Facebook, _and other top dogs_", and "_e.g._ Material UI" -- emphasis mine.

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

#280
post #142

Looks nice. I find it similar to Adobe AIR but with DART as programming language.

Except Adobe Air doesn't compile to native and the apps don't run until you nag the user to download the Air runtime.

No it does not work like that.

To be able to publish on iOS, there Adobe AIR compile to native binary.

On Android, Windows, and macOS (also Linux) it does not to do that (eg. it is fast enough), so instead you have the choice to publish an app that need the AIR runtime, OR to publish a captive runtime (it bundle inside the app).

In general, most dev use captive runtime and so you don't need the AIR runtime installed first.

Now, keeping a runtime bundled vs compiling to native have numerous advantages, for ex you can make part of your app dynamically updatable without re-installing the whole app.

Technically Adobe have the tech in the AIR SDK to compile to any native target, they just use it for iOS.

Post reply on HN