Memilih library atau framework JavaScript

Umar Hansa

Artikel ini membagikan insight tentang cara memilih library atau framework untuk digunakan dalam aplikasi web. Diskusi di sini akan membantu Anda mempertimbangkan pro dan kontra dalam menemukan library atau framework JavaScript yang tepat untuk masalah bisnis yang sedang Anda coba selesaikan. Memahami kelebihan dan kekurangan mana yang berlaku dalam berbagai situasi merupakan kunci untuk memeriksa pilihan library JavaScript yang tersedia dalam jumlah besar.

Apa itu library dan framework JavaScript

Apa itu library JavaScript? Dalam bentuknya yang paling sederhana, library JavaScript adalah kode yang telah ditulis sebelumnya yang bisa Anda panggil dalam kode project untuk mencapai tugas tertentu.

Postingan ini utamanya menyebutkan "perpustakaan". Namun, banyak diskusi yang juga berlaku untuk kerangka kerja. Pada dasarnya, perbedaan antara keduanya dapat dirangkum sebagai berikut:

  • Untuk library, kode aplikasi Anda memanggil kode library.
  • Untuk framework, kode aplikasi Anda dipanggil oleh framework.

Contoh praktis berikut membantu menggambarkan perbedaannya.

Contoh panggilan ke library JavaScript

Library JavaScript melakukan tugas tertentu, kemudian mengembalikan kontrol ke aplikasi Anda. Saat menggunakan library, Anda mengontrol alur aplikasi dan memilih waktu untuk memanggil library.

Pada contoh berikut, kode aplikasi mengimpor metode dari library lodash. Setelah fungsi selesai, kontrol dikembalikan ke aplikasi Anda.

import capitalize from 'lodash.capitalize';
capitalize('hello'); // Hello

Saat dieksekusi, metode lodash.capitalize akan memanggil kode JavaScript yang telah ditulis sebelumnya yang menjadi kapitalisasi karakter pertama dari string.

Contoh penggunaan Framework JavaScript

Framework JavaScript adalah template kode yang telah ditentukan sebelumnya yang digunakan untuk membentuk perilaku aplikasi. Artinya, saat Anda menggunakan framework, framework akan mengontrol alur aplikasi. Untuk menggunakan framework, tulis kode aplikasi kustom, lalu framework memanggil kode aplikasi.

Contoh berikut menunjukkan cuplikan kode yang menggunakan framework JavaScript Preact:

import { createElement } from 'preact';

export default function App() {
  return (
    <p class="big">Hello World!</p>
  )
}

Dalam contoh, perhatikan bahwa framework memiliki lebih banyak kontrol atas kode yang Anda tulis, dan dalam beberapa kasus, framework bahkan mengambil kontrol atas kapan harus mengeksekusi kode Anda.

Mengapa menggunakan library?

Menggunakan library JavaScript dapat membantu menghindari pengulangan kode yang tidak perlu. Library dapat memisahkan logika yang kompleks, seperti manipulasi tanggal atau penghitungan keuangan. Library juga dapat membantu menampilkan produk awal Anda, daripada harus menulis semua kode dari awal, yang dapat memakan waktu.

Beberapa library JavaScript sisi klien membantu memisahkan keunikan platform web. Perpustakaan juga dapat berfungsi sebagai alat pembelajaran. Misalnya, jika Anda belum terbiasa dengan fungsi easing animasi, kode sumber library dapat mengajari Anda cara kerja easing tersebut.

Beberapa perpustakaan didukung oleh perusahaan besar yang menginvestasikan waktu dan uang untuk menjaga perpustakaan tetap terbaru dan aman. Banyak library yang disertai dengan dokumentasi lengkap, yang menawarkan cara cepat kepada Anda dan tim Anda untuk memahami penggunaan library tersebut.

Pada akhirnya, menggunakan library JavaScript akan menghemat waktu Anda.

Mengapa Anda harus peduli tentang penggunaan library?

Secara teknis, Anda dapat mengembangkan aplikasi web dari awal, tetapi mengapa harus bersusah payah ketika Anda dapat menggunakan perangkat lunak gratis ({i>open source<i}), atau membeli solusi yang, dalam jangka panjang, dapat menghemat waktu dan uang? Ada banyak sekali library dan framework JavaScript yang tersedia, masing-masing menawarkan pendekatan unik untuk memecahkan masalah, dan masing-masing memiliki karakteristik berbeda. Contoh:

  • Library dapat ditulis dan dikelola secara internal, bukan oleh pihak ketiga.
  • Library dapat memiliki lisensi hukum tertentu yang membuatnya sesuai atau tidak sesuai untuk aplikasi web Anda.
  • Library mungkin sudah usang atau tidak terawat.
  • Perpustakaan dapat menyederhanakan serangkaian tugas yang kompleks dan menghemat banyak waktu dan uang.
  • Library dapat digunakan secara luas dalam komunitas, dan cukup dikenal di kalangan developer.

Seperti yang mungkin Anda duga, karakteristik yang berbeda dapat memengaruhi aplikasi web Anda dengan cara yang berbeda. Terkadang, keputusannya tidak sedalam itu, dan Anda dapat menukar perpustakaan dengan aman jika Anda tidak menyukainya. Namun, terkadang library dapat memiliki efek signifikan terhadap pekerjaan dan aplikasi web Anda, yang menyarankan agar diperlukan pendekatan yang lebih tepat.

Ada beberapa lingkungan JavaScript non-klien, seperti di server (dijalankan di lingkungan cloud) atau di Raspberry Pi, di mana Anda mungkin perlu menyesuaikan kriteria yang digunakan untuk memeriksa library dan framework.

Performa

Efek performa library JavaScript pada aplikasi web sisi klien tidak boleh diabaikan. Library JavaScript yang besar dapat mengganggu performa pemuatan halaman; ingat, milidetik menghasilkan jutaan.

Pertimbangkan sebuah skenario saat Anda menggunakan library JavaScript untuk animasi. Beberapa library dapat dengan mudah menambahkan puluhan kilobyte, dan dalam beberapa kasus, bahkan ratusan kilobyte. Resource JavaScript seperti ini dapat menambah penundaan yang signifikan pada pemuatan halaman karena browser harus mendownload, mengurai, mengompilasi, dan mengeksekusi kode.

Semakin besar library JavaScript, semakin besar efek performa pada pengguna Anda.

Saat mengevaluasi atau menggunakan library atau framework JavaScript, pertimbangkan saran berikut untuk meningkatkan performa:

  • Dengan library JavaScript yang besar, pertimbangkan untuk menggunakan alternatif yang lebih kecil. Misalnya, date-fns menawarkan banyak fungsi dengan ukuran yang lebih wajar daripada beberapa opsi lainnya.
  • Setelah contoh tanggal fns sebelumnya, impor hanya fungsi yang Anda perlukan, seperti: import { format } from 'date-fns'. Pastikan untuk menggabungkan pendekatan ini dengan tree shaking, sehingga payload JavaScript minimal akan dibuat dan dikirim ke pengguna Anda.
  • Gunakan alat pengujian performa seperti Lighthouse untuk mengamati efek performa penggunaan library JavaScript tertentu. Jika library menambahkan penundaan satu detik pada waktu muat halaman Anda (jangan lupa untuk men-throttle jaringan dan CPU selama pengujian), Anda mungkin perlu mengevaluasi kembali library pilihan Anda. Selain memeriksa pemuatan halaman, pastikan untuk membuat profil perilaku halaman web apa pun yang memanggil kode dari library yang dimaksud, karena performa pemuatan halaman tidak memberikan gambaran lengkap.
  • Jika komentar disambut oleh penulis perpustakaan, kirimkan pengamatan kinerja, saran, dan bahkan kontribusi Anda untuk proyek. Di sinilah komunitas {i>open source<i} bersinar! Jika Anda memutuskan untuk memberikan kontribusi, Anda mungkin perlu berkonsultasi dengan perusahaan terlebih dahulu.
  • Gunakan alat pelacakan paket otomatis, seperti bundlesize, untuk memantau update besar yang tidak terduga pada library. Biasanya library JavaScript akan berkembang seiring waktu. Penambahan fitur, perbaikan bug, kasus ekstrem, dan lainnya, semuanya dapat ditambahkan ke ukuran file library. Setelah Anda/tim setuju untuk menggunakan library, memperbarui library dapat mengurangi masalah dan dapat menimbulkan sedikit pertanyaan. Di sinilah pentingnya mengandalkan otomatisasi.
  • Lihat persyaratan Anda untuk library dan evaluasi apakah platform web menawarkan fungsi yang sama secara native atau tidak. Misalnya, platform web sudah menawarkan pemilih warna, yang menghilangkan kebutuhan untuk menggunakan library JavaScript pihak ketiga untuk menerapkan fungsi yang sama.

Keamanan

Penggunaan modul pihak ketiga dapat menimbulkan beberapa risiko keamanan bawaan. Paket berbahaya dalam codebase aplikasi web dapat membahayakan keamanan tim pengembangan dan pengguna.

Pertimbangkan library yang dipublikasikan ke ekosistem NPM. Paket seperti itu mungkin sah. Namun, seiring waktu, paket itu dapat disusupi.

Berikut ini beberapa tips keamanan yang perlu dipertimbangkan saat menggunakan atau mengevaluasi kode pihak ketiga:

  • Jika Anda menggunakan GitHub, pertimbangkan penawaran keamanan kode, seperti Dependabot. Atau, pertimbangkan layanan alternatif yang memindai kerentanan dalam kode Anda, seperti snyk.io.
  • Pertimbangkan untuk menggunakan layanan audit kode, yaitu tim engineer yang dapat mengaudit kode pihak ketiga yang Anda gunakan secara manual.
  • Evaluasi apakah Anda harus mengunci dependensi ke versi tertentu, atau menerapkan kode pihak ketiga dalam kontrol versi. Ini bisa membantu mengunci dependensi Anda ke satu versi tertentu—yang dianggap aman. Ironisnya, hal ini dapat memberikan efek tanding pada keamanan, karena Anda mungkin melewatkan update penting pada library.
  • Pindai halaman beranda project, atau halaman GitHub, jika ada. Mencari tahu apakah ada masalah keamanan yang belum terselesaikan, dan apakah masalah keamanan sebelumnya telah diselesaikan dalam jangka waktu yang wajar.
  • Kode pihak ketiga yang menggunakan kode pihak ketiga lainnya dapat memiliki risiko lebih besar dibandingkan library yang memiliki dependensi nol. Perhatikan risiko ini.

Aksesibilitas

Anda mungkin bertanya-tanya bagaimana perpustakaan perangkat lunak terkait dengan aksesibilitas web. Meskipun library software dapat digunakan di berbagai lingkungan, dalam konteks library berbasis JavaScript sisi klien, aksesibilitas web menjadi sangat penting.

Library berbasis JavaScript sisi klien (atau framework, dalam hal ini) dapat meningkatkan atau mengurangi aksesibilitas situs Anda. Pertimbangkan library JavaScript pihak ketiga yang menambahkan penggeser gambar ke halaman. Jika penggeser gambar tidak memperhitungkan aksesibilitas web, Anda sebagai developer web mungkin mengabaikan fitur penting tersebut, dan merilis produk yang melewatkan fitur penting, seperti penggeser yang dapat dinavigasi dengan keyboard!

  • Apakah plugin tipografi responsif mendukung pengguna yang memperbesar atau memperkecil laman?
  • Apakah plugin uploader file mendukung upload file dari perangkat asistif?
  • Apakah library animasi menawarkan dukungan untuk pengguna yang lebih menyukai gerakan yang dikurangi?
  • Apakah plugin peta interaktif mendukung penggunaan keyboard saja?
  • Apakah koleksi pemutar audio menawarkan pengalaman yang sesuai di pembaca layar?

Masuk akal untuk mengharapkan bahwa beberapa tingkat keterlibatan diperlukan dari Anda, sebagai developer web, untuk memenuhi persyaratan aksesibilitas tersebut. Contoh:

  • Untuk fitur yang tidak ada, Anda dapat mengimplementasikan fitur tersebut dalam codebase, bahkan sambil terus menggunakan library yang dimaksud.
  • Dengan dukungan dari perusahaan, Anda dapat mengontribusikan fitur yang belum ada ke {i>library<i}, jika penulis {i>library<i} mengizinkan kontribusi seperti itu.
  • Anda dapat membuka dialog dengan penulis library. Misalnya, apakah fitur aksesibilitas khusus ini ada dalam rencana Anda? Apakah kamu setuju bahwa game ini ada di perpustakaan?
  • Untuk kasus penggunaan populer, Anda dapat menjelajahi opsi library alternatif yang lebih mudah diakses; opsi library ini mungkin ada, tetapi lebih sulit ditemukan.
  • Dalam kasus ekstrem, Anda mungkin perlu menghapus library sepenuhnya dan mengimplementasikan fitur Anda dari awal. Hal ini bisa terjadi ketika library atau framework mengalami penurunan pengalaman aksesibilitas pada penggunaan awal, dan Anda perlu mengurungkan banyak hal yang seharusnya diberikan oleh library atau framework secara gratis.

Konvensi

Library software yang menggunakan konvensi coding yang telah ditetapkan akan lebih mudah digunakan. Jika library menggunakan konvensi coding yang belum pernah ada, Anda dan tim Anda mungkin akan kesulitan untuk bekerja dengan library tersebut.

Jika library tidak mengikuti konvensi coding umum (misalnya, panduan gaya umum), tidak banyak yang dapat Anda lakukan sebagai perbaikan langsung. Namun, masih ada beberapa opsi:

  • Pastikan untuk membedakan antara kode sumber library dan API yang diekspos kepada Anda, sebagai pengguna library. Meskipun kode sumber internal mungkin menggunakan konvensi yang tidak dikenal, jika API (bagian dari library yang Anda berinteraksi dengan) menggunakan konvensi yang sudah dikenal, mungkin tidak ada yang perlu dikhawatirkan.
  • Jika API library tidak mengikuti konvensi coding umum, Anda dapat menggunakan pola desain JavaScript, seperti pola proxy, untuk menggabungkan dan memuat semua interaksi dengan library ke satu file dalam codebase. Proxy kemudian dapat menawarkan API yang lebih intuitif ke bagian kode lainnya dalam codebase Anda.

Konvensi memainkan peran besar dalam hal kemudahan penggunaan. Library yang menyertakan API intuitif dapat menghemat waktu berjam-jam, atau bahkan berhari-hari, jika dibandingkan dengan API kontra-intuitif yang membutuhkan banyak eksperimen untuk mengetahuinya.

Info Terbaru

Sebagai contoh, untuk library yang berfungsi sepenuhnya dan melakukan beberapa perhitungan matematis, library tersebut mungkin jarang memerlukan update. Faktanya, library berfitur lengkap adalah hal yang langka ditemukan dalam dunia pengembangan web yang terus berubah. Namun, ada kalanya Anda ingin penulis perpustakaan responsif dan bersedia melakukan pembaruan. Penelitian dan temuan baru dapat mengungkapkan cara yang lebih baik dalam melakukan sesuatu, sehingga teknik yang digunakan dalam library dan framework selalu dapat berubah.

Saat Anda memilih library atau framework, perhatikan cara penanganan update, dan perhatikan bahwa keputusan tersebut dapat memengaruhi Anda:

  • Apakah library memiliki jadwal rilis yang masuk akal? Misalnya, update pada repositori kode sumber mungkin sering terjadi, tetapi jika update seperti itu tidak "dipublikasikan" atau "dirilis" sebagaimana mestinya, Anda akan kesulitan mendownload update tersebut.
  • Apakah library merilis update dengan skema pembuatan versi software yang logis? Perpustakaan akan menghemat waktu Anda. Jika Anda harus mengubah kode secara tidak terduga setiap kali mengupdate versi library, tujuan penggunaan library tersebut pada awalnya mungkin tidak sesuai. Perubahan yang dapat menyebabkan gangguan terkadang tidak dapat dihindari, tetapi dalam kondisi ideal, perubahan jarang terjadi dan tidak dipaksakan oleh konsumen library.
  • Apakah library berupaya untuk mencapai kompatibilitas mundur? Terkadang, update software dapat disertai dengan perubahan yang dapat menyebabkan gangguan, tetapi juga menyediakan lapisan kompatibilitas mundur. Hal ini memungkinkan konsumen library menggunakan versi library terbaru dengan perubahan minimal pada kode mereka.

Pemberian (hak) lisensi

Pemberian lisensi software merupakan aspek penting dalam penggunaan library software pihak ketiga. Penulis perpustakaan dapat menetapkan lisensi ke perpustakaannya. Jika Anda mempertimbangkan untuk menggunakan library, pilihan lisensi mereka mungkin akan memengaruhi Anda.

Misalnya, library JavaScript mungkin memiliki lisensi software yang mengizinkan Anda untuk menggunakannya dalam lingkungan non-komersial. Untuk proyek hobi pribadi, ini bisa menjadi pilihan yang bagus. Jika proyek Anda memiliki elemen komersial, maka Anda mungkin perlu mempertimbangkan lisensi perusahaan.

Jika ragu, pertimbangkan untuk meminta nasihat hukum profesional atau menyerahkan kepada tim hukum di perusahaan Anda.

Komunitas

Library atau framework yang memiliki komunitas pengguna/kontributor dalam jumlah besar dapat bermanfaat, tetapi bukan jaminan. Secara umum, semakin banyak pengguna yang dimiliki library atau framework, semakin besar kemungkinan manfaat yang diperoleh. Pertimbangkan pro dan kontra berikut untuk berpartisipasi dalam komunitas pengembangan:

Kelebihan:

  • Basis pengguna yang besar dapat berarti kemungkinan besar bug terdeteksi lebih awal dan sering.
  • Komunitas aktif yang besar dapat berarti lebih banyak tutorial, panduan, video, dan bahkan kursus, di perpustakaan atau kerangka kerja yang dimaksud.
  • Komunitas aktif yang besar dapat berarti lebih banyak dukungan di forum serta situs tanya jawab, meningkatkan kemungkinan pertanyaan dukungan akan dijawab.
  • Komunitas yang terlibat dapat berarti lebih banyak kontributor eksternal terhadap perpustakaan atau kerangka kerja. Mereka dapat membantu menyampaikan fitur yang tidak ada dalam rencana penulis.
  • Ketika sebuah perpustakaan atau kerangka kerja populer di dalam komunitas, kemungkinan besar rekan dan kolega Anda akan mendengar, atau bahkan familier dengan, perpustakaan atau kerangka kerja tersebut.

Kekurangan:

  • Proyek dengan basis pengguna yang besar dan beragam dapat menjadi kewalahan karena penambahan fitur yang terus-menerus. Library yang membengkak dapat mengganggu performa web.
  • Sebuah proyek dengan komunitas yang aktif dan terlibat dapat membuat stres bagi penulis dan pengelola, dan mungkin membutuhkan moderasi komunitas yang berat.
  • Sebuah proyek yang berkembang pesat, tetapi tidak memiliki dukungan yang tepat, dapat mulai menunjukkan tanda-tanda memiliki komunitas yang negatif. Sebagai contoh, developer web pemula atau junior dapat dibuat merasa tidak disukai di komunitas tertentu karena adanya pembatasan.

Dokumentasi

Tidak peduli seberapa sederhana atau rumitnya library atau framework JavaScript, dokumentasi software selalu dapat membantu. Bahkan developer yang sangat berpengalaman pun dapat menggunakan dokumentasi, alih-alih mencari tahu kodenya sendiri. Dokumentasi menjelaskan API yang harus Anda gunakan, dan cara Anda menggunakannya.

Dokumentasi bahkan dapat memberikan kode contoh, sehingga memudahkan Anda untuk memulai dengan cepat. Saat Anda mengevaluasi perpustakaan atau kerangka kerja, Anda dapat mengajukan beberapa pertanyaan berikut:

  • Apakah perpustakaan menyertakan dokumentasi? Jika tidak, Anda harus merasa nyaman untuk mencari tahu sendiri.
  • Apakah dokumentasinya jelas, mudah dipahami, dan bebas dari ambiguitas? Banyak developer menghabiskan banyak waktu untuk dokumentasi. Mungkin hal ini terlihat sepele, tetapi kejelasan dalam dokumentasi tekstual dapat berpengaruh besar pada produktivitas Anda.
  • Apakah dokumentasi dibuat secara otomatis? Dokumentasi semacam ini bisa jadi lebih sulit untuk dipahami dan tidak selalu memberikan panduan yang jelas tentang cara menggunakan API.
  • Apakah dokumentasinya sudah yang terbaru? Pemeliharaan dokumentasi kadang-kadang dianggap sebagai tambahan. Jika library diperbarui, tetapi dokumentasinya tidak diperbarui, hal ini dapat menyebabkan pemborosan waktu pengembangan.
  • Apakah dokumentasinya komprehensif dan tersedia dalam berbagai format? Panduan pengguna, kode contoh, dokumentasi referensi, demo langsung, dan tutorial adalah format dokumentasi berharga yang dapat membantu Anda agar berhasil menggunakan library atau framework.

Dokumentasi tidak selalu lengkap, dan itu tidak apa-apa. Anda harus menilai kebutuhan organisasi, persyaratan proyek, dan kompleksitas perangkat lunak, dan menggunakannya untuk menentukan tingkat dokumentasi yang dibutuhkan.

Kesimpulan

Wajar jika Anda merasa kewalahan saat memilih library atau framework untuk pertama kalinya. Sama seperti semua hal lainnya, semakin banyak Anda belajar dan berlatih suatu tugas, semakin baik Anda berkembang. Mungkin akan bermanfaat untuk merujuk ke postingan ini saat Anda selanjutnya memilih library atau kerangka kerja untuk digunakan. Anda dapat menggunakan judul dalam postingan ini sebagai checklist. Misalnya: Apakah library ini berperforma tinggi? Apakah perpustakaan ini memenuhi standar bisnis saya untuk aksesibilitas web?

Ada aspek lain dari pustaka dan kerangka kerja yang mungkin perlu Anda pertimbangkan, dan yang belum banyak dibahas dalam posting ini:

  • Perluasan: seberapa mudah untuk memperluas library dengan logika dan/atau perilaku kustom?
  • Alat: jika berlaku, apakah library memiliki alat seperti plugin editor kode, alat proses debug, dan plugin sistem build?
  • Arsitektur: kode yang bersih itu penting, tetapi apakah keseluruhan arsitektur library ini wajar?
  • Pengujian: apakah project memiliki rangkaian pengujian? Apakah situs project menggunakan badge atau indikator yang lulus dari rangkaian pengujian terhadap commit terbaru?
  • Kompatibilitas: apakah library berfungsi baik dengan library dan/atau framework lain yang saat ini Anda gunakan?
  • Biaya: berapa biaya framework? Apakah produk ini {i>open source<i} atau tersedia untuk dibeli?
  • Metrik cantik: metrik ini harus ditempatkan di tingkat rendah dalam daftar kriteria Anda, atau bahkan diabaikan sepenuhnya, tetapi Anda dapat mempertimbangkan "pemilihan" project, akun media sosial yang mewakili project, dan/atau berapa banyak bug/masalah terbuka yang ada di halaman project.