5 ms·

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 fo

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.

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.