7 ms·

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

by devit 11y ago

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

headmelted 11y ago
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?)
- moonchrome 11y ago
  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.
  - badlogic 11y ago
    > 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.
  - headmelted 11y ago
    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.
  - invalidname 11y ago
    All of the above was answered by codenameone.com already. And unlike flutter it's unlikely to be spring cleaned anytime soon.
- badlogic 11y ago
  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.
  - harryf 11y ago
    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"
    - merb 11y ago
      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).
      - invalidname 11y ago
        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.
    - nogridbag 11y ago
      Actually it does mention that briefly in "What are the origins of Flutter?"
      - positr0n 11y ago
        Yes that section exactly answers his question.
lugus35 11y ago
Or Ionic which can be used by AngularJS developers easily. http://ionic.io/ http://ionic.io/
zerr 11y ago
I wander why Qt/QML doesn't get much attention.
- boost_ 11y ago
  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.
  - oblio 11y ago
    Maybe C++ is also a showstopper for many?
    - boost_ 11y ago
      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).
      - oblio 11y ago
        The thing with QML: I think you still need C++ for more complex app logic.
        discreteevent 11y ago
        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.
mda 11y ago
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.
- talldan 11y ago
  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.
  - kaendfinger 11y ago
    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.
    - talldan 11y ago
      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.
- andrewmcwatters 11y ago
  > 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
forumuid 11y ago
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
frik 11y ago
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 https://github.com/flutter/engine
- skrebbel 11y ago
  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).
  - frik 11y ago
    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 https://github.com/flutter/flutter (99.1% Dart)
sethladd 11y ago
(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.
- banachtarski 11y ago
  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.
  - robertknight 11y ago
    > 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.
- Dnguyen 11y ago
  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?

by devit 11y ago

headmelted 11y ago

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?)

moonchrome 11y ago
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.
- badlogic 11y ago
  > 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.
- headmelted 11y ago
  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.
- invalidname 11y ago
  All of the above was answered by codenameone.com already. And unlike flutter it's unlikely to be spring cleaned anytime soon.
badlogic 11y ago
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.
- harryf 11y ago
  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"
  - merb 11y ago
    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).
    - invalidname 11y ago
      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.
  - nogridbag 11y ago
    Actually it does mention that briefly in "What are the origins of Flutter?"
    - positr0n 11y ago
      Yes that section exactly answers his question.

lugus35 11y ago

Or Ionic which can be used by AngularJS developers easily. http://ionic.io/ http://ionic.io/

zerr 11y ago

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

boost_ 11y ago
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.
- oblio 11y ago
  Maybe C++ is also a showstopper for many?
  - boost_ 11y ago
    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).
    - oblio 11y ago
      The thing with QML: I think you still need C++ for more complex app logic.
      - discreteevent 11y ago
        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.

mda 11y ago

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.

talldan 11y ago
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.
- kaendfinger 11y ago
  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.
  - talldan 11y ago
    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.
andrewmcwatters 11y ago
> 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

forumuid 11y ago

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

frik 11y ago

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 https://github.com/flutter/engine

skrebbel 11y ago
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).
- frik 11y ago
  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 https://github.com/flutter/flutter (99.1% Dart)

sethladd 11y ago

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

banachtarski 11y ago
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.
- robertknight 11y ago
  > 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.
Dnguyen 11y ago
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?