Live data from Hacker News

Google's cross-platform Flutter UI toolkit goes 1.0

techcrunch.com

151–160 of 343 posts

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

#151
post #134
post #91

Earlier quoted context omitted.

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

Same in the desktop world - Qt emulates the widgets, but can theme them, then QML is another story. Also WPF (from what I've heard) uses (skia?) to paint own widgets. IMGUI is another example. Then using the native wrappers, like wxWidgets is often cumbersome to create customized control, and if you do you end up with some platform specific version (not end of the world, but pretty much why not use the OS toolkit dir…

WPF uses DirectX.

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

#152
post #121

Earlier quoted context omitted.

Then why bother to post to complain? Is it necessary to also post in React Native threads about how that framework does not fit your needs?

Because Flutter would be a nice framework to use if they hadn't decide to bet on a language struggling for survival outside Googleplex. React Native uses a programming language widely accepted, no need for complains.

My point is why complain about something you clearly dislike and have no interest in being involved with?

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

#154
post #138

Like I said yesterday "The road block for adoption will be Dart. Why they didn't just choose Typescript or go with native javascript is beyond me. No one uses Dart. It was probably the poorest design decision they could make." The comment from pzo points out an even worst of an adoption showstopper.

They won't stop pushing Dart, thanks to success of Go, yet another 'good enough for the job' mediocre (at best) language.

I'm curious to know your thoughts on what makes Dart a mediocre language. At first glance, it seems to be merging the best of both worlds (can be AOT compiled for prod and JIT for dev)

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

#155

I have been a freelance Android Dev for past 4 or 5 years. I have recently built out a flutter app for a client. And honestly I am now looking for more Flutter work. UI development in Android is such a pain and I feel like I spend most of my time trying to get the UI just right. With Flutter I am building UI so much faster and getting to focus on the actual logic of the code. Dart was fine, I learned it as I went. I…

> UI development in Android is such a pain

Have you implemented any layouts using the Constraint Layout? Normally, I'd agree with you, but I find the Constraint Layout pretty great for designing UI's. The "glued together" approach makes responsiveness a breeze, imo.

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

#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 of the opinion that React Native is “more native” than Flutter is; it might be a bit slower but it is much easier to build apps that could pass as actual “native” apps because the React Native team doesn’t need to try to emulate system controls.

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

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

I guess someone is very outdated on their information.

https://www.adobe.com/devnet/air/articles/aot-or-interpreter...

Air supports native compilation since 2012!

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

#159
post #140
post #51

Earlier quoted context omitted.

From my point of view it looks a big internal politics war. Whoever wins, we loose.

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.

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

#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 with GUI nodes of native GUI toolkit.

So now going from each OS to another, you don't have to learn gazillion different ways to specify the layout. The type of nodes displayed on your GUI app changes from each environment to another. So you get to have the same programming techniques and you can get a web-app or a desktop app.

Post reply on HN