Dioxus 0.5: Rust ile geliştirilen web, masaüstü ve mobil uygulamalar

 (dioxuslabs.com)
3 puan yazan GN⁺ 2024-03-29 | 1 yorum | WhatsApp'ta paylaş
  • Rust GUI çatısı Dioxus 0.5, dioxus-core'un yeniden yazımı ve unsafe'in kaldırılması etrafında; web, masaüstü, mobil ve Fullstack geliştirme akışını büyük ölçüde sadeleştiriyor
  • 0.4.3 ile 0.5.0 arasında 100.000 satırdan fazla kod ve 1.400'den fazla commit eklendi; yeni çekirdek, lifetime ve Scope bağımlılığını ortadan kaldıracak şekilde değişti
  • Mevcut use_state ve use_ref merkezli durum yönetimi, Copy yapılabilen Signal API'siyle değiştirildi; böylece event handler'larda ve future'larda tekrarlayan Clone yükü azalıyor
  • Tek bir dioxus::launch ve dx serve --platform akışıyla web, masaüstü ve Fullstack uygulamalar çalıştırılabiliyor; CLI, hedef platforma uygun build feature'ları otomatik olarak iletiyor
  • Varlık hot reload'u, event sisteminin yeniden yazımı, masaüstü render iyileştirmeleri ve server function streaming de birlikte değişerek tek bir Rust kod tabanının kullanım alanını genişletiyor

Dioxus 0.5'in sürüm yönü

  • Dioxus, Rust ile GUI oluşturmak için kullanılan bir kütüphane ve web uygulamaları, masaüstü uygulamaları, mobil uygulamalar dağıtmak için kullanılıyor
  • 0.5 sürümü, topluluğun talep ettiği sadeleşme, sağlamlık ve olgunluk artışını hedefleyerek tasarlandı
  • Başlıca değişiklikler şunlar
    • dioxus-core'un tamamen yeniden yazılması ve unsafe kodun kaldırılması
    • use_state, use_ref yerine Signal tabanlı API'nin gelmesi
    • Tüm lifetime'ların ve cx: Scope durumunun kaldırılması
    • Tüm platformlarda uygulamayı başlatan tek bir launch fonksiyonu
    • Tailwind ve Vanilla CSS destekli varlık hot reload'u
    • Yerel WebSys event tiplerine erişim sağlayan event sisteminin yeniden yazılması
    • Error Boundary, Server Future, Suspense entegrasyonu
    • Masaüstünde reconciliation performansında 5 kat iyileşme
    • Server function streaming ve Fullstack hot reload
  • Dioxus 0.4'ten güncelleme yapacak kullanıcılar için bir migration guide sunuluyor

Lifetime ve Scope'un kaldırılması

  • Dioxus 0.1'den 0.4'e kadar, bileşen içindeki değerler 'bump lifetime'ına sahipti; bu sayede hook'lar, props ve scope event listener'larda kopyalamaya gerek kalmadan kullanılabiliyordu
  • Bu yaklaşım event handler'larda çoğunlukla iyi çalışsa da, Dioxus future'ları 'static olmak zorunda olduğundan, değerleri future içine taşımadan önce clone gerekiyordu
  • Lifetime hataları oluştuğunda, hata mesajları hook'un kendisinden çok cx'in 'static'ten daha uzun yaşaması gerektiğini söylüyor ve kafa karışıklığı yaratabiliyordu
  • Dioxus 0.5, Scope ve 'bump lifetime'ını kaldırıyor ve Element'i lifetime'sız bir yapıya dönüştürüyor
  • Bileşenler artık scope parametresi olmadan props'u doğrudan alabiliyor
    • Örnek: fn MyComponent(name: String) -> Element
  • Runtime fonksiyonları artık yalnızca bileşen içinde değil, future ve event handler içinde de doğrudan kullanılabiliyor
  • Element'in 'static hale gelmesi, onun hook içinde kullanılmasını veya context API üzerinden sağlanmasını da mümkün kılıyor
  • Bu değişim, sanal liste ya da offscreen rendering gibi API'lerin uygulanmasını kolaylaştıran bir temel oluşturuyor

dioxus-core içinde unsafe'in kaldırılması

  • 'bump lifetime'ı ve scope'un kaldırılması, Dioxus içindeki unsafe kodu azaltmak için bir fırsat yarattı
  • dioxus-core 0.5 içinde unsafe kod bulunmuyor
  • Bazı bağımlılıklarda az miktarda unsafe kalmaya devam ediyor ve Dioxus ekibi bunu 0.5 sürüm döngüsü boyunca kaldırmayı planlıyor
  • Kalan unsafe kullanımları, ya doğrudan kaldırılabilecek olanlar ya da FFI nedeniyle gerekli olanlar olarak sınıflandırılıyor

Signal tabanlı durum yönetimi

  • Dioxus 0.5, bileşenlerin temel durum ilkel tipi olarak Signal'ı sunuyor
  • Signal'ın önceki use_state ve use_ref'e göre iki avantajı var
    • Her zaman Copy yapılabiliyor
    • Elle abonelik gerekmiyor

  • Copy durum

    • Signal<T>, içindeki T değeri Copy olmasa bile kendisi Copy
    • Bu davranış, unsafe kullanılmadan uygulanmış generational-box crate'i sayesinde mümkün oluyor
    • Gerekirse Signal Send+Sync yapılabiliyor, böylece thread'ler arasında taşınabiliyor
    • Copy durum, Send+Sync Signal'lar ve static bileşenlerin birleşimi; durumu future'lara, event handler'lara, thread'lere ve ihtiyaç duyulan diğer yerlere kolayca taşımayı sağlıyor
    • Bellek kullanım biçimi 0.4 ile neredeyse aynı kalırken, açık Clone ihtiyacı ortadan kalkıyor

  • Akıllı abonelik

    • Signal, değer değiştiğinde hangi bileşenin yeniden çalıştırılacağını daha hassas biçimde belirliyor
    • Yalnızca Signal değerini okuyan bileşen yeniden çalıştırılıyor
    • async görevlerde veya event handler'larda yapılan okumalar, bileşeni yeniden çalıştıran abonelik olarak sayılmıyor
    • Üst bileşen bir buton tıklamasıyla Signal'ı değiştirip değeri kendisi okumuyorsa, ama alt bileşen değeri okuyorsa yalnızca alt bileşen yeniden render ediliyor
    • Bu yapı sayesinde ayrı bir durum yönetimi crate'i olan Fermi'ye ihtiyaç kalmıyor
    • Fermi, static'i anahtar olarak kullanan use_state benzeri bir API sunuyordu
    • Dioxus 0.5'te GlobalSignal, static içine konup normal bir Signal gibi kullanılabiliyor
    • Signal, context API ile de çalıştığı için ayrı bir use_shared_state hook'u olmadan bileşenler arasında durum paylaşımı yapılabiliyor
    • use_future, use_memo gibi hook'lar içinde Signal okunduğunda, ilgili Signal hook bağımlılıklarına otomatik ekleniyor

CSS ve varlık hot reload'u

  • Dioxus 0.5, varlık sistemindeki yenilemenin bir parçası olarak varlık dizinindeki CSS dosyaları için hot reload getiriyor
  • Bir CSS dosyası RSX içinde geçtiğinde, dx CLI bu dosyayı izliyor ve güncellemeleri çalışan uygulamaya anında stream ediyor
  • Desteklenen hedefler Web, Desktop ve Fullstack; mobil desteğin ise ileride mobil odaklı bir güncellemeyle gelmesi planlanıyor
  • Tailwind watcher ile birlikte kullanıldığında Tailwind CSS hot reload da destekleniyor
  • VSCode'da custom regex extension ile Tailwind class ipuçları da alınabiliyor
  • Değişiklikler aynı anda birden çok cihaza stream edilerek tüm hedef cihazlarda hot reload sağlanabiliyor

Event sisteminin yeniden yazılması

  • Dioxus, ilk çıktığından beri çapraz platform event API'si oluşturmak için synthetic event sistemi kullanıyordu
  • Synthetic event, platformlar arası davranış ve ağ üzerinden serileştirme için faydalıydı ancak sınırları da vardı
  • Dioxus 0.5, her platformun temel event tipini açığa çıkarıyor ve çapraz platform API'si için trait'ler de sağlıyor
  • Bu değişikliğin iki avantajı var
    • Gerekli bilgiler doğrudan platform event tipinden alınabiliyor veya diğer kütüphanelere aktarılabiliyor
    • Uygulamanın kullanmadığı event kodları için bundle splitting yapılabiliyor
  • Hello world örneğinde gzip'lenmiş boyut yaklaşık %25 azaldı
  • Daha küçük bundle üretmeye yönelik ipuçları Dioxus optimization guide içinde yer alıyor

Çapraz platform çalıştırma API'si

  • Dioxus 0.5, uygulama çalıştırmak için yeni bir çapraz platform API'si sunuyor
  • Ayrı renderer paketleri import etmek yerine dioxus crate'inde feature etkinleştirmek ve prelude içindeki launch fonksiyonunu çağırmak yeterli
  • Tek bir uygulama şu platformlar için çalıştırılabiliyor
    • Desktop: dx serve --platform desktop
    • SPA Web: dx serve --platform web
    • Fullstack: dx serve --platform fullstack
  • CLI, hedef platforma göre uygun build feature'larını otomatik olarak iletiyor

Varlık sistemi betası ve Manganis

  • Dioxus ve web uygulamalarında varlık yolları kolayca eskiyebiliyor, masaüstü ile web arasında linkler farklı olabiliyor ve bundle'a eklenecek varlıkların elle eklenmesi gerekebiliyordu
  • Varlıklar aynı zamanda performans darboğazı da oluşturabiliyor
  • Dioxus Mobile rehberi örneğinde, 0.4 sürümü yüklenirken 7 saniye sürüyor ve 9 MB kaynak aktarıyordu
  • 0.5 mobil rehberi ise aynı görselleri kullanmasına rağmen 1 saniyenin altında yükleniyor ve gereken kaynak miktarı 1/3'e düşüyor
  • Dioxus 0.5, yeni varlık sistemi manganis'i sunuyor
    • CLI ile entegre çalışarak uygulama varlıklarını denetliyor, bundle'a ekliyor ve optimize ediyor
    • API henüz kararlı olmadığı için ayrı bir crate olarak dağıtılıyor
    • Bir varlığı mg! makrosuyla sarmaladığınızda CLI bunu otomatik olarak algılıyor
    • Ayrıntılar manganis docs içinde bulunuyor
  • 0.5 sürüm süreci boyunca manganis varlıklarına da hot reload eklenmesi planlanıyor

Masaüstü render performansında 5 kat iyileşme

  • Dioxus, render diff'lerini hızlı oluşturmak için çeşitli optimizasyonlar kullanıyor
  • Templates, rsx! makrosunun statik kısımlarındaki diff işlemlerini atlamayı sağlıyor
  • Dioxus Web'de sledgehammer ile Rust'tan DOM değişiklikleri hızlı şekilde uygulanıyor
  • Dioxus 0.5, aynı yaklaşımı ağ üzerinden değişiklik uygulamada da kullanıyor
  • Desktop ve LiveView renderer'ları değişiklikleri JSON yerine ikili protokol ile iletiyor
  • Render yükü yüksek işlerde yeni renderer, değişiklikleri tarayıcıya uygulama süresini 1/5'e, gecikmeyi ise 1/2'ye indiriyor
  • Dioxus 0.4'te renderer'ın sürekli takıldığı benchmark, Dioxus 0.5'te akıcı biçimde çalışıyor

Bileşen yazmayı kolaylaştıran özellikler

  • Dioxus 0.5, belirli bir element'i genişletmeyi ve özellikleri element'e yaymayı destekliyor
    • Örnek: img element özelliklerini genişleten ImgPlus bileşeni, width, height, src gibi sıradan img özelliklerini doğrudan alabiliyor
  • Özellikleri ve bileşenlere aktarılacak değerleri yazarken struct initialization shorthand sözdizimi kullanılabiliyor
    • class: class yerine doğrudan class yazılabiliyor
  • Kısaltılmış özellik yazımı, IntoAttribute uygulayan tüm öğelerde çalışıyor ve Signal da bundan yararlanıyor
  • Signal özellikleri henüz diffing atlama optimizasyonundan yararlanmasa da, 0.5 sürüm döngüsü içinde bunun performans iyileştirmesi olarak eklenmesi planlanıyor
  • Birden fazla satıra bölünmüş özellikler birleştirilebiliyor
    • Aynı class özelliğine koşullu değerler eklendiğinde bunlar boşluk ayırıcıyla birleştiriliyor
    • Bu, Tailwind gibi derleme zamanında parse gerektiren ama çalışma zamanında dinamik işleme de ihtiyaç duyan kütüphaneler için önemli
    • Bu sözdizimi Tailwind compiler ile entegre olarak tailwind-merge benzeri kütüphanelerin runtime yükünü kaldırıyor

Server function streaming ve Fullstack

  • Dioxus 0.5, streaming veri desteği sunan güncel server functions crate'ini destekliyor
  • Server function'lar, veriyi istemciye stream edebiliyor veya istemciden sunucuya stream edebiliyor
  • Streaming server function'lar, çıktı tipini tanımlayıp server function içinden TextStream döndürerek oluşturulabiliyor
  • Bu yapı, uzun süren işlemler sırasında istemciyi güncel tutmak için uygun
  • Kalosm ve yerel LLM'ler kullanılarak sıradan donanım üzerinde OpenAI ChatGPT endpoint'ine benzer işlev sunan bir örnek bulunuyor
  • CLI artık fullstack platformunu destekliyor; istemci ve sunucu için hot reload ile paralel build sağlıyor
    • dx serve
    • dx serve --platform fullstack

LiveView, varlık işleyici ve dosya işleme

  • Dioxus 0.5'te router, LiveView uygulamalarında varsayılan olarak çalışıyor
  • Dioxus Desktop, custom asset handler desteği sunuyor
  • Custom asset handler, Rust kodundan JavaScript'e uğramadan veriyi tarayıcıya verimli biçimde stream etmeyi mümkün kılıyor
  • Bu yaklaşım, video streaming gibi bant genişliği yüksek iletişimler için uygun
  • gstreamer veya webrtc verileri doğrudan webview'e iletilebildiği için kareleri ayrıca encode/decode etme ihtiyacı azalıyor
  • Masaüstünde dosya sürükleyip bırakma da event sistemine yerel olarak entegre edildi

Hata yönetimi

  • Dioxus, Error Boundary ve throw trait'i ile üst bileşenlerde hataların kolayca ele alınmasını sağlıyor
  • throw yaklaşımı, hata durumu ile erken dönüşün avantajlarını birleştiriyor
  • Debug uygulayan Result tiplerinde throw çağrılarak hata durumuna geçilebiliyor ve ? ile erken dönülebiliyor
  • ErrorBoundary bileşeni, alt bileşenlerde fırlatılan hata olduğunda farklı bir bileşen render ediyor
  • ErrorBoundary iç içe kullanılabiliyor, böylece uygulamanın farklı seviyelerinde hatalar yakalanabiliyor
  • Bu desen, kurtarılamayan hatalarda panic etmek veya her hata için durumu elle yönetmek yerine global hata durumunu ele almak için kullanışlı

Geliştirici deneyimi ve şablonlar

  • Dioxus, 0.3'te hot reload getirdi, 0.4'te bunu Desktop'a taşıdı ve 0.5'te varsayılan olarak etkinleştirdi
  • Uygulama dx serve ile çalıştırıldığında, geliştirme modunda hot reload varsayılan olarak açık oluyor
  • Desktop uygulamalarında hot reload mümkün olmayıp tam yeniden derleme gerektiğinde bile açık pencerenin durumu korunup geri yükleniyor
    • Uygulama penceresinin boyutu ve konumu korunuyor
    • Her düzenlemede uygulamanın tüm ekranı kaplaması gibi durumlar azaltılıyor
  • Yeni şablonlar, Web, Desktop, Mobile, TUI ve Fullstack uygulamalarını tek komutla oluşturacak şekilde düzenlendi
  • dx new varsayılan uygulaması create-react-app'e daha yakın bir yapıya dönüştü
    • assets, CSS ve temel dağıtım ayarlarını içeriyor
    • dioxus-std, VSCode Extension, dokümantasyon, eğitimler gibi faydalı kaynak bağlantılarını içeriyor

Dioxus Community ve ekosistem

  • Dioxus Community, 0.5 sürümü için önemli ekosistem crate'lerini güncelledi
  • icons, charts ve Dioxus'a özel standart kütüphane gibi crate'ler, 0.5 çıkışıyla birlikte hemen kullanılabilecek şekilde hazırlandı
  • Dioxus Community projesi, orijinal maintainer'ı ayrılsa bile önemli crate'leri güncel tutmak için kurulan yeni bir GitHub organizasyonu
  • Dioxus için kütüphane geliştiriyorsanız, Dioxus ekibi bakım konusunda yardımcı olabiliyor ve bunu fiilen bir “Tier 2” destek düzeyi olarak sürdürmeyi hedefliyor

Gelecekte planlanan özellikler

  • 0.5 sonrasındaki planlar şu başlıkları içeriyor
    • Varlık sisteminin kararlı hale getirilmesi ve daha derin entegrasyon
    • lazy component ile birlikte çıktı .wasm için doğrudan bundle splitting
    • Islands, resumable interactivity ve Signal serileştirme
    • Server component ve LiveView'un Fullstack içinde birleştirilmesi
    • Gelişmiş Devtools ve test framework'ü
    • Mobil tarafın tamamen yenilenmesi
    • WebSocket, SSE, progressive form gibi özellikleri içeren Fullstack yenilemesi

Servo tabanlı Dioxus-Blitz önizlemesi

  • Dioxus-Blitz'in “Blitz 2.0” sürümünde Servo entegrasyonu ile, Firefox'u çalıştırmaya benzer bir CSS motoru üzerinde WGPU tabanlı yerel render hedefleniyor
  • Taffy layout library'nin yaratıcısı Nico Burns, bu çalışmayı ilerletmek için tam zamanlı olarak ekibe katıldı
  • Demoda google.com, GPU üzerinde 900 FPS ile render ediliyor
  • Mevcut uygulama henüz tamamlanmış değil ve google.com render'ı hâlâ biraz kusurlu görünse de kullanılabilir seviyeye hızla yaklaşıyor
  • Depoya https://github.com/jkelleyrtp/stylo-dioxus adresinden bakılabiliyor

Nasıl katkı verilir

  • Dioxus projesi şu katkıları bekliyor
    • Dokümantasyon çevirisi
    • “Good First Issues” denemeleri
    • Dokümantasyon iyileştirmeleri
    • CLI katkıları
    • Discord topluluğunda soruları yanıtlama
  • Dioxus ekibi, 2024'ün geri kalanında topluluk desteği için teşekkür ediyor ve uygulama geliştirmeyi dönüştürmeye yardımcı olunmasını istiyor

İlgili okumalar

1 yorum

 
GN⁺ 2024-03-29
Hacker News yorumları
  • Geçen yıl Dioxus ile Mastodon istemcisi Ebou geliştirdim; genel olarak iyi bir deneyimdi ama eksikleri de çoktu.
    Çalışmaya başladığımda sürüm 0.2’ydi; bu 0.5 değişiklikleriyle o dönemde yaşadığım karmaşıklığın neredeyse tamamı ortadan kalkmış gibi görünüyor. Henüz kendim denemedim ama lifetime’ların kaldırılması ve sürekli klonlama yükünün azalmasıyla çok daha rahat olacağını düşünüyorum.
    • Dioxus’u nasıl seçtiğini merak ediyorum.
      Masaüstü, web/wasm, mobil vb. hedeflere dağıtılabilen yerel reaktif UI yapmaya çalışan epey Rust framework’ü var: https://github.com/flosse/rust-web-framework-comparison. Yanlış seçersem terk edilmiş bir framework’ü sürdürmek ya da sancılı bir migration yapmak zorunda kalırım diye endişeleniyorum.
      Rust HTTP sunucu framework’lerinde de benzer şekilde çok seçenek vardı; şimdi Axum, Actix ve Rocket önde görünüyor, topluluk akışı da Axum’a kayıyor gibi olduğu için Actix’i seçmek hata mıydı diye düşünüyorum. Dioxus’un kazanacağına dair bir işaret var mı; büyük topluluk, YC desteği ve momentum dışında bugün seçilebileceğini gösteren bir ölçüt var mı, merak ediyorum.
      Leptos ve Yew de başlıca rakipler mi; Dioxus’tan daha iyi ya da daha kötü olmalarının sebepleri neler, bilmek isterim. Şirket Rust, Actix ve Bevy’ye ciddi yatırım yaptı; ileride Bevy ile Dioxus gibi framework’leri birleştirerek yerel masaüstü ve mobil istemciler yapmak istiyoruz.
      Ayrıca Dioxus adının Pokémon’daki Deoxys’ten gelip gelmediğini de merak ediyorum. Logo öyle bir his veriyor ama codebase’de Pokémon referansı yok.
  • “Genel olarak iyiydi ama çok eksiği vardı” sözüne katılıyorum.
    Yaklaşık 9 ay önce Dioxus ile sshfs için bir GUI frontend’i yaptım; geliştiricinin henüz tamamlamadığı bir özellikle duvara çarpana kadar gerçekten harika bir GUI framework’ü izlenimi vermişti.
    Farklı context’ler arasında state paylaşımı da zaman zaman sancılı ama dil ya da temel teknoloji ne olursa olsun kullandığım tüm GUI framework’lerinde böyleydi. Dioxus 0.5 bu konuda büyük bir ilerleme gibi görünüyor. Blog’um HTML’in epey büyük bir kısmını Dioxus ile render ediyor; sınırları zorlayan bir kullanım olmadığı için gayet iyi çalışıyor.
  • Dioxus’u ilgiyle takip ediyorum ama henüz deneme fırsatım olmadı.
    Ancak lifetime’ları kaldırma çözümü bana biraz tuhaf geliyor. generational-box bir tür yoksul işi garbage collector değil mi diye düşünüyorum; performans etkisinin nasıl olduğunu merak ediyorum.
    Ayrıca [generational-box]([https://crates.io/crates/generational-box](<https://crates.io/crates/generational-box>;)) bağlantısı bozuk.
    • Evet, yoksul işi bir garbage collector; ama bellek semantiği önceki sürümle tamamen aynı.
      use_hook, component’in lifetime’ı boyunca değerin sahipliğini tuttuğu için component kaybolduğunda o değer de drop edilir. Tüm signal’lar hâlâ use_hook kullandığından lifetime’ları da aynı. use_hook dışında GenerationalBox::new() çağırmak genelde önerilmediği için performans etkisi yok.
      Bir döngü içinde GenerationalBox::new()’u gelişi güzel kullanırsanız o çöp component drop edilene kadar kalır; ama çoğu durumda bir Map’e ya da Vec’e push/pop yaparsınız ve o zaman normal bellek semantiği geçerli olur.
    • Bu temelde otomatik referans sayımıdır: https://en.wikipedia.org/wiki/Automatic_Reference_Counting
  • Rust programcısı değilim ama generational-box crate’inin nasıl çalıştığını merak ediyorum.
    Bunun bir tür arena allocation olduğunu anlıyorum; ama “kopyalamadan kopyalama”yı nasıl desteklediğini ve içeride nesilli bir RefCell arenası oluşturup GenerationalBox’ın Copy olduğu açıklamasının neden güvenli olduğunu anlayamıyorum.
    Statik veriye işaretçi oluşturulabileceğini anlıyorum; peki statik lifetime’ı olmayan bir değer olursa ne oluyor, merak ediyorum.
    • Veriyi kopyalamıyorsunuz; veriye olan referansı kopyalıyorsunuz.
      Veri referansı programın lifetime’ı boyunca korunuyor. Generational box, programa göre daha kısa yaşayan verileri koymanıza olanak tanır; ama o veri referans içermemelidir. Koyduğunuz veriyi drop ettiğinizde o box başka bir allocation için yeniden kullanılır.
      Merkezi bir arena yerine box kullanması dışında, nesilli arenaya çok benzeyen bir yaklaşım; bu da kilitlenme sorunlarından kaçınmak için seçilmiş. Drop edildikten sonra Copy referansla veriye erişmeye çalışırsanız iyi bir hata mesajıyla başarısız olur.
    • Bu crate’i iyi bilmiyorum ama Rust açısından bakınca Copynin belirli bir anlamı var.
      Bir tür Copy trait’ini implemente ediyorsa bu, memcpy ile kopyalanabileceği anlamına gelir; derin kopyadan çok sığ kopyaya yakındır.
      Bu yüzden bunu “kopyalamadan kopyalama” değil, Copy olmayan bir türü Copy tür gibi ele almayı mümkün kılmak olarak anlıyorum. README’de statik içeriğin gerektiği yazıyor; dolayısıyla statik lifetime’ı olmayan değerler için cevap “bunu yapamazsınız” olur.
  • Bir süredir takip ediyordum; yayınlanmasına çok sevindim.
    Dioxus’un React’i başarılı kılan unsurların çoğunu alırken bunun üzerinde hızlıca yenilik yapıp dağıtmasını seviyorum. Bu sürümdeki signals’ı denemeyi sabırsızlıkla bekliyorum.
  • RSX yerine React/JSX’ten çok SwiftUI’ye daha yakın bir şey olmasını isterdim.
    React’in JS ve web için yaptığı iyi şeyleri ve isim değerini kabul ediyorum; ama 2024’te bir dili ya da DSL’i sıfırdan tasarlayabiliyorsak “reaktif UI” kodunun mutlaka React gibi görünmesi gerektiğini düşünmüyorum.
    SwiftUI’nin kusursuz olduğunu söylemiyorum; ama SwiftUI ile yazılan kod, React’te benzer kod yazmaya kıyasla çok daha temiz düzenlenmiş ve bölümlenmiş hissi veriyor.

Çapraz platform GUI’de JSX kullanmanın gerçek avantajı, web için mevcut kütüphaneleri yeniden kullanmak gibi görünüyor; RSX’in ise geliştiricinin JSX kavram bilgisini RSX’e taşıyabilmesi dışında “taşınabilir değeri” daha az görünüyor. Bence React/JSX paradigmasından nesnel olarak daha iyi olduğu düşünülen yeni bir paradigmayı öğrenmek daha iyi bir uzlaşma olurdu.
Özetle, “SwiftUI ama çapraz platform” olan bir proje olsa güzel olurdu, ama henüz yok. @Tokamak/TokamakUI’yi biliyorum, fakat hâlâ epey tamamlanmamış ve etkinliği de azalmış gibi görünüyor.

  • https://ribir.org/ var.
    Şimdilik yalnızca Linux/mac/windows üzerinde yerel masaüstü uygulamalarını destekliyor, ancak WASM, web ve mobil desteği planları var.
  • Freenet’in merkeziyetsiz ana sayfasını yapmak için Dioxus’u seçtim.
    Freenet’i kuran kişilerin ilk göreceği merkeziyetsiz web sitesi olacak. Birkaç yıldır aralıklı olarak üzerinde çalıştığım Kotlin web framework’ü Kweb’e de biraz benziyor; özellikle durum yönetimi ve koddan HTML’ye eşlenen DSL yaklaşımı benzer. Şu ana kadar hoşuma gitti.
    https://freenet.org/
    https://kweb.io/
    • Harika. İlk DSL’i tasarlarken kweb’e bakmıştım sanırım; ikisi gerçekten çok benziyor.
      Aslında Kotlin hayranıyım; Kotlin DSL’lerini ve eşzamanlılık modelini seviyorum.
  • Tauri ile karşılaştırınca nasıl olduğunu merak ediyorum.
    • README’ye bunu yazdık: https://github.com/dioxusLabs/dioxus/?tab=readme-ov-file#dioxus-vs-tauri
      Tauri, frontend’i bir webview içine koyar ve yerel Rust fonksiyonlarıyla Electron’daki gibi bir IPC sınırı üzerinden iletişim kurmak zorundadır.
      Dioxus’ta Rust kodu yerel tarafta olduğu için dosya sistemi okuma, websocket gibi işler için IPC gerekmez. Tauri, frontend’i WASM’e derlemeyi zorunlu kılar; ilginç Rust crate’lerinin birçoğu da wasm’e derlenmez.
      IPC sınırı olmadığında geliştirmenin ne kadar basitleştiğini sözle anlatmak zor. Dioxus araçları yalnızca Rust’ı hedeflediği için sıfırdan paketlenmiş bir .app’e 1 dakikadan kısa sürede gidebilirsiniz. Yeni build yaklaşık 12 saniye, yeni bundle yaklaşık 20 saniye.
      Yine de Tauri’nin sağladığı esnekliği, yani web uyumlu herhangi bir UI’yi frontend olarak kullanabilmeyi çok seviyorum; Tauri uygulaması içinde Dioxus da kullanılabilir.
    • Ben de bu soruyu sormaya gelmiştim.
      Dioxus’un README’de bunu doğrudan ele alması güzel, ama ikisini de kullanmış kişilerin gerçek deneyimlerini de merak ediyorum.
      Tauri ile oyuncak bir masaüstü uygulaması yaptım; web frontend’in her tuş vuruşunda güncellenip çalışmasına rağmen gecikme olmayacak kadar IPC’nin hızlı olup olmadığını kontrol ettim ve yanıt “evet”ti. Büyük bir dosyayı her tuş vuruşunda frontend’den Rust katmanına gönderip tekrar frontend’e geri alabilir miyim sorusunun yanıtı ise, en azından benim saf uygulamamda, “hayır”dı.
      Hem Tauri hem Dioxus için iyi görünen pek çok kullanım örneği var ve bazı durumlarda Dioxus daha iyi olabilir gibi. “Projemizde X ve Y nedeniyle Dioxus ya da Tauri’yi seçtik” türünden karşılaştırmalı deneyimleri duymak isterim. Dioxus gerçekten harika görünüyor; denemeyi dört gözle bekliyorum.
  • Yerel uygulamaların nasıl render edildiğini merak ediyorum. Hâlâ bir tür tarayıcı örneğinin içinde mi çalışıyor?
    • Renderer olarak sistem webview’ünü kullanabilir ya da stylo’yu içe alan deneysel WGPU tabanlı motoru seçebilirsiniz.
      stylo, Servo’dan gelip Firefox ile paylaşılan kısım. Uzun vadede insanları WGPU renderer’a geçirmek istiyoruz, ama hâlâ oldukça erken aşamada; Dioxus kullanan birçok şirket de webview’ün uygulamanın yaklaşık %90’ı için pratikte yeterince iyi bir çözüm olduğunu biliyor.
  • “0.5 sürüm döngüsü boyunca çeşitli bağımlılıklarda kalan çok küçük unsafe parçalarını kaldırmayı planlıyoruz” kısmında, bunların nerelerde kullanıldığını ve motivasyonun ne olduğunu görmek isterdim.
    İnsanların bazen unsafe’i fazla kolay kullandığını anlıyorum, ama standart kütüphane de unsafe ile dolu ve çizgiyi orada çekmek bazen kuma çizgi çekmek gibi görünüyor.
    • Çoğunlukla FFI ile etkileşim kurmak veya bazı tipleri Send/Sync olarak bildirmek için gerekiyor.
      Üç yerde kullanılıyor. iOS’te bazı FFI düzeltmeleri, signal üzerinde fonksiyon çağırma sözdizimini mümkün kılan implementasyon ve pointer’ı hash olarak kullanan ID için Send/Sync implementasyonu.
      Sonuncusuna şimdi bakınca usize ile değiştirirsek kaldırılabilir gibi görünüyor.
    • İnsanların unsafe’ten biraz fazla korkabileceğine katılıyorum.
      Yine de bir crate yazarının kendi crate’inden unsafe’i kaldırmayı hedeflemesi mutlaka kötü bir karar değil.
      Tüm unsafe’leri kaldırmaya çalışan crate yazarları çoğu zaman kullanıcının taşımak zorunda olduğu güven yükünü azaltmak ister. Bence unsafe anahtar sözcüğünün gücü de burada. Aslında belki trust_me blokları ve check_yourself fonksiyonları olarak ikiye ayrılmalıydı.
      unsafe, bellek güvenliği tartışmasını kodun çok dar ve denetlenebilir noktalarıyla sınırlar; aynı zamanda güven hakkında yeni ve yönetilebilir bir tartışma yaratır.
  • React’in hook API’sinde use* adlandırma kuralını neden getirdiğini anlıyorum, ama Dioxus’ta yeni signal oluşturan fonksiyonun neden use_signal olduğunu merak ediyorum.
    let mut count = use_signal(|| 0); yeni bir signal oluşturan çağrı değil mi? Signal her render’da yeniden oluşturulmaz; zaten signal’in özü bu.
    SolidJS’te signal, const [count, setCount] = createSignal(0) gibi createSignal ile oluşturulur ve bu çok daha anlaşılır.
    API adları önemlidir. Çünkü state hook’ları farklı çalışır ve useMemo gibi tamamlayıcı ihtiyaçlar da doğabilir. Dioxus’un React’e yakın görünmek istemesi dışında use_signal adını seçmesinin bir nedeni var mı, merak ediyorum.
    • Dioxus hâlâ component’i yeniden render eder, ancak component’in ürettiği rsx üzerinde birçok optimizasyon uygulayarak Solid’e yakın performans verir.
      Solid’den çok Preact’e daha yakındır.
      Optimizasyonlar arasında UI’nin dinamik parçalarını ayrı “diff bin”lere ayırmak, varsayılan memoization ve signal’in property’leri örtük olarak dirty/managed diye işaretlemesi yer alır.