
Flutter and Dart, or how to quickly build a mobile app without losing your hair - witek1902
https://altkomsoftware.pl/blog/flutter-dart-quickly-build-mobile-app-without-losing-much-hair/
======
dragonsh
I think Flutter now can survive without google. It has enough developer
momentum behind it and it’s unlike react native a bolt on solution to somehow
make it work. It might fit Facebook’s case (although they abandoned it
themselves in favour of native speaks volumes about it).

But I think keeping in sync changes in API, hardware device drivers and new
interactions across different platforms and device will still be nightmare and
in general it will play catch up with native. It can be seen in the number of
issues opened on flutter project on GitHub [1]. Hopefully there is some
support from different platforms so it remains reasonable choice and perform
well compared to native.

Also it’s declarative UI paradigm is good and even SwiftUI is doing the same.

I had concern about this project earlier although personally I looked at Dart
just because it’s developed by Lara Bak the person who transformed google by
giving them V8 engine in chrome. Earlier dart could not take off because no
one wants dartvm in browsers except chrome.

It might not have succeeded in replacing JS from browser but Flutter is dart’s
killer platform and it is very much focused now on becoming a language focused
on user interface programming. So I think dart will survive beyond google.

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

~~~
pjmlp
Everyone from original Dart team left, Lars is now one of co-founders of a
startup trying to sell a Dart like language for IoT.

Dart and Flutter futures are are now married, and I still don't buy into
Flutter.

Languages married with UI frameworks seldom last, specially when the
competition outside of the UI framework is so much better in tooling and
available set of libraries.

Plus hot reloading were a novelty when Smalltalk, Common Lisp, Oberon System,
Eiffel got introduced into the market.

And the competition isn't sleeping either, Flutter touched the Android team
nerves hard enough that now we are getting Jetpack Composer, Xamarin already
has its prototype available, Qt always kind of had it, so in the next twos
(give or take it), all the cross-platform mobile frameworks will have dynamic
code reload, with more market relevant languages, couple with 20 - 30 years of
libraries.

Until Google releases Fuchsia and makes everyone write Dart code, I will pass.
Qt, Xamarin, PWAs do the job just fine, with more mature languages.

~~~
dragonsh
It’s good to have multiple choices, but given the momentum and quality of apps
developed using Flutter, I think it’s ahead and will have enough developers to
keep it relevant and stay.

Also UI programming is very complex given the proliferation of device form
factors, interaction and implicit inputs using sensors. It needs language
especially designed to handle all of it and provide a smooth user experience.
For end user UI is the whole system. Dart is especially designed for it.

It provides superior developer experience compared to other cross platform UI
toolkit. I think a language designed for user interface programming providing
clean, smooth and performant developer experience is a need which dart fill.

Obviously not everyone likes declarative UI programming and they will lean
towards what they know. I am from the camp who prefer declarative UI’s and
that’s the reason like SwiftUI and Flutter.

~~~
raydev
What are some examples of quality apps made with Flutter on iOS?

------
Barrin92
My personal experience with it was as someone who had never developed for
mobile or the web before, and I have to say I really appreciated it.

Dart itself is very simple to pick up basically as you write. It feels like
the most generic 'algol family' language imaginable, in a good way.

The widgets itself that the framework provides are very complete and make
inuitive sense. This was a big differentiator for me compared to my modest
experiences with react a while ago.

As someone who doesn't live in the world of UI and end-user software at all
react was not easy for me because I had to learn javascript and css and html
and so on. When the last thing you've built UI wise is Java desktop apps ten
years ago that's not easy. Flutter felt much more like a traditional desktop
framework in how high-level and complete it is.

------
h8hawk
I've worked on Dart and Flutter last year on a startupish project. I can say
flutter is amazing. It got good ideas from react architecture (eg: managing
state and declarative UI) and add many good things like very rich and well
designed API. writing UI in language and without other markup language like
XML is amazing. You also save a lot of cost to developing in parallel for
multiple platform's. Dart is also a pleasant language, here are some pros and
cons about language.

pros:

1- Everything is object. (no more inconsistencies like Java primitives, null
and generics)

2- It has very well designed generics and you can access generic type in run
time.

3- Good Type inference.

4- Has powerful facilities for asynchronous programming.(eg: async await,
coroutines ,...)

5- Not overall bad or complex type system. Compare to Golang or java dart's
type system is vastly superior.

some cons:

1- Everything can be null (null is also object).

2- Lack of Union and algebraic data types.

3- Lack of python's like tuple.(eg: (1,'string'))

4- I personally dislike C-style type definition and mandatory semicolon (eg:
int foo=23; rather than foo : int=23 )

~~~
thosakwe
As for nulls, non-nullability is currently in the works:
[https://github.com/dart-
lang/language/blob/master/accepted/f...](https://github.com/dart-
lang/language/blob/master/accepted/future-releases/nnbd/feature-
specification.md)

~~~
slimsag
serious question: how effectively can things like non-nullability be bolted
onto a language after it and a large part of its ecosystem has been created?

I see the plan to allow libraries to opt-in and migrate that way.. but I
wonder how long that migration will take and if it will ever actually be
completed?

------
RcouF1uZ4gsC
> Secondly (and this can be seen as both a flaw and an advantage), both
> Flutter and Dart come from Google. The good part of it is that Google is a
> tech giant, and if they want to maintain something, they have the resources
> and manpower to do it. The bad part is that while Google is known to
> introduce useful tech and services, it’s also known to kill off or retire
> them when they’re deemed obsolete.

I think over time the crippling of Google’s developer initiatives because of
this perception will cost a lot more than all the money saved from all the
retired services.

~~~
wstrange
I think the risk of Flutter getting cancelled is very remote. Google knows
they have a winner on their hands.

Flutter is the UI framework for Fuschia. It is picking up huge momentum [1].
The support for native apps and web[2] is still immature, but promising.

Flutter brings the joy back into UI development. No messing with CSS, tables,
etc. - "everything is a widget" makes for a very composable framework that is
super fun to use.

[1] [https://redmonk.com/sogrady/2020/02/28/language-
rankings-1-2...](https://redmonk.com/sogrady/2020/02/28/language-
rankings-1-20/) [2] [https://flutter.dev/web](https://flutter.dev/web)

~~~
mkl
I don't see any reason Google wouldn't cancel Fuchsia at a moment's notice.
It's been consuming their resources for years and is far from launching in a
product, and Google happily cancels even established well-used products.

~~~
SlowRobotAhead
I don’t know why people tried to hide your post. Yes, it’s entirely plausible
that Fuchsia is killed in favor of Android evolution not revolution.

Plausible, but i wouldn’t put odds on anything.

LUCKILY, for me because i really like Flutter, I think it hits critical mass
soon and wouldn’t matter if Google killed Fuchsia.

~~~
rvz
You both say this but the interesting thing is that Fuchsia support is
creeping up in more essential low level software like LLVM, Rust, WebKit and
the devs actually have Chrome already running on the platform for years.
Dart/Flutter is used throughout the OS and used in many apps today.

From day 0 on launch, you can expect Fuchsia to run your Dart apps and to run
existing Android apps via a tool called Machina (Zircon hypervisor running
Linux kernel). If Fuchsia benefits from the Flutter apps being made and gives
Google more complete control over the OS unlike Android, then it looks highly
unlikely that it will be killed.

In reality as Fuchsia is being ’dog-fooded’ on Google devices it is
increasingly likely that Android will be killed.

~~~
pjmlp
The fact that ChromeOS had to gain Android support speaks loudly about what
might win in the end.

If Fuchsia ever gets released, I bet ART will replace Flutter.

It is already being ported to run on Fuchsia anyway.

~~~
LordDragonfang
ART isn't a UI framework, it can't "replace" Flutter. You can run Flutter apps
in ART, the article even talks about doing so.

~~~
pjmlp
Indeed it the basis of the Android stack, so it plugs naturally with
everything written in Java and Kotlin for Android.

Flutter has zero relationship with ART, it just plugs into Android via the
NDK, like anyone else using C++ code.

------
mqus
I tried out flutter in the past few weeks and it seems really great,
especially compared to the android framework. Dart also seems to fit in really
well.

But I do have some criticism for dart. While it's nice that they moved to a
static types, they still made _every single type_ nullable. So e.g. if you get
a boolean in your function, be aware that it can be true, false and also null.
I have my problems with java having nullable objects, but having the
primitives also be nullable?

Well, I'm pretty much a beginner, so maybe there are better ways and I still
don't know them. But afaik, they weren't mentioned in the brief Dart intro on
the flutter page.

Dart does also have some cool things, though: Extensions (for adding
interfaces to existing types), explicit getters, async/await and lots of
syntactic sugar. Building your widget-tree in dart sometimes looks like a
declarative style similar to xml, but far more concise, except that it's
really imperative, which is really cool. No long

Component a = new Component();

a.setOnClickHandler(xyz);

a.setColor("green");

b.add(a);

chains anymore!

~~~
wstrange
> they still made every single type nullable

NNBD is almost here: [https://github.com/dart-
lang/language/blob/master/accepted/f...](https://github.com/dart-
lang/language/blob/master/accepted/future-releases/nnbd/feature-
specification.md)

------
tarkin2
I tried Flutter a year or two ago after coding Android and iOS apps (to a
lesser extent) for years and years.

The dev experience was lightyears ahead of Android. Dart was nice fit. I came
upon some edge-cases where Flutter's API seemed immature. But as far as
quickly getting apps/prototypes out there, there was no competition.

My main roadblock: the UI was centered around Material design. To use the iOS
widgets, which looked good, it seemed you need to put a load of if statements
to use the iOS widgets instead - and this felt hugely cludgey.

I'll reiterate what another poster said: if your business depends on apps, go
native. Flutter will get you to 90 or 95% really quickly but it's probably
that 5% that gives you an edge.

I'd use Flutter when apps are of secondary importance to the business, and
when we need an iOS and Android app, and I want it done without spending huge
amounts of effort.

------
cletus
So this article [1] matches my own recollection. Like many projects that
originate from Google, it always struck me as a solution looking for a
problem.

The first "problem" was Javscript.

At one presentation about this I recall that Lars Bak (IIRC) took quite a
beating about DArt, just in terms of the questions asked, to the point that
someone had to point out just how much he'd accomplished (ie V8). This was, in
essence, an appeal to authority.

I recall the Ads PA basically stepping in to save the project. I can only
speculate why but my best guess is the AdWords TL woke up one day and decided
to rewrite AdWords in Dart (as he allegedly had with GWT some years before).
But all that's pure speculation.

The second "problem" that Dart solved was using the same code on client and
server, something Google is inexplicably obsessed with (eg GWT). I don't know
what caveats came with Dart but GWT had plenty (eg for many years it wasn't
possible to use the same protobuf classes on client and server).

I believe the intent with Dart was, at one point, to run natively within
Chrome (the article mentions Dartium). This worked out really well for
vbscript. No one wants to write different languages for different browsers.
Again, I speculate here, but my strong suspicion is the Chrome team killed the
idea of shipping a Dart VM in Chrome and that was the end of that.

Maybe it's just me but TypeScript just seemed far more sane.

So... Flutter. I don't know why a UI library needs to be language-specific but
it strikes me as a bad idea. Now, the counterpoint is that Flutter is an SDK
And more akin to, say, React Native (albeit with significant architectural
differences) but I don't think it started that way.

:UI frameworks, libraries and SDKs just don't seem to be in Google's
wheelhouse (as opposed to, say, infra, which very much does). I can only
speculate as to why but my best guess is Google engineers (disclaimer:
Xoogler) can't see passed something as an engineering problem, so much so that
they take on philosophies no one asked for or needed (eg same code on client
and server), which come with a huge cost and no tangible benefits.

[1]: [https://insights.dice.com/2019/03/27/fall-rise-dart-
google-j...](https://insights.dice.com/2019/03/27/fall-rise-dart-google-
javascript-killer/)

~~~
Rury
Can't similar things be said for node.js and other tech? Electron apps
perhaps? What problems did these technologies solve?

Mostly I agree with you, but coming from desktop development, I also sometimes
feel like javascript and the web in general is a mess, and prefer things in a
familiar format. As so I don't find things like "DArt" or "Flutter" as
surprising...

~~~
cletus
> node.js

I don't have a strong opinion on Node.

> Electron apps perhaps?

Hate them with a passion.

> What problems did these technologies solve?

Node.js to is primarily a platform for high-concurrency event-driven request
handling where each request itself is a single thread. In my day job I
primarily write Hack (PHP) nowadays. PHP embraced this model years ago and I,
personally, think it's pretty much ideal for something most often used to
service HTTP requests. You almost never want to be in the business of starting
and coordinating threads. It gains you a lot of complexity and a lot more
failure modes for very little benefit over the single thread per request model
(combined with async/await programming, in particular).

Electron is, in my opinion, trash. It's a cheap and crappy way for people to
create desktop apps that have a much larger attack surface than any native
desktop app (being the entire Chrome runtime) and a huge memory footprint all
for the privilege of being able to use HTML/CSS to layout your app.

> and prefer things in a familiar format

So this explains a lot of the things you see from Google. Google engineers, in
general, look down on Javascript. There's actually a hierarchy. The C++
engineers look down on anything that isn't C++. Java engineers look down on
anything that isn't C++/Java (and sometimes even C++ is looked down on) and so
on.

A lot of Google JS is written for the Closure compiler. This was an early
effort to add type hints to JS code. If you look at the code you can tell it's
written by Java engineers. I like to quip that "Closure puts the Java into
Javascript". The JsDoc comment format is basically Javadoc. The type system is
familiar to those coming from Java.

So you have GWT, which seemed to appeal to people who though tit would allow
them to not need to know anything about JS [insert standard reference to the
Joel Spolsky's "leaky abstraction" essay].

Closure tries to remake JS into Java.

What these things tell you is the people coming up with these ideas don't
really understand Javascript and more to the point, they don't think they have
to nor do they want to.

> I also sometimes feel like javascript and the web in general is a mess

Everything is a mess if you look closely enough.

~~~
omnimus
Does Hack somehow add async to php (like swoole?). It seems to me that PHP and
Node are pretty different. PHP is thread per connection and no async, node is
just one single thread and you write as much async as you can. Pretty
different modes of thinking apply.

------
mmastrac
Using Dart in flutter feels like Google was trying to avoid tossing away a
bunch of pre-existing work by finding a purpose for it somewhere. It's Lars'
sorta Java, sorta Javascript personal project and it just doesn't have any
sort of design to it. Dart's failure in the web space showed that there wasn't
any real demand for it - it just wasn't better enough.

I realize they can't use Java, but this is a weird horse to tie themselves to.

~~~
sebe
They certainly did find a new purpose for Dart outside of it being used in
parts of their Ads platform, but Flutter, when is was the chrome experiment
called sky, first started out using Javascript.

The chrome guys decided to move on and look at several language before going
with Dart, Swift may have been an option, if it was opensource at the time.

Seems a reason for Dart's failure in the web space was mobile.

Lar gave a talk last year about his and Kasper iot startup
[https://www.toitware.com/](https://www.toitware.com/) he mentions why dart
didn't make it into chrome, saying "then the whole mobile shift happen and
there was no room for extra stuff in chrome"
[https://youtu.be/mPna6D21Eqg](https://youtu.be/mPna6D21Eqg)

------
tomduncalf
Is there a good example of a great, native feeling Flutter UI? I just
downloaded a couple of random “Flutter gallery” type Apps from the iOS App
Store and both of them have animations and text rendering that feel “wrong”
(and somewhat janky in the case of the animations).

This may reflect more on the development of those particular apps than the
framework though, hence my asking - in my experience, React Native does a
pretty good job of feeling “native” by default in most cases.

Not saying users would necessarily care so much, but I’m interested regardless
- I wonder if there have been any studies/anecdotes into how sensitive users
are to “details” like animation etc. in terms of engagement.

~~~
bsaul
that's the question i keep asking everytime there's a thread about flutter
being great, and so far i haven't received any answer.

my intuition is that flutter is used mostly for business apps made of forms
and lists, where expectation in terms of graphical performances are very low.

~~~
krzat
That's Xamarin. Flutter is better at implementing custom UI, like stuff that
can be seen on dribbble.

~~~
bsaul
and yet the UI performance of simple things like scrolling are a total
disaster.. how can you get anything fancy with those performance ?

------
divan
Flutter is the best thing that happened to the UI development in the last
decade or even two.

Before Flutter, if I needed to build a simple app (couple of screens and
network requests), there were no real option except of outsource it to the
mobile app development studio. After discovering Flutter I've built and
published my first app in 3 days while watching initial Flutter tutorials.

Since then, making mobile apps for my projects has become such a pleasant
experience, that I'm now trying Flutter Web as a substitute to the madness of
JS/HTML/CSS ecosystem, and I'm quite impressed with a result. It's still in
Beta, but the development experience is so much smoother.

At the same time, a lot people still don't know what Flutter even is, so
having it in your arsenal is a huge competitive advantage at the moment.

~~~
jiofih
> there were no real option

React Native, Xamarin, Ionic, and a ton more?

~~~
divan
All those solve the "two codebases" problem by piling levels of complexity one
on top of another. It's fire-sure way to make developers unhappy and code
unmaintainable in the long run.

React Native was the best shot in this market, but adding the worst UI
framework in the history of software – typesetting markup language (HTML), set
of global classes for styling with magic words like "!important" (CSS) and
hackish scripting language designed under pressure from Sun in 2 weeks (Mocha,
renamed to Javascript) - on top of the already complicated stacks yielded all
sorts of problems: from dependency management hell to unforgivably slow UI.
Even AirBnB – the largest React Native shop over there – abandoned it
altogether and returned to native iOS/Android development. My own experience
working with React Native project for 1.5 years (with ClojureScript added on
top for coolness) just reassured me that 5 layers of complexity is worse than
1 layer :)

Flutter design is so sick, that unless I'm writing own native plugins, I don't
even touch iOS/Android layers. So it's basically single layer of complexity
from the perspective of the developer and it's a game changer in this field.

~~~
jiofih
There is no HTML or CSS in react native. Are you sure you didn’t work with
plain React in a webview instead? I can’t even imagine trying to add another
compiler (ClojureScript) to its build process.

AirBnB abandoned it for other reasons - mostly difficulty integrating it with
_existing_ native codebases and developer pushback, without fully commuting to
it. MS Office, Shopify and a host of other products are fully invested now.

Flutter doesn’t have native UI, so I don’t think it compares well (or will
catch up for non-gaming/casual apps).

------
matt2000
HN: I won't use anything Google makes, they always shut stuff down. Also HN:
I'm all in on Go.

HN: Learn a new language every year, it's easy and worth it even the language
isn't useful for anything. Also HN: I won't learn a new language that would
allow me to double my mobile dev productivity because someone told me it was
bad 8 years ago.

~~~
detaro
It's almost as if HN is a community made of different people with different
opinions and not a singular entity.

~~~
libria
This isn't about who likes what, it's about inconsistent reasoning.

If Google creating a language is reason to believe it will die, why does that
apply to Dart and not Go?

This assumes you've observed the much higher popularity for Go and lack of it
for Dart here on HN (and most elsewhere).

~~~
nl
Go is used at a bunch of major companies outside Google. Dart is _only_ used
in Flutter (and apparently Fuchsia).

Dart overlaps in goals almost completely with Typescript which is heavily used
multiple teams within Google.

Switching Flutter to Typescript is something I could easily see happening if
Google wanted Flutter to be truly popular.

~~~
dragonwriter
> Dart overlaps in goals almost completely with Typescript

As I see it, that's not all that true.

Now, it's true, that it's non-native use competes with TypeScript in domain
and shares some implementation method details in that domain (e.g., both are
languages that rely on compilation to JS in the web domain), but the goals
clearly aren't the same. TypeScript's goals are basically limited to static
typing and source compatibility with modern JavaScript (that is, it is an goal
to be a typed superset of JS.)

Dart has a wide array of different goals, including being a typed replacement
for JS that is not limited in its other goals by being source-compatible with
JS.

------
askafriend
If mobile is at all _critical_ to your business, then you build in native -
period.

I think we've all learned at least that much in the past few years.

A lot of businesses either overestimate or underestimate their mobile product
needs because they don't understand the market or the platform. Expectations
for an interactive consumer mobile app (Ride-sharing, Social media, Photo
editing, etc) are extremely high and it would be foolish to under-invest or
try to take shortcuts. At the same time there are ton of businesses (Home
listings, Saas tools, Informational apps, etc) that would be well served by a
simple React Native app. Know which type of business you are.

~~~
yesimahuman
The plethora of companies building mission critical apps on platforms like
Ionic and React Native would stand to disprove this

~~~
sschueller
There are two new app only banks here in Switzerland and they both use a cross
platform framework. One for sure ionic. On Android these apps are absolute
garbage. They are slow to start, slow interaction and slow animation. One of
these apps has a main.js in it that has over 200k lines of crap with hundreds
of lines of if (ios) and if (android). All the iOS styles are packed in the
Android apk which is just stupid.

If these banks want to compete with revolut or transferwise they need to
provide an app that's isn't garbage.

~~~
nexuist
My local bank has a native app as far as I can tell and it regularly takes
over 10 seconds to get past the login page. My credit card (Discover) app
somehow won an award for best UX in the industry and _still_ takes over 5
seconds to log in (both of these are with Face ID by the way).

Contrast this to Robinhood, which jumps from cold boot to main screen in about
a second.

The problem is not the frameworks, it is poor development practices. Until the
big guys learn that outsourcing critical software is a stupid idea, the next
generation cool kid apps will continue to eat at their customer base (until
they become relevant enough to be bought out by the big guys, and the cycle
repeats).

------
3PS
Not super related to the article, but I had to get this off my chest. Suppose
you use VSCode on Windows to write a Flutter app targeting the Surface Duo. In
that case, you would be using a Microsoft editor running a Google SDK on a
Microsoft operating system, targeting a Microsoft distribution of a Google
operating system. We've not only come full circle, we've gone in loops.

------
sandGorgon
Over the past two weeks I have seen Shopify, Flipkart, Microsoft Office,
Coinbase and others officially throw their weight behind React Native.

I'm also seeing the Expo.io project (ready made starters for React Native)
mature to production quality extent.

At this point, I'm seeing a massive production scale behind React Native which
doesn't exist in the Flutter world.

Plus the elephant in the room - React. How do you compete against that ?
Incidentally, Flutter was inspired by React.

At this point, if I had to take a bet - React Native would win against Flutter
definitely. There will still be a massive Java/Kotlin userbase...but I don't
see why Flutter will exist in a even-Microsoft-Office-is-using-React-Native
world.

~~~
pjmlp
Microsoft is not only using React Native, they are the main contributors to
React Native on Windows and macOS.

React Native is also one of the reasons why WinUI core components are all
going to be C++, instead of a mix of C# and C++.

------
wruza
“Without losing your hair”

Future common data boilerplate. Qt/gtk-style app init boilerplate. Routing
boilerplate. Future builder boilerplate. Homepage title state boilerplate.
Setmapsfordicts boilerplate. DTOs. Widget scaffold. Step builder boilerplate.
New policy subject(?). Complex handwritten setters and validators.

How on earth is that not losing your hair? Can’t we just drop a list view, few
controls on a form, attach field formatters, and then write a simple
controller that implements a part of a table view delegate and a save method?
What’s wrong with modern ui?

~~~
scalatronn
You don't have to do that. you can write everything in one file if you want.
But when you introduce some architecture you always have some verbosity

------
hota_mazi
> The bad part is that while Google is known to introduce useful tech and
> services, it’s also known to kill off or retire them when they’re deemed
> obsolete.

Do you know any company that doesn't retire a product once it's deemed
obsolete?

~~~
ternaryoperator
Most enterprise IT vendor. IBM in particular will support obsolete products
for decades (e.g. OS/2). It's part of the reason managers feel comfortable
writing them big checks b/c they know that if they make a bet on the
technology they will still be able to get support many years later.

------
canada_dry
> You’ll find the complete app code here [1]

Leads to an empty repository.

[1] [https://github.com/asc-lab/personal-insurance-flutter-
poc](https://github.com/asc-lab/personal-insurance-flutter-poc)

~~~
witek1902
Yes, our mistake. Tomorrow we added full code to this repo.

------
zerubeus
Why Flutter over React Native can anyone answer this question?

~~~
gavinray
This is a complicated answer that would probably take experience developing
real-world applications in both to fully appreciate, but I`ll bite.

A few years ago, I was CTO of a small startup and spent a significant portion
of a year building out our mobile app in React Native.

I have experience building cross-platform mobile apps going all the way back
from when Ionic was called Apache PhoneGap and was an entirely different
product.

In my opinion, React Native is a classic case of follow-the-herd syndrome.
This is not to say that React Native is not a viable technology, but simply
that it just isn't very _good_. Let me dive into a few of the things that were
really grating when developing on RN:

\- The hot-reload times were painstakingly slow. I am talking about 15-20
seconds after save. This really takes a toll on development velocity.

\- You have a major decision to make when building an RN app: To use Expo or
not. Expo is an SDK which allows you to circumvent needing to drop down into
the native build processes for each platform and provides wrapper APIs for
accessing native hardware functionality on the phone, with the tradeoff being
that a wide number of RN libraries were not compatible since they required
being installed as Cocoa Pods or Gradle/Maven packages natively. So you are
trading convenience and development speed for flexibility. We chose to go with
Expo, and did not regret it.

\- Performance is an issue in RN that you need to aggressively optimize
against. I remember being aghast that rendering a scrollable list of 300 text
items caused so much lag and stuttering it required a full day of manual
optimization to calculate viewport area and which cells would be in view to
prevent that work from being done by the element on-thread in order to be
semi-usable. You have to be really cautious about your render cycles and
everything else when building views.

\- Doing heavy custom styling requires some hacky workarounds since RN wraps
the native UI elements and does not expose all of the style API that they
provide.

Later on, at another company, we ended up building an app with NativeScript +
Vue which was a much better experience. NativeScript is essentially React
Native, but allows you to use any JS/TS framework (or none at all) and has
much better APIs for interacting with the device, and allows you to fully
style the underlying device-specific UI element if you really need to. And the
performance ran circles around RN. The entire experience was overall miles
better. Very few people use NativeScript though, just due to the fact you
never hear about it.

Ultimately, if I had to give advice, it would be this:

Either write a regular PWA web app, so that you can leverage existing web
technologies and all the component libraries, and then add native
functionalities and publish to the app store using the Capacitor framework
that powers Ionic apps. Or just use Flutter.

Flutter has the only cross-platform mobile experience that does not feel
really hacky to me. It does not try to compile to platform-specific view
elements, instead compiling to native ARM code, and tries to maintain 120FPS.
You can use the same Flutter codebase to generate mobile, web, and desktop
apps. And the whole developer experience is really incredible. Instant
stateful hot-reloading, screaming performance. Google put a lot of effort and
thought into it, and Flutter is not going anywhere given that it powers all of
Fuschias UI.

~~~
antoniuschan99
When React Native started there was Appcelerator Titanium, Xamarin, and others
such as Qt and Rubymotion (Ionic was popular too but it’s considered webview).

We may be in Peak React right now as adoption is at an all time high vs
Angular and Vue. But tools such as Svelte and Flutter are the next thing that
has a chance to be competitive.

Flutter reminds me of Vue, loved by Developers but low adoption (compared to
React or Angular). At least Flutter is backed by a giant. Hopefully the
adoption rate keeps increasing.

------
Okawari
I work for a little web-development shop that does the occational app on the
side, mostly if an existing customer are interested in having one developed,
we don't employ any full time app developers. We have just decided to try out
flutter for our next app project. We are close to being done with the actual
app development, and it looks like we are going to be done way under budget,
so we are very happy with the technology as it currently is.

Before my time, we initially started app development using Cordova. It lined
up well with existing expertise in the office as that what we work with most
of the time. The apps turned out rather well except for reliability and
building. These are by contract applications, so we make them, release them
and don't revisit them unless we need to perform support on them. Changes in
the web browser, particularity on iOS has broken these apps on several
occasions where we have to go back and fix them. Some of these issues have
been expected, such as when iPhone X came to market, but sometimes an update
has broken something else, seemingly out of the blue.

We decided to try out some new technologies as we we're not too impressed with
Cordova and settled on Nativescript + Vue. Again due to expertise with vue as
it is one of the technologies we utilize a lot in web projects. Pretty much
all of the people who had been involved with the previous apps found it a
better experience than Cordova. But in my opinion, it was also quite
infuriating to work with. Hot module reloading never truly worked the way it
should, we often had to quit and reload the app for changes to be correctly
applied. It didn't end up as cross platform as initially thought. We had to
make a lot of platform specific components for things we initially didn't
think we had to, mostly because the shared options of components in their
standard libraries we're not as good as we had hoped. We ended up spending way
more time than initially thought wresling components into submission in order
to get close to the design we initially envisioned, and we ended up
compromising a lot on UI in order to make budget and deadlines. Performance
was also something I we had to optimize a lot more for than initially planned.
Animations and screen transitions would usually take a performance dive even
though our views were very simple and did not really have much data in them at
all. We struggled a lot to wrangle UI components into shape, hence why we felt
we had to make so many components. And we encountered issues with very simple
components such as images in list views not rendering if scrolled out then
back in from views.

For this next project I suggested we try flutter before committing more to
NativeScript, and we have seen immediate value from this technology over any
of the others we have tried.

* We spend way less time on platform specific code, the reusable pieces look more consistent across platforms which means we spend less time tweaking them for either iOS or Android. I think that flutter using its own rendering technique is a serious boon to us who are just making cross platform apps as cheap as possible.

* Any non standard UI component is often way less time consuming to develop in flutter as you don't have to write platform specific version of it. This has also let us cut down on external dependencies which we felt were necessary on Nativescript in order to implement some features in the allotted time available. This is something I think we will appreciate a lot over time, as NativeScript does not have the most active community and the potential work we will have to do to maintain components that may be abandoned by their original developer down the line.

* Tooling works a lot better for flutter. Hot module reloading actually works(most of the time). Statefulness and these reload is not as smooth. Actual breakpoints and debugging is very nice. We could get that with Nativescript too, but only in the javascript code, not for the templates which were written in XML. And if something went wrong on the "native" side, it would be like a black box to us which we could not truly inspect our way into. Flutter allows us to follow the stack deep into any widget.

* When you have to write native code for Flutter, you at least get the help of the tooling built for native platform development, as opposed to NativeScript where you declare that in javascript. It is very seldom needed for the kind of projects we've been doing however so I have no great insights here.

I'm very apathetic towards Dart as a language. It is entirely inoffensive. I
felt like I could work in it without even trying to learn it, and I think I
have spent at most an hour or two hours to look into and learn the more dart
specific language features. I am not that much of a fan of how to deal with
JSON data and the dynamic type in there. Dynamic feels a bit accident prone
but other than that, Dart as a language gets less on my nerves than some of
the more common and frankly way more tedious web related programming languages
I have to use daily for work.

As far as the kind of work we're doing, Flutter is great

------
loftyal
I wouldn't discount React Native. Microsoft and Shopify are now fully
committed to it, and Facebook is committed to fixing the architecture issues
that made Airbnb leave it in the first place.

[https://www.ideamotive.co/blog/what-to-expect-from-react-
nat...](https://www.ideamotive.co/blog/what-to-expect-from-react-native-
in-2020)

[https://reactnative.dev/blog/2019/06/12/react-native-open-
so...](https://reactnative.dev/blog/2019/06/12/react-native-open-source-
update)

------
fmakunbound
Do I need to use Dart in order to use Flutter?

~~~
pjmlp
Yes, Flutter is Skia + an UI framework written in Dart.

You can also get Skia + whatever you want and get your own "Flutter".

Currently they still have a better experience to sell regarding code
reloading, but competing frameworks are upping their game by adding similar
capabilities to their developer toolchains.

------
wstrange
Cached article:

[https://webcache.googleusercontent.com/search?q=cache:4HEVGP...](https://webcache.googleusercontent.com/search?q=cache:4HEVGPuxZ3kJ:https://altkomsoftware.pl/blog/flutter-
dart-quickly-build-mobile-app-without-losing-much-
hair/+&cd=2&hl=en&ct=clnk&gl=ca)

------
Razengan
If most of my focus is on Apple platforms (iOS, macOS, tvOS, watchOS, and
possibly soon the rumored arOS), I would rather pick SwiftUI over any other
framework.

Though at its early stage, as with all new Apple tech, you will still be
losing your hair. Hopefully there's only a few months to go until a
substantial increase in its stability (and documentation.)

~~~
izacus
The issue with SwiftUI is that you can't just have "most" of your focus on
Apple platforms. You need to have _all_ of the focus on Apple platforms
because you can't run it anywhere else.

With Flutter you have all of your focus on most of of the smartphone market
practically for free which makes a massive difference in your addressable
market.

------
nojvek
How does Flutter compare to React Native? I haven’t used either but previously
my go to framework was React Native since I have a ton of JS experience.

~~~
scalatronn
My React Native experience is very limited, but RN lacks of widgets. With
Flutter you get complete package of material and apple widgets to create UI.
Also RN is quite laggy on Android

------
vips7L
Outside of flutter, how it's darts performance compared to other languages?

------
meerita
I find Flutter and Dart horrendous for apps. So many lines of code, so many
things to check. I much preffer Swift approach or web approach is way more
interesting.

------
animalnewbie
How's xamarin? Anybody with experience here?

~~~
nmfisher
Buggy and unstable. I spent quite some time investigating Xamarin vs Flutter
for my app, and ended up choosing Flutter simply because Xamarin was so
unreliable.

No regrets whatsoever. There's no two ways about it - Flutter has already won
the battle.

In fact, it hasn't just won the battle, it's already sitting in a spa
celebrating its victory with bottles of champagne.

~~~
throwmeback
I had an opposite experience with Xamarin.Forms - I loved my time with it. A
deployed commercial app I made is in the stores for a year now.

No idea about Flutter though.

------
senthil_rajasek
This is a garbage software. I wasted 2 hrs installing / reinstalling this
trash and it was complaining about licenses.

Untested unstable software... Never going anywhere near this pile of shit.

~~~
senthil_rajasek
I am unfairly getting downvoted. I downloaded and installed this software and
spent hours to fix the errors.

Running flutter doctor is recommended in their "Getting Started" page to check
the sanity of the install.

But I kept getting the same "license status unknown" error after multiple
installs /uninstalls in various order.

Their GitHub issues page has this issue as closed.

If this is the state of a simple install I dread to venture any further into
actual development.

This will be a complete waste of developer's time and resources.

I am merely sharing my experience. Do not waste your time trying the flutter /
stutter / sputter.

~~~
sebe
If you're running windows, someone found this worked and allows them to run

flutter doctor --android-licenses

[https://github.com/flutter/flutter/issues/16025#issuecomment...](https://github.com/flutter/flutter/issues/16025#issuecomment-468958533)

If you just want to try out flutter, I wonder if you can avoid the android
stuff by just running on ios and when they are ready the desktop and the web.

~~~
senthil_rajasek
Thanks for your response.

Unfortunately, that solution is a dud. It does not work.

flutter doctor is looking for the sdkmanager in an outdated directory.

The point is not "googling" for fixes, the point is this software is not a
well maintained software if I have to spend hours to just "Get started..."

Developers, abandon this piece of crap.

Android sdkmanager tool not found
(%LOCALAPPDATA%\Android\Sdk\tools\bin\sdkmanager). Try re-installing or
updating your Android SDK, visit [https://flutter.dev/setup/#android-
setup](https://flutter.dev/setup/#android-setup) for detailed instructions.

------
hota_mazi
Dart

\- Is dynamically typed at the core

\- Has no support for nullability

\- Has old school syntax for constructors, semi colons

In other words, Dart on the wrong side of history for pretty much every single
important feature for programming languages in 2020.

Even C# looks more modern than Dart from a design perspective, and C# is
fifteen years old.

~~~
brabel
\- Dart 2 has a sound type system and the compiler has been receiving lots of
optimisations based on types since then (several years now). So this is no
longer true.

\- that's currently true but in the next release (at least that's what the
Dart team have been working on for the past several months) it will have
nullable types just like Kotlin.

\- That's a strange criticism. Dart has excellent constructor syntax, I don't
know a language that is more flexible with constructors.

e.g.

    
    
        class Person {
            String name;
            int age;
            Person(this.name, this.age);
            String toString() => "Person($name, $age)";
        }
    
        main() => print(Person("Joe", 40));
    

Looks pretty good compared to most other languages?!

~~~
hopia
Dart has some annoying traits that hurt productivity with it. For example, the
lack of union types or some kind of sealed classes is fairly annoying when the
language is actually statically typed.

There's some work being done to overcome this but so far no solution has seen
the daylight in practice.

~~~
scalatronn
Relax, it's being speced now, give them time to make non-nullables first.

