Beberapa Alasan Untuk Tidak Mengadopsi Framework Javascript

Angular, Ext JS, React, Vue, Svelte, Alpine, Remix, Blitz, Qwik dan lain-lain. Daftar platform fantastis yang berkembang untuk pengembangan front-end. Saya mulai menggunakannya sekitar tahun 2011 dan terus berlanjut sampai ini hari dengan perubahan yang sering terjadi, selalu mencari teknologi canggih berikutnya.

Namun, dalam beberapa tahun terakhir, saya mulai mempertimbangkan dan mempraktikkan cara alternatif, yang saya sebut pengembangan "brick and mortar", berdasarkan blok bangunan dasar aplikasi web, yakni HTML, CSS, dan Javascript, dengan bantuan yang sangat diperlukan. dari jQuery.

Dengan cara yang agak provokatif, saya ingin menyuguhkan argument di sini untuk mendukung tesis bahwa memilih alat "tingkat rendah" sesuai itu bisa membawa manfaat nyata dalam pengembangan front-end dibandingkan dengan mengadopsi platform canggih seperti Angular atau React. Saya tidak mau meremehkan inovasi yang diperkenalkan oleh alat paling modern, tapi saya mempertanyakan "keberlanjutan" mereka yang sebenarnya dalam pembangunan jangka panjang.

Apa yang salah dengan kerangka kerja lanjutan

1. Terlalu banyak pilihan

Ada terlalu banyak kerangka kerja "canggih" yang ada. Sepertinya bukan masalah, tetapi mungkin itu problem utamanya. Temukan seseorang yang tidak pernah bertanya mengapa platform baru selalu berkembang biak. Sebagai full-stack developer, mengapa saya harus sering berubah, walau frame-work yang saya gunakan sudah sesuai dengan tujuannya?

Terlepas dari pertimbangan individu, banyaknya kemungkinan arsitektur tekhnis memicu berbagai masalah nyata yang berkaitan dengan kualitas dan kuantitas keterampilan yang diperlukan dan keusangan pemecahan.

2. Kurva belajar dan keterampilan pemrograman

Tantangan pertama ialah membangun dan memelihara, dari waktu ke waktu, tim dengan pengetahuan dan keterampilan pemrograman yang memadai untuk pengembangan dan pemeliharaan jangka panjang dari aplikasi web yang dibuat dengan platform canggih itu.

Misalkan kita ingin mengembangkan sistem yang cukup kompleks dengan platform X (di mana X bisa berarti Angular, React, Vue, atau eXtra-Cool-JS-Framework lainnya). Kandidat yang ideal untuk bergabung dengan tim pemrograman harus memiliki kualitas berikut :

pengetahuan kerja yang sangat baik tentang dasar-dasar (HTML, CSS, JS, jQuery)
keahlian yang baik dari platform X (mudah-mudahan dalam inkarnasi terbarunya)
pengalaman kerja dengan praktik terbaik di X Setidaknya satu orang senior dalam tim juga harus tahu
apa cara terbaik untuk menyusun sistem dengan teknologi X yang hebat Realitas yang menyedihkan ialah bahwa kita beruntung jika kita menemukan seorang yang mendekati #4, kita bisa mendapatkan beberapa anak lelaki atau wanita dilatih di X (#2) tapi tidak begitu bisa diandalkan di #1, dan kita menyerah pada

Keberadaan banyak sekali platform pengembangan lanjutan mengurangi jumlah specialist yang ada untuk tiap-tiap platform.

Adopsi awal platform dapat memperumit masalah: tidak ada seorang pun dalam tim yang memiliki senioritas yang cukup untuk memanfaatkan teknologi dengan cara terbaik. Dalam hal ini, hasilnya adalah beberapa produk setengah matang dengan sisa teknologi lama bercampur dengan komponen baru dalam urutan yang jarang.

Jika itu tidak cukup, manajer proyek mungkin tidak cukup tahu tentang X untuk menilai keefektifan dan ketepatan pilihan desain yang dibuat.

Sebaliknya, dalam tim proyek bata-dan-mortir, satu-satunya hal yang diperlukan adalah pengetahuan yang baik tentang alat dasar yang sama yang selalu tersembunyi: HTML, CSS, Javascript, dan jQuery. Blok bangunan yang sama dari ratusan juta situs web.

3. Maintenance and volatility

Pertimbangkan tiga fakta sederhana:

sistem aplikasi terbaik bertahan bertahun-tahun (catatan saya adalah sistem ERP, dibangun 20 tahun yang lalu, masih berjalan)
cepat atau lambat, seseorang yang tidak menulis perangkat lunak akan melakukan pemeliharaan
platform pengembangan tercanggih berevolusi dengan cepat (atau, terkadang, mati)

Dengan premis-premis ini, apakah menurut Anda lebih murah untuk mempertahankan, dari waktu ke waktu, sistem yang dibangun dengan alat dasar yang sangat stabil atau yang dibuat dengan teknologi terbaru yang terbaik dalam evolusi berkelanjutan?

Tebaklah.

Selain itu, pertimbangkan hal-hal berikut: berapa probabilitas alat yang Anda pilih akan menjadi alat utama beberapa tahun setelah pengembangan awalnya?

4. Struktur dan Sintaks(Diedit)Pulihkan teks asli

Platform terbaik bertujuan untuk mengurangi pekerjaan pengembang, khususnya dengan memperkenalkan sintaks yang lebih ringkas dan banyak operasi implisit yang dibuat oleh kerangka kerja atas nama pemrogram.

Pendapat saya adalah bahwa niatnya baik, tetapi mereka telah bertindak terlalu jauh karena beberapa alasan:

Setiap kerangka telah mengeksploitasi kebebasan sintaksis HTML dengan caranya sendiri, memperkenalkan ekstensi berpemilik, terkadang dengan sintaks eksotis. Beberapa framework bahkan mengizinkan developer untuk menambahkan ekstensi HTML mereka sendiri.
Pengikatan data otomatis dan manajemen status mungkin rumit untuk dikontrol dan dioptimalkan, dibandingkan dengan solusi JS/DOM "sepele" yang sesuai
Sintaks yang ringkas, kode yang disematkan dalam tag, manajemen peristiwa otomatis, dan logika pemrosesan tersembunyi dapat mempersulit proses debug.
Framework memiliki tapak yang tidak ringan dan seperangkat alat/perpustakaan tambahannya sendiri yang diperlukan untuk berfungsi. Lebih banyak alat berarti kurva pembelajaran yang lebih curam dan lebih banyak kemungkinan masalah kompatibilitas seiring perkembangan platform.
Tidak ada framework JavaScript yang menghilangkan kebutuhan untuk menggunakan library tambahan untuk mengadopsi solusi “terbaik” yang tersedia untuk antarmuka pengguna.

5. Mitos palsu dan kenyataan pahit

Adopsi kerangka kerja sering kali didorong oleh efek “rumput tetangga selalu lebih hijau”. Sangat mudah untuk tertipu oleh klaim yang lebih mirip promosi pemasaran daripada fakta yang dapat diverifikasi secara objektif.

Mitos no. 1: Pengembangan lebih cepat

Sulit untuk dibuktikan, sama seperti sulit untuk membuktikan sebaliknya. Aplikasi web non-sepele apa pun membutuhkan banyak waktu dan banyak kode, bahkan dengan kerangka kerja paling canggih sekalipun.

Mitos no. 2: Arsitektur software yang lebih baik

Kebaikan dan kebenaran tidak bergantung pada alatnya tetapi pada metode, kedisiplinan, dan ketrampilan. Semakin kompleks kerangka kerja, semakin mudah untuk tidak memanfaatkan sepenuhnya kemungkinannya dan membuat kesalahan penataan.

Mitos no. 3: Performa yang lebih baik

Untuk beberapa framework, ini jelas-jelas salah.

Dalam semua kasus lain, Anda mungkin tidak akan melihat keunggulan kinerja ini dalam kehidupan nyata. Bahkan jika sebuah platform membuat beberapa fungsi tertentu menjadi lebih cepat, waktu respons aplikasi web bergantung 99,99% pada fungsi dan datanya serta cara desainnya. Itu tidak pernah tergantung pada kerangka yang digunakan.

Di sisi lain, dalam menghadapi beberapa keuntungan hipotetis, mudah untuk menemukan beberapa kerugian nyata dan non-hipotetis dalam penggunaan kerangka lanjutan:

Fakta tidak nyaman no. 1: Kurva belajar dan kekurangan keterampilan Ketersediaan keterampilan profesional pada platform lanjutan terfragmentasi. Dalam jangka panjang, kesulitan dalam mendapatkan sumber daya pemeliharaan mungkin akan semakin besar.
Fakta tidak nyaman no. 2: Keusangan Sebagian besar platform ini akan menghilang atau, paling banter, tetap menjadi fenomena khusus. Yang paling sukses maju dengan kecepatan sedemikian rupa sehingga aplikasi yang dibuat dengan versi lama menjadi usang (dan karenanya sulit dipertahankan) dalam beberapa tahun.
Fakta tidak nyaman no. 3: Kehilangan kontrol teknis Kerangka kerja yang lebih canggih memperlemah kemampuan Anda untuk mengontrol mekanisme internal aplikasi. Penentuan dan pengoptimalan masalah dapat menjadi tugas yang sulit.

Banyak omong kosong?

Seperti yang saya perkirakan, artikel ini bertujuan untuk, setidaknya sebagian, menjadi provokasi. Saya orang pertama yang bersemangat tentang teknologi baru. Saya selalu jatuh cinta dengan alat inovatif yang kebetulan saya gunakan. Namun, pada saat yang sama, saya menyadari bahwa sering kali antusiasme awal mengarah pada pengabaian aspek-aspek yang lebih konkret mengenai kemampuan suatu produk untuk bertahan dari waktu ke waktu.

Saya ingin tahu pendapat Anda. Adakah di antara Anda yang memberi saya alasan kuat untuk mengadopsi kerangka kerja tertentu di atas yang lain atau kerangka kerja apa pun di atas tidak sama sekali?