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

Kotlin vs NativeScript vs Flutter - Building th...

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
  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. 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
  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.
  5. I WILL TRADE A FEW CPU CYCLES FOR DEVELOPER CYCLES

    ANY DAY DHH (Basecamp & Ruby on Rails founder)
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. DESIGN PATTERNS FLUTTER ▸ No officially documented/endorsed design pattern ▸

    Unofficial MVC and MVVM-like examples available ▸ Business Logic Component (BLoC) pattern getting popular 30
  13. DRAG/DROP GUI EDITOR Yes - fully featured No No -

    partial support via 3rd party tools
  14. BREAKPOINT DEBUGGING Yes - fully integrated with Android Studio No

    - very limited support, socket connection breaks Yes - via Android studio but not 100% reliable
  15. HOT RELOAD Partial - currently opened activity refreshes. Also slow

    Yes - Recently released, Webpack HMR based. Buggy sometimes Yes - rock solid
  16. 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
  17. 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.
  18. 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
  19. 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
  20. 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
  21. 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
  22. App Size (prod) 3.1 MB 5.8 MB 10 MB (per

    arch) 62MB (2 archs) 70MB (2 archs)
  23. Lines of Code (excluding autogenerated files) 1140 : 640 kt

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