4 ms·

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

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

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