Kotlin vs NativeScript vs Flutter - Building the same app in all platforms

In this, I have made the same app in all 3 platforms - Kotlin/Android, Nativescript (with Vue) and Flutter.

Transcript

1. WHAT DID I LEARN? I BUILT THE EXACT SAME APP IN KOTLIN, NATIVESCRIPT AND FLUTTER
2. SO WHAT APP IS THIS ? ▸ “realworld.io" - a project by thinkster (github.com/gothinkster) ▸ A simplified clone of Medium ▸ Standardised API ▸ We can make backend or frontend using any technology as per the API
5. MY EXPERIENCES WITH THE PLATFORMS FOR CONTEXT - PRIOR EXPERIENCE ▸ Native Android developer since 2011, using Kotlin for > 2 years, multiple popular libraries written ▸ NativeScript - 8-10 months, Vue.js - almost 2 years, author of popular vue libraries ▸ Flutter - Explored once 6 months back, but this is my first app in Flutter
6. MY EXPERIENCES WITH THE PLATFORMS WHAT THIS IS NOT . . . ▸ Promotion of any platform. I have tried to be unbiased. ▸ Bashing any platform. Objective facts and numbers here. None of the platforms are ‘bad’. ▸ A definitive guide to choose. Here lay a few benchmarks. Might help in your choice. Your decision, still, should be driven by use case.
7. DEVELOPER EXPERIENCE
8. I WILL TRADE A FEW CPU CYCLES FOR DEVELOPER CYCLES ANY DAY DHH (Basecamp & Ruby on Rails founder)
9. Available IDEs
10. Available IDEs
11. Available IDEs
12. GETTING STARTED THIS SHOULD BE EXTREMELY EASY
13. GETTING STARTED ▸ Android Studio installation takes care of all required dependencies ▸ Create new project in GUI ▸ Created project works out of the box ▸ Most problems in starting a project have multiple StackOverflow answers 13
14. GETTING STARTED ▸ Installing Flutter SDK has command-line steps ▸ flutter doctor command to check installation success (not 100% reliable) ▸ GUI-based steps to create project in Android Studio ▸ Created project works out of the box 14
15. GETTING STARTED ▸ Installing nativescript-cli has command-line steps ▸ tns doctor command to check installation success (not 100% reliable) ▸ CLI-based step to init starter template. Multiple starter templates - can be confusing ▸ Created project may not work out of the box. Circuitous dependency resolution in starter template too 15
16. LANGUAGES
17. LANGUAGES MORE SIMILAR THAN YOU THINK ▸ Differences in implementations, practices, common patterns, internal mechanisms ▸ On the surface, modern multi-platform languages have very similar syntax and features
19. VARIABLES
20. ARRAYS
21. MAPS
22. ARRAY - MAP - STREAM
23. CLASSES
24. INTERFACES
25. TUPLE RETURN
26. DOWNCASTING
27. DESIGN PATTERNS IT HELPS TO HAVE WELL-ESTABLISHED
28. DESIGN PATTERNS KOTLIN (NATIVE ANDROID) ▸ All 3 - MVP, MVC and MVVM well defined and documented ▸ MVC: Conventional (and easy to get started) ▸ Modern Android Architecture Components - focus on MVVM ▸ ReactiveX available via RxJava, RxAndroid and RxKotlin 28
29. DESIGN PATTERNS NATIVESCRIPT (WITH ANGULAR OR VUE) ▸ Angular - Component based (sort of MVC) but can by Reactive is using RxJS ▸ Vue - MVVM, can be Reactive if using vuex- rxjs ▸ Flux-like state management via vuex available in Vue 29
30. DESIGN PATTERNS FLUTTER ▸ No officially documented/endorsed design pattern ▸ Unofficial MVC and MVVM-like examples available ▸ Business Logic Component (BLoC) pattern getting popular 30
31. COMMON TOOLS GOOD TO HAVE
32. DRAG/DROP GUI EDITOR Yes - fully featured No No - partial support via 3rd party tools
33. BREAKPOINT DEBUGGING Yes - fully integrated with Android Studio No - very limited support, socket connection breaks Yes - via Android studio but not 100% reliable
34. HOT RELOAD Partial - currently opened activity refreshes. Also slow Yes - Recently released, Webpack HMR based. Buggy sometimes Yes - rock solid
35. TESTING FRAMEWORKS Well Supported - JUnit for unit test and Espresso for UI test ??? - Can use Vue/ Angular usual mechanisms, but not well documented Well Supported - Separate unit and UI test methods not needed
36. DATA (DE)SERIALIZATION AT RUNTIME Yes - Gson, Jackson, FasterXML. Also data class generators available Yes - Not needed for JSON , XML libraries exist No - Not possible without reflection. Need data classes pre- generated.
37. 2-WAY DATA BINDING Kind of - Using LiveData and DataBinding Yes - Vue supports proper 2-way binds with v-model No - Not in usual sense. There is widget-binding
38. FULLY FEATURED ORM Yes - multiple solutions for SQLite and also Realm for object-storage Yes - TypeORM for SQLite No - sqflite is kind of ORM but lot of hand- written SQL needed. Not possible because no runtime reflection
39. INTEGRATING WITH NATIVE WIDGETS Ofcourse Yes - Might need Kotlin/ Swift knowledge to glue together No - Preliminary support recently dropped, doesn’t work reliably yet Needed to embed Google Maps or WebViews
40. MAINTAINABILITY / UPGRADABILITY Easy (mostly), IDE suggests too except the recent androidx drama 7th circle of Dante’s hell - Not making it up - recreating the project and copying over sources is easier. Very Easy ! - Had surprisingly close to zero issues for such a nascent platform How much of a pain is it to upgrade libraries/runtimes
41. WALK THROUGH THE CODEBASE LET US TAKE A
42. KOTLIN CODEBASE WALKTHROUGH cb.lk/rwappkt
43. NATIVESCRIPT CODEBASE WALKTHROUGH cb.lk/rwappns
44. FLUTTER CODEBASE WALKTHROUGH cb.lk/rwappfl
45. BENCHMARKS Raw Numbers
46. App Size (debug) 3.6MB 42MB 16 MB 75MB 73MB
47. App Size (prod) 3.1 MB 5.8 MB 10 MB (per arch) 62MB (2 archs) 70MB (2 archs)
48. Peak CPU Usage 36% 26% 40% 17% 15% 12 threads 4 threads
49. Consistent CPU Usage 6% 14% 10% 4% 12 threads 4 threads 1%
50. Peak Memory Usage 127 MB 160 MB 145 MB 80 MB 35 MB
51. Average Memory Usage 50 MB 90 MB 75 MB 40 MB 30 MB
52. Lines of Code (excluding autogenerated files) 1140 : 640 kt + 500 xml 740 : 470 + 270 json 480 : 230 vue + 150 ts + 100 dts
53. Build Time (cold/clean) 32s 50s 30s 30s 40s
54. Build Time (warm/dirty) 8s 8s 7s 6s 9s
55. Time taken to develop (via wakatime.com stats) 10.5 hrs 8 hrs 8.5 hrs
56. CONCLUSIONS Summarising the facts
57. CONCLUSION ▸ If you need lots of background services, GPS/geofences, Bluetooth, hardware, telemetry access, you have to go native. ▸ If app size, CPU/RAM usage, energy efficiency are critical, close-to-metal is easier to optimise. ▸ Time/money/energy investment is high. Larger team needed. 57
58. DESIGN PATTERNS 58 ▸ If you/your team already is knee-deep in frontend frameworks, Nativescript or React Native makes sense. ▸ Time/energy saved in being able to share code across mobile and web is immense. ▸ App size, performance takes a hit. Cannot really avoid understanding native SDKs. Debugging, maintaining might be nightmare for newcomers to mobile.
59. CONCLUSION 59 ▸ UI/Animation heavy apps should try it out. High fidelity reproduction, pixel-perfect matching across platforms. ▸ Good for CRUD frontends, freelance/small projects. Ridiculously low time taken to build, even for newcomers. ▸ Buttery smooth UI comes at the cost of CPU, RAM and energy usage. Lower end devices can choke. ▸ Integrating with native is still dodgy, nascent ecosystem = less support.
60. QUESTIONS? speakerdeck.com/championswimmer THANK YOU! @championswimmer : Twitter | Github