Hal yang biasanya saya perhatikan dalam memilih library untuk web app saya
Di dunia per-frontend-an dimana komunitasnya sudah sangat besar didukung dengan library yang silih berganti tapi bentuknya mirip-mirip mungkin kadang kita agak bingung gimana cara memilih library yang cocok untuk aplikasi kita. Atau mungkin kamu sedang dapat task untuk melakukan migration project, tapi library yang dipake di codebase yang lama sudah enggak relevan lagi di jaman sekarang, kamu juga jadi bingung gimana milih library penggantinya.
Sebagai frontend developer yang mungkin belum terlalu familiar dengan dunia per-npm-an, yang mana disitu banyak librarynya yang mirip-mirip dengan popularitas yang sama mirip-miripnya juga, hal ini bisa bikin dilema. Atau enggak?
Soalnya pemilihan library yang tepat ini juga akan membantu kita untuk maintain codebase kita di waktu yang akan datang, tentunya kita enggak mau pake library yang tidak sustainable dan tidak reliable. Nah, mari kita bongkar detail-detail dalam halaman library NPM untuk membantu kita memilih library yang tepat.
Photo of Dayjs in npmjs.com
Kita akan mulai kulik dari bagian atas ya
Typescript-based library is better than Typescript declaration file
Typescript-based (kiri) vs non Typescript-based (kanan)
Pertimbangan pertama yang saya ambil adalah untuk memilih library yang dibikin pake typescript alias typescript-based. Sebenernya hal ini penting nggak penting, tapi untuk long-live project saya akan sarankan untuk pilih yang TS-based. Beberapa keuntungan memilih library yang TS-based:
- Ketika kita nantinya akan migrasi ke project yang berbasis Typescript juga, kita tidak perlu melakukan penambahan install type declaration
@types/[something] - Karena typing yang satu set dengan librarynya, kita lebih confident ketika melakukan upgrade library, sehingga tidak ada risiko versi library yang kita pakai sudah naik etapi ternyata type-nya belum terupdate/belum relevan
Fewer dependencies are better
Dependencies comparison
Pertimbangan kedua saya dalam memilih library adalah memilih yang Dependencies nya lebih sedikit. Karena dengan begitu kita tahu bahwa risiko library kita break ketika ada dependecy yang deprecated/discontinue semakin kecil.
Karena enggak lucu library yang biasa kita pake serve user sehari-hari tiba-tiba nge-break karena ada dependency yang udah enggak relevan lagi. Kan kita juga day-to-day nya ngerjain fitur dan enggak ngecekin si dependencies ini.
Jangan sampe kejadian tahun 2016 terulang lagi, dimana library bernama left-pad tiba-tiba di-unpublish sama developernya terus bikin dunia Javascript seantero jagat mati total.
https://www.theverge.com/2016/3/24/11300840/how-an-irate-developer-briefly-broke-javascript
Weekly downloads specify the popularity
Weekly download comparison
Weekly download juga bisa jadi faktor penting dalam menentukan library, karena weekly download yang banyak menandakan banyak user/developer yang percaya sama library ini, sehingga menandakan library ini cukup populer di kalangan developer.
Kenapa penting memilih library yang populer instead of indie? Karena library yang populer akan berbanding lurus dengan community support-nya. Sehingga ketika kamu punya issue, kamu akan merasa lebih aman karena pasti ada yang akan menjawab atau pasti ada yang pernah mengalami.
Your answer will be one Google Search away~
Issues and pull request count are your friend
Issues and PR comparison
Masih nyambung dengan popularitas sebuah library, semakin populer tentu sebuah library semakin banyak yang memperhatikan dan sama-sama ikut mempertahankan lifetime dari library tersebut. Hal ini akan ditunjukkan dengan kenaikan angka dari issues & pull request .
Issues ini enggak melulu yang buruk-buruk, bukan berarti library yang kita pake akan bermasalah kalo angkanya tinggi. Justru kalo kita mau spare waktu sedikit lebih banyak untuk ngeliat issues yang ada di library tersebut, kita justru malah tau, library ini kedepannya mau dibawa kemana dan gimana; apa hal-hal yang kemungkinan akan disupport di masa yang akan datang; apa aja limitation library itu; dll.
Jadi nggak usah takut sama angka issues yang tinggi, etapi issue yang tinggi perlu diikuti sama pull-request yang tinggi pula, karena ini artinya member komunitasnya mau berkontribusi untuk improve library ini. Kalo PR-nya kosongan, issuenya tinggi, artinya librarynya udah enggak ada yang nggubris. 😀
Unpacked size will affect your bundle size
Unpacked size comparison
Ini sangat perlu diperhatikan oleh frontend developer, terutama jika aplikasinya dipakai oleh user/customer dan bukan internal applications. Unpacked size dari sebuah library akan mempengaruhi seberapa besar bundle size dari aplikasimu.
Meskipun di teknologi sekarang sudah bisa kita akalin dengan adanya tree-shaking, lazy loading, dynamic import, dll, tapi akan jauh lebih baik memilih library yang punya size yang lebih kecil. Jadi tanpa melakukan optimization tadi, bundle size aplikasi kita tetap akan se-minimum mungkin.
Last publish will define your future fate
Last publish comparison
Last publish ini seperti namanya, kapan si latest version dari library ini dipublish. Saya biasanya akan memilih yang lebih muda alias yang lebih baru, karena dengan begitu teknologi yang dipakai kemungkinan lebih relevan dengan perkembangan saat ini, sehingga librarynya bisa lebih cepat, lebih performant, lebih optimized.
Tapi jika kamu tipikal orang yang lebih prefer yang lebih lama karena lebih battle-tested (enggak perlu dipublish lagi aja udah banyak yang pake kok), itu juga boleh. Yang penting jangan sampe terlalu jauh misal 1.5 tahun yang lalu last publishnya, itu bukan battle-tested, itumah otw deprecated.
Last but not least, the trending library might not be the best option, the rising star is
Ini agak berbeda approachnya, jadi kita enggak melihat di web npmjs.com tapi kita melihat di npmtrends
Kalo membaca penjelasan saya kan kita bisa simpulkan bahwa “oh berarti library yang populer ini yang paling baik buat saya ya”. Jawaban saya “ya belum tentu juga”
Kalo kita lihat redux ini merupakan state management library yang masih sangat populer di React, tapi setelah hands-on zustand , saya akan merekomendasikan zustand dibanding redux kepada temen-temen frontend saya yang lagi belajar atau lagi mempertimbangkan library state management yang baru.
Karena zustand punya approach yang lebih baru, lebih mudah digunakan dan disetup dibandingkan redux yang meskipun sekarang disupport sama redux-toolkit menurut saya tetap masih ribet penggunaannya.
Begitu teman-teman kurang lebihnya, mungkin masih ada banyak lagi pertimbangan lainnya, tapi baseline saya untuk memilih library biasanya itu sih.
Ternyata cukup banyak variable yang bisa kita pertimbangkan ya dalam memilih library di aplikasi/project kita. Hehe, semoga cerita kali ini bisa menambah insight buat temen-temen terutama frontend developer sehingga codebase yang sedang kamu kerjakan lebih maintainable dan sustainable.
Have a great day!