Verimli Yazılım Geliştirmede Yolumuzu mu Kaybettik?

• Tarayıcıda yaklaşık 30MB’lık bir Word belgesini düzenlemeye çalışırken yaşanan yazma gecikmesi, modern web uygulamalarının performans maliyetini somut biçimde gösteren bir örnek oldu
• Belge çoğunlukla metinden oluşuyor, yalnızca bazı görseller ve tablolar içeriyordu; buna rağmen Google Docs veya Chrome ortamında akıcı şekilde işlenemedi
• Ücretli Microsoft Office yerine kurulan LibreOffice aynı belgeyi çok daha hızlı çalıştırdı ve böylece web uygulamaları ile yerel uygulamalar arasındaki fark belirginleşti
• Modern web uygulamalarının daha fazla bellek ve CPU istemesi, donanımın daha yüksek özelliklere çıkmasının kaynak yoğun web uygulamalarıyla bağlantılı olduğu yönünde bir sorgulamaya yol açtı
• PWA’lerin ve tarayıcı tabanlı arayüzlerin yaygınlaşmasına rağmen, gerçek kullanılabilirlikte yerel render ve verimli yazılım tasarımı hâlâ önemli

---

30MB’lık belgede ortaya çıkan web uygulaması performans sorunu

• Google hesabı ve bulut otomatik eşitlemeden yararlanılabildiği için ilk tercih Google Docs oldu
• Belge Google Docs’a yüklendikten sonra yazı yazmayı denediğinde, karakterlerin ekranda görünmesi birkaç saniye sürdü
• Dosya boyutu yaklaşık 30MB idi; bazı görseller ve basit tablolar vardı ama büyük bölümü metinden oluşuyordu
• Chrome’un veya Google Docs’un bu belgeyi düzgün işleyemediği sonucuna varıldı
• Microsoft Office ücretli olduğu için elendi; onun yerine kurulan LibreOffice aynı belgede oldukça hızlı çalıştı

Verimlilik üzerine daha büyük soru

• Modern araçların, framework’lerin ve dillerin performans açısından yazılımları daha ağır hâle getirip getirmediğini yeniden düşündürüyor
• Kaynak yoğun web uygulamalarını çalıştırabilmek için donanım özelliklerinin yükseldiği, yalnızca saf yerel uygulamalar olsaydı bu tür gereksinimlerin daha düşük olabileceği öne sürülüyor
• Mobil cihazlarda 16GB RAM gerektiren durum örnek gösterilerek, yazılımların artan kaynak tüketimi eleştiriliyor
• Web’in yalnızca basit bir UI render motoru sarmalayıcısı olarak kalmak yerine, yerel render düzeyinde verimlilik kazanması gerektiği savunuluyor
• 1966’daki Apollo bilgisayarı 2KB RAM ile Ay’a inişi mümkün kılmışken, 2024’te tarayıcıda yaklaşık 30MB’lık bir belgeyle çalışmanın bile zor olması, optimizasyon gereğini vurgulayan bir karşıtlık oluşturuyor

[GN⁺]

Hacker News yorumları

• Yerel uygulama yapmak istesem bile Apple ve Microsoft’un sürekli önüme engel çıkardığını hissediyorum. Geliştirici hesabı, ikili dosya imzalama sertifikası ve hiçbir iyi nedeni olmayan gelirin %30’u komisyonunu göze almak gerekiyor; özellikle Microsoft tarafındaki API’ler de kafa karıştırıcı biçimde değişti.
  Bu yüzden daha basit ve ucuz olan webi seçer hale geliyorum.

  • macOS’ta Apple Developer Program yalnızca ikili dosya imzalama ya da Mac App Store üzerinden dağıtım istendiğinde gerekli. Microsoft da yalnızca Microsoft Store’a koyarken ya da şirket belirli bir ölçeğin üzerindeyken Visual Studio kullanıldığında ücret çıkarıyor.
    İmzalanmamış uygulamalar Windows ve macOS’ta çalıştırılabiliyor ama daha fazla uyarı çıkıyor. %30 komisyon da yalnızca Mac App Store veya Microsoft Store kullanıldığında geçerli; Microsoft Store, oyun değilse ve kendi ödeme sisteminizi kullanıyorsanız komisyon almıyor gibi görünüyor.
  • Uzun süre C/C++ geliştirme yaptıktan sonra JavaScript web geliştirmeye geçmemin nedenlerinden biri buydu. Bir iPhone uygulamasını Apple App Store’a koyma süreci cehennem gibiydi; web uygulamaları ise lisans, onay ve kurulum programı gerektirmiyor.
  • Açık konuşmak gerekirse Microsoft için geliştirici hesabı açmak, ikili dosya imzalamak ve gelirin %30’unu paylaşmak zorunlu değil. Microsoft API’lerinin de berbat olduğunu düşünmüyorum; Win32, .NET, UWP gibi seçenekler var ve oldukça iyi çalışıp esnekler.
    Apple’ı çok iyi bilmiyorum ama Mac uygulamaları büyük ihtimalle geliştirici hesabı olmadan da yapılabiliyor; iPhone içinse geliştirici hesabı gerekiyor. Geçmişte gördüğüm fiyat yıllık 99$ idi; ciddi şekilde uygulama yapmayı düşünüyorsanız büyük para değil.
  • Web’de kart ödemesini doğrudan eklerseniz Stripe’a %2,9 + 30¢ ödemeniz gerekir. İşlem ücretinin %6 seviyesine inmesi için 10 dolar almak gerektiğinden, taban fiyat ve ücretlendirme modeli kısıtları ortaya çıkar.
    Chargeback ve iade işlemleri de maliyetlidir; müşteri desteğine zaman ayırmanız ya da insan çalıştırmanız gerekir. Yıllık geliriniz 1 milyon doların altındaysa Apple komisyonu %15’tir; bu yüzden düşük fiyatlı uygulamalar veya katma değerli uygulamalar için Apple, ödemeyi doğrudan işlemeye kıyasla daha iyi bir anlaşma olabilir.
  • macOS, Windows ve Linux için yerel uygulama yaparken bunların hiçbirini yapmak zorunda kalmadım; sadece Qt kullandım.

• Bu yazının, 265 kelimelik tek bir yazı için 10,88 MB indiren Medium’da yayımlanmış olması ironik.

  • Medium açısından asıl içerik reklamlardır. Yazı, reklam denen gerçek içeriği tarayıcıya kadar taşıyan bir aracıdır; reklam teslimatı için de çok fazla karmaşıklık gerekir.
  • Firefox about:process ile baktığımda, yükleme bittikten 10 dakika sonra bile bu yazı 239 MB bellek ve %0,06~0,2 CPU kullanıyordu; CPU zamanının %45’i de Google reCAPTCHA tarafından kullanılıyor gibi görünüyordu.
    Mozilla ya da Google gibi yerlerin alan adına göre CPU, bellek ve enerji kullanım istatistikleri toplayıp performansı umursamayan geliştiricileri herkesin önünde utandırmasını isterdim.
  • Tarayıcılar çoğu işletim sisteminden daha büyük hale geldi; ekosistem de kapalıymış gibi hissettiriyor. WASM hâlâ çok kısıtlı ve web geliştirmede fiilen mümkün olan seçenekler yalnızca JS/HTML/CSS.
    Web yeniden 2005 yılı gibi hissettiriyor. Tek fark, bu kez pop-up’ların sayfanın içine gömülü olması.
  • Böyle durumlarda Gemini tarayıcısıyla gemini://gemi.dev/bin/waffle.cgi adresini açıp URL’yi yapıştırıyorum. Gemini ağını kullanmayanlar URL’de medium.com kısmını scribe.rip olarak değiştirebilir.
  • Metin modlu tarayıcılarda sorun yok.

• Evet, yolumuzu kaybettik ve nedeni basit: Bunu yapabildiğimiz için. En az dirençli yol buydu, biz de o yolu seçtik.
  Yazılım onlarca yıl boyunca donanım gelişiminin sırtından bedavaya geçindi; özellikle web ve masaüstü uygulamalarında böyle oldu. Moore Yasası hem nimet hem lanetti; bugün kullandığımız yazılımlar da bu bedavaya geçişin zirvede olduğu dönemde teknolojiyi öğrenen insanlar tarafından yapıldı.

  • Bilgisayarda yaptığımız işler her yıl neredeyse aynı kalırken yazılımın giderek ağırlaşması insanı çıldırtıyor. 2010’da bile masaüstü ortamı açılmış bir Linux dağıtımı başlangıçtan hemen sonra 100 MB RAM, optimize edilmiş sürümler ise yaklaşık 60 MB kullanıyordu.
    Şimdi 8 GB altı bilgisayar kullanılamaz halde, 8 GB bile zar zor idare ediyor. Yeni yazılımlar Electron kullanıyor ve en az 1 GB RAM yiyor; tarayıcı dahil her şey akıl almaz miktarda bellek tüketiyor.
    Windows’u ise anlamak daha da zor. Annemin bilgisayarına her yardım ettiğimde, yeni sayılabilecek i5 ve 8 GB RAM’li bir PC olmasına rağmen çok yavaş; açılış, program başlatma ve güncellemeler uzun sürüyor. Açılması 1 dakikadan fazla süren bir bilgisayarı camdan atmak isteyecek hale geliyorum.
  • Doğru. Yazılımdaki zor sorunların önemli bir kısmının çözüldüğünü değil, etrafından dolaşıldığını düşünüyorum. Konteynerler bunun tam örneği.
    Birden çok dil ve ortamda uygulama dağıtımı sorununu çözmedik; konteyner motoruyla etrafından dolaştık. Kullanıcı isterse derleyici ve araçları kuran bir build script de verebilirsiniz ama düzgün test etmesi zor olduğundan sonunda konteyner kullanılıyor.
    Redbean ve Cosmopolitan libc bu sorunu “çözmeye” en çok yaklaşan şeyler gibi görünüyordu. Kullanıcıların uygulamayı kolay ve güvenilir biçimde dağıtmasını istiyorsanız konteynerler rekabette avantajlı; bunun hemen ardından da 100 MB’tan fazla disk kullanımı ve bir konteyner motoru geliyor.
  • “Yapabildiğimiz için” mantığıyla yapay zeka ölümcül bot sürülerine kadar gidince Slaughterbots ortaya çıkıyor.
    Devletler veya şirketler arasındaki rekabeti teknolojik gelişmenin temel ilkesi yaptığımız sürece iklim değişikliği, ekosistem tahribatı ve ölümcül yapay zeka gibi küresel krizleri kontrol etmek zor. En üst düzey örgütlenme ilkesi olarak iş birliği ve ortak çalışma gerekiyor; rekabet ise tüm gezegen üzerinde devasa olumsuz dışsallıklar yaratıyor.
  • Katılmıyorum. Sebep framework’ler ve işletim sistemlerinin güvenlik özellikleri; örneğin telemetri gibi şeyler ve bunların kütüphaneleri.
    Lazarus, yani Free Pascal ile yazılmış programlar Windows 11 gibi güncel Windows sürümlerinde bile çok hızlı çalışıyor. Masaüstünde belirli bir amaca yönelik yazılmış yazılımı sürdürmek, hız ve kararlılık için en iyisi.
    Yazılımdaki tüm modernleşme, hem donanım hem framework tarafında, mevcut işlevlerin tamamına bindirilen bir vergi gibi davranıyor.
  • “En az dirençli yol” ifadesini sevdim. Sanki o yolun üzerine özgeçmiş odaklı geliştirme bolca serpilmiş gibi.
    Karmaşıklık tamamen yanlış yerde birikmiş.

• Bu tür şikâyetler tekrarlanıp duruyor ama aslında kimsenin bunu gerçekten istediği yok.
  Geliştiriciler, tamamen entegre ve bağlantılı genel amaçlı bilgi işlem platformu olan web’i seviyor; kullanıcılar da yeterince iyi olduğu sürece performansı pek önemsemiyor gibi. Sonuçta yazılım, kullanıcıları fazla sinir etmeyecek noktaya kadar kötüleşse de tolere ediliyor.
  Yönetim de yeterince iyi yazılım zaten geliştirilmişse daha iyisini yapmakla ilgilenmiyor. Birileri köklü bir kopuş gerektiğine karar vermedikçe hiçbir şey değişmiyor; hangi açıdan bakarsanız bakın değişim için pek teşvik yok.

  • İnsanlar performans ve indirme boyutu konusunda elbette şikâyet ediyor, ama bunu genellikle yan etkiler üzerinden dile getiriyorlar. Dizüstü bilgisayarlarının neden ısındığını, iPhone’un neden “ekran donması” yaşadığını sormaları gibi.
    Çekimi zayıf bir telefonda büyük bir uygulama indirenler, internetin istikrarsız olduğu bölgelerde yaşayanlar ya da düşük gelirli kesimlerde/gelişmekte olan ülkelerde eski cihaz kullananlar, büyük ve yavaş uygulamalar yüzünden hayal kırıklığı yaşıyor. Performans ve uygulama boyutunun umursanmadığını düşünüyorsanız, yanlış kişilere yanlış soruyu soruyor olabilirsiniz.
  • Yazılım şişmesi yeni bir olgu değil. En azından 1990’ların ortalarından beri şikâyetler vardı; daha eskiler bunun 1980’lere hatta 1970’lere kadar gittiğini söyleyecektir.
    Zaman geçtikçe yalnızca şikâyet edenler tuhaf görünür; geri kalanlar ya yükseltme yapar, ya şişkinliği kabullenir ya da eski yazılımı kullanmaya devam eder.
    Yine de bu şişkinliğin sağladığı faydalara da bakmak gerekir. Google Docs sadece bir Word kopyası olsaydı bu kadar kullanılmazdı; ama ücretsiz olması, birden çok cihazdan erişim sağlaması ve sorunsuz iş birliği sunması nedeniyle kullananlar var.
    Ayrıca şişkinlik gibi görünen bazı şeyler aslında kullanım kolaylığındaki artışlardır. Her boyutta güzel görünen orantılı yazı tipleri, Unicode yazı tipleri, bellekten büyük belgeleri işleme, çalışma belgesiyle kaynaklar arasında geçiş, bellek koruması gibi özellikler kaynak tüketir ama yaşam kalitesini artırır.
  • Gerçekten öyle mi, emin değilim. Web geliştiricileri için böyle olabilir ama doğrudan web geliştirmeyi pek yapmadım. Web arayüzü bir tercih; abonelik geliri istemek ve tek seferlik satıştan kaçınmak gibi ticari gereklilikler büyük itici güç gibi görünüyor.
    Modern bulut tabanlı veya yarı çevrimiçi dünya, kullanıcı açısından epey yapay; para kazanma zorunluluğu olmayan OpenOffice gibi örnekler masaüstü uygulaması olarak kalabiliyor.
  • Başarılı olmuş startup’lardan biri, 5 MB’lık paket indiren ve veriyi önceden okuyan tek sayfa uygulamasıydı; başlaması neredeyse 10 saniye sürüyordu.
    Kimse bundan şikâyet etmedi; uygulamanın bazı bölümlerinin performansı berbat olsa bile müşteri şikâyeti nadirdi. Şikâyetler ancak yükleme süresi yaklaşık 60 saniyeye geldiğinde başlamıştı.
    Buna rağmen yazılım, bir hafta süren işi birkaç dakikaya indiren çok değerli bir problemi çözdüğü için müşteriler onu öve öve bitiremiyordu. Rekabet sertleştikçe iyileştirme gerekiyordu ama çoğu kişi gerçekten umursamıyordu ve bu konu her zaman öncelik listesinin en altındaydı.
  • Bu farkın en çok hissedildiği yer, bu tuzağa düşmemiş yazılımları kullanırken ortaya çıkıyor. MYOB EXO/CRM veya SAP ERP gibi sistemler, onlarca yıllık kod tabanlarını çok yavaş değiştirdi; aslında 2000’ler teknolojisi oldukları için hâlâ kullanımı zahmetli, ama bu büyük bir avantaj hâline geliyor.
    Görev Yöneticisi’ni açıp mevcut veritabanının önemli bir kısmı yüklenmiş olmasına rağmen yalnızca 20–30 MB RAM kullandığını görmek keyifli. VLC ve Blender da benzer örnekler.

• Çoğunluğun suçu geliştiricilere atması ilginç, ama gerçekçi bakınca bunların hepsi iş kararı.
  Buluta geçişin nedeni şirketlerin aboneliğin istikrarlı gelirini sevmesi; kurumsal müşteriler de IT ekibi çalıştırmak zorunda kalmıyor ve sorumluluk dışarıya geçtiği için yüksek çalışma süresi talep edebiliyor. Performansın son kullanıcı için “idare eder” düzeyde olması yeterli.
  On-premises yazılım yükseltmelerini reddeden müşteriler uzun bakım döngülerine ve bitmek bilmeyen yamalara yol açtı; web’de bir kez geliştirme yaklaşımı ise her platform için ayrı geliştirici ve testçi bulundurmaktan iş açısından daha avantajlı. Geliştirici uzmanlığı tek başına bu temel güçleri değiştiremez.

  • Belli bir süre sonra o yazılım müşteri için basitçe iyi çalışır. Photoshop buna iyi bir örnek.
    Parlak yeni özellikleri kullanamazsınız belki, ama bir Win7 makinesinde CS4 hâlâ ek ücret olmadan kullanılabilir.
  • Bulut üzerinde de verimli web uygulamaları yapılabilir. Sonuçta bu sadece bir sunucu.
    Sorun, geliştiricilerin kullanıcıların satın alamayacağı performanstaki makinelerde geliştirme yapması ve performans ile verimli koda önem vermemesinde.
  • Birçok geliştiricinin de aynı kararları vereceğini düşünüyorum. Aynı yazılımın platforma özel sürümlerini ayrı ayrı sürdürmek zahmetli; sunucularla uğraşmak da geliştirme süresinden çalıyor.

• 90’ların başında MS Word’ün birkaç floppy diskete sığdığını, ana çalıştırılabilir dosyanın da 2MB olduğunu hatırlıyorum. Toplam RAM’i 2MB olan 16MHz 386’da bile gayet iyi çalışıyordu.
  Bugün yaptığımız işlerin çoğunu o zaman da yapıyordu; eksik olan aşağı yukarı yalnızca dil bilgisi denetleyicisiydi. Artık GB’larla ölçüyoruz, 1000 kat büyüdü ama ne kazandığımızı bilmiyorum. Sadece yolumuzu kaybetmedik, varış noktasının ne olduğunu da bilmez olduk.

  • Kazandığımız şey özellikler ve grafikler oldu.
    Örneğin Linux’taki dict.words bile 4,8MB; Arial Unicode ise yaklaşık 20MB’lık bir yazı tipi. Üzerinde çalıştığım uygulamanın tek bir ikonu 400KB, çökme işleme için kullanılan Google Crashpad handler’ı da birkaç MB.
    4K true-color ekran, 640x480 16 renkli ekrandan 138 kat daha büyük.
  • Birkaç yıl önce 1 Nisan şakası olarak PXE ağ önyükleme sunucusuna DOS/Windows 3.11 disk imajları koymuştum. Çalışan Word 6 for Windows da içindeydi ve gzip ile sıkıştırılmış imaj 12MB içine sığıyordu.
    O dönemin PC’leri UEFI olmadan da boot edebiliyordu; doğru ayarlanınca Windows 3.11 neredeyse anında açılıyor, Word de hemen başlıyordu.
    Bugünkü Word’e epey sayıda çok küçük özellik ve birkaç büyük özellik eklendi ama Microsoft gerçekten isterse bellek kullanımını onda bire indirebileceğinden eminim. Sadece teşvik yok. Bilgisayarlar hızlı, bellek bol ve floppy disketlere bağımlı değiliz; bunu yapmak yalnızca daha fazla maliyet demek.
    Yazılım şişkinliğinin çevre üzerinde göz ardı edilemeyecek bir etkisi olabileceğini düşünüyorum; ama yeterince güçlü bir tepki ya da AB’den yazılım şişkinliği karşıtı bir yasa gibi bir şey çıkmadıkça değişmeyecek.
    Yakın zamanda GitHub’da MS Word for Windows 1.0 kaynak kodunu da gördüm. Asıl yayın Computer History Museum’da ve https://computerhistory.org/blog/microsoft-word-for-windows-... adresinden görülebilir. Saf C idi ve büyük bölümü assembly’ydi; fakat kod, bugünkü C/C++ standartları, kalıpları ve dil özellikleriyle kıyaslanamayacak kadar dağınıktı.
  • Bir zamanlar hurdaya ayrılmak üzere gelen eski bir PowerBook Duo’da nostalji olsun diye Word 5.1’i açmıştım.
    Yazılımın gaz gibi olduğu, kendisine verilen alanı dolduracak şekilde genleştiği şeklinde bir ifade görmüştüm.
    Live dağıtımlarda da benzer durum var. Eskiden CD-R’a sığdırmak için 700MB olurlardı; şimdi 2GB USB’ye sığanını bulmak zorlaştı. Yine de “minimal” yaklaşımının güç kazanması sevindirici.
  • Şirkette makine öğrenimi kodu çalıştıran Docker dosyası 6GiB. Model dosyaları buna dahil bile değil.
    Nvidia, bize tam olarak ne indirtiyor diye düşünüyorum. Asla kullanmayacağımız binlerce üretim kodu kombinasyonunu mu indiriyoruz?
  • Word 6’da bulunan özellikler, fiilen bugün en güncel Word’de de kullandığımız özellikler.
    Ama eklenen şişkin özelliklerin arasında istediğimi bulmak daha uzun sürüyor.

• Minimal yazılım var ama insanlar pek tercih etmiyor. Bağımlılıkları muhafazakâr biçimde seçmeye epey zaman harcıyorum; bu da hafif ve yüksek performanslı bir stack’e yol açıyor.
  Bu aralar Lua, SQLite, Fennel[0], Althttpd[1], Fossil[2], Mako Server[3] gibi araçları tercih ediyorum. Harika, hafif, kararlı ve verimli yazılımları ücretsiz kullanmak mümkün; fakat yaygın yoldan biraz sapmak gerekiyor. Stack Overflow’da sık duyacağınız şeyler değiller.
  Frontend konusunda biraz ikilemdeyim. Native uygulamaları ve web sayfalarını tercih ediyorum ama Tiddlywiki’yi her gün kullanıyorum ve web uygulamalarının bir yeri olduğunu düşünüyorum. Yine de 6MB’lık bir Tiddlywiki dosyası sekmesi RAM’de 155MB kullanırken, çok özelleştirilmiş Emacs oturumum yalnızca 88MB kullandığı için yazarın derdine katılıyorum.
  [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, bildiğim programlama araçları arasında en az değer verilenlerden biri. Lua’da ustalaşmak, programlama becerisini yükseltmenin en iyi yollarından biri.
    Elbette kötü de kullanılabilir; ama diğer dillerin çoğuyla kıyaslandığında Lua programlarının ne kadar küçük ve verimli olabildiği neredeyse şaşırtıcı.

• Sorunun kabaca şöyle olduğunu düşünüyorum: Bir şirket yöneticisi rekabet gücü için geliştiricilere en üst seviye donanım gerektiğine karar veriyor; geliştirici de şirketin verdiği 128GB RAM’li yüksek performanslı dizüstünde web uygulaması geliştiriyor.
  Sonra babasının kullandığı 2010 model aile PC’si gibi ortamlarda test etmiyor ya da pek çok şeyin bozulup kullanılamaz hale geldiğini fark edecek kadar sık ve kapsamlı test etmiyor.

  • Ağ bağlantısı da aynı. Ofiste Wifi 7 ve simetrik gigabit fiber internetle uygulamayı kullanan biriyle, apartman sitesindeki berbat Wi-Fi router’ı ve tüketici tipi internet hattıyla kullanan birinin deneyiminin aynı olması beklenemez.
  • Bu kolayca düzeltilebilir. Geliştirme sırasında geliştirici araçlarını mobil ve kısıtlı bağlantı durumuna ayarlarsınız.
    Böylece mobile-first responsive tasarım, sınırlı ekran alanı ve kötü bağlantıdaki olası sorunlar birinci sınıf öncelikler haline gelir.
    Genelde ürün sorumlusuna sorunu bildirince üstünden geçiliyor. Bu yüzden üçüncü madde “2010 model aile PC’sinde de test ediyoruz ama daha önemli paydaşlar için bu bir öncelik değil” diye düzeltilebilir.
  • Şu an yaptığım işin bir kısmı eski donanımda veya düşük performanslı donanımda, hâlâ kullanılan eski tarayıcılarda ve özellikle mobil ortamda test etmek.
  • Tamamen yanlış bir tahmin değil. Ancak yazının kendisi hayali bir sorunu ele alıyordu.
  • Bununla bağlantılı olarak, Google Android mühendislerinin Android telefonları bizzat kullanıp test edip etmediğini merak ediyorum. Çoğunun Apple kullanıcısı olduğunu sanıyorum.

• Yakın zamanda eski bir sayfayı saf HTML ve backend tarafından üretilen yapıdan React'e taşıdık; yaklaşık bin öğe içeren bir açılır listenin açılması birkaç saniye sürdü. Eskiden tüm sayfa yaklaşık 100ms içinde açılırdı
  İlk başta yalnızca ilk 100 öğeyi gösterip kullanıcının render edilmesi için üç karakter girmesini isteme önerisi geldi. Günümüzün gerçeği biraz böyle
  Elbette pratikte berbat React kodunu düzelttik ve anında render edilir hale getirdik

  • Evet. Çok yaygın bir durum. İlk ekranın gösterilme süresi gibi performans yazıları artarken, React bu türden tamamen yeni bir problem kategorisi yarattı
  • Turbo gibi sunucu tarafı render framework'leri kullanmak yeterli. Bugün insanların istediği istemci tarafı framework'lerin çoğunu denedim ama veri çok olunca hepsi yavaştı; tek istisna Turbo oldu
  • Binlerce seçenek içeren bir seçim kutusu kullanıcı deneyimi açısından berbat görünüyor
    Yeni framework sorunu fazla belirgin hale getirip birinin bunu gerçekten düzeltmesi için gerekçe oluşturabiliyorsa, bu o framework'ü kullanmak için daha da iyi bir neden olabilir

• “idiomatic Ruby” ya da “erken optimizasyon tüm kötülüklerin anasıdır” gibi yazıları öne çıkarıp “geliştirme süresi performanstan önemlidir” deyince sonuç bu oluyor
  Eskiden daha az zamanda daha iyi kod yazan geliştiriciler vardı

  • Katılmıyorum. Günümüzde verimli kod yazmaya yardımcı olan kaynaklar geçmişe göre çok daha fazla
    Eski kodlar arasında, bugün olsa asla yazılmayacak korkunç kod da çok gördüm