Hixie

(Flutter TL here)

I encourage you to compare our iOS ("cupertino") widgets with the UiKit ones. We've still got many to implement, but I think we have the fidelity pretty high for the ones we've implemented. If you disagree please do file bugs, we care very much about fidelity.

I use Emacs, and I'm one of the lead contributors to Flutter. Hopefully that answers your question. :-)

We have various tools that can help you configure your setup without an IDE. For example, `flutter run` listens to SIGUSR1 to do a hot reload, `flutter analyze` has a flag to write the latest results to a file, etc.

If someone implements one. :-)

> How fast is Dart 2?

Not really sure how to answer that exactly. Fast enough? :-) Performance is one of our top priorities for Flutter (basically priority #2 after "correctness"). There's still plenty of opportunity to optimize, though.

Honestly, so far we haven't found that Dart's intrinsic performance is an issue for Flutter. When we've investigated performance issues in the past, it's usually turned out to be around graphics or bad algorithms in the framework. Our most recent performance issue was related to compiling shaders on the fly; turns out if your shaders are super-optimised to render scenes really quickly, they can end up being so expensive to compile in the first place that you miss a frame or two when you first try to show the scene.

> I heard here that it enforces static typing

Sort of. It's more that the compiler does type inference if you don't specify types (as opposed to just not having any static types). You can still explicitly specify "dynamic" as a type, and generally if you just don't mention types it feels dynamic, still. (The Flutter framework itself always specifies types explicitly, because that helps catch bugs earlier.)

> I assume for performance reasons.

As I understand it, it's partly for correctness reasons -- it makes it much easier to catch bugs -- and partly for performance reasons.

Yeah, Swift was on our list of languages we considered. At the time, Swift wasn't open source and it wasn't clear what Apple's plans for the language were, so we didn't do a deep dive on its technology. It's possible that if we were to start over today that we would consider Swift more seriously.

Fuchsia doesn't require using Flutter. Flutter is just one possible UI framework you can use with Fuchsia.

Well hopefully I won't make the same mistakes this time. :-)

I don't have the link handy right now but someone actually implemented an XML-ish syntax transpiler so that they can write code in XML-ish syntax and have it generate the corresponding Dart code for Flutter. So if that's what you prefer, you can totally do that.

We're a small team, so we have to start somewhere. Mobile is where there's a real lack of good solutions right now, so that's where we started. If we're successful and our team grows, or if we get contributions from the community, I could totally see us expanding into other areas. The engine itself is written to have an embedding API so if you're familiar with C++ you could totally start creating a non-mobile solution with Flutter today.

FWIW what we've seen in usability studies is that people who know JavaScript can pick up Dart without even noticing. (Literally, after an hour in a usability study we'd ask people what language they'd been using and they would respond with surprise, having not even noticed that it was a new language.)

Regarding trusting us to support a new framework, Flutter is entirely open source, so if Google every gives up, the code is still out there and can be maintained. Having said that, since AdWords is starting to use Flutter, it's probably going to be supported for a while.

I believe we have a sample app called "Flutter Gallery" in the app stores. See https://play.google.com/store/apps/details?id=io.flutter.gal...

Dart2 is optionally typed in that you don't have to enter the types. It's different from original Dart in that previously, if you didn't enter the type Dart would assume you meant "dynamic", whereas Dart2 will infer the type based on what you are actually doing. The net result is that the compiler/analyzer will catch more bugs but the code looks more or less the same.

Flutter originally used JavaScript, we ended up switching to Dart after studying dozens of languages. Our choice of Dart very much did not come from wanting to support Dart, in fact, originally, I think the Dart team was a bit confused about what we were doing. :-) You can see this a bit in how, for example, we started with out own style guide and only over time have slowly converged it to match Dart's style guide (it still isn't 100% merged).

Basically because a UI framework's usability is directly related to how idiomatic it feels. So if you write a UI framework in C for C, it will feel nicer than a UI framework in Python for C, or in C for Python. This directly translates into how productive developers can be using the framework, which is one of our top priorities.

When we started, about 3 years ago now, we looked at many languages (dozens of them) and, objectively, Dart was the best fit for what we wanted to build.

At the time, "we" was a few people from the Chrome team, and me (HTML spec editor at the time). We were all Web people, whose only impression of Dart was somewhat like negative comments in the thread here. When we studied each language, though, we found that impression was really not relevant to Dart as a language for mobile, and in fact it fared better in our comparisons than the other languages we looked at.

I think it would make a lot of sense for people to create other projects very similar to Flutter where Skia is combined not with the Dart VM but with other languages, and for the Flutter framework to be ported -- in a language-idiomatic manner -- to those other languages. I can totally imagine, for instance, a TypeScript-based UI framework like Flutter, or a Kotlin-based UI framework like Flutter, or a Swift-based UI framework like Flutter. After all, in many ways, Flutter is just an evolution of previous UI frameworks like React, DOM/CSS, UIKit, and Android views.

Let a thousand flowers bloom. One day I hope I can write my mobile apps in FreePascal using a reactive framework with a design evolved from Flutter. :-)

(Flutter TL here, I wrote large parts of the Flutter framework.)

Dart really is a big part of why the Flutter framework is as it is. Obviously you could design similar frameworks in other languages and have similar results, but there's really a very nice synergy between Dart's design and the Flutter framework, all the way down to small details like how garbage collection works in Dart vs how the framework happens to allocate objects.

In profiles we see about half the time spent in Dart and half spent in the underlying graphics bindings (it varies wildly per scene, obviously, but as a first approximation this is roughly true). If Dart had been less efficient, then we'd quickly see it in the profiles as a problem. I doubt other languages could have achieved similar results without sacrificing usabilty (e.g. we could get faster performance using C++, probably, but good luck writing a usable reactive framework with manual memory management).

https://flutter.io/platform-channels/ is intended to make it easy to integrate with many existing "native" (OEM-side) third-party libraries.

There's also a surprisingly large number of pure Dart packages. See pub.dartlang.org.

Flutter is just an open source project. You are certainly welcome to use it (and maybe even contribute to it), but it isn't in any way something that Google wants to force anyone to use. We hope people like it and want to use it, that's all.

The problem with your argument is that "every single mobile app worth its salt" will want to handle slow networks by showing pretty progress indicators, and just calling a single method won't do that.

Having said that, we definitely need to make Flutter's network story better. This isn't one of our near-term priorities, but medium term I plan to implement a library that abstracts away issues like unreliable networks, offline, etc, and has a very simple API.

Flutter has a concept called "plugins" that specifically is intended to let you use existing platform libraries. That's how we implement things like notifications. Dart code talks to the OEM side that is implemented using the native library. See https://flutter.io/platform-channels/

A lot of those are things we've fixed since we published that app. We're just not very good about publishing updates to the play store. I'll see if we can get an update out soon.

(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.

(I'm on the Flutter team)

We're actively working on accessibility right now. It's one of our top priorities for the next few months.

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

(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.

The WHATWG had a spec-compliant HTML parser in Pascal, if you need it. Currently only does UTF-8 but that should be fixable.

My favourite language in FreePascal's dialect of ObjectPascal (which is largely derived from the work Borland did with Delphi, which itself is largely derived from Borland's Turbo Pascal).

It has all the benefits of a modern language -- strong typing, generics, operator overloading, objects, metaclasses, dynamic arrays, interfaces, RTTI, dynamic dispatch, method pointers, type helpers, true modules, fast compile times, preprocessor directives, pretty large set of libraries from the community, etc -- and all the benefits of a compiled language -- compiles to pretty small binaries, small memory footprint at runtime, tight control over memory allocation and layout, trivial ability to shell out to assembler when necessary, etc. It builds to pretty much every platform under the sun -- Mac, Windows, Linux, Android, iOS, MSDOS, OS/2, BeOS, Netware, you name it.

Some of its features are features I've rarely seen in 'fashionable' languages. For example the way classes and metaclasses work in FreePascal is great. You can pass classes around by value, constructors can be virtual, even static methods can be virtual.

In many ways it's really a better C++. For example, what I just said about metaclasses. It has native support for strings. The declaration part of a module (unit interface) is separate from its implementation, so it's easy to get an overview of what is exported from a module, but it's in the same file and is a first-class-citizen of the language, unlike C++ header files. The syntax also makes a lot more sense than C-like languages. For example, there's an explicit keyword to introduce a function, and constructors are named rather than using the type name. (These don't sound like interesting features until you're trying to navigate the source and you find that searching for a method becomes far easier, or you're trying to copy/paste a class and you find you don't have to worry about renaming constructors, stuff like that.) It doesn't even have to link in a libc, it has its own RTL. (It can link in a libc if you want to use some C or C++ libraries with it though.)

There's aspects of it that are a bit crufty from having decades of legacy, but it's probably still better than C++ in that regard.

I don't really know why Pascal derivatives haven't taken off more.

At work I use Dart, which has many of the benefits I listed above, but in the form of a GC'ed VM-hosted language. Dart's a much newer language, though, so regardless of its usage it's probably too early to know if it will end up in the "unfashionable" category. Dart has all kinds of cool features like the ".." operator for chaining, the "??=" operator for assignment-if-null, the "with" feature for doing composition rather than inheritance, etc. Also very readable.

The HTML spec's preprocessor is written in FreePascal: https://github.com/whatwg/wattsi

There's no DRM on that page, it's just a Web page. Just copy and paste the content. "Save as HTML". Print to PDF. Whatever floats your boat. :-)

But (as the OP says) you can have browser tolerance without leaving it undefined.

HTML (and the Web in general) has many, many examples of this, for example the way we parse <i><b>x</i></b> is required to be compatible with pages that relied on the way early browsers did it. In fact almost all of the Web's quirks are because of this.

Please do. One of the goals of writing the contemporary HTML spec was to make it easier to make a Web browser by actually defining all the difficult things that browsers have to do. (It used to be really hard to make a browser because literally half the work was reverse-engineering other browsers.)