Pengembangan yang Terlalu Berpusat pada JavaScript Merusak Web
(jonoalderson.com)Ringkasan Umum
Pengembangan yang Terlalu Berpusat pada JavaScript Merusak Web
- Penyalahgunaan framework JS memperparah kompleksitas website
- Pengalaman pengembang (DX) mengalahkan pengalaman pengguna (UX)
- Bahkan tugas sederhana pun menuntut struktur yang berlebihan
- Performa, aksesibilitas, dan kemudahan pemeliharaan semuanya menurun
- Memulihkan fungsi asli web adalah solusinya
Pendahuluan
Masalah web yang berpusat pada pengembangan
- Sebagian besar website terlalu rumit dan lambat
- Desain yang berpusat pada JS menggeser struktur agar berfokus pada pengembang, bukan pengguna
- Bahkan perubahan sederhana pun umumnya membutuhkan proses deployment yang rumit
Isi
Penyebabnya adalah keinginan agar terlihat seperti aplikasi
- Sejak 2010-an, bersama populernya aplikasi mobile, permintaan akan "web seperti aplikasi" meningkat
- Kompleksitas meningkat tajam setelah framework JS seperti Angular diperkenalkan
- Bahkan konten sederhana pun dikembangkan seperti sebuah sistem
Budaya yang mendahulukan pengalaman pengembang (DX)
- Framework terbaru berfokus pada kenyamanan pengembang
- Abstraksi komponen memicu jarak dengan UX
- Alih-alih bertanya "mengapa blog memakai React", pembahasan kompatibilitas SSR justru lebih diutamakan
Realitas ketika kompleksitas menjadi standar
- Bahkan tugas sederhana membutuhkan struktur multi-tahap seperti build, routing, API, dan cache
- Karena stack yang rumit, non-pengembang tidak bisa mengubah konten
- Perubahan teknologi terlalu cepat sehingga sulit dipelihara
Dampak buruk dari penyalahgunaan framework
- Fitur web yang sudah ada seperti SSR, cache, dan metadata sedang diimplementasikan ulang
- Performa menurun, sementara dependensi terus bertambah
- Pada akhirnya muncul kontradiksi berupa mereplikasi CMS dengan framework JS
Pengulangan yang sia-sia dan biayanya
- Adopsi dan pembuangan framework terus berulang sehingga tidak ada struktur yang stabil
- Fokus bergeser ke penyelesaian kompleksitas internal alih-alih memecahkan masalah pengguna nyata
- Content marketing, SEO, dan eksperimen melambat, sementara pengalaman pengguna memburuk
Kerugian bagi pengguna dan pemasar akibat penyalahgunaan JS
- Perubahan konten membutuhkan campur tangan pengembang
- SEO dan kualitas halaman menurun
- Pengguna mengalami makin banyak ketidaknyamanan seperti loading lambat dan error interaksi
JS hanyalah alat, bukan tujuan
- JS adalah alat yang kuat, tetapi berlebihan untuk sebagian besar website
- Untuk konten statis, HTML, CSS, dan sedikit JS saja sudah cukup
- Vanilla JS, server-side rendering, dan script seminimal mungkin lebih efisien
Konsentrasi kewenangan dan masalah struktural
- Karena stack yang rumit, semua pekerjaan menjadi bergantung pada pengembang
- Dalam struktur organisasi, kekuasaan terkonsentrasi pada pengembang
- Keputusan teknis dibuat berdasarkan kenyamanan pengembang, bukan kebutuhan pengguna
Kesimpulan
Memulihkan hakikat web adalah solusinya
- Dibutuhkan website yang cepat dimuat, mudah ditemukan lewat pencarian, dan mudah dipelihara
- Kembali ke dasar seperti HTML server-rendered, markup semantik, dan JS seminimal mungkin adalah jawabannya
- Dibutuhkan pendekatan yang berfokus pada hasil, bukan teknologi
- Pertanyaan "mengapa memakai teknologi ini?" perlu diajukan
- Web yang sederhana dan berpusat pada pengguna pada akhirnya menghadirkan performa, penghematan biaya, dan fleksibilitas
23 komentar
Coba lihat WordPress saja .. sepertinya itu bisa menjadi jawaban untuk pertanyaan di atas
Pangsa pasarnya juga jauh lebih besar untuk WordPress, meskipun lambat ..
Saya rasa jika ada hasil benchmark sebagai dasar, para pengembang akan lebih bisa berempati. Jika ada coding framework yang berlebihan, tentu situs akan menjadi lambat, tetapi secara pribadi saya justru lebih sering melihat situs yang dibuat dengan kode vanilla lebih lambat dalam hal perpindahan halaman di dalam situs dibanding situs framework yang dioptimalkan. Tentu saja, jika itu situs yang hanya berisi data statis, mungkin yang hanya memakai HTML + CSS akan lebih cepat, tetapi saya tidak yakin di zaman sekarang situs yang hanya berisi data statis itu umum.
Kalau tidak ada React atau Vue,
meskipun mengimplementasikan fungsi yang sama, bukankah kodenya jadi harus dibuat lebih rumit?
Terutama saat menangani pop-up, bahkan hanya meneruskan satu
propssaja kalau memakai JavaScript murni, kodenya jadi jauh lebih kompleks.Kalau untuk hal sesederhana ini saja kodenya sudah jadi rumit, benar-benar
fitur yang kompleks jadi makin sulit diimplementasikan.
Itu memang kompleksitas yang tak terhindarkan. Bukan lagi HTML templat sederhana seperti dulu
Browser yang dipakai orang juga cuma beberapa jenis, tapi kenapa framework-nya bisa sebanyak ini. Bukankah yang terbaik adalah perusahaan yang mengelola browser membuat framework yang paling optimal lalu ikut mengelolanya bersama. Sampai kapan lingkaran setan ini akan terus diulang.
Filosofi pengembangan yang dikejar tiap orang memang sangat beragam.........
Saya setuju dengan fenomenanya, tetapi tidak setuju dengan kesimpulannya.
Penyebab yang tampak di permukaan dari fenomena ini, seperti juga disebutkan di tulisan utama, adalah meningkatnya permintaan terhadap "web yang terasa seperti aplikasi".
Baik sekarang maupun dulu, web sebenarnya tidak cocok untuk membuat "sesuatu yang mirip aplikasi", tetapi kalau dipaksakan habis-habisan, saya rasa tetap "bisa dibuat mirip".
Pada dasarnya, web sejak lahir memang merupakan platform yang dibuat untuk berbagi semacam "dokumen" seperti makalah.
Hal ini bisa dilihat hanya dari komponen dasar HTML.
Lalu muncullah teknologi seperti CGI yang bisa menghasilkan konten dinamis, dan ketika bahasa skrip juga ditanamkan di sisi browser sehingga hasil akhirnya bisa diberi dinamika, mulailah web beranjak dari "web sebagai dokumen".
Masalahnya, sejak momen awal pergeseran itu sampai sekarang, fondasi web tetaplah sistem yang berbasis "dokumen".
Memang banyak teknologi baru seperti WebSocket, WebRTC, WASM, dan lain-lain yang keluar dari orientasi "dokumen", tetapi sampai saat ini sebagian besar situs web masih dikembangkan dengan bergantung pada platform lama yang berbasis "dokumen".
Sampai sekarang pun kita tetap harus menumpuk tag
divuntuk menggambar layar.Sampai di sini itu analisis fenomenanya, lalu muncul pertanyaan: jadi jawabannya apa?
Kalau mengabaikan sepenuhnya soal realisme dan membayangkan fungsi platform berikutnya yang ideal, kira-kira seperti ini.
(Bukan berarti semua situs harus seperti ini, melainkan dibatasi pada situs yang bersifat aplikasi.)
Pertama, browser menjadi semacam peluncur aplikasi.
Sekali diunduh, ia seharusnya bisa dijalankan juga dalam keadaan offline.
Dan aplikasinya diimplementasikan dengan keluar dari html/css/js yang ada sekarang ke bahasa lain.
Dalam proses itu, browser tampaknya bisa menyediakan semacam framework seperti Android.
Cara berkomunikasi dengan server juga tampaknya bisa keluar dari request web yang ada sekarang dan memakai paradigma lain.
Untuk komunikasi yang membutuhkan real-time, mungkin saja tetap memakai komunikasi TCP seperti adanya,
dan kita juga bisa membuat lalu memakai komunikasi RPC yang lebih sederhana dan tidak menggunakan protokol HTTP.
Saya kurang paham maksud bagian terakhir yang Anda sebutkan tentang platform yang ideal.
Pada akhirnya, itu kan cerita dari masa ketika kita mengunduh program native lalu memakai ActiveX di dalamnya.
Inti masalahnya adalah semacam upaya jungkir balik untuk membuat web terasa seperti aplikasi di dalam protokol HTTP yang pada dasarnya berlandaskan pada "dokumen" web,
dan pendapatnya adalah, jika yang dibutuhkan untuk mengatasinya adalah fitur di level aplikasi, bagaimana kalau membuat protokol dan framework baru khusus untuk aplikasi.
Seperti halnya di smartphone program native murni tidak dijalankan secara langsung, melainkan aplikasi yang disandboxing dijalankan, begitu pula strukturnya berjalan di level browser.
Tentu saja, agar tidak berakhir seperti ActiveX, keterbukaan dan standardisasi harus didahulukan.
Menurut saya, meskipun web dibuat seperti aplikasi, tetap sebaiknya diarahkan mendekati kesimpulan yang disebutkan. Jika terlalu banyak menggunakan JavaScript, dari sisi klien jadinya berat.
Sebenarnya bukan berarti tidak ada framework yang bisa mengimplementasikannya seperti itu. Bahkan Next.js pun kurang lebih memungkinkan jika penggunaan client component diminimalkan hanya saat diperlukan, dan di kubu Rails yang disebut orang lain juga ada Hotwire(https://hotwired.dev/), yaitu kumpulan framework (Turbo, Stimulus, dan lain-lain) yang mendukung web seperti aplikasi agar bisa sangat mendekati kesimpulan yang disampaikan penulis.
Saya sepakat dengan kesadaran tema mendasar dari tulisan ini, tetapi ada beberapa bagian yang juga membuat saya agak mengernyitkan dahi.
Sebagai contoh, situs web promosi untuk layanan tertentu yang dioperasikan perusahaan kami mempertahankan kesederhanaan seperti yang dipuji dalam tulisan ini. Untungnya, sebagian besar elemen di situs web ini cukup statis. Kode frontend seperti HTML dan CSS ditulis langsung secara manual oleh manusia tanpa framework apa pun, dan JS juga hanya memakai jQuery serta Google Analytics. Hal-hal seperti pengumuman atau papan buletin diimplementasikan dengan AJAX menggunakan jQuery, tetapi saya tidak menganggapnya sebagai sesuatu yang tidak masuk akal atau terlalu rumit. Menurut saya, itu masih berada pada tingkat yang dulu bisa saya implementasikan ketika pertama kali belajar dasar-dasar pengembangan web sejak lama. Setahu saya, situs ini sudah beroperasi sejak era Internet Explorer, jadi bukan saya yang membuatnya sendiri, tetapi menurut saya hasilnya tidak buruk.
Namun, di sini sudah diterapkan version control Git dan pipeline CI/CD, serta server staging dipisahkan dari server production yang sebenarnya. Jika Pull Request digabungkan ke branch Main, pipeline akan menjalankan bundler lalu otomatis mendeploy artefak hasilnya ke server staging, dan setelah penanggung jawab memeriksa server staging lalu memberikan persetujuan akhir untuk deploy, barulah itu dideploy lagi ke server production. Dulu caranya hanya menimpa langsung file sumber ke server production lewat FTP, tetapi setelah pekerjaan terkait dialihkan ke tim kami, kami mengubahnya menjadi seperti ini.
Apakah ini benar-benar kompleksitas yang tidak rasional? Dulu, mengubah title tag situs web itu berarti cukup masuk langsung ke file HTML di server production memakai AcroEdit yang mendukung koneksi FTP (ya, orang-orang yang dulu menulis langsung HTML situs itu memang masih memakai ini), lalu mengubah satu baris, simpan, dan semua pekerjaan selesai. Jadi mungkin bagi mereka memang terasa seperti itu.
Namun menurut saya, penambahan kompleksitas pada tingkat ini sepenuhnya masih layak ditanggung. Tidak semua pekerjaan setara dengan sekadar mengubah satu title tag, bukan? Dan menurut saya, ada cukup banyak kelebihan: kode lama yang dulu menumpuk hanya sebagai komentar bisa dihapus total tanpa beban karena bisa dikembalikan kapan saja, pelacakan perubahan yang transparan dan rollback menjadi mungkin, dan jika perlu bundler juga bisa menambahkan sedikit optimasi yang lebih mendasar. Penambahan server staging untuk preview sebelum deploy ke lingkungan nyata juga, kalau dilihat dari satu sisi, bisa dibilang sebagai kompleksitas, tetapi menurut saya itu memang diperlukan.
Saya juga punya banyak keluhan soal struktur kode internal berbagai situs web yang menjadi terlalu rumit dan berat. Akhir-akhir ini aplikasi Outlook di Windows berbasis web app, dan belakangan ini rasanya jadi makin berat. Hanya untuk menulis isi email di layar atau memilih seluruh isi saja sudah tersendat-sendat, bahkan sampai muncul "halaman tidak merespons". Karena penasaran kenapa bisa begitu, saya membuka developer tools di Outlook web lalu cukup kaget. Setelah sekali membersihkan cache dan me-refresh, bahkan satu menit kemudian masih terus muncul berbagai request. Ketika saya cek di browser, beberapa gigabyte data tersimpan hanya untuk hal-hal yang terkait dengan situs MS Office.
Namun, tulisan ini mencampuradukkan banyak hal; ada bagian yang saya setujui, tetapi ada juga bagian yang tidak terlalu saya setujui. Soal semantic HTML dan aksesibilitas, justru saya tahu masa lalu malah lebih mengerikan. Selain itu, saya sama sekali tidak bisa berempati dengan klaim bahwa peningkatan developer experience memperburuk user experience, meskipun mungkin itu karena saya bukan developer frontend web. Bahkan klaim bahwa semua kekuasaan dan kontrol terkonsentrasi pada developer terdengar seperti omong kosong. Bukankah di perusahaan kekuasaan ada pada manajemen? Atau apakah struktur perusahaan di Barat memang agak berbeda dari Korea?
Seperti biasa, saya sepenuhnya setuju bahwa keseimbangan dan jalan tengah, serta kesederhanaan dan kepraktisan, adalah nilai penting yang harus diprioritaskan dalam pengambilan keputusan. Namun, tulisan ini berargumen seolah-olah "memperlakukan semua situs web seperti produk perangkat lunak" sepenuhnya merupakan tanggung jawab developer, dan menurut saya justru bagian itulah yang mengaburkan kesadaran masalah yang mendasar. Selain itu, bagian yang tampak seperti meromantisasi 'masa lalu yang indah' ketika semuanya belum tertata justru rasanya lebih layak untuk dikritik.
Bukankah itu cerita yang sama sekali berbeda dari yang Anda bicarakan?
Menurut Anda, pada bagian mana ini benar-benar menjadi cerita yang berbeda?
Pada akhirnya, saya pikir yang dikritik oleh tulisan ini adalah kompleksitas yang berlebihan dan pembengkakan yang ditimbulkannya. Saya tidak menganggap komentar saya sama sekali tidak relevan hanya karena saya tidak menyinggung JavaScript dalam komentar tersebut. Dalam satu sisi, itu juga merupakan kritik terhadap bagian yang lebih periferal. Dan seperti yang sudah saya sebutkan sejak awal dalam komentar saya, saya juga sependapat dengan kesadaran tematis yang mendasar dari tulisan aslinya.
Sepertinya Anda salah memahami maksud tulisan aslinya.
"...di sini sudah ada manajemen versi Git dan pipeline CI/CD, serta server staging dan server produksi yang dipisahkan. Jika Pull Request digabungkan ke branch
main, pipeline akan menjalankan bundler lalu secara otomatis men-deploy hasil build ke server staging. Setelah penanggung jawab memeriksa server staging dan memberikan persetujuan akhir untuk deploy, barulah itu kembali di-deploy ke server produksi. Dulu kami cukup langsung menimpa file asli di server produksi lewat FTP, tetapi setelah pekerjaan terkait dialihkan ke tim kami, prosesnya diubah seperti ini.Apakah ini benar-benar kompleksitas yang tidak rasional?"
Anda mengatakan begitu, tetapi menurut saya ini tulisan yang tidak terlalu relevan dengan topik tersebut. Tingkat pengelolaan deployment seperti itu dan apa yang ingin disampaikan tulisan ini rasanya sangat berbeda.
Maksud tulisan aslinya bukan sekadar mengkritik framework JS yang kian rumit.
Agar praktis, saya akan mengutip dari tautan terjemahan bahasa Korea di atas.
> Sekarang, bahkan untuk sekadar mengubah satu judul saja dibutuhkan 4 engineer, 3 framework, dan pipeline CI/CD. Menerbitkan halaman web telah menjadi sesuatu yang rumit secara tidak masuk akal.
> Sedikit demi sedikit, web telah berubah menjadi sesuatu yang harus dikompilasi sebelum dipublikasikan. Bukan karena pengguna membutuhkannya. Melainkan karena developer ingin merasa modern.
> Semua hal dioptimalkan untuk developer, dan menjadi tidak ramah bagi semua orang lainnya.
> Kita bukan lagi sekadar menoleransi kompleksitas, tetapi menganggapnya sebagai sesuatu yang wajar. Kita berasumsi bahwa setiap situs memerlukan tahap build, bundler, strategi hidrasi, lapisan routing, lapisan API, design system, serta logika invalidasi cache yang cerdik. Kita membangunnya sebagai microservices, meng-host-nya di edge network, dan menerapkan pipeline hanya untuk menyajikan konten yang sederhana.
> Kita sedang membangun ulang fungsi platform seperti WordPress, tetapi hasilnya 10 kali lebih berat dan jauh lebih buruk dalam hal kegunaan. Yang lebih buruk lagi, setiap lapisan baru menambahkan bug baru, masalah kompatibilitas baru, dan beban kognitif baru. Kini kita memelihara logika hidrasi, strategi cache, dan pipeline build hanya agar sebuah homepage sederhana bisa online.
> Kampanye marketing tertunda karena library komponen tidak cukup fleksibel. A/B test dibatalkan karena lapisan analitik tidak kompatibel dengan strategi hidrasi. Pembaruan konten harus menunggu build selama berhari-hari. Penyesuaian SEO dasar pun tenggelam di backlog.
> Marketer tidak bisa memperbarui copy atau menjalankan eksperimen tanpa membuat tiket. Mereka tidak bisa mem-pratinjau konten, menguji layout, atau memublikasikan halaman. Setiap perubahan harus melewati developer, pipeline, persetujuan, dan build ulang.
> Marketer, editor konten, penanggung jawab SEO, dan desainer semuanya tersingkir dari proses. Karena sekarang bahkan tugas sederhana pun membutuhkan kefasihan teknis. Jika Anda ingin mengganti title tag, Anda akan diminta berkonsultasi dengan engineer, dan jika ingin meluncurkan kampanye, Anda akan diminta membuat tiket lalu menunggu dua sprint.
> Semua hal mengalir melalui tim developer. Artinya, tim developer lah yang menentukan apa yang penting, apa yang dirilis, dan apa yang didorong ke belakang prioritas tanpa batas waktu. Dan semakin banyak kompleksitas yang mereka tambahkan, semakin tak tergantikan pula mereka.
Berbeda dengan budaya pengembangan di Korea yang alurnya turun dari manajemen -> perencana -> pengembang, di Barat tidak ada konsep perencana seperti di Korea, dan ada sisi di mana pengembang terlibat aktif dalam perencanaan produk dan semacamnya. PM di Barat, misalnya, juga tidak sepenuhnya identik dengan perencana di Korea, sama seperti cover letter dan surat pernyataan pribadi bukanlah konsep yang sepenuhnya sama. Tentu saja, untuk game yang sangat berciri proyek kreatif dan di mana keseruan serta gameplay itu penting, Barat juga lebih horizontal dibanding Asia, tetapi tetap ada alur dari direktur ke pengembang.
Begitu ya, ada perbedaan seperti itu.
Namun sepertinya itu bukan bagian yang terlalu berkaitan dengan isi di atas.
Gunakan Rails, berbahagialah
Saya setuju dengan inti tulisan ini. Belakangan ini JS terlalu sering dipakai berlebihan, sehingga bahkan saat menggunakan i9-9900k pun banyak situs yang terasa tersendat. Memang spesifikasinya agak tanggung untuk gaming atau pekerjaan berat, tetapi kenyataannya masih sangat banyak komputer kantor dengan spesifikasi yang lebih rendah dari itu.
Karena itu saya menyukai Astro dan Hotwired, framework dengan filosofi bahwa JS sebaiknya digunakan hanya ketika benar-benar diperlukan, seperti untuk bagian yang interaktif atau navigasi halaman yang interaktif. Saya juga menyukai server-side rendering, yaitu merender di sisi server. Sebaliknya, saya sangat tidak suka CSR (termasuk yang hanya merender meta tag di sisi server lalu menangani sisanya dengan CSR). Karena saya melihatnya sebagai pengalihan pekerjaan yang seharusnya dilakukan server kepada klien. Secara pribadi, saya berpendapat bahwa pendekatan SPA tradisional yang menggunakan CSR seharusnya dipakai ketika frontend dijalankan secara lokal di aplikasi seperti Electron. Tentu saja, jika frontend dimuat dari server, maka SSR-lah yang seharusnya digunakan.
Berikut adalah ringkasan respons komentar terhadap postingan yang diklasifikasikan ke dalam 5 jenis:
1. Sangat setuju dan mendukung
Ciri utama: Sepenuhnya setuju dengan argumen tulisan dan mengakui masalah dari stack JS yang kompleks.
Contoh pendapat:
2. Kekhawatiran terhadap penyalahgunaan framework
Ciri utama: Mengkritik penggunaan framework seperti React dan Angular secara berlebihan, serta berpendapat bahwa teknologi yang lebih sederhana sudah cukup.
Contoh pendapat:
3. Setuju sebagian + mempertimbangkan realitas
Ciri utama: Bersimpati dengan argumen tersebut, tetapi juga ada pandangan realistis bahwa kompleksitas tidak terhindarkan atau memang dibutuhkan dalam sebagian situasi.
Contoh pendapat:
4. Kritik terhadap budaya pengembangan dan struktur industri
Ciri utama: Menunjukkan bahwa kelebihan penggunaan framework bukan sekadar masalah teknis, melainkan hasil dari struktur rekrutmen, budaya, dan pemasaran.
Contoh pendapat:
5. Kritik atau penolakan
Ciri utama: Tidak setuju dengan premis tulisan atau mengkritiknya sebagai argumen yang sepihak.
Contoh pendapat:
Wah, dibagi berdasarkan jenis jadi enak dilihat dan bagus ya
Saya setuju dengan masalah 'kompleksitas web yang berlebihan' yang ditunjukkan tulisan aslinya. Namun, saya sulit setuju dengan diagnosis yang hanya menyalahkan budaya developer atau penyalahgunaan framework sebagai penyebabnya. Kompleksitas web saat ini sebagian besar juga merupakan bayang-bayang dari fungsi dan keamanan yang secara tak terelakkan dituntut oleh 'model bisnis'. Tanpa memasukkan poin ini, diagnosisnya mau tak mau hanya akan menjadi setengah matang.
Web bukan lagi sekadar ‘ruang pamer gratis’. Saat ini, selain situs publik, sebagian besar layanan web bertujuan menghasilkan pendapatan. Karena itu, pertanyaan inti dalam memilih teknologi seharusnya bukan “apakah kode ini murni?”, melainkan “apakah teknologi ini membuat bisnis kita berhasil?”.
Dilihat dari sudut pandang ini, ‘web konten ringan’ yang digambarkan secara ideal oleh tulisan asli akan berbenturan dengan tembok kebutuhan bisnis di dunia nyata. Misalnya, bisnis yang menjual konten tidak mungkin dijalankan hanya dengan halaman statis sederhana. Untuk menangani langganan berbayar dan pembayaran, diperlukan logika berbasis status seperti autentikasi pengguna, pemeriksaan status langganan, dan manajemen izin; untuk melindungi konten, lapisan keamanan seperti verifikasi token real-time guna mencegah pembajakan atau akses tanpa izin juga mutlak diperlukan. Lebih jauh lagi, untuk meningkatkan pengalaman pengguna dan conversion rate melalui personalisasi dan A/B test, pemrosesan data dinamis juga dibutuhkan.
Semua ini berada di ranah 'aplikasi yang canggih', dan framework adalah alat yang realistis untuk mewujudkannya.
Tentu saja, tidak semua kompleksitas bisa dibenarkan. Kita perlu membedakan kompleksitas menjadi dua jenis.
Kompleksitas yang tak terelakkan: kompleksitas dengan ROI yang jelas, yang muncul untuk mengimplementasikan fungsi bisnis (autentikasi, pembayaran, personalisasi, dan sebagainya). Ini adalah biaya yang harus ditanggung.
Kompleksitas insidental: kompleksitas yang tidak perlu, yang muncul karena kemudahan pengembangan atau abstraksi teknis yang berlebihan. Ini adalah utang teknis sekaligus pemborosan yang harus terus diukur dan dihilangkan.
Layanan yang sukses membedakan kedua hal ini dan membangun arsitektur yang realistis. Artinya, bagian terdepan yang penting untuk marketing dan SEO dibuat seringan mungkin, sementara area internal yang memerlukan transaksi inti atau fitur personalisasi dijaga kestabilannya dengan basis framework, melalui strategi hybrid yang memungkinkan mereka meraih dua hal sekaligus: kecepatan dan fungsionalitas.
Tulisan asli terlalu memusatkan penyebab memburuknya pengalaman pengguna pada budaya framework, sambil mengesampingkan ‘tuntutan yang tak terelakkan akibat model pendapatan’. Membahas pengembangan web tanpa poin ini tak ubahnya seperti hanya membicarakan menyajikan 'hidangan yang cepat dan lezat' ke meja pelanggan, sambil menganggap tidak ada dapur kompleks yang menyiapkannya dan kasir tempat pembayaran diterima.
Hanya karena web terasa berat, kita tidak bisa serta-merta membuang framework. Menurut saya, pokok persoalannya haruslah bagaimana mengimplementasikan fungsi yang dituntut bisnis seefisien mungkin, dengan biaya serendah mungkin, lalu menyampaikan nilainya kepada pengguna.
Versi terjemahan bahasa Korea ada di bawah ini.
https://junghan92.medium.com/%EB%B2%88%EC%97%AD-%EC%9E%90%EB%B0%94%EC%…