- CRDT öğreticisindeki etkileşimli demoları uzun ömürlü içerik olarak ele almak için, belirli bir framework yerine doğrudan HTML içine konabilen web bileşenleri daha uygundur
- Astro’nun MDX bileşenleri build, CSS kapsamı, TypeScript gibi kolaylıklar sağlar; ancak Astro dışına taşındığında yeniden yazma maliyeti doğabilir
- Web bileşenleri, Markdown’a
<pixelart-demo></pixelart-demo> gibi özel etiketler koyup yalnızca script yükleyerek sayfanın herhangi bir yerinde etiket tabanlı yeniden kullanım sağlar
- Framework’ler ve TypeScript de bağımlılıktır; bu yüzden sürüm, API ve uyumluluk değişimleri birikir ve uzun süre dokunulmamış kodda bağımlılık ne kadar çoksa toparlamak o kadar zorlaşır
- Web platformu, eski sitelerin modern tarayıcılarda da çalışabileceği kadar kararlıdır; bu nedenle 5, 10, 20 yıl sonra erişilebilir kalması istenen işler için standart tabanlı yaklaşım avantajlıdır
Etkileşimli demoları içerik gibi korumak
- CRDT blog serisi, kavramları gösteren etkileşimli demolara ihtiyaç duyuyordu; örnek olarak ortak çalışmaya uygun bir piksel art düzenleyicisi kullanıldı
- Teknoloji seçimindeki ölçüt, demo HTML, CSS ve JS ile yapılmış olsa bile blog yazısının içine yerleştirilen içeriğe daha yakın olmasıydı
- Bir yazının içine eklenen görsel veya video gibi bir şeye daha yakındır
- HTML render edilebilen her yere taşınabilmelidir
- Site 2023 itibarıyla Astro ile yapılmıştı; ancak daha önce özel bir statik site üreticisi, Hugo, PHP ile özel CMS, Tumblr, Movable Type, WordPress gibi sistemlerden geçmişti
- Şu anda Astro beğenilse bile, web sitesinin sonsuza dek Astro üzerinde çalışacağını varsaymak zordur
Markdown’ın migration maliyetini düşürme biçimi
- Son migration’ın kolay olmasının nedeni, içeriğin Markdown düz metin dosyaları olarak tutulmasıydı
- Sistem taşırken sıkça gereken işler azalır
- Bir sistemden dışa aktarıp başka bir sisteme içe aktarmak
- Uyumluluk sorunlarını düzeltmek
- Taşınacak yolu bulunamayan öğeleri kaldırmak
- Markdown dosyaları yeni web sitesine konduğunda çoğu şey olduğu gibi çalışır
- Markdown içinde doğrudan HTML yazılabildiğinden, karmaşık etkileşimli diyagramlar da normal HTML etiketleriyle ifade edilebiliyorsa içeriğin geri kalanı gibi taşınabilir
Astro MDX’in kolaylığı ve taşınabilirlik sınırı
- Astro’nun MDX entegrasyonu, Markdown içinde Astro bileşenlerinin render edilmesini sağlar
- Astro bileşenleri build sisteminin çeşitli kolaylıklarından yararlanır
- Tek dosyada HTML, CSS, JS yazma
- CSS seçicileri için kapsam işleme
- TypeScript derleme
- Koşullu markup render etme
- Diğer optimizasyonlar
- Sorun, tüm bu kolaylıkların yalnızca Astro içinde güvenilir biçimde çalışmasıdır
- Başka bir site üreticisine taşınıldığında bileşenleri yeniden yazmak gerekebilir
- HTML, CSS ve JS’yi ayırmak gerekebilir
- Yeni build sistemi yapılandırması gerekebilir
- Stil kapsamı için yeni bir yöntem bulmak gerekebilir
- Bu yüzden Astro’ya özgü özellikler kullanışlı olsa da uzun süre korunması gereken demolar için uygun bir seçim değildir
Web bileşenlerinin çözdüğü kısım
- Web Components, yeniden kullanılabilir HTML öğeleri oluşturmak için kullanılan web standardı teknolojiler kümesidir
- Kullanım biçimi, özel bir öğe sınıfı yazmak, etiket adını kaydetmek ve markup içinde o etiketi kullanmaktır
- Piksel art demosu, Markdown içine yalnızca şu HTML konularak dahil edilir
<pixelart-demo></pixelart-demo>
- Özel bir ayar veya belirli öğeleri önce yerleştirip ardından fonksiyon çağırma gibi bir süreç gerekmez
- JS dosyası korunmalı ve
<script> etiketiyle bağlanmalıdır; ancak metin içeriği içinde medyaya referans verme ihtiyacı, diğer medya türleriyle aynıdır
- Script yüklendiğinde etiket adı kaydedilir ve JavaScript çalışmadan önce markup zaten mevcut olsa bile sayfanın herhangi bir yerinde çalışır
Tek dosya yapısı ve Shadow DOM
- Web bileşenleri HTML, CSS ve JS’yi tek bir dosya içinde kapsülleyebilir ve ayrı bir build sistemine ihtiyaç duymaz
- Bileşen kodu tek yerde toplandığında zihinsel yük azalır; tek dosyalı bileşenler geliştirme deneyimi açısından da avantaj sağlar
- Örnek
<pixelart-demo> bileşeni HTMLElement’ten kalıtım alır, attachShadow({ mode: "closed" }) ile Shadow DOM ekler ve ardından iç markup ile stilleri render eder
- Dosyanın üst kısmındaki
import PixelEditor from "./PixelEditor.js";, ES module import olduğu için ayrı bir build sistemine bağlı değildir
- İlgili dosyalar birlikte tutulursa modülleri tarayıcı işler
- Shadow DOM, bileşeni çevresindeki sayfadan yalıtır
- Uygulamanın geneliyle stil paylaşılması gerektiğinde tuhaf kalabilir
- Tamamen yalıtılması gereken durumlarda uygundur
- Görsel veya video gibi, nerede kullanılırsa kullanılsın aynı görünümü ve davranışı koruyabilir
Dış ayarları attribute’larla almak
- Web bileşenleri, dışarıdan ayarlanabilen attribute’lar sunabilir
- Attribute’lar native attribute’lar gibi kullanılabilir
- CSS değişkenleri Shadow DOM içine girebilen az sayıdaki değerden biri olduğundan, örnekteki range slider accent rengini şöyle ayarlar
<range-slider style="--accent: #0085F2"></range-slider>
- Piksel art demosu attribute ile çözünürlüğü 20’ye değiştirir ve her pikselin debug bilgisini gösterir
<pixelart-demo debug resolution="20"></pixelart-demo>
- Bileşen sınıfındaki
getAttribute ve hasAttribute çağrıları bu attribute değerlerini okumak için kullanılır
- Aynı bileşeni öğreticinin farklı aşamalarında yeniden kullanırken, ilerleme aşamasına göre belirli özellikleri açmak için yararlı oldu
Framework’ler ve TypeScript de bağımlılıktır
- Lit, Stencil, Svelte gibi web bileşenlerine derlenen araçlar vardır; ancak framework nihayetinde bir bağımlılıktır
- Burada en çok endişe edilen trade-off, uzun vadeli bakım maliyetidir
- TypeScript de web’in native temeli olmadığı için bir bağımlılık sayılır
- Son 15 TypeScript sürümünde breaking change vardı; bu değişikliklerin çoğu yararlı yeni özellikler olsa da kod değişikliği gerektirdi
- Bağımlılık kullanıldığında yeni sürüm yayınları, API değişiklikleri ve uyumluluk kontrolü maliyetleri beraberinde gelir
- Bu koda sürekli dokunma planı olmadığı için, ileride mutlaka düzeltmek gerektiğinde yılların güncellemelerini tek seferde ele almak istenmeyen bir durumdur
Eski web sitelerini kurtarma deneyimi ve web platformunun kararlılığı
- Çevrimiçi bir müze oluştururken 10 yıldır açılmamış bir dizüstü bilgisayarda kayıtlı eski kodlar kurtarıldı ve bağımlılığı daha fazla olan web sitelerini hayata döndürmenin daha zor olduğu görüldü
- Yaklaşık 20 yıl boyunca web geliştirirken jQuery’nin doğuşu, büyümesi ve gerilemesi görüldü; Node.js’in ortaya çıkışı ile io.js fork’u ve birleşmesi de yaşandı
- Backbone hızla AngularJS ile, AngularJS de React ile değiştirildi; React de bunun yaklaşık yarısı kadar bir sürede çeşitli bileşen yazma biçimlerinden geçti
- Ekosistem değişirken web platformunun kendisi, mevcut web sitelerini bozmamak için dikkatli biçimde değiştirilerek oldukça kararlı kaldı
- Eski siteler modern tarayıcılarda hâlâ çalışıyor
- 5, 10, 20 yıl sonra da erişilebilir kalacak işler isteniyorsa, kontrol edilemeyen bağımlılıkları azaltıp bozulma olasılığı düşük web standartlarına bağlı kalmak daha uygundur
- Web’in kusurları olsa da, aradaki katmanlar olmadan bu özellikleri dikkate alarak geliştirildiğinde dirençli, taşınabilir ve geleceğe dönük bir bilişim platformu olur
1 yorum
Hacker News yorumları
htmx bir framework değil, bir kütüphane; yazıda da adı geçtiği için birkaç noktaya yanıt vermek istiyorum.
Öncelikle yazı, sunucu ile durumu senkronize etme meselesini ele almıyor; htmx ise hipermedya alışverişi yoluyla tam da bu probleme odaklanıyor. Bu açıdan bakıldığında htmx ile Web Components birbirine dik kesen, yani bağımsız konular.
Bağımlılıklar yeni sürümler, API değişiklikleri ve uyumluluğu koruma maliyeti getirdiği için htmx’in bağımlılığı yok ve geriye dönük uyumluluğa çok odaklanıyor. Örneğin IE11 ile uyumlu; htmx’in 1.0’ı sayılabilecek intercooler.js, tek bir jQuery bağımlılığıyla 2013’te çıkmıştı ama hâlâ destekleniyor.
Pek çok JavaScript kütüphanesinde API’leri yeniden yazma ve zor yükseltmeler kültürü var; ancak htmx açıkça böyle değil ve bu tür genellemelerin içine atılmamalı. htmx 2.0’daki tek kırıcı değişiklik muhtemelen IE desteğinin kaldırılması olacak.
Web Components’ın htmx’ten daha uzun ömürlü olup olmayacağına gelince, tarayıcının bir parçası olduğu için muhtemelen evet; ancak htmx de mümkün olduğunca çok kararlı ve az değişen bir yapıda kalmaya devam edecek. API temelde doğru yönde ve sırf saflık ya da havalı görünmek uğruna her şeyi baştan yazmaya gerek olmadığını düşünüyorum.
Her şeyden önemlisi htmx, Web Components’tan farklı bir soruya, yani sunucu ile durumun nasıl senkronize edileceğine yanıt veriyor.
WebComponent kullanınca, Htmx’in morphdom’unda olduğu gibi dışarıdan değiştirilen DOM öğelerinin yaşam döngüsüne bağlanabiliyorsunuz. Bir özellik değiştiğinde React bileşenine haber vermek, düğüm DOM’dan kaldırıldığında da React’in temizlik adımlarını çalıştırmasını bildirmek gerekiyor. WebComponents olmadan bunu temiz ve verimli yapmak zor olurdu diye düşünüyorum.
Sonuç olarak iş mantığına ait durumun tamamını sunucuda tutan, istemcide ise yalnızca o anda odakta olan öğe veya yazılmakta olan metin gibi sınırlı bazı şeyleri bırakan Htmx yaklaşımında kalmaya devam edebiliyoruz. Bu yöne gidildikçe hatalar ve yarış durumları azalıyor, kullanıcı deneyimi çok daha iyi hale geliyor; bu yüzden çabaya değiyor.
https://x.com/jlazaroff/status/1717176726248108469
https://htmx.org/essays/hypermedia-friendly-scripting/
POST yapabilenin yalnızca formlar olması ve yanıtı işlemenin tek yolunun tüm sayfayı yeniden yazmak olması keyfi biçimde kısıtlayıcı görünüyor. htmx, HTML6 gibi bir şeye dönüşürse tüm JavaScript framework’lerinden daha uzun ömürlü olur.
Daha çok backend’e odaklanan bir mühendis olduğum için, alıp kullandığım JS kütüphanelerinin çoğu sonradan büyük bakım yükü getiriyor ve sık sık büyük API değişiklikleri de yaşıyor. htmx’i kişisel bir projede denemeyi düşünüyorum.
Sunucu tarafında HTML parçaları üreten şablonların da daha az karmaşık hale geleceğini düşünüyorum.
htmx’in kendisi gerçekten ikna edici bir kavram; keşke daha büyük bir topluluğu olsaydı. Bu biraz tavuk-yumurta meselesi ama diğer web framework’lerine kıyasla blog yazısı veya video gibi kaynaklar fazla değil. Örneğin Auth0 kimlik doğrulamasını bir htmx uygulamasına entegre etmek gibi temel bir konuda bile kaynak bulmak zor.
non.io’nun tamamını saf Web Components ile yazdım ve tamamen bir SPA. Basit iç içe blog bileşenlerinin ötesine geçince öğrendiğim birkaç şey oldu
Durum yönetimi için hâlâ net bir cevap yok. Bir sarmalayıcı framework kullanmazsanız pek çok şeyi kendiniz yapmanız gerekiyor. React’in iyi yanlarından biri, durum yönetiminin büyük ölçüde çözülmüş olması ve yerleşik kalıplar ile beklentilerin bulunması. Web Components tarafı ise Vahşi Batı gibi; JSX’teki gibi karmaşık nesneleri attribute olarak geçemediğiniz için attribute’ları, event’leri ve sınıf fonksiyonlarını doğrudan çağırmayı karıştırıyorsunuz
Performans da beklediğim kadar büyük bir kazanç olmadı. İkon gibi küçük atomik öğelerde, sayfada yüzlercesi olduğunda instance oluşturma maliyeti sağladığı değeri aştığı için bunları Web Components’ten geri aldım. Statik öğeler kod okunabilirliği sağlasa bile Web Components olarak kullanmaya değmiyor; bu da epey hayal kırıklığı yarattı
Yine de gerçekten sevdiğim yanları da var. Yazarın dediği gibi, hangi framework’ü kullandığınızdan bağımsız olarak yeni bir sayfaya bileşen eklemek çok kolay. Web Components ile yapılmışsa gerçekten her yerde kullanabiliyorsunuz. nonio’nun API dokümantasyonu gibi yardımcı siteler oluştururken, stack farklı olsa bile istediğiniz bileşeni seçip kullanmak kolay olduğu için güzeldi. Bir bileşeni embed etmeniz gerekiyorsa JS’yi getirip HTML’i eklemeniz yeterli
shadow root’un stil kapsüllemesi de oldukça iyi. Sayfa üzerinde çalışırken bir bileşenin stilini bozacağım diye endişelenmemek hoşuma gidiyor. Başka bir öğenin stilini ezip ezmeyeceğinizi tahmin edip kontrol etme işi azalıyor; bunu garanti altına almak için görsel fark denetimi framework’lerine duyulan ihtiyaç da azalıyor
Paket boyutunun küçük olması da güzel. Kütüphane ya da ek yükleme yok; her şey yerleşik. Gerekli bileşenleri kolayca seçip kullanabildiğiniz için paket boyutunu düşük tutmak da çok kolay
nonio’nun kaynak bileşenleri burada: https://github.com/jjcm/nonio-frontend/tree/master/component...
Durum yönetimi tarafında da istediğiniz herhangi bir durum yönetimi çözümünü bağlamanızı engelleyen hiçbir şey yok. Amaç bağımlılıkları en aza indirmekse tarayıcının yerleşik event modelini kullanan çözümleri de epey gördüm
Son olarak, tüm uygulamayı saf Web Components ile yazmak bence kişisel olarak oldukça zorlama bir fikir. 5KB ile Lit kullanarak çok daha iyi bir geliştirici deneyimi elde edebilirsiniz: https://lit.dev
Bu framework’ler genelde sayfa genelindeki DOM işlemlerini toplu işleyerek performans kazanıyor; Web Components’te ise bunu yapamazsınız
Sırf bu nedenle bile Web Components’i neredeyse çıkmaz sokak olarak görüyorum. Tamamen istemci tarafında render edilen bir sayfa yerine yalnızca küçük işlev adacıklarına ihtiyaç duyulduğunda faydalı olabilir
Ben de benzer performans sınırları gördüm ama bunun hep shadow DOM’un ağır olmasından kaynaklandığını düşünmüştüm. Şimdi instance oluşturmanın kendisinin mi ağır olduğunu merak etmeye başladım
Durum yönetiminde de aynı sorunu hissettim; masaüstü geliştirmeden fikir ödünç alıp pencere düzeyinde bir mesaj veri yolu kurmayı, tüm bileşenlerin buna abone olup filtreleme yapmasını ve tüm durum değişikliklerini bu mesaj veri yoluna yayınlamasını denemeyi düşünüyorum
Karmaşık nesneleri attribute olarak geçirme örneği için burada zx-listeditor’a bakabilirsiniz:
https://github.com/wisercoder/uibuilder/blob/master/WebCompo...
Web Component’in kendisi burada:
https://github.com/wisercoder/uibuilder/blob/master/WebCompo...
Bunu mümkün kılan küçük, 500 satırlık kütüphane burada:
https://github.com/wisercoder/uibuilder/#jsx-for-web-compone...
LiveState’in temel kalıbı “event dispatch et, duruma abone ol” şeklinde. Event’ler ve durum güncellemeleri WebSocket bağlantısı üzerinden iletiliyor; frontend ve backend kütüphaneleri Phoenix Channels üzerinde ince bir katman
Şu anda event handler fonksiyonları Elixir ile yazılıyor, ancak WebAssembly’ye derlenen herhangi bir dille yazılabilmesini sağlamak için çalışmalar sürüyor
Tercih ettiğim JS framework’ünün hep aynı kalmasını beklemiyorum. Ömürlerinin kısa olduğunu biliyorum ve bu hoşuma gidiyor
İleri gitmek, ilerleme kaydetmek ve iyileştirmek için React, Vue, Svelte vb. kullanıyoruz. Şu anda statik bir şey istemiyorum. Çünkü Web Components dahil bugün kullanılabilen framework’lerin hiçbiri sorunu özellikle zarif biçimde çözmüyor
Web Components ile yapılmış bir sitenin JS framework’üyle yapılmış bir siteden daha uzun ömürlü olacağı iddiasıysa, buna bahse girmek isterim. Açıkçası önümüzdeki 20 yıl içinde Web Components teknoloji yığınının bir parçasının Chrome, Safari, Firefox’tan kaldırılıp uygulamayı bozma olasılığını, 2 yıl önce yazılmış bir React 16 uygulamasının JavaScript’teki değişiklikler yüzünden bozulma olasılığından daha yüksek görüyorum
React 16 uygulamasının tüm bağımlılık sürümlerini tamamen sabitlersen bozulmayabilir; ama bu, “React 16 uygulaması üzerinde çalışmaya ve hacklemeye devam edebilmekten” çok eski bir programı VM’de ya da emülatörde çalıştırmaya benzer
Daha anlamlı bahis şu olurdu: “React ZZZ uygulamasında geliştirmeye devam edebilmek mi, yoksa Web Components ile yapılmış uygulamada geliştirmeye devam edebilmek mi?”
Koşulları kendi bakış açımı avantajlı kılacak ama yine de daha anlamlı olacak şekilde kuracak olsam, “N yıllık bağımlılık güncellemesini yakalamak için React uygulamasını güncellemenin maliyeti, Web Components uygulamasına göre daha mı büyük yoksa daha mı küçük?” derdim. Web Components uygulamasına bir sürü tuhaf bağımlılık eklemediysen, React uygulaması tarafındaki güncelleme maliyetinin çok daha yüksek olma ihtimalini görüyorum
Temelde tarayıcı üreticilerinin geriye dönük uyumluluğu React yazarlarından daha az bozacağına bahis oynamış oluyorsun
HTML Imports, yalnızca JS’e dayalı çözümler tercih edilerek kullanımdan kaldırıldı; Firefox bunu zaten implemente etmişti
Custom Elements v0 da kullanımdan kaldırıldı; Chrome bunu implemente etmişti ve YouTube aceleyle bununla yeniden yazılmıştı. YouTube’un geçişi bu kadar sürdüğü için implementasyonun kaldırılması yaklaşık 4 yıl beklemek zorunda kaldı
Kodu güvenli tutmak için kütüphaneleri güncellemek gerekir. Ama eski kütüphane sürümlerinin desteği kesilir ve giderilemeyen bilinen açıklar birikmeye başlar. Saldırganların, bilinen açıkları olan web sitelerini tarayıp otomatik saldırılar yapan programlara sahip olma ihtimali yüksek
Buna karşılık Web Components gibi geriye dönük uyumluluğa önem veren bir kütüphane ya da platform kullanırsan, güvenliği korurken eski kodu daha uzun süre destekleyebilir
Teknolojiden çok insanlara odaklanmaya başladım
Yeni bir projeye başlayacaksam önce o projede çalışacak insanların ne bildiğine bakarım. Frontend’de bugünlerde React’te olduğu gibi ortak payda ya da iyi uygulamalar varsa, doğrudan onu kullanırım
Böyle teknik kararlar üzerinde fazla kafa yormam. Çünkü ekip yapısı, iş arayanlar piyasası ve StackOverflow’daki teknoloji sıralamaları bu sorulara kolayca cevap veriyor
Ama herkes böyle düşünürse, yazılım üretmek için daha iyi bir cevap olsa bile sonsuza kadar React kullanırız. Popüler olanı kullanmak, iyi teknik çözümler bulup onları popüler hale getirecek başkalarına teknoloji yığını iyileştirmesini emanet etmek demek
Başka bir deyişle, bu strateji benimseme eğrisinde kesinlikle orta-geç dönem benimseyenler tarafında yer alıyor. Bu tür yazıların ve tartışmaların önemli bir kısmı daha erken benimseyenleri hedefliyor
Markdown içinde HTML yazılabildiğine göre, gösterişli etkileşimli diyagramlar da sıradan HTML etiketleriyle ifade edilebiliyorsa Markdown’ın geri kalanı gibi taşınabilir olur denmesi, MDX ile de tam olarak aynı şekilde yapılabilir
Burada Web Components teknolojisinin kendisi yardımcı olmuyor. Yazarın önemsediği şey, markup ile çalışma zamanı işlevselliğini uygulayan kod parçaları arasındaki arayüz. Web Components burada yalnızca bir uygulama detayı. Köşeli parantezlerin arasına bir ad yazdığınızda bunun bir React bileşenine mi, Astro’daki bir şeye mi, yoksa bir Web Component’e mi referans verdiği önemli değil. Asıl nokta, başka bir şeyin çağrılması
Burada Web Components’ın dezavantajı, fiilen yalnızca istemcide çalışması. Sunucuda render edilmiş shadow DOM içeriğini istemciye aktarmanın yolu olmadığından, Web Component tamamen etkileşimsiz olsa bile render etmek için istemci tarafında JS gerekiyor. Diğer framework’lerde durum böyle değil
Yazarın noktasının yanlış olduğunu söylemiyorum. Kod parçaları arasındaki arayüzü sistematikleştirmenin bir yolu olarak Web Components muhtemelen en iyi ve en uzun ömürlü yöntem olabilir. Ama sunucuda Web Components hiçbir işe yaramaz. Render edilmez, arayüzü zahmetlidir ve kodun zaten bütün olarak ele alınabilecek şekilde yazılmış olma ihtimali yüksektir. Sunucuda Astro kullanıyorsanız Astro kullanmaya devam edebilirsiniz. React, Vue ya da her ne ise aynı şekilde
Web Components’ın parladığı yer istemcidir. Seçtiğiniz framework ile yazılmamış olabilecek üçüncü taraf bileşenleri kullanırken, sayfaya koyduğunuz bileşenin hangi framework ile yapıldığını bilmeniz gerekmez. HTML etiketini yazarsınız ve çalışır. Arayüz mekanizması tarayıcı seviyesine çıktığı için iki framework’ün birbirinin uygulama detaylarını bilmesine gerek kalmaz
Bu açıdan, bir araca ihtiyaç olduğu konusunda haklısınız. Ancak o araç, ilk HTML’i doldurup bootstrap edecek herhangi bir sunucu tarafı şablon motoru olabilir
Ama sunucuda render edilmiş shadow DOM istemciye aktarılabilir. Buna bildirimsel shadow DOM denir ve Firefox dışında tüm büyük tarayıcılarda çalışır. Firefox da şu anda bunun üzerinde çalışıyor ve bir polyfill de var
https://developer.chrome.com/articles/declarative-shadow-dom...
Bu arada bu polyfill oldukça kolay; dolayısıyla tarayıcı şu anda desteklemese bile kullanmanız mümkün olabilir
Sunucuda render edilebilen Web Components ortaya çıkarsa, çok sayfalı uygulamalarda kullanıcı deneyimini daha iyi hâle getirmek için pek çok olasılık açılır
JS dünyası hâlâ tüm kontrolü elinde tutan kalın istemci fikrine fazla takıntılı olduğu için sunucu dünyasında olup biten ilginç şeyleri kaçırıyor
Rails Hotwire, Phoenix LiveView, Laravel Livewire gibi çözümler, minimum JS ve neredeyse hiç geliştirici deneyimi karmaşıklığı olmadan frontend’in %80’ini çözebilir
Sunucu olmadan veritabanı ve nesne depolamayı okuyup yazan, özellik açısından zengin frontend uygulamaları da yaptım. Taşınabilirliği çok iyi ve kurulum adımı birkaç dosya yüklemekten ibaret. Basit bir CDN’den doğrudan çalışabilir ve çok hızlıdır
Tanıdığım çoğu frontend geliştiricisi de Hotwire tarzını biliyor, ancak onlar için böyle bir stack geliştirici deneyimine karmaşıklık ekliyor. Bazen insanlar “karmaşıklık” derken aslında “yabancılık” demek istiyor. Frontend ve backend ikisi de aşırı karmaşık hâle gelebilir, ama böyle olmak zorunda değiller
İşler ters gittiğinde daha fazla kontrolün daha iyi olduğunu düşünüyorum. Özellikle istemcinin hemen istediğini talep ettiği hızlı tempolu ortamlarda bu daha da geçerli
Kişisel olarak HTML’in üzerine sözdizimsel şeker serpmek yerine her şeyi JavaScript/TypeScript ile yazmayı tercih ederim
Livewire gibi sunucu tarafına koymak, gecikme süresi gibi güçlü dezavantajları ortadan kaldırmıyor
Başlık muhtemelen doğru, ama bunun önemli olup olmadığını bilmiyorum. Çoğu uygulama o kadar uzun yaşamıyor
Yakın zamanda Web Components kullandım; herhangi bir framework’te çok basit olan bir işlevi ayarlamak gerçekten kafa karıştırıcı ve karmaşıktı. Bileşen basit bir şeyse sorun olmayabilir, ancak JS ile uygulama yapıyorsanız slotlar, birleştirilebilir bileşenler oluşturmayı sağladığı için temel bir özelliktir
Geliştirici araçlarında shadow DOM debug etmek de gerçekten kafa karıştırıcıydı
React’in renderProp’u veya Vue’nun scoped slot’u, üst bileşenden alt bileşene veri enjekte etmek için çok yaygın kullanılır. Ancak Web Component’te böyle bir davranışı yeniden üretmek, MutationObserver hack’leri olmadan fiilen imkânsızdır. Web Component’in alt ve üst bileşenlerin birbirinin bilgisini bilmesine gerek olmadığı varsayımı gerçek dünyayla uyuşmuyor
Alt bileşenin üst bileşenden bağımsız olarak her zaman yüklendiği ve başlatıldığı varsayımı da çoğu framework’te yanlıştır. Çoğu framework’te üst bileşen, alt bileşenin gerçekten yüklenip başlatılıp başlatılmayacağına karar verir
Web Components, yalıtılmış ve yeniden kullanılabilir bileşenler yazmak için daha iyi olabilir; ancak uygulamanın çalışması için bir şeyleri birbirine bağlamakta kullanılan DOM API düpedüz berbat.
XML belgelerini düzenlemek için yapılmış olduğu belli.
Yalıtılmış ve yeniden kullanılabilir bileşenler için bile Web Components oluşturmamamın bir nedeni daha var: Hiçbir editör özellik veya olay adları için otomatik tamamlama ya da yazım hatası denetimi gibi şeyleri doğru düzgün yakalamıyor.
Kullanışlı hale getirmek için birden fazla bağımlılığı birbirine bağlamanız gerekiyor ve bu bağımlılıkların muhtemelen React kadar iyi bakım görmeyeceği açık.
Bu felsefeyi izleyen bir şirkette çalışmıştım. Tüm UI bileşenleri, her birinin ayrıca kurulması gereken kendi npm paketine sahip Web Component’lerdi. İyi çalışıyordu ama hiçbir faydası yoktu. Aradan 6 yıl geçti, hâlâ bir faydası yok. Muhtemelen hiç gelmeyecek bir gelecek için optimizasyon yapmış oluyorsunuz.
HTML/CSS siteleri hepsinden daha uzun ömürlü olacak.
Çünkü metin, görseller ve düzen gerçekten statik olan bir şeyin içinde yer alıyor; dokunulmadığı sürece sonsuza kadar yaşayabilir ve karmaşık kod çalıştırmaya ya da belirsiz, hızla değişen yarı standartların bakımına ihtiyaç duymaz.
Uzun ömürlü siteler yapmak ve uzun ömürlü teknolojilere sahip olmak istiyorsanız, kademeli olarak iyileştirilmiş HTML web siteleri oluşturmayı öğrenmeniz yeterli. Web Components gibi işe yaramaz, tireli, tanımsız HTML öğeleri oluşturup ardından bir yığın JavaScript çalıştırdıktan sonra bunları tanımlayan yaklaşım ya da HTML kullanıyormuş gibi bile yapmayan JavaScript framework’leri ancak birkaç yıl dayanır.
En azından tarayıcılardan HTTP/1.1 desteği kaldırılana kadar böyle olacak.