Memilih library atau framework JavaScript

Artikel ini membagikan insight tentang cara memilih library atau framework yang akan 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 Anda coba pecahkan. Memahami kelebihan dan kekurangan yang berlaku dalam berbagai situasi adalah kunci untuk memeriksa banyak pilihan library JavaScript yang tersedia.

Apa yang dimaksud dengan library dan framework JavaScript

Apa yang dimaksud dengan library JavaScript? Dalam bentuk yang paling sederhana, library JavaScript adalah kode yang telah ditulis sebelumnya yang dapat Anda panggil dalam kode project untuk mencapai tugas tertentu.

Postingan ini terutama menyebutkan "library". Namun, banyak diskusi yang juga berlaku untuk framework. 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 mengilustrasikan perbedaannya.

Contoh panggilan ke library JavaScript

Library JavaScript melakukan tugas tertentu, lalu mengembalikan kontrol ke aplikasi Anda. Saat menggunakan library, Anda mengontrol alur aplikasi dan memilih kapan harus memanggil library.

Dalam contoh berikut, kode aplikasi mengimpor metode dari library lodash. Setelah fungsi selesai, kontrol akan ditampilkan 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 menggunakan huruf besar untuk karakter pertama string.

Contoh penggunaan Framework JavaScript

Framework JavaScript adalah template kode yang telah ditentukan sebelumnya tempat Anda membangun perilaku aplikasi. Artinya, saat Anda menggunakan sebuah framework, framework tersebut akan mengontrol alur aplikasi. Untuk menggunakan framework, Anda perlu menulis kode aplikasi kustom, lalu framework memanggil kode aplikasi Anda.

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 alih kontrol atas waktu untuk mengeksekusi kode Anda.

Mengapa menggunakan library?

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

Beberapa library JavaScript sisi klien membantu memisahkan keunikan platform web. Library juga dapat berfungsi sebagai alat pembelajaran. Misalnya, jika Anda tidak memahami fungsi easing animasi, kode sumber library dapat mengajarkan cara kerja easing tersebut.

Beberapa library didukung oleh perusahaan besar yang menginvestasikan waktu dan uang untuk menjaga library tetap terbaru dan aman. Banyak library disertai dengan dokumentasi ekstensif, yang menawarkan cara cepat bagi Anda dan tim Anda untuk membiasakan diri dengan penggunaan library.

Pada akhirnya, menggunakan library JavaScript akan menghemat waktu Anda.

Mengapa Anda harus memperhatikan penggunaan library?

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

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

Seperti yang Anda duga, karakteristik yang berbeda dapat memengaruhi aplikasi web Anda dengan cara yang berbeda. Terkadang, keputusannya tidak terlalu rumit, dan Anda dapat mengganti library dengan aman jika tidak menyukainya. Namun, terkadang library dapat memiliki efek yang signifikan pada pekerjaan dan aplikasi web Anda, yang menunjukkan bahwa pendekatan yang lebih tepat mungkin diperlukan.

Ada beberapa lingkungan JavaScript non-sisi klien, seperti di server (berjalan di lingkungan cloud) atau di Raspberry Pi, tempat 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 Anda; ingat, milidetik menghasilkan jutaan.

Pertimbangkan 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 memperlambat pemuatan halaman karena browser harus mendownload, mengurai, mengompilasi, dan mengeksekusi kode.

Makin besar library JavaScript, makin 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.
  • Mengikuti contoh date-fns sebelumnya, hanya impor fungsi yang Anda perlukan, seperti: import { format } from 'date-fns'. Pastikan untuk menggabungkan pendekatan ini dengan tree shaking, sehingga payload JavaScript minimal dibuat dan dikirim ke pengguna.
  • Gunakan alat pengujian performa seperti Lighthouse untuk mengamati efek performa penggunaan library JavaScript tertentu. Jika library menambahkan penundaan satu detik ke waktu pemuatan halaman (jangan lupa untuk menghalangi jaringan dan CPU selama pengujian), Anda mungkin perlu mengevaluasi ulang library pilihan Anda. Selain memeriksa pemuatan halaman, pastikan untuk membuat profil perilaku halaman web apa pun yang memanggil kode dari library yang dimaksud—performa pemuatan halaman tidak memberikan gambaran lengkap.
  • Jika komentar diterima oleh penulis library, kirimkan pengamatan performa, saran, dan bahkan kontribusi Anda ke project tersebut. Di sinilah komunitas {i>open source<i} bersinar! Jika Anda memutuskan untuk memberikan kontribusi, Anda mungkin perlu memeriksanya dengan pemberi kerja terlebih dahulu.
  • Gunakan alat pelacakan paket otomatis, seperti ukuran paket, untuk memantau update besar yang tidak terduga pada library. Library JavaScript biasanya akan berkembang seiring waktu. Penambahan fitur, perbaikan bug, kasus ekstrem, dan lainnya, semuanya dapat menambah ukuran file library. Setelah Anda/tim Anda setuju untuk menggunakan library, mengupdate library mungkin tidak terlalu menjadi masalah dan dapat menimbulkan sedikit atau tidak ada pertanyaan. Di sinilah Anda dapat 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, sehingga Anda tidak perlu menggunakan library JavaScript pihak ketiga untuk menerapkan fungsi yang sama.

Keamanan

Penggunaan modul pihak ketiga memiliki beberapa risiko keamanan yang melekat. Paket berbahaya dalam codebase aplikasi web Anda dapat membahayakan keamanan tim pengembangan dan pengguna Anda.

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

Berikut 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, tim insinyur yang dapat mengaudit secara manual kode pihak ketiga yang Anda gunakan.
  • Evaluasi apakah Anda harus mengunci dependensi ke versi tertentu, atau melakukan commit kode pihak ketiga dalam kontrol versi Anda. Hal ini dapat membantu mengunci dependensi Anda ke satu versi tertentu—yang mungkin dianggap aman. Ironisnya, hal ini dapat memiliki efek yang berlawanan dalam keamanan, karena Anda mungkin melewatkan update penting pada library.
  • Pindai halaman beranda project, atau halaman GitHub, jika ada. Riset 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 menimbulkan lebih banyak risiko daripada library yang memiliki nol dependensi. Perhatikan risiko ini.

Aksesibilitas

Anda mungkin bertanya-tanya bagaimana library software terkait dengan aksesibilitas web. Meskipun library software dapat digunakan di lingkungan yang berbeda, dalam konteks library berbasis JavaScript sisi klien, aksesibilitas web sangat penting.

Library berbasis JavaScript sisi klien (atau framework) dapat meningkatkan atau menurunkan 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 akan mengabaikan fitur penting tersebut, dan merilis produk yang tidak memiliki fitur penting, seperti penggeser yang dapat dinavigasi dengan keyboard.

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

Anda, sebagai developer web, perlu melakukan beberapa tindakan untuk memenuhi persyaratan aksesibilitas tersebut. Contoh:

  • Untuk fitur yang hilang, Anda dapat menerapkan fitur tersebut dalam codebase, bahkan saat terus menggunakan library yang dimaksud.
  • Dengan dukungan dari pemberi kerja, Anda bisa menyumbangkan fitur yang belum ada di perpustakaan, jika penulis perpustakaan mengizinkan kontribusi seperti itu.
  • Anda dapat membuka dialog dengan penulis library. Misalnya, apakah fitur aksesibilitas ini ada dalam rencana Anda? Apakah Anda setuju bahwa buku tersebut seharusnya ada di perpustakaan?
  • Untuk kasus penggunaan populer, Anda dapat menjelajahi opsi library alternatif yang lebih mudah diakses; opsi tersebut mungkin ada tetapi lebih sulit ditemukan.
  • Pada kasus yang ekstrem, Anda mungkin perlu menghentikan library sepenuhnya dan menerapkan fitur dari awal. Hal ini dapat terjadi jika library atau framework memiliki pengalaman aksesibilitas yang menurun pada penggunaan awal, dan Anda perlu mengurungkan banyak hal yang seharusnya diberikan library atau framework secara gratis.

Konvensi

Library software yang menggunakan konvensi coding yang sudah mapan lebih mudah digunakan. Jika library menggunakan konvensi coding yang tidak dikenal, Anda dan tim mungkin akan kesulitan menggunakan 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 ditampilkan kepada Anda, pengguna library. Meskipun kode sumber internal mungkin menggunakan konvensi yang tidak dikenal, jika API (bagian library yang berinteraksi dengan Anda) 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 dalam satu file di codebase. Proxy Anda kemudian dapat menawarkan API yang lebih intuitif ke bagian kode lain dalam codebase Anda.

Konvensi memainkan peran besar dalam kemudahan penggunaan. Library yang menyertakan API intuitif dapat menghemat waktu berjam-jam, atau bahkan berhari-hari, bagi karyawan, jika dibandingkan dengan API yang berlawanan dengan intuisi yang memerlukan banyak eksperimen untuk mengetahuinya.

Pembaruan

Misalnya, untuk library yang berfungsi sepenuhnya dan melakukan beberapa penghitungan matematika, library tersebut mungkin jarang memerlukan update. Bahkan, library yang lengkap fiturnya adalah temuan yang jarang di dunia pengembangan web yang terus berubah. Namun, terkadang Anda ingin penulis library responsif dan bersedia melakukan update. Riset dan temuan baru dapat mengungkapkan cara yang lebih baik untuk melakukan sesuatu, sehingga teknik yang digunakan dalam library dan framework selalu dapat berubah.

Saat Anda memilih library atau framework, perhatikan bagaimana update ditangani, dan ketahuilah bahwa keputusan tersebut dapat memengaruhi Anda:

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

Pemberian Lisensi

Lisensi software adalah aspek penting dalam menggunakan library software pihak ketiga. Penulis library dapat menetapkan lisensi ke library-nya. Jika Anda mempertimbangkan untuk menggunakan library, pilihan lisensinya dapat memengaruhi Anda.

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

Jika ragu, pertimbangkan untuk meminta nasihat hukum profesional atau tunduk kepada tim hukum dalam perusahaan Anda.

Komunitas

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

Kelebihan:

  • Basis pengguna yang besar dapat berarti peluang yang lebih besar untuk menemukan bug lebih awal dan lebih sering.
  • Komunitas aktif yang besar dapat berarti lebih banyak tutorial, panduan, video, dan bahkan kursus, tentang library atau framework yang dimaksud.
  • Komunitas aktif yang besar dapat berarti lebih banyak dukungan di forum dan situs tanya jawab, sehingga meningkatkan kemungkinan pertanyaan dukungan dijawab.
  • Komunitas yang aktif berinteraksi dapat berarti lebih banyak kontributor eksternal untuk library atau framework. Mereka dapat membantu menghadirkan fitur yang tidak ada dalam roadmap penulis.
  • Jika library atau framework populer di suatu komunitas, besar kemungkinannya rekan dan kolega Anda akan mendengar, atau bahkan mengenal, library atau framework tersebut.

Kekurangan:

  • Project dengan basis pengguna yang besar dan beragam dapat menjadi membengkak karena penambahan fitur yang konstan. Library yang membengkak dapat membahayakan performa web.
  • Proyek dengan komunitas yang aktif dan berinteraksi dapat menimbulkan stres bagi penulis dan pengelola, serta mungkin memerlukan moderasi komunitas yang berat.
  • Sebuah proyek yang berkembang pesat, tetapi tidak memiliki dukungan yang sesuai, dapat mulai menunjukkan tanda-tanda memiliki komunitas yang tidak sehat. Misalnya, developer web pemula atau junior dapat merasa tidak diterima di komunitas tertentu karena gatekeeping.

Dokumentasi

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

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

  • Apakah library 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. Hal ini mungkin tampak sepele, tetapi kejelasan dalam dokumentasi tekstual dapat berdampak besar pada produktivitas Anda.
  • Apakah dokumentasi dibuat sepenuhnya secara otomatis? Dokumentasi tersebut mungkin lebih sulit dipahami dan tidak selalu memberikan panduan yang jelas tentang cara menggunakan API.
  • Apakah dokumentasinya sudah yang terbaru? Pemeliharaan dokumentasi kadang-kadang dianggap sebagai sesuatu yang baru. Jika library diperbarui tetapi dokumentasinya tidak, hal ini dapat menyebabkan waktu pengembangan terbuang.
  • Apakah dokumentasi tersebut komprehensif dan tersedia dalam beberapa format? Panduan pengguna, kode contoh, dokumentasi referensi, demo langsung, dan tutorial adalah format dokumentasi yang berharga yang dapat membantu Anda berhasil menggunakan library atau framework.

Dokumentasi tidak selalu lengkap, dan itu tidak masalah. Anda harus menilai kebutuhan organisasi, persyaratan project, dan kompleksitas software, lalu menggunakannya untuk menentukan tingkat dokumentasi yang diperlukan.

Kesimpulan

Wajar jika Anda merasa kewalahan saat memilih library atau framework untuk pertama kalinya. Sama seperti hal lainnya, semakin banyak Anda belajar dan berlatih suatu tugas, semakin baik Anda melakukannya. Anda mungkin dapat merujuk ke posting ini ketika berikutnya Anda memilih {i>library<i} atau {i>framework<i} yang akan digunakan. Anda dapat menggunakan judul dalam postingan ini sebagai checklist. Misalnya: Apakah library ini berperforma baik? Apakah library ini memenuhi standar bisnis saya untuk aksesibilitas web?

Ada aspek lain dari library dan framework yang mungkin ingin Anda pertimbangkan, dan yang belum banyak dibahas dalam postingan ini:

  • Kemampuan untuk diperluas: seberapa mudah library diperluas 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 memang penting, tetapi apakah arsitektur library secara keseluruhan sudah tepat?
  • Pengujian: apakah project memiliki rangkaian pengujian? Apakah situs project menggunakan badge atau indikator yang diteruskan oleh suite pengujian terhadap commit terbaru?
  • Kompatibilitas: apakah library berfungsi dengan baik dengan library dan/atau framework lain yang saat ini Anda gunakan?
  • Biaya: berapa biaya framework? Apakah open source atau tersedia untuk dibeli?
  • Metrik pamer: metrik ini harus berada di bagian bawah daftar kriteria Anda, atau bahkan diabaikan sepenuhnya, tetapi Anda dapat mempertimbangkan "suara" project, akun media sosial yang mewakili project, dan/atau jumlah bug/masalah terbuka di halaman project.