React’ı gerçekten seven biri var mı?

 (jsx.lol)
1 puan yazan GN⁺ 2 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • React ve React ekosistemindeki araçlara dair eleştirel yazıları derleyip kürate eden bir kaynak koleksiyonu; farklı geliştirici ve blog yazarlarının yazıları alıntı biçiminde düzenlenmiş
  • React’ın sahip olduğu performans düşüşü, artan karmaşıklık ve hydration sorunları gibi yapısal sınırlara işaret eden çok sayıda yazı içeriyor
  • React merkezli teknoloji seçimi, teknik uygunluktan çok atalete ve ağ etkisine dayanarak kemikleşmiş durumda; “herkes React biliyor” varsayımının mimari kararlardan önce geldiği eleştiriliyor
  • React Server Components ve Next.js etrafındaki güvenlik ve yönetişim kaygıları büyüdü; CVE-2025-55182, CVSS 10.0 seviyesinde kimlik doğrulama gerektirmeyen uzaktan kod çalıştırma açığı olarak duyuruldu
  • React ekosistemindeki API tasarımı karmaşası, kalite krizi ve karmaşıklık; uzun vadeli bakım ile öğrenmeyi zorlaştırıyor ve Hooks, modern UI özellikleri, sürüm akışı gibi konularda React’ın yönü üzerine tartışmalara yol açıyor

Siteye genel bakış

  • "Does anybody actually like React?" gibi kışkırtıcı bir soruyla öne çıkan bir kürasyon sitesi
  • React ve React’tan etkilenmiş araçlara yönelik eleştirel yazıları toplayan cherry-picked koleksiyon
  • RSS abonelik özelliği sunuyor

React’ın kendisine yönelik temel eleştiriler

Güvenlik ve yönetişim sorunları

API tasarımı ve öğrenme eğrisi sorunları

  • Is it Time to Regulate React?

    • React’ın temel başarısızlığı, kafa karıştırıcı API tasarımı yüzünden daha da ağırlaşıyor
    • Dokümantasyon kararsız; doğru kullanım biçimi üzerine tartışmalar hiç bitmiyor

  • I don't have time to learn React

    • React’ın modern UI öğrettiği iddiasının aksine, gerçekte modern UI’yi neredeyse hiç ele alamıyor
    • autofocus bozuk, custom elements ise deneysel sürümler dışında çalışmıyor
    • dialog, popover gibi modern özellikleri kullanmak için useEffect gerekiyor
    • synthetic event sistemi yüzünden gerçek DOM davranışını neredeyse hiç öğrenemiyorsunuz
    • Bu modern UI değil, 2013 seviyesinde bir UI

  • The React Blog Post: Reflections and Reactions

    • Her sorunu “skill issue” diye geçiştirip dış kütüphanelerle çözülebileceğini söyleyen yaklaşım tuhaf bulunuyor
    • Üç yıl sonra geri dönüldüğünde de üzerinde çalışılabilen bir teknoloji olması gerekirken, frontend özellikle de React böyle değil

  • React, where are you going?

    • Günümüzde React’ı daha az keyifli kılan iki sorun: ownership ve complexity
    • Yeni geliştiricilerin React karşısında gözlerinin korkabileceği endişesi var

Performans ve kullanıcı deneyimi sorunları

  • Why use React?

    • Temelde kötü şöhretli hydration kalıbına mahkûm kalınıyor
    • Sunucuda JS ile tüm hesaplamaları yapıp HTML’i hemen gönderen, ardından aynı JS’yi istemciye tekrar gönderen bir yapı

  • How React 19 (Almost) Made the Internet Slower

    • Kamuya açık tepki ve sert tartışmaların ardından React ekibi değişikliği askıya aldı

  • An even faster Microsoft Edge

    • React’tan modern Web Components + HTML-first mimariye geçildi
    • Özellikle düşük donanımlı cihaz kullananlar için büyük fayda sağladı

  • Switching costs

    • İstemci tarafı React’ın dayattığı berbat kullanıcı deneyimi hakkında daha fazla şikâyet olması dileniyor
    • Ama fiiliyatta şikâyetler neredeyse tamamen geliştirici deneyimine odaklanıyor

  • Pivoting From React to Native DOM APIs: A Real World Example

    • Bir geliştirme ekibi React’ın “ezici VDOM” yaklaşımından modern DOM API’lerine geçti
    • Hız ve etkileşim iyileşmesini anında hissetti

Mobil ve platform sorunları

Ekosistem ve topluluk sorunları

React Server Components eleştirileri

  • React Server Components: the Good, the Bad, and the Ugly

    • React, istemci tarafı iyileştirmelerini neredeyse tamamen bırakmıştı (2019’da deneysel çalışmalar durduktan sonra)
    • Facebook ölçeğindeki sorunları Facebook ölçeğindeki kaynaklarla çözmek için yapılmış bir legacy framework; kullanım senaryolarının çoğu için uygun değil

  • React Server Components are a bad choice (for shipping)

    • Hızlıca yayına çıkmak istiyorsanız React Server Components kullanmamalısınız
    • Öğrenme, deney ve içerik üretimi amacıyla ise kullanılabilir

Temellere dönüş ve alternatif vurgusu

Geçiş ve dönüşüm örnekleri

Genel eğilim ve geleceğe bakış

Hooks ve alternatif paradigmalar

  • Why Signals Are Better Than React Hooks

    • React Hooks’larını doğru kullanmak zor, yüksek performansla kullanmak ise daha da zor
    • Birçok uygulamada kod kalitesi ve performans düşüşünün nedeni

Mecazi eleştiriler

  • What Is React.js?

    • Destekçilerinin tuhaflığı, aşırı öz-ciddiyeti ve bitmek bilmeyen dokümantasyonu Hristiyanlığa benzeten bir video

İlgili okumalar

1 yorum

 
GN⁺ 2 시간 전
Hacker News görüşleri

  • React’ta sevmediğim bazı şeyler var. React, ekrana etkileşimli HTML çizen bir framework; aşırı karmaşık programlama yapmak için var olan bir şey değil
    Birincisi, fazla karmaşık kavramlara ve terminolojiye dayanıyor. Vue ile karşılaştırınca useEffect, watch; useMemo ise computed karşılığı
    İkincisi, bu gereksiz yere “akıllı” yaklaşım terminolojinin ötesine geçip ekosisteme de işlemiş durumda. Eskiden Redux’ta tek bir sayıyı artırmak için bile birden çok dosyada bir sürü kod yazmak gerekiyordu ve bunun sebebi de yazarının havalı bilgisayar bilimi kavramlarını sevmesi gibi görünüyordu. Aynı dönemde VueX’te o sayıyı sadece artırmanız yeterliydi. Neyse ki bugünlerde React ekosisteminde aklı başında birçok state manager var
    Üçüncüsü, React CSS ile çalışmak için araçları kutudan çıktığı gibi sunmuyor
    Dördüncüsü, React optimizasyonu sizin yerinize yapmıyor. useEffect ve useMemo’yu ne zaman, nasıl kullanmanız ya da kullanmamanız gerektiğini bilmeniz gerekiyor; ayrıca React optimizasyonu hakkında kulaktan dolma bir sürü bilgi var. Yeniden render etme en temel amaçlardan biri olmasına rağmen durum böyle. Vue’da ise framework kendi araçlarını kullanmaya yönlendiriyor ve optimizasyonun çoğunu bunların içinde hallediyor; bu yüzden hiç “Vue uygulamasını manuel optimize etmem lazım” diye düşünmedim
    Beşincisi, o kulaktan dolma bilgi birikiminin kendisi sorun. React API’si ve “doğru React yazma biçimi” o kadar çok kez ve o kadar büyük ölçüde değişti ki, bugün bile hangi bilginin hâlâ geçerli olup hangisinin olmadığını ayırt etmek çok zor
    Sonuç olarak React’ın fikirlere, bilgisayar bilimine ve yüksek seviyeli soyutlamalara fazla odaklanıp, gerçekten ekrana etkileşimli HTML’i kolayca çizmeye daha az odaklandığını söyleyebilirim
    React, Vue ve Svelte’i yoğun biçimde kullandım ama React kullanırken, Vue ya da Svelte’in zaten halletmiş olacağı şeyleri sürekli düşünmek zorunda kalıyorum. Performans açısından üçü de benzer
    Bununla ilgili daha önce de şunu yazmıştım: https://www.brachkow.com/notes/what-i-like-in-vue/

  • Son yaklaşık 16 yılda JavaScript’in ana akımındaki hemen her şeyi görmüş biri olarak, bir bakıma React’ı seviyorum
    React, denediğimiz diğer her şeyi dışarıda bırakırsak en kötü JavaScript framework’ü
    Angular 1 dönemindense her zaman React’ı seçerim. Backbone gibi her şeyi her seferinde sıfırdan birleştirmek yerine Angular 1’in ağır MVC’sini tercih ederdim; klasik JQuery çorbası yapısından ise Backbone’un asgari MVC yapısı daha iyiydi. O dönemin native API’leri yerine de JQuery’nin DOM manipülasyonunu ve standart kütüphane eklemelerini hemen seçerdim
    React’ın da trade-off’ları var ama çalışmayan sayısız alternatifi uzun süre deneyimledikten sonra buraya geldik

    • React kullanmaktan keyif alıyorum ve daha önce çıkanlara kıyasla React’ı tercih ederim. Ama ihtiyaç duyulan şey buysa, htmx/data-star ve server-side rendering yerine React’ı seçmem; birkaç biraz daha karmaşık sayfa için de aynı şey geçerli
    • Ama neden Vue yerine React seçildiğini anlamıyorum. En büyük hayal kırıklığım, Vue’nun sonunda React yönüne doğru hareket etmesi oldu. Vue’nun orijinal bileşen yapısı, yani HTML template, JavaScript state ve CSS style’ın birlikte yer alması gerçekten çok iyiydi. Bileşen içinde URL ile veri çekme yaklaşımı da son derece sezgiseldi
    • Katılıyorum. Elle yazılmış cgi-bin HTML’den JQuery’ye, Angular v1’e ve sonra React’a geçtim; React, memnuniyetle elime alacağım bir araç. Yapmak istediğim işi yapıyor
    • Angular’dan iyisi React, React’tan iyisi Vue
    • Svelte kullandın mı merak ediyorum. Birinin neden React’ı daha çok sevebileceğini pek anlayamıyorum. Bana göre React’ın tek avantajı, frontend’in IBM’i gibi olması. Kimse React’ı seçti diye işten çıkarılmaz

  • Elbette React’ı seven insanlar var. JavaScript gibi fiilen mecburen kullanılan bir şey de değil; kimse React’ı ya da başka bir web framework’ünü zorla kullandırmıyor ama React kazandı. Bu da en azından onu çoğu diğer framework’ten yeterince fazla kişinin sevdiğinin bir kanıtı sayılabilir
    2010’ların sonlarına kadar web geliştirme hakkındaki yaygın şikâyet, her şeyin fazla hızlı değişmesi ve sürekli yeni şeyler öğrenmek zorunda kalmaktı; bu şikâyet de haklıydı. Ama React tek kültürü zirveye çıkınca bu kez de herkes bundan hoşlanmadığını söylüyor. Gerçekten kimseye yaranmak mümkün değil

    • İş hayatında framework ve kütüphane seçebildiğim çok az zaman oldu. Neredeyse her zaman ya birkaç yıl önce başkasının başlattığı işi devraldım ya da seçeneklerin sıkı biçimde belirlendiği bir organizasyonda oldum. Kişisel olarak ben React’ı seçmezdim
      React’ın kazanmasının sebebi varsayılan seçim haline gelmesi ve insanların bildikleri, alışık oldukları şeyleri sevmesi
    • React’ın avantajları var ama çoğu zaman işe en uygun araç olduğu için değil, atalet yüzünden seçiliyor. “Herkes React kullandığı için işe alım havuzunu ve taşeron havuzunu büyütebiliriz”, “React projesi CV’de iyi görünür” gibi gerekçeler etkili oluyor
    • Hatta çoğu zaman React ve Next.js kullanmaya zorlanıyoruz. Birçok SaaS sağlayıcısı Vercel ile ortak çalışıyor ve genişletme noktalarını sadece o tarafa açıyor
      Başka bir şey kullanmak isterseniz entegrasyonu kendiniz yazmanız, daha önce yapılmış bir açık kaynak proje bulmanız ya da AI’a sormanız gerekiyor
      Hobi projelerinde olur ama iş ortamında bunu hayal etmek zor
    • Kimsenin React kullanmaya zorlanmadığı derken ne kastedildiğini anlamıyorum. Lisp öğrenip onu istediğiniz her şeyde kullanabildiğiniz ve şirket kültürünün teknoloji seçimine hiç etki etmediği o harika yeni dünya tam olarak nerede acaba?

  • React’ı seviyorum. HTMX/Hotwire tarafını da ciddi biçimde denedim.
    Gelen kutusundan gelindiyse tarayıcı API’siyle geri gitmek, aksi halde kaydırma konumunu korumak için gelen kutusu bağlantısına yönlendiren bir geri düğmesi yapmak istedim. HTML’de davranışı bağlayıp geri gitme fonksiyonunu çağırmam, denetleyicide önceki sayfayı belirlemem ve ardından JavaScript etkin geri düğmesini ya da sabit bağlantıyı sunmam gerekti. Mantık 3 dosyaya dağılmış oldu.
    React’ta bileşenin içindeki JavaScript, önceki sayfanın gelen kutusu olup olmadığını belirleyebiliyor ve bu değere göre geri düğmesi JSX’ini ya da bağlantıyı gösterebiliyor. Her şey tek dosyada bitiyor. Benim için tek bir kavramsal varlığı modellemek yeterli oluyor, ama diğer yaklaşımda işlevi 3 farklı varlığa zorla sıkıştırmak gerekiyor.
    Daha yavaş mı? Kesinlikle daha yavaş. Yine de beni mutlu ediyor. Şirketin dağınık React kod tabanında acı çekiyorsanız bunun suçunu çalışma arkadaşlarınıza yüklemelisiniz. React olmasaydı kesinlikle daha da kötü olurdu.

    • Bu yüzden React tek sayfa uygulamalarını sevmiyorum. Her zaman tarayıcının geri düğmesini ve gezinme düğmelerini bozan aptalca bir yol buluyorlar gibi geliyor.
      Bazen form iyileştirmeleri dışında, her zaman htmx/sunucu tarafı render ve yerel davranışı tercih ederim.
    • Bence HTMX’i yalnızca veri durumu ile ilgili işler için kullanmak daha iyi. Akıllı geri düğmesi gibi kaynak durumuna bağlı olmayan şeyleri backend’de hesaplamamak daha iyi.
      Önerilen htmx yaklaşımında onclick düğmesini satır içi JavaScript’e bağlayabilir ya da bundan hoşlanmıyorsanız goBackOrInbox gibi bir fonksiyonu çağırabilirsiniz.
      function goBackOrInbox() { if (document.referrer) { const path = new URL(document.referrer).pathname; if (path.startsWith('/inbox')) { history.back(); return; } } window.location.href = '/inbox'; }
      Bu deseni çok kullanıyorsanız, gidilecek yolu argüman olarak alacak şekilde parametreleştirebilirsiniz.
    • Geri düğmesi sorununu çözmenin en iyi yolu, işleri fazla karmaşıklaştırmamak ve gerçekten dönmek istediğiniz şeylerin tarayıcı geçmişine girmesini garanti etmek değil mi diye düşünüyorum. Sorunun kendisi adeta “yapıyı daha iyi kursan bunu çözmene gerek kalmaz” diye bağırıyor.
    • Orada burada karmaşık kısımlar olabilir ama bunun Web Components ile de yapılabileceğini düşünüyorum.

  • Uzun süre React kodu kullandım, şimdi ise iş yerinde büyük bir Vue projesi üzerinde çalışıyorum. Eskiden herkes Vue’nun ikisi arasında daha kolay ve daha erişilebilir seçenek olduğunu söylerdi, ama artık farklı görmeye başlıyorum.
    React zarif bir şekilde, bileşenlerin özünde yalnızca fonksiyon olmasına dayanıyor ve bunun dışında çok fazla şey yok. Next.js ekosistemini bir kenara bırakırsak, frontend geliştirmede gördüğüm en zarif şeylerden biri.
    Buna karşılık Vue biraz yamalı bohça gibi geliyor. JavaScript’i düzgün öğrenmek istemeyen backend geliştiricilerinin benimseyip övdüğü izleri görülüyor ve ortaya çıkan sonuç temizce birleşmeyen tuhaf bir karışım gibi hissettiriyor.

    • Bu görüşü hiç anlayamıyorum. React bileşenleri sadece fonksiyon değil; hook’lar üzerinden erişilen sihirli biçimde enjekte edilmiş bir bağlam taşıyan fonksiyonlar. Bu hook’lar türlü türlü garantiler gerektiriyor ve bunların farkında olmazsanız hata ayıklaması zor sonuçlar ortaya çıkıyor. Bana pek zarif gelmiyor.
      Başlıca framework’lerin hepsini kullandım ve şu anda büyük bir Angular web uygulaması yapıyorum. Angular’da bileşenler sınıf, şablon ve stillerle ifade ediliyor. Olay dinleyicileri çoğunlukla sınıftaki metotları çağırıyor ve durum, sınıfın özellikleri kadar basit olabiliyor. Çok daha doğal ve tuzağı da çok daha az. Tabii sıfır değil.
    • Vue’yu ne kadar uzun süredir kullandığınızı merak ediyorum. Ben de birkaç yıl önce React geçmişiyle Vue’ya bakarken benzer şeyler düşünmüştüm. Ama şimdi React yerine Vue’yu tercih ediyorum ve hem kişisel projelerde hem de iş projelerinde önce Vue’yu seçiyorum.
      Kullanım hissi biraz farklı. React’ta daha kolay olan şeyler de var, Vue’da daha kolay olan şeyler de var ama Vue’nun signal kullanması benim için büyük bir artı.

  • React’in kendisinden çok, genel olarak arayüzü kodla yazmanın en iyi yolu nedir sorusuyla daha çok ilgileniyorum
    React hayranıyım ve yaptığım neredeyse tüm web uygulamalarında React kullanıyorum, ama en büyük ve en açık sorun şu: React ile UI yazmak, Go ile komut satırı araçları ya da Elixir ile gerçek zamanlı uygulamalar yazmak kadar doğal hissettirmiyor
    Bazı diller belirli işler için şaşırtıcı derecede doğal ve sürtünmesizdir. Ama UI tarafını henüz kimse gerçekten fethedebilmiş değil. Swift, JSX/HTML, Svelte ya da o çizgideki hangi popüler framework olursa olsun, hepsi bir noktada sorunu sadece dolanıyormuş gibi geliyor. Sanki dil/framework tasarımcıları bir noktada gereksinimleri karşılamak için dağınık, garip ya da acı verici sözdizimsel tavizler vermek zorunda kalmış
    UI’ın doğal arayüzü görsel olduğu için Figma gibi araçlar çözümün önemli bir parçası olabilir. Yine de bir şeyler eksikmiş gibi geliyor. Görsel olanı kodla ifade etmenin daha sezgisel bir yolu olmalı. Mevcut çözümleri tam olarak açıklamak zor ama hepsi bir şekilde hep sınırda yetersiz kalıyor

    • Benzer hissediyorum. React ilk çıktığında o dönemin alternatifleriyle kıyaslandığında kusursuz geliyordu, bu yüzden gerçekten çok sevmiştim
      Hâlâ React’i, Svelte, Vue ve Solid dahil neredeyse her şeye tercih ediyorum. Ama son zamanlarda Crank(https://crank.js.org/) kullanmaya başladım ve gitmek istediğim yöne bir adım daha yakın gibi görünüyor. Yine de şimdiye kadar onu sadece oyuncak projelerde kullandım, bu yüzden hem performans hem geliştirici deneyimi açısından ne kadar iyi ölçekleneceğini söylemek zor
    • “Bazı diller belirli işler için şaşırtıcı derecede doğal ve sürtünmesizdir, ama UI tarafını henüz kimse gerçekten fethedebilmiş değil” fikrine güçlü biçimde katılıyorum. 90’ların başında bu meseleyi ele alan kitaplara[1] bakınca, bugün için de aynen geçerli olduklarını görüyorsunuz
      Şimdiye kadar gördüğüm en iyi analiz, Chatty’nin “Programs = Data + Algorithms + Architecture: consequences for interactive software engineering”[2] yazısında. Okuması biraz zor ama fazlasıyla değer
      Kısaca özetlersem sorun mimari, daha doğrusu dil ile mimari arasındaki uyumsuzluk. “Genel amaçlı” programlama dillerinin teşvik ettiği call/return mimari tarzı, kullanıcı arayüzlerinin ihtiyaç duyduğu mimariyle uyuşmuyor; hatta onunla çatışıyor
      Bu konu hakkında “Can Programmers Escape the Gentle Tyranny of call/return?” başlıklı yazıda da yazdım
      Şu anki yaklaşım, alternatif mimari tarzlarını kolayca ifade edebilen bir programlama dili olan Objective-Smalltalk[4]’ı önce yapmak
      Şu anda onunla interscript adlı bir UI framework’ü geliştiriyorum; buna HTMXNative ve çeşitli ek parçalar da dahil
      Oldukça iyi gidiyor gibi görünüyor
      [1] Örn. Myers ve diğerlerinin “Languages for developing user interfaces” https://api.taylorfrancis.com/content/books/mono/download?id...
      [2] https://opendl.ifip-tc6.org/db/conf/ehci/ehci2007/Chatty07.p...
      [3] https://2020.programming-conference.org/details/salon-2020-p...
      [4] https://objective.st
    • Bir mühendis olarak her probleme bakıp “mükemmel bir çözüm var, sadece henüz bulamadık” diye düşünmek kolay
      Ama zamanla daha az idealist cevapları kabul etmeye başlıyorsunuz. Belki de böyle bir çözüm yoktur. Problem alanı o kadar karmaşıktır ki, tüm biçimleri kapsayan, insani ölçekte uygulanabilir genel bir çözüm hiç var olmayabilir. Bunun doğru olduğu bir alan varsa, muhtemelen o alan UI’dır

  • Doğru. React, deklaratif ve imperatif tarzları başarılı biçimde birleştiren, açık ara en sezgisel arayüz. Tüm dillerdeki UI framework’leri arasında JSX’e yaklaşan başka bir şey olduğunu sanmıyorum

    • Flutter, SwiftUI, Jetpack Compose ve daha birçok platform, React’i kendi UI framework’leri gibi uyguladı
    • Madem bu kadar sezgisel, neden neredeyse tüm React uygulamalarında performans bug’ları var anlamıyorum

  • Svelte’i gerçekten seviyorum ve daha karmaşık uygulamalar için SvelteKit kullanıyorum
    Eskiden React kullanacağım birçok durumda bunun çok daha iyi bir gelişme olduğunu hissettim
    Svelte, web geliştirme, HTML, CSS ve JavaScript temellerini bilen biri için öğrenmesi çok daha kolay görünüyor. Ama bugünlerde insanların web geliştirmeye React ile başladığını sık sık görüyorum; bu sıra biraz ters gibi geliyor
    Kişisel olarak mobil uygulamaları SvelteKit + Capacitor ile yapıyorum, kurulumumu da burada yazdım: https://bryanhogan.com/blog/web-to-app-sveltekit-capacitor
    Basit landing page’ler için Astro’yu tercih ediyorum

    • Ben de her zaman önce Svelte + SvelteKit’e uzanıyorum. Basit uygulamalarda Kit fazla olabilir ama beklenmedik şekilde karmaşıklaştığında elinizin altında olması iyi oluyor
      İnsanların bugünlerde web geliştirmeye React ile başlamasının ters bir sıra gibi geldiğine katılıyorum. Svelte, HTML’i ana dili gibi konuşuyor; bu da bu sorunu büyük ölçüde engelliyor. Web geliştirmeye Svelte(Kit) ile başlarsanız, React ile başlamaya kıyasla temelleri daha fazla öğrenme ihtimaliniz yüksek
    • Bana göre doğru kombinasyon Svelte + Astro. Dokümantasyon siteleri ve isteğe bağlı etkileşim içeren sayfalar için çok iyi

  • React’i mümkün kılan kişilerden bazılarının arasındaydım, dolayısıyla bir miktar önyargılıyım; ama React’i gerçekten seviyorum. Ondan önce frontend’de yaşadığımız sorunları çözmek için her şeyi deniyorduk. Ama React çıktıktan sonra buna ihtiyaç kalmadı ve sadece bir şeyler inşa etmeye odaklanabildim

  • Gerçekten çok beğendiğim sunumlardan biri https://www.youtube.com/watch?v=h9SDuTSy7ps idi. Benim deneyimime göre React’in mimarisi gerçekten çok iyi ve büyük uygulamalar geliştirmeye oldukça uygun
    Ne yazık ki React’in en büyük sorunu, seni JS/TS ekosistemine girmeye zorlaması. Benim için JavaScript/TypeScript, şüphesiz doğrudan uğraşmak istediğim bir sistemden çok derleme hedefi gibi
    Elm’den memnunum. Topluluğu gerçekten çok küçük ve bazen kütüphaneleri kendin yazman gerekiyor. TEA, React geçmişinden gelen biri için bazen doğal hissettirmiyor ama useEffect gibi örtük ve beklenmedik durumlar hakkında endişelenmek zorunda olmamak nedeniyle Elm ile çalışırken her zaman heyecan duyuyorum
    Ayrıca Claude da en azından büyük ve korkutucu kod tabanlarında React’e kıyasla Elm’de daha iyi dayanıyor gibi görünüyor

    • Benim deneyimime göre Elm fiilen ölmüş durumda. Çalışmaya devam eden kütüphanelere sahip React ve TypeScript kullanmak daha iyi olur. TypeScript’i native olarak derlenebilir hale getirmeye yönelik girişimler de olmuştu
    • TEA’yi seviyorum ama yeniden kullanılabilir bileşenleri veya yeterince karmaşık sayfaları olan uygulamalarda bunun nasıl ölçeklendiğini tam olarak anlayamadım. Bunu ele almak için üzerinde uzlaşılmış bir yaklaşım olup olmadığını merak ediyorum
      State büyük bir tabu gibi göründüğü için biraz çelişkili de geliyor. Sonuçta bu, tüm Elm uygulamalarının effectsiz bir global Redux + React uygulamasına dönüştüğü anlamına mı geliyor, onu da merak ediyorum. Elm’de neyin keyifli olduğunu ve nasıl çalıştığını daha ayrıntılı duymak isterim. Linkler de olur