Apakah Kita Tersesat dalam Membangun Perangkat Lunak yang Efisien?

Sulitnya Membuka File Microsoft Word di Google Docs

• Ayah penulis harus memasang Word di laptop untuk mengerjakan file dokumen Microsoft Word
• Penulis menyarankan Google Docs kepada ayahnya
  • Karena ayahnya sudah memiliki akun Google, mudah digunakan, berbasis cloud, dan tersinkronisasi otomatis
• Namun, saat file dokumen berukuran sekitar 30MB dibuka di Google Docs, Chrome atau Google Docs kewalahan, misalnya butuh beberapa detik sampai teks yang diketik muncul di layar
• Pada akhirnya, LibreOffice dipasang, dan di sana semuanya berjalan sangat cepat

Renungan tentang Standar Perangkat Lunak Masa Kini

• Muncul pertanyaan apakah pengembangan perangkat lunak justru mengalami kemunduran dari sisi performa
  • Apakah alat, framework, dan bahasa modern yang canggih malah membuat kita mundur dalam hal efisiensi
• Spesifikasi hardware terus meningkat untuk menangani web app dan browser
  • Hal ini mungkin tidak perlu jika yang ada hanya aplikasi native murni
  • Mengapa ponsel kini memerlukan RAM 8GB atau 16GB
• Web membutuhkan rendering native, bukan sekadar pembungkus engine rendering UI
  • Alasan file Word 30MB tidak bisa dibuka di Google Docs bahkan di laptop berspesifikasi tinggi adalah karena browser membutuhkan lebih banyak memori dan penggunaan CPU
• Kita tampaknya telah kehilangan cara membangun aplikasi yang teroptimasi, efisien, dan berkinerja baik. Masalah ini harus diperbaiki
  • Komputer Apollo tahun 1966 dengan RAM 2KB berhasil membawa manusia ke bulan, tetapi pada 2024 browser tidak mampu menangani file dokumen 30MB
• Semua orang di industri saat ini berfokus pada web karena mereka memusatkan perhatian pada aplikasi PWA untuk masa depan

Pentingnya Optimasi API

• Optimasi API penting baik di web maupun aplikasi native karena performa API dapat berkontribusi pada performa aplikasi
• Produk penulis, Onradar(https://onradar.io), membantu optimasi melalui pemantauan API
  • Onradar menyediakan pemantauan uptime dan pemantauan berbasis flow untuk API
  • Di flow editor, pengguna dapat membuat skenario pengguna yang dimungkinkan oleh API terkait, lalu Onradar akan mengujinya 24/7
  • Layanan ini memberikan notifikasi saat insiden terjadi

Opini GN⁺

• Masalah kompatibilitas antara Google Docs dan MS Office sudah lama disorot. Hingga kini pun belum terselesaikan sepenuhnya dan masih menimbulkan ketidaknyamanan bagi pengguna. Akan lebih baik jika kedua perusahaan bekerja sama lebih aktif untuk menyelesaikan masalah ini
• Menyelesaikan masalah performa web app hanya dengan menaikkan spesifikasi hardware bukanlah solusi mendasar. Pengembangan perangkat lunak yang menggunakan sumber daya terbatas secara efisien tetap diperlukan
• Mendorong penggunaan aplikasi native adalah salah satu cara, tetapi memperbaiki performa web app sambil tetap memanfaatkan keunggulan web akan menjadi arah yang lebih baik. Portabilitas dan aksesibilitas web app adalah keunggulan yang sulit ditinggalkan
• Optimasi dan pemantauan API adalah elemen penting yang dapat berkontribusi pada peningkatan performa seluruh sistem. Terutama di masa ketika arsitektur microservices semakin dominan, perhatian pada layer API hanya akan semakin besar
• Membandingkannya dengan era Apollo tampaknya kurang tepat. Sulit menempatkan kendali wahana antariksa dan pengolah kata pada level yang sama. Perangkat lunak modern kini jauh lebih besar dan kompleks, sehingga sulit mengharapkan efisiensi seperti pada masa Apollo

[GN⁺]

Opini Hacker News

Ringkasan:

• Apple dan Microsoft menghambat pengembangan aplikasi native dengan mewajibkan akun pengembang, pembelian sertifikat untuk penandatanganan biner, pembagian pendapatan, dan sebagainya. Web adalah alternatif yang jauh lebih sederhana dan murah.
• Berkat hukum Moore, perangkat lunak selama beberapa dekade telah menumpang pada kemajuan perangkat keras. Ini adalah berkah sekaligus kutukan.
• Para pengembang menyukai platform komputasi universal yang sepenuhnya terintegrasi dan terhubung, yaitu web. Pengguna pun tidak terlalu peduli selama kinerjanya cukup baik. Membuat perangkat lunak yang bagus tidak dianggap penting.
• Keputusan bisnis menjadi penyebab utama:
  1. Pindah ke cloud - perusahaan lebih menyukai langganan berkala, dan pelanggan tidak perlu mempekerjakan tim TI sendiri
  2. Pelanggan menolak upgrade perangkat lunak on-premise sehingga siklus pemeliharaan menjadi panjang dan patch terus berlanjut tanpa akhir
  3. Pengembangan web memerlukan biaya lebih rendah dibandingkan pengembangan untuk banyak platform
• Pada awal 90-an, MS Word didistribusikan lewat floppy disk dan file eksekusinya berukuran 2MB. Sekarang ukurannya diukur dalam GB, tetapi tidak jelas apa yang sebenarnya membaik.
• Ada perangkat lunak ringan, tetapi jarang dipilih. Ada perangkat lunak ringan yang sangat bagus seperti Lua, SQLite, Fennel, Althttpd, Fossil, dan Mako Server.
• Untuk frontend, orang cenderung lebih menyukai aplikasi native dan halaman web, tetapi web app seperti Tiddlywiki juga punya kelebihan tersendiri. Namun tetap saja, ia masih menggunakan lebih banyak sumber daya daripada Emacs.
• Ada kasus saat transisi halaman React membuat rendering dropdown memakan waktu lama. Pada akhirnya masalah itu diselesaikan dengan memperbaiki kode React.
• Karena perusahaan menyediakan perangkat berkinerja tinggi untuk pengembang, muncul masalah bahwa pengujian pada PC umum yang lebih lama tidak lagi dilakukan dengan cukup baik.
• Orang banyak membaca tulisan blog seperti "kode idiomatis" dan "optimisasi performa adalah akar dari segala kejahatan", lalu menganggap waktu pengembangan lebih penting. Dulu ada pengembang yang menulis kode lebih cepat dan lebih baik.