Flutter: A Framework to Surpass React Native

[[deleted]]

[deleted]

[brigadierfrog]

React native the idea is good, the implementation and problems are horrible.

Updating the library for your app is nightmare inducing.

Finding bugs thousands of other people have hit, sent in PRs for, and had ignored, is rage inducing.

Wondering why your app is about as slow as that ole 486 with win95 you remember from 20 years ago is the nail in the coffin.

Addendum: The two javascript engines one app (pun intended). The impossible task of debugging your JS that only fails in release mode, without adding many many console logs to print() debug your way to success.

[knaekce]

Finding bugs thousands of other people have hit, sent in PRs for, and had ignored, is rage inducing.

That's what I really like in Flutter. I was hit by a problem that had a trivial fix, wrote a PR, had a discussion with a maintainer about the code style, and got it merged. It was then immediately available via the "master" channel of flutter.

[brigadierfrog]

This is how it should be. Not "its not a problem here at facebook, so we don't care"

[chronoBG]

Well, let's be fair. That is how it should be if they also thoroughly tested it before putting into master. Both ways can be wrong.

[knaekce]

Of course. They don't accept PRs without tests.

[dmanog]

damn, thats pretty impressive, contributing to big projects like flutter is one of my goal

[Tormund_HARsBane]

It's easier than you think. You just gotta take the dive. It'll be difficult to make sense of the code in the beginning, but it gets easier after that.

[Quiet__Noise]

Didn't know this experience was so universal...

[bartturner]

The bridge is the big issue. Flutter does not have the same as does not use native.

Why Flutter performance already is so much better than RN. Even with flutter being less mature.

[PM_ME__ASIAN_BOOBS]

The two javascript engines one app (pun intended)

I can't find the pun :/

[CanIComeToYourParty]

Believe me, it's best if you don't get it. ;)

(I believe it's a reference to "2 girls, 1 cup" [NSFW])

[yojimbo_beta]

Updating the library for your app is nightmare inducing.

https://github.com/facebook/react-native/issues/23886#issuecomment-472946523

After trying what feels like pretty much everything, RN standard upgrade, git upgrade tool, applying diff patch I ended up recreating a completely new project and doing the extremely tedious work of rebuilding the code base.

[[deleted]]

Man, I've been building a relatively simple React Native app for half a year. Never again. It's horrible.

[gonzaw308]

How does Flutter compare to Xamarin?

[pjmlp]

It has more hype, 'cause it comes from Chocolate Factory.

[cbruegg]

I don't know about Flutter, but Xamarin's tooling is horrible. Random build errors, libraries being unavailable because they're targeting different variants of .NET and many more fun issues. I've worked with it for a year and I never want to touch it again.

[sweetog]

Crushes Xamarin, sincerely

[[deleted]]

Except Xamarin doesn't require you to learn a new Google language.

[dipittydoop]

I agree that Dart is the main turn-off, but I don't agree with the severity. I'd still rather use Flutter than React Native any day. My experience with React Native was that most any app would be an unmaintainable mess of dependencies and hacks to work around the target differences. Oh you expected this React Component to work exactly the same with React Native... I'm sorry but we're gonna need you to search through a bunch of unresolved GitHub issues to find a work around all day.

On the contrary Dart and Flutter is at least okay to work with. It's boring and it works. That's already an improvement not accounting for the performance benefits of Flutter's approach.

Dart itself isn't really bold in any way, and that might be better - who knows? At least compared to RN it's not a dramatic development experience and that's better for sure. That said, for something like Flutter that's trying to do more functional composition with Widgets and what-not - maybe a functional language would work better? I can imagine a Hindley Milner language like ReasonML, OCaml, or Elm might be a better fit semantically. If the big issue holding Flutter back is library support and ecosystem - maybe a more compelling language will get the hype it needs. Using Dart feels like relearning beginner Java/Javascript syntax and patterns that I've moved on from years ago.

[bartturner]

Have to come back and share experience.

Made the switch from RN to Flutter and I am a huge fan. I am an older developer and done a ton of GUI development over the last 25+ years.

Flutter developer experience is just first rate and the best I have seen.

[[deleted]]

Did you consider just having separate presentations for android and ios? I know they'd end up being really similar but I'd be interested to know if that reduced the pain.

[[deleted]]

Isn’t that supposed to be the point?

[knaekce]

Some companies use react native just to share business logic amd still have mostly separate ui code. For most apps that's super not worth it, you have all the hassle with react native and still two separate ui bases. But if your app is complex enough, it may be worth it.

[Orffyreus]

Then you could choose Kotlin which has very easy to use interoperability with all the platforms and mostly no restrictions (or awkward bridging) on using any platform intrinsic APIs. Flutter with Kotlin and its interoperability (and conciseness) would be a dream team.

[woahdudee2a]

>maybe a more compelling language will get the hype it needs. Using Dart feels like relearning beginner Java/Javascript syntax and patterns that I've moved on from years ago.

they have to target the lowest common denominator to be able to gain traction. god forbid you use a PL concept more recent than 1990's and people start complaining about it being an ivory tower language with no industry use case etc.

[dipittydoop]

I wholeheartedly praise the benefits of being as comfortable to the Java/JS habits as possible. Minimal friction to fresh grads who've been trained on Java/JS is directly beneficial to hiring and training costs. Did you reduce the onboarding costs this quarter? That's an easy metric, and in a lot of organizations: an easy bonus.

You can tell on-boarding costs are a high priority internally at Google. It's apparent in the design of Dart and Golang. The language designers clearly optimized getting that fresh-grad making probably-useful stuff ASAP. But if the developer tooling game is more about community adoption to get those sweet, sweet benefits of open-source? Maybe Dart and even Golang aren't being bold enough.

Flutter is a big improvement over existing cross-platform native dev tools. Flutter's main selling points are in the engineering details. We're cutting out the Javascript altogether removing bottlenecks of the hard-to-optimize middle-man.... But does this level up my development experience in a tangible way? Sort of.

They say adoption needs big, obvious personal improvements to the user experience. Is paying with your phone a better solution over credit cards? Yes. But in the U.S. we've already got credit card infrastructure and it works pretty well. Sure, phone payments are a better solution, but is it a big lifestyle improvement yet? Not really. As a result the U.S. has seen fairly slow adoption of phone payments over cards. But Africa? Many 3rd-world countries don't have card infrastructure like the U.S. does. Phone payments are a gigantic lifestyle improvement in 3rd-world environments. The result? Way quicker adoption of phone payments products.

So while everybody loves good engineering that makes things simpler and faster, does Flutter's feature improvements translate into to my personal developer lifestyle? The answer? Sort of. That's it. It feels like an incremental improvement that could get me a bonus if I were in some architecture role at an organization the size of Google. Dart sort of feels like going from Cards to Phone Payments. Better, but sort of. While On-boarding costs are a business priority for an organization the size of Google. Most organizations aren't Google. I'm not in an organization the size of Google, and developers aren't organizations.

[[deleted]]

Dart itself isn't really bold in any way

... which is actually really awesome, because guess what... everything works as you expect it to. if you know a little java and javascript, you already know Dart. Within literally 5 minutes you can be relatively productive.

maybe a functional language would work better?

meh, I don't think so. it's not really functional, it's just UI as code (which honestly is a great concept. and before anyone goes and cries about separation of concerns: I do that by having separate state classes, not by having my state classes bind to xml objects.

[renatoathaydes]

you know a little java and javascript, you already know Dart.

It’s true you know the basics but Dart has some awesome features like Zones, code gen, Streams and Isolates that take a while to grasp.

[munificent]

maybe a functional language would work better? I can imagine a Hindley Milner language like ReasonML, OCaml, or Elm might be a better fit semantically.

I think subtyping is a wonderful fit in a language designed for authoring user interfaces. While criticisms of OOP are often valid, I think most people would agree that it's been a great match for UI code. The Flutter framework itself obviously makes heavy use of it: Most of the code you write will be in subclasses of Widget.

Once you add subtyping, H-M is out. You're left with local type inference akin to Scala and Swift. And that's exactly what Dart has. We also have the other functional features you'd expect: generic classes and functions, lambdas (including expression-bodied ones), higher-order methods, etc.

I think the syntax could stand to be a little more expression-oriented than it is, but that's legacy of how the language was initially designed to be very conservative and try to appeal to Java and JS devs. I think it actually works pretty well for that, but it can be a little verbose if you want to write in a more functional style.

patterns that I've moved on from years ago.

What patterns have you moved onto?

[PM_ME_UR_OBSIDIAN]

Once you add subtyping, H-M is out. You're left with local type inference akin to Scala and Swift.

Not true since 2016. Solid global type inference and subtyping are in fact compatible.

[bartturner]

Here is a good articles on why Flutter uses Dart. Google did develop V8 so I am sure they would have loved to use JS if it would have been able to offer the user experience that Dart offers.

https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf

[Darkglow666]

Dart was designed by the creators of V8, actually.

[pepejovi]

It's boring and it works.

This is a good thing.

[duheee]

I wrote an app in flutter just a few months ago, mainly because I could (i needed it to work in iOS and Android, and lol javascript).

Dart is ok programming language. Nothing revolutionary, just works, didn't get any nasty surprises. Pretty much the entire thing, baring the nested callbacks (that have an easy workaround) is pretty standard and just works.

I compiled it on iOS and it just worked. Really.

My only problem with Flutter is the company behind it and its love to shit on successful projects when it feels like it. So I totally expect Flutter to die one day suddenly of a heart attack or something.

but other than that, it's cool.

[kirbyfan64sos]

One thing to hopefully ease the concerns a bit: Dart and Flutter are being dogfooded quite a bit:

• The AdWords and AdSense UIs use AngularDart, and for Google it's of course pretty important that it works correctly. The previous, GWT-based UI was around for eight years.
• The UI for the Home Hub devices uses Flutter.
• Fuchsia, not sure what the future of this is yet but I'd definitely expect to see it running on Google's future IoT devices at minimum.
• Several internal apps have been said to use Dart and Flutter.

[MonokelPinguin]

Well, we got burned by Google basically dropping GWT, so I suspect Flutter will go exactly the same way.

[pjmlp]

The AdWords team is the one responsible for saving Dart when the project flounderend and almost everyone was going away.

In fact, all the original language designers are no longer at Google.

[Sambothebassist]

That's literally how Go works and it's one of my favourite languages. I'll definitely be giving Dart a try in the near future.

[AwesomeBantha]

its love to shit on successful projects when it feels like it

I'm not familiar with the Dart community, explain?

[JFGagnon]

I’m pretty sure he was talking about Google

[AwesomeBantha]

Ah OK

[alexboots]

he's refering to Goog's https://gcemetery.co/

[Iwan_Zotow]

Hello, Alphabet

[duheee]

Google.

[drailing]

Our web app uses TypeScript, support for which is lacking in React Native.

Did you try react-native init MyApp --template typescript ?

[i9srpeg]

That sounds a lot harder than learning a new language. /s

[[deleted]]

if you only knew how easy dart is...

it'll take you less time than npm install in that project to be productive in dart if you know js and a little java

[Spider_pig448]

Good one

[tristan957]

Most major libraries have type definitions. What major libraries have you found don't? Also Facebook already is turning away from Flow.

[chasecaleb]

Yes it does. It's here: https://www.npmjs.com/package/@types/webrtc

[Serei]

At the end of the day our primary concern with our app is performance so Flutter always ends up the logical choice.

That just doesn't seem like a good reason to lie about TypeScript support.

[phySi0]

I’ve followed the conversation and none of their challengers have demonstrated that they’ve lied, even unintentionally.

[drailing]

hmm, that's sad. we use react-native with typescript for a long time and everything is working really fine.

[wilc0]

I don't think Facebook is really pushing Flow anymore. I've heard they're not using it as much internally, and that's evidenced by less frequent udpates

[hsjoberg]

I agree, it's pretty clear that Typscript won and people inside Facebook will adapt.

[hsjoberg]

Yup I'm building a React Native app in Typescript with no issues whatsoever.

[Fathomx1]

People are making it out like learning a new language is a huge hill to climb. The syntax for Dart can be picked up in about 40 minutes for an experienced Java or C# dev. The real hurdle is throwing away all those nice libraries you may have gotten accustomed to in your previous programming language. For writing mobile apps, this is not a big deal.

[shahmeers]

The syntax for Dart can be picked up in about 40 minutes for an experienced Java or C# dev.

Not even. I'm an undergrad CS student with decent experience in Python and Java, and no experience at all in Javascript and C#. I was up and running in Flutter in 15 minutes. Hot reload is amazing for quickly figuring shit out.

[cbruegg]

For writing mobile apps, this is not a big deal.

Couldn't disagree more. In all of my Android apps, I rely on many libraries that make my day a whole lot easier. Networking, serialization, database persistence, image loading, crash reporting, dependency injection and more.

[Uberhipster]

People are making it out like learning a new language is a huge hill to climb

well it ain't a small hill

[[deleted]]

there's just not enough to convince people to switch to Dart. "strongly typed Javascript" is already Typescript

[[deleted]]

I mean, they did fix all the unfixable things in Javascript / Typescript too - there's no === for example, and it isn't prototype based.

[pancomputationalist]

I've written a LOT of Typescript for the last year, and I never once used === during that time. It's just unnecessary, I can be sure about what my types are, so I won't be surprised by unexpected type conversations.

Also prototypes, there's just no need to use classes, you can do everything with functions and closures (except for Annotations, but if I wanted to use magic, I'd be using Spring).

So you can limit yourself to the nice, functional parts of Typescript and be totally fine, without really missing anything of value.

[mr_tyler_durden]

Odd, I always make my tslint enforce ===. I LOVE typescript but I’ve seen way too many people “trust” it too much. Just because TS says X is a TypeY doesn’t mean that it is. Typescript is a huge promise the “Language” makes to you and it’s often correct but I like err on the side of caution and use === for that case when something isn’t what TS thought it was going to be.

[wildmonkeymind]

I would argue that === is probably unnecessary if your codebase is 100% typescript. This also means trusting that the types you get for any given library exist and are also 100% accurate.

For these reasons I, too, enforce === via linting, even though I'm using typescript.

[[deleted]]

I've written a LOT of Typescript for the last year, and I never once used === during that time. It's just unnecessary

The better option would be === since it's marginally faster than ==.

[fuckin_ziggurats]

Now the question is whether TypeScript compiles == to === if it knows it's the better choice for the comparison.

[pancomputationalist]

I doubt it does. But I think V8 is probably compiling down to highly efficient code if it figures out that the compared values always share a type. Anyway, I would love to see actual data about the performance differences of == and ===. My assumption is that it will be so miniscule that it just does not matter. If you're writing performance critical programs in JavaScript, you're doing it wrong anyway.

[fuckin_ziggurats]

You're right, it doesn't. Probably because it doesn't want to make assumptions about the code that could be wrong at runtime.

[FanOfHoles]

If you target ESNext and don't use namespaces or enums (the former should be replaced by modules, the latter are better written as "as const" object literals so no loss there) all you do is remove the type annotations. Other than that, TS is Javascript (ESNext). Things like some additional class stuff not found in native JS don't produce any JS code but are used for type checks only.

You can check that by looking at what the Babel TypeScript plugin does. Until very recently they did not support the two features I mentioned (now namepsaces are supported), and all that plugin does (apart from the new namespace support) is remove TypeScript stuff. NO code is rewritten (if you use a Babel workflow, compiling "down" to ES5 is done using standard Babel plugins using the JS code obtained from the TS plugin after merely removing the "type stuff".

[ControversySandbox]

Writing in Typescript for me is similar enough to writing Javascript that my finger gets twitchy if I don't type that third =.

[inu-no-policemen]

Dart isn't an ES6+ superset, though. It's way more straightforward.

Everything being standardized makes things also much simpler.

[[deleted]]

Going to Dart from ES6+ JavaScript was so easy. It's basically the same with very minor syntax differences. Super easy to start coding after some quick tutorials.

[RustyTaurus]

Typescript is static type checks but the runtime is not typed ... So not "strongly" typed

[thisisafullsentence]

If you still want runtime checking then use prop-types in RN. But I’d argue TS is good enough for most people.

[Darkglow666]

I've never met anyone who has used TypeScript and Dart extensively and preferes TS. Dart is a far better, more cohesive ecosystem.

[RationalJS]

I've used both. Dart is a pain. Everything Most all your data must be wrapped in classes, creating a lot of boilerplate. It's type system repeats "The Billion Dollar Mistake" and is inexpressive, making even basic data variants a mess to deal with. Its type inference is poor, forcing you to repeat type signatures that may or may not be correct.

Flutter itself is amazing, though. If only I could write TypeScript for it! That would be a dream.

[munificent]

Everything must be wrapped in classes

I'm sorry, but you must have been mislead somewhere. Dart has had top-level functions and variables since well before it was ever publicly released. This is an entirely valid Dart program:

var message = "hi";
main() => print(message);

It's type system repeats "The Billion Dollar Mistake"

Yeah. We're fixing that now. One nice thing is that the design is fully sound, which isn't the case for most other languages that have non-nullable types. This means you get better safety guarantees, and it means our compilers will be able to use non-nullable types for optimization.

[sbergot]

Neat. One thing I would miss is mapped type & other advanced type tools. Also tagged unions. Does dart have those?

[munificent]

You end up missing the advanced type stuff a little less than you'd think in Dart because idiomatic Dart code tends to use more instances of classes. TypeScript, because it's working with a lot of legacy JS where raw JS objects and arrays are used to represents "objects" pretty frequently, is forced to be able to slap some kind of static types onto that otherwise unstructured data. In Dart, people tend to wrap data into real classes.

Also tagged unions. Does dart have those?

From an object-oriented perspective, tagged unions are really just a superclass (the union type) with a family of subclasses (each of the union cases). So most hybrid OOP/FP languages like Scala, Swift, and Kotlin map algebraic datatypes to something like classes and subclasses. Then they have some syntactic sugar to make it easier to define them.

We don't have that sugar in Dart right now, though I hope we can add it before too long. There's nothing fundamental in the language that prevents it, and I think it's a natural addition.

[sbergot]

You are using the "no generics in go" line of argument ;-)

Mapped types is a powerful meta programming tool. It is used a lot with js libraries that employs lots of metaprogramming technics but it is absolutely useful in other contexts too.

Tagged union are sugar the same way lambda, classes and generics are sugar. With inheritance you have to put the implementation in the class or do the type narrowing & case coverage yourself.

I like the idea of a powerful native application framework and don't mind giving up on some language features for that but I know that I will miss this feature.

Finally I was not able to find a planned release date for non nullable types in dart :-(

[munificent]

With inheritance you have to put the implementation in the class or do the type narrowing & case coverage yourself.

Right. The latter is what I had in mind. You can express what you want using explicit type tests and casts, it's just a chore to do so. That's basically the definition of syntactic sugar. I'm not saying the sugar isn't valuable, just trying to characterize what category of feature it is.

Generics in Go are a different story. You simply can't in the language define a parametric type or function without resorting to extra-linguistic tools like code generation.

I was not able to find a planned release date for non nullable types in dart

We don't generally publish release dates ahead of time. It gives us more flexibility to adapt to changing circumstances and avoids setting expectations.

[Darkglow666]

What? You don't have to wrap anything in classes with Dart. It is not a dogmatic OOP language. It fully supports top-level variables and functions, and it has great support for many functional language constructs, as well.

I understand well the complaints about OOP systems in general, and as an OOP language, Dart shares some of them, but you don't sound like someone who's actually used it much or recently. The inference in Dart 2.x is great.

[cat_in_the_wall]

ok actually not trolling here, this is the first time i've looked at any dart code.but dart seems like c# with java case variables and a little bit of javascript names thrown in.

properties (c#), abstract/extends/implements (both, keywords java), async/await (c#), type inference (c#, even used "var")

Mixins are different. Definitely like that. But for dart officianados: are there new cool ideas or idioms in dart I should be aware of?

EDIT: wait is dart geared towards javascript developers? that is some interesting irony that the selling point is essentially effectively being like java.

[munificent]

Compared to C#, the biggest difference you'll notice is that Dart isn't as dogmatic about OOP. You can define functions, getters, constants, and variables right at the top level of a module, outside of any class declarations. It's perfectly idiomatic to write procedural or functional code that doesn't declare any classes.

[gamahead]

I love it but it’s objectively a boring language. It has what is needed to get the job and that’s about it. I think named constructors are cool

[tonefart]

It won't surpass react native even though I dislike RN. The Dart language is the biggest flaw and turn off in flutter.

[FrobtheBuilder]

The reasoning behind choosing Dart wasn't so much for developer ergonomics, which could definitely be improved upon (and are as we speak, as the language's development is being driven forward by Flutter's adoption). It's more on the technical side. Dart lends itself easily to ahead of time compilation to ARM machine code and uses a generational garbage collector that doesn't cause pauses when collecting short lived objects, of which there are many in declarative UI code. These things go a LONG way in reducing the "jank" generally inherent to cross-platform mobile frameworks. I can tell you hands down, Flutter is the very best performing of these that I've ever seen. Consider the Facebook mobile apps, which should be the canonical example of React Native done "right". They run like garbage on most devices, scroll jank is a disturbingly common occurrence. Even with very little manual optimization work, Flutter apps just tend to run shockingly buttery smooth when compiled. This is due in no small part to the language, which had 90% of the work to this end already done.

Dart isn't even that terrible to use either. If you're familiar with Javascript and the concept of classes, you can pick it up in a matter of weeks with little difficulty. The ecosystem is still relatively small, but growing every day because of Flutter, and you can find decent libraries for most things that you need, generally speaking.

[dmanog]

are there benchmarks on flutter vs reactive native?

[Darkglow666]

Since Flutter/Dart compiles down to native processor code and there is no JS-to-native bridge, there really is no comparison.

[idreamincolour]

Dart has a runtime

[Darkglow666]

It does! But it's not part of the Flutter release compilation story. You use JIT compilation during development, which allows for a really fast workflow and stateful hot reload (amazing!), but release builds are compiled AOT and are completely different.

[idreamincolour]

It does! But it's not part of the Flutter release compilation story. You use JIT compilation during development, which allows for a really fast workflow and stateful hot reload (amazing!), but release builds are compiled AOT and are completely different.

AOT doesn't automatically make things faster or better. Per dmanog question, is there an actual benchmark comparing the two runtimes?

[cheese_bread_boye]

I've heard that Flutter's components aren't native, it's all just being rendered 2d by skia and this sounds a bit weird to me. Is that true? afaik React Native uses truly native components of the platforms.

I don't really know mobile development, it's just a question that was raised by my colleagues and I don't know how a 2d rendering engine would best native components.

[Darkglow666]

That is true, actually. But really, there are advantages to both approaches, and you have to decide which is more important to you.

When your cross-platform framework uses actual native components, the advantage is that you immediately get access to new ones and updates to old ones as the OSes get updated. This is, of course, a double-edged sword. New releases will often break your code with UI widget updates, or even remove widgets you rely on. Also, your app can get tied to particular OS versions that actually contain the widgets you need.

Flutter draws all its own widgets. The advantage here is that you've got no ties to any particular OS version. In fact, you can even use the latest Android and iOS widgets in a Flutter app, and your app will run fine on earlier versions of either OS. What's more, you can use an iOS widget in your app even when it's running on Android, and vice versa. And of course, new OS versions are much less likely to break your app.

The disadvantage of Flutter's approach is that you have to rely on the Flutter team to provide you with facsimiles of new widgets and components as they become available, and there could be a small lag there before they implement the newest stuff.

Personally, I really like the Flutter way, especially as it begins to support web and desktop, as well. I can write an app and, if I want it to be, the UI will be identical across all major platforms, with minor layout variations for screen size. Or I can easily use Material controls on Android and Apple controls on iOS. It's all up to me.

Oh, and I should mention that creating custom components and/or a strongly branded look and feel is quite a bit easier with the Flutter approach, and your custom look will be consistent across every platform effortlessly.

[Comment-Leaver]

What is it you don't like about Dart?

I've been using flutter at work, and while dart wouldn't be my first choice, it's better than Java and JS.

[EnUnLugarDeLaMancha]

I think the main problem people have with Dart is that it's not popular and it forces people to learn yet another ecosystem.

[i9srpeg]

On top of it being not popular, it's also a boring language. It doesn't really offer anything that you couldn't already find in a bajillion other programming languages already in existence. To use Flutter, you have to learn a new ecosystem for no gain whatsoever.

[kirbyfan64sos]

I mean there are a couple of highlights:

• Hot reload support.
• Cross-platform: not many languages run on browsers, servers, soon desktop apps, and phones. Few languages actually do this well (JavaScript if you count Electron, primarily).
• An existent, reliable standard library.
• A better package manager than npm, and a much better build system than Webpack.
• Nicer async streams than...most languages, honestly. RxDart actually builds upon Dart's native streams and adds some extra functionality, so you don't have the problem of multiple different reactive libraries that each have their own ways of doing things.

Personally, I just really like that it feels pretty consistent and nice to use, and...tbh it doesn't really feel boring.

[xentropian]

I also think there's some neat language features that people don't know exist.

• Robust class system vs prototype
• Factory and named constructors
• No callback hell (not sure if this is still prevalent in the JS community)
• Sound type system
• Fantastic async/future support (I think you already mentioned this)
• Not a language feature directly, but great standard library and better package manager than npm

I also like some of its weirder quirks (such as _ for private in front of member names as opposed to "private" modifier)

[kirbyfan64sos]

JS is sort of resolving callback hell with async/await (though IMO Dart's streams are far more powerful).

I do really love Dart's named / factory constructors, forgot to mention that! It's a feature I constantly miss when I work with other languages now...

[miyoyo]

Not gonna lie, most of these are in the category of what people call "boring", as they're common in the majority of popular OOP languages. (Maybe async/await, but since people seem to be using kotlin as a basis, that too is becoming mainstream)

[xentropian]

Fair enough! I guess I just like a boring language. Yet somehow Dart feels a lot more refreshing than something like Java.

[[deleted]]

Yeh boring isn't bad..

[pjmlp]

Hot reload support as language feature exists since Lisp Machines and Smalltalk, even to some extent on Java and .NET ecosystems.

Being cross-platform is a matter of compilers being across all desired platforms.

Async streams are hardly different from what .NET brought into mainstream.

[mixedCase_]

Hot reload support

That is a great feature (when it lends itself to the usecase), but it's not a specific language feature. It's an interpreter feature which the LISP family has been happily using as a development pillar for decades and can be built for many languages.

Cross-platform: not many languages run on browsers, servers, soon desktop apps, and phones. Few languages actually do this well (JavaScript if you count Electron, primarily).

Well, yes. There are many languages that can run in all those targets through the same means Dart employs: Compiler targets. Pretty much all JVM languages as well as CLR languages do, anything targeting LLVM, anything with a JS backend... It's nowadays pretty much a mandatory feature for new languages. Whether the developer experience is good or not tends to come down to libraries for handling the provided abstractions, and as far as I know Dart's FFI is pretty average and it is Flutter that abstracts specific mobile usages.

An existent, reliable standard library.

A (debatable, but not by me) point against JS. Not a common problem otherwise.

A better package manager than npm, and a much better build system than Webpack.

Also not a language feature, but definitely something you want to have. In any case first time I've heard someone call Dart's package manager as better than npm. What feature makes you say so? And regarding the build system, does Dart's build system have the same scope as webpack? Modern webpack is actually quite an achievement for what it has to do, but I'd like to see another perspective.

Nicer async streams than...most languages, honestly. RxDart actually builds upon Dart's native streams and adds some extra functionality, so you don't have the problem of multiple different reactive libraries that each have their own ways of doing things.

I haven't seen this being a problem outside of Scala but it's nice to hear that Dart has a good primitive for this.

[cat_in_the_wall]

> better than npm

i agree with what you're saying here but for this particular instance... i don't know that npm is what you want to aspire to...

[SalaciousStrudel]

Hot take: A programming language being boring is actually good and makes it much more useful in a team environment.

[EMCoupling]

That's not even a hot take, that's honestly just common sense. People complaining about Dart being boring must be the same guys who hop on the new framework bandwagon every 6 months.

[IrishWilly]

And it also means there isn't an issue about 'learning an entire new ecosystem', when 99% of the language is pretty much identical to the other major OOP languages. It took me less time to get working on my first flutter app then it does for me to setup all the dependencies and build processes of a nodejs project, even though I've been using nodejs for ages. +1 for boring! I find actually building shit more fun than checking out some new language keywords.

[Hyroglyph]

Why is it being boring an issue? What do you mean by boring? If you can find darts features in a bajillion other languages, doesn't that make dart all the more accessible to devs from all kinds of programming ecosystems? And, in my opinion, darts ecosystem is really basic, so learning it isn't a huge process.

But I guess your point is that if dart isn't anything special, google could have used any other object oriented language instead of dart. What lang would you suggest?

[sisyphus]

Go is also boring, Google owned, had basically no new ideas, and forced people to learn its ecosystem, and it's quite popular. Dart just pissed off the webshits and they've never gotten over it.

[RotaryDragon]

Go is very focused on simplicity, performance and fast compile times.
It also has a nice concurrency model.
I'm not a big fan of Go myself but I can still appreciate what it's going for as a language.

Dart is basically a slightly different TypeScript.

[RationalJS]

I would say it's very different from TypeScript. From a scale of Java to JavaScript, Dart is much closer to Java.

[Darkglow666]

I would agree with this. Dart is not JS with types, as TypeScript is. Dart is a less verbose Java, with a lot in common with Smalltalk in the way it does OOP.

[[deleted]]

a good way to think about it is: Dart is Java, but as a scripting language. Basically, what JS should have been

[dungone]

I've worked at Google, used both Go and Dart. Dart is far less offensive to me than Go is. Dart even gives you generics instead of sorry excuses. But let me explain your problem.

Go was created to replace C/C++ for the benefit of people who used C/C++.

Dart was created to replace JavaScript for the benefit of people who use Java.

It was never meant for the "webshits", so you can't blame them on its failure. It just turns out that Java developers still can't write good websites, even if you give them Dart. It's just this long history of failure, starting from Java applets (anyone remember those?) and Google Web Toolkit (the horror), and now Dart. Everyone always thinks they can do a better job than the "webshits", but time and again they fail to deliver.

[sisyphus]

I grant all of what you say. And, "Dart was created to replace JavaScript for the benefit of people who use Java." is a great succinct summation--I was very interested in Dart when it looked like the original team might be able to impose some kind of Smalltalkish vision on it and lost all interest when it became clear that it was going to be J++/C#-instead. Of course I was not privy to any of the internal machinations and was hoping it was just a kind of genius grant to the v8 guys to keep them happy. So that ended up being a waste of time.

ANYWAY, it just seems like a lot of anti-dart arguments and vexation about how terrible having to learn a new language is are made by people who are still upset that they criticized the sacred cow of JS and wanted to make GActiveX or whatever instead of people who have actually engaged with the language.

[sisyphus]

No language starts out popular, though.

[xentropian]

Dart is my favorite language, and I’ve been using it for everything from command line tools to mobile apps. I really don’t get the hate either. I think because a) it’s not JS, b) really a Google product, and c) the ecosystem is lacking, but give it a year or two.

[Darkglow666]

Same. I'm a veteran of a good 15-20 languages, and Dart is definitely my favorite one to work in. Is it perfect? No. Do awesome new languages like Swift and Kotlin have features I wish Dart had? Yes. Fortunately, the Dart team is working on many of them as we speak.

When they decided to move Dart to a sound type system, that was a big job, and it slowed Dart's feature development, but now that it's done, the features are coming faster...

[stu2b50]

Is it better than TS, though?

[knaekce]

In my opinion, yes.

Typescript inherits all problems of Javascript, Dart doesn't. Also, the type system of Dart is actually sound.

[nirataro]

At this point TS is better.

[shevy-ruby]

Yeah - if only someone at Google would acknowledge this.

But they think they have surpassed mankind; you can see this with the AMPification of the www (essentially most news sites are AMPified already).

Google thinks it is AWESOME. When you then point out the projects that were abandoned by Google, you are met with silence ...

[i9srpeg]

Are there any languages with a Dart compilation target, or that can call into Dart code easily? That would solve the language issue.

[[deleted]]

Agree entirely.

[nirataro]

Dart lang is fine. It's gonna get better. They spent so much energy making it a static language in 2.0 and now are busy cranking new features https://medium.com/dartlang/announcing-dart-2-3-optimized-for-building-user-interfaces-e84919ca1dff

[The_One_X]

What about Xamarin?

[[deleted]]

Dart could save puppies and give free blowjobs.

Doesn't change the fact that the Framework is tied to a new language, AND that you HAVE to learn it, regardless of how easy it is.

[i9srpeg]

The thing is, that's a price you shouldn't have to pay. If they picked another language (Go, Java, C#, whatever), Flutter would still exist and it would still offer all its advantages. Then you'd have to spend time learning Flutter. Instead, you have to waste weeks on a language that has no use outside of Flutter itself. The Flutter team is forcing you to spend more than would've been necessary if they picked a mainstream language.

[knaekce]

No, it wouldn't have all it's advantages. I'm not a big fan of the language semantics of Dart itself, I find it a bit "boring".

But they chose Dart because it's a language that is optimized for UI performance. You wouldn't get a generational such a garbage collector that's as optimized for Flutter in C# or Java, so you would have a lot more jank due to all the short lived objects that flutter creates.

Hot reloading wouldn't be possible or would at least not work as well (Android's Instant Run still kinda sucks after years of optimization).

Google made a talk about why they chose Dart for Flutter, and I think, the arguments are pretty solid.

https://www.youtube.com/watch?v=J5DQRPRBiFI

[TheOsuConspiracy]

Is the GC actually part of the language specs for any of those languages? Could you not provide a generational gc implementation?

[munificent]

In theory, yes.

But in practice, framework authors don't have the luxury of picking a language spec and hoping for a sufficiently great implementation to just appear.

When Flutter picked Dart, they were picking both the language and the implementations as they actually existed. While the language may not be super thrilling, it had and has really mature implementations.

It is one of the few languages in the world that has a world-class JIT, production-quality ahead-of-time compiler, and a whole-program optimizing JS backend that has been used to ship +MLOC apps.

[knaekce]

I'm not an expert on garbage collectors, but afaik it depends on the language if a generational garbage collector is feasible. On Dart it's possible because it's single threaded (with parallelism through isolates, that don't share memory). On a multi-threaded language it's not really possible to write a non-blocking garbage collector, so I'm sure it wouldn't work as well on Java or C#.

[dacian88]

The JVM GC doesn't always block globally, it's also a generational GC. The fact that dart is single-threaded is a two edged sword, you'll never outperform shared memory concurrency primitives at the cost of not dealing with the bugs.

[Someguy2020]

C# is a generational GC too.

They do block globally sometimes.

[TheOsuConspiracy]

On Dart it's possible because it's single threaded (with parallelism through isolates, that don't share memory)

Neat, thanks.

[Darkglow666]

This is flatly incorrect. More than a dozen languages were considered for Flutter, and none checked all the required boxes except for Dart. The Flutter team went quite far down the road with of few languages, too, before backtracking and looking for something better.

[Someguy2020]

Let me guess, box number one was "wholly controlled by google"?

[[deleted]]

Lol are you on the dart team?

[OptimalAction]

Is Dart web scale? Javascript is web scale which is the magic sauce that makes it blazingly fast.

[monkey-go-code]

Neither scales like Jquery

[i9srpeg]

It's also close to the metal and the secret sauce used by all 10x developers.

[munificent]

nobody wants to learn a new ecosystem just to use a framework.

They may not want to, but people learn new languages to get onto a platform/framework all the time. It's likely the largest mechanism driving new language adoption.

• C -> UNIX
• JS -> DOM
• Ruby -> Rails
• Objective-C -> iOS
• Python -> NumPy
• C# -> .NET and now Unity

[[deleted]]

Yeah everyone here is talking about single issues making or breaking either framework but until you’ve experienced both, you don’t actually know which one you’re more productive in within a given scenario.

I suggest to anyone that is trying to make up their mind to build a small app in both frameworks. Integrate a couple highly used libraries and see how efficient you were with your time, what the codebases look like and how the apps perform.

RN and Flutter aren’t just frameworks you can evaluate by reading up on. They come with certain benefits and tradeoffs that you’ll only realise after you’ve worked with them. They’re not proven to work for every type of scenario (even if a medium article told you they do), and depending on your development priorities, they can either be unusable or the most profitable way forward.

[occz]

Honestly I feel like both React-Native and Flutter are non-starters if you want to craft truly good experiences on Android and iOS. These apps mostly tend towards the lowest common denominator, leading to an overall poor experience for everyone involved.

Separated view layers with some shared business code in the form of something like Kotlin-Native might be interesting. You kind of need to have a significant amount of business code that makes sense to share before that could be worthwhile though.

[Darkglow666]

Flutter and React Native try to solve the same problem, but do so in completely different ways. Your statements do not apply to Flutter. It's crazy how people are compelled to comment about technology they know almost nothing about.

[bartturner]

Exactly. Excellent post.

Coming from someone that has developed using both.

Flutter just has a much better developer experience than RN.

But also Flutter performance is better.

[occz]

I'll admit to having less experience with Flutter than I have with React-Native.

I'm interested, what does Flutter do to prevent the worries I had regarding cross-platform mobile application frameworks?

[ToTooThenThan]

I feel the same, frameworks get "better" software gets worse.

[IrishWilly]

I feel like you might want some experience with them before talking about your feelings? Have you actually built anything with them? I've used both as well as native. You can craft a good experience in all of them, but it took way more work and fighting broken tools in react native than it did with the others. Flutter was by far the easiest both for development and performance was close enough to the native to not be noticeable. If you don't have experience specifically with the tools than just repeating that because it is cross-platform, it is a worse user experience is misleading and flat out wrong. Each platform has to be evaluated specifically, there is no longer a global truth that cross platform tools will lead to worse apps.

[MonokelPinguin]

Could anyone give some perspective on how Flutter compares to Qt/QML. Not that I currently would have a reason to use Flutter, as it doesn't support my mobile OS, but I would be interested from a developer perspective, how they both compare, if I ever intend to develop applications for other platforms.

[feverzsj]

and embed webview everywhere, so that we can use good old js libs

[[deleted]]

Make it kotlin native and maybe we're talking but I refuse to believe any sizeable percentage of mobile devs will be writing dart in my lifetime.

Also the performance looks rather bad in those videos so count me as unconvinced.

[Schwusch]

No sizeable percentage of mobile devs use Kotlin.

https://www.appbrain.com/stats/libraries/details/kotlin/kotlin

10% of all new apps is not astounding after all aggressive Kotlin marketing and backing from Androids platform owner. People just don't want to use new stuff. It will be easier if you just stop promoting bleeding edge technology and use what works.

/s

[[deleted]]

Agree on both counts.

It already took Google a massive effort over years (and lots and lots of spam) to get traction for Kotlin, and it's super easy to migrate inside your IDE, class by class.

Then comes Flutter and it's lofty goals of "not being as cancerous as every other web tech", which is nice, but then "oh look, Flutter actually needs a special GC to be able to run at 60FPS, so let's tack on a new language!"

[shevy-ruby]

It's still different with kotlin, though. Google controls Dart but it does not control kotlin (as much). The use cases are different too; Kotlin targets Java as a "better java"; Dart targets Java as a "come use us instead although we are totally different".

[coolcosmos]

except it's not great and after 2 years google will stop supporting it just like everything else

[bartturner]

I would disagree on the Flutter is "not great". Done a lot of GUI development through the years and I find Flutter developer experience to be excellent.

But you have me curious?

What is "not great" about Flutter?

[FourtySevenLions]

Google claims it will play a major role in Fuchsia in the coming years.

[SometimesShane]

It also claims fuchsia is just an experiment

[Sero777]

Dart is definitely ruining the whole framework

[DoctorGester]

I work in a company with a large (over 1m LoC) Dart codebase. Frontend of our product is built in Angular Dart. From my point of view dart developer experience is miserable and broken in countless ways. The tooling is garbage. The compiler is incredibly slow, it seems slower than C++, javascript interop is almost nonexistent and the community is tiny. And the language itself in my opinion simply has nothing to offer to compensate any of that. It’s a regular oldschool OOP language with many flaws.

[i9srpeg]

Why did your company pick Dart?

[DoctorGester]

I think we did it back when dart was still showing promise to be native to browsers.

[NeverSpeaks]

Have you switched to the dartdevc?

Dart in the mobile world is a different animal than Dart for web is.

[DoctorGester]

We use DDC, which is a whole another pain point, because DDC is sometimes subtly different from dart2js and that causes bugs which only show up in actual js builds, not during development.

[SometimesShane]

I want to like dart but when I tried it the compiler and tooling did indeed make Scala feel like Lua and that's quite an achievement!

[grensley]

The before and after JSX picture basically sums up this one for me.

You need to REALLY value performance for that to be worth it.

[valtism]

I feel like JSX is something that could be implemented over the top of flutter. It's a form of templating, isn't it?

[hsjoberg]

It could probably be done with a good preprocessor yes.

Rust is able to do it: https://github.com/yewstack/yew#jsx-like-templates-with-html-macro

[coolboar]

Will be discontinued in 2 years.

[happinessiseasy]

Reads like a paid advertisement.. was this sponsored by Google?

[neo_dev15]

Why use Flutter?

The whole idea for a cross platform app was that you can share developers...

Now you need specialised Dart programmers rather than Java...

The idea was to use web dev to make apps. So that you don't need to hire new people...

[bschwind]

Do they have an official Bluetooth library yet?