Google's cross-platform Flutter UI toolkit goes 1.0 • Hacker News Board

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

#171

Post by lern_too_spel » Tue, Dec 04, 2018, 9:56 PM UTC

forgot-my-pw wrote: post #98

lern_too_spel wrote: post #77

Earlier quoted context omitted.

AdWords previously used GWT, which is no longer maintained by Google. I get the feeling the AdWords team just really doesn't like JavaScript, which is understandable, but it doesn't say anything about whether AdWords will stick with the current non-JavaScript language du jour or move to another.

GWT served them well for 8 years. Now the Dart one is expected to last for the next 7+ years. Read this interview if you're interested to learn more on their reasoning: https://news.dartlang.org/2016/03/the-new-adwords-ui-uses-da...

7+ years from early 2016, which means 4+ years today. Take it as you will.

The point being that just because Google uses something for AdWords doesn't mean Google will maintain it for the long run. I might find other arguments more convincing.

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

#172

Post by Hemospectrum » Tue, Dec 04, 2018, 10:00 PM UTC

guix992 wrote: post #160

I don't understand why we have to keep reinventing GUI toolkits and layout engines over and over again. Why can't this domain be smarter like Compiler world and build pluggable components? So something like, a react-engine that renders the recently changed display node. The react-engine is offered as an API/library layer, it could be run in browser where it works with DOM, it could be run in a desktop where it works…

It's one thing to draw some widgets. That's the "easy" problem (to borrow some AI jargon).

It's totally another thing to specify how these widgets read and write the model in which the business logic is encoded. If you want to animate transitions between valid model states, it all gets ten times as complicated. And then when you try to make it performant by eliminating redundant redraws, it becomes an even bigger mess.

There is no simple and obvious solution that tackles all of the above. The reactive UI model (not just Flutter, but all React-like frameworks) is an ongoing attempt to do a better job of all of it, with varying success. Existing UI toolkits, before the introduction of this model, were not designed for it. They were built on the assumption that the future would be a giant object graph caught in a tangle of callback methods. If you want to make a reactive UI populated by native widget objects, you have to figure out how to plumb all their mutable state back into the reactive model. That's an enormous investment of labor. Writing a new toolkit from the ground up is a huge amount of work in absolute terms, but in relative terms it's the easy way out.

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

#173

Post by saagarjha » Tue, Dec 04, 2018, 10:03 PM UTC

myko wrote: post #162

saagarjha wrote: post #157

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

Not sure. But Flutter can't even get switches and text fields to work right, so it really has much further to go than React Native does.

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

#174

Post by k__ » Tue, Dec 04, 2018, 10:06 PM UTC

mikece wrote: post #8

bluetidepro wrote: post #2

Congrats on their 1.0 launch! I haven't looked too closely at Flutter yet, to be honest. How does it compare to React Native (besides what a basic Google search will yield)? Has anyone jumped ship for either or after trying one of them?

Comparison: React Native (and Xamarin, for that matter) use platform-native widgets with JavaScript composing the UI dynamically in the case of React Native (and UI's either dynamically composed or statically compiled with Xamarin -- depends how you build the app). Flutter brings it's own widget layer to iOS and Android (and Fuchsia?) so it's more like starting with a blank 2D graphics canvas and creating your own co…

Parts of React-Native are also written in C++, btw.

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

#175

Post by Gonzih » Tue, Dec 04, 2018, 10:08 PM UTC

I did a small app in flutter last week out of curiosity (fetching rss/atom feeds, rendering html content) and was surprised how easy it was to work with tooling that flutter provides. Also was pleasant surprised on how well Dart fits in to this use case. Go flutter!

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

#176

Post by k__ » Tue, Dec 04, 2018, 10:09 PM UTC

ystrdytmrrw wrote: post #163

Nothing will make me learn or do Dart.

Well, you're lucky. There is React-Native (JS/TS), Xamarin (C#) and Boden (C++)

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

#177

Post by k__ » Tue, Dec 04, 2018, 10:13 PM UTC

tabs_masterrace wrote: post #63

asien wrote: post #46

Google is spending so much money on Flutter , it’s insulting. Honestly, the entire industry is shifting towards JavaScript/Typescript and the only language that they could think of for Flutter is Dart ? This is even more Hypocrite knowing that Flutter doesn’t actually run the Dart VM, it uses AOT and compile to native code. Meaning we could use literally any ECMAScript language to run with Flutter instead of Dart. Th…

I'm not a fan of Dart either, but common JavaScript/TypeScript isn't exactly the holy grail either. JS is basically unusable due to, well lack of types, and TypeScript hacks them into it by hugely increasing complexity of everything. Should have gone with Kotlin. Would just sweep over huge amounts of existing Andoid devs too.

Reason is an interesting approach to the "JS problem", a better one than TS and Dart.

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

#178

Post by snaky » Tue, Dec 04, 2018, 10:28 PM UTC

pjmlp wrote: post #159

snaky wrote: post #140

Earlier quoted context omitted.

What we loose if Android side wins?

A Java fork failing to keep up with standard Java, winning on where Microsoft failed (aka Google J++), thus forcing Java library authors to either write two versions or constrain themselves to the common subset. Meanwhile, there are plenty of other Java vendors that are able to create their own Java implementations and play ball with the rest of the eco-system.

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.

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

#179

Post by baybal2 » Tue, Dec 04, 2018, 10:28 PM UTC

I'm surprised to see them showing Taobao app there. I know it is done in Weex, without anything like Flutter.

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

#180

Post by baybal2 » Tue, Dec 04, 2018, 10:32 PM UTC

guix992 wrote: post #160

I don't understand why we have to keep reinventing GUI toolkits and layout engines over and over again. Why can't this domain be smarter like Compiler world and build pluggable components? So something like, a react-engine that renders the recently changed display node. The react-engine is offered as an API/library layer, it could be run in browser where it works with DOM, it could be run in a desktop where it works…

Both GTK and Qt can render to HTML