1 puan yazan GN⁺ 2025-01-18 | 1 yorum | WhatsApp'ta paylaş
  • learn.yjs.dev şu anda dağıtımı geçici olarak duraklatıldığı için öğrenme içerikleri görüntülenemiyor
  • Sayfada This deployment is temporarily paused durum mesajı dışında duraklatma nedeni belirtilmiyor
  • Dağıtımın ne zaman yeniden başlayacağına dair bir zamanlama da paylaşılmamış
  • Yjs öğrenme içeriklerinin yapısı, özellikleri ve örnekleri şu anki sayfadan doğrulanamıyor
  • Şu anda varılabilecek tek değerlendirme, learn.yjs.dev’in geçici olarak duraklatılmış durumda olduğudur

1 yorum

 
GN⁺ 2025-01-18
Hacker News yorumları
  • Hey HN! Bunu yapan Jamsocket geliştiricisiyim. Yjs’ye aşina değilseniz, işbirlikçi ve local-first uygulamalar geliştirmek için bir CRDT kütüphanesi olarak düşünebilirsiniz.
    Dağıtık durumla daha önce uğraşmadıysanız öğrenme eğrisi epey var; JavaScript framework demolarındaki “hello world” gibi sayaç artırma örnekleri bile işin içine birden fazla istemci girince zorlaşıyor.
    Pek çok eğitim “şu kütüphaneyi ve metin editörü entegrasyonunu kur, uygulama tamam” tarzında olduğu için gerçekte neler olup bittiğine dair bir zihinsel model vermiyor.
    Bu yüzden etkileşimli bir Yjs eğitimi olan Learn Yjs’i hazırladım; local-first geliştirmeye yeni başlayanların da sezgisel olarak anlayabilmesi için keşfedilebilir demolar ve kodlama alıştırmaları ekledim.

    • CRDT’lere ve işbirliği özelliklerine ilgi duyuyordum ama her başlamaya çalıştığımda en büyük engel tam da “kütüphaneyi kur, bitti” tarzı eğitimlerdi.
      WebSocket için ücretsiz hosting bulmak da biraz daha zor görünüyor; mevcut CRDT eğitimleri de çok yardımcı olmuştu.
    • Local-first uygulama geliştirmeye dair örnekler olup olmadığını merak ediyorum.
      Saf HTML/JS ve Alpine ile çalışıyorum; bu tür uygulamalarda da Yjs kullanılıp kullanılamayacağını bilmek isterim.
    • Bunun Yrs [0] ile de çalışıp çalışmadığını, yoksa ayrı bir proje mi olduğunu merak ediyorum.
      Ayrıca Y-Sweet’in Automerge veya Loro gibi başka CRDT kütüphaneleriyle de çalışıp çalışmadığını, yoksa yalnızca Yjs’ye özel mi olduğunu öğrenmek isterim.
      Hepsi ikili dosya alıp verme yapısı açısından benzer göründüğü için Y-Sweet’in benzer CRDT uygulamalarıyla ne kadar uyumlu olduğunu merak ettim.
      [0] https://github.com/y-crdt/y-crdt
    • Gerçekten çok iyi yapılmış. Bununla sonunda CRDT’yi anlayıp anlayamayacağımı merak ediyorum; hafta sonu sonuna kadar bakmayı planlıyorum.
  • Yjs iyi ve P2P sonuç almak kolay.
    Ancak Yjs backend’i, kalıcılık, nihai çakışma çözümü (bir editörün çok uzun süre çevrimdışı kaldığı durumlar) ve geçmişi geri sarma çözmesi zor mühendislik problemleri gibi görünüyor.
    Platejs https://platejs.org/ gibi blok editörlerde hep iyi bir deneyim istemiştim.
    Liveblocks https://liveblocks.io/text-editor gibi çözümlerin geliştirici deneyimini basitleştirmeye çalışması iyi, ama çoğunda veri kontrolünden bir ölçüde vazgeçmek gerekiyor.
    HN’de CRDT anahtar kelimesiyle arama yapınca her zaman iyi sonuçlar ve ilgi görülüyor; ancak açık kaynak backend tarafında iyi seçenekler pek görünmüyordu. Geçmişte birkaç kez kontrol ettim; kaçırdığım bir şey varsa söylerseniz sevinirim.
    https://hn.algolia.com/?dateRange=pastYear&page=0&prefix=tru...
    Çoğu kişi en azından Google Docs veya Notion gibi çalışmasını bekliyor; geliştirici açısından da ayrıntılı uygulamaya derinlemesine girmeden, Postgres JSONB’ye benzer bir formatta özel olarak saklanmasını istiyor.

    • Teoride yalnızca serileştirilmiş yamaları dağıtmak yeterli, ancak gerçek bir backend’de mevcut belge durumunu, kullanıcı kimliğini ve bir miktar erişim kontrolünü de bilmek gerekebilir.
      Go backend’de Y.js kullanmak istediğim birkaç kez oldu, ama basit bir referans uygulama bulmak zor olduğu için zaman kısıtları nedeniyle her seferinde vazgeçtim.
      Yıllardır tekrar kontrol ediyorum; Node.js dışında hâlâ zor görünüyor.
  • Daha önce küçük bir yan projede Yjs kullandım. İstemci tarafını öğrenmek ve kullanmak oldukça kolaydı.
    Sunucu tarafında tek bir binary olarak dağıtmak istiyordum; ancak Node dışı dillerde örnekler, örneğin Rust portu Yrs için örnekler neredeyse yok denecek kadar azdı.
    Sonunda https://github.com/yjs/y-websocket üzerinde biraz değişiklik yaptım ve LevelDB tabanlı kalıcılık ekledim; bana göre ideal değildi.
    Rust gibi bir dilde kalıcılık dâhil sunucu tarafını uygulamak için iyi kaynaklar olup olmadığını merak ediyorum.
    Hatırladığım kadarıyla mevcut istemci materyalleri metin editörü entegrasyonlarına çok ağırlık veriyordu; bu yüzden bu eğitim gerçekten faydalı. Metin editörü entegrasyonu kullanmadığım için kendim el yordamıyla ilerlemek zorunda kalmıştım.

    • Y-Sweet[1] doğru seçenek olabilir. Learn Yjs’in banner’ını çalıştıran açık kaynak Rust sunucusu.
      Depolama için S3 veya yerel dosya sistemini kullanıyor ve musl ile linklenmiş birkaç MB’lık bir binary olarak derleniyor.
      https://github.com/jamsocket/y-sweet
  • “İndeksleri tamsayı değil kesir olarak tutan kesirli indeksleme tekniği” deniyor; durmadan önce kaç kez kullanılabilmesi gerektiğini merak ediyorum.

    • Kendim test ettim, 1075 kez çıktı; çok büyük bir değer değil, bu yüzden bu kütüphanenin önemli sorunlarından biri olabilir gibi görünüyor.
      Test kodu şöyle:
      let left = 0, right = 1
      let rightPrevious = 2
      let counter = 0;
      while (right > left && right < rightPrevious) {
      rightPrevious = right;
      right /= 2;
      counter++
      }
      console.log(counter)
      Depoya çok kısa baktım ama bu sorunun nerede ele alındığını bulamadım; derinlemesine inceleyecek vaktim yoktu. Gerçek bir issue ise çözmeye yardımcı olabilirim.
  • Şu anda çevrimdışı çalışma gerektiren bir uygulama geliştirirken Yjs kullanıyorum.
    Aslında gerçek zamanlı bir işbirliği uygulaması değil, ama sunucuyu bir işbirlikçi, uygulamayı da diğer işbirlikçi olarak düşünürseniz kullanım senaryosunu kolayca hayal edebilirsiniz.

  • Yjs’te bir türlü aşamadığım nokta, bu öğreticideki yapılacaklar uygulamasında öğe taşıma örneğini genelleştirince işlerin çok hızlı karmaşıklaşmasıydı.
    Birbiriyle ilişkili birden fazla nesne olduğunda bunları aynı Document içine koymak istiyorsunuz; bu ilişkiyi senkronize durumda tutmak içinse öğreticideki kesirli indeksleme gibi pek çok tuzak var.
    Sonra veritabanı ölçeğinde öğe birikince, her şeyi tek bir belgeye koyan oyuncak model, herhangi bir öğeyi okumak isteyen tarafa tüm DB’yi ve geçmişini göndermek gerektiği anlamına geliyor.
    Sonunda öğeleri ayrı nesnelere bölüp kendiniz kalıcı hale getirmeniz gerekiyor; ama bu öğretici [0] dışında dokümantasyon yok. Spoiler: yıllardır “Work in Progress - come back later” yazan boş bir sayfa.
    Bu yüzden bir Provider oluşturup yönetmeye çalışsanız da dokümantasyon durumu aynı [1].
    Subdocuments’ı keşfedip bu yaygın soruna bir çözüm var sandığınız için seviniyorsunuz [2], ama bazı Provider’lar alt belgeler arasındaki ilişkileri işleyemiyor, bazı Provider’lar da alt belgelerin kendisini desteklemiyor. Sonunda kendi Provider’ınızı yazmanız gerekiyor ve yine dokümantasyon yok sorununa dönüyorsunuz.
    Kodu okumaya çalışınca, Yjs’in özünde aslında bir protokol olduğunu fark ediyorsunuz. Ama Yjs’in özü olan o protokol de tam olarak belgelenmiş değil; oldukça kendine özgü kodun çeşitli yerlerine dağılmış durumda. Tabii 10 yıl önce Yjs’in öncülünün nasıl çalıştığını anlatan makaleyi dokümantasyon saymazsanız.
    Bunu bir şikâyet olarak yazmak istememiştim, ama yıllar boyunca çalışır hale getirmek için çok fazla zaman harcadım ve “sihir gibi çalışıyor!” tarzı oyuncak demolarla gerçek bir şey arasındaki boşluk çok büyük. O kısmın dokümantasyonu 10 yıldır “Work in Progress” dışında boştu.
    Bu yazının yazarı gibi Yjs ile gelir elde etmeye çalışan şirketlerin bu boşluğu kapatmasını umuyorum.
    [0] https://docs.yjs.dev/tutorials/persisting-the-document-to-a-...
    [1] https://docs.yjs.dev/tutorials/creating-a-custom-provider
    [2] https://docs.yjs.dev/api/subdocuments
    [3] Bunu yazarken durumun değişmiş olmasını umuyordum, ama tüm dokümantasyon 5 yıl önce olduğu gibi hâlâ çalışma aşamasında ve alt belge desteği de aynı görünüyor.

  • Etkileşimli demoda gecikme kaydırıcısının ağ gecikmesi gibi değil, debounce tamponu gibi davranması şaşırtıcı. Neden böyle yaptıklarını anlamıyorum.

    • Birden çok konumda durum değiştiğinde ortaya çıkan sorunu göstermek için yeterli olan en basit gecikme modelini seçtik.
      Bu yaklaşımın avantajı, okuyucudan hiçbir durumu gizlemeden uygulanabilmesi. Pasta grafik, var olan tek iç durumu doğrudan gösteriyor.
      Amaç doğru bir ağ simülasyonu değil, sezgi oluşturmak.
  • Etkileşimli demo çok güzel. Yapmak için hangi kütüphaneleri kullandıklarını merak ediyorum.

    • Sitenin tamamı Astro ile yapıldı; demolar ise React ile yapılmış “etkileşim adaları”.
      Demoların içinde gerçekten Yjs çalışıyor. Her “istemcinin” kendi belgesi var; kullanıcı tıkladığında setTimeout ile gecikme simüle ediliyor, ardından belgeler elle birbirleriyle birleştiriliyor. Ortadaki zaman çizelgesi için üçüncü bir belge de var.
      Bunun dışında yapılacaklar demosundaki sürükle-bırak için dnd kit [1], animasyonlar için Motion [2], metin düzenleyici için CodeMirror [3] kullanıldı.
      [1] https://dndkit.com
      [2] https://motion.dev
      [3] https://codemirror.net
  • Banner görselindeki oyun aptalca ama eğlenceli.

  • Sonunda dört yapraklı yonca yaptım, ama yaklaşık 2 dakika sonra biri mahvetti.
    Düzenleme: Durun, herkes nereye gitti? Sanırım ya biz bozduk ya da ben engellendim. Yine de yapan kişiyi alkışlıyorum. Harika bir şey.

    • Engellendiğin kesinlikle yok. Sanırım insanlar kısa süreliğine azaldı; şu anda epey imleç görünüyor.
      Bu arada iki tane daha gizli emoji var.