Having tested both, I approve of the fact that CN1 is more complete than Flutter on several aspects: - support of Java/Kotlin, which are familiar languages to many developers (while Dart requires learning a new language) and which allows to "easily" port one of the many libraries developed in these languages to CN1 (and thus to save time), while Dart has a much poorer libs catalog.
- The GUIBuilder that allows to prototype a graphical interface quickly (even if it is quite bugged so I stopped using it for Forms too complex, with more than 5-10 components...) - Better native widgets integration (it is not true that you can't use native widgets with Flutter. See for example their Google Maps widget: https://pub.dartlang.org/packages/map_view . It currently do not support displaying a Google Map within the Flutter widget hierarchy (so it is pretty like the old days of CN1 where you couldn't render a Component on top of a PeerComponent) but this might (and probably will) change in the future... - More platforms supported - Probably better performances (even if, while testing Flutter, it was really fluid, even on low end devices, so performances differences wouldn't really be an issue as both perform well. But I trust you if you say that CN1 performs better (which could be a real advantage if CN1 ever integrate a real 2D and 3D drawing api (I don't know if a port from the one from libgdx is conceivable in a distant future) to allow the developpment of AR apps and 2D/3D games). Bytheway I don't think that the Flutter rendering engine is more recent that the one of CN1. If I am not mistaken, it is base on Skia which is more than 15 years old: https://en.wikipedia.org/wiki/Skia_Graphics_Engine ;-) That beeing said, Flutter clearly outperforms CN1 in term of UI offer. Having a complete set of widgets with beautifull default rendering (like the automatic border shadow arround components depending on their elevation property in material design widgets, the animations on pretty much any component interaction... These are "details" that really makes a GUI nice to be used by the end user) is a real plus. Having tried to get an "acceptable" GUI using CN1 default components, I must say that some components like Slider, OnOffSwitch... where a pain to work with. I completely understand that the CN1 team is a small team and do not have the ressources Flutter has in terms of developpers (and the CN1 features and support are pretty much amazing for such a small team) but I think the UI is clearly something you should focus on in the near future (as, in the end, having a beautifull app rather than a more raw one is often what would attract users to use your app and keep using it, So it is a essential to any developper). This is the reason why I started developping a set of my own components based on the material design guidelines (for now I have Slider, OnOffswitch, LinearProgressIndicator and CircularProgressIndicator implemented and I am working on the MD Dialog widget) so as a FlexLayout and androidGridLayout Layout managers. So I am investing some time on CN1 because I think in the long term, it is a better solution than Flutter (even if I am still keeping an eye on Flutter to see how it evolves ;-) ) Appart from that, I would also love to see easy on-device debugging coming to CN1. And, in what concerns local builds, it might not be too difficult to do with CN1 but the lack of basic documentation makes it really hard for any developper wanting to jump into CN1 (it took me 2 complete days to create a java script that can convert any CN1 project into an android studio gradle project file, essentially because I did not find any documentation to start with (there is some old script and "tutorial" in Steve's blog for iOS but it is deprecated as it do not use parparVM. And for android there is just no information at all) and some parts are a bit tricky (essentially the Stub glue code for native cn1libs)). I think you should have made the course on how to build offline from sources (https://www.codenameone.com/blog/use-open-source-build-offline.html) part of the free courses bundle if you want to attract new developpers to CN1 (that could be affraid of beeing dependent on the CN1 build cloud service) On Tuesday, May 8, 2018 at 9:23:02 AM UTC+2, Shai Almog wrote: > They spent a lot more resources on marketing flutter than I had > anticipated for sure. When I wrote that no one was using it and by now > that's no longer the case. > They are still a tiny community when compared to react native and other > industry leaders but Google has roughly 15x the developers we have working > on flutter and it shows. > > Despite that a lot of what I said still holds. > > > CN1 apps are smaller, almost certainly not faster in terms of rendering > > I think we are as fast when the app uses the right API's. Compiling to ARM > doesn't give and performance advantage since that happens anyway whether > you use Java or xcode. > I'm sure our VM is MUCH faster especially in the interconnect where > flutter works with an event dispatch system... > > There are probably cases were their rendering system can seem smoother as > they give up on deep integration with native peers thus they can make some > assumptions we can't. They also wrote their rendering engine years after we > did so they could make assumptions we couldn't. If we had unlimited > resources I'd rewrite our rendering engines but with the current state I > think it's better to focus on local optimizations & making better > performance profiling tools. > > Other than that flutters asynchronous nature and lack of threads put it at > a huge performance disadvantage as native OS's don't work that way. > > > Full integration with native OS including native widgets > > This is crucial for things like camerakit, maps etc. You might not need it > right now but if you start developing an app and you need a native widget > this can become a huge problem. > > > Except for Application Loader you need a Mac > > We would have added application loader support years ago if that was the > case. You can use Mac In Cloud and similar services in the free quota. > Since application loader takes minutes it's practical to do that with a > mac in cloud account. > > Still it's something we might offer, the bigger blocker here is the need > for an apple developer account. > > > Flutter is catching up. > > In some degrees yes but in other degrees it's starting to hit that wall > where adding more engineers makes them go back. > Flutter has been in development for 3-4 years by now, it's not new. It has > a lot to catch up with. > > > Simple to debug, test, run and profile on the device > > That's one thing I think we really need. Right now on-device-debugging > isn't easy with Codename One and it's something we can technically fix. We > can make the on device debugging experience even better than it is with > flutter. > > > Building for free on the machines I already own - also means I can > choose what version to build against for the life of the project. > > You can do that with the open source project, albeit it's not as simple as > it is with flutter but not much harder. > > I would add another advantage that they have and that's better looking > apps by default. We need to invest a lot in that area which is a real pain > point. > > -- You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to codenameone-discussions+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/codenameone-discussions. To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/04d326c6-cff5-4510-a34d-736c6876544e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
