Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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.

Arnav Gupta

March 09, 2019
Tweet

More Decks by Arnav Gupta

Other Decks in Technology

Transcript

  1. WHAT DID I LEARN?
    I BUILT THE EXACT SAME APP IN
    KOTLIN, NATIVESCRIPT AND
    FLUTTER

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  5. DEVELOPER
    EXPERIENCE

    View full-size slide

  6. I WILL TRADE A FEW CPU
    CYCLES FOR DEVELOPER
    CYCLES ANY DAY
    DHH
    (Basecamp & Ruby on Rails founder)

    View full-size slide

  7. Available IDEs

    View full-size slide

  8. Available IDEs

    View full-size slide

  9. Available IDEs

    View full-size slide

  10. GETTING STARTED
    THIS SHOULD BE EXTREMELY EASY

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  15. ARRAY - MAP - STREAM

    View full-size slide

  16. TUPLE RETURN

    View full-size slide

  17. DESIGN PATTERNS
    IT HELPS TO HAVE WELL-ESTABLISHED

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  20. DESIGN PATTERNS
    FLUTTER
    ▸ No officially documented/endorsed design
    pattern
    ▸ Unofficial MVC and MVVM-like examples
    available
    ▸ Business Logic Component (BLoC) pattern
    getting popular
    30

    View full-size slide

  21. COMMON
    TOOLS
    GOOD TO HAVE

    View full-size slide

  22. DRAG/DROP GUI EDITOR
    Yes - fully featured
    No
    No - partial support via
    3rd party tools

    View full-size slide

  23. BREAKPOINT DEBUGGING
    Yes - fully integrated
    with Android Studio
    No - very limited
    support, socket
    connection breaks
    Yes - via Android studio
    but not 100% reliable

    View full-size slide

  24. HOT RELOAD
    Partial - currently
    opened activity
    refreshes. Also slow
    Yes - Recently released,
    Webpack HMR based.
    Buggy sometimes
    Yes - rock solid

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  31. WALK THROUGH
    THE CODEBASE
    LET US TAKE A

    View full-size slide

  32. KOTLIN CODEBASE WALKTHROUGH
    cb.lk/rwappkt

    View full-size slide

  33. NATIVESCRIPT CODEBASE WALKTHROUGH
    cb.lk/rwappns

    View full-size slide

  34. FLUTTER CODEBASE WALKTHROUGH
    cb.lk/rwappfl

    View full-size slide

  35. BENCHMARKS
    Raw Numbers

    View full-size slide

  36. App Size (debug)
    3.6MB
    42MB
    16 MB
    75MB
    73MB

    View full-size slide

  37. App Size (prod)
    3.1 MB
    5.8 MB
    10 MB (per arch)
    62MB (2 archs)
    70MB (2 archs)

    View full-size slide

  38. Peak CPU Usage
    36%
    26%
    40%
    17%
    15%
    12 threads
    4 threads

    View full-size slide

  39. Consistent CPU Usage
    6%
    14%
    10%
    4%
    12 threads
    4 threads
    1%

    View full-size slide

  40. Peak Memory Usage
    127 MB
    160 MB
    145 MB
    80 MB
    35 MB

    View full-size slide

  41. Average Memory Usage
    50 MB
    90 MB
    75 MB
    40 MB
    30 MB

    View full-size slide

  42. Lines of Code (excluding autogenerated files)
    1140 : 640 kt + 500 xml
    740 : 470 + 270 json
    480 : 230 vue + 150 ts + 100 dts

    View full-size slide

  43. Build Time (cold/clean)
    32s
    50s
    30s 30s
    40s

    View full-size slide

  44. Build Time (warm/dirty)
    8s
    8s
    7s 6s
    9s

    View full-size slide

  45. Time taken to develop (via wakatime.com stats)
    10.5 hrs
    8 hrs
    8.5 hrs

    View full-size slide

  46. CONCLUSIONS
    Summarising the facts

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  50. QUESTIONS?
    speakerdeck.com/championswimmer
    THANK YOU!
    @championswimmer : Twitter | Github

    View full-size slide