Announcing Flutter Release Preview 1 | Hacker News Reader

Announcing Flutter Release Preview 1

medium.com

180 pointsmattsolle82 comments

I've been using Flutter for a few months now, and have not felt this productive in years. Being able to iterate so quickly on real or virtual devices has changed how I design and development a UI. I can set out with a mock-up and almost immediately start to feel why it isn't perfect and just use it until the feel is right. The productivity bonuses are sometimes hard to explain to people who haven't yet tried Flutter and it's tooling.

This announcement of preview 1 is coming at a great time as I am launching my first app on iOS and Android next week.

Dart is by far the most productive cross-platform web technology I've ever worked with. We got the same (quite complex due to the domain requirements) core codebase for web client, IOS, Android, and on the server side is well. Had we chosen to go with the more traditional combination, the effort to keep everything in sync would rise exponentially with the complexity of the project.

Now I wish dart had nullability support.

What frameworks are you using for the web client and the server?

Web client: our own mini-framework developed on top of dart:html (we needed maximum flexibility there, for simpler UI we could have used an existing framework)

Server: shelf

Cool - how is the WebView support?

I have a project that will require a WebView in the app.

Also I downloaded Flutter a while back and noticed a lot of buggy / unintuitive behavior with their TextViews (multi-line specifically) such as with copying and pasting, selecting text, etc.

Do you know whether these components have matured?

I found this: https://github.com/dart-flitter/flutter_webview_plugin

Looks rather hacky.

I've used this for pop-up dialogs. Works fine and I've had no issues on various sites which certainly have gross amounts of js. It shouldn't be long before the Flutter team provides a WebView widget.

I had some similar experiences with multiline text controls in the summer of last year, but it seemed to improve by around the fall. Not quite sure of the current state but it seemed to be improving.

(Overall it was still super worth it to use flutter at the time)

Sounds like Expo to me.

How does it handle native APIs? Like React-Native (you have to write bridges in ObjC/Java) or like NativeScript (you can simply access all native APIs via JS)

See this blog post from last year: https://hackernoon.com/whats-revolutionary-about-flutter-946...

The styles-as-widgets idea sounds nice.

I saw that with JSX somewhere <Row> <Column> <Grid> etc. Made the whole thing look much cleaner.

Asynchronous bridges

Unfortunately, I kind of feel torn: On one hand, I love flutter as a concept[1]. It removes a lot of the baroque from mobile development (no need for the whole RecyclerViewer construction for every list! No Fragments! Doesn't require Android Studio to start working!) but I hate the language (dart). After using Kotlin (let alone Rust), It feels like moving back to Java (no non-nullable types) and in some ways it's actually worse than Java (threads are extremely heavy weight, every interaction with native code is async and slow).

I wish there was:

1. A good Kotlin language server (unlikely, as the company behind the language is an IDE company).

2. A good reactive Kotlin GUI library (meaning, with the ergonomics of Flutter (as in, I don't have to work with Fragments and their lifecycles, just use views)).

3. A good JVM interpreter (to speed up Kotlin/Java compilation)

[1]. No I don't use Flutter to "write two apps for the price of one", as most (of my) apps are just a front-end over a back-end server, so they don't have any special logic worth saving between iOS and Android. I just find Flutter easier to work with relative to Android.

I'm on the Dart team (though I wouldn't necessarily take my comment to be an official statement of the entire team).

> (no non-nullable types)

I really wanted [1] to get those into Dart 1 (way back before Swift and TypeScript even existed), but I couldn't convince language team at the time that it was worthwhile.

When we moved to a stricter, sound type system with strong mode, we hoped to get non-nullable types into that and ship them with Dart 2. But, as you can imagine, migrating millions of lines of code from an optionally typed, unsound type system to a sound, reified static type system is a hell of a lot of work. (I'm not aware of any cases where it's been done at this scale.)

We weren't able to fit non-nullable types into that schedule and into our users' migration pain tolerance. There is only so much you can drag them through, and just getting to strong mode was a lot.

There is still a desire to bring non-nullable types to Dart. It probably won't be soon because we want to give our users a break from migration, and give our implementation teams time to take advantage of the new type system. But I haven't given up on them, and our team's new focus on static ahead-of-time compilation makes them more important than ever.

I agree that Kotlin is a really nice language. I hope we can catch up to them with Dart and exceed them in areas.

[1]: http://journal.stuffwithstuff.com/2011/10/29/a-proposal-for-...

The thing is that the longer you wait, the harder it will be to migrate, as the codebase size grows (and once you leave beta, people assume that the language is finalized and won't be too happy being forced to refactor their code when Dart 3 comes out). But as it is, I doubt that the nice parts of Kotlin will ever make it to Dart.

> The thing is that the longer you wait, the harder it will be to migrate.

Definitely preaching to the choir on that one. I pressed my case as hard as I could before 1.0.

We do still have more freedom to make breaking changes than many post 1.0 languages do because, frankly, we don't have that many users. But every day, the cost to make that change goes up.

> people assume that the language is finalized and won't be too happy being forced to refactor their code when Dart 3 comes out

I was worried about that with the transition to the new type system in Dart 2, but users — internal and external — were surprisingly accepting of the breakage. We don't want to be cavalier about breaking them, of course, but my impression is that there is more room for significant changes than I'd initially assumed.

> But as it is, I doubt that the nice parts of Kotlin will ever make it to Dart.

Dart will never be Kotlin, but I hope we can get to a point where most users don't consider it to be deficient compared to Kotlin and where we have some features to make Kotlin users jealous.

Yes, it's really sad that a language as young as Dart already has such problems :/

It's because the language was made to compile to JS, and competition to JS, so appropriate tradeoffs were made.

For example:

1. JS is single-threaded, with extremely heavy threads only recently made available. So Dart is single threaded, with extremely heavy threads available.

2. JS is weak-typed, so Dart was made optional typed. Remember, it was made before typescript, so they probably didn't expect that such type-heavy features as ADT would interest people.

Kotlin does the same (for example, internal immutability would be much nicer, but since the JVM doesn't support that, neither does Kotlin).

From what I've seen how apple did it:

1. They added optional nullability syntax to objective-c, a language that assumes everything is null and doesn't crash when you send a message to nil. If your file uses nullability, it's required for the file, otherwise you don't have to use it. Code without nullability annotations using non-null annotated code could interface with the non-nullable code. Errors didn't come up unless you did very obvious things like directly put nil in a non-null argument.

2. They migrated their entire apple library base to have proper nullability annotations. Code that didn't have nullability annotations continued to work fine. Or I think you could just turn off the build error with a compiler flag.

3. Apple introduced swift. Any objective-c code that didn't have nullability defined was assumed to be an implicitly unwrapped non-null. So if you give a null to something not expecting a nil in swift, it would crash.

Apple has a blog article specifying it further here: https://developer.apple.com/swift/blog/?id=25

-----

I liked this approach for the most part. Migration wasn't that much of a pain, and it was incentivized because I didn't want implictly unwrapped stuff in my swift code.

If you migrated the flutter framework and the dart stdlib to have nullability, then new projects can start with proper nullability annotations from the start, while old projects can progressively migrate files as needed.

Java also has a nullable syntax annotation, and kotlin probably has some sort of java-kotlin nullability interop somewhere. I would really suggest doing it, nullability has given big stability benefits to large projects as it is, and would help adoption in the future as people using something like kotlin & swift for new projects vs flutter itself.

not sure what's dart like relative to enums, but enum with associated type + optionnals are the absolute killer feature for swift. Steal those and you'll have nothing to worry about.

> (I'm not aware of any cases where it's been done at this scale.)

Facebook has done it twice at this scale: PHP -> Hack, plain JS -> Flow JS.

As far as I know, both Hack and Flow are unsound and don't do any runtime type checks to preserve soundness. It's a lot easier to migrate dynamic code to a static type system if you have the luxury of just ignoring the type system when you want to. :)

In Dart 2, the type system is sound and checked at runtime in cases where it can be proven statically safe (downcasts, variance, etc.). That makes it a lot more work to migrate because the code actually needs to run correctly without violating any of the dynamic type tests.

The Flow core type system is sound: https://dl.acm.org/citation.cfm?doid=3152284.3133872, although there are unfortunately some known unsoundnesses in the actual type system. Does Dart suffer from the same?

Hack does check type hints at runtime, so it's "sound" in the same sense as Java might be. Is this the same sense in which Dart is sound?

> the type system is sound and checked at runtime in cases where it can be proven statically safe

I didn't understand this. If the code is statically proven safe, why would you need runtime checks?

Neither Hack nor Flow are reified, so it's a different matter.

Both of these languages started out with strict null-checking — Hack because there were too many bizarre falsy values in PHP to allow otherwise, and Flow because it worked out so well in Hack. So neither had to tack on strict null-checking afterwards.

There have been some similar large-scale migration efforts. For example, Hack's record types were built on top of PHP arrays, which don't distinguish between absent and null values. Consequently, Hack's record types didn't distinguish between optional and nullable fields. Furthermore, records support width subtyping by default. This is unsound: you can construct distinct types A and B with A <: B <: A.

After a lot of effort, we did migrate the entire codebase to resolve this unsoundness. Essentially, we changed every record declaration to be an "open" record type and made all new records "closed" by default (referring to whether they supported width subtyping).

The analogue, then, would be something like refactoring every type declaration in every consumer's Dart code to be annotated as nullable, adding explicit null-checks, and allowing them to write non-nullable types as the default thenceforth.

How did you end up in that team, and how one should apply (in case you have any open positions)?

The story of how I ended up on the team is probably too random to be actionable. I believe we do have open headcount, but I don't know how the hiring process works for getting a new hire on to a particular team.

Email me and I'll see what I can figure out.

Sad to see optional typing go. I thought that's the best of both worlds -- you can write type annotations for documentation or checking, but you also have the benefit of dynamic typing when static typing comes in the way.

I have a different view on it, I actually like Dart. I like the strong types and how the language is more suited for enterprise development than both typescript and JavaScript.

There is the added benefit of being able to reuse assets from your mobile app in AngularDart, which I suspect may see an increase in use along with flutter.

I’m not coming from Kotlin or rust though, but a .net core backend with JavaScript on the front end and Xamarin for apps. I can definitely see us move from AngularJS and Xamarin to flutter and AngularDart though as this move would be a nice improvement.

I’m not too worried about the lack of available projects and libraries on dart compared to say JS, as we typically wouldn’t include some one man hobby project anyway.

That being said, I think we’ll wait and see what happens throughout 2018.

>is more suited for enterprise development than both typescript and JavaScript.

What makes you think this given the library and tooling situation? Is this strictly a "worse is better" thing where lacking modern language features is a plus (at which point I'd argue for Java) or is there a Dart feature that makes you think it's actually an improvement over TypeScript, Kotlin, .NET Core (both C# and F#) or Rust (just to avoid adding more languages to what you mentioned) for enterprise development?

I'm frankly astonished at seeing how something that I see as an extremely clear step backwards as far as languages go is getting so much traction; not sure if it's just because Flutter is that good a tool (in which case I'd think we should be aiming to make the native core available to other languages) that people are willing to root for the whole package or if there's something else.

I think you misunderstood me. I don’t think it’s an improvement over c# (or Kotlin, but I have no experience with Kotlin so I wasn’t commenting on that).

I think it’s an improvement over JavaScript, Typescript and the Xamarin experience + tooling, with the added advantage of letting you share language in your clients.

I don’t think dart is great though, it’s just better than the terrible alternatives.

TypeScript has ADTs, non-nullable types and the tooling is one of the best (great autocomplete, support for refactorings, incremental compilation, yarn is a great package manager, etc).

Its type system is also one of the most advanced in mainstream languages, being inferior only to Scala and Haskell.

In comparison, Dart doesn't have ADTs or non-nullable types. For a new language, I consider this very underwhelming.

I'm considering using Flutter for a new project because it seems to be a great platform, but having to use Dart instead of TypeScript is a step backwards.

>I think it’s an improvement over [...]Typescript

JS I understand, but what makes you prefer Dart over TypeScript in this case?

Here are my personal opinions as a long time Dart/JS/TS developer.

- Dart had a lot of features before either JS or TS. Important features like cancellable promises or optional chaining are still missing (I know they might be coming soon). Also some nice quality of life features like named constructors.

- As a superset of JS, Typescript has a lot of idiosyncrasies that might bother people. Personally I don't mind, but people new to web development often find Dart to be a friendlier experience, with fewer pitfalls.

- To me, and this is very subjective, the TS syntax is uglier than either JS or Dart. The types get in the way and add noise to the code. I find Dart's and pretty much any other language's type declarations much cleaner.

However, I have two very big problems with Dart that prevent me from using it as much as I'd like to.

- JS interop is much much cleaner in Typescript/Flow. Every compiled-to-JS language that isn't a superset suffers from this. It's what prevents me from using ReasonML seriously too.

- No support for JSX. I can't go back to writing nested createElement after using JSX

I thought reasonml's JavaScript interoperability was quite good, seems to compile faster and the type system cannot lie about it's inferences like it can in TS

But the main thing for me between TS and reason is exhaustive pattern matching is better in reason, it feels jacky in TS

could I use reasonml/js with flutter widgets and ignore dart?

Maybe Dart is simply better than C#/Java but worse than Kotlin?

On (2), there is a Kotlin language server in progress: https://github.com/fwcd/KotlinLanguageServer

A fair comparison would be with JS as all the other alternatives use JS.

Or languages that compile to JS (like TypeScript). Maybe one day we'll get languages compiling to Dart[1].

[1]. Although it'll be a pity. JS is stuck as a compilation target because it's a standard, and it's old, and even then wasm may one day take over JS. Flutter could have been a library, and one could have written in Go or Rust or Java with Flutter bindings. As it is now, I don't know if its possible.

Agree the language is the worst part. Honestly if Dart has extensions like Swift and Kotlin, and rust (I think) I would be satisfied though.

Extensions is also my #1 most missed language feature! Wasn't possible before when Dart was dynamically typed, but perhaps now with Dart 2's strong mode we'll see it in future.

> It removes a lot of the baroque from mobile development (no need for the whole RecyclerViewer construction for every list! No Fragments!

The Android API sets the bar really, really low for improvements.

This release follows Airbnb posts describing their deep experience in React Native and why they ended up abandoning it: https://medium.com/airbnb-engineering/sunsetting-react-nativ...

Based on the issues they've had with React Native [1] I believe they would've had a better experience with Dart and Flutter which also has a fast iterative dev experience with a productive language that lets you build both iOS and Android Apps from a single code-base. But in contrast to RN, Dart 2 is statically typed and AOT compiled into native ARM which enables better performance and doesn't have any of the JS VM issues Airbnb kept running into. I also prefer Flutter's x-plat approach of drawing all their widgets with Skia as it also mitigates the UI widget inconsistencies they would've had if they tried to wrap native widgets. Flutter widgets follow Material design by default but can also be themed to look like native iOS widgets (https://flutter.io/widgets/cupertino/).

React Native nails the development experience but is plagued with issues which isn't clear if it's because it's architecturally flawed or that it's just poorly resourced and Facebook only cares about resolving their own issues.

I've been burnt by the lack of support in React Native indiscriminately closing issues, which stopped me from wasting my time reporting any more issues and eventually stopped using React Native altogether.

I've been pleasantly surprised by Flutter, it does what it says on the tin, enables a productive dev environment for creating Native Apps from a single code-base and in contrast to my RN experience their support has been stellar, several team members responded to my queries immediately with solutions and workarounds.

The biggest issue I've run into coming from JS/RN is not being able to use reflection due to iOS's AOT restrictions for which you'll need to use code-gen to workaround. Also I prefer JSX for designing UIs, whilst Dart's object declarations enable a kind of code DSL it's not as composable as using a declarative XML markup where you can freely move widgets around to design UIs. Ultimately I hope they provide a similar language feature for using an XML-like markup as an alternative for (and just transpiles to) object declarations.

  [1] https://medium.com/airbnb-engineering/react-native-at-airbnb-the-technology-dafd0b43838#4b2b

> it's just poorly resourced and Facebook only cares about resolving their own issues.

I'm not sure this is _the_ cause for anything, but it's definitely something that happens. I've seen obvious bugs lingering forgotten on RN just because it's not something they're interested in resolving.

And before someone mentions "open source" some of those are deep structural problems that not anyone can just come and fix since they'd have side effects all over the code base. I've also seen actual fixes lingering for months until someone would decide to review or approve it.

> Facebook only cares about resolving their own issues

One could argue that Google suffers from this weakness as well.

Hasn't been my experience with Flutter, it looks like a well resourced project with a very talented team who are committed at building a high-quality and productive tool for developing Mobile Apps and are actively supporting their existing user base.

React Native feels like an in-house development project they've open sourced but don't have the resources to resolve external issues so they've instituted a policy of routinely indiscriminately closing and signalling their intentions to never fix them and by extension removing any visibility of which issues still exist and from anyone else being able to resolve them either. They've done this for 1000's of issues - not going to invest in a platform plagued with issues that stands no chance of being resolved.

I think proactivity and a knowing a good platform to ask questions in, helps. For some of us, the difficulty is often whether to ask on StackOverflow or to open a bug on Github.

An overflow of Github issues can lead to some issues going unnoticed (depending on whether issues are regularly triaged by a team).

For example, I have a Flutter Android app that has an infinite notification loop bug [1]. I've struggled for many hours (spread over a few weekends) trying to figure out what was wrong. I eventually opened an issue on GH after giving up.

After a few days, I decided to post a question on SO, and someone from the Flutter team saw it. The issue might have gone unnoticed for a bit if I hadn't done so (especially given its obscurity). I believe so because popular projects on GH get a lot of issues, and yours might get buried if someone doesn't pick it up immediately.

The other thing is that when we open issues, and project maintainers try to work with us, we often delay in responding to them. That over time, leads to issue clutter, and probably developer fatigue.

So perhaps we can be better citizens by being more proactive, given that someone who's often paid a lot is taking time to help us with issues.

---

I agree with your point on RN and in-house development.

[0] https://play.google.com/store/apps/details?id=za.co.movingga... [1] https://github.com/flutter/flutter/issues/18524

I'm not referring to technical support questions, I'm referring to actual issues with verifiable repros which works everywhere else (inc. their debugger). They dismiss issues with core functionality like their W3C fetch API not being able to maintain long-running HTTP connections which breaks solutions relying on them like SSE [1]. They originally closed it making it known they have no intentions on ever fixing it and have since locked it preventing anyone else from being able to comment on it either.

RN enables a fast development model but you'll continually skate into an open mine field of issues where you'll end up wasting time on putting out fires and diagnosing issues only to discover they're known issues they have no intentions of fixing so you'll be spending time on implementing workarounds mitigating broken UX experiences in your App instead of focusing on delivering end-user value. Given the 1000's of issues that have received similar treatment I suspect React Native is just an architecturally flawed experiment and why we'll continue to see more users abandoning it. Hopefully they wont have wasted as much effort and resources as Airbnb's multi-year investment who despite having a large enough dev team to maintain their own fork was still unable to make RN work for them.

[1] https://github.com/facebook/react-native/issues/12912

This has been my experience exactly. Flutter devs quickly answering stack overflow or gitter questions.

With React Native I found the little touch 'click' sound wasn't working on Android. Someone had raised a bug and provided a patch years ago but Facebook still hadn't included it.

Similarly, I'm interested in what blockers exist for using Flutter for production/complicated apps

As someone who has spent some time inside the Windows 10 environment working on UWP applications, I always thought that Xamarin would someday be my goto whenever I have the opportunity to dive into Mobile development. I am comfortable with C# and I have always felt happy writing in XAML.

But looking into Flutter, I think it's undeniable how smart this project truly was. Even if it isn't backed by a popular programming language, since Dart obviously does not fall on that category.

Let’s see if it’s smart 10 years from now. Cross platform toolkits that draw their own widgets tend to have a hard time keeping up longer term and Google isn’t really known for the constance regarding project management.

If they “only” pull another AngularJS -> Angular transition. and it’s already a bad thing. If they abandon it, ouch!

Have you looked at Uno?

http://platform.uno/

C# & XAML UWP layer with Xamarin for mobile. The company behind it has been using for a few years to produce apps and recently open sourced it. I'm intrigued and weighing it against Flutter for my next bit of mobile experimentations.

This thing seems to be a layered cake of leaky abstractions. Flutter is actually the opposite.

I'd love to play with Flutter but issues like this keep me at arm's length. Hopefully when this kind of thing is finally resolved I'll be able to give it a closer look.

https://github.com/flutter/flutter/issues/6827

To summarize, Flutter provides no automated or easy means to save/restore state when Android auto-kills the app (e.g. because of low memory). The main problem here is that the `onSaveInstanceState` and `onRestoreInstanceState` lifecycle callbacks require a synchronous response (return value) but the IPC system between Dart and native code is inherently asynchronous.

React Native currently has the very same problem. This is the reason why some very useful native components that require synchronous delegate callbacks (such as UITableView and UICollectionView from iOS) are not available from RN. However, the core team at Facebook is working on a "large re-architecture" that will allow synchronous calls into JS, fixing these issues:

https://facebook.github.io/react-native/blog/2018/06/14/stat...

State restoration pretty damn important too. Say for example, the user goes into multi-window on Android. If they were doing anything important on the screen, that would just be wiped out.

While it's common to restart on all sorts of config changes like multiwindow or layout changes on Android, flutter specifically configures it's android activity to not restart. So going into multiwindow works just fine, and the framework handles redrawing and resizing.

I've been using flutter now for a few months and I love the workflow I can get in, quickly iterating and seeing the changes immediately. A side effect of the hot reloading I found is that I am able to build quickly and not worry about the style until later because I know changing the style is relatively easy and quick to iterate on itself.

If you use VSCode, it really is a first class citizen, which makes me happy as I am most familiar with that editor.

Overall I haven't been this happy with development in a while.

Have you used RN?

Anyone else remembers the original Flutter app that lets you control music with hand gestures? Google bought them and only kept the name apperently.

https://flutterapp.com

Dart's interesting enough if I can actually use it for both Fuchsia and Web [1], but I find the following statement misleading: "Dart’s type system, like the type systems in Java and C#, is sound [2]." Java's type system is not sound [3], nor is C Octothorp's [4]. What gives?

[1] Though what happened with Chrome is a shame: https://news.dartlang.org/2015/03/dart-for-entire-web.html

[2] https://www.dartlang.org/guides/language/sound-dart#what-is-...

[3] https://dev.to/rosstate/java-is-unsound-the-industry-perspec...

[4] https://stackoverflow.com/a/23968075/775282

It might sound stupid, but I'd really like to see flutter for desktop as well. Web too, hell why not?

You may appreciate https://github.com/google/flutter-desktop-embedding

Or this: https://github.com/google/flutter-desktop-embedding

I'm also working on a similar project.

Not sure if you meant to, but you posted the same link.

Whoops sorry - I mistook the link for this one: https://github.com/flutter/engine/wiki/Custom-Flutter-Engine...

If they at least replaced @Override with override keyword, it is not like Dart had to deal with backwards compatibility of 5 language versions.

Has anyone used both Flutter and NativeScript/React Native?

I'd be really curious to hear some experiences and why you prefer one over the other.

I wonder what happened to Rikulo UI cross-platform framework for Dart: http://rikulo.org

I love Dart and used flutter for a few months but once I hit the lack of native support for maps, I had to switch to native iOS development. It was a great learning experience for prototyping quickly but hitting a wall with maps was not OK for any high fidelity app.

With Airbnb’s announcement around React Native, I feel like native dev is still the way to go.

So this is different from the Flutter product I backed on Kickstarter? Confusing...

https://www.kickstarter.com/projects/flutterwireless/flutter...

Is there anything that Dart does particularly well in a project like this that justifies its use over TypeScript?

Check out this blog post from earlier this year: https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf

Is it safe to say, they are probably ramping up the fuchsia development too?

Just noticed that https://flutterstudio.app/ only works properly on Chrome, what a surprise.

Works just fine in Safari and Firefox Nightly for me. Consider reporting your browser configuration to the author? [1]

[also notice that it is in no way affiliated with Flutter and done by somebody in the community]

[1] I can't find any way to contact the author, but here is his blog post about the Studio https://medium.com/@pmutisya/flutter-studio-version-2-41cce1...

I tried, but won't bother with Medium subscription just to post a comment there.

Doesn't work on Edge or FF stable.

Given that flutterstudio.app isn't made by Google, I'm not sure what you're implying.

I am implying that the generation that complained about "This works best on IE" is now responsible for "This works best on Chrome", just now it isn't a problem because Google is cool.

A classic Google again... I hope they fix that, I'm not going to open up Chrome just for this.

It's not Google, actually; this IDE is from a third-party developer.

Reply on news.ycombinator.com