Apakah Kita Kehilangan Arah dalam Membangun Perangkat Lunak yang Efisien?

• Saat mencoba mengedit dokumen Word sekitar 30MB di browser, terjadi jeda saat mengetik, menjadi contoh nyata biaya performa aplikasi web modern
• Dokumen tersebut sebagian besar berisi teks dengan hanya beberapa gambar dan tabel, tetapi Google Docs atau lingkungan Chrome tidak dapat menanganinya dengan lancar
• Di LibreOffice yang dipasang sebagai pengganti Microsoft Office berbayar, dokumen yang sama berjalan jauh lebih cepat, menonjolkan perbedaan antara aplikasi web dan aplikasi native
• Seiring aplikasi web modern menuntut lebih banyak memori dan CPU, muncul kesadaran bahwa peningkatan spesifikasi perangkat keras berjalan beriringan dengan aplikasi web yang intensif sumber daya
• Bahkan ketika PWA dan UI berbasis browser makin meluas, rendering native dan desain perangkat lunak yang efisien tetap penting untuk kegunaan nyata

---

Masalah performa aplikasi web yang terlihat dari dokumen 30MB

• Google Docs dipilih lebih dulu karena dapat memanfaatkan akun Google dan sinkronisasi cloud otomatis
• Setelah dokumen diunggah ke Google Docs dan dicoba diketik, butuh beberapa detik sampai huruf muncul di layar
• Ukuran file sekitar 30MB, berisi beberapa gambar dan tabel sederhana, tetapi sebagian besar adalah teks
• Disimpulkan bahwa Chrome atau Google Docs tidak mampu menangani dokumen ini dengan baik
• Microsoft Office tidak dipilih karena berbayar, dan sebagai gantinya dipasang LibreOffice, di mana dokumen yang sama berjalan sangat cepat

Pertanyaan yang lebih besar tentang efisiensi

• Hal ini mendorong refleksi apakah alat, framework, dan bahasa modern justru membuat perangkat lunak menjadi lebih berat dari sisi performa
• Untuk menanggung aplikasi web yang intensif sumber daya, spesifikasi perangkat keras ikut meningkat; jika yang ada hanya aplikasi native murni, kebutuhan seperti ini mungkin bisa berkurang
• Dengan mencontohkan situasi perangkat mobile yang memerlukan 16GB RAM, penulis mempersoalkan meningkatnya penggunaan sumber daya oleh perangkat lunak
• Web dinilai perlu memiliki efisiensi setara rendering native, bukan sekadar menjadi pembungkus mesin rendering UI sederhana
• Komputer Apollo pada 1966 memungkinkan pendaratan di bulan dengan 2KB RAM, tetapi di browser tahun 2024 bahkan pekerjaan pada dokumen sekitar 30MB pun sulit, kontras yang menegaskan perlunya optimisasi

[GN⁺]

Opini Hacker News

• Rasanya Apple dan Microsoft terus menghalangi meski kita ingin membuat aplikasi native. Harus menanggung akun developer, sertifikat penandatanganan biner, sampai komisi 30% dari pendapatan tanpa alasan jelas, dan khususnya API di sisi Microsoft berubah membingungkan
  Jadi akhirnya memilih web yang lebih sederhana dan murah

  • Di macOS, Apple Developer Program hanya diperlukan jika ingin penandatanganan biner atau distribusi lewat Mac App Store. Microsoft juga hanya berbayar jika mengunggah ke Microsoft Store, atau memakai Visual Studio ketika ukuran perusahaan melewati kriteria tertentu
    Aplikasi tanpa tanda tangan pun tetap bisa dijalankan di Windows dan macOS, hanya saja peringatannya lebih banyak muncul. Komisi 30% juga hanya berlaku jika memakai Mac App Store atau Microsoft Store, dan Microsoft Store tampaknya tidak memungut komisi jika aplikasinya bukan game dan memakai pembayaran sendiri
  • Ini salah satu alasan saya pindah dari pengembangan C/C++ yang sudah lama saya lakukan ke pengembangan web JavaScript. Proses memasukkan aplikasi iPhone ke Apple App Store itu seperti neraka, sedangkan aplikasi web tidak perlu lisensi, persetujuan, atau installer
  • Terus terang, untuk Microsoft, membuat akun developer, menandatangani biner, dan berbagi 30% pendapatan bukanlah kewajiban. Saya juga tidak melihat API Microsoft berantakan; ada opsi seperti Win32, .NET, dan UWP, dan semuanya cukup berjalan baik serta fleksibel
    Saya tidak terlalu tahu soal Apple, tetapi kemungkinan besar aplikasi Mac bisa dibuat tanpa akun developer, sedangkan iPhone membutuhkan akun developer. Harga yang pernah saya lihat dulu $99 per tahun, dan kalau memang serius ingin membuat aplikasi, itu bukan uang yang besar
  • Jika memasang pembayaran kartu langsung di web, Anda harus membayar 2,9% + 30¢ ke Stripe. Harus mengenakan 10 dolar agar biaya transaksi turun ke kisaran 6%, jadi muncul batas bawah harga dan pembatasan model penagihan
    Chargeback dan pemrosesan refund juga memakan biaya, dan Anda harus menghabiskan waktu untuk dukungan pelanggan atau mempekerjakan orang. Jika pendapatan tahunan di bawah 1 juta dolar, komisi Apple adalah 15%, jadi untuk aplikasi murah atau aplikasi bernilai tambah, Apple bisa jadi kesepakatan yang lebih baik daripada memproses pembayaran sendiri
  • Saat membuat aplikasi native untuk macOS, Windows, dan Linux, saya tidak perlu melakukan hal-hal seperti itu dan cukup memakai Qt

• Ironis bahwa tulisan ini dimuat di Medium, yang mengirimkan 10,88MB untuk satu artikel berisi 265 kata

  • Dari sudut pandang Medium, iklanlah konten yang sebenarnya. Tulisan hanya sarana untuk mengangkut konten sebenarnya, yaitu iklan, sampai ke browser, dan pengantaran iklan membutuhkan banyak kompleksitas
  • Saat saya lihat dengan Firefox about:process, bahkan 10 menit setelah selesai dimuat, artikel ini masih memakai memori 239MB dan CPU 0,06~0,2%, dan 45% waktu CPU tampaknya dipakai oleh Google reCAPTCHA
    Saya berharap pihak seperti Mozilla atau Google mengumpulkan statistik penggunaan CPU, memori, dan energi per domain, lalu mempermalukan secara publik para developer yang tidak peduli pada performa
  • Browser sudah menjadi lebih besar daripada kebanyakan sistem operasi, dan ekosistemnya juga terasa tertutup. WASM masih punya banyak batasan, dan dalam pengembangan web pilihan yang praktis tersedia pada dasarnya hanya JS/HTML/CSS
    Web terasa seperti kembali ke tahun 2005. Hanya saja kali ini popup tertanam di dalam halaman
  • Dalam kasus seperti ini, saya membuka gemini://gemi.dev/bin/waffle.cgi dengan browser Gemini lalu menempelkan URL. Bagi yang tidak memakai jaringan Gemini, cukup ganti medium.com pada URL menjadi scribe.rip
  • Di browser mode teks, ini baik-baik saja

• Memang benar kita tersesat, dan alasannya sederhana: karena itu bisa dilakukan. Itu adalah jalur dengan hambatan paling kecil, jadi jalur itulah yang diambil
  Selama puluhan tahun, software menumpang gratis pada kemajuan hardware, terutama di aplikasi web dan desktop. Hukum Moore adalah berkah sekaligus kutukan, dan software yang kita pakai hari ini dibuat oleh orang-orang yang mempelajari teknologi saat masa menumpang gratis itu sedang berlangsung

  • Pekerjaan yang dilakukan dengan komputer hampir sama setiap tahun, tetapi software makin lama makin berat, dan itu membuat frustrasi. Pada 2010 saja, distro Linux dengan lingkungan desktop berjalan memakai RAM 100MB segera setelah start, dan versi yang dioptimalkan sekitar 60MB
    Sekarang komputer dengan RAM di bawah 8GB tidak bisa dipakai, dan 8GB pun hanya pas-pasan. Software baru memakai Electron dan memakan minimal 1GB RAM, sementara semuanya, termasuk browser, memakai memori dalam jumlah yang tidak masuk akal
    Windows lebih tidak bisa saya pahami. Setiap kali membantu komputer ibu saya, meski PC itu memakai i5 terbaru dan RAM 8GB, tetap saja sangat lambat; booting, menjalankan program, dan update memakan waktu lama. Kalau sebuah komputer butuh lebih dari 1 menit untuk booting, rasanya ingin saya lempar ke luar jendela
  • Benar. Menurut saya, banyak masalah sulit dalam software bukan diselesaikan, melainkan diakali. Container adalah contoh persisnya
    Kita tidak menyelesaikan distribusi aplikasi dengan berbagai bahasa dan environment, melainkan menghindarinya lewat engine container. Kalau pengguna mau, kita bisa memberikan skrip build yang memasang compiler dan tool, tetapi karena sulit diuji dengan benar, akhirnya memakai container
    Redbean dan Cosmopolitan libc tampak paling mendekati “penyelesaian” masalah ini. Jika pengguna ingin mendistribusikan aplikasi dengan mudah dan stabil, container unggul secara kompetitif, dan setelah itu langsung ikut terseret disk lebih dari 100MB serta engine container
  • Jika logika “karena bisa” dibawa sampai ke kawanan bot AI pembunuh, jadinya Slaughterbots
    Selama persaingan antarnegara atau antarkorporasi dijadikan prinsip inti pengembangan teknologi, krisis global seperti perubahan iklim, perusakan ekosistem, dan AI pembunuh akan sulit dikendalikan. Di tingkat prinsip organisasi tertinggi, dibutuhkan kolaborasi dan kerja sama, sementara persaingan menciptakan eksternalitas negatif raksasa bagi seluruh planet
  • Saya tidak setuju. Penyebabnya adalah framework dan fitur keamanan sistem operasi, misalnya telemetri, serta library-librarynya
    Program yang ditulis dengan Lazarus, yaitu Free Pascal, berjalan sangat cepat bahkan di Windows modern seperti Windows 11. Mempertahankan software yang ditulis khusus untuk tujuan tertentu di desktop adalah yang terbaik untuk kecepatan dan stabilitas
    Semua modernisasi software, baik hardware maupun framework, bertindak seperti pajak yang dikenakan pada seluruh fungsi yang sudah ada
  • Saya suka ungkapan “jalur dengan hambatan paling kecil”. Rasanya di sepanjang jalur itu bertebaran sangat banyak pengembangan yang didorong oleh CV
    Kompleksitas menumpuk di tempat yang sepenuhnya salah

• Keluhan seperti ini terus berulang, tetapi pada kenyataannya hampir tidak ada yang benar-benar menginginkan keadaan itu
  Pengembang menyukai web, sebuah platform komputasi umum yang sepenuhnya terintegrasi dan terhubung, sementara pengguna tampaknya tidak terlalu peduli soal performa selama hasilnya cukup baik. Pada akhirnya, perangkat lunak boleh menjadi cukup buruk selama tidak terlalu membuat pengguna jengkel
  Manajemen juga tidak tertarik membuat perangkat lunak yang lebih baik jika perangkat lunak yang cukup baik sudah dibuat. Selama tidak ada yang memutuskan bahwa diperlukan perubahan drastis, tidak ada yang berubah, dan dari sudut pandang mana pun insentif untuk berubah sangat kecil

  • Orang jelas mengeluhkan performa dan ukuran unduhan, tetapi biasanya mengungkapkannya dengan membicarakan efek sampingnya. Misalnya bertanya mengapa laptop menjadi panas, atau mengapa iPhone mengalami “layar membeku”
    Orang yang mengunduh aplikasi besar di ponsel dengan sinyal lemah, tinggal di wilayah dengan internet tidak stabil, atau memakai perangkat lama di kalangan berpenghasilan rendah maupun negara berkembang akan frustrasi karena aplikasi yang besar dan lambat. Jika terasa seolah mereka tidak peduli pada performa dan ukuran aplikasi, mungkin pertanyaannya diajukan kepada orang yang salah dengan cara yang salah
  • Pembengkakan perangkat lunak bukan fenomena baru. Keluhan sudah ada setidaknya sejak pertengahan 1990-an, dan orang yang lebih lama berkecimpung mungkin akan menelusurinya sampai 1980-an atau 1970-an
    Seiring waktu, hanya orang yang mengeluh yang terlihat aneh, sementara yang lain melakukan upgrade, menerima pembengkakan itu, atau terus memakai perangkat lunak lama
    Namun manfaat dari pembengkakan itu juga perlu dilihat. Jika Google Docs sekadar tiruan Word, mungkin tidak akan banyak dipakai, tetapi ada orang yang memakainya karena gratis, bisa diakses dari banyak perangkat, dan kolaborasinya mulus
    Selain itu, sebagian hal yang terlihat seperti pembengkakan sebenarnya adalah peningkatan kenyamanan. Fitur seperti font proporsional yang tampak bagus pada ukuran apa pun, font Unicode, penanganan dokumen yang lebih besar daripada memori, perpindahan antara dokumen kerja dan materi referensi, serta proteksi memori memang memakai banyak sumber daya, tetapi meningkatkan kualitas hidup
  • Saya tidak yakin benar begitu. Pengembang web mungkin seperti itu, tetapi saya sendiri hampir tidak pernah melakukan pengembangan web langsung. Antarmuka web adalah sebuah pilihan, dan pendorong besarnya tampaknya adalah kebutuhan komersial untuk menginginkan pendapatan berlangganan dan menghindari penjualan sekali bayar
    Dunia modern yang berbasis cloud atau setengah online ini terasa cukup tidak alami dari sudut pandang pengguna, dan kasus seperti OpenOffice yang tidak perlu dimonetisasi bisa tetap bertahan sebagai aplikasi desktop
  • Salah satu startup yang pernah sukses adalah aplikasi single-page yang mengunduh bundle 5MB dan membaca data terlebih dahulu, dan butuh hampir 10 detik untuk mulai berjalan
    Tidak ada yang mengeluh soal itu, dan meski performa sebagian aplikasi sangat buruk, keluhan pelanggan jarang muncul. Keluhan baru mulai muncul saat waktu loading mendekati 60 detik
    Meski begitu, perangkat lunak itu memecahkan masalah yang sangat bernilai karena memangkas pekerjaan yang tadinya memakan waktu seminggu menjadi beberapa menit, sehingga pelanggan sangat memujinya. Ketika persaingan makin ketat, perbaikan memang diperlukan, tetapi kebanyakan orang benar-benar tidak peduli dan hal itu selalu berada di prioritas paling bawah
  • Tempat perbedaan ini paling terasa adalah saat memakai perangkat lunak yang tidak terjebak dalam perangkap ini. Sistem seperti MYOB EXO/CRM atau SAP ERP telah mengubah codebase yang sudah berusia puluhan tahun dengan sangat lambat, dan pada dasarnya masih berupa teknologi era 2000-an, sehingga tetap tidak nyaman dipakai, tetapi justru itu menjadi keunggulan besar
    Ada kesenangan tersendiri saat membuka task manager dan melihatnya hanya memakai RAM 20–30MB, padahal sebagian besar database saat ini sudah dimuat. VLC dan Blender juga contoh serupa

• Menarik bahwa kebanyakan orang menyalahkan pengembang, tetapi secara realistis semuanya adalah keputusan bisnis
  Perpindahan ke cloud terjadi karena perusahaan menyukai pendapatan stabil dari langganan, sementara pelanggan korporat tidak perlu mempekerjakan tim IT dan tanggung jawab berpindah ke pihak luar, sehingga mereka bisa menuntut uptime tinggi. Performa cukup “lumayan” bagi pengguna akhir
  Pelanggan yang menolak upgrade perangkat lunak on-premises melahirkan siklus pemeliharaan panjang dan patch tanpa akhir, sementara pendekatan mengembangkan sekali untuk web lebih menguntungkan secara bisnis daripada memiliki pengembang dan tester terpisah untuk tiap platform. Keahlian pengembang saja tidak bisa mengubah kekuatan mendasar ini

  • Setelah waktu tertentu, perangkat lunak itu memang berfungsi baik bagi pelanggan. Photoshop adalah contoh yang bagus
    Mungkin fitur terbaru yang mencolok tidak bisa dipakai, tetapi di mesin Win7, CS4 masih bisa digunakan tanpa biaya tambahan
  • Aplikasi web yang efisien tetap bisa dibuat di atas cloud. Pada akhirnya itu hanya server
    Masalahnya ada pada pengembang yang membuatnya di mesin berperforma tinggi yang tidak bisa dibeli pengguna, dan tidak peduli pada performa maupun kode yang efisien
  • Banyak pengembang juga kemungkinan akan mengambil keputusan yang sama. Memelihara versi terpisah dari perangkat lunak yang sama untuk tiap platform itu menyakitkan, dan urusan server menyita waktu pengembangan

• Pada awal 90-an, seingat saya MS Word muat dalam beberapa keping disket, dan file eksekusi utamanya berukuran 2MB. Itu berjalan baik bahkan di 386 16MHz dengan total RAM 2MB
  Sebagian besar pekerjaan yang kita lakukan sekarang juga sudah bisa dilakukan saat itu, hanya belum ada pemeriksa tata bahasa. Sekarang ukurannya dihitung dalam GB, membesar 1000 kali lipat, dan saya tidak tahu apa yang kita dapatkan. Kita bukan hanya tersesat, tapi juga tidak lagi tahu tujuannya

  • Yang didapat adalah fitur dan grafis
    Misalnya, dict.words di Linux saja berukuran 4,8MB, dan Arial Unicode adalah font sekitar 20MB. Satu ikon aplikasi yang sedang dikerjakan berukuran 400KB, dan handler Google Crashpad untuk penanganan crash juga beberapa MB
    Layar true color 4K 138 kali lebih besar daripada layar 640x480 16 warna
  • Beberapa tahun lalu, sebagai lelucon April Mop, saya menaruh image disk DOS/Windows 3.11 di server boot jaringan PXE. Di dalamnya ada Word 6 for Windows yang berfungsi, dan image terkompresi gzip itu muat dalam 12MB
    PC pada masa itu bisa boot tanpa UEFI, dan jika dikonfigurasi dengan benar Windows 3.11 menyala hampir seketika, begitu juga Word langsung terbuka
    Word sekarang memang mendapat cukup banyak fitur sangat kecil dan beberapa fitur besar, tetapi saya yakin Microsoft bisa mengurangi penggunaan memorinya menjadi sepersepuluh jika mereka mau peduli. Hanya saja tidak ada insentif. Komputer cepat, memori banyak, dan kita tidak bergantung pada disket, jadi itu hanya menambah biaya
    Saya pikir pembengkakan software mungkin punya dampak lingkungan yang tidak bisa diabaikan, tetapi hal itu tidak akan berubah kecuali muncul keluhan yang cukup kuat atau semacam undang-undang anti-pembengkakan-software dari UE
    Baru-baru ini saya juga melihat source MS Word for Windows 1.0 di GitHub. Publikasi aslinya ada di Computer History Museum dan bisa dilihat di https://computerhistory.org/blog/microsoft-word-for-windows-.... Itu C murni dan sebagian besarnya assembly, tetapi kodenya sangat berantakan sampai tidak bisa dibandingkan dengan standar atau pola C/C++ modern maupun fitur bahasa sekarang
  • Dulu, karena nostalgia, saya pernah menyalakan Word 5.1 di PowerBook Duo tua yang masuk untuk dibuang
    Saya pernah melihat ungkapan bahwa software itu seperti gas: ia mengembang untuk memenuhi ruang yang diberikan
    Di distro live juga mirip. Dulu ukurannya 700MB agar muat di CD-R, sekarang yang muat di USB 2GB saja makin sulit ditemukan. Meski begitu, saya senang melihat “minimal” mulai mendapat tempat
  • Di perusahaan, file Docker untuk menjalankan kode machine learning berukuran 6GiB. Itu bahkan belum termasuk file model
    Nvidia, sebenarnya apa yang kalian suruh kami unduh? Apakah ribuan kombinasi kode generatif yang tidak akan pernah dipakai?
  • Fitur yang ada di Word 6 pada dasarnya adalah fitur yang juga dipakai di Word terbaru sekarang
    Hanya saja sekarang butuh waktu lebih lama untuk menemukan yang diinginkan di antara fitur-fitur bengkak yang ditambahkan

• Software minimalis itu ada, tetapi orang-orang jarang memilihnya. Saya menghabiskan cukup banyak waktu untuk memilih dependensi secara konservatif, dan itu mengarah ke stack yang ringan dan berperforma baik
  Belakangan ini saya menyukai alat seperti Lua, SQLite, Fennel[0], Althttpd[1], Fossil[2], dan Mako Server[3]. Software yang bagus, ringan, stabil, dan efisien bisa dipakai gratis, tetapi harus sedikit keluar dari jalur umum. Itu bukan hal-hal yang sering Anda dengar di Stack Overflow
  Untuk frontend, saya agak bimbang. Saya lebih suka aplikasi native dan halaman web, tetapi memakai Tiddlywiki setiap hari, dan menurut saya web app memang punya tempat. Namun tab berisi file Tiddlywiki 6MB memakai RAM 155MB, sementara sesi Emacs yang sangat banyak saya kustomisasi hanya memakai 88MB, jadi saya setuju dengan kegelisahan penulis
  [0]: https://fennel-lang.org/
  [1]: https://sqlite.org/althttpd/doc/trunk/althttpd.md
  [2]: https://fossil-scm.org/home/doc/trunk/www/index.wiki
  [3]: https://makoserver.net/

  • Lua adalah salah satu alat pemrograman yang paling diremehkan yang saya tahu. Mahir Lua adalah salah satu cara terbaik untuk meningkatkan kemampuan pemrograman
    Tentu saja bisa juga digunakan dengan buruk, tetapi dibandingkan kebanyakan bahasa lain, betapa kecil dan efisiennya program Lua bisa hampir mengejutkan

• Menurut saya masalahnya kira-kira begini. Eksekutif perusahaan memutuskan bahwa demi daya saing, developer membutuhkan hardware kelas atas, lalu developer membuat web app di laptop berperforma tinggi dengan RAM 128GB yang diberikan perusahaan
  Lalu mereka tidak mengujinya di lingkungan seperti PC keluarga keluaran 2010 milik ayah, atau tidak mengujinya cukup sering dan cukup menyeluruh untuk menyadari bahwa banyak bagian rusak dan nyaris tidak bisa dipakai

  • Koneksi jaringan juga sama. Pengalaman orang yang memakai aplikasi di kantor dengan Wifi 7 dan internet fiber gigabit simetris pasti berbeda dari orang yang memakainya lewat router Wi-Fi buruk di kompleks apartemen dan koneksi internet konsumen
  • Ini mudah diperbaiki. Saat pengembangan, atur developer tools ke mode mobile dan koneksi terbatas
    Dengan begitu, desain responsif mobile-first, ruang layar terbatas, dan potensi masalah pada koneksi buruk diperlakukan sebagai perhatian utama
    Biasanya ketika masalah ini diberitahukan kepada product owner, mereka mengabaikannya begitu saja. Jadi poin ketiga bisa diperbaiki menjadi “kami juga menguji di PC keluarga keluaran 2010, tetapi itu bukan perhatian bagi pemangku kepentingan yang lebih penting”
  • Sebagian dari pekerjaan saya sekarang adalah menguji di hardware lama atau berperforma rendah, browser lama yang masih digunakan, terutama di lingkungan mobile
  • Itu bukan tebakan yang meleset. Hanya saja tulisannya sendiri membahas masalah imajiner
  • Terkait hal ini, saya penasaran apakah engineer Google Android benar-benar memakai ponsel Android untuk pengujian. Saya rasa kebanyakan dari mereka pengguna Apple

• Baru-baru ini saya memindahkan halaman lama dari HTML murni dan pembuatan di backend ke React, lalu satu dropdown dengan sekitar seribu item butuh beberapa detik untuk terbuka. Dulu seluruh halaman bisa terbuka dalam sekitar 100ms
  Awalnya ada usulan untuk hanya menampilkan 100 pertama dan baru merender setelah pengguna mengetik tiga huruf. Memang begitulah kenyataan sekarang
  Tentu saja, pada akhirnya kami memperbaiki kode React yang buruk sehingga bisa dirender seketika

  • Benar. Ini hal yang umum. Sementara makin banyak tulisan soal performa seperti waktu tampil pertama, React telah menciptakan kategori masalah yang sama sekali baru seperti ini
  • Pakai saja framework rendering sisi server seperti Turbo. Saya sudah banyak mencoba framework sisi klien yang diinginkan orang-orang sekarang, tetapi semuanya lambat kalau datanya banyak, dan hanya Turbo yang menjadi pengecualian
  • Kotak pilihan dengan ribuan opsi tampaknya memberi pengalaman pengguna yang buruk
    Jika framework baru membuat masalahnya terlihat begitu jelas sehingga seseorang punya alasan untuk benar-benar memperbaikinya, justru itu makin menjadi alasan untuk memakai framework tersebut

• Ketika tulisan seperti “idiomatic Ruby” atau “optimisasi prematur adalah akar dari semua kejahatan” ditonjolkan, lalu orang mengatakan “waktu pengembangan lebih penting daripada performa”, jadinya begini
  Dulu ada developer yang menulis kode lebih baik dalam waktu lebih singkat

  • Saya tidak setuju. Saat ini ada jauh lebih banyak materi yang membantu menulis kode efisien dibanding masa lalu
    Saya juga pernah melihat banyak kode lama yang mengerikan, yang tidak akan dibuat jika pada zaman sekarang