Web Components fena değil

 (nolanlawson.com)
2 puan yazan GN⁺ 2024-10-01 | 1 yorum | WhatsApp'ta paylaş
  • Web Components tartışması, en yüksek performans ile platform standartları arasında yalnızca birini seçme meselesi değil; ayrıca tüm JavaScript framework’lerini değiştirmesi gerektiği varsayımı da baştan aşırı
  • Custom Elements, arayüz olarak DOM kullandığı için ek yük yaratır; ancak gerçek ürünlerde yalnızca performans değil, bakım kolaylığı, güvenlik, kullanılabilirlik ve erişilebilirlik de birlikte değerlendirilmelidir
  • Framework’lerin web component desteğinin maliyeti bazı basit kontrollerle karşılanabilir; ayrıca bir özelliğin standart olması, her framework’ün onu mutlaka benimsemesi gerektiği anlamına gelmez
  • Web Components, sunucu tarafı render (SSR), erişilebilirlik ve bazı birlikte çalışabilirlik alanlarında zayıflıklara sahip; bu yüzden React, Solid ve Svelte’in daha uygun olduğu durumlar hâlâ var
  • Salesforce örneğinde olduğu gibi istemci tarafı render edilen uygulamalar, component marketplace’leri ve uzun vadeli geriye dönük uyumluluğun önemli olduğu ortamlarda Web Components pratik bir seçenek olabilir

Tartışmanın çıkış noktası ve yazarın konumu

  • Son tartışma, Ryan Carniato’nun “Web Components Are Not the Future” yazısıyla Cory LaViska’nın “Web Components Are Not the Future — They’re the Present” yazısı arasında sürüyor
  • Mesele, karşı tarafı hedef almak değil; farklı kısıtlara sahip geliştiricilerin ortak bir zemin bulup bulamayacağına daha yakın
  • Ryan Carniato, Solid ve js-framework-benchmark içinde görülen performans ile framework tasarımı çalışmaları nedeniyle yüksek saygı görüyor
  • Web Components tarafı da framework implementasyonu, component üretimi, Web Components Community Group, Accessibility Object Model grubu ve shadow DOM, custom elements, erişilebilirlik çalışmalarına bağlı gerçek kullanım alanlarına sahip

Performans: DOM maliyeti gerçek, ama her şey bundan ibaret değil

  • Web Components’ın temel zayıflığı, Custom Elements temelli olması
    • Tüm arayüzlerin DOM üzerinden geçmesi gerektiği için performans ek yükü oluşur
    • Eğer amaç mutlak olarak en hızlı framework ise DOM düğümlerini mümkün olduğunca azaltmak gerekir; bu ölçütte Web Components dezavantajlıdır
  • Ancak performans, yazılım geliştirmenin tek ölçütü değildir
    • Bakım kolaylığı, güvenlik, kullanılabilirlik ve erişilebilirlik de birlikte düşünülmelidir
    • aria-* niteliklerini render etmemek DOM render’ını biraz hızlandırabilir, ama erişilebilir bir arayüz için bunlar gerekli olabilir
    • for döngüsünün .forEach()’ten hızlı olması ya da var’ın const/let’ten hızlı olması gibi mikro optimizasyonlar genellikle katlanmaya değer değildir
  • DOM düğümlerini en aza indirmek, virtualization yaklaşımının temel fikridir
    • En hızlı seçenek olmasa da daha basit bir yaklaşımın yeterli olduğu durumlar olabilir
    • components as elements de en iyi çözüm olmayabilir, ama hedefin her zaman optimum olması gerekmez
  • Farklı framework’lerle yapılmış custom element’leri birlikte kullanmak da pratikte anlamlıdır
    • Framework A’dan Framework B’ye kademeli geçiş gerekebilir
    • Birden fazla mikro frontend’in bir araya getirilmesi gereken durumlar olabilir
    • En hızlı arayüz olmayabilir, ama gerekli bir ödünleşim olabilir
  • Gerçek web performansında layout thrashing, network waterfall ve gereksiz yeniden render gibi düşük maliyetli iyileştirme alanları daha yaygındır
    • js-framework-benchmark gibi rekabetler framework yazarları için ilgi çekici olsa da tipik ürün koşullarında her zaman belirleyici değildir
    • Kaynakların kısıtlı olduğu bir ortamda her milisaniye önemliyse Web Components’tan vazgeçmek de makul bir seçimdir

Framework desteğinin maliyeti ve seçim özgürlüğü

  • Web Components desteğinin framework yazarları için aşırı büyük bir maliyet olduğu iddiasına katılmıyor
    • props ve attributes tespiti prop in element kontrolüyle yapılabilir
    • Web component üretmek sancılı olabilir, ama bu her framework’ün mutlaka yapması gereken bir iş değildir
    • Vue 2 ayrı bir web component wrapper library kullandı ve Remount, React ekibinin katkısı olmadan var oldu
  • Framework’ler, 2011’den sonra web platformuna eklenen özellikleri yok sayarak da gayet iyi olabilir
    • jQuery v1 hâlâ birçok web sitesinde çalışıyor
    • Tarayıcı performans ekipleri geçmişteki web geliştirici kalıplarını optimize ettikçe eski kod yeni tarayıcılarda daha hızlı bile olabilir
  • Modern web platformu özelliklerini benimsemek yeni değerlendirmeleri de beraberinde getirir
    • Symbol, Proxy, Promises gibi özellikler de aynı sınıfa girer
    • Web’in geriye dönük uyumluluğu sayesinde yazdığınız kod 10 yıl sonra da çalışmaya devam edebilir
  • Web Components ile ilgilenmeyen veya desteklemek istemeyen framework’ler de gayet mümkün
    • Tüm UI Web Components ile yapılabilir
    • HTML web components sadece kısmen de kullanılabilir
    • Hiç kullanmama seçeneği de vardır
    • “no web components” framework’leri de hayran kazanabilir

Standartlar bir referans noktasıdır, zorunluluk değil

  • Bir özellik standart haline geldiğinde geliştiriciler onu varsayılan karşılaştırma ölçütü olarak düşünmeye başlar
    • Component yazarı, kendi <slot> çözümünün yerel <slot> gibi davranıp davranmamasına karar vermelidir
    • IntersectionObserver veya <img loading="lazy"> kullanıp kullanmayacağına ya da kendi soyutlamasını kurup kurmayacağına da karar verir
  • Standartlar ortak bir referans noktası ve paylaşılan bir sözlük sağlar
    • Farklı yaklaşımları karşılaştırmak ve ayırmak için ölçü sunar
    • Ancak sırf standart diye mutlaka kullanılmaları gerekmez
  • Web’de kullanılmasa da duran özellikler ve eski API’ler birlikte yaşamaya devam eder
    • document.domain, with, <frame> gibi deprecated API’ler hâlâ desteklenir
    • Web platformunun özellikleri seçilerek kullanılabilir ya da tamamen bırakılabilir

Web Components’ın uygun olduğu ve olmadığı yerler

  • Web Components birçok işi iyi yapar, ama tüm JavaScript framework’lerinin yerini alacak bir araç değildir
  • Zayıf tarafları arasında sunucu tarafı render (SSR), erişilebilirlik ve bazı birlikte çalışabilirlik sorunları bulunur
  • React, Solid ve Svelte gibi framework’lerin daha çok öne çıktığı pek çok durum hâlâ mevcut
  • “Web Components geleceğin kendisi değil” sözü, belirli geliştiriciler veya projeler için doğru olabilir
  • Tartışmanın temelinde, farklı insanların farklı kısıtlar altında farklı şeyler ürettiği gerçeği yatıyor

Salesforce örneği ve pratik değerlendirme

  • Salesforce, Web Components’ın iyi uyabileceği bir ortam gösteriyor
  • Bu koşullar yoksa tüm UI’yi Web Components, shadow DOM ve ilgili tüm yapıyla kurmak gerekli olmayabilir
  • Web platformunda WebGL, Wasm, Service Workers gibi farklı yeteneklerle geliştirilen oyunlar, sanat projeleri ve kurumsal SaaS uygulamaları bir arada var oluyor
  • Platforma yeni özellikler eklendiğinde yaratıcılık sınırlanmak yerine, daha önce hayal edilmeyen ifade biçimlerine alan açılıyor
  • Ek okuma olarak Lea Verou’nun yazısı ve Baldur Bjarnason’ın yazısı da bulunuyor

İlgili okumalar

1 yorum

 
GN⁺ 2024-10-01
Hacker News yorumları

  • Atıfta bulunulan “Web Components Are Not the Future” yazısını anlamaya çalıştım ama ikna edici dayanak çok fazla değildi.
    Bugünkü frontend framework ekosisteminin hâli karmakarışık ve karmaşık framework’leri ya da dokümantasyonu okumadan anlaşılmayan sihirleri (useState, createSignal vb.) öğrenmek istemiyorum.
    Web Components’tan başlayınca sezgisel geliyor ve Shadow DOM izolasyonu gibi başka yerde olmayan yetenekler de kazanılıyor.
    React döneminden geriye kalması gereken tek şeyin JSX olduğunu düşünüyorum; Web Components’ı JSX ile birlikte kullanan bir kütüphane yaptım: https://webjsx.org

    • “Karmaşık framework öğrenmek istemiyorum” cümlesi birkaç düşünceyi bir araya getirdiği için yorumlaması zor.
      Framework’ün kendisini öğrenmek istememek mi, öğrenmeye gerek kalmayacak kadar sihirli hissettiren bir şey istemek mi, dokümantasyon okumak isteyip istememek mi belirsiz.
      Ağırlıklı olarak Vue kullandım; SPA ekosistemi karmaşık ama karmaşık duruma sahip istemci uygulamalarını yönetmek için başka nasıl bir sistem mümkün, onu da pek bilmiyorum.
    • UI’a nasıl baktığınızla ilgili bir fark da var.
      jQuery’nin temel kalıbı, öğeleri seçip değiştiren yan etki odaklı bir yaklaşım; React veya Vue.js ise UI durumunun veri tarafından belirlendiği bileşenler oluşturmayı sağlıyor.
      Veri değiştiğinde en az DOM değişikliğiyle güncelliyor; bu yaklaşım, konuma bağlı olarak UI widget’larını çok daha okunabilir ve bakımı kolay hâle getiriyor.
      Günümüzde web siteleri ve web tabanlı masaüstü uygulamaları 20 yıl öncesine göre çok daha karmaşık olduğundan, yalnızca basit UI yapmayacaksanız durum yönetimi tarafındaki yenilik önemli.
    • Bir React uygulaması yazmak için useState’in içeride nasıl çalıştığını bilmeniz gerekmez; uygulanma biçimi de oldukça sezgiseldir.
      Buna karşılık önerilen kütüphane, daha baştan daha karmaşık bir zihinsel model gerektiriyor gibi görünüyor.
      Framework’ün ayrıntılarını derinlemesine anlamak ideal olsa da React, iç modelini neredeyse hiç bilmeden de oldukça sofistike uygulamalar geliştirmeyi mümkün kıldığı için başarılı oldu.
    • Angular o kadar zor değildi; yaklaşık bir haftada karmaşık bir site yapacak veya makul bir PR gönderecek seviyeye gelmek mümkündü.
      C#’ın beta döneminden beri, HTML/JS/CSS’in ilk zamanlarından beri geliştirme yapan biri olmamın da etkisi vardır ama hızlıca kavradım.
      Eski ve karmaşık bir çekirdek altyapı yönetim portalını değiştirirken Angular’ı seçtik; kararlı, hızlı ve hoş görünümlüydü, herkes memnun kaldı.
      “Dik öğrenme eğrisi” daha çok sektöre yalnızca JavaScript ve biraz React bilerek giren geliştiricilerden geliyor gibi; daha fazla deneyim varsa hemen öğrenilebiliyor.
    • useState’in içini merak eden bir geliştirici birkaç saniye içinde mantıklı ve doğru bir cevaba ulaşabilir.
      Karmaşık ya da sihirli değil; React hook’larına benzer asgari bir uygulama birkaç yüz satırla yapılabilir.
      Temel bir useState ve runFunctionComponent uygulaması, üniversite bilgisayar bilimi üçüncü dönem ödevlerinin çoğundan daha kolaydır.
      Sihir için ölçüt buysa, etrafımız kahvaltı sırasında bile yeni bir Eldritch Invocation üreten 20. seviye Warlock’larla dolu demektir.

  • Bu tartışmada tarafların birbirini ıskalamasının nedenlerinden birinin, optimize etmeye çalıştıkları şeylerin farklı olması olduğunu düşünüyorum.
    VC yatırımı almış bir startup’ta hızlı hareket edip sürekli bakım yapılacak çekirdek bir ürün geliştiriyorsanız framework iyi uyabilir.
    Ama akademik araştırma laboratuvarlarında, yapılmış uygulamaların bakımını sürdürecek çok para olmaz ve fon yeni projelere geçtikten sonra da uygulamanın çalışmaya devam etmesi gerekir.
    Bir Vue uygulamasını Web Components ile yeniden yazma işini neredeyse bitirdim; bağımlılıklar çürümüş, güncellemek imkânsız hâle gelmişti.
    Önceden bağımlılık cehennemini düzeltmeye zaman harcıyordum ve muhtemelen ileride de böyle olacaktı; Web Components’ı denediğimde hemen iyi geldiği için geçiş yaptım.
    Bağımlılıklar yaklaşık 15’ten yaklaşık 1’e (d3js) düştü ve pişman değilim.
    Eski uygulama https://bam.iobio.io/, yeni uygulama https://bam2.iobio.io/

    • Bu mantığı bazen anlamakta zorlanıyorum.
      Kimse framework’ü her zaman en son sürüme yükseltmeye zorlamıyor; kullandığınız Vue sürümünde kalabilirdiniz.
      Özel bir neden yoksa sonuna kadar aynı sürümü kullanmak da gayet mümkün olabilirdi.
      En başta o kullanım senaryosu için Vue’ya gerek olmadığı ya da bağımlılıkları kaldırmanın kötü bir seçim olduğu anlamına gelmiyor; ama Vue’dan memnunsanız en yeni sürümde kalma zorunluluğu yok gibi görünüyor.
    • d3js dışında bağımlılıkları kaldırabildiyseniz, aynı şeyi yaparken Vue bağımlılığını da korumak mümkün olmaz mıydı?
      Vue’nun ek bağımlılık gerektirmesinin nedeninin build sistemi tarafında olup olmadığını merak ediyorum.
    • Alışınca Web Components geliştirme herhangi bir framework’ten daha yavaş olmayacaktır diye düşünüyorum.
      Bu yüzden VC ekosisteminin neden framework olmadan idare edemediğini pek anlamıyorum.
    • Tüm Web Components’ları elle yazdıklarına inanmak zor; dış bağımlılığın hiç olmadığına inanmak da zor.

  • Svelte’in Custom Elements API üzerinden Web Components üretmeyi desteklemesi hoşuma gidiyor.
    Svelte normal JS/HTML/CSS’e derlendiği için, herhangi bir framework’te ya da vanilla JS’te çalışan yeniden kullanılabilir bileşenler oluşturmak doğal: https://svelte.dev/docs/custom-elements-api

    • Rich de bunun Svelte’in bir numaralı hedefi olmadığını kabul ediyor; dolayısıyla gerçeğin vaadin gerisinde kalması şaşırtıcı değil.
    • Vue da bu özelliği sunuyor: https://vuejs.org/guide/extras/web-components

  • Web Components tartışmalarını yıllardır takip ediyorum ama bir full-stack geliştirici olarak hayatımı daha iyi hâle getirmek için ne yapabileceklerinden hâlâ pek emin değilim
    Bu örneklerin çoğu veriyi HTML’e şablon olarak koymaktan ibaretti; bunu zaten handlebars ile yapabiliyoruz
    Bir şeyi mi kaçırıyorum acaba

    • “Web”de HTML’i belge olarak gören bir model ile HTML’i daha karmaşık uygulamaların sahne grafiği olarak gören bir model var
      HTML’i belge olarak kullanıyorsanız Web Components ile daha gelişmiş gerçek zamanlı etkileşim özellikleri ekleyebilirsiniz
      WebSocket’e bağlanan terminal emülatörü, tarih seçici, özel form öğeleri, harita, veri tablosu, sekme widget’ı ve eski jquery-ui’nin sağladığı özel bileşenler buna örnek
      Web Components olmadan da yapılabilir ama özel bileşen olarak yapınca HTML çok daha temiz ve belge gibi kalıyor
      Tutarlı bir Web Components kütüphanesi olsa iyi olurdu; HTMX ve server-sent events ile de epey iyi bir gerçek zamanlı sohbet mümkün görünüyor
    • Tam yerel izolasyon mümkün
      HTML, CSS ve JS’nin tamamını tarayıcı, ek numaralara gerek kalmadan izole ediyor
      Bir Web Component oluşturup JS, HTML ve CSS API’sini değişkenler üzerinden net tanımladıktan sonra herhangi bir ortama koyduğunuzda bozulmaması; karmaşık CSS namespace’leri ve framework bağımlılıkları labirenti oluşturmak zorunda kalmamanız güzel
    • Kademeli iyileştirme için çok iyi
      Örneğin bir tabloyu saran Web Component ile filtreleme veya sürükle-bırak sıralama gibi özellikler ekleyebilirsiniz; JS kapalıysa ya da yüklenemezse kullanıcı yine temel tabloyu ve içeriği alır
      Eskiden bu, frontend framework’lerinin beyaz ekranından çok daha iyiydi; ama artık sunucu tarafı render yaygın biçimde mümkün olduğundan avantajı azaldı
      Stil kapsülleme de iyi ama günümüzde headless UI kütüphaneleri ve framework’lerin scoped styles’ı yaygınlaştığı için 10 yıl öncesine göre daha az acil görünüyor
      Yine de slot kullanmak için Shadow DOM’u seçmek zorunda kalmak; kendi yeniden kullanılabilir bileşenlerinizi yaparken sayfaya tek bir stylesheet koyarak stillendirememeniz sinir bozucu
    • Örneklerin dinamik API’den kaçınmasının nedeni muhtemelen o kısmın çok çirkin ve durumla dolu olması
      Bir demo manuel DOM düzenleme için 200 satır gösteriyorsa Web Components’ın gelecek olduğunu söylemek zor
    • Web Components, başka framework’lerle yapılmış UI bileşenlerini kendi framework’ünüzde kullanmanızı sağlar
      Hepsi bu; diğer amaçların çoğu için de epey kötü
      Ayrıca UI bileşenini 7 farklı sürüm hâlinde yapmadan, tüm framework’lerde çalışacak şekilde dağıtabilirsiniz

  • Web Components ve Shadow DOM’un en kötü tarafı, tarayıcı uzantılarının düzgün çalışmamasına ya da hiç çalışamamasına yol açabilmesi
    Tarayıcı üreticileri de bu durumu düzeltmek için acele etmiyor

    • Kullanıcı ajanının yapılandırılabilirliği web’in killer özelliği

  • Web Components’ın en büyük “hatalarından” birinin, insanların zihninde onu Shadow DOM ile birleştirmesi olduğunu düşünüyorum
    Uygulama geliştirmede canlı DOM’a bağlı kalırsanız Web Components çok hafif ve kolay bir seçenek hâline geliyor
    bootstrap, tailwind gibi istediğiniz CSS araçlarını kullanmaya devam ederken neredeyse sıfır maliyetle harika bir işlevsel kapsülleme elde edebiliyorsunuz; renderer olarak lit-html gibi bir şey kullanınca özellikle iyi oluyor
    Ekipler yerel Web Components ile çalışmayı genel olarak ferahlatıcı buldu; framework dünyasından gelen geliştiriciler de bir hafta kadar alışınca geri dönmek istemedi
    Basit sınıf özellikleri ve set() içinde render fonksiyonunu elle çağırmakla, framework zahmeti olmadan reaktifliğin avantajlarını elde edebiliyorsunuz
    Sorun, “kolay mod”la nasıl başlanacağını gösteren pek fazla kaynak olmaması
    Giriş materyallerinin çoğu, uygulama geliştiricilerden çok kütüphane yazarlarına yönelik Shadow DOM, CSS parts gibi sancılı teknolojilere doğrudan itiyor
    Web Components ile hayatı kolaylaştıran “The Good Parts” tarzı bir rehber yazmak gerekiyor gibi

    • Shadow DOM’u her gün kullanıyorum ama Web Components’ta insanların kafasını en çok karıştıran kısım da genelde bu. Muhtemelen gerekli olmadığı için
      Alternatif olarak yalnızca canlı DOM kullanan, sunucu tarafı render öncelikli ve “jQuery sosu”nun yerine iyi gelen “HTML web components” var: https://adactio.com/journal/20618
      Bir de Shadow DOM’u mümkün olduğunca az kullanıp, stillendirme veya bileşim gerekiyorsa bunu canlı DOM’da bırakan “Shadow gristle” var: https://glazkov.com/2023/03/02/shadow-gristle/
    • Bunun hakkında yazarsanız okumak isterim. Dinlemek de iyi olur
      Bu teknoloji, kullanım biçimine göre hem nimet hem de lanet olabiliyor gibi; bu yüzden ilgili kaynakları ve yorumları topluyorum
    • Önceki işimde aynı stack’i, yani Shadow DOM’suz WC ve yalnızca lit-html’i kullanıyorduk; çok iyiydi
      En iyi yanı, iki haftada bir bağımlılık cehennemine düşmemek
    • Tam olarak mesele bu. Şu anda eksik olan şey light DOM için slotlar

  • Birlikte çalışabilirlik kullanıcı açısından en büyük avantaj, ama bunun bedeli olarak kullanılan her bileşenle birlikte gereksiz bir runtime gelebilmesinden doğan performans maliyetinin hafife alındığını düşünüyorum
    Web Components ile birlikte Lit gibi bir framework kullanmak önerilen yol; zamanla yeni framework'ler çıktıkça ve bileşenler eski sürümlere bağlı kaldıkça bu maliyet birikir
    Bir sayfada birden fazla yinelenen kütüphane bulunması yönünü kimseye önermek istemem; bu iyi uygulamalara dahilse uzun vadede iyi değil
    Web Components savunucularının yazılarını, sosyal medya paylaşımlarını ve videolarını yıllardır görüyorum; aslında hedef kullanıcı ben olmalıyım, ama birlikte çalışabilirlik vergisinin üstüne ana akım framework'lerde olmayan dezavantajlarla dolu
    Her framework ekosisteminin içinde birlikte çalışabilirlik iyi çalışıyor ve geliştiricilerin birlikte çalışabilirlik aramasına yol açan aynı dinamikler, az sayıdaki ana akım framework etrafında toplanmalarını sağlıyor
    Web Components'ın teknik açıdan yetişemediğini ve 2010'ların başındaki bir tasarım uğruna web platformuna çok fazla karmaşıklık eklediğini düşünüyorum: https://x.com/Rich_Harris/status/1840116730716119356

    • Başka bir yazıda değinmiştim ama genel olarak, tüm web uygulamaları eklenen her kB için performansa duyarlı değildir. E-ticaret böyledir, ama üretkenlik araçları genelde değildir
      Svelte gibi küçük runtime'a sahip framework'ler de çok; bir sayfaya 100 tane koyalım demiyorum ama 5-6 tane bence sorun olmaz
      Bunun ideal olduğu anlamına gelmez, ama kademeli geçişlerde veya mikro frontend'lerde faydalı olabilir
      Bu arada React 17 de aynı sayfada birden fazla React sürümü bulundurabilme özelliğini getirmişti: https://nolanlawson.com/2021/08/01/why-its-okay-for-web-components-to-use-frameworks/, https://bundlephobia.com/package/svelte@4.2.19, https://legacy.reactjs.org/blog/2020/10/20/react-v17.html
    • Söylediğin doğru olsa da bugün yapılan web uygulamalarının çoğuna bakınca birden fazla kütüphane sorunu yuvarlama hatasına yakın görünüyor
      React ve react-dom birlikte 100KB'ı aşıyor; Svelte ve Lit ise tek haneli KB düzeyinde
      İnsanların her gün düşünmeden kullandığı şişkinliğe yaklaşmak için epey fazla framework ekleyebilirsiniz
    • Daha geniş bakarsak Web Components'ın framework yazarlarını ikna etmesi gerekiyor
      Şimdiye kadar sürekli gördüğüm sinyaller iyi değil; o topluluk X'te ve Web Components onların sorunlarını çözmüyor, en iyi durumda bile iyi kullanılmıyor
      İkna etmeyi başarmalarını isterim, ama onlar genel olarak Web Components'ın başarısız olduğunu ve genel anlamda web için kötü olduğunu söyleme eğiliminde
    • Bu argümanı açıkçası pek anlayamıyorum
      Runtime'ların çoğu oldukça küçük ve iki runtime'ın aynı anda çalışması büyük bir performans yükü yaratmaz
      Modern web framework'lerinin hepsi reaktif; yanıt verecek bir şey yoksa hiçbir şey yapmazlar
      Bir sayfanın bir kısmı React, başka bir kısmı Lit, bir diğer kısmı Svelte ile yapılsa bile kullanıcı deneyiminin veya pil tüketiminin tek framework'lü bir sayfadan belirgin biçimde kötüleşmesi için pek neden göremiyorum
      Alıntılanan tweet, Web Components'ın “framework oluşturmak için yararlı ilkel öğeler” olup olmadığıyla ilgili; gerçekten kullanmış hayranları bile çoğunlukla buna evet demeyecektir
      Web Components bir dağıtım mekanizmasıdır ve alternatif, aynı kütüphaneyi React, Preact, Svelte, Solid, Vue ve vanilla JS için 7 kez yapmaksa bu berbat bir şeydir

  • Web Components'ı seviyorum ve kendi elimizle yarattığımız mevcut frontend cehenneminden çıkmamızı sağlayabileceği konusunda iyimserim
    Yakın zamanda frontend'in geleceği hakkında kısa bir sunum yaptım; başkaları da bir çıkış yolu bekliyor gibiydi
    DB GUI'si için bir veri tablosu yaptım ve yüz binlerce satır yüklense bile kaydırma çok akıcı
    Web Component kütüphanesini de yakında yayımlamayı düşünüyorum; henüz erken ve pürüzlü ama daha fazla kişinin bakmasını isterim: www.astra-ui.com

    • Mevcut frontend cehenneminden çıkmanın tek yolunun istemci tarafı import gelmesi olduğunu düşünüyorum: https://github.com/whatwg/html/issues/2791
    • Dokümantasyona baktım; iPhone 15 Pro Max'te Safari 18.0'da render oldukça tuhaf
      Küçük ekranlar için responsive tasarımı düşünerek kenar çubuğunu yeniden konumlandırmanız ve body'ye width yerine max-width vermeniz iyi olur
      Ana sayfanın altındaki “explore components” düğmesi hiçbir yere bağlanmıyor gibi
      “İyi yapılandırılmış ve erişilebilir bileşen uygulamalarından öğrenin” diyorsunuz ama dokümantasyonda uygulama bağlantısı bulamadım
      “Yönetecek veya güncelleyecek bağımlılık yok” diyorsunuz ama astra-ui'nin kendisi bir bağımlılık değil mi diye düşünüyorum; ayrıca değişiklik günlüğü de var: https://www.astra-ui.com/changes/
      “Kod ve stil üzerinde tam kontrol” de diyorsunuz; kütüphanenin sağladığı uygulamaya bağımlıyken bunun nasıl tam kontrol olabildiğini anlamıyorum
      Bu kütüphaneyi yayımlamaya karar verme nedeninizi merak ediyorum. Dahili yazılımı açık kaynak yapmak, şirketin belirli hedefleri olduğunda yararlı olabilir; ama genelde karşılıksız zaman tüketimine dönüşmesi kolaydır
      Bileşen kütüphaneleri ekosistem benimsenmesi için mücadele etmek zorundadır; aksi halde dinleyici kitlesi olmaz ve yayımlamak için pek az neden kalır
    • Vue bileşeni gibi bir şey yerine bunu kullanmamızın nedeni ne olurdu?
    • Web Components neden hâlâ yerleşmedi ya da daha yaygın kullanılmıyor?
      Harika bir çözüm gibi görünüyor
    • Şirketin frontend reklam kodunu Web Components ile yeniden yazdım

  • Birkaç ay önce yeni işimde yaklaşık 250 bin satırlık bir JS codebase’i devraldım
    Tek bir devasa sınıf ve birkaç alt sınıf her şeyi yapıyordu; bazı dosyalar 30 bin satıra kadar çıkıyordu
    Framework de reactivity de yoktu; bir düğmeye tıklayınca event listener ile ekrandaki her şeyi elle güncellemek gerekiyordu
    Sanki biri elinde yalnızca temel bir JavaScript kitabıyla yıllarca bir manastır hücresine kapanıp yazmış gibiydi
    Parça parça ilerlemem gerektiği için Web Components ile refactoring yapmaya başladım; çok faydası oldu ve şu ana kadar 50 bin satır azalttım
    Ama asıl amaç, yeniden yazmadan önce mevcut kodun yaptığı her şeyi öğrenmekti

    • Eski ve anlaşılması zor bir codebase’i anlamanın anahtarı, her seferinde küçük bir kısmı refactor etmek
      Web Components ile yeniden yapmak bu hedefe ulaşmanın bir yolu; her şeyi çöpe atıp sıfırdan başlamamış olması iyi
      Yine de bir noktaya kadar ilerleyip başka bir projeye geçerse, sıradaki kişinin gelip kendi tarzıyla refactoring’e başlaması ve bunun üç farklı stile sahip anlaşılması zor bir codebasee dönüşmesi riski var
      Buna rağmen 250 bin satırı tek seferde yeniden yazmaktan iyidir

  • Web Components’ta hoşuma giden şeylerden biri, en azından teoride JS devre dışıyken de çalışabilmesi
    Progressive enhancement için bunu birkaç kez yaptım
    Genel olarak Nolan’ın söylediklerine katılıyorum. Web Components’ın yeterince pürüzlü kenarı var; mevcut haliyle dünyayı ele geçirmesi zor, ama belirli kullanım alanları için oldukça iyi
    Yalnız server-side rendering ile iyi uyuşmadığı sözüne pek katılamıyorum; sorunsuz biçimde yaptım

    • Bunu neden söylediğini merak ediyorum
      Gördüğüm kadarıyla belirli bir etikete template kaydetmek için JavaScript gerekiyor gibi: https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_templates_and_slots
    • Bunun nasıl çalışması gerektiğini bilmiyorum
      ReactJS’te component veya template’leri sunucuda render edebiliyorsunuz ve JSX’in oldukça iyi bir template dili olduğunu düşünüyorum
      Web Components’ta yerleşik iyi bir template dili yok; anladığım kadarıyla kendiniz getirmeniz gerekiyor
      Bir etiketle ilişkilendirilmiş JS component parçasını alıp, JS çalıştırmadan gereken HTML’i render eden standart bir mekanizma bilmiyorum
    • Yazarı benim. Başka bir yazıda değindim ama temel olarak istemcide elde ettiğiniz birlikte çalışabilirlik avantajları sunucuda henüz yok
      İleride sunucuda üç farklı Web Component framework’ünü render edebilir, bunları birbirleriyle compose edebilir ve temiz biçimde hydrate edebilirsek, bunun çözüldüğünü söyleyebiliriz: https://nolanlawson.com/2023/08/23/use-web-components-for-what-theyre-good-at/