
Google’s Flutter = React and Java Swing - kiyanwang
https://codeburst.io/googles-flutter-react-java-swing-8174c8d9d402
======
tobiaswk
Flutter is an amazing project. It feels like an futuristic version of the
Android SDK. Everything is a widget and it has a catalog of amazing widgets.
These conform to the Material Design guidelines. It makes it very hassle-free
to make a functionally great and beautiful app. You write your Flutter app
using Dart. The Dart code is compiled to native code. The more I work with
Dart the more I like it. The IntelliJ Flutter plugin makes for a tight and
great integration.

Right now the weak point of Flutter is that there aren't many plugins for
utilizing platform specific features. This always the fault line with these
cross-platform frameworks. These will come I'm sure of. It's relatively easy
to write a plugin which is a great plus.

I've done native development on both Android and iOS. Tried Cordova-based
development. Lastly React Native. Out of all these I like Flutter the most.
You will make a beautiful app with much less work compared to native
development and other alternatives. The performance is also fantastic. Flutter
uses its own high-performance rendering engine to draw widgets. Almost the
entirety of Flutter is written in Dart; also the lower parts. This is
important for development because nothing is closed off. With everything being
written in Dart it gives you a high degree of control.

My early work so far using Flutter;

[https://play.google.com/store/apps/details?id=org.me.tvligen...](https://play.google.com/store/apps/details?id=org.me.tvligenu)
(Danish television listings)

[https://play.google.com/store/apps/details?id=dk.kjeldsen.et...](https://play.google.com/store/apps/details?id=dk.kjeldsen.etherexplorer)
(Ethereum blockchain explorer)

~~~
pjmlp
> Flutter is an amazing project. It feels like an futuristic version of the
> Android SDK.

This is how I would like to have seen ChromeOS being implemented, a fresh
revisit of the Smalltalk experience but using Dart instead.

Instead they created a browser window manager.

~~~
pgeorgi
At least that "browser window manager" came with lots of useful tools to solve
problems with the computer, based on a wide ecosystem.

"Smalltalk Revisited" doesn't solve any problems per-se, and would be firmly
stuck in the chicken and egg corner that produced way too many stillborn
projects in IT.

So, Chrome OS implementing Dart might have been interesting, but on the other
hand, as soon as there was talk about adding Dart to the web platform, there
were all those rants about "Google is monopolizing the web!!!!11". I guess
it's hard to please everyone.

(disclosure: I'm on the Chrome OS firmware team. Although while "Chrome",
there's definitely no Javascript or Flutter involved. My team's code needs to
run in the absence of arbitrary amounts of RAM [edit-to-add: which means I
have no stake in the game of which language has a hipster-compatible garbage
collector])

~~~
pjmlp
So let me tell you that I don't see any value spending money on ChromeOS as it
is, and there is hardly any computer store in Europe selling Chromebooks.

When they try to sell them, it is a single model on a corner of the shop with
increasing discounts until someone finally takes it away, or they return the
unit back.

So from European point of view those "lots of useful tools to solve problems
with the computer, based on a wide ecosystem." are nowhere to be seen.

> My team's code needs to run in the absence of arbitrary amounts of RAM

Chrome's memory usage on the process system monitor shows a different reality
about that code.

~~~
pgeorgi
I think I missed the real meat in this comment in my other response, so here's
attempt #2:

> So from European point of view those "lots of useful tools to solve problems
> with the computer, based on a wide ecosystem." are nowhere to be seen.

These "useful tools" are web sites (and web apps). By providing excellent
support for these, the devices are immediately useful. Much better than hoping
that another ecosystem like Android's can be jumpstarted.

The average user buys a (hypothetical) Dartbook: Looks for some Dart app. Gets
frustrated by the lack of choice. Returns the device.

The average user buys a Chromebook: Browses their favorite websites (and face
it: 90% of contemporary computer use is _just_ _that_). Reasonably happy
customer (unless they insist on installing "TuneUp Utilities" because they
always do that).

That's what I meant with the availability of lots of useful tools to solve
problems with the computer (in that case, a Chromebook), repurposing a wide
ecosystem (the entire web, basically).

From your other comments on this site (eg about the Atom editor), you seem to
be fundamentally opposed to html/js as a platform and with that sentiment,
Chromebooks must look anathema to you. Alright, that's one position to take.
But what use would be a Dartbook to you? You'd probably complain (with full
reason!) about its inability to run emacs just the same.

~~~
pjmlp
> These "useful tools" are web sites (and web apps).

Web browser app....

> The average user buys a Chromebook:

And returns it back after discovering it cannot install his/her favorute
software and requires a permanent internet connection to make anything useful
with the device.

> The average user buys a (hypothetical) Dartbook: Looks for some Dart app.
> Gets frustrated by the lack of choice. Returns the device.

The return rate of those devices running Android is quite big apparently.

> But what use would be a Dartbook to you?

The same as my tablet and mobile phone running Android.

~~~
stickfigure
It's a mistake to look at Chromebooks as consumer products.

I have bought Chromebooks for my employees. They can access business resources
without me having to worry about them getting hacked and leaking proprietary
information and passwords to production systems. Chromebooks are cheap,
unsexy, and can't run fancy games. These are all pluses.

Chromebooks are the 3270 of the present day. They're for the average customer
service representative, not for the home user.

~~~
remir
I don't agree. Chromebooks are wonderful for the elderly and folks who don't
need a traditional OS. They can browse the web, read email, watch videos,
without worrying about drivers, virus, downloading gigs and gigs of update
every years for features they don't care about.

------
hardwaresofton
Does anyone feel a tinge of guilt using the amazing technology that Google
provides?

I think Google is overall a pretty "evil" (I use quotes because the term is
loaded, and the reasoning is too long to easily state) company. IMO Google is,
at best, hard-to-trust, and at worst adversarial in many of the decisions they
make. But I sure am excited when it produces technology like Android, Golang,
Flutter etc and makes it free to use.

Personal opinions aside, what they've done here is managed to create a _full-
measure_ cross platform mobile application, and they have the resources that
warrant taking them seriously. All the other options are either half measures
or require such a drastic shift/ongoing support that I hesitate to use them,
to list a few:

\- Cordova/Phonegap (half-measure)

\- React Native (Facebook is your benevolent dictator)

\- Lambda Native (convince the team to go full lisp, and hope/build support as
the platforms change under you)

\- Native (learn all the ins and out of 2+ different platforms, and hope to be
prolific, because you'll likely not be expert in either one)

I just wanna know if anyone else has this dilemma/thinks about this.

IANAL, but the license
([https://github.com/flutter/flutter/blob/master/LICENSE](https://github.com/flutter/flutter/blob/master/LICENSE))
is basically MIT + don't put google's name in your product... Maybe I'm
thinking about this too much

~~~
beaner
I feel like Google generally takes the right side of things. Defensive
patents, tight security, easy to use, friendly products. Their stuff is mostly
open source and free. TBH Google are relative angels. Microsoft before them
had shitty products and strongarmed other corps to get what they wanted.
Actively sued based on dumb patents. And Apple only turned "privacy" into a
thing they supposedly cared about when people started being concerned about
Google's powers. They're not actually sincere about it, it's marketing like
everything else.

Sometimes I think people forget the history of how and why Google got where it
is. They've had some snafus, but for the most part just been a freaking
awesome company from the start who puts out amazing, free things, and push OS
and CS research forward.

No, I have no guilt using anything they make.

~~~
Flow
> They're not actually sincere about it, it's marketing like everything else.

Really? How do you explain Secure Enclave, end-to-end iMessage encryption and
lots more? Not to mention the tough stance they publicly took against FBI
wanting special OS version to crack terrorist phones?

~~~
pgeorgi
To play the devil's advocate:

> Secure Enclave

ARM TrustZone. My 2005-era low-end devices have that. Hardly Apple's idea.

Microsoft did ground work in that space for ~2 decades by now. It's called TPM
and has a bunch of advantages by being a discrete component. It's also an
industry-wide initiative and open to all.

> end-to-end iMessage encryption

Perfect for locking down the ecosystem.

> tough stance they publicly took against FBI

Posturing (on both sides: The FBI knows that they're SoL on getting such
favors, with or without writing whiny op-eds on how they're incompetent).

You'd have already seen leaked versions of the "special OS versions to crack"
had the other vendors budged to such demands. They might just discuss matters
with the Feds without inviting the press.

~~~
tptacek
The Secure Enclave is not ARM TrustZone. The SEP is a discrete component.

------
jaequery
Dart? Sorry I'll have to pass. On top of Elixir, Go, and JS fatigue, I don't
think I have any more room left for another language to "try".

But if it was Polymer with native iOS/Android support, now then this would've
been a different story! When I compare all the recent front-end frameworks,
Polymer still is the most appealing to me, I wish it had a bit more steam
behind it.

~~~
yrio
Dart is quite similar to Java. If you are already familiar with Java I believe
it will take you very little time to get started with Dart.

FWIW, I was able to write two small but useful program in Dart in one day,
without any experience with the language at all:

\- A script to convert CSV file to SELECT ... UNION ALL SELECT ... statements

\- A script to parse my timesheet (in Emacs' org-mode) & insert it into my
client's timesheet database

I just used these 3 resources:

[1] Dart language tour
[https://www.dartlang.org/guides/language](https://www.dartlang.org/guides/language)

[2] Standard library introduction
[https://www.dartlang.org/guides/libraries](https://www.dartlang.org/guides/libraries)

[3] Standard library reference (like JavaDocs)
[https://api.dartlang.org/stable/1.24.2/index.html](https://api.dartlang.org/stable/1.24.2/index.html)

[4] And the pub package manager
[https://www.dartlang.org/tools/pub](https://www.dartlang.org/tools/pub)

~~~
copperx
It's really easy to get started with almost any language, the problem is
becoming an expert in it. How can somebody become an expert on the nuances of
JS, Typescript, Dart, etc not to mention libraries and APIs of each? And
that's just for the frontend.

------
tallowen
It is very exciting to see more people write frameworks using "React" ideas.
This will make React and similar frameworks better!

It seems like one of the biggest ideas that flutter brings to the table is a
different approach to component libraries. It makes sense that there is a need
for this given that larger companies that invest in React tend to have their
own tailored component library that people outside of those companies
generally don't get to take advantage of. The startup costs to developing your
own library of React components and their CSS/Native wrappers are high.

That being said, when I think of prebuilt component libraries (eg, bootstrap,
swing) I generally think of components that are too familiar for users and a
crutch for developers to allow them to quickly develop interface code where
they may not be an expert. In a high quality app, I would expect widgets to
follow the patterns that other apps on the platform follow. Won't this be
difficult for a framework like Flutter which will have to re-create each of
these native widgets (as apposed to React native where they are just wrapped
in a JS layer)?

Regardless of these qualms, I'm excited to see more well funded frameworks
enter this space because I'm sure that all users of frameworks in this space
will benefit. I will be on the look out for more complex uses of this
framework to see how people overcome these types of issues!

------
sandGorgon
The biggest problem with Flutter is that of developer reluctance - primarily
because of Dart. And ever more so _now_ because Android adopted a small,
scrappy company's homegrown language (Kotlin) instead of Google's own.

I'm kind of wondering what are the political fault lines inside Google around
the Dart, Flutter and Android ecosystem.

If Kotlin gets adopted server side at Google as well (which is fairly likely
considering Google is already using the JVM), then why would people bet on
Dart ?

Is Dart 10x better than Kotlin ?

~~~
cheapsteak
Search trend comparison of Dart vs Kotlin vs React Native:

[https://trends.google.com/trends/explore?q=%2Fm%2F0h52xr1,%2...](https://trends.google.com/trends/explore?q=%2Fm%2F0h52xr1,%2Fm%2F0_lcrx4,React%20Native)

Interesting that there's heavy kotlin searching mainly in Russia

~~~
evilduck
Not really that surprising to me, Kotlin is named after a Russian island, so
naturally their non-developer populace will use the term more than the rest of
the world and the programming language was created by JetBrains, a Russian
company, so I'd also assume there's probably some elevated interest for
Russians in something successful that's also "home grown".

~~~
sfRattan
Technically, JetBrains is a Czech company with offices in Russia, among a half
dozen or so counties.

------
zelos
> So they can look like iOS native widgets or Android native widgets. This is
> basically the exact same approach as JavaSwing.

Hang on, he's saying it's like Java Swing as if that's a _good_ thing?

~~~
bitL
Yeah, funny, isn't it?

I wish we had a variation of Deplhi's VCL for web/java/etc. instead of all
these monstrosities that make life miserable instead of taking 5 minutes to
make a solid UI.

~~~
Hixie
Can you elaborate on which part of Delphi's VCL you are looking for?

------
smdz
Link: [https://flutter.io/](https://flutter.io/)

------
cypher303
The floating 'open in app' on this page is really bad. Please stop doing that.
For fucking crying loud, don't mix text with bullshit.

------
criddell
It looks fantastic, but with Google I always wonder about their long term
commitment to stuff like this.

~~~
anthonybullard
Well, they state that they are using it in their own production apps. They did
the same with Angular from basically day 1. And it started as a 20% project
for Igor(sorry if I'm remembering that wrong). Nearly seven years later and
here we are at Angular 3, I'm sorry 4. It all depends on adoption.

~~~
WaltPurvis
>Well, they state that they are using it in their own production apps. They
did the same with Angular from basically day 1.

This reminds me of a question I've had before: exactly what production apps
does Google use Angular for? Have they rewritten Gmail to use Angular? Or
Calendar? Or Docs? I'm too lazy to dig into the obfuscated source of any of
these to figure it out for myself. Does anyone know what apps Google actually
uses Angular for?

~~~
filiph
I can answer this for AngularDart. That one is used for AdWords, AdSense,
AdMob — these 3 alone bring 75%+ of Google's revenue —, a company-wide CRM,
Fiber, Shopping Express, Wing, ...

No Gmail, Calendar, Docs, or any other consumer app so far.

Disclaimer: I work on the Dart team.

~~~
copperx
Aren't those the same apps that claim to use GWT?

------
mbid
Is Flutter tied to Dart, or are there good C bindings so I can use whatever
language I want?

I've never understood the obsession with creating a whole language around a
library (R, Matlab, Magma, Javascript, Wolfram...) so that I'm essentially
forced to use that.

~~~
pjmlp
Bravo, you just discovered how language adoption works.

Also as an addendum, C is a language designed around an operating system.

If it wasn't for UNIX's adoption, C would have been a footnote in the history
of systems programming languages.

~~~
mbid
Well, yeah, but wouldn't you agree this is a sad state?

Also, C as a "portable assembler" kind of make sense as a lingua franka,
because every language has to go through assembler before being executed at
some point.

~~~
pjmlp
No, because adoption needs to be driven by an actual need of some sort.

A programming language doesn't get adopted just for its grammar and semantics
alone.

Regarding the benefits of C as portable Assembly, I advise you read about the
programming languages and operating systems designed in the 60's, 10 years
before UNIX was created.

------
Keats
Any idea when this will be in beta? That looks way more interesting than React
Native to me.

~~~
amelius
Unless you want to run your code on the web as well, I guess ...

~~~
rpeden
If you write the web version of your app using AngularDart, you could probably
share a fair amount of code between the two.

------
xg15
I'm looking forward to the first library/tool/support project called Shy

~~~
gagege
Or port it to a different language and go with the deep cut, Zephyr.

Makes a lot of sense because reactive programming is inherently lazy. :)

------
alkonaut
Looks very nice. Any indications that is or will be possible to make non
mobile apps? Or that it will have bindings to other languages?

Dart is a huge step up from JS, but I can see how other languages would be a
nice fit too.

------
Tloewald
My first problem with Flutter is that it doesn't unify web and native
development, so it fails to solve the big problem immediately. If you can
deliver web and mobile from the same codebase, you can deal with the "long
tail" of users (and web users too). React Native (not that I have any great
love of React) and its clones are working towards supporting all platforms.

My second problem with Flutter is the writer's apparent biggest positive
feature — Dart. (I love how he naively states that Dart was conceived as a
language to transpile to Javascript; it was conceived as a _replacement_ for
Javascript with transpilation as a stopgap.) I think Javascript is a fine
("good enough") language that (a) works almost everywhere and (b) is evolving
at a more-than-sufficient rate. I have no desire to drink Google's Kool-aid.
(Go, OTOH, I am fine with.)

But then I get to "Building Layouts with Flutter":

[https://flutter.io/tutorials/layout/#step-1](https://flutter.io/tutorials/layout/#step-1)

This makes the articles I've read on "thinking the React way" seem mild in
comparison. In exchange for having to restrict your layout ideas to the stuff
that will work in Flutter (which first entails somehow grokking what works in
Flutter), you have to go from visual concept to hierarchical breakdown and
then translate that into code in less than intuitive ways, and then when your
graphic designer decides that such-and-such needs to be 2 pixels lower or the
stars should get bigger in the middle, you're still going to be hosed or
inserting fixed height shims all over the place (and how will that look on a
tablet?)

This API seems too high level to produce polished products. Of course it's
alpha so blah blah blah but being able to quickly produce generic stuff is not
a proof of concept, especially if you can't then refine the generic stuff to
the nth degree.

~~~
Hixie
(I work on the Flutter team.)

> This API seems too high level to produce polished products.

You can target whichever level of Flutter's APIs that you want. Almost the
entire stack is in Dart, from the compositor, to the layout engine, to the
animation logic, to the composition (widgets) layer, to the material widgets.
If one layer is too high level, you can go down one level and work directly
there instead.

The lowest level (the C++ layer) is literally just the Skia API, the Dart core
APIs, a text rendering API, and a message-passing API for talking to your
Java/Kotlin or ObjectiveC/Swift code. Everything else is layers you can
directly poke at from Dart, written in Dart.

~~~
Tloewald
Thanks for addressing this specific issue (and hey, Hixie!) Obviously, I don't
know much about the APIs so I'll take your word for it.

I guess my first objection (doesn't unify web development) stands, but that
can be addressed in future (and presemably Dart will work just dandy with Web
Assembly).

I assume my other objection can be addressed by simply building layouts
directly and not using the autolayout stuff if you don't want.

------
brad0
Finally a cross platform framework that makes sense! Writing your own UI
elements using the platforms graphics primitives makes a lot of sense.

It will be interesting to see how it works in practice.

------
steedsofwar
My years of toil with Java Swing makes me shudder every time i hear its
wretched name.

------
edtechdev
I wonder about accessibility of flutter widgets though, since they aren't just
wrappers for native widgets.

Looks like it's still not accessible
[https://github.com/flutter/flutter/issues/10562](https://github.com/flutter/flutter/issues/10562)
The issue was brought up a year ago too
[https://groups.google.com/forum/m/#!topic/flutter-
dev/xwUJ7D...](https://groups.google.com/forum/m/#!topic/flutter-
dev/xwUJ7DzIFlk)

~~~
gman83
Adam Barth from the flutter team responded last time this came up:

[https://news.ycombinator.com/item?id=14433320](https://news.ycombinator.com/item?id=14433320)

------
taeric
> There are no external UI DSLs (i.e. html or xml files). > The entire UI is
> written in Dart. This, for me, is a > big win.

This view amuses me. It is obviously held as an opinion, and isn't one I
disagree with; but goes heavily against what everyone was aiming for with the
likes of HTML. To the point that it is kind of hard to believe I'm seeing it.

I give it about 4 months before there is a UI language that is not "code" that
is usable here. Pushed by the other side.

~~~
untog
HTML was designed to create documents, though - not UIs. That also happens to
be the core of a lot of problems with it (that, IMO, are overblown).

A lot of the struggle/difference between JS frameworks is this disagreement
about where things fit on the document vs app scale, IMO.

~~~
taeric
And to an extent, I fully get what you are saying. However, the entire push of
HTML/CSS is not much different than the push of LaTeX over TeX. Or any number
of other examples. (You can almost draw the line at people wanting a fully
declarative language for content being the problem. I'm sympathetic to that
view. I haven't explored it enough, yet.) People want to find a very hard
separation of presentation from content.

And to an extent, this makes sense. However, ditching HTML and similar tech
seems excessive to me. The largest problem with HTML is so many people try to
appease the flow and native layout of the elements. This leads to a massive
bloat of markup to create what is actually easy to describe using minimal
markup and liberal usage of absolute/relative positioning.

------
Kiro
> React Native uses native widgets. This means you have to create separate
> apps for Android and iOS.

I've never used any native widgets in React Native. Didn't even know they
existed. I create and style all widgets I want from scratch so they obviously
look the same on both Android and iOS. I thought that was how everyone did it.
What am I missing?

~~~
CognitiveLens
All of the built-in React Native components are wrappers around the
corresponding native widgets: [https://facebook.github.io/react-
native/docs/components-and-...](https://facebook.github.io/react-
native/docs/components-and-apis.html)

You can also integrate other native widgets not designed first and foremost
for React Native [https://facebook.github.io/react-native/docs/native-
componen...](https://facebook.github.io/react-native/docs/native-components-
ios.html)

~~~
Kiro
Thanks. What's the benefit of using the built-in Button component? The only
reason I could see is that you actually want them to look differently on
Android and iOS. I've heard the sentiment before but I don't fully understand
it. For example, when I build an app I want it to look like my app, with its
own distinct graphics, and not like a generic system app. Why go through the
hassle of making two different UIs when you can just go with your own?

~~~
pavlov
Accessibility is a big one. When your buttons are actual UIButtons, they get
treated as such by the iOS accessibility system.

Most developers don't consider accessibility at all because they don't need it
themselves. But there are millions of iOS and Android users who do need it,
and they might be thankful that you've made their life easier with your app.

Following platform standards makes things easier for users. Users don't care
if your app has distinct graphics.

~~~
Kiro
Thanks. Is that's really what's happening with React Native's built-in button
though?

[https://github.com/facebook/react-
native/blob/master/Librari...](https://github.com/facebook/react-
native/blob/master/Libraries/Components/Button.js)

    
    
        if (color && Platform.OS === 'ios') {
          textStyles.push({color: color});
        } else if (color) {
          buttonStyles.push({backgroundColor: color});
        }
    

Looks like they are just styling them differently to make them look like
system default.

~~~
pavlov
Sorry, I don't know how React Native does it, although my understanding is
that Button components do end up as real platform buttons.

Generally speaking, UIButtons have important semantics that are easy to miss
if one just reproduces the appearance using custom graphics. The same applies
to other standard controls too.

------
bsaul
Something i don't get : does this mean the flutter team will have to redevelop
all the gui features and new components of every single new version of cocoa
touch, every year, within the timeframe of the beta and the actual release of
the new sdk ? And do the same with android sdk ?

Or, will you end up with old looking interfaces and wait anxiously for someone
to update the gui component library ?

Because except for creating its own ui paradigm, that will look different from
both ios and android, i don't see another option.

------
rockmeamedee
At this point we should probably make a framework for implementing the native
features in these systems, so the next Cordova/Ionic/Xamarin/React
Native/Flutter doesn't have to start from scratch every time and take 2 years
to re-build nearly the exact same ecosystem for native features.

As a plus we could consolidate all that brainpower spread across different
cross platform native feature libraries to make these native features less
buggy, more featureful and more maintained.

------
devdoomari
how's flutter's interop with java/kotlin/swift/etc? Would I be able to use
existing libraries from those lang.s?

~~~
afsina
[https://flutter.io/faq/#can-i-interop-with-my-mobile-
platfor...](https://flutter.io/faq/#can-i-interop-with-my-mobile-platforms-
default-programming-language)

~~~
devdoomari
hm... is it something like IPC? By 'message passing', would it be ok to use a
java image-processing/video-processing library?

~~~
Hixie
(I'm on the Flutter team.)

IPC is "inter-process communication". This message passing is same-process.

We haven't yet proved that it's sufficiently performant for extremely latency-
sensitive work, and we currently copy the bytes for the messages when
switching so it's not very suitable for high-bandwidth work like video where
you're sharing the bytes between Dart and Java.

------
yellowapple
A lot of the praises of Flutter in the article can be said about Tk. I guess I
ought to have a look.

------
tannhaeuser
The title led me to believe this is about a java.awt.geom and Swing port to
Android.

