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

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.

37fbf83b7d45711e41e774e29fed710e?s=128

Arnav Gupta

March 09, 2019
Tweet

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
  3. None
  4. None
  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
  18. None
  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