Treadmill Frontend
(polotek.net)- Semakin lama umur sebuah produk, biaya yang lebih besar sering kali bukan berasal dari pemilihan framework frontend, melainkan dari waktu dan energi yang dihabiskan untuk perdebatan penulisan ulang
- Jika sebuah produk masih hidup 5 tahun kemudian, itu berarti sukses, tetapi dalam rentang waktu itu framework yang dipilih kemungkinan besar akan menjadi usang atau berubah drastis dalam versi baru dengan nama yang sama
- Tim produk yang lebih baik tidak buru-buru pindah ke alat baru, melainkan memahami framework yang dipakai saat ini secara mendalam dan meningkatkan kemahiran hingga alat tersebut tidak menghambat kemajuan kerja
- Untuk menurunkan biaya jangka panjang, pilihan yang lebih dekat ke platform web dan teknologi inti web, alih-alih abstraksi yang rumit, bisa menjadi kompromi bisnis yang realistis
- Kompleksitas ekosistem frontend menyulitkan baik developer junior maupun tim perekrutan, dan developer dengan dasar-dasar web yang lemah akan lebih rentan terhadap perubahan stack berikutnya
Sulit keluar dari treadmill hanya dengan menulis ulang
- Banyak tim frontend percaya bahwa penulisan ulang akan membawa keadaan yang lebih baik, tetapi untuk produk yang bertahan lama, pemilihan framework itu sendiri bukan keputusan teknis yang paling penting
- Jika sebuah produk bertahan lebih dari 5 tahun, itu bisa dianggap sukses, namun selama periode itu framework yang dipilih bisa menjadi usang
- Komunitas frontend terus bergerak dengan perubahan sebagai pusatnya, dan kecil kemungkinan hal ini akan berubah dalam waktu dekat
- Bahkan framework populer yang bertahan pun bagian dalamnya bisa berubah sepenuhnya, dan pada praktiknya bisa ditulis ulang di bawah nomor versi baru
- Hal yang perlu difokuskan tim bukanlah mengejar alat baru yang berkilau, melainkan menguasai framework yang sedang digunakan saat ini dengan cukup baik
- Diperlukan pemahaman dan kemahiran sampai alat tersebut tidak menjadi penghalang bagi kemajuan pekerjaan
- Harapan bahwa masalah akan selesai hanya dengan berpindah ke alat pengganti lebih dekat pada sebuah jebakan
Semakin dekat ke platform web, semakin rendah biaya jangka panjang
- Perusahaan yang ingin mengurangi biaya dari teknologi frontend yang cepat usang dapat mempertimbangkan arah yang lebih dekat ke platform web
- Perlu mengurangi abstraksi yang rumit dan mempelajari kembali apa yang sebenarnya bisa dilakukan web
- Ini bukan berarti jawaban untuk semua masalah atau selalu lebih baik tanpa syarat
- Ini bisa menjadi kompromi bisnis yang memberi nilai lebih besar dan menurunkan biaya dalam jangka panjang
- Jika lebih dekat dengan teknologi inti web, saat merekrut engineer yang kompeten di masa depan, perusahaan akan lebih sedikit dipengaruhi oleh klaim bahwa mereka hanya bisa bekerja jika ratusan juta baris kode ditulis ulang
- Bagi engineer secara pribadi juga, memahami teknologi inti web secara mendalam lebih membantu nilai pasar jangka panjang daripada terus mengikuti framework tertentu
- Mungkin harus mengorbankan sebagian daya jual di pasar kerja jangka pendek
- Ini lebih menguntungkan bagi keberlanjutan karier dibanding pendekatan mencoba mempelajari semua teknologi populer
- Mengetahui teknologi tertentu tidak berarti terlindungi dari realitas seperti memburuknya pasar
Preferensi framework dan biaya tim
- Engineer yang memiliki preferensi kuat terhadap framework sebaiknya mencerminkan hal itu dalam syarat pencarian kerja mereka
- Jika sudah masuk ke tim yang menggunakan framework tertentu lalu mencoba mengalihkannya ke framework yang disukai sendiri, itu akan mengguncang tim dan sangat meningkatkan biaya
- Kompleksitas ekosistem frontend saat ini membebani developer junior maupun perusahaan
- Developer junior kesulitan menguasai keterampilan yang cukup untuk mendapatkan pekerjaan dan merasa kewalahan oleh alat yang rumit
- Perusahaan bahkan merasa lebih sulit merekrut developer umum, dan ambang masuk untuk peran developer tetap pun meningkat
- Jika orang yang mempelajari ekosistem teknologi saat ini tidak mempelajari dasar-dasar web, mereka bisa mengalami kerugian serius ketika stack berubah lagi
- Web adalah platform yang cakap dan unik untuk menyampaikan perangkat lunak, dan seiring waktu menjadi semakin baik sambil mempertahankan tingkat kompatibilitas mundur yang tinggi
- Alat dasar saat ini sudah cukup baik, tetapi lapisan framework justru bekerja berlawanan dengan platform alih-alih merangkulnya
1 komentar
Komentar Hacker News
Baru-baru ini saya mengerjakan perubahan sistem build kode frontend dari yarn ke pnpm. Biasanya saya insinyur backend, tapi saya juga cukup banyak berurusan dengan sisi JS.
Hal yang paling menyebalkan saat masuk ke frontend adalah benar-benar semuanya terasa deprecated. Kalau pada 2022 Anda memakai apollo CLI, itu langsung menjadi deprecated dan Anda harus mempelajari alat yang sama sekali berbeda seperti graphql-client, dengan konfigurasi dan opsi yang berbeda total. Pada akhirnya saya mempertahankan yang lama dan hanya mematikan pemeriksaan Node engine di pnpm supaya tidak mengeluh. Kalau mencoba melakukan patch upgrade pada suatu dependensi, type signature bisa rusak, jadi itu juga saya pin, lalu meninggalkan TODO di codebase dengan harapan suatu hari ada yang memperbaikinya.
Begitu akhirnya berhasil dijalankan, ratusan peringatan deprecated mengalir saat instalasi, dan begitu build selesai rasanya ingin langsung kabur.
Rasanya benar-benar aneh melihat seluruh pengembangan frontend menerima breaking change dan deprecated sampai sejauh ini. Saya hampir 4 tahun mengerjakan proyek Rust besar, dan selama itu memang ada beberapa breaking change kecil dari library pihak ketiga, tetapi hanya sekali ada perubahan besar yang memaksa aplikasi dirombak cukup besar. Sebaliknya, di JS rasanya belum sampai 6 bulan pun sudah ada sesuatu yang harus ditulis ulang.
Dunia frontend jauh lebih aktif merangkul media sosial, YouTube, bahkan Twitch dibanding bidang lain. Para influencer seperti ini perlu terus punya materi baru agar tetap relevan, jadi mereka terus-menerus mendorong hal baru yang bisa dijadikan konten.
Ditambah lagi ada budaya konferensi yang aktif. Konferensi frontend dan JS terasa seperti kompetisi besar untuk mempresentasikan topik baru yang sedang naik daun.
Pasar untuk menjual kursus frontend juga besar. Para pembuat kursus harus membuat atasan menyetujui kursus video harga terbatas $700 untuk mempelajari tren baru, dan agar itu terjadi, industri harus dijauhkan dari hal lama yang sudah diketahui semua orang. Jadi mereka mendorong yang baru dengan kuat dan membuat yang lama menjadi deprecated.
Sebuah web app JS murni kecil sekitar 5 KLOC yang saya tulis 15 tahun lalu masih dipakai sekitar 10 orang setiap hari tanpa satu baris pun diubah. Malah lebih tahan dibanding aplikasi Win32.
Menurut saya sebagian besar churn di frontend pada dasarnya lebih dekat ke kegagalan politik dan organisasi.
Saat saya mulai di era JS murni/jQuery, manajemen dependensi pada praktiknya adalah menyalin file
.jske direktorivendor/. Setelah itu nodejs/npm muncul, di frontend sebelum npm juga ada bower, lalu tiba-tiba saran standar menjadi jangan membuat sendiri, unduh saja modul.Namun bahkan saat itu pun banyak orang sudah mempertanyakan apakah benar menyerahkan ribuan baris kode tersembunyi yang tidak dimiliki sendiri kepada para sukarelawan yang membuat open source untuk bersenang-senang.
Sampai sekarang, kalau ingin mempertahankan proyek untuk waktu lama, Anda bisa memilih untuk tidak membuat bagian yang tak terlihat menjadi terlalu membengkak. Masalah kecil bisa ditangani dengan cara seperti, “Kita hanya butuh satu fungsi dari library ini, jadi jangan bergantung pada seluruh library; salin saja fungsi itu ke codebase dan tambahkan test.”
Jadi menurut saya ini bukan masalah JavaScript itu sendiri, melainkan masalah manusia dan proses. Banyak developer JS yang tidak mengalami masalah seperti ini, tetapi sebagian besar ekosistem memang demikian.
Ribuan jam-orang setiap hari dihabiskan untuk memperbaiki akibat breaking change yang ‘sangat penting’™ seperti “Bagaimana kalau MultiselectDropdown kita ubah menjadi MultiSelectButtonDropdown? API-nya juga sekalian kita ganti total!”
Hampir tidak ada budaya yang memahami biaya luar biasa besar dari API yang rusak. Setelah 10 tahun memakai Go, ini terasa sangat membuat frustrasi. Go punya janji kompatibilitas mundur, dan ini tampaknya juga memengaruhi sikap para developer library Go terhadap kompatibilitas dan breaking change. Rasanya benar-benar menyenangkan ketika kode yang ditulis 10 tahun lalu tetap bisa dikompilasi dan berjalan apa adanya di Go terbaru.
Saya juga pernah pindah ke Flutter untuk keluar dari neraka JS/web ini, dan cukup cocok; saya bisa melupakan banyak kompleksitas tak disengaja dari web stack. Namun budaya “tidak apa-apa merusak package” juga mulai merembes ke ekosistem Dart, dan itu sangat menyebalkan.
Sejujurnya menurut saya jauh lebih parah daripada frontend. Frontend setidaknya, berkat TypeScript dan karakteristik bahasanya, membuat lingkup kerusakan tetap relatif sane. Di Python, Anda benar-benar bisa melakukan secara harfiah apa saja, sehingga para penulis library juga benar-benar melakukan apa saja. Kalau ingin mengubah cara modul di-import, silakan ubah; kalau ingin memakai metaclass untuk merusak semua asumsi tentang perilaku class, itu bisa. Anda mungkin mengira static type akan membantu, tetapi hal sepele seperti
Partialsaja tidak bisa, dan menegaskan secara statis bahwa dua objek bertipe sama pun tidak bisa.Saya tertawa saat melihat orang mengeluh karena library berubah. Transisi dari Python 2 ke 3 begitu mengerikan sampai di tempat kerja saya sebelumnya ada monolith Python 100 juta baris yang sama sekali tidak punya rencana untuk upgrade ke Python 3. Pindah dari SqlAlchemy 1 ke 2 adalah migrasi 8 tahap dan pada praktiknya penulisan ulang total; kalau satu saja rusak, situs turun. Tapi orang mengeluh karena React menambahkan hooks secara opsional.
Yang aneh, internet penuh dengan tulisan tentang “treadmill frontend”, tetapi hampir tidak terlihat tulisan yang mengeluh tentang sisi sebaliknya.
Tentang pernyataan bahwa “jika Anda seorang engineer, semakin dalam Anda memahami teknologi web inti, semakin tinggi nilai pasar yang bisa Anda pertahankan seiring waktu”, saya merasa berhak berpendapat karena sudah hampir 20 tahun mengerjakan frontend dan melalui beberapa perubahan paradigma besar
Memahami semua teknologi web inti memang jelas membuat Anda menjadi engineer yang lebih seimbang. Namun saya skeptis apakah itu membuat Anda terlihat lebih menarik di pasar rekrutmen. Bukan karena pengetahuan ini tidak penting, melainkan karena para pengambil keputusan perekrutan umumnya melakukan pattern matching
Jika ingin memaksimalkan “nilai pasar”, Anda tetap harus sangat mahir React. Ini hampir seperti tiket masuk dasar; hal-hal lain memang bagus, tetapi tanpa fondasi itu pilihan Anda akan berkurang. Mungkin penulis sebenarnya bermaksud demikian dan saya saja yang salah membaca
Namun untuk peran seperti konsultasi atau kontraktor, saya setuju dengan komentar asal. Jika Anda pernah bekerja dengan orang-orang di perusahaan konsultasi besar yang merekrut atau menentukan siapa yang layak diwawancarai, mereka hampir otomatis menolak orang yang belum mengetahui stack yang mereka sukai atau yang sedang dipakai klien mereka. Bahkan arsitek teknis pun begitu, jadi ini bukan hanya masalah perekrut non-teknis. Terlepas dari tingkat keahlian, mereka tidak ingin ada waktu untuk beradaptasi dengan teknologi itu sendiri
Dalam peran semacam ini, tetap mengikuti perkembangan terbaru sangat penting. Kalau tidak, manajer perekrutan akan membuang CV karena tidak ada buzzword, bahkan sebelum seorang engineer sempat menilai kemampuan Anda
Mungkin ini kasus yang tidak umum, tetapi tidak pernah menjadi masalah bahwa saya tidak tahu React. Ungkapan “tiket masuk dasar” terlalu kuat
Frontend punya batas kompensasi yang cukup keras. Setelah naik melewati level tertentu, Anda tidak perlu lagi membuat UI
Kebanyakan perusahaan, bahkan perusahaan besar, tidak terlalu peduli, tidak memverifikasi, atau tidak merekrut berdasarkan fondasi inti. Mereka merekrut berdasarkan kriteria seperti “mahir React” atau “banyak pengalaman Next.js”
Fondasi memang bagus ketika membangun sesuatu dari nol, tetapi perusahaan nyata jarang melakukan itu. Biasanya mereka mengambil solusi jadi dengan ekosistem besar dan dokumentasi yang baik. Jika Anda mahir memakai hal-hal itu, Anda akan jauh lebih mudah direkrut, dan fondasinya bisa dipelajari sepanjang proses
Pernyataan bahwa “framework apa pun yang dipilih akan menjadi obsolete dalam 5 tahun” terdengar seperti argumen yang agak usang
Saya bukan developer frontend utama, tetapi saya tidak menghindarinya ketika perlu mengerjakan frontend, dan selama sekitar 10 tahun terakhir saya memakai React. Memang sebagian arus mulai bergeser ke Svelte, tetapi pada saat Svelte menyalip React, kemungkinan Svelte juga sudah dipakai di produksi selama kira-kira selama itu. Angular juga mungkin suatu saat melemah, tetapi jika melihat era Angular1 dan Angular2+ bersama-sama, umurnya lebih panjang daripada React
Memang benar pengembangan frontend bergerak cepat, tetapi tidak seburuk itu. Jika memilih opsi yang membosankan, hasilnya juga membosankan
Angular1 dan 2 nyaris tidak bisa dibandingkan selain namanya, dan banyak developer terkena dampaknya di sini. Angular sendiri juga sedang berubah cukup besar. Tidak separah perpindahan dari v1 ke Angular2, tetapi tetap cukup untuk membutuhkan penyesuaian ulang yang signifikan. Semuanya bergerak ke standalone component, sintaks template baru, signals, dan sebagainya
React juga mirip. Munculnya functional component dan hooks membawa pergeseran paradigma besar. Kompatibel, tetapi keduanya sangat berbeda
Hal yang sama juga berlaku pada paradigma yang lebih umum. Awalnya semuanya server-side rendering, lalu berlari kencang ke single-page app, kemudian kembali lagi ke server-side rendering, tetapi kali ini menjadi server-side rendering parsial dengan hydration
Perbedaannya cukup besar sampai bisa disebut framework lain, jadi meski ada nuance, argumen itu belum sepenuhnya mati
Sangat sederhana untuk dikerjakan. Saya membuat aplikasi alokasi saham sederhana, dan hal yang paling mengejutkan adalah ukuran bundlenya. Dengan gzip ukurannya 9KB, lebih kecil daripada framework mana pun yang saya tahu. Bahkan lebih kecil daripada htmx, yang sampai taraf tertentu mendekati “anti-JS”
Framework lama bisa tetap berjalan sangat lama. Selama masih ada orang yang memahami stack itu dan bisa direkrut untuk mengerjakannya saat dibutuhkan, stack itu belum obsolete. “Tua” atau “legacy” mungkin benar. Namun sampai hari ketika tidak ada lagi orang yang tersisa untuk menanganinya, itu belum obsolete
Menarik menyebut ini sebagai masalah frontend. Ini bukan masalah frontend, melainkan masalah ekosistem raksasa yang terus kedatangan peserta baru
Saya melihat hal yang sama 15 tahun lalu, ketika Java berada di garis depan inovasi. Dalam beberapa tahun, puluhan framework dan beberapa sistem build bermunculan. Perubahan dari React 17 ke 18 jauh lebih kecil dibandingkan perpindahan dari Perl 5 ke 6, atau Python 2 ke 3
Di backend, yang muncul bukan “ayo pakai framework baru”, melainkan “ayo pakai bahasa baru”. Tren terbaru adalah menulis ulang sesuatu dengan Rust; sebelumnya ada Go, Haskell, Scala, dan F#
Kalau menurut Anda memindahkan kode frontend dari React ke sesuatu seperti Svelte itu merepotkan, coba saja tulis ulang aplikasi VB 6. Belum lagi hal-hal seperti RPC yang datanya ada di dalam kode
Ini bukan berarti ketidakstabilan praktik engineering bukan masalah. Itu masalah besar. Hanya saja, itu bukan masalah yang khusus frontend
webpack juga sudah berusia 13 tahun, tetapi bahkan dalam beberapa tahun terakhir cara konfigurasinya berubah secara drastis
Jika konfigurasi Apache berubah sesering sistem-sistem ini, tidak akan ada orang yang memakai Apache
Di tempat kerja sebelumnya, dalam 2 tahun ada dua kali migrasi database, dan total memakan 1 tahun waktu engineering. Bukan hanya beberapa tabel non-inti, melainkan semua tabel. Kalau ada sesuatu yang rusak atau atasan bertanya mengapa semuanya begitu lambat, mereka menyalahkan engineer yang sedang belajar frontend karena dianggap kurang pengalaman
Saya sudah bekerja sebagai developer Java selama lebih dari 25 tahun, dan selama sedikit lebih dari 10 tahun pertama saya mengerjakan full-stack development, yang saat itu merupakan bentuk umum di perusahaan-perusahaan. Sekarang biasanya ada tim frontend terpisah, bahkan sering ada tiga tim: web, iOS, dan Android. Bagi saya, perubahan itu terjadi kira-kira pada masa transisi dari AngularJS ke Angular
Java juga berubah cepat selama sekitar 10 tahun pertama, terutama 3 tahun pertamanya sangat cepat. Namun masa itu sudah berakhir. Java 5 adalah perubahan besar dan Java 8 juga punya fitur-fitur utama, tetapi Java 8 dirilis pada 2014. Tim kami baru belakangan ini pindah ke Java 11, sementara sekarang Java 24 sudah keluar. Saya bahkan belum pernah memakai fitur Java 11 dan tidak tahu apa saja fiturnya. Selama 10 tahun saya tidak mempelajari satu pun fitur bahasa baru
Build tool-nya sama selama 15 tahun terakhir, IDE-nya sama selama 20 tahun terakhir. Framework utama yang dipakai juga sama selama 10 tahun. Saat saya pindah ke pekerjaan terakhir, struktur codebase-nya persis sama dengan tim sebelumnya
Membuat web service dengan Java adalah masalah yang sudah terselesaikan. Dalam arti baik, sepenuhnya membosankan, seperti COBOL
Frontend berubah cepat pada akhir 90-an dan awal 2000-an, tetapi setelah itu pun terus berubah cepat. Proyek UI pribadi yang saya buat beberapa tahun lalu sudah benar-benar usang
Kalau itu proyek Java yang saya kerjakan pada era pasca-EJB, hari ini pun Anda bisa mencari developer Java dan memasukkannya ke proyek itu, lalu ia bisa langsung produktif. Bahkan jika developer itu lahir setelah proyeknya dibuat. Hanya ada beberapa library lama yang perlu dipelajari
Cara turun dari treadmill adalah tidak memakai framework frontend sama sekali. Bukan memilih framework lain secara acak lalu menulis ulang nanti
Yang dibutuhkan adalah server-side rendering, JavaScript hanya saat diperlukan, dan tidak memisahkan tenaga backend dan frontend di dalam perusahaan
Jika satu engineer dapat menulis SQL untuk mengambil kolom yang tepat persis untuk web view SSR, dan juga bertanggung jawab atas web view itu, ia tidak perlu memikirkan API atau ORM sedetik pun. Cukup tahu SQL dan HTML/CSS/JS murni modern. Sebagian besar pekerjaan menjadi mengubah view bisnis (SQL) menjadi DOM (HTML), sementara ekosistem pemrograman sisi server mundur ke belakang
Menurut saya bentuk akhirnya adalah melakukan SSR konten web di dalam RDBMS. Seperti pendekatan Oracle APEX. Namun kebanyakan engineer belum siap untuk percakapan itu. Saya pun begitu saat pertama kali melihatnya di lapangan. Kita terlalu melekat pada cara-cara kita menderita
Itu memperparah masalah frontend yang menjadi terlalu kompleks. Karena ada orang-orang di tim frontend, mereka terus menciptakan pekerjaan dan menambah kompleksitas. Terlalu banyak orang yang hanya tahu web development dan tidak tahu hal lain juga menjadi masalah
Dalam side project, salah satu batasan awal yang saya tetapkan adalah seluruh situs harus tetap mengalami graceful degradation meskipun JavaScript dimatikan. Akibatnya, setiap kali ingin menambahkan fitur yang biasanya dibuat dengan JavaScript, saya bertanya, “bisakah ini dilakukan tanpa JavaScript?” dan sejauh ini, mengejutkannya, jawabannya selalu ya
Dengan CSS selector untuk kontrol HTML dasar saja, sekarang benar-benar banyak hal yang bisa dilakukan. Di codebase itu belum ada satu baris JS pun
Tim produk/desain bisa mendorong untuk memasukkan sebanyak mungkin ornamen JavaScript tanpa sama sekali mempertimbangkan usability, performa, aksesibilitas, atau engineering yang baik
Saya tidak terlalu mahir frontend, dan tidak ada desainer. Backend jauh lebih saya kuasai, tetapi orang lain di tim lebih berbakat daripada saya dalam desain frontend
Saat membuat situs web pertama, saya membaca tulisan seperti “Svelte lebih baik daripada React” dan “solid-js akan menjadi tren besar berikutnya”, lalu mengira itu adalah bagian penting dari pengembangan web
Pemula sebaiknya membaca MDN dan mengabaikan sisanya
Orang membutuhkan tutorial dan walkthrough, serta perlu membangun pemahaman internal tentang cara semua ini bekerja
Framework membantu mengabstraksikan bagian-bagian itu
Namun obsesi terbaru terhadap Next.js dan SSR mungkin tidak demikian. Secara pribadi saya melihat ini bisa menjadi faktor kejatuhan di sisi React
Melihat perkembangan JS murni dan CSS dalam beberapa tahun terakhir, serta fitur menarik seperti animasi
display: noneyang hampir mencapai tahap adopsi, pendekatan membuat HTML template di server dan memakai JS hanya di tempat yang diperlukan tampak lebih masuk akal daripada sebelumnyaIni saya katakan sebagai orang yang sebagian besar mencari nafkah dari React
Seperti penulis, saya juga sudah mengerjakan frontend selama 20 tahun dengan berbagai cara. Ekosistem, churn, dan akrobat menyinkronkan state antara frontend dan backend benar-benar sudah di tingkat gila
Belakangan saya memulai proyek proof of concept dengan Go templates dan HTMX, dan mencoba mendekati nuansa membuat UI dengan “komponen” seperti di React. Masih banyak bagian yang kasar, tetapi ada potensinya. Jujur saya juga belum yakin apakah HTMX memang diperlukan. Saya mulai mengelola event listener sendiri, dan rasanya saya lebih menyukai cara itu
Menariknya, pengelolaan state UI yang kompleks berdasarkan peran dan izin pengguna jauh lebih mudah di server. Cukup kirim HTML yang boleh dilihat pengguna, selesai
Namun React, Vue, dan lainnya punya momentum yang luar biasa. Saya tidak tahu bagaimana pergeseran pola pikir kolektif bisa dimulai. Apalagi mengingat banyak developer hanya tahu framework frontend sebagai cara membuat UI
Saya kurang yakin dengan pernyataan “framework apa pun yang dipilih, 5 tahun kemudian akan obsolete”
Saya sudah memakai React secara profesional selama lebih dari 10 tahun
package.json? Versi node/npm apa yang dipakai tim?Jika memakai versi yang cukup baru dan library populer, Anda pasti pernah melihat peringatan deprecated untuk sub-dependensi menumpuk saat
npm installAgar adil, menurut saya kode React sendiri cukup baik menjaga backward compatibility. Ini bukan kesalahan React. Namun semua sistem build yang dipakai 5 tahun lalu sudah berubah dan memutus backward compatibility. Saya juga sempat lupa soal metode lifecycle komponen
Bahkan proyek yang dikelola sebaik React pun tidak bisa lepas dari kekacauan ekosistemnya
Tidak selalu bisa memilih, tetapi belakangan saya biasanya memilih mengimpor JS murni tanpa sistem build, menangani sebanyak mungkin di backend Python/Django, dan sepenuhnya keluar dari ekosistem JavaScript. Saya tidak pernah menyesal
Apakah aplikasinya masih dibiarkan di React 15?
Semua editor WYSIWYG yang berjalan di React 16 sudah tidak didukung lagi. Jika ditemukan isu keamanan, situasinya menjadi “berharap pada keberuntungan”. Atau sebaiknya jangan dipakai
React 16 masih didukung, tetapi jelas sudah obsolete
Argumen tandingannya adalah jika tidak mengadopsi framework, pada akhirnya Anda membuat framework sendiri yang tidak dipahami orang di luar tim, dokumentasinya umumnya buruk, dan Anda harus terus bekerja menambahkan fitur yang sudah ada di framework yang ada
Di frontend ada fitur-fitur yang umum dibutuhkan dan masalah-masalah umum yang harus diselesaikan. Bukankah lebih baik memulai dengan setidaknya memasang sesuatu daripada mulai dari nol?
Karena orang belum pernah melihat framework internal itu, mustahil mencari orang yang bisa langsung produktif. Meski dokumentasinya sangat baik, tetap butuh waktu untuk mempelajari dan menginternalisasikannya. Untuk perekrutan jangka panjang mungkin bukan yang terburuk, tetapi jika sementara waktu butuh lebih banyak developer, tidak ada jalan keluar
Seperti yang saya tulis di tempat lain, hampir semua orang menginginkan webapp atau merasa mereka punya webapp, tetapi kenyataannya kebanyakan hanya situs web dinamis. Tidak perlu menumpuk framework untuk membuat situs web dinamis
Ini bukan masalah frontend, melainkan masalah ekosistem JS. Ini juga terjadi di backend
Lingkungan JS adalah kekacauan total dengan dependensi yang memiliki puluhan atau ratusan dependensi lain. Misalnya, grafik dependensi Platformatic, framework Node berbasis Fastify, adalah sebagai berikut
https://npmgraph.js.org/?q=platformatic#zoom=h
Dependensi ini bisa ditinggalkan kapan saja. Bahkan dependensi raksasa seperti Axios atau Express pun pernah tampak seperti terbengkalai
Dan setiap dependensi dikendalikan oleh cara yang menurut maintainer-nya benar. Beberapa hari lalu, sebuah dependensi yang dipakai di produksi memutuskan bahwa dukungan untuk versi Safari sekitar 3 tahun lalu boleh dihentikan, meski dependensi itu mencatat sekitar 25 juta unduhan per minggu, sementara React sekitar 26 juta, dan dipakai di 10 juta repositori GitHub. Mengingat pangsa pasar Safari di mobile AS lebih dari 50%, itu benar-benar gila