Live data from Hacker News

Google's cross-platform Flutter UI toolkit goes 1.0

techcrunch.com

161–170 of 343 posts

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

#161
post #121

Earlier quoted context omitted.

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.

You said you can't be bothered to learn dart because you want to build your skills in c# etc. As a result the only criticisms you can make are devoid of content: It's not a proper, modern language (what?). It's struggling for survival...

I can't be bothered to learn Dart because it lacks market value.

C# was just an example of a language that is actually worthwhile to have on a CV. I could have given many other examples.

Ad Words team rescued Dart from certain death and Flutter it is attempt to come play into the ring.

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

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

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

#164
post #93
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 are all excellent points. I'm curious how Flutter stands to address these risks/issues in the early days. I'd imagine it will take much more than 1.0 to get close to parity with the OS. Even if we assume it will always be 90% of the full OS experience (which is fine for the vast majority of use cases).

It helps that the Flutter and Android teams can talk to each other (they're both part of Google). So atleast for Android, you might be able to expect Android platform features appearing on Flutter in sync'd release cycles.

And in cases where you're using platform-specific feature that Flutter doesn't support yet, then your experience will be no different -- the burden remains on you to write platform-specific code.

It's unclear to me that this is a sticking point.

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

#165

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.

Here's some of the explanation about why they chose Dart: > There’s a lot of nice properties of Dart, we talk some about this on our website at our frequently asked questions. One of the nice properties of Dart is that it has a really fast garbage collector, one of the choices that we made in Flutter was to have this reactive style system where it’s very common to allocate thousands of objects in a – if not, tens of…

No one uses Dart. No one is going to switch from React or Vue to Flutter when they can't bring over their TypeScript skills and tooling. It was a stupid, arrogant decision on Google's par, end of story.

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

#166
post #121

Earlier quoted context omitted.

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?

Because Flutter would have been an interesting toolkit if it wasn't for Dart.

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

#167
post #125
post #103

Earlier quoted context omitted.

Nah, I rather built up my skills with C# and Xamarin, Qt and C++, or PWAs, it is more relevant to my CV.

Sure, you do what you want, no one is stopping you. But I guarantee you'd be amazed of just how quickly you could go from installing the Flutter plugin into VS Code to actually developing a fully hot-reloaded app inside an iOS emulator. The DX of Flutter is by far the best I've seen anywhere.

I am old enough to have seen similar tooling in action with Smalltalk, Common Lisp, Oberon, Eiffel, VB, Delphi, C++ Builder.

So no surprises there.

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

#168
post #15
post #6

Earlier quoted context omitted.

> like a game engine In this aspect it's very similar to Flash or QT.

or canvas or kodi (which has been improved now to not refresh the entire screen.)

you mean this Kodi https://kodi.tv/ ?

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

#169
post #158
post #142

Earlier quoted context omitted.

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!

I'm not sure why you'd be referring to me in the third person while replying to me, but if that's the case then yes, it's quite possible they've improved.

> SWF content on all platforms other than iOS is JIT compiled

Cool, but I use Android.

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

#170

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…

So you're asking all the OS vendors to get together and implement a universal UI toolkit? Good luck with that.
Post reply on HN