hot reload on native simulators?

[Jaanus Hansen]

Hi!

it looks like, that Google has released a direct competition for CN1:

https://flutter.io

The frameworks have quite similar approaches - both use canvas to draw the app and compile to native code.

But Flutter tooling support seems a bit better - it has hot reload support, which shows code changes on native simulators.

I wonder, if CN1 could also somehow support hot reloads, I am getting a bit annoyed, that it takes so much time, before I can see how my code change looks on native device...

Jaanus Hansen

[Shai Almog]

Hi,
flutter isn't a product from google. It's a test balloon from the Dart team. The fact that Googles Android team makes fun of WORA tools and have picked Kotlin over Dart is pretty much an indication of how this isn't a "product from Google". In a large org like Google a Director can just launch nonsense like this with no approval from management or any real direction. Since it's alpha it can be abandoned like GWT, Google Code, Chrome App Store etc.

We support live code updates in our simulator and have supported that since launch. We'll support it on the devices when we release the on-device-debugging support which I would hope to do in 2018.

Flutter is roughly 7-8 years behind us and amusingly enough it's architecture is significantly inferior on Android as it needs to traverse the slow JNI bridge when communicating with "native Java". Here are just a few things we do better:

- Smaller more native applications and probably faster - this is especially true on Android where we use the native Java support
- Full integration with native OS including native widgets
- More platforms - Desktop, Windows, JavaScript
- No need for a Mac, we work on Linux/Windows
- Kotlin & Java tooling is years ahead of Dart
- Better overall tooling - GUI builder, CSS/Theming tools
- More documentation and online tutorials - real world applications

If flutter wasn't mistakenly perceived as a product from Google people wouldn't give it the time of day.

[nickk...@gmail.com]

Strong words Shai, I don't know if you think anything has changed during 2018 regarding Flutter.

I've been evaluating it recently and there are a lot of things I like about it and while its certainly beta (with a humble version 0.35) it already has produced apps that have been featured on the app stores and look and run beautifully.

The main issues I have with CN1 are the slow cycle involved in order to get changes onto the device and the lack of insight into what's going on once it is on the device. With Flutter both of those have been addressed but your points are valid. Here are my thoughts in order with notes:

- Smaller more native applications and probably faster - this is especially true on Android where we use the native Java support

CN1 apps are smaller, almost certainly not faster in terms of rendering and that these days separates good apps from great apps, totally responsive UI, fast smooth animations. I'd be interested to see benchmarks in terms of CPU heavy work. Flutter runs on a C++ engine under the hood and compiles to native ARM

- Full integration with native OS including native widgets

CN1 has this but using it is complex, to get the full benefit from CN1's WORA you DON'T use native widgets if at all possible. I believe this has improved particularly around the maps but I got burnt in the early days of PeerComponent and have been weary of getting back to it since. I'm not sure what benefit Native widgets provide and Flutter has a complete Material design theme and an iOS one both of which produce a more modern default look than CN1 without native widgets. In terms of integration with the native OS for other functionality the approach between CN1 and Flutter to get into the native code is broadly similar in concept.

- More platforms - Desktop, Windows, JavaScript

Fair enough. I don't want or need to support other platforms, and can't justify the subscription level required for JavaScript support anyway. If these platforms are required CN1 provides them and Flutter does not.

 - No need for a Mac, we work on Linux/Windows

Except for Application Loader you need a Mac anyway and if you already need one then using one and getting hot reload onto iOS devices instead of minutes long builds to iterate you may as well use it. The build times for iOS is one of the pain points for using CN1 and the fact that despite the goal of WORA you simply can't make any non-trivial app without finding quirks between platforms and to get to the bottom of them fast iteration, on-device debugging and profiling are key.

- Kotlin & Java tooling is years ahead of Dart

Yes, and Dart is an obscure language with Flutter really its only main use outside of Google. 

- Better overall tooling - GUI builder, CSS/Theming tools

This is one of the things that concerns me about Flutter (along with Dart). I haven't yet seen how complex it will be to modify the design of a functioning Flutter app. In CN1 it is possible to keep the layout and theming separate from the logic to a good extent which doesn't seem to be the Flutter way.

 - More documentation and online tutorials - real world applications

Flutter is catching up.

 

I've only recently started looking into Flutter and as it immediately addresses the pain points I have with CN1 its something I'm going to continue to look in to. I highly doubt that they are 7-8 years behind CN1. I think Flutter will be giving React Native a run for its money by the end of this year, for an 11 month old project it has a lot going for it and its current shortcomings are understandable based on how young it is AND that it uses an obscure / new language. My main concerns with Flutter are:

1. Dart. Kotlin seems better than Dart on first impressions and of course the Java ecosystem has years worth of existing solutions that Dart just doesn't have.

2. The GUI building and themeing being incorporated in amongst the logic in deeply nested and bracketed widget definitions. Seems like refactoring and reskinning will be much more complicated.

3. The native bridge being at least as complicated if not more so as CN1's. Compare to Multi-OS Engine (which has a much longer list of concerns!) where iOS libraries and frameworks are automatically wrapped and then fully available in Java with very little development work. 

Things I like are:

1. Lightning fast performance and also development due to hot reload

2. Simple to debug, test, run and profile on the device - you can trigger performance overlays on the device from the IDE, update UI code and see the changes in under a second, observe the DartVM from your dev machine. All of these things are only possible in CN1 on the simulator

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

As always its a case of picking the right tools for the right job and keeping a broad view on what's available, but I think Flutter is one to watch this year.

[Shai Almog]

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.

[Thomas]

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)

[Shai Almog]

Thanks for the feedback. I agree, the default look is the biggest pain point. It's also a far higher priority than on-device-debugging.

Check out this guy for offline build on Android: https://groups.google.com/d/msg/codenameone-discussions/xbvrMCjW06o/a6foc28JCQAJ

The main motivation behind making the offline build course as a paid part is to avoid the noise of people who don't have the required skill set. If someone wants to build a simplified version (like the guy in the link) then I wouldn't mind that at all.

If you have good material design components/ideas the best way to handle that is through a pull request so we can all benefit including you as we'd help maintain your work...