Semuanya bagus, tetapi jika memakai ini, Anda tidak bisa mengendalikan Wireguard dari sistem. Jika ingin menggunakannya secara terpisah dari tunnel, Anda harus membaginya lewat VM.
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.
Karena urusan akuisisi OpenAI, Claude menghentikan penyediaan lisensi versi terbaru, jadi kalau mau memakai model Claude versi 4.x di Windsurf harus beli API langsung dengan mahal. Apakah Claude akan kembali?
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.
Terlalu menakutkan.
Catatan yang dicatat secara jahat,
mengalahkan ingatan dan pengalaman lalu menjadi bukti
dan sesuatu seperti itu bisa terjadi hingga mengancam kita.
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.
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 div untuk 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.
Sebulan lalu, sambil menggunakan CURSOR untuk mempelajari apa itu AI coding, saya mulai mengembangkan framework pengembangan.
Selama sekitar 3 minggu, saya berulang kali mengalami situasi di mana source code yang sempat berhasil dan tervalidasi oleh AI Agent malah rusak kembali. Saya mencoba segala cara untuk mengendalikan AI Agent, tetapi gagal.
Lalu saya menyadari bahwa sebelum mengembangkan framework pengembangan, prioritas utamanya adalah mengembangkan source code untuk mengendalikan AI Agent.
Akhirnya, tepat 1 bulan setelah mulai karena ingin memahami apa itu AI pertama saya, saya berhasil menyelesaikan pengembangan software yang dapat diimplementasikan 100% dan dioperasikan 100% oleh AI dengan kendali sempurna atas AI Agent (lebih tepatnya, tidak memerlukan LLM eksternal maupun AI Agent).
Saat ini, selama 14 hari terakhir, saya sedang menjalankan proses peningkatan lanjutan dengan melatih tambahan META AI tersebut sambil membuat aturan operasional agar dipatuhi. Pada saat yang sama, saya juga sedang melakukan migrasi, perbaikan, dan standardisasi secara bersamaan terhadap tiga sistem MES yang sebelumnya dibuat secara tidak sempurna oleh manusia, dan kini sudah memasuki tahap akhir.
Dan sekarang saya sedang menyiapkan evolusi lainnya.
Visi inti dari teknologi MCP-B tampaknya adalah sebagai berikut.
"Melalui perantara tepercaya berupa extension Chrome, memanfaatkan informasi pengguna yang sudah dikelola browser dengan aman (cookie, sesi, autentikasi, dan sebagainya),
memanggil dan mengendalikan 'alat (Tools)' yang telah didefinisikan sebelumnya oleh pengembang di halaman web dari jendela chat AI dengan perintah bahasa alami."
Namun, saya merasa "teknologi ini tampaknya tidak punya ruang untuk berkembang", dan saya kira alasannya adalah sebagai berikut.
Resistensi pengguna: Ini adalah hambatan terbesar. Pengguna memiliki penolakan naluriah dan kekhawatiran keamanan terhadap pemasangan extension yang mengakses informasi browser mereka. Jika kenyamanan yang ditawarkan teknologi ini tidak cukup luar biasa untuk melampaui kekhawatiran tersebut, pengguna akan ragu untuk memasangnya.
Beban bagi pengembang web: Selain membuat API yang sudah ada, pengembang situs web juga harus menanggung beban tambahan untuk mendefinisikan dan mengelola 'alat (Tools)' khusus untuk MCP-B secara terpisah. Jika manfaat yang diperoleh dari adopsi luas teknologi ini tidak besar, pengembang tidak akan mau melakukan upaya ganda seperti itu.
Tanggung jawab atas masalah keamanan: Jika insiden keamanan terjadi melalui teknologi ini, bisa menjadi tidak jelas apakah tanggung jawab ada pada pengembang situs web, pengembang extension, atau penyedia model AI. Kompleksitas seperti ini membuat perusahaan enggan mengadopsi teknologi tersebut.
Ketiadaan platform terpusat: Saat ini belum ada direktori atau platform terstandarisasi yang memberi tahu "situs web mana menyediakan alat apa". Pengguna sulit mengetahui fungsi AI apa yang tersedia sampai mereka benar-benar mengunjungi situs web tersebut.
Kesimpulannya,
ide MCP-B sendiri memang sangat menarik dan inovatif secara teknis, tetapi tampaknya tidak dapat memberikan jawaban yang jelas atas pertanyaan mendasar dari pengguna maupun pengembang: "Mengapa harus memakai cara ini?" Dibandingkan pendekatan API yang ada, manfaat yang diperoleh tidak jelas, sementara kekurangan berupa kekhawatiran keamanan dan kompleksitas pengembangan justru jelas terlihat.
Karena itu, untuk saat ini teknologi ini mungkin bisa digunakan secara eksperimental di kalangan sebagian penggemar atau pengembang dengan tujuan tertentu, tetapi tampaknya masih akan menghadapi banyak kesulitan untuk meluas ke seluruh ekosistem web.
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.
Semuanya bagus, tetapi jika memakai ini, Anda tidak bisa mengendalikan Wireguard dari sistem. Jika ingin menggunakannya secara terpisah dari tunnel, Anda harus membaginya lewat VM.
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.
Karena urusan akuisisi OpenAI, Claude menghentikan penyediaan lisensi versi terbaru, jadi kalau mau memakai model Claude versi 4.x di Windsurf harus beli API langsung dengan mahal. Apakah Claude akan kembali?
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.
Filosofi pengembangan yang dikejar tiap orang memang sangat beragam.........
Ternyata AI juga tidak adil.
Terlalu menakutkan.
Catatan yang dicatat secara jahat,
mengalahkan ingatan dan pengalaman lalu menjadi bukti
dan sesuatu seperti itu bisa terjadi hingga mengancam kita.
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.
Saya penasaran kenapa kesepakatan itu batal.
Bentuk pamungkas AI yang menjilat pengguna ternyata adalah AI yang menjilat bos...
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.
Wah, sepertinya masa depan Windsurf juga tidak sepenuhnya cerah.
Sebulan lalu, sambil menggunakan CURSOR untuk mempelajari apa itu AI coding, saya mulai mengembangkan framework pengembangan.
Selama sekitar 3 minggu, saya berulang kali mengalami situasi di mana source code yang sempat berhasil dan tervalidasi oleh AI Agent malah rusak kembali. Saya mencoba segala cara untuk mengendalikan AI Agent, tetapi gagal.
Lalu saya menyadari bahwa sebelum mengembangkan framework pengembangan, prioritas utamanya adalah mengembangkan source code untuk mengendalikan AI Agent.
Akhirnya, tepat 1 bulan setelah mulai karena ingin memahami apa itu AI pertama saya, saya berhasil menyelesaikan pengembangan software yang dapat diimplementasikan 100% dan dioperasikan 100% oleh AI dengan kendali sempurna atas AI Agent (lebih tepatnya, tidak memerlukan LLM eksternal maupun AI Agent).
Saat ini, selama 14 hari terakhir, saya sedang menjalankan proses peningkatan lanjutan dengan melatih tambahan META AI tersebut sambil membuat aturan operasional agar dipatuhi. Pada saat yang sama, saya juga sedang melakukan migrasi, perbaikan, dan standardisasi secara bersamaan terhadap tiga sistem MES yang sebelumnya dibuat secara tidak sempurna oleh manusia, dan kini sudah memasuki tahap akhir.
Dan sekarang saya sedang menyiapkan evolusi lainnya.
Visi inti dari teknologi MCP-B tampaknya adalah sebagai berikut.
"Melalui perantara tepercaya berupa extension Chrome, memanfaatkan informasi pengguna yang sudah dikelola browser dengan aman (cookie, sesi, autentikasi, dan sebagainya),
memanggil dan mengendalikan 'alat (Tools)' yang telah didefinisikan sebelumnya oleh pengembang di halaman web dari jendela chat AI dengan perintah bahasa alami."
Namun, saya merasa "teknologi ini tampaknya tidak punya ruang untuk berkembang", dan saya kira alasannya adalah sebagai berikut.
Kesimpulannya,
ide MCP-B sendiri memang sangat menarik dan inovatif secara teknis, tetapi tampaknya tidak dapat memberikan jawaban yang jelas atas pertanyaan mendasar dari pengguna maupun pengembang: "Mengapa harus memakai cara ini?" Dibandingkan pendekatan API yang ada, manfaat yang diperoleh tidak jelas, sementara kekurangan berupa kekhawatiran keamanan dan kompleksitas pengembangan justru jelas terlihat.
Karena itu, untuk saat ini teknologi ini mungkin bisa digunakan secara eksperimental di kalangan sebagian penggemar atau pengembang dengan tujuan tertentu, tetapi tampaknya masih akan menghadapi banyak kesulitan untuk meluas ke seluruh ekosistem web.
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.
Sok membosankan~…
Di Korea, semuanya berujung pada Java, jadi terasa asing ya wkwk
Menurut saya, teknologi negara lain != data negara lain
Untuk sementara, aku belum percaya sampai dirilis gratis. Grok bahkan harganya 30 dolar, jadi takut buat langganan...
Wkwkwk mahasiswa pascasarjana yang tiba-tiba kena hantam jadi bengong ..