Tam da ihtiyacım olduğu için yapmaya başladığım bir şeydi, bunu yapmışlar... Claude Code Max kullanıyorum; aynı anda birden fazla proje geliştirirken gerçekten ihtiyaç duyduğum bir yazılımdı.
Disk alanı israfı sorunu konusunda epey empati kurmamak elde değil...
AKS işletiyorum; konteyner imaj boyutu 1GB'ı aşan Python uygulamalarını her gördüğümde başım ağrıyor.
Şu anda Dockerfile'ı alıp boyutunu tekrar ben küçültüp yüklüyorum; 500MB'nin altına indiremezsem de artık vazgeçiyorum haha
Vay be...! İlk kullandığımda, Python olduğu için seçtiğim bir projeydi...
Aradan uzun zaman geçmiş!
Tekrar kullanabileceğim bir ortamda çalışabilsem ne güzel olurdu :) hahaha
Acaba yan iş olarak bir şeyler mi denesem...
Aşırı iyi fiyatlı, aşırı iyi bir makine bir tane olsa yeter gibi? Aşırı iyi bir hukuk bürosuysa satın alır kullanır herhalde. Ama hani fabrika makinesini 24 saat çalıştırır gibi, lol
Asıl yazının amacı yalnızca karmaşıklaşan JS framework’lerini eleştirmek değil.
Kolaylık olması açısından yukarıdaki Korece çeviri bağlantısından alıntı yapacağım.
Artık yalnızca bir başlığı değiştirmek için bile 4 mühendis, 3 framework ve bir CI/CD pipeline’ı gerekiyor. Bir web sayfası yayımlamak tuhaf derecede karmaşık hale geldi.
Böylece web, yavaş yavaş, kullanıcılar ihtiyaç duyduğu için değil, geliştiriciler kendilerini modern hissetmek istediği için yayımlanmadan önce derlenmesi gereken bir şeye dönüştü.
Her şey geliştiriciler için optimize edildi ve diğer herkes için düşmanca hale geldi.
Artık karmaşıklığa yalnızca katlanmıyoruz; onu doğal kabul ediyoruz. Her sitenin bir build aşamasına, bundler’a, hydration stratejisine, routing katmanına, API katmanına, tasarım sistemine ve akıllı cache invalidation mantığına ihtiyaç duyduğunu varsayıyoruz. Mikroservislerle inşa ediyor, edge ağlarında barındırıyor ve basit içerik sunmak için pipeline’lar devreye alıyoruz.
WordPress gibi platformların işlevlerini yeniden yaratıyoruz, ama ortaya 10 kat daha ağır ve kullanılabilirliği çok daha kötü sonuçlar çıkıyor. Daha kötüsü, her yeni katman yeni bug’lar, yeni uyumluluk sorunları ve yeni bilişsel yük getiriyor. Artık yalnızca bir ana sayfayı yayına almak için hydration mantığını, cache stratejilerini ve build pipeline’ını bakımda tutuyoruz.
Bileşen kütüphanesi yeterince esnek olmadığı için pazarlama kampanyaları gecikiyor. Analitik katmanı hydration stratejisiyle uyumlu olmadığı için A/B testleri iptal ediliyor. İçerik güncellemeleri için günlerce build bekleniyor. Temel SEO düzenlemeleri backlog’da kaybolup gidiyor.
Pazarlamacılar ticket açmadan metni güncelleyemiyor ya da deney yürütemiyor. İçeriği önizleyemiyor, yerleşimi test edemiyor veya sayfa dışa aktaramıyorlar. Her değişiklik geliştiricilerden, pipeline’lardan, onaylardan ve yeniden build sürecinden geçmek zorunda.
Pazarlamacılar, içerik editörleri, SEO uzmanları ve tasarımcılar; hepsi süreçten dışlanıyor. Çünkü artık basit işler bile teknik akıcılık gerektiriyor. Başlık etiketini değiştirmek istiyorsanız size bir mühendisle görüşmeniz söyleniyor; bir kampanyayı yayına almak istiyorsanız ticket açıp iki sprint beklemeniz isteniyor.
Her şey geliştirme ekibinin içinden geçiyor. Bu da neyin önemli olduğuna, neyin yayımlandığına ve neyin süresiz olarak geri plana itildiğine geliştirme ekibinin karar verdiği anlamına geliyor. Ve onlar ne kadar fazla karmaşıklık eklerse, o kadar vazgeçilmez hale geliyorlar.
Yazının işaret ettiği "webin aşırı karmaşıklığı" sorununa katılıyorum. Ancak bunun nedenini yalnızca geliştirici kültürüne ya da framework’lerin kötüye kullanımına bağlayan teşhise katılmak zor. Günümüz webinin karmaşıklığı, büyük ölçüde "iş modelinin" zorunlu kıldığı işlevlerin ve güvenliğin gölgesinden kaynaklanıyor. Bu noktayı dışarıda bırakırsak, değerlendirme kaçınılmaz olarak eksik kalır.
Web artık bir "ücretsiz sergi salonu" değil. Bugün kamu siteleri dışındaki çoğu web hizmetinin amacı gelir elde etmektir. Bu yüzden teknoloji seçimindeki temel soru "Bu kod ne kadar saf?" değil, "Bu teknoloji işimizi başarıya ulaştırıyor mu?" olmalıdır.
Bu açıdan bakıldığında, yazının idealize ettiği "hafif içerik webi" gerçek dünyanın iş gereksinimleri duvarına çarpar. Örneğin içerik satan bir iş modeli, yalnızca basit statik sayfalarla yürütülemez. Ücretli abonelik ve ödemeleri işlemek için kullanıcı kimlik doğrulaması, abonelik durumunun kontrolü ve yetki yönetimi gibi durum tabanlı mantık gerekir; içeriği korumak için de korsan kopyalama veya yetkisiz erişimi engelleyen gerçek zamanlı token doğrulaması gibi güvenlik katmanları zorunludur. Dahası, kişiselleştirme ve A/B testleriyle kullanıcı deneyimini ve dönüşüm oranını artırmak istiyorsanız dinamik veri işleme de gerekir.
Bunların tamamı "gelişmiş uygulama" alanına girer ve framework’ler bunu hayata geçirmek için kullanılan gerçekçi araçlardır.
Elbette her karmaşıklık meşrulaştırılamaz. Karmaşıklığı ikiye ayırmalıyız.
Kaçınılmaz karmaşıklık: İşlevsel gereksinimleri (kimlik doğrulama, ödeme, kişiselleştirme vb.) yerine getirmek için ortaya çıkan, ROI’si net olan karmaşıklıktır. Katlanılması gereken bir maliyettir.
Tesadüfi karmaşıklık: Geliştirme kolaylığı ya da aşırı teknik soyutlama nedeniyle ortaya çıkan gereksiz karmaşıklıktır. Sürekli ölçülmesi ve ortadan kaldırılması gereken teknik borç ve israftır.
Başarılı hizmetler, bu ikisini ayırt ederek gerçekçi bir mimari kurar. Yani pazarlama ve SEO’nun kritik olduğu ön yüzü mümkün olduğunca hafif tutarken, temel işlem veya kişiselleştirme işlevlerinin gerekli olduğu iç alanlarda framework tabanlı yapılarla istikrar sağlar; böylece hız ve işlevselliği birlikte yakalayan hibrit bir strateji izler.
Yazı, kullanıcı deneyiminin kötüleşme nedenini yalnızca framework kültürüne odaklayıp "gelir modelinin doğurduğu kaçınılmaz gereksinimleri" dışarıda bırakmış. Bu noktayı hariç tutarak web geliştirmeyi tartışmak, müşterinin masasına "hızlı ve lezzetli yemek" koymaktan söz ederken o yemeğin hazırlandığı karmaşık mutfağı ve paranın tahsil edildiği kasayı yok saymaktan farksızdır.
Web ağırlaştı diye framework’leri düşünmeden bir kenara atamayız. Asıl tartışılması gereken, işletmenin ihtiyaç duyduğu işlevleri ne kadar verimli ve en düşük maliyetle hayata geçirip kullanıcıya değer sunduğumuz olmalıdır diye düşünüyorum.
Streaming özelliği sunulması gereken chatbot benzeri servislerde, eşzamanlı işleme sırasında Prefill işi decode’u da etkilediği için VRAM geniş olsa bile kullanıcı açısından performans çok düşmüş gibi görünüyor.
Chunked prefill ile ilgili seçenekleri ve vLLM’nin deneysel olarak sunduğu Disaggregated Prefilling özelliğini de denedim, ancak hâlâ yeni bir istek geldiğinde mevcutta üretilmekte olan yanıtların takıla takıla kesilmesi sorunu var; bu yüzden acemi bir geliştirici olarak GPU ve node sayısını artırmanın dışında en verimli yöntemin ne olduğunu merak ediyorum.
Tam da ihtiyacım olduğu için yapmaya başladığım bir şeydi, bunu yapmışlar... Claude Code Max kullanıyorum; aynı anda birden fazla proje geliştirirken gerçekten ihtiyaç duyduğum bir yazılımdı.
Django'nun doğum günü kutlu olsun!
Türkçe çeviri aşağıdadır.
https://roy-jung.github.io/250701-history-of-js/
Büyük ölçüde iyileştiğini, üstün olduğunu ve doğru olduğunu sayılarla göstermeleri iyi olurdu.
Kore nasıl farklı olacak acaba?
Disk alanı israfı sorunukonusunda epey empati kurmamak elde değil...AKS işletiyorum; konteyner imaj boyutu 1GB'ı aşan Python uygulamalarını her gördüğümde başım ağrıyor.
Şu anda Dockerfile'ı alıp boyutunu tekrar ben küçültüp yüklüyorum; 500MB'nin altına indiremezsem de artık vazgeçiyorum haha
Vay be...! İlk kullandığımda, Python olduğu için seçtiğim bir projeydi...
Aradan uzun zaman geçmiş!
Tekrar kullanabileceğim bir ortamda çalışabilsem ne güzel olurdu :) hahaha
Acaba yan iş olarak bir şeyler mi denesem...
Claude 4 çıkmışken bunu Claude 3 ile karşılaştırmak neredeyse dolandırıcılık değil mi...
Kore saatiyle yaklaşık 07:00’den itibaren yaklaşık 50 dakika kadar kesinti yaşandı; şimdi ise düzgün çalışıyor.
CMD> nslookup news.hada.io 1.1.1.1
Ben de DNS sunucusuna erişilemediğine dair Android push bildirimi almaya devam ettim.
Kısa süreliğine Google DNS'e geçtim.
https://developers.google.com/speed/public-dns/…
vay...
Evet, amacın ne olduğunu ve neden yapılması gerektiğini ne kadar derinlemesine incelersek, o kadar net çözümler ortaya çıkıyor gibi görünüyor.
Yazıyı beğenmeniz beni sevindirdi, teşekkür ederim!
Güzel sözleriniz için teşekkür ederim!
Aşırı iyi fiyatlı, aşırı iyi bir makine bir tane olsa yeter gibi? Aşırı iyi bir hukuk bürosuysa satın alır kullanır herhalde. Ama hani fabrika makinesini 24 saat çalıştırır gibi, lol
Porsche fiyatını düşünüp bakım masrafı, yakıt gideri, sigorta vb. şeyleri hiç hesaba katmayan biri
Asıl yazının amacı yalnızca karmaşıklaşan JS framework’lerini eleştirmek değil.
Kolaylık olması açısından yukarıdaki Korece çeviri bağlantısından alıntı yapacağım.
Sanırım Kore şirketleri için geçerli olmaz.
Yazının işaret ettiği "webin aşırı karmaşıklığı" sorununa katılıyorum. Ancak bunun nedenini yalnızca geliştirici kültürüne ya da framework’lerin kötüye kullanımına bağlayan teşhise katılmak zor. Günümüz webinin karmaşıklığı, büyük ölçüde "iş modelinin" zorunlu kıldığı işlevlerin ve güvenliğin gölgesinden kaynaklanıyor. Bu noktayı dışarıda bırakırsak, değerlendirme kaçınılmaz olarak eksik kalır.
Web artık bir "ücretsiz sergi salonu" değil. Bugün kamu siteleri dışındaki çoğu web hizmetinin amacı gelir elde etmektir. Bu yüzden teknoloji seçimindeki temel soru "Bu kod ne kadar saf?" değil, "Bu teknoloji işimizi başarıya ulaştırıyor mu?" olmalıdır.
Bu açıdan bakıldığında, yazının idealize ettiği "hafif içerik webi" gerçek dünyanın iş gereksinimleri duvarına çarpar. Örneğin içerik satan bir iş modeli, yalnızca basit statik sayfalarla yürütülemez. Ücretli abonelik ve ödemeleri işlemek için kullanıcı kimlik doğrulaması, abonelik durumunun kontrolü ve yetki yönetimi gibi durum tabanlı mantık gerekir; içeriği korumak için de korsan kopyalama veya yetkisiz erişimi engelleyen gerçek zamanlı token doğrulaması gibi güvenlik katmanları zorunludur. Dahası, kişiselleştirme ve A/B testleriyle kullanıcı deneyimini ve dönüşüm oranını artırmak istiyorsanız dinamik veri işleme de gerekir.
Bunların tamamı "gelişmiş uygulama" alanına girer ve framework’ler bunu hayata geçirmek için kullanılan gerçekçi araçlardır.
Elbette her karmaşıklık meşrulaştırılamaz. Karmaşıklığı ikiye ayırmalıyız.
Kaçınılmaz karmaşıklık: İşlevsel gereksinimleri (kimlik doğrulama, ödeme, kişiselleştirme vb.) yerine getirmek için ortaya çıkan, ROI’si net olan karmaşıklıktır. Katlanılması gereken bir maliyettir.
Tesadüfi karmaşıklık: Geliştirme kolaylığı ya da aşırı teknik soyutlama nedeniyle ortaya çıkan gereksiz karmaşıklıktır. Sürekli ölçülmesi ve ortadan kaldırılması gereken teknik borç ve israftır.
Başarılı hizmetler, bu ikisini ayırt ederek gerçekçi bir mimari kurar. Yani pazarlama ve SEO’nun kritik olduğu ön yüzü mümkün olduğunca hafif tutarken, temel işlem veya kişiselleştirme işlevlerinin gerekli olduğu iç alanlarda framework tabanlı yapılarla istikrar sağlar; böylece hız ve işlevselliği birlikte yakalayan hibrit bir strateji izler.
Yazı, kullanıcı deneyiminin kötüleşme nedenini yalnızca framework kültürüne odaklayıp "gelir modelinin doğurduğu kaçınılmaz gereksinimleri" dışarıda bırakmış. Bu noktayı hariç tutarak web geliştirmeyi tartışmak, müşterinin masasına "hızlı ve lezzetli yemek" koymaktan söz ederken o yemeğin hazırlandığı karmaşık mutfağı ve paranın tahsil edildiği kasayı yok saymaktan farksızdır.
Web ağırlaştı diye framework’leri düşünmeden bir kenara atamayız. Asıl tartışılması gereken, işletmenin ihtiyaç duyduğu işlevleri ne kadar verimli ve en düşük maliyetle hayata geçirip kullanıcıya değer sunduğumuz olmalıdır diye düşünüyorum.
Streaming özelliği sunulması gereken chatbot benzeri servislerde, eşzamanlı işleme sırasında Prefill işi decode’u da etkilediği için VRAM geniş olsa bile kullanıcı açısından performans çok düşmüş gibi görünüyor.
Chunked prefill ile ilgili seçenekleri ve vLLM’nin deneysel olarak sunduğu Disaggregated Prefilling özelliğini de denedim, ancak hâlâ yeni bir istek geldiğinde mevcutta üretilmekte olan yanıtların takıla takıla kesilmesi sorunu var; bu yüzden acemi bir geliştirici olarak GPU ve node sayısını artırmanın dışında en verimli yöntemin ne olduğunu merak ediyorum.