Why Flutter Will Take Off in 2018 • Hacker News Board

Re: Why Flutter Will Take Off in 2018

#21

Post by ubersoldat2k7 » Tue, Nov 28, 2017, 1:10 PM UTC

Although it seems like a great alternative and competition is always welcome, one of the best points about React Native is that any JS/React/Web developer can go to a React Native project and know what the hell is going on. Even if they don't know exactly what a View is.

Flutter would be great if Google didn't have to sell Dart somehow and instead stick with TS/JS. Now you have Flutter developers, not Dart developers because Dart is dead as it was 5 years ago, who can't do either Web nor Native. Not a great selling point there.

So, if you're a web developer, you have to learn a new language, framework (whatever Flutter uses) and set of APIs. If you're a native developer, you have to learn, pretty much the same things. And then, you're stuck there. Implementing everything which you can already find on JavaScript and with a knowledge you won't find a job for.

This was funny:

_Native mobile engineers who are adding a hybrid mobile framework to their tool belt DON’T want to slide back to JavaScript._

Yeah, like learning a whole new set of language and tools, which we cannot reuse for anything else, is going to drive us to the wonders of Dart.

_It’s also not only for mobile but for the web as well._

Angular, one of Google most successful projects, uses TypeScript and not Dart, let that sink in.

And BTW, Dart is a language, so expect many other Dart-Flutter Frameworks poping up. React Native is based on a framework with lots of traction already and you can just use stuff you're already familiar with like Redux, Underscore and pretty much a whole set of JS libraries already present. Almost every service has a JS library. Now you have to redo the whole thing on Dart?

In conclusion, Dart and Flutter is the next smoke cloud and fad to sell on 2018 and will die (or evolve to use TypeScript/JavaScript) on 2019.

Edit: I really hope it's the second option because, the other points about RN are true. The documentation is not the best and competition is always a good thing.

Edit 2: After the demise of so many projects from Google, I frankly distrust them whenever a new thing comes from them.

Edit 3: Now that I think about it, NativeScript already uses Angular and TypeScript, so maybe that's the reason for choosing Dart for Flutter.

Re: Why Flutter Will Take Off in 2018

#22

Post by m_fayer » Tue, Nov 28, 2017, 1:15 PM UTC

seenickcode wrote: post #14

slig wrote: post #11

Earlier quoted context omitted.

Yes! TypeScript would be perfect.

I can't believe how easy Dart is to learn, especially having a TypeScript background myself.

I'm not worried about learning Dart. I'm worried about adding yet another tooling and OSS ecosystem to my collection, that's where the real cognitive burden is. I'll do it if I have to, but in mobile you really don't have to. You can choose from Java/Kotlin, Swift, .NET, and HTML+(Java/Type)Script - chances are you're already in one of these worlds, and if you're not then entering any one of them will pay much bigger dividends than Dart.

Re: Why Flutter Will Take Off in 2018

#23

Post by ENGNR » Tue, Nov 28, 2017, 1:21 PM UTC

After seeing React upgrade the entire library to v16 to enable entirely new use cases, without breaking the API... I'm pretty impressed. That's in production right now

If Flutter does something cool like provide better native component libraries it might end up as a library inside the React API

Re: Why Flutter Will Take Off in 2018

#24

Post by seenickcode » Tue, Nov 28, 2017, 2:03 PM UTC

ubersoldat2k7 wrote: post #21

Although it seems like a great alternative and competition is always welcome, one of the best points about React Native is that any JS/React/Web developer can go to a React Native project and know what the hell is going on. Even if they don't know exactly what a View is. Flutter would be great if Google didn't have to sell Dart somehow and instead stick with TS/JS. Now you have Flutter developers, not Dart developers…

A huge amount of people out there try to avoid JS like the plague, hence the popularity of TypeScript, so yep, if I can learn Dart in an afternoon and have the ability to write hybrid mobile apps then it's plenty worth it.

Re "Angular, one of Google most successful projects, uses TypeScript and not Dart, let that sink in.": Google is also promoting AngularDart as well, "Hundreds of Google engineers use AngularDart to build the sophisticated, mission-critical apps that bring in much of Google’s revenue." https://webdev.dartlang.org/angular/

"Demise of so many projects from Google" I agree with (sans the popularity of Go).

Flutter is in alpha so time will tell if Google will put enough funding/focus into it.

Re: Why Flutter Will Take Off in 2018

#25

Post by seenickcode » Tue, Nov 28, 2017, 2:04 PM UTC

m_fayer wrote: post #22

seenickcode wrote: post #14

Earlier quoted context omitted.

I can't believe how easy Dart is to learn, especially having a TypeScript background myself.

I'm not worried about learning Dart. I'm worried about adding yet another tooling and OSS ecosystem to my collection, that's where the real cognitive burden is. I'll do it if I have to, but in mobile you really don't have to. You can choose from Java/Kotlin, Swift, .NET, and HTML+(Java/Type)Script - chances are you're already in one of these worlds, and if you're not then entering any one of them will pay much bigger…

Yep good point.

Re: Why Flutter Will Take Off in 2018

#26

Post by axemclion » Tue, Nov 28, 2017, 3:50 PM UTC

seenickcode wrote: post #15

jbergens wrote: post #8

As I understand it he says that Flutter uses dart and that is much better than js, react native lacks good documentation and the developer tools are great for Flutter/dart. Both Flutter and Dart seems interesting but I don't think they will take over the world in 2018. TypeScript already exists and has a lot more users than dart and also has good tooling. It is also typed like dart which makes more traditional c# and…

Good points. After writing native mobile apps with ObjC, Swift etc I still prefer strong typed languages like Go, TypeScript, etc.

I am a member of the React Native Core team

> On the documentation The document is not abandoned. Infact, we are actively working on fixing the document and reaching out to the community to identify gaps in documentation and fixing them. We are also moving docs to a separate repo to make sure that they are easy to contribute to.

> On Typed languages. A lot of people use React Native with Flow or TypeScript, and are able to benefit from type systems.

Re: Why Flutter Will Take Off in 2018

#27

Post by ElectricPenguin » Tue, Nov 28, 2017, 6:29 PM UTC

kennydude wrote: post #12

The demo has an iOS app which looks like an Android app. Why.

:-) In the demos that I've seen they even say... "Don't do this."

I think it's to emphasize that while it can mimic the native environment of either platform Flutter also has the ability render non-native custom controls to either platform.

Re: Why Flutter Will Take Off in 2018

#28

Post by Kipters » Fri, Dec 01, 2017, 9:53 AM UTC

hesarenu wrote: post #9

Kipters wrote: post #4

I may be biased since I've been working with Xamarin since 2013, but I fail to see how Flutter could be a better choice than Xamarin: - the language is a niche compared to C# (which translates in "it's harder to hire devs") - it's less mature (both the framework and the language) - most importantly, Flutter uses its own set of controls that look like the native ones, while Xamarin uses the platform's native controls.…

Does Xamarin have native UI widgets not just basic components? ReactNative has native controls but most are just basic. Flutter has material/ios widgets built in which simplifies develpoment. I like flutters declarative syntax similar to reactjs. But its still in alpha hence can't commit much time to it.

In addition to what m_fayer says, you can also bind native libs and make the same adjustments, so most native controls written in Objective-C or Java are basically drop-in (bindings are already available for most common components on NuGet, but they're almost trivial to write)

Binding Swift libraries is a pain though