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 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 Slide

  3. View Slide

  4. View Slide

  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

    View Slide

  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.

    View Slide

  7. DEVELOPER
    EXPERIENCE

    View Slide

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

    View Slide

  9. Available IDEs

    View Slide

  10. Available IDEs

    View Slide

  11. Available IDEs

    View Slide

  12. GETTING STARTED
    THIS SHOULD BE EXTREMELY EASY

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  16. LANGUAGES

    View Slide

  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

    View Slide

  18. View Slide

  19. VARIABLES

    View Slide

  20. ARRAYS

    View Slide

  21. MAPS

    View Slide

  22. ARRAY - MAP - STREAM

    View Slide

  23. CLASSES

    View Slide

  24. INTERFACES

    View Slide

  25. TUPLE RETURN

    View Slide

  26. DOWNCASTING

    View Slide

  27. DESIGN PATTERNS
    IT HELPS TO HAVE WELL-ESTABLISHED

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  31. COMMON
    TOOLS
    GOOD TO HAVE

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

  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.

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  41. WALK THROUGH
    THE CODEBASE
    LET US TAKE A

    View Slide

  42. KOTLIN CODEBASE WALKTHROUGH
    cb.lk/rwappkt

    View Slide

  43. NATIVESCRIPT CODEBASE WALKTHROUGH
    cb.lk/rwappns

    View Slide

  44. FLUTTER CODEBASE WALKTHROUGH
    cb.lk/rwappfl

    View Slide

  45. BENCHMARKS
    Raw Numbers

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  56. CONCLUSIONS
    Summarising the facts

    View Slide

  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

    View Slide

  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.

    View Slide

  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.

    View Slide

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

    View Slide