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

    WHAT DID I LEARN? I BUILT THE EXACT SAME APP

    IN KOTLIN, NATIVESCRIPT AND FLUTTER
  2. 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. 3.
  4. 4.
  5. 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. 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. 8.

    I WILL TRADE A FEW CPU CYCLES FOR DEVELOPER CYCLES

    ANY DAY DHH (Basecamp & Ruby on Rails founder)
  8. 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
  9. 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
  10. 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
  11. 16.
  12. 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
  13. 18.
  14. 19.
  15. 20.
  16. 21.
  17. 23.
  18. 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
  19. 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
  20. 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
  21. 32.

    DRAG/DROP GUI EDITOR Yes - fully featured No No -

    partial support via 3rd party tools
  22. 33.

    BREAKPOINT DEBUGGING Yes - fully integrated with Android Studio No

    - very limited support, socket connection breaks Yes - via Android studio but not 100% reliable
  23. 34.

    HOT RELOAD Partial - currently opened activity refreshes. Also slow

    Yes - Recently released, Webpack HMR based. Buggy sometimes Yes - rock solid
  24. 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
  25. 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.
  26. 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
  27. 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
  28. 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
  29. 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
  30. 47.

    App Size (prod) 3.1 MB 5.8 MB 10 MB (per

    arch) 62MB (2 archs) 70MB (2 archs)
  31. 52.

    Lines of Code (excluding autogenerated files) 1140 : 640 kt

    + 500 xml 740 : 470 + 270 json 480 : 230 vue + 150 ts + 100 dts
  32. 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
  33. 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.
  34. 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.