Live data from Hacker News

Ready for Production Apps: Flutter Beta 3

developers.googleblog.com

31–40 of 107 posts

Re: Ready for Production Apps: Flutter Beta 3

#31

Fun fact: on pre-release Angular 2 versions, Dart was it's main language. My hypothesis is that, if they decided to continue using Dart, probably we would have more Dart developers and this could have lead to a faster Flutter adoption.

Angular.js (aka Angular 1) had a Dart option for a long time, which was hardly used. If it were the only option, it'd have probably led to fewer Angular developers.

Re: Ready for Production Apps: Flutter Beta 3

#32
post #10
post #8

Earlier quoted context omitted.

I've been a React fanatic for several years, so my opinion is colored by that: 1. Great DX (developer experience) - a single language (Dart); no need for JSX, JavaScript, JSON, Flux/Redux and various other libraries. You can focus on the business logic rather than battling the ecosystem. 2. A single set of components (no iOS or Android specific navigator components etc.) 3. No longer need a JS engine to run - truly n…

Being agree with all 4 points I see two drawbacks: 1. Not using OEM widgets. Even the rendered widgets may look good, they can't beat the native widgets optimized for the particular platform. 2. The choice of Dart as the main language. I can understand both points though

Not using OEM widgets has huge advantages too though - easier portability, you can preview any OS style on any device (e.g. develop an iPhone app even if you don't have an iPhone), you don't rely on the underlying platform as much (e.g. if maybe that platform doesn't get updated very reliably!).

Really the only downside is that it is a ton of work to make it match the look of the native widgets. They've done a good job though. I really doubt 99% of people could tell at all.

Dart is ok. Better than Java or Javascript at any rate!

Re: Ready for Production Apps: Flutter Beta 3

#33
post #6

> Alibaba praises Flutter for its consistency across platforms As a user, I don't. Sure, on Android Flutter looks OK, but on iOS it looks out-of-place.

There is an iOS theme (Cupertino), but I am not sure how complete it is.

It’s not so much the widgets as it is the actual look and feel. Neither scrolling nor text rendering is quite right.

I wrote a post to that effect here: https://harveynick.com/2018/05/21/an-ios-developers-opinions...

Re: Ready for Production Apps: Flutter Beta 3

#34
post #26

Earlier quoted context omitted.

I'm always concerned that accessibility is being left behind. Android and iOS both put great efforts into making their UI accessible, why do the work again? Chances are that the accessibility of those third-party components will be worse or maybe doesn't even work at all.

The problem is that the accessibility work already needs to be done on every platform (for now we have two really popular ones but nobody can be sure what the future brings). Also, if you could just recompile your app for a new platform and release (more or less), it would remove the biggest barrier to entry for possible new platforms: Adoption.

That's not what I meant. Android and iOS already have their own widgets with accessibility features in place. iOS even better than Android. It took years for them to develop to where they are now.

Now Flutter is making its own widgets that look and handle like the corresponding native widgets. So they need to implement accessibility all over again in the same way that is already present on the platforms. Google is thus redoing all the work they already did in Android.

A lesson from modern software development is that software is developed incrementally and because accessibility is never high on those priority lists, it will lack in quality at first and take multiple iterations to get up to the same level as the native accessibility of the OS, if it even gets there in the first place.

Re: Ready for Production Apps: Flutter Beta 3

#35
post #8

Earlier quoted context omitted.

I've been a React fanatic for several years, so my opinion is colored by that: 1. Great DX (developer experience) - a single language (Dart); no need for JSX, JavaScript, JSON, Flux/Redux and various other libraries. You can focus on the business logic rather than battling the ecosystem. 2. A single set of components (no iOS or Android specific navigator components etc.) 3. No longer need a JS engine to run - truly n…

How is it native if you're just replacing a JavaScript VM with a Dart VM? Or is the Dart somehow compiled to native code?

Dart has a VM (with hot reloading) for dev time and an AOT compiler for release builds.

I’d say that’s one of the most attractive things about Dart to compensate for yet another language.

Re: Ready for Production Apps: Flutter Beta 3

#37
post #36

Isn't "beta" supposed to mean "not quite ready for production"?

Chicken and egg, right? If Google declares it not ready for production, then nobody uses it for production apps, so it never gets the kind of testing it needs to really be production ready.

If Google declares it out of beta, then people assume nothing will change, and if things do change they complain.

So the current wisdom is to have a 'production ready beta' which indicates an in-between period where things can change, but you're encouraged and expected to use it in production.

Re: Ready for Production Apps: Flutter Beta 3

#38
I liked the idea of Flutter since I saw it for the first time probably long time ago. Dart as a language choice was throwing me back though, but in general this language is very similar to ES6 and makes OO easier. For example it doesn't require to use `this` in methods. I wish it was TypeScript instead, because it has more mature tooling and community support.

I'm still hesitant to put my hand on it for side project until it's more popular. Chicken and egg problem I guess.

Re: Ready for Production Apps: Flutter Beta 3

#39
post #10
post #8

Earlier quoted context omitted.

I've been a React fanatic for several years, so my opinion is colored by that: 1. Great DX (developer experience) - a single language (Dart); no need for JSX, JavaScript, JSON, Flux/Redux and various other libraries. You can focus on the business logic rather than battling the ecosystem. 2. A single set of components (no iOS or Android specific navigator components etc.) 3. No longer need a JS engine to run - truly n…

Being agree with all 4 points I see two drawbacks: 1. Not using OEM widgets. Even the rendered widgets may look good, they can't beat the native widgets optimized for the particular platform. 2. The choice of Dart as the main language. I can understand both points though

It’s true it’s very difficult to completely replicate the look and feel of a native toolkit with something like this.

However, my experience has been that most people want a heavily customized and styled UI that looks similar on both iOS and Android because a generic stock UI doesn’t have enough visual bling to attract users or establish a strong brand. And it looks like doing that kind of customization should be a lot easier with Flutter than it is with either native platform’s native APIs.

Re: Ready for Production Apps: Flutter Beta 3

#40
post #37
post #36

Isn't "beta" supposed to mean "not quite ready for production"?

Chicken and egg, right? If Google declares it not ready for production, then nobody uses it for production apps, so it never gets the kind of testing it needs to really be production ready. If Google declares it out of beta, then people assume nothing will change, and if things do change they complain. So the current wisdom is to have a 'production ready beta' which indicates an in-between period where things can cha…

Wouldn’t that traditionally be a Release Candidate? Something you think is good to go, but needs wider testing before you can say that for sure?
Post reply on HN