2024'te JavaScript Şişkinliği
(tonsky.me)- Web sayfalarının gerçek içerikten çok daha büyük sıkıştırılmamış JavaScript indirmesi yaygınlaştıkça, basit açılış sayfalarından iş uygulamalarına kadar tarayıcı yükü artıyor
- Ölçüm, macOS üzerinde Firefox'ta eklentiler ve önbellek kapatılarak yalnızca JavaScript için yapıldı; görüntü, video ve stiller hariç tutularak kod çalıştırma maliyetine odaklanıldı
- Wikipedia 0,2 MB iken Linear 3 MB, Zoom ve Vercel 6 MB, GitLab 13 MB gibi basit sayfalar bile birkaç MB'den çift haneli MB seviyelerine çıkıyor
- Uygulama tarafında Gmail 20 MB ve FastMail 2 MB ile 10 kat fark gösterirken, Jira yaklaşık 50 MB ve Slack 55 MB gibi sohbet ve iş araçlarının kod miktarı özellikle büyük
- JavaScript, indirildikten sonra da ayrıştırma, bellekte tutma ve çalıştırma maliyetleri oluşturduğu için, küçük bir içeriği render etmek adına dev kod paketlerine ihtiyaç duyan yapı performans ve pil üzerinde doğrudan yük oluşturuyor
Ölçüm yöntemi ve karşılaştırma ölçütü
- Ölçüm ortamı macOS üzerinde Firefox idi; tarayıcı değişse de genel olarak benzer olacağı varsayımıyla ilerlenmiş
- Koşullar şöyleydi
- Gizli mod değil, normal mod
- Tüm eklentiler devre dışı
- Yalnızca JavaScript ölçüldü
- Sıkıştırılmamış boyut esas alındı
- Service Worker etkin
- Önbelleğin devre dışı bırakıldığı soğuk yükleme
- İçerik, siteden siteye çok değiştiği için karşılaştırmanın dışında bırakıldı
- YouTube'daki video ile Slack'teki metin mesajlarının boyutu doğası gereği farklı
- JavaScript, etkileşim karmaşıklığını karşılaştırmak için ortak metrik olarak kullanıldı
- Esas nokta, tarayıcının kodu ayrıştırmak ve çalıştırmak için üstlenmesi gereken iş yükü
- Referans noktası olarak tonsky.me blogunun kendisi 0,004 MB ölçülmüş
Açılış sayfaları ve statik içerik
- Biraz etkileşim içeren sıradan sayfa örneklerinde Wikipedia yaklaşık 0,2 MB seviyesinde
- Daha ağır açılış sayfaları şöyle
- Linear: 3 MB
- Zoom: 6 MB
- Vercel: 6 MB
- GitLab: 13 MB
- Yukarıdaki sayılar görüntü, video ve stiller hariç yalnızca JavaScript kodunun boyutu
- Statik metin gösteren web siteleri de birkaç MB JavaScript indiriyor
- Medium: 3 MB
- Substack: 4 MB
- Quora: 4,5 MB
- Pinterest: 10 MB
- Patreon: 11 MB
- Statik sayfayla da yapılabilecek gibi görünen içerik gösterme işleri için büyük JavaScript paketlerinin kullanıldığı örnekler var
Arama ve basit etkileşimli uygulamalar
- Arama odaklı uygulamalarda temel iş sorgu girişi ve sonuç listesini göstermek olsa da JavaScript boyutu küçük değil
- StackOverflow: 3,5 MB
- NPM: 4 MB
- Airbnb: 7 MB
- Booking.com: 12 MB
- Google arama, metin alanı ve bağlantı listesi ağırlıklı bir ekran olmasına rağmen 9 MB ölçülmüş
- Basit giriş arayüzüne sahip servisler de birkaç MB JavaScript kullanıyor
- Google Translate: 2,5 MB
- ChatGPT: 7 MB
- ChatGPT'nin karmaşıklığının sunucu tarafında olmasından bağımsız olarak tarayıcıya 7 MB JavaScript geliyor
Medya servisleri ve e-posta
- Video servislerinin JavaScript boyutu şöyle
- Loom: 7 MB
- YouTube: 12 MB
- Pornhub: 1,4 MB
- Ses servislerinde SoundCloud ve Spotify'ın her biri yaklaşık 12 MB ölçülmüş
- E-posta servislerinde fark büyük ölçüde açılıyor
- Google Mail: 20 MB
- FastMail: 2 MB
- FastMail, aynı e-posta servisi kategorisinde Google Mail'den 10 kat daha az JavaScript kullanıyor
- Google Mail'in 20 MB'ı, Figma gibi özel C++/OpenGL render içeren uygulamalarla karşılaştırılacak kadar büyük bir değer
Üretkenlik araçları ve belge düzenleme
- Üretkenlik uygulamalarında da basit işlere kıyasla JavaScript büyük
- Todoist: 9 MB
- Dropbox: 10 MB
- 1Password: 13 MB
- Trello: 13,5 MB
- Discord: 21 MB
- Dropbox klasördeki dosya listesini, 1Password parola listesini, Trello ise kartları göstermek gibi işler için ayrı ayrı 10 MB'ın üzerinde kullanıyor
- Belge düzenleme servisleri çift haneli MB seviyesinde
- Google Docs: 13,5 MB
- Notion: 16 MB
- Belge düzenlemede imleç hareketi ve senkronizasyon gibi zor özellikler var; ancak karşılaştırılan servislerin JavaScript boyutu yine de büyük
Sosyal ağlar ve çok büyük örnekler
- Sosyal ağlar beğeniler, akış, mesajlaşma vb. için genel olarak 12 MB civarında JavaScript kullanıyor
- Twitter: 11 MB
- Facebook: 12 MB
- TikTok: 12,5 MB
- Instagram: 16 MB
- LinkedIn: 31 MB
- LinkedIn blog, platform, arama, mesajlaşma ve sosyal özelliklerin tümünü içeriyor ve 31 MB ölçülmüş
- Çok büyük web uygulaması örnekleri neredeyse ayrı bir kategori
- Jira: neredeyse 50 MB
- Slack: 55 MB
- Slack kullanıcı listeleri, mesajlar ve tepkilerle uğraşan bir sohbet uygulaması olmasına rağmen 55 MB JavaScript indiriyor
- react.dev başlangıçta 2 MB ile başlıyor; ancak tekrar tekrar kaydırıldığında JavaScript'in sürekli arttığı gözlemlenmiş
- Örneğin 100 MB'a kadar artırılabiliyordu
- Güncellemeye göre normal kullanıcı deneyiminde gömülü kod editörü ilk yüklemeden sonra önbelleğe kaydediliyor ve sonrasında ağ trafiği görünmüyor
- Yine de kaydırma sırasında 100 MB JavaScript'in sürekli ayrıştırılması, değerlendirilmesi ve başlatılması mümkün
10 MB kod ne anlama geliyor
- 2015'te ortalama web sayfası boyutu Doom 1 shareware sürümünün 2,5 MB'ına yaklaşmıştı
- 2024'te Slack, yalnızca JavaScript ile orijinal Quake 1'in tüm kaynak boyutu olan 55 MB'a ulaşıyor
- 10 MB kod sıradan bir seviye gibi görünse de, ortalama bir kod satırının 65 karakter olduğu varsayılırsa yaklaşık 150 bin satıra karşılık geliyor
- Bu kod zaten minify edilmiş durumda olduğundan, kaynak hâlinde 300 bin satırdan fazla olabilir
- Google Maps, SPA'nın başlıca örneklerinden biri olarak gösterilse de 4,5 MB ölçülmüş; modern web uygulamaları ölçütüne göre ise aksine küçük sayılabilecek bir örnek olarak karşılaştırılıyor
- Figma karmaşık bir front-end uygulaması olduğu için JavaScript indirme boyutunun büyük olması doğal; ancak Gmail Figma'ya benzer, LinkedIn 1,5 kat, Slack ise 2,5 kat seviyesinde
Tarayıcının ödediği maliyet
- Sorun indirme boyutuyla bitmiyor
- JavaScript, tarayıcının ayrıştırması, bellekte tutması ve çalıştırması gerektiği için sürekli bir maliyet yaratıyor
- İçerik boyutunun kod boyutundan büyük olması gerektiği ölçütüyle bakıldığında, 10K karakterlik bir blog yazısını render etmek için 1000 kat daha büyük JavaScript gerektiren yapı aşırı
- İyi örnek olarak anılan siteler yalnızca 0,1 MB JavaScript ile yeterince çalışıyor
- Aynı web ortamında GitLab, statik bir açılış sayfasını göstermek için 13 MB, yaklaşık 500 bin satırdan fazla JavaScript gerektiren bir örnek olarak karşılaştırılıyor
1 yorum
Hacker News yorumları
10 MB, 12 MB gibi şeyleri performansı gerçekten önemseyen Pornhub 1,4 MB ile karşılaştırmak yeterli.
Porno siteleri, şaka gibi “teknoloji” devlerinin aksine, her zaman gerçek web yüksek teknolojisiydi ve mühendislikleri de iyiydi.
Temel UI/UX’i, içerik iletimini ve sağduyulu tasarımı berbat ettiklerini pek hatırlamıyorum.
Gerçek web uygulamalarında sayfa yenilemenin istenmeyen bir davranış olması nedeniyle, bir anda herkes web sitelerinde sayfa yenilemekten korkar olmuş gibi.
20 yıldır kurumsal uygulamalarla uğraştım, doğmadan önce yapılmış sistemleri bile gördüm; React’in bu tür sistemlerde önceki korkunç istemci/sunucu UI’larının yerini alan en iyi frontend olduğunu düşünüyorum.
Angular/Vue vb. de aynı bağlamda. Ama sıradan web sayfalarında, Gmail ve Facebook gibi etkileşim ve gerçek zamanlı güncellemelerin ürünün merkezinde olduğu durumlar dışında neredeyse hiç gerek yok.
Pornhub gibi yerler için PHP bile yeterli, çoğu web sitesi için de öyle. HN ya da old.reddit.com’u hâlâ tercih eden çok kişinin olması buna örnek; daha yavaş hâle gelen yeni Facebook yerine old.Facebook’u tercih edecek de çok kişi olurdu diye düşünüyorum.
Pop-up’lar, pop-under’lar, sahte içerikle benzer toplayıcı sitelere yönlendirme, içerik yerine ortaklık siteleri açma, arama sonuçlarını kirletme gibi şeyler.
Porno, insanların söylediği kadar teknolojiyi sürükleyen bir sektör değil; Betamax-VHS ile ilgili şehir efsanesi de doğru değil, internet inovasyonuna öncülük ettiği iddiası da abartılı.
Kaliteli ürünler yapan birkaç oyuncu var, ama bu tüm sektörü temsil etmiyor. Link çiftlikleri, boş içerik, klon siteler, yanıltıcı reklamlar ve arama sonucu manipülasyonu çok fazla.
Bugünkü en büyük sitelerin hızlı hissettirmesi rekabetin sonucu gibi görünüyor. UX kötüyse bedava porno zaten bol olduğu için kullanıcı hemen başka yere gider; bu yüzden elde tutma için optimize etmek zorundalar.
Diğer web sitelerinde hissedarlar, içerik sağlayıcılar, münhasır anlaşmalar, tekel konumu gibi başka teşvikler var; bu yüzden kullanıcı deneyimini o kadar optimize etmek zorunda değiller.
Video iletimi, canlı yayın (eskiden Flash, şimdi WebRTC), sayfa boyutu ve akla gelebilecek her şeyi optimize etmeye sayısız saat harcanıyor.
Neden sıkıştırma öncesi veriye baktığımızı merak ediyorum. Kötü örnek olarak verilen bazı siteler bile sıkıştırılınca GMaps’in 1,5 MB’ından kolayca küçük oluyor.
Spotify ya da GMail gibi dinamik uygulamalarda, sayfa yüklendikten sonra gezinme hızlıysa bence sorun yok.
Başlangıçta güncellenmesi birkaç saniye süren Discord, her tıklamada en fazla 2 saniye bekleten GitLab’dan daha iyi.
Günümüzde cold start’a ve statik render’a verilen önceliğin bazı sitelerde deneyimi aksine bozduğunu düşünüyorum.
Deneme olarak GitHub’da dosya ağacında gezinirseniz, benim cihazımda GitHub’ın diğer bölümlerinden çok daha akıcı. Tesadüfen, bu bölüm statik render edilmeyen neredeyse tek bölümlerden biri.
Her gün yüzlerce GitHub sayfasına tıklıyorum; tek bir pipeline’a bakmak için her seferinde tüm footer’ı tekrar almaktansa, bir kez devasa miktarda JavaScript gönderip mümkün olduğunca çok şeyi cache’lemesini tercih ederim.
[1]: GMail ve Spotify sadece örnek; gerçekte kullanmıyorum.
Erişilebilirlik tartışmalarında bu konu sık sık gündeme geliyor; iOS ile Android arasında CPU performansı farkı büyük ve yaygın kullanılan düşük seviye cihazlara kadar bakınca bugün satılan yeni bir Android cihazın 2014 model bir iPhone’dan yavaş olduğu durumlar bile var.
Geliştiriciler sadece en yeni iPhone’u ya da amiral gemisi Android’i kullanıyorsa, kod şişkinliğinin ortalama kullanıcıyı ne kadar etkilediğini gözden kaçırmaları kolay.
https://infrequently.org/2024/01/performance-inequality-gap-...
Cache’leme indirme ve sıkıştırmayı açma için gereken güç ve zaman maliyetini azaltsa da gerçek kullanım maliyetini ortadan kaldırmaz.
Kişisel sezgisel kuralım şu: sıkıştırma öncesi JavaScript ne kadar büyükse, fareyi hareket ettirdiğinizde, tuşa bastığınızda ya da kaydırdığınızda CPU’nun sürekli çalıştırdığı kod da o kadar fazla olur.
Biraz zaman veriminden vazgeçip güç verimi kazanmak daha iyi; CSS ile değiştirilebilecek yerlerde süslü hareketler yerine statik olanı tercih ederim.
Ya da asıl daha büyük sorun, tıklamayla URL’nin başka bir sayfaya gitmesi dışında çeşitli eylemlerde de ekstra dosya indiren siteler olabilir. Bu gizli bir şişkinliktir ve arşivleme için de çok kötüdür.
JavaScript ile adres çubuğundaki URL aynı kalırken farklı bir “sayfa” gösterilmesin isterim. Bu da arşivleme için gerçekten kötü.
Bir başka sezgisel kural da şu: sıkıştırma öncesi JavaScript ne kadar büyükse, arşivlenmiş site sürümünün düzgün çalışma olasılığı o kadar düşer.
Geçen hafta internetim yavaştı; GitHub web sitesinde bir dosyaya tıklayınca script ile yüklemeye çalışıp başarısız oluyordu, dosya ağacı kelimenin tam anlamıyla çalışmıyordu.
Bunun yerine dosya URL’sini kopyalayıp tarayıcının adres çubuğuna yapıştırınca düzgün yükleniyordu.
Spotify’da ağ bağlantısı sorunları büyük. Bir albümü indirmiş olsanız bile ağ değişince tamamen paniğe kapılıyor. Sürekli çevrimiçi kalmaya çalışmasındansa sadece çevrimdışı mod daha iyi.
Buna bakıp tüm mimariyi yargılamak zor; bu, çok kötü bir SPA’yı gösterip tüm SPA’ların kötü olduğunu söylemeye benziyor.
Tüm yazılımlar, onu yapan organizasyonun görünümünü yansıtır
Aktarılan verilerin çoğu, sayfanın çalışması için gerçekten gerekli JavaScript değil; analiz araçları ve çeşitli üçüncü taraf script’leri olabilir
Yalnızca “elephant” kategorisi React gibi tembel yüklenen modüllere karşılık geliyor
Bunların önemli bir kısmı, bu sorunu bilmeyen ya da umursamayan pazarlama ekipleri tarafından yönlendiriliyor
Geliştiriciler çoğu zaman sayfaya Google Tag Manager ya da başka script ekleme servislerini iliştirmiş oluyor. Bazı durumlarda geliştirici bunu bile yapmıyor; operasyon altyapısındaki proxy sayfayı değiştiriyor
Daha anlamlı endişe, pazarlamanın çıktılar üzerinde işi fiilen yapan insanlardan daha fazla kontrole sahip olması olabilir
“elephant” sayfalarında şişkinlik organizasyonun kendisinde. Sorun birkaç aptal değil, ölçeklenmiş aptallar sorunu
Önceki işimde Google Tag Manager teknik olmayan bir departmanın elindeydi ve canlı sayfalara enjekte edilen çöpleri sürekli izlemek zorundaydık
Ondan kurtulmak için gerçekten çok mücadele ettim
Aramadaki Google, Yahoo’ya göre öyleydi; Chrome da çıktığı dönemde IE/Firefox’a göre öyleydi
Chrome’un kendisinde neredeyse hiç UI yoktu ve bu bir özellikti
Kısa süre önce Yeni Zelanda’daki bir road trip’ten döndüm; kırsal bölgelerin büyük bölümünde cep telefonu sinyali neredeyse yok ya da hiç yok
Buna roaming de eklenince bir katman daha yavaşlamış gibi hissettiriyor; web’in büyük kısmını kullanmak gerçekten zorlaştı
Spotify’da PM varsa çevrimdışı UX’i gözden geçirmesini isterim. Çevrimdışı kullanım, Premium’un temel özelliklerinden biri; ama uygulamayı gerçekten çevrimdışı kullanmaya çalışınca birçok açıdan çok kötü
Spotify internet olduğunu düşündüğünde tüm bağlam menüsü içeriğini sunucuya soruyor, birkaç saniye yanıt bekliyor; bazen menüyü göstermeyi bırakıyor, bazen de çevrimdışı modda olsaydı anında gerçekleşecek davranışa geri dönüyor
Bu oynatıcıdan gerçekten nefret ediyorum
Gecikmenin çok yüksek ya da paket kaybının fazla olduğu ara durumlarda aslında çevrimdışı gibi davranması gerekirken Spotify çevrimiçi olduğunu düşünüyor
Yine de bu tür sorunlar çok yaygın; başarısız olan yalnızca Spotify değil ve doğru eşik değerlerini belirlemek zor olsa gerek
Spotify’ın sinyal yokken uygulamanın bir şey yüklemesi için neden 30 saniye beklettiğini anlamıyorum. Sadece indirdiğim podcast’i dinlemeye devam etmek istiyorum
Hangi mühendislik kararı bu senaryoları ağırlıklandırmayı bu kadar karmaşık hale getirdi merak ediyorum
Bu yazı, özellikle gerçek web uygulamalarında JavaScript dosyalarının neden bu kadar büyük olduğunu parçalarına ayırıp incelememesi açısından meseleyi tamamen kaçırıyor
Örneğin Google Translate’e yakından bakarsanız, bir kez etkileşip biten bir uygulama değildir. Sözlük, alternatif öneriler, transliterasyon, telaffuz, birden çok giriş yöntemi vb. var
Bunları hesaba katsak bile 2.5MB çok büyük; bazı isteğe bağlı özellikler tembel yüklenebilir ve yüklenmeli diye düşünüyorum, ama mevcut yazı daha derin bir tartışmaya pek yardımcı olmayacak kadar tembel
if data.transliteration show icon with audio embediçin ne kadar JavaScript gerekir ki?Görseller büyük ve çok sayıda olabilir, anlıyorum; ama biraz ironikti
Buradaki ima “çok fazla JavaScript var” biliyorum, ama bunun ne kadarının saf takip çöpü olduğunu da konuşmak gerek
Daha kötüsü, bazılarının host koduna bağlanmaması ve dışarıdan çekilmesi; bu da gecikmeyi ve olası güvenlik risklerini artırır
Pazarlamacıların geliştirici müdahalesi olmadan web uygulamasına istedikleri çöpü enjekte etmesini sağlayan bir araçtı
İlişkiler de biraz bozuldu, kazanamadım da; performans hâlâ berbat
Sonra performans sorunu yaratan şeyler harita ve grafik gibi ağır kütüphaneler; bunlar genelde akıllı tembel yükleme ile çözülür
Bizzat yaşadığım örneklerde, çok küçük bir özellik için başlangıçta QR kod tarama kütüphanesi ve harita kütüphanesinin yüklenmesi; tüm uluslararasılaştırma dizelerinin başlangıçta waterfall isteklerle alınıp herhangi bir JS çalışmadan önce engel oluşturması; Zendesk’in sayfa performansını tamamen mahvetmesi ama üst yönetim talimatı olduğu için yalnızca tembel yükleme koyabilmemiz vardı
Sonra DOM öğelerini, yeniden render’ları veya waterfall istekleri aşırı tetikleyen kötü tasarlanmış kod geliyor
En son uygulama düzeyindeki kod boyutu geliyor; bu da tembel yüklemeyle düzeltilebilir, ama uygulama çok büyümeden genelde gerekli olmaz
Örneğin GitLab landing page’i, takip script’leri engellenince 13MB’den “yalnızca” 6MB’ye düştü
Pazarlama departmanı yazılım şişkinliğini her zaman ikiye katlayacaktır
Popüler sitelerin soğuk yüklemede ne kadar JavaScript yüklediğini karşılaştıran bir içerik. Başlıca noktalar şöyle:
PornHub, YouTube’dan yaklaşık 10 kat daha az JS yüklüyor (1,4 MB’a karşı 12 MB)
Gmail’in footprint’i anlaşılması zor derecede büyük (20 MB). Fastmail 10 kat daha hafif, 2 MB; Figma ise daha karmaşık bir uygulama olmasına rağmen benzer şekilde 20 MB
Jira’nın 58 MB olması inanılmaz
Jira bir kez indirildikten sonra, güncellenene kadar çevrimdışı bir uygulama gibi yerelden yüklenecektir
Pornhub’ın gizli modda çalıştırılma olasılığı yüksek olduğundan önbellek pek işe yaramaz
Jira da berbat ve yavaş
https://wordsandbuttons.online/ üzerindeki tüm sayfalar, animasyon ve etkileşimler olsa bile hâlâ 64 KB’ın altında
Örneğin şu sayfa https://wordsandbuttons.online/trippy_polynomials_in_arctang... 51 KB
Kod da hiç ekonomik değil. %80’i ufak farklarla kopyala-yapıştır; akıllıca küçültmeye yönelik bir deneme de yok. Tamamı eski usul vanilla JS; sıkıştırma da yok, boşluk temizleme de yok
“View page source” ile açınca kod tamamen okunabilir halde
Sır, sıfır bağımlılık politikası. Ne üçüncü taraf ne de dahili bağımlılık var. Gerekli tüm kod HTML dosyasıyla birlikte alınıyor
Paradoksal biçimde, uzun vadede kopyala-yapıştır şişkinliğin nedeni değil, önlemi
Mobilde kenarlar kelimenin tam anlamıyla görünmüyor
Bağımlılıkların kendisi neden değil, belirti. Web siteleri ve şirketler artık şişkinliği azaltmak için teşvik görmediğinden, mükerrer bağımlılıklar neredeyse hiç temizlenmiyor
2015 tarihli The Website Obesity Crisis yazısını [1] hatırlatıyor. O zamandan beri [2] durum daha da kötüleşti ve şimdiden neredeyse 10 yıl geçti
Bundan 10 yıl sonra, 2015 civarındaki bir PC ile web’de gezinmenin imkânsız hale geleceğini söylemek aptalca mı olur? Hiçbir şey değişmezse öyle görünüyor
2013 model eski bir MacBook’a güncel Firefox kursanız bile https://civitai.com sayfasındaki 23,98 MB JavaScript’in üstesinden gelemiyor ve bu felaket web frontend’ini render etmeye çalışırken yaklaşık 30 saniye donuyor
Bu yalnızca web’in sorunu değil. Mobil hepsi-bir-arada uygulamalar da o kadar büyüdü ki 2013’ten kalma telefonlarda aynı şekilde yüklenemiyor; bunların yarısı da web teknoloji yığını üzerine yazılmış durumda
Bütçesi büyük şirketlerin neden native uygulama yazmaya gücünün yetmediğini anlamıyorum
[1] https://idlewords.com/talks/website_obesity.htm
[2] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Web’in hali çok üzücü
Fiber bağlantı kullanan çoğu insan web’in ne kadar yavaşladığını bile fark etmiyor
Ama hâlâ 2 Mbps bağlantı üzerindeyseniz gerçekten korkunç. Ben böyle bir durumdayım ve acı verici
Bu yüzden reklam/izleme engelleyici kullanmamak benim için hiç düşünülemez
Bu testi Ublock Origin açıkken görmek isterdim
Bu kodların çoğu kullanıcı takibi ve reklam yönetimi için gibi geliyor
Daha iyi ve hızlı bilgisayarlarımız ve ağ hızlarımız varken, uygulamaları ve web sitelerini sürekli daha küçük yapmaya odaklanmamız gerektiğini düşünmeyi anlamıyorum
Moore yasası sayesinde geliştiriciler optimal olmaktan ödün verip daha fazlasını zorlayarak hızlı hareket edebildi; bunun çok örneği var