Hacker News new | comments | ask | show | jobs | submit login

For some reason the website fails to prominently mention the two defining characteristics: it's based on Dart and it uses its own widget implementation.

Honestly, between the use of a relatively exotic language of dubious quality with types that are "optional and unsound" (https://www.dartlang.org/articles/why-dart-types/), their custom widget implementation that who knows how well is going to work, and lack of web support, it doesn't seem very attractive.

React-native seems a much safer bet.




(disclaimer: I work on the Flutter team.)

It's true that Dart is an optionally-typed system, and that type annotations are ignored at runtime. That may seem scary at first, but we built an analyzer that statically analyzes your program and gives you feedback (errors, warnings, and hints).

Dart is used at Google to build very big and complex apps, and our engineers use the analyzer in their build/CI systems to check their program. The analyzer is also wired into their IDEs. So they get feedback if a method doesn't exist, or you are trying to pass a variable into a method that is expecting something else.

The Dart team is also working on an optional analyzer feature called "strong mode", which does even more static checking. In strong mode, you can't write code that is incorrectly typed (but, you can still write code that is dynamically typed, if you want to).

Our experience, at least internally, is that as your program matures and grows in complexity, developers appreciate the extra checks provided by strong mode. The win is that it's something you can turn on later, when you're ready. Early on in the program's development, you are probably refactoring a lot and you don't want to bother with strong mode. This scalability is a win for us.


So for those of use outside of Google, it's not a "smooth" environment to work in. I wish we have the tools that you have. Are they available outside of Google?


Yes, strong mode and the Dart analyzer are all available in the Dart SDK. (Strong mode is in development, but it's still quite useful.)


Yes, but do we also get the custom IDE and whatnot? I'd really like to play with Dart, but I hope it isn't a dead-end for non-Google projects.


Yes we get all of the whatnots ;)

The developers on this project are using Atom https://github.com/atom/atom/ for their day to day Dart development. They are contributing to the Dart plugin https://github.com/dart-atom/dartlang, and implementing a Flutter specific plugin https://github.com/flutter/atom-flutter-dev. The Dart SDK https://github.com/dart-lang/sdk provides the basic source code analysis tools. All of these projects are open source, on github, and see regular commits.


Dart + "Unfortunately, due to iOS restrictions, updating your Flutter app over the network is not possible" means 100% no thanks from me.

I don't want another language in my build ecosystem. Between javascript (necessary for web), objective-C, Java, C++ for shared stuff, adding another one that provides no genuinely useful semantics or performance implications is a sheer non-starter.


> Dart + "Unfortunately, due to iOS restrictions, updating your Flutter app over the network is not possible" means 100% no thanks from me.

Indeed. One of _the_ biggest selling points of React Native is the promise of near-instant over-the-air updates for iOS and Android.


How do you do things like text input without native widget integration?

Are you familiar with Codename One (https://www.codenameone.com/ )?

It seems to me that what we implemented there is roughly in the same direction although not as mature.


Oh great news on the strong mode. One of my biggest issues with Dart is it not being actually statically typed.

Could you potentially generate smaller js libraries if the language was statically typed?


A lot of the push for strong mode comes from a project to create a "plain JavaScript" compiler for Dart: https://github.com/dart-lang/dev_compiler


I am sorry but part of your comment smells a little bit like a red herring, what is the language of react-native? Ah. Website clearly stresses that the main point of flutter is to build cross platform high performance applications. I think language of choice is of lower importance. There are still many developers who would not touch javascript with a ten foot pole but I can see them using a saner language like Dart. It may find its place.


It's definitely saner to use something that has a community and traction. You definitely can't argue that Dart is a saner choice of language than JavaScript. After all if they'd chosen JavaScript, Dart could be useable via compilation. So would a whole bunch of other more commonly known and probably saner languages.


Sane by your definition is not the same as my definition then. A community can't grow if people aren't a part of it. Using Dart is one of the best decisions I have made in my life.


I gather you're already compiling it to JavaScript, though? Otherwise your audience would be very limited.

The decision to use Dart for this project seems to me like an attempt to find a lifeline for it. That's fair enough, but it could ultimately be a highly limiting factor and the reason it doesn't go anywhere. That would be a shame as cross-platform frameworks need to keep evolving to be more useable and performant.


"There are still many developers who would not touch javascript with a ten foot pole but I can see them using a saner language like Dart." haha sir you need some reality check.


Anecdotal, but I'm a mobile developer who also dabbles with some web apps and I hate Javascript.


I used to hate JavaScript. It is a very imperfect language, but many of its pitfalls come from widespread mediocre practices and craftsmanship, rather than the language's quirks.


But do you program in Dart? My point is, when given a choice I can't see a reason why someone who would invest their precious time to learn some relatively obscure language like Dart would NOT learn javascript. Also hating something and not using it are two different things. You say you hate javascript but you probably do use javascript.


Funny you say that given JavaScript's immense popularity. JS is by far the most popular and easy to learn language out there and has a large, inclusive community. There are little reasons to knock JS these days, especially with the upcoming language extensions and powerful tools like Babel.

React Native in my eyes has done a fantastic job of demonstrating highly performant JS driven applications that are accessible to tons of developers. An added bonus is the luxury of bundling in millions of existing NPM modules along with existing native modules. Facebook in my eyes is doing better at solving the code portability problem than Google, they are extremely focused, whereas Google, they want us to build things in a million different ways. Which direction do we go? Web components? Angular + Typescript? Dart + Flutter? Or maybe some new development far on the horizon that is the new way?


> There are still many developers who would not touch javascript with a ten foot pole but I can see them using a saner language like Dart.

lmao what universe do you live in


He's in the one that uses proper grammar and usage on respected forums.

If all the browsers supported a real programming language in their runtime, JS would die like Flash is doing.


Web Assembly is on the horizon so we will see. In the meantime, how do you explain meteoritic the rise of JS? Why do devs choose to use tools like Babel over Emscripten? Why is it that companies like Netflix, PayPal and LinkedIn, etc all utilize and embrace NodeJS? Why is Facebook so interested in using JS for future apps rather than native languages? Your theory is very short sighted and based in fantasy


how idealistic


Apparently the same one I'm living in. I avoid Javascript as much as possible.


Just what I was thinking.

What problem is this trying to solve?

The big draw of React-native is that I can reuse largely the same core code everywhere, and for the parts I can't (mobile UI), I'm at least working in a language that everyone on my team is familiar with, with the same pattern as elsewhere (react/flux).

This to me sits in a weird middle ground between RoboVM/Xamarin and Cordova, but has the benefits of neither (it uses a language that I'm not already familiar with, and doesn't give me access to native controls).

Am I being unfair? (Is there a killer feature here I'm not seeing, beyond being backed by Google?)


I've only had a short look at this but here are my impressions :

It doesn't pack a huge VM/class library like RoboVM/Xamarin and doesn't try to gap two VMs/GC like Xamarin on Android - instead it uses IPC for talking to system services using it's custom service definition language to define the IPC API/schema in cross language way.

Dynamic language/custom VM lets them do a better job at development experience (dynamic code reloading) as opposed to buggy/complex one you get from trying to statically compile bytecode or bridging two VMs to share objects.

IPC architecture then lets you write performance parts in portable native code (eg. C/C++/Rust) or system specific language (eg. Java/Swift/Objective-C) and it should be easier to make cross platform - hiding the dirty FFI crap.

Dart is much closer to C# than you think, go look at some examples - it's quite a productive language from my experience with it so far.

Custom GUI framework means it doesn't behave/look the same as native framework (just like webview tech) but at the same time it can also mean higher performance (certainly better than WebView), consistent behavior between platforms and versions (faster development), etc.

Overall I like it, I can see a GUI framework on same tech built for desktop (custom widgets but same rendering principles) and doing client side development in Dart sounds great - fast prototyping and iteration because of it's dynamic nature but the optional type system gives you same guarantees as C#/Java type systems.


I totally agree with you with regards to the language itself sharing similarities with C#, and you make a good point about avoiding all the FFI native calls hassle.

I couldn't find a whole lot of independent benchmarks but I'd suspect that at least in Chrome, it does outperform V8.

I guess I'm just not the target developer for this, though. If I want optional static types I can implement typescript incrementally into my existing stack, while retaining the code portability benefits. For desktop apps, NW.js is aiming to plug that gap, and I wouldn't have to give up my npm modules.

Another poster mentioned waiting until it sees a push at Google I/O before taking it seriously. I'd settle for them just to explain the problem case that drove it's development.

EDIT: I hadn't spotted harryf's reply below that makes the point about transparency better than I have above, kudos.


> It doesn't pack a huge VM/class library like RoboVM/Xamarin and doesn't try to gap two VMs/GC like Xamarin on Android - instead it uses IPC for talking to system services using it's custom service definition language to define the IPC API/schema in cross language way.

A minimal "Hello World" RoboVM app adds 3mb per CPU slice. I'd assume packaging the Dart VM has a similar footprint.


All of the above was answered by codenameone.com already. And unlike flutter it's unlikely to be spring cleaned anytime soon.


Not sure if being backed by Google is a good thing. They tend to abandon their publically available code very quickly, see PlayN, Liquifun, etc.


I've heard tales of Google engineers creating tools and frameworks largely as a way to attract positive performance reviews and enable promotions. That said there projects like Google Web Toolkit that have a long history and well cared for. Perhaps some transparency would help i.e. instead of "this was made by Google" how about "was made by this team at Google for these reasons and here's where we see it going"


And still Google Web Toolkit slowly gets deprecated.

The problem on GWT is that it builds too slow on bigger Apps, while ScalaJS builds even faster. Also the compiler needs to be reworked on lot's of side, I'm not sure if 2.6, 2.7 will handle all these problems.

But I don't think that GWT gets a 3.0. But thats mostly caused by the fact that this is a really really old technology and there are newer technologies which google builds upon. (AngularJS). They replaced lots of GWT Things already (Cloud Console, Google Apps Console, App Engine Console).


Gwt mostly got abandoned. Far better solutions like teavm that we use at Codename One are available. GWT is now maintained by the community and not by Google.


Actually it does mention that briefly in "What are the origins of Flutter?"


Yes that section exactly answers his question.


I wander why Qt/QML doesn't get much attention.


QML is slow, you only get the compiler in the commercial version.

Still no proper support for mobile platforms. You basically have to write most of the bindings yourself. Specially a pain in Android, given JNI.

Only QML widgets get some platform theme support, not the C++ ones, so you need to add the QML engine to the set of libraries to pack.

Also you are supposed to code all native UI behaviours yourself, thus having more work than an hybrid development of native mobile OS language (views) + portable C++ libraries (business logic).

If you pack Qt libraries with your application it is around 30 MB for the runtime dependencies. You can also scare the user by asking them to download the libraries as separate app instead.

I got my demo application using Java + C++ and C++/CX + C++ around 5 MB.

Finally if you look at the set of exposed platform APIs across all mobile OSes, they are way behind Xamarin and their commercial licenses are much more expensive.


None of answers is correct in my opinion. I follow Qt/Gtk news from old days (2005-4). The problem with Qt right now is its direction is not clear , all people remember when Qt was only C++ widget library.after a while because of one person decision they change whole direction to QML and RICH application development, and who knows ? maybe they changed it tomorrow again . at least behind react and and flutter and cordova there is big name


They seem trying to cater to the web folks with QML becoming the main focus and C++ for the infrastructure support.

This is I idea I as an outsider get from the talks at Qt events and the various iterations of QML and WebViews that took place in the 5.x releases.


I have tried.The most simple widget app take about 15M size. the learning curve of QT framework is very steep,although Qml is very simple.


i think is because most people don't know how far Qt has come in terms of mobile development.

most people hear Qt and immediately think about heavy desktop applications. its a shame really, Qt is pretty awesome atm for mobile development.


Maybe C++ is also a showstopper for many?


while that is certainly true, using QML you can build native apps using almost only javascript (if you want), most people have no idea about that too i suppose.

but i agree, for many people C++ is a no-no, even though Qt C++ is pretty straightforward with all the helpers they provide (like the parent-child memory management).


The thing with QML: I think you still need C++ for more complex app logic.


You can write all of your Qt logic in javascript if you want to. It will probalbly still be much faster than a browser. But the thing is that Qt allows you to write your logic (and your ui) in C++ if you need to. It gives you somewhere to go when performance is an issue. And on mobile or embedded there is a high chance that only a compiled, no-vm, no-gc language like C/C++ or Objective C or Rust will give you the performance you need. One thing is for sure: If you have to build a cross platform native application be sure to first prototype the performance and processor/battery use of your technology choice. Even if you don't choose something like Qt at least you can write your backend in C++ and write a different native front end for each OS. But if you use e.g. web technology and don't prototype first there will be absolutely fire escape later. A lot of people have learned this the hard way.


> You can write all of your Qt logic in javascript if you want to. ... But the thing is that Qt allows you to write your logic (and your ui) in C++ if you need to.

Maybe that sounds appealing to some, but for me is just choosing between two evils. Unsafe dynamic language on one side - kitchen-sink low-level language on the other side.

I personally would like something in between, but still cross platform. F# with Xamarin looks most appealing to me, but Xamarin is unfortunately not free, so...


All these QML/js stuff smells rather artificially put (into Qt) to me... I mean, why not have a functionality to define the scene (and not just a logic) in pure C++? I think one reason for QML/js is to (try) attract contemporary js/web devs.


Last time I checked (Qt 5.3), I was forced to duplicate native widgets on my own, and write my own Framework wrappers on Android, with zero support for Windows Store applications.

From what I could understand in the Qt 5.5 release notes, this has hardly changed.


QML is elegant for GUI design.


I think it should support platform own widget or an abstract UI framwork implemented by playform api like facebook's react native. Flutter's own widget implementation can make simple apps,but it is more difficult to implement native style UI with rich user experience (animation,touch...) provided by platform api. Looking at own widget implementations such as Delphi/firemonkey,Qt/Qml,JUCE...,they are far behind native widgets


Or Ionic which can be used by AngularJS developers easily.

http://ionic.io/


C++ 76.4%, Python 10.6%, Dart 5.7%, Java 3.0%, Objective-C 1.7%, C 1.2%, Other 1.4%

source: https://github.com/flutter/engine


Ho come on, that's the flutter sources. Why is it so popular on HN to "debunk" points with irrelevant statistics? As if numbers win arguments no matter what?

The point is that Flutter application code is intended to be 100% Dart. Just like React Native application code is 100% JavaScript (and React Native itself isn't).


Just the raw statistics from github plus the direct link. Don't over-interpret it.

What you mean is there: https://github.com/flutter/flutter (99.1% Dart)




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: