Brief by evilfactorylabs

Brief by evilfactorylabs • Untuk obrolan makan siangmu seputar dunia pemrograman. Terbit sebelum jam 13.37 WIB setiap hari Senin & Selasa.

Static Typing untuk Frontend Developer?

Apa yang ingin dicapai untuk frontend development dalam menggunakan static typing?

Static typing sedang menjadi topik yang hangat diperbincangkan. Static typing/statically typed singkatnya adalah sebuah "cara" yang mana sekali kita menetapkan sebuah tipe pada sebuah variable, maka tipe tersebut tidak bisa diubah. Yang artinya, tipe mengarah ke variable, bukan ke nilai.

Contoh singkatnya, kita bandingkan potongan kode dibawah yang ditulis menggunakan Rust dan JavaScript:

Jika dilihat dari kode diatas, di kode Rust, tipe mengarah ke variable. Yang artinya, nilai bergantung dengan tipe yang dimiliki. Beda dengan JavaScript yang mana tipe bergantung dengan nilai.

Proses pemeriksaan typing ini biasanya berada di compile time, yang berarti bahasa program yang memiliki static typing adalah bahasa yang memiliki proses kompilasi.

Beda dengan yang dynamic, yang mana proses pemeriksaan nya berada di runtime. Itulah mengapa bahasa program yang dynamic memiliki runtime error karena proses pemeriksaan berada di runtime, karena tidak memiliki compile time (alias bahasa program ini biasanya interpreted bukan compiled).

Kembali ke pembahasan, static typing terlihat menjanjikan. Tapi sebelumnya, mari kita bahas tentang apa yang "dijual" oleh static typing, alias alasan yang dapat diterima kapan menggunakan static atau dynamic type system.

Yang nanti akan kita bahas khusus untuk konteks seorang Frontend Developer.

Runtime Exceptions

Familiar dengan undefined is not a function? Mengapa itu bisa terjadi? Karena sederhana, ehm, undefined bukanlah sebuah fungsi.

Oke, sederhananya, karena kita memperlakukan sesuatu sebagai sebuah fungsi (yang bisa dipanggil), padahal sesuatu tersebut bukanlah fungsi. Penyebabnya beragam, namun intinya, alih-alih kita ber-ekspektasi itu adalah sebuah function, malah sebuah undefined.

Dengan static typing, exception ini bisa teratasi karena pertama proses checking dilakukan di compile time (bila memang fungsi tersebut ter-eksekusi) dan yang kedua karena kita sudah menetapkan type disitu.

Di contoh diatas sekilas tidak ada perbedaan (lihat di bagian window yang kanan), namun ketika dicoba untuk dieksekusi, untuk function kecilinTapiGakError terdapat compiler error yang intinya program tidak bisa dilanjutkan (untuk di compile) sampai error tersebut diperbaiki.

Bagaimana jika kita tetap mengeksekusi kode diatas? Misalnya untuk yang kecilinTapiError? Sederhana, exception something.toLowerCase is not a function akan muncul di log, dan compiler sudah tau itu.

Dengan menggunakan static typing, kesalahan seperti ini bisa diminimalisir kemunculannya di runtime, karena sudah terjadi di compile time.

Productivity

Selain itu, peran static typing adalah di alasan produktivitas. Biasanya, kita menggunakan pendekatan "named parameter" di JavaScript dengan cara menggunakan object sebagai parameternya.

Dengan bantuan static typing (dan language server) kita tidak perlu capek-capek mengingat sebuah function tersebut memiliki parameter apa saja, dan tipe nya apa saja.

Robustness

Familiar dengan cerita klasik terhadap legacy code? Atau gimana ribetnya mementor developer baru? Ya, static typing bisa membantu untuk membuat akal mu tetap sehat karena ia bisa bertindak sebagai "self-documented" code.

Dengan menggunakan static typing, jumlah wtf per-minute developers akan tidak sebanyak ketika menggunakan yang dynamic typing ketika melihat kode yang ada.


Kita sudah membahas sebagian kecil keuntungan yang didapat ketika menggunakan static typing, apakah ada kekurangannya? Sudah jelas.

Learning Curve

Ya, tidak semua familiar dengan static typing. Dan tidak semua mengetahui maksud dari Promise<any> dan <T, K extends keyof T>(o: T, propertyName: K): T[K] itu apa.

Selain itu, ada yang harus dipelajari lagi terkait idiom yang unik pada suatu bahasa program baik dari sisi paradigma, pola, ataupun sintaksis.

Dengan memilih menggunakan "statically typed language" harusnya organisasi sudah siap untuk membayar biaya di learning curve ini, atau kemungkinan yang terjadi adalah chaos baik terhadap developer ataupun project.

Produktivitas

Benar sekali, anda tidak salah baca.

Selain static type language memberikan produktivitas sebagai "keuntungannya", di sisi lain menjadi kekurangannya juga.

Karena developer harus lebih berhati-hati, harus mengikuti apa yang compiler inginkan (hello @ts-ignore!), dan ya, harus memiliki fondasi yang kuat.

Menggunakan static type language mungkin berpengaruh untuk mengurangi technical debt, khususnya untuk project yang sifatnya long-term. Tapi, harus membayar biaya produktivitas diawal agar bisa menikmatinya untuk waktu yang panjang.

Runtime Exceptions will be always there

At least lebih sedikit dan lebih ter-prediksi.

Menggunakan static typing adalah untuk mengurangi runtime error, bukan untuk menghilangkan. Karena, well, sesuatu yang sedikit mustahil menulis kode tanpa error.

Terlebih, lingkungan web adalah lingkungan yang unik. Pengguna bisa saja memakai peramban paling terbaru versi nightly dan bisa saja menggunakan IE 11 yang terkutuk.

Who knows.

Di lain sisi, developer ingin lebih produktif. Menulis menggunakan gaya async/await tentu lebih singkat daripada menggunakan Promise resolve-reject.

Compiler bisa membantu ini dengan mengubahnya menjadi Promise, namun ada biaya lain yang harus dibayar: Bundle size yang setara untuk semua platform.

Polyfill tentu tidak bisa membantu untuk hal yang sifatnya "syntax sugar" bukan API.

Kebijakan kita sebagai developer akan diuji disini: Dukung semua demi efektivitas atau korbankan beberapa untuk efisiensi. Dan fyi:

Kasus diatas hanyalah salah satu contoh dari "Runtime error pasti selalu ada". Silahkan cari kasus lain, hmm mungkin seperti parse JSON dari server yang ternyata server ngasihnya halaman HTML karena error 503 tapi status code nya 200?

Who knows.

For Frontend Developer?

Melihat ekosistem static typing di dunia frontend seperti adopsi TypeScript, Reason, ClojureScript, Elm, dll menimbulkan pertanyaan "apakah frontend developer perlu menggunakan static typing language?"

Yaa meskipun ujung-ujungnya akan dijadikan (dan dieksekusi) sebagai kode JavaScript juga (hello Wasm!).

Untuk menjawab pertanyaan tersebut, mari kita buat hipotesis berdasarkan sumber valid A (baca: asumsi).

Frontend is become more complex

Thanks to state-driven dan component-based UI, kita perlu mendefinisikan state apa saja yang dimiliki oleh component tersebut. Karena sederhana, rumus dari UI tersebut adalah:

UI = fn(state)

Yang artinya, UI berubah bila state pada UI tersebut ada yang berubah. State pada halaman login sederhana saja ada:

  • Email input
  • Password input
  • Button login
  • Error message

Belum lagi validasi, action toggle, action request dsb yang bereaksi setiap state berubah.

Oh iya, belum lagi ada component yang dimuat secara "malas".

Dan ya, harus konsisten!

Dan hey, pernah mendengar design system?

Untuk menjaga kewarasan seorang developer, perlunya "interface" sangat berguna disini terlebih untuk menambah produktivitas (LSP things).

Siapa yang bisa nginget kalau component Button punya properti onClick, onPress, color, theme, dsb?

Siapa yang bisa inget kalau setiap action button punya state isLoading, isDisabled, isVisible, dan handleClick?

Dan ya, kemunculan propTypes baik di React ataupun di Vue bukanlah tanpa alasan.

Mereka mencoba membawa "fitur static typing" dengan cara mereka sendiri, karena sekali lagi, membuat UI adalah hal yang kompleks, dan harus kompleks.

Dan platform, hanya bisa menjalankan (well, not actually) kode JavaScript yang mana dynamically typed dan terlebih weakly typed.

Refactor is hard as fuck

Dunia Frontend dituntut untuk menghadapi perubahan yang sangat cepat.

Alasannya? Silahkan tanya UX/Product Designer, PM, hasil A/B testing, ataupun metriks di hotjar dan GA.

Entah itu di copywriting, pemilihan warna, posisi CTA, ataupun di kode internal.

Level abstraksi dalam membuat UI mungkin tidak terlalu banyak, biasanya perubahan yang terjadi (di dunia "modern" frontend) adalah di "props".

Dan ya, silahkan cek state manager/container yang kalian pakai berikut dengan flow nya.

Dan hey, apakah ada yang menggunakan design system disini???

Bagaimana cara agar tanpa takut melakukan refactor di kode yang dynamically typed khususnya JavaScript dan dapat tidur tenang di setiap malam?

Pasti kamu tau jawabannya, tapi sabar ya, itu akan kita bahas nanti.

Dengan menggunakan static typing, refactor bisa dilakukan dengan lebih mudah. Entah itu untuk mengubah kode terkait UI, menghapus baris yang tidak perlu, apapun.

"Culture"

Budaya bisa menjadi alasan mengapa Frontend Developer juga harus menulis kode dari bahasa yang menggunakan static typing, entah karena CTO mu dari latar belakang C++, team lead mu dari latar belakang Java, atau ada insiden billion dollar terkait dynamic typing (hello null).

Who knows.

Yang artinya, organisasi sudah siap untuk membayar biaya-biaya terkait learning curve, produktivitas, dsb.

Quality over quantity, they said.

Ya, menggunakan static typing meningkatkan kualitas kode yang mana kualitas tersebut mengarah ke pemeliharaan, abstraksi, dan penggunaan.

Pertimbangan menggunakan static typing khususnya untuk frontend developer adalah untuk menambah kualitas kode, agar kode yang dibuat terkait frontend dapat dipelihara lebih mudah & digunakan untuk waktu yang lama (hello design system???)

Frontend bukan hanya tentang apa yang dilihat langsung oleh pengguna akhir, melainkan ke apa yang dirasakan juga. Performa. Pengalaman pengguna. Yang artinya, frontend bukan cuma menulis kode untuk membuat antarmuka pengguna. Kamu dapat poin nya.

Kesimpulan

Lihat "biaya" yang harus dibayar dibagian "kekurangan" dalam menggunakan static typing, khususnya untuk frontend developer yang biasanya hanya mengetahui HTML, CSS, dan JavaScript.

Jika sekiranya organisasi sudah siap untuk membayar biaya tersebut diberbagai level dan skala, silahkan pertimbangkan untuk pindah/mulai menggunakan static typing.

Jika belum, ada alternatif lain yang memang bisa menjawab permasalahan-permasalahan yang terkait di dynamic typing namun bisa diselesaikan di static typing.

Seperti, menulis test. Menjawab permasalahan runtime exceptions, refactor, robustness, dsb.

Lalu, membuat komentar (seperti menggunakan JSDoc). Bisa menjawab masalah terkait produktivitas dsb.

Dan terakhir, only solves existing problem. Tidak perlu membuat solusi untuk masalah yang tidak ada, karena setiap pilihan pasti ada kekurangannya. Atau juga, menggunakan solusi untuk masalah yang bukan di skala kamu.

Seperti pertimbangan dalam menggunakan static typing, jika organisasimu memiliki masalah yang solusinya harus menggunakan static typing, go do it.

Otherwise, ya biar apa?

Beberapa pertimbangan dalam menggunakan static typing untuk bagian Frontend bisa menggunakan "bahasa program" berikut, diurutkan berdasarkan tingkat kesulitannya:

  • Flow (normal good)
  • TypeScript (neutral good)
  • ClojureScript & Reason (chaotic good)

Mari kita tutup dengan pertanyaan: Apa yang ingin dicapai untuk frontend development dalam menggunakan static typing?

Mungkin masih banyak topik yang tidak ter-cover disini, mari berdiskusi?

Menikmati tulisan ini?

Blog ini tidak menampilkan iklan, yang berarti blog ini didanai oleh pembaca seperti kamu. Gabung bersama Loading... yang telah membantu blog ini agar terus bisa mencakup tulisan yang lebih berkualitas dan bermanfaat!

Pendukung

Dukung Mengapa saya harus mendukung?
You've successfully subscribed to Brief by evilfactorylabs
Great! Next, complete checkout for full access to Brief by evilfactorylabs
Welcome back! You've successfully signed in
Success! Your account is fully activated, you now have access to all content.