Bağımlılık yönetimi yorgunluğu: React'i bırakıp neden Go+HTMX+Templ seçtim

• Bu yıl Go, HTMX ve Templ kullanarak kişisel projeler geliştirdikten sonra React kullanmayı bırakmaya karar verdim
  • HTMX’in resmi web sitesinde React’i bırakıp HTMX’i seçmeye dair birçok ikna edici argüman bulunabiliyor, ancak bağımlılık yönetimi yorgunluğundan bahseden pek fazla kişi olmadığını düşünüyorum
• "Bağımlılık yönetimi yorgunluğu" nedir?
  • React ile yaptığım son kişisel projede (etkileşimli Katalanca sözlük), zamanımın büyük kısmını React paketlerinin bağımlılık güncellemelerine harcadığımı fark ettim
  • Paketleri en son sürümlere güncellediğimde API’de büyük değişiklikler ortaya çıktı ve kodu yeniden düzenlemek için zaman harcamam gerekti
  • Web uygulamasını bir EC2 instance’ında herkese açık bir servis olarak dağıttığım için bağımlılık güncellemelerini sürdürmek istedim
• Yeni büyük sürümler gerçekten gerekli mi?
  • wouter (bir React router paketi) ve TanStackQuery (backend’den veri çekmek, önbelleğe almak ve durumu yönetmek için kullanılıyor) gibi paketler, büyük sürüm güncellemeleri nedeniyle web uygulamasını kritik biçimde bozdu
  • İlk büyük sürüm güncellemesi uygulamayı bozduğunda hiç sorgulamadan kodu yeniden düzenledim, ancak aynı şey ikinci kez olunca sorgulamaya başladım
  • Güvenlik yamaları dışında, web uygulamasının büyük sürüm yayınlarından gerçekte ne gibi bir fayda sağladığını sorguladım
  • Ana bileşenlerin API’lerini beş kez kırmanın gerekli olup olmadığını sorguladım
  • Yeni özellikler ya da başka ürünler çıkarabileceğim ne kadar zamanı kaybettiğimi düşündüm
• Zaman yetersizliği sorunu
  • Kişisel kodlama projelerine ayıracak çok zamanım olmadığı için, bağımlılıkların büyük sürüm güncellemelerinden sonra kodu yeniden düzenleyerek zaman kaybetmek istemiyorum
  • Müşteriler için ürün geliştiriyor ve ileride bakım işleri için ücretlendirme yapmayı planlıyorsanız, çok sayıda kararsız bağımlılık kullanmanız sorun olmayabilir
  • Ancak minimum bakım gerektiren bir ürün yapmak istiyorsanız, JS ekosisteminden uzak dururdum
• Go+HTMX+Templ kullanmak
  • Kişisel projelerde Go+HTMX+Templ kullanmamın başlıca nedeni, Go projelerinin genel bağımlılık/güvenlik güncellemelerini göz ardı etmeden özellik yayınlamaya odaklanmayı mümkün kılması
  • Go dilinin kendisi de kararlı bir standart kütüphane ve dil belirtimini koruyor

[bbulbum]

HTMX hakkında epey olumlu yorum var gibi görünüyor.
SSR tabanlı uygulamalar için bir tamamlayıcı olarak birçok kişinin HTMX aradığını düşünüyorum.
Bunu ben de yan tarafta bir kez denemeliyim gibi duruyor.

[savvykang]

TanStack kütüphanelerini, gerekenden fazla karmaşık oldukları ve son birkaç yılda dokümantasyon kalitesi düştüğü için tercih etmedim. Ayrıca npm paketlerinin yenilenme döngüsü de fazla kısa; bu yüzden her zaman en güncel sürümü kullanmakta ısrar etmek gerçekten gerekli mi diye düşünüyorum.

Yine de şirket işlerinde React'tan vazgeçmek mümkün olmayacak gibi görünüyor. Kişisel projelerde ise ne kullandığınız çok fark etmez.

[dohyun682]

Sadece major sürüm güncellemeleri yapmazsanız bağımlılık sorunları çok büyük olmuyor, değil mi...?

[aer0700]

Geçenlerde şirket içinde çalışan planlanmış işler arasında Python 2 ile çalışan bir tanesine rastladım ve gerçekten nefesim kesildi.
Bir süre düşündükten sonra, şimdilik sorunsuz çalıştığı için olduğu gibi bırakmaya karar verdik. Elbette güncellemeden sonsuza kadar idare edemeyiz.

[aer0700]

Bağımlılık yönetiminin yorgunluğu vs tekerleği yeniden icat etmenin bıkkınlığı
Eski bir tartışma. Gereksiz tekerlekleri kullanmamak doğru ama bugün gerekmiyorsa yarın da gerekmeyecek mi...
Hiç Go kullanmadım ama son zamanlarda Go ile yapılmış çok fazla sunucu görüyorum. Hemen kullanmayacak olsam da en azından bir kez elden geçirmek istiyorum.

[clickin]

HTMX popüler teknolojilerin öncülerinden biri olduğu için sanırım deneyen çok kişi var; ama acaba bunun yerine go + vecty + gox gibi bir yön daha mı iyi olur diye düşünüyorum.

[GN⁺]

Hacker News görüşü

• React gibi kütüphaneleri bırakıp Actix, Tera ve HTMX ile web uygulaması geliştirme deneyimini paylaşıyor. Bu yığının bakım kolaylığının yüksek olduğu ve kullanıcılar tarafından beğenildiği belirtiliyor

  • Yeni bir web uygulamasını hızlıca geliştirip test kullanıcılarına dağıtma deneyimini anlatıyor
  • "bağımlılık yönetimi yorgunluğu" olmadığı için araçları daha derinlemesine anlayabildiğini söylüyor

• Tanner'ın kütüphanelerinin çok özellikli olduğunu ancak API tasarımının zayıf olduğunu değerlendiriyor

  • React Table ve React Query güçlü olsa da sınırların yanlış çizildiğini ve bunun sorun çıkardığını söylüyor
  • React'in avantajının bir framework olmaması ve iyi tasarlanmış sınırlarda durması olduğunu belirtiyor
  • Yalnızca bu ölçütleri karşılayan kütüphaneleri benimsemeye çalıştığını ifade ediyor

• HTMX örneklerinin karmaşıklığı başka yerlere taşıdığını düşündüğünü, JSX'in ise şablonlardan kaçınmanın zarif bir yolu olduğunu söylüyor

  • Routing, state management ve authentication gibi hâlâ çözülmesi gereken birçok sorun olduğunu belirtiyor

• React'i bıraktığını söylemenin tuhaf geldiğini, sorunun React'te değil başka bağımlılıklarda olduğunu savunuyor

  • Backend'i Go ile yazma seçeneğinin zaten her zaman mevcut olduğunu söylüyor

• Bir paketin bir sonraki büyük sürümüne güncellerken değişiklik beklenmesi gerektiğini unutmamayı vurguluyor

  • Remix örneği üzerinden değişikliklerin kademeli olarak nasıl uygulanabileceğini anlatıyor
  • İyi paketlerin ciddi emek gerektirdiğini savunuyor

• Django ve HTMX ile bir SPA projesini migrate etme deneyimini paylaşarak JavaScript bağımlılıklarını büyük ölçüde azalttığını anlatıyor

  • SPA'nin adeta bir saatli bomba gibi hissettirdiğini söylüyor

• React'in kötü sürdürülen üçüncü taraf paketlerden sorumlu olmadığını savunuyor

  • Router veya Redux gibi state management araçlarının gerekli olmadığını açıklıyor

• react-query v5'in v3 API ile uyumlu olması gerektiğini düşündüğünü, ancak migration'ın kolay olduğunu ve zorunlu olmadığını söylüyor

  • "bağımlılık yönetimi yorgunluğu"nun abartıldığını düşündüğünü ve makul sayıda bağımlılık tutulmasını tavsiye ediyor

• Web uygulamasının ek bir fayda elde etmemesine rağmen neden yükseltme yapıldığını sorguluyor

  • En son sürüme yükseltmenin bir avantaj sağlamadığını belirtiyor

• React ve nextjs'i bırakıp başka bir stack'e geçtikten sonra stresinin azaldığını ve güncellemelerin artık depresyon tetiklemediğini anlatıyor