
Flutter: the good, the bad and the ugly - marcobellinaso
https://medium.com/asos-techblog/flutter-vs-react-native-for-ios-android-app-development-c41b4e038db9
======
faitswulff
I think the biggest benefit of Flutter, speaking as a developer, is that the
design choices have been abstracted away. It feels like SquareSpace or Lego
for mobile app design. I compose the component hierarchy and then the app
looks, for the most part, like I want it. In contrast to React Native, where
there are a lot more fiddly bits and CSS that I'm not interested in.

On the other hand, stepping outside the bounds of the framework becomes much
more difficult, so it's a double edged sword. But I'm a simple type, I like
Bootstrap just fine - Flutter does things well enough for the most part.

~~~
nv-vn
Spot on. We experimented with a bunch of platforms for our app and ultimately
settled on Flutter for this exact reason. Design is orders of magnitude
simpler than in almost anything else. Working on a small team without a full-
time designer this was a godsend.

------
resters
React-Native is great, the only problem is that Facebook does not do enough to
nurture the open source use of it, and this creates lots of extra work for
teams using it.

Airbnb's decision to abandon RN is clearly due to engineering blunders and
political nonsense internal to Airbnb, which has little to do with RN itself.

But if you look at all of the github issues for RN you will see that many of
them are open/unresolved for weeks with hundreds or thousands of +1s only to
have someone at Facebook mysteriously close them, leaving a lot of people in
the lurch.

We're also seeing a lot of API and internal refactoring fromi FB rather than
focusing on the ecosystem, which indicates that inside FB it is more
beneficial to say "I sped up x by 10% in react-native" than it is to improve
usability for the many using it as an open source library trying to get
something simple to work as expected.

~~~
ryanwaggoner
See, and I think that React Native is terrible, and Airbnb abandoning it
clearly shows that their engineering culture is solid and not driven by cargo
cult engineers chasing the latest fad.

~~~
chrisco255
Discord uses React Native, and they only have two developers on their iOS app.
Millions of users, impressive app with high performance...two devs.

~~~
ryanwaggoner
I haven’t used their app, but scaling an app isn’t actually that difficult if
the backend can handle it. I don’t think that their use of RN is relevant here
unless you think there’s no way that a native iOS app of similar complexity
couldn’t be built by two devs? But then you’d have to explain all the
counterexamples, or even where a solo dev builds an app that goes viral and
gets millions of users...

~~~
k__
"airbnb abandoning it shows it's bad, but other companies using it
successfully doesn't sbow it's good!"

~~~
nv-vn
Abandoning something takes more work than using it, since it adds the cost of
a rewrite. If Airbnb adopted framework X that wouldn't make me confident in
framework X -- they haven't even used it yet! If they used it for a long time
that would increase my confidence in X (in the absence of evidence to the
contrary). But if everyone else started abandoning X I'd take Airbnb's
experience with a grain of salt. I get that Discord is able to do well with
it, but that doesn't mean everyone is able to do well with it depending on
their needs. And who knows, maybe Discord is having just enough trouble that
it hurts but too little to switch.

~~~
chrisco255
They give it rave reviews: [https://blog.discordapp.com/why-discord-is-
sticking-with-rea...](https://blog.discordapp.com/why-discord-is-sticking-
with-react-native-ccc34be0d427)

------
ken
> don’t worry, it’s super easy if you’re familiar with Java, JS, Kotlin, Swift
> or C#

Those languages are pretty different from each other. I've used 4 out of 5 of
them professionally, and I'd say it takes a good 6 months to get comfortable
with the new syntax and idioms.

(Learning to speak a language may be super easy if you already know another
one in the same family, but you still have to learn it. Easy learning is not a
zero cost activity.)

JS and Swift, in particular, feel like opposites. Besides using the {}
characters a lot, I can't think of much they have in common.

Programmers today frequently need to learn new languages, but why? If you
believe that these languages are similar enough to be "super easy" to cross
between them, then how is it the incremental value of any of these languages
so great that it justifies writing a new compiler, and making millions of
programmers figure it out? It's not just learning time. I've run into nasty
bugs with every compiler I've ever used.

As an engineering decision, is there any feature of Dart that is required by
Flutter? This looks like the software analog of the pentalobe screw. It's not
technically difficult to deal with but it serves no real purpose except to be
different.

~~~
thosakwe
The Flutter team has answered this question directly in a few public pieces:

[https://hackernoon.com/why-flutter-uses-dart-
dd635a054ebf](https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf)

[https://flutter.io/docs/resources/faq#why-did-flutter-
choose...](https://flutter.io/docs/resources/faq#why-did-flutter-choose-to-
use-dart)

I personally already knew Dart, and had quite a bit of experience with it
before I found out about Flutter, but honestly, I still don't see the language
itself as _that_ much of a barrier to a platform to where it should be one of
the most common criticisms of the entire framework.

After all, there _do_ exist alternative mobile development
frameworks/infrastructure, in the other languages that people usually bring up
as alternatives to Dart (ex. Kotlin, Java, Swift, C#, JS).

~~~
ken
Thanks for replying, but I don't actually see the answer to my question here.
They read like post-hoc rationalization, i.e., _Given_ that Dart was chosen,
what are some attributes of it that programmers found desirable?

Several other languages offer _most_ of these desired features. Did anyone
compare the effort required to add the remaining requirements to an existing
language? That's what would make it an engineering decision.

Even if Dart somehow takes zero effort to learn, I'm still not convinced it
was a net win.

~~~
Apocryphon
Here's a podcast episode with Randal Schwartz on Flutter that you might find
interesting, as it might shed some light as to how Flutter evolved from the
Dartium project and how the Chrome team was involved.

[https://softwareengineeringdaily.com/2018/07/11/flutter-
in-p...](https://softwareengineeringdaily.com/2018/07/11/flutter-in-practice-
with-randal-schwartz/)

You can also skim the transcript (pgs. 3-6) Transcript here:

------
mark_l_watson
Flutter looks good, the ‘goods’ out weighing the ‘bads.’ I am “retiring” next
spring, and I look forward to getting back into user experience development. I
wrote successful commercial UI heavy products for three platforms when they
were first released (Xerox Lisp Machine, 1984 Mac, Windows 1.0 beta) but
mostly people pay me for AI development, but I would enjoy getting back into
UI. I used RubyMotion to convert Cookingspace.com to simple iOS and Android
apps a few years ago, but RubyMotion hit a road block, I think, when it was
sold to an individual. Flutter seems more secure longer termed.

~~~
mark_l_watson
Also: it would be cool if Flutter was extended to support macOS, GTK (Linux),
and maybe even Windows 10. Give small dev teams more market reach.

~~~
garyclarke27
Agreed Flutter for : Android /IOS /Web /Windows 10 /MacOS Would be the amazing
killer combo, that would cause me to invest considerable resource into Flutter
and switch my team to it. I know there is an unofficial versions that
apparently do this, I would need the comfort of an official proven Google
version.

------
rhardih
Flutter appears to have a lot of the momentum that other frameworks lack. I've
usually sworn to Qt/QtQuick, but only because I want to be able to easily jump
into native code, and/or reuse existing C/C++ libraries, even on mobile
devices. Flutter can't do that yet afaik. Qt just isn't going in the right
direction. IMO if they'd gotten their act together, even years ago, all these
new fangled X-Platform frameworks, wouldn't even have existed.

I have to admit, that I haven't really taken RN seriously, because I
fundamentally don't believe in that architecture on a mobile device. RN only
seems exist to provide a means for people who like React. Not to actually
provide a beneficial application framework.

~~~
spiritcat
I think I can more or less say that we would not have been able to build what
we have without RN. At least not with same budget. There is a large class of
apps that would suck @ __in a webview but can get by just fine in RN with 90%
cross-platform code re-use. If you 're already a team of experienced react
developers the learning curve mostly just comes down to learning how to
resolve build issues. And possibly expo can take care of that depending on
your app. (anyone actually use expo for real stuff?)

With RN + React Web + [PaaS/FaaS] I feel like a lone dev can be dangerous
theses days.

Doesn't mean Flutter or PWA's won't obsolete it eventually, and I'm optimistic
about Flutter's approach. Just saying that there's a reason RN is a thing.

~~~
polskibus
Could you elaborate what is the sweet spot for RN, when webview is not enough?

~~~
chrisco255
I think webview is rarely enough. If you already have React experience then
building React Native is only marginally more difficult than a web app but the
UX is much better.

------
finchisko
React Native will get rid of bridge costly serialization/deserialization for
crutial parts like animations very soon. See talk
[https://www.youtube.com/watch?v=UcqRXTriUVI](https://www.youtube.com/watch?v=UcqRXTriUVI)
If you had already invested in RN, i wouldn't jump to flutter and rather wait.
From what I read here on HN, even Android team is kind of skeptical about
flutter (but maybe they are also about RN, who knows).

What I personally don't like about flutter is that I have to learn new
language (which I cannot use anywhere else), ui components will never look
look same as native (specially visible when you would like to mix native part
of application with part written in flutter) and far less components and
libraries to choose from than RN.

But of course there are some benefits on flutter's side too. Article covers
that pretty much.

~~~
HappySweeney
The hot reload feature makes all the negatives seem trivial. I cannot stress
enough how much productivity improves when you can see your changes in less
than a second.

~~~
emp
[http://www.injectionforxcode.com](http://www.injectionforxcode.com) lets you
hot load swift/objc

~~~
saagarjha
Injection is a nice project, but it’s fundamentally limited to what the what
the Objective-C runtime allows.

------
alexhayes
> Debugging is not at its best.

I don't think the author correctly represents this functionality in flutter.

I've found the debugging of flutter apps inside Android Studio to be
excellent! You add a break point (by clicking on the lane to the left of your
code or hitting some keyboard shortcut) and execution will be stopped and you
can step through etc etc..

Using print statements to debug is slow and cumbersome, debugging in flutter
is not.

------
jillesvangurp
I'm a backend developer; so not much stake in this game. But honest question:
why does this need a relatively unknown and unloved language, i.e. Dart? I
mean Google just made a big commitment to Kotlin, which is awesome (using it
on the backend) and has lots of momentum, and does native compilation as well.
So what is up with Dart, aka yet another language not quite unlike swift,
java, javascript, c# and indeed kotlin? They've been pushing Dart for nearly a
decade and I've yet to meet a single developer specializing in it. I more or
less considered this completely dead, obsolete, irrelevant, and forgotten
until Google started talking about this flutter thing.

Why is this language needed at all? What's so good about this flutter thing
that it could not possibly be done with other languages (i.e. Kotlin) but must
have its own language (and associated tools, and other cruft).

I mean, I look at this and think: when is Google going to walk away from this
one (again)? Or did they already and just not bother to inform the poor people
behind it. It sort of fits in a long line of Google abandon ware. Call me
cynical but; really honestly: is this a last ditch attempt at getting Dart on
people's agenda or just plain and simple dead on arrival abandon ware.

~~~
Apocryphon
Technical reasoning for Dart: [https://hackernoon.com/why-flutter-uses-dart-
dd635a054ebf](https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf)

[https://flutter.io/docs/resources/faq#why-did-flutter-
choose...](https://flutter.io/docs/resources/faq#why-did-flutter-choose-to-
use-dart)

As for having to learn another language- Dart seems simple and boringly
conventional enough to pick up. And it's not as if there isn't ample
precedence for mobile engineers having to learn a niche language to make apps.
How many Swift, Kotlin, or Objective-C uses are there outside of mobile apps
right now? How many servers are running Vapor? How many programs are using
Kotlin/Native?

Which isn't a knock on those projects. Like Flutter, they're all relatively
new endeavors using fairly new languages. And so, Dart might not be used as
much yet, as it's not the native language of choice, and Google's attempts to
promote it in web haven't caught on, but low adoption at the beginning doesn't
mean it's fundamentally unsound.

------
saurik
I have been doing a _lot_ of research recently on Flutter, and sadly there are
a lot of "little things" that end up feeling like showstoppers, at least if
you want to support iOS, that all stem from a combination of its premise (to
reimplement all of the UI) and its focus (which seems to be Android first).
Here are a few examples that mattered to me: the keyboard input has tons of
open issues that make it seem unusable (and what app doesn't need good text
input...), taking photos with the camera picker apparently strips all of the
EXIF data (which means the photo is going to show up in the wrong orientation
with the wrong gamma, and so look totally broken), and despite constantly
reading "they spent a ton of time making the accessibility work", if you
actually glance through their issue tracker there are lots of accessibility
issues that would seem to be serious problems for users relying on VoiceOver
(and then of course, there are tons of accessibility features on iOS that are
for people with other disabilities, and pretty much none of them are
implemented at all for Flutter as these are all subtle changes to the native
controls, each of which they are slowly reimplementing).

[https://github.com/flutter/flutter/issues/12920](https://github.com/flutter/flutter/issues/12920)
[https://github.com/flutter/flutter/issues/9507](https://github.com/flutter/flutter/issues/9507)
[https://github.com/flutter/flutter/issues/20693](https://github.com/flutter/flutter/issues/20693)

[https://github.com/flutter/flutter/issues/24575](https://github.com/flutter/flutter/issues/24575)
[https://github.com/flutter/flutter/issues/24574](https://github.com/flutter/flutter/issues/24574)
[https://github.com/flutter/flutter/issues/18391](https://github.com/flutter/flutter/issues/18391)

[https://github.com/flutter/flutter/issues/1668](https://github.com/flutter/flutter/issues/1668)
[https://github.com/flutter/flutter/issues/14543](https://github.com/flutter/flutter/issues/14543)

[https://github.com/flutter/flutter/issues/4830](https://github.com/flutter/flutter/issues/4830)
[https://github.com/flutter/flutter/issues/4827](https://github.com/flutter/flutter/issues/4827)
[https://github.com/flutter/flutter/issues/4826](https://github.com/flutter/flutter/issues/4826)

And like... there are even serious issues on Android, stemming from a massive
argument about how the core developers of Flutter don't want to support
synchronous callbacks into the Dart isolate even though there are tons of
Android lifecycle APIs that fundamentally require synchronous delegates :/.
This issue is so serious that it supposedly makes Flutter entirely unusable on
many Android devices, as it can't react to memory pressure requests (which
means activities get destroyed) but _also_ is unable to implement the
save/restore state mechanism (so views come back either in subtly wrong ways
or even entirely broken); and so people have been reporting that it is
literally impossible to use the photo picker on smaller Android devices (as
that is a widget that deterministically causes memory pressure).

[https://github.com/flutter/flutter/issues/6827](https://github.com/flutter/flutter/issues/6827)
(opened Nov _2016_ )
[https://github.com/flutter/engine/pull/4358](https://github.com/flutter/engine/pull/4358)
("closed" due to being rejected)

[https://github.com/flutter/flutter/issues/15479](https://github.com/flutter/flutter/issues/15479)
[https://github.com/flutter/flutter/issues/15478](https://github.com/flutter/flutter/issues/15478)
[https://github.com/flutter/flutter/issues/15476](https://github.com/flutter/flutter/issues/15476)

[https://github.com/flutter/flutter/issues/21102](https://github.com/flutter/flutter/issues/21102)
[https://github.com/flutter/flutter/issues/18059](https://github.com/flutter/flutter/issues/18059)
[https://github.com/flutter/flutter/issues/17186](https://github.com/flutter/flutter/issues/17186)

[https://github.com/flutter/flutter/issues/17165](https://github.com/flutter/flutter/issues/17165)
[https://github.com/flutter/flutter/issues/18700](https://github.com/flutter/flutter/issues/18700)
[https://github.com/flutter/flutter/issues/17950](https://github.com/flutter/flutter/issues/17950)

Essentially, I highly encourage anyone attempting to use pretty much anything
to sit around and read through the open issues and look at what is currently
being built vs. what is still on the roadmap, as the marketing messages behind
a lot of these projects might say "we now support so many more iOS controls
and it is amazing" while the reality on the ground is that the controls they
have might only sort of work and the things that you need might not only not
yet be done but might be on the list of things that the project has some
philosophical aversion to (which is the case with the Android issues there: if
any of those things will cause you a problem, you might be waiting for years
to see fixes for them, as the obvious fix was rejected).

~~~
p2detar
Thank you! I did an hour and a half of reading last night on these. Especially
on
[https://github.com/flutter/engine/pull/4358](https://github.com/flutter/engine/pull/4358).
Very, very interesting and certainly put me on a watch out about Flutter.

Also, this should really be a top comment.

~~~
chickenfries
Man, this issue is really damning.

------
pcwalton
Note that the truth is more complicated than that "Skia is the graphics engine
for Mozilla Firefox". Firefox does use Skia on many platforms right now, but
on Windows (by far the most popular platform) Direct2D is mostly used instead.
Moreover, at the moment we're in the process of switching to WebRender, which
represents an approach quite different from legacy APIs like Skia.

~~~
rofrol
comment in wrong place?

~~~
PaulBGD_
No, the article mentions that Skia is used in multiple web browsers.

> through a fast C++ 2D graphics library called Skia (which also serves as the
> graphics engine for Google Chrome, Chrome OS, Android, Mozilla Firefox and
> Firefox OS, and many other products).

------
pier25
Flutter has a lot of potential. If Google also officially supported macOS and
Windows (even without the native components) it would be amazing.

~~~
MarkMc
I'm working on just such a project:

[https://feather-apps.com/](https://feather-apps.com/)

(although it's not officially supported by Google)

~~~
MartianSquirrel
Is this Open-sourced? looking at the website it doesn't seem like it

~~~
MarkMc
No the code we write is mostly closed-source, but it is based on this open-
source project: [https://github.com/google/flutter-desktop-
embedding](https://github.com/google/flutter-desktop-embedding)

~~~
sunsetMurk
do you plan on open sourcing? what are your plans?

~~~
MarkMc
No, it's a commercial product. At some point we will charge a fee to publish
apps on our platform.

------
talkingtab
The down sides for me for me are Dart - no thanks to learning another
language, and to Google lock in. As others have pointed out, Google has a
pattern of developing and then abandoning products and technology. See
[https://gcemetery.co/](https://gcemetery.co/)

~~~
marcobellinaso
It's a good language though, and if you have experience with
C#/Swift/Kotlin/Java etc...you'll be productive from day 1...there's not
really much to learn, I wouldn't call it a problem.

~~~
brianpgordon
Did you just say that Dart is a good language? You're aware of the memes about
Dart's type system being completely broken _by design_ right?

[https://www.dartlang.org/faq#q-why-are-generics-
covariant](https://www.dartlang.org/faq#q-why-are-generics-covariant)

Of course this is from the company that brought us interface{} and people seem
to be OK with that...

~~~
kiriakasis
I gather that you would prefer invariant generics. I know a bit about type
systems but very little about subtyping so I would really enjoy some
information :)

Why are covariant generics bad? (also just a link is fine)

~~~
brianpgordon
Invariant generics would at least let you rely on the type system doing its
job correctly. But even better would be to annotate each type parameter as
covariant, contravariant, or invariant - this is what Scala and C# and
probably a bunch of other languages do.

As an example, here's approximately how the Function trait is defined in
Scala. The square brackets indicate type parameters (like angle brackets in
Java), the - indicates covariance, and the + indicates contravariance.

    
    
      trait Function1[-T, +R] {
          def apply(arg1: T): R
      }

------
alexhayes
Another thing I'd point out is that the flutter widgets themself have perhaps
the most extensive, and useful, documentation in code I've come across. If
you're using an editor that let's you "click through" into the thing you're
calling then it's almost all the documentation you need!

------
paul_h
Co-creator of Selenum 1.0 checking in. My part of the 2004 Selenium was the
wire protocol that allowed one process (the Java/Ruby/C#/Python test runner)
to control the other (the browser). In so doing implemented a rudimentary
COMET protocol, as it happens.

Anyway, FlutterDriver is pretty frickin limited. Its like Selenium-RC without
the XPath. Thank Turing that Simon Stewart and WebDriver came along and did a
reverse takeover of Selenium. Selenium on my MacBookAir for perfected build
toolchains can zip along at 3-5 tests as second with the browser open and you
being able to roughly see what it is doing. Not 3-5 clicks a second, 3-5 tests
a second.

FlutterDriver, by contrast is 5x slower. And even then that's only after the
APK has been shoved into the emulator which can be minutes on my MBA. It
__feels __to me like the FlutterDriver tests are being added to the APK being
sent to the emulator, and then phoning home with minimal output of the run
(not withstanding the ability to attach a debugger). There 's no doubt that
the better solution would be to open a socket to the host OS's test-runner
process and chat back and forth about direction of the testing. If needs be,
that shitty Selenium-RC COMETalike way , but there's no reason a whole bunch
of telemetry couldn't be traded too if a BEEPlike protocol were developed. And
the running process shouldn't be constrained to Dart. Some teams will want
their test runner logic in another 3GL like Python.

Then there's the lack of reflection. I may agree that production apps may want
to explicitly turn off reflection in order to be more efficient. But for test-
automation purposes it is great (e.g. Gherkin), and it would be nice of there
were some effort to publish patterns and set policy that would allow that way
of working to be lasting.

Also, Apple are way ahead with a simulator for iOS and the XCode toolchain
that's so much faster for testing considerations. Faster than a reliance on
QEMU - at lest on busy 8GB machines. I bought a Mac Mini two days ago, mostly
because of Flutter really, but general bloat too.

~~~
Hixie
It's totally fair to say that flutter_driver isn't a great experience today.
The reality is that you hardly ever need to use it, though, because you can do
pretty much everything you want using unit tests (including doing golden file
tests). We mostly only use driver tests for on-device benchmarks.

------
misiti3780
Is react native really on it's way out ? I was about to start a new expo
project and invest some time in building something i plan to stick in the
google app store.

~~~
jchw
I think React Native is still a good choice, for now; lots of apps use it, and
it can allow you to share JS code between mobile apps and web apps. I'd still
personally recommend checking flutter out though, it makes for some buttery
smooth apps.

------
virmundi
I know the article says that mostly techies will care, but has there ever been
research into seeing if normal users care about native? When I look at many
apps on the market, they are so heavily themed that the nativeness is hard to
find. When I worked with Ionic one of the issues was how jarring it would be
for people in iOS. Has anyone seen this concern become a reality?

~~~
WA
Normal people don’t know the difference and even experienced people can be
fooled.

Anecdote: I have an Ionic app that is used by 15,000 people daily. It looks
like a native app. Nobody ever wrote me an email that the app is not native,
not fast enough or anything else. Normal people want to get their shit done
and move on.

Heck, one user apparently was a dev and came up with a suggestion (enable
keyboard suggestions for text input fields) and he wrote me specifically which
iOS UI element I should choose over some other element he thought I was using.
I replied: thanks, but this is an Ionic app, it doesn’t use native iOS
elements ;)

Native apps are totally overrated imho, unless you make heavy use of fine-
grained input controls. Here, Ionic does have its limits. You can’t control
the keyboard properly for example, unless you wire in some Cordova plugins.

Oh and JS doesn’t run in the background. This can cause issues if you do a lot
of background processing.

But performance is not much of an issue anymore in 2018 and Ionic is the most
polished web-based framework that is tough to distinguish from native apps.

~~~
yesimahuman
(Ionic CEO here) Thanks for the response and sharing your experience. I also
have not heard any feedback that iOS users find Ionic's iOS styles jarring.
Ionic is also meant to be customized and branded quite a bit, so stock native
style isn't really what we're after anyways.

A priority for us in 2019 is making keyboard and background processing easier!

~~~
virmundi
I phrased that poorly. I personally liked the look of Ionic. I read Medium
post after Medium post while researching telling me I'm crazy to use Ionic
since iOS people pay for apps and demand native appearance.

~~~
yesimahuman
Interesting, well considering even a side menu isn’t official Apple UI that
might be a case of native engineers projecting their own opinions on
developers. Hard to say

------
GenericsMotors
My main problem with using anything from Google is that I work on projects
that may end up in production for years, and Google's history of playing fast
and loose with (or shit-canning) the frameworks it develops doesn't inspire
much confidence.

Fortunately for me UI dev isn't my primary role.

~~~
eeZah7Ux
Tell that to the Go crowd :(

~~~
bsaul
I’m not sure i understand your comment : do you think go is going to be cut
off by google anytime soon ??

~~~
eeZah7Ux
"cut off ... soon" is an exaggeration and not what I've said. I've been around
a while and seen many languages and products being developed and hyped up by
one company for 5, 10, 15 years and then bent out of shape, or sold out, or
being put on life support. Sometimes when the company wants to push a new,
competing product, often times their priorities change and they stop focusing
on the needs of the developer community.

------
d0100
If Flutter was js + jsx I'd jump right in.

~~~
marcobellinaso
Funny...one of the reasons I like it (and prefer it over RN) is that it
doesn't use JS :)

------
hardwaresofton
BTW, for those looking for another option other than Flutter and React Native,
check out NativeScript[0], or Nativescript-Vue[1].

Nativescript is different from react native because it includes a native call
translation layer -- you can write JS that actually uses native runtime
objects. It's also got excellent support for cross platform applications that
reach down to native on both platforms, and can meld right in with a fully
native app as well, and is thoroughly F/OSS (they take the marketplace
approach to monetization).

Nativescript different from Flutter in that it has nothing to do with the
tirefire that is Dart. Nativescript is OSS and is taking the marketplace
approach to capitalizing and recently they got Hot Module Reloading as a
result of integrating more closely with webpack/other capable bundlers.

I've recently done projects (one larger client app, another a small personal
project) in both and kept some notes on what I liked about Nativescript vs
Flutter (I'm pretty biased for Nativescript now), not sure if I'll make a blog
post about it but here are some hopefully interesting points:

\- Performance tradeoffs are roughly the same for dart vs nativescript, do
hard work in an isolate (dart) or webworker(nativescript)

\- Flutter's reactivity is 10x more tedious than Nativescript-Vue. Making an
entire other class and doing all these overrides for what should be a basic
feature is pretty ridiculous, though everyone's fine with it because they just
right click in their $IDE.

\- Flutter's data management is not great -- everything they've made so far
seems like a hack. I'm uncomfortable with the build function being on the
state object conceptually, InheritedWidgets are just using context as a grab-
bag, the BLoC pattern is so complicated.

\- State<MyPage> & StatefulWidget being separate classes and the State<MyPage>
having the build function unsettles me. I don't know if it had to be this way
because of dart 2's type system (which is subpar in my experience, Typescript
is better because it at least offers duck-typed interfaces)

\- Dart is terrible. It is a modern language yet it lacks almost none of the
advances of modern languages, Dart 2 was a near rewrite and it it still
manages to be less compelling than Typescript, and nowhere near languages like
Go, Rust, Crystal, etc. I am kind of suspicious google is pushing this
language just because they invented it and can control it -- I don't know a
single redeeming quality of dart, especially if you consider dart 1 before you
consider dart 2.

\- Flutter subtly forces you into either Material Design or Cupertino -- this
surprised me. Flutter subtly pushes you towards material design, which I have
no interest in, and I think most people actually trying to create unique app
experiences wouldn't either. This is a double edged sword, in Nativescript you
have to seek out native-looking components, but in Flutter they're forced upon
you especially at the beginning, and I prefer the former.

\- Automatic sending of crash logs to Google -- who thought this was a good
idea? And to make it opt-out instead of opt-in?

\- Flutter probably has the better longer term viability because it's being
embedded into Fuschia and other things google is doing.

\- I expect Nativescript to eventually take on WASM and _really_ open up the
choices for languages to use with it.

[0]: [https://docs.nativescript.org](https://docs.nativescript.org)

[1]: [https://nativescript-vue.org/](https://nativescript-vue.org/)

~~~
Hixie
We definitely don't intend to push you into Material... can you elaborate on
that? What would we have to change for you to think we were not pushing you
into Material?

Regarding the crash logs, it has definitely helped us improve stability. We do
try hard to notify you that it's happening. It's opt-out because people don't
tend to opt in to that kind of thing and so the data would be more or less
useless (not representative of real usage) if we made it opt-in.

~~~
hardwaresofton
Sorry for the delay in response, I didn't see this. I think the problem is
kind of endemic -- it's kind of like all the documentation and everything
always _starts_ from a Material component. Like if you look at provided
scaffolds and you see CupertinoScaffold in the Widget Index[0], you might
expect MaterialScaffold to be an option as well, but it's just "Scaffold".
Little things like this indicate that you expect "MaterialScaffold" to be the
default resting state. 99% of the time when I'm writing an app I have the
design already and it may or may not be in material style or Cupertino style
-- I personally would expect a framework to offer general tools first then the
specializations. There are a bunch of other example of components that only
really work correctly in the Material context. It's not a _huge_ thing, and
Google _does_ have a pony in the race (which makes it easier for me to
tinfoilhat about it), you have every right to push material as the
default/make it easier to work with -- but I enjoy not having any such bias
with Nativescript, even if it costs me slightly more work to get components
that are stylistically coherent with either paradigm.

From an engineering standpoint I absolutely understand the automatic crash
logging, it's good that you're able to get the user data. I think you guys are
just fine as I'm more tinfoil-hatty than 99% of the usual developer will ever
be -- the average developer won't care. I don't know realistically how it
could be improved without sacrificing that useful data, but maybe a notice @
install time? I just never saw any mention (I read through the docs, watched
lots of video), and was surprised -- maybe the negative impression was
amplified because I was having issues with flutter at the time. My
thought/reaction at the time was that "Oh so a weird crash _and_ you're
sending the details back without me explicitly allowing it? classic google".

To wrap this up, I do want to thank you (I'm assuming you're on the flutter
team) for the hard work -- drawing every pixel and building a composable,
considered system to do that is _very_ hard, and you've expanded the mobile
development landscape, Flutter is unique in it's approach AFAIK, and I mention
it any time I talk about the mobile dev continuum. Building flexibly to
support multiple embedders is awesome and I'm sure flutter will go far.

[0]:
[https://flutter.io/docs/reference/widgets](https://flutter.io/docs/reference/widgets)

------
bonsai80
Does Flutter (and related tooling) offer anything to push small code changes
out to devices without doing a full version update to the app stores (similar
to what can be done with React Native)?

~~~
judge2020
Flutter is compiled to native ARM code, and as such doesn't allow this
functionality. This exact limitation is mentioned in the article.

------
convery
Any idea about how well Flutter would integrate with C/C++? As in, using
Flutter for the UI and having callbacks to C++.

~~~
pjmlp
Flutter is built on top of Skia, so there is some kind of integration there.

------
matchbok
In my experience these cross-platform tools (Flutter/RN) have such a limited
use-case that they are rarely worth it. Even basic stuff (navigation) require
huge amateur libraries that barely work. Couple that with the dumpster fire
that is javascript and it's a recipe for disaster.

~~~
matt2000
Flutter doesn't use javascript.

~~~
HappySweeney
Nor do you need any libraries for navigation.

------
supergilbert
Still waiting for Kotlin to be the 1-stop shop for app development.

------
bad_user
Serious question: why do people, software developers actually, use Medium for
blogging?

\- they nag mobile users to install a shitty app "optimized for readers"
because apparently the browser is no longer suitable for freaking blogs

\- they nag desktop users to login

\- they are in fact not GDPR compliant

\- the downloaded pages are huge, the browser ends up downloading and
interpreting over 2 megabytes of crap in order to display 3 paragraphs of text

\- the domain name isn't yours so you can lose your content and your identity
and it isn't easy to port to other platforms

Why do you put up with this shit?

I have a blog built with a static site generator since 2008, with minimal
maintenance and costs required, on my own domain, with changes tracked in
Github. My blog is at this point at least 4 years older than all Medium
accounts and will probably outlast Medium.

This may not be for your grandmother, but you're a software developer and the
setup would take you one day of work. It actually takes more than that to
write a good article.

~~~
levosmetalo
> Serious question: why do people, software developers actually, use Medium
> for blogging?

Serious question: why first comment on HN have to be totally unrelated to the
fine article?

Do we really need to discuss medium issues every time a blog post entry is
posted here, instead of discussing the post itself.

Serious question 2: Why don't you write a blog post about "Using Medium for
blogging" on your own static self-hosted blog, and put a link here for
discussing it?

~~~
apl002
thank you for saying that. so annoying

