Dioxus 0.5: Aplikasi Web, Desktop, dan Mobile yang Dikembangkan dengan Rust

(dioxuslabs.com)

3 poin oleh GN⁺ 2024-03-29 | 1 komentar | Bagikan ke WhatsApp

Framework GUI Rust Dioxus 0.5 sangat menyederhanakan alur pengembangan Web, Desktop, Mobile, dan Fullstack, dengan fokus pada penulisan ulang dioxus-core dan penghapusan unsafe
Antara 0.4.3 dan 0.5.0, masuk lebih dari 100.000 baris kode dan lebih dari 1.400 commit; core baru berubah ke arah menghilangkan lifetime dan ketergantungan pada Scope
Manajemen state yang sebelumnya berpusat pada use_state dan use_ref digantikan oleh API Signal yang dapat di-Copy, sehingga beban Clone berulang di event handler dan future berkurang
Dengan satu alur dioxus::launch dan dx serve --platform, aplikasi Web, Desktop, dan Fullstack dapat dijalankan, sementara CLI otomatis meneruskan build feature yang sesuai dengan platform target
Hot reload aset, penulisan ulang event, peningkatan rendering Desktop, hingga streaming server function ikut berubah, sehingga cakupan penerapan satu codebase Rust menjadi lebih luas

Arah rilis Dioxus 0.5

Dioxus adalah library untuk membuat GUI dengan Rust, dan digunakan untuk distribusi aplikasi web, desktop, dan mobile
Rilis 0.5 dirancang dengan tujuan penyederhanaan, ketangguhan, dan peningkatan kelengkapan yang diminta komunitas
Perubahan utamanya adalah sebagai berikut
- Penulisan ulang penuh dioxus-core dan penghapusan kode unsafe
- Pengenalan API berbasis Signal sebagai pengganti use_state dan use_ref
- Penghapusan semua lifetime dan state cx: Scope
- Satu fungsi launch untuk memulai aplikasi di semua platform
- Hot reload aset yang mendukung Tailwind dan Vanilla CSS
- Penulisan ulang event yang memungkinkan akses ke tipe event native WebSys
- Integrasi Error Boundary, Server Future, dan Suspense
- Peningkatan reconciliation Desktop hingga 5 kali
- Streaming server function dan hot reload Fullstack
Panduan migrasi tersedia bagi pengguna yang memperbarui dari Dioxus 0.4

Penghapusan lifetime dan Scope

Dari Dioxus 0.1 hingga 0.4, nilai di dalam komponen memiliki lifetime 'bump, yang memungkinkan hook, props, dan scope digunakan di event listener tanpa perlu disalin
Di event handler, pendekatan ini umumnya berjalan baik, tetapi future di Dioxus harus bersifat 'static, sehingga nilai perlu di-clone sebelum dipindahkan ke dalam future
Saat terjadi error lifetime, pesan yang muncul bisa membingungkan karena menyatakan bahwa cx, bukan hook itu sendiri, harus hidup lebih lama daripada 'static
Dioxus 0.5 menghapus Scope dan lifetime 'bump, serta mengubah Element menjadi bentuk tanpa lifetime
Komponen kini dapat menerima props secara langsung tanpa parameter scope
- Contoh: fn MyComponent(name: String) -> Element
Fungsi runtime dapat digunakan langsung tidak hanya di dalam komponen, tetapi juga di dalam future dan event handler
Karena Element menjadi 'static, ia juga bisa digunakan di dalam hook atau disediakan melalui context API
Perubahan ini menjadi fondasi yang memudahkan implementasi API seperti virtual list atau offscreen rendering

Penghapusan unsafe dari `dioxus-core`

Penghapusan lifetime 'bump dan scope membuka peluang untuk mengurangi kode unsafe di internal Dioxus
dioxus-core 0.5 tidak memiliki kode unsafe
Sejumlah kecil unsafe masih tersisa di beberapa dependensi, dan tim Dioxus berencana menghapusnya selama siklus rilis 0.5
Unsafe yang tersisa diklasifikasikan sebagai hal yang dapat dihapus secara sederhana atau diperlukan karena FFI

Manajemen state berbasis Signal

Dioxus 0.5 memperkenalkan Signal sebagai tipe primitif state inti untuk komponen
Signal memiliki dua keunggulan dibanding use_state dan use_ref sebelumnya
- Selalu dapat di-Copy
- Tidak memerlukan subscription manual
State Copy
- Signal<T> bersifat Copy meskipun nilai T di dalamnya bukan Copy
- Perilaku ini dimungkinkan oleh crate generational-box yang diimplementasikan tanpa unsafe
- Jika diperlukan, Signal dapat dibuat Send+Sync sehingga bisa dipindahkan antar-thread
- Kombinasi state Copy, Signal Send+Sync, dan komponen static membuat state mudah dipindahkan ke lokasi yang diperlukan seperti future, event handler, atau thread
- Pola penggunaan memorinya hampir sama dengan 0.4, tetapi tidak memerlukan Clone eksplisit
Subscription cerdas
- Signal menentukan dengan lebih rinci komponen mana yang perlu dijalankan ulang saat nilainya berubah
- Komponen hanya dijalankan ulang jika komponen tersebut membaca nilai Signal
- Pembacaan di async task atau event handler tidak dianggap sebagai subscription untuk menjalankan ulang komponen
- Jika parent mengubah Signal melalui klik tombol tetapi tidak membaca nilainya secara langsung, sementara hanya child yang membaca nilainya, maka hanya child yang di-render ulang
- Berkat struktur ini, Fermi, yang sebelumnya merupakan crate manajemen state terpisah, tidak lagi diperlukan
- Fermi menyediakan API mirip use_state yang menggunakan static sebagai key
- Di Dioxus 0.5, GlobalSignal dapat ditempatkan di static dan digunakan seperti Signal biasa
- Signal juga bekerja dengan context API, sehingga state dapat dibagikan antar-komponen tanpa hook use_shared_state terpisah
- Saat Signal dibaca di dalam hook seperti use_future atau use_memo, Signal tersebut otomatis ditambahkan ke dependensi hook

Hot reload CSS dan aset

Sebagai bagian dari perombakan sistem aset, Dioxus 0.5 mengimplementasikan hot reload untuk file CSS di direktori aset
Jika file CSS muncul di dalam RSX, CLI dx akan memantau file tersebut dan langsung melakukan streaming update ke aplikasi yang sedang berjalan
Target yang didukung adalah Web, Desktop, dan Fullstack; dukungan mobile akan disediakan dalam pembaruan yang berfokus pada mobile di masa mendatang
Jika digunakan bersama Tailwind watcher, hot reload Tailwind CSS juga didukung
Di VSCode, hint class Tailwind juga dapat diperoleh melalui custom regex extension
Perubahan dapat di-streaming secara bersamaan ke beberapa perangkat untuk melakukan hot reload di seluruh perangkat target

Penulisan ulang sistem event

Sejak awal rilis, Dioxus menggunakan sistem synthetic event untuk membuat API event lintas platform
Synthetic event berguna untuk perilaku event lintas platform dan serialisasi jaringan, tetapi juga memiliki keterbatasan
Dioxus 0.5 mengekspos tipe event dasar dari masing-masing platform, sekaligus menyediakan trait untuk API lintas platform
Perubahan ini memiliki dua keuntungan
- Informasi yang diperlukan dapat diperoleh langsung dari tipe event platform atau diteruskan ke library lain
- Kode event yang tidak digunakan aplikasi dapat di-bundle splitting
Pada contoh hello world, ukuran gzipped berkurang sekitar 25%
Tips membuat bundle kecil disertakan dalam panduan optimasi Dioxus

API eksekusi lintas platform

Dioxus 0.5 memperkenalkan API lintas platform baru untuk menjalankan aplikasi
Alih-alih mengimpor paket renderer terpisah, cukup aktifkan feature pada crate dioxus dan panggil fungsi launch dari prelude
Satu aplikasi dapat dijalankan dengan target platform berikut
- Desktop: dx serve --platform desktop
- SPA Web: dx serve --platform web
- Fullstack: dx serve --platform fullstack
CLI secara otomatis meneruskan build feature yang sesuai berdasarkan platform target

Beta sistem aset dan Manganis

Di Dioxus dan aplikasi web, path aset mudah menjadi usang, link bisa berbeda antara desktop dan web, dan aset yang perlu disertakan dalam bundle harus ditambahkan secara manual
Aset juga bisa menjadi bottleneck performa
Pada contoh panduan Dioxus Mobile, versi 0.4 membutuhkan 7 detik untuk memuat dan mentransfer resource sebesar 9 MB
Panduan mobile 0.5 menggunakan gambar yang sama, tetapi dimuat dalam waktu kurang dari 1 detik dan resource yang diperlukan berkurang menjadi 1/3
Dioxus 0.5 memperkenalkan sistem aset baru manganis
- Terintegrasi dengan CLI untuk memeriksa, membundel, dan mengoptimalkan aset aplikasi
- Karena API-nya masih belum stabil, didistribusikan sebagai crate terpisah
- Jika aset dibungkus dengan makro mg!, CLI akan mendeteksinya secara otomatis
- Detail lebih lanjut tersedia di dokumentasi manganis
Selama rilis 0.5 berlangsung, hot reload juga direncanakan untuk ditambahkan ke aset manganis

Peningkatan rendering Desktop 5 kali

Dioxus menggunakan berbagai optimasi untuk membuat diff rendering menjadi cepat
Templates membuat diff bagian statis dari makro rsx! dilewati
Di Dioxus Web, perubahan DOM diterapkan dengan cepat dari Rust melalui sledgehammer
Dioxus 0.5 juga menggunakan pendekatan yang sama untuk menerapkan perubahan melalui jaringan
Renderer Desktop dan LiveView mengomunikasikan perubahan dengan protokol biner, bukan JSON
Pada workload dengan beban rendering berat, renderer baru mengurangi waktu penerapan perubahan ke browser menjadi 1/5 dan latensi menjadi 1/2
Benchmark yang membuat renderer terus berhenti di Dioxus 0.4 berjalan mulus di Dioxus 0.5

Fitur kemudahan penulisan komponen

Dioxus 0.5 mendukung kemampuan memperluas element tertentu dan menyebarkan atribut ke element
- Contoh: komponen ImgPlus yang memperluas atribut element img dapat menerima atribut img umum seperti width, height, dan src apa adanya
Saat meneruskan nilai ke atribut dan komponen, sintaks singkat inisialisasi struct dapat digunakan
- Dapat ditulis seperti class alih-alih class: class
Atribut singkat bekerja untuk semua item yang mengimplementasikan IntoAttribute, dan Signal juga mendapatkan manfaat ini
Atribut Signal belum melewati diffing, tetapi direncanakan ditambahkan sebagai optimasi performa selama siklus rilis 0.5
Atribut yang terbagi dalam beberapa baris dapat digabungkan
- Jika nilai kondisional ditambahkan ke atribut class yang sama, nilainya digabungkan dengan spasi sebagai pemisah
- Ini penting untuk library seperti Tailwind yang membutuhkan parsing saat compile time sekaligus pemrosesan dinamis saat runtime
- Sintaks ini terintegrasi dengan Tailwind compiler dan menghilangkan overhead runtime dari library seperti tailwind-merge

Streaming server function dan Fullstack

Dioxus 0.5 mendukung crate server functions terbaru yang mendukung data streaming
Server function dapat melakukan streaming data ke client atau streaming data dari client ke server
Streaming server function dapat dibuat dengan mendefinisikan tipe output dan mengembalikan TextStream dari server function
Cocok untuk memperbarui client selama pekerjaan yang berjalan lama
Ada contoh yang menggunakan Kalosm dan LLM lokal untuk menyediakan fungsi serupa endpoint OpenAI ChatGPT pada hardware biasa
- Repositori contoh: https://github.com/ealmloff/dioxus-streaming-llm
CLI kini mendukung platform fullstack, serta menyediakan hot reload dan build paralel untuk client dan server
- dx serve
- dx serve --platform fullstack

LiveView, asset handler, dan pemrosesan file

Di Dioxus 0.5, router berjalan secara default pada aplikasi LiveView
- PR terkait: https://github.com/DioxusLabs/dioxus/pull/1505
Dioxus Desktop mendukung custom asset handler
- PR terkait: https://github.com/DioxusLabs/dioxus/pull/1719
Custom asset handler memungkinkan data di-streaming secara efisien dari kode Rust ke browser tanpa melalui JavaScript
Cocok untuk komunikasi berbandwidth besar seperti streaming video
- PR terkait: https://github.com/DioxusLabs/dioxus/pull/1727
Data gstreamer atau webrtc dapat diteruskan langsung ke webview, sehingga kebutuhan untuk mengenkode dan mendekode frame secara langsung berkurang
File drop di desktop juga terintegrasi secara native ke sistem event

Penanganan error

Dioxus memudahkan penanganan error di komponen atas melalui Error Boundary dan trait throw
Pendekatan throw menggabungkan keunggulan state error dan early return
Pada tipe Result yang mengimplementasikan Debug, throw dapat dipanggil untuk mengubahnya menjadi state error, lalu ? digunakan untuk early return
Komponen ErrorBoundary me-render komponen lain jika ada error yang dilempar dari child
ErrorBoundary dapat disarangkan, sehingga error dapat ditangkap di berbagai level aplikasi
Pola ini berguna untuk menangani state error global saat terjadi error yang tidak dapat dipulihkan, tanpa melakukan panic atau mengelola state secara manual untuk setiap error

Pengalaman pengembangan dan template

Dioxus memperkenalkan hot reload di 0.3, menambahkannya ke Desktop di 0.4, dan mengaktifkannya secara default di 0.5
Saat aplikasi dijalankan dengan dx serve, hot reload aktif secara default dalam mode development
Bahkan saat hot reload tidak memungkinkan di aplikasi Desktop dan diperlukan recompilation penuh, state jendela yang terbuka dipertahankan dan dipulihkan
- Ukuran dan posisi jendela aplikasi dipertahankan
- Mengurangi situasi ketika aplikasi menutupi seluruh layar setiap kali diedit
Template baru dirapikan agar aplikasi Web, Desktop, Mobile, TUI, dan Fullstack dapat dibuat dengan satu perintah
Aplikasi default dx new berubah menjadi bentuk yang lebih dekat dengan create-react-app
- Mencakup assets, CSS, dan konfigurasi deployment dasar
- Mencakup link resource berguna seperti dioxus-std, VSCode Extension, dokumentasi, dan tutorial

Dioxus Community dan ekosistem

Dioxus Community memperbarui crate ekosistem penting untuk rilis 0.5
Crate seperti icons, charts, dan standard library khusus Dioxus disiapkan agar dapat langsung digunakan saat 0.5 dirilis
Proyek Dioxus Community adalah organisasi GitHub baru untuk menjaga crate penting tetap mutakhir meski maintainer asli mundur
Jika membuat library untuk Dioxus, pihak Dioxus dapat membantu pemeliharaannya dan menargetkan dukungan yang secara praktis setara “Tier 2”

Fitur yang direncanakan ke depan

Rencana setelah 0.5 mencakup hal-hal berikut
- Stabilisasi sistem aset dan integrasi yang lebih mendalam
- Bundle splitting langsung output .wasm bersama lazy component
- Islands dan resumable interactivity, serialisasi Signal
- Penggabungan Server component dan LiveView ke Fullstack
- Devtools dan framework testing yang ditingkatkan
- Perombakan penuh Mobile
- Perombakan Fullstack yang mencakup WebSocket, SSE, progressive form, dan lainnya

Pratinjau Dioxus-Blitz berbasis Servo

Pada “Blitz 2.0” dari Dioxus-Blitz, tujuannya adalah mengintegrasikan Servo untuk rendering native WGPU dengan engine CSS yang sama seperti yang menjalankan Firefox
Nico Burns, pembuat Taffy layout library, bergabung penuh waktu untuk mendorong pekerjaan ini
Dalam demo, google.com di-render di GPU pada 900 FPS
Implementasi saat ini belum lengkap dan rendering google.com masih agak janggal, tetapi dengan cepat mendekati tingkat yang dapat digunakan
Repositorinya dapat dilihat di https://github.com/jkelleyrtp/stylo-dioxus

Cara berkontribusi

Proyek Dioxus menginginkan kontribusi berikut
- Menerjemahkan dokumentasi
- Mencoba “Good First Issues”
- Memperbaiki dokumentasi
- Berkontribusi ke CLI
- Menjawab pertanyaan komunitas Discord
Tim Dioxus berterima kasih atas dukungan komunitas selama sisa tahun 2024 dan meminta bantuan untuk mengubah pengembangan aplikasi

1 komentar

GN⁺ 2024-03-29

Opini Hacker News

Tahun lalu saya membuat klien Mastodon Ebou dengan Dioxus; secara keseluruhan pengalamannya bagus, tetapi banyak hal yang masih kurang.
Saat mulai mengerjakannya, versinya 0.2, dan dengan perubahan di 0.5 ini, hampir semua kerumitan yang saya alami saat itu tampaknya sudah hilang. Saya belum mencobanya langsung, tetapi penghapusan lifetime dan berkurangnya beban untuk terus-menerus melakukan clone sepertinya akan membuatnya jauh lebih nyaman.
- Saya penasaran bagaimana Anda memilih Dioxus.
  Ada cukup banyak framework Rust untuk membuat UI reaktif native yang bisa di-deploy ke desktop, web/wasm, mobile, dan lain-lain https://github.com/flosse/rust-web-framework-comparison, jadi saya khawatir kalau salah pilih, kita harus memelihara framework yang terbengkalai atau melakukan migrasi yang menyakitkan.
  Framework server HTTP Rust juga dulu sama banyaknya, tetapi sekarang Axum, Actix, dan Rocket tampak berada di depan, dan arus komunitas sepertinya bergeser ke Axum, sampai-sampai saya bertanya-tanya apakah memilih Actix adalah kesalahan. Saya penasaran apakah ada sinyal bahwa Dioxus akan menang, atau indikator selain komunitas besar, dukungan YC, dan momentum yang membuatnya layak dipilih sekarang.
  Saya juga ingin tahu apakah Leptos dan Yew juga pesaing utama, serta apa alasan keduanya lebih baik atau lebih buruk daripada Dioxus. Perusahaan kami sudah banyak berinvestasi pada Rust, Actix, dan Bevy, dan ke depannya kami ingin menggabungkan framework seperti Bevy dan Dioxus untuk membuat klien desktop dan mobile native.
  Dan saya juga penasaran apakah nama Dioxus berasal dari Deoxys di Pokémon. Logonya terasa seperti itu, tetapi di codebase tidak ada referensi Pokémon.
Saya setuju dengan ungkapan “secara keseluruhan bagus, tetapi banyak yang kurang.”
Sekitar 9 bulan lalu saya membuat frontend GUI untuk sshfs dengan Dioxus, dan sampai sebelum menabrak dinding berupa fitur yang belum diselesaikan pengembangnya, kesannya benar-benar seperti framework GUI yang hebat.
Berbagi state antar-konteks yang berbeda juga kadang menyakitkan, tetapi semua framework GUI yang pernah saya pakai seperti itu, apa pun bahasa atau teknologi dasarnya. Dioxus 0.5 terlihat seperti kemajuan besar dalam hal ini. Blog saya merender sebagian besar HTML dengan Dioxus, dan karena bukan penggunaan yang mendorongnya sampai batas, semuanya berjalan sangat baik.
Saya mengikuti Dioxus dengan minat, tetapi belum sempat mencobanya.
Namun solusi penghapusan lifetime ini agak membuat saya bingung. generational-box terasa seperti semacam garbage collector versi sederhana, dan saya penasaran bagaimana dampaknya terhadap performa.
Selain itu, tautan [generational-box]([https://crates.io/crates/generational-box](<https://crates.io/crates/generational-box>;)) rusak.
- Memang benar itu garbage collector versi sederhana, tetapi semantik memorinya persis sama dengan versi sebelumnya.
  Karena use_hook memiliki nilai selama lifetime komponen, saat komponen menghilang nilai itu juga di-drop. Semua signal masih memakai use_hook, jadi lifetime-nya juga sama. Memanggil GenerationalBox::new() di luar use_hook biasanya tidak disarankan, sehingga tidak ada dampak performa.
  Jika Anda membanjiri loop dengan GenerationalBox::new(), sampah itu akan tetap ada sampai komponennya di-drop, tetapi kebanyakan orang akan melakukan push/pop pada Map atau Vec, dan dalam kasus itu semantik memori biasa berlaku.
- Ini pada dasarnya adalah automatic reference counting: https://en.wikipedia.org/wiki/Automatic_Reference_Counting
Saya bukan programmer Rust, tetapi penasaran bagaimana crate generational-box bekerja.
Saya paham ini semacam alokasi arena, tetapi saya tidak mengerti bagaimana ia mendukung “menyalin tanpa menyalin”, dan mengapa penjelasan bahwa secara internal ia membuat arena RefCell bergenerasi dan GenerationalBox adalah Copy itu aman.
Saya paham bahwa kita bisa membuat pointer ke data statis, tetapi bagaimana jika nilainya tidak memiliki lifetime statis?
- Yang disalin bukan datanya, melainkan referensi ke data.
  Referensi data dipertahankan selama lifetime program. generational box memungkinkan Anda memasukkan data yang hidup lebih pendek daripada lifetime program, tetapi data itu tidak boleh memuat referensi. Saat data yang dimasukkan di-drop, box tersebut digunakan kembali untuk alokasi lain.
  Pendekatannya sangat mirip dengan arena bergenerasi, kecuali ia memakai box alih-alih arena terpusat; itu dipilih untuk menghindari masalah locking. Jika Anda mencoba mengakses data melalui referensi Copy setelah di-drop, operasi itu gagal dengan pesan error yang bagus.
- Saya tidak terlalu tahu crate ini, tetapi dari sudut pandang Rust, Copy punya makna tertentu.
  Jika suatu tipe mengimplementasikan trait Copy, artinya tipe itu bisa disalin dengan memcpy, dan itu lebih dekat ke shallow copy daripada deep copy.
  Jadi saya memahaminya bukan sebagai “menyalin tanpa menyalin”, melainkan membuat tipe yang bukan Copy bisa diperlakukan seperti tipe Copy. README mengatakan konten statis diperlukan, jadi untuk nilai yang tidak memiliki lifetime statis, jawabannya adalah “tidak bisa dilakukan seperti itu.”
Saya sudah mengikutinya cukup lama dan sangat senang rilis ini keluar.
Saya suka Dioxus mengambil banyak unsur yang membuat React sukses, tetapi tetap berinovasi dan merilis dengan cepat di atasnya. Saya menantikan untuk mencoba signals di rilis ini.
Saya berharap alih-alih RSX, ada sesuatu yang lebih dekat ke SwiftUI daripada React/JSX.
Saya mengakui hal baik yang dilakukan React untuk JS dan web, serta kekuatan namanya, tetapi jika pada 2024 kita bisa merancang bahasa atau DSL dari nol, saya tidak berpikir kode “UI reaktif” harus terlihat seperti React.
Bukan berarti SwiftUI sempurna, tetapi kode yang ditulis dengan SwiftUI terasa jauh lebih rapi dan tersegmentasi dibandingkan ketika menulis kode serupa dengan React.

Keuntungan nyata memakai JSX untuk GUI lintas-platform kira-kira hanya bisa memakai ulang library yang sudah ada untuk web, sedangkan RSX tampaknya tidak punya banyak “nilai yang bisa dipindahkan” selain bahwa developer bisa memindahkan pengetahuan konsep JSX mereka ke RSX. Rasanya kompromi yang lebih baik justru mempelajari paradigma baru yang secara objektif dianggap lebih baik daripada paradigma React/JSX
Singkatnya, akan bagus kalau ada proyek yang “seperti SwiftUI tetapi lintas-platform”, tapi sejauh ini belum ada. Saya tahu @Tokamak/TokamakUI, tetapi tampaknya masih sangat belum matang dan aktivitasnya juga menurun

Ada https://ribir.org/
Saat ini hanya mendukung aplikasi desktop native untuk Linux/mac/windows, tetapi ada rencana mendukung WASM, web, dan mobile
Saya memilih Dioxus untuk membuat beranda terdesentralisasi Freenet
Ini nantinya akan menjadi situs web terdesentralisasi pertama yang dilihat orang setelah menyiapkan Freenet. Sedikit mirip juga dengan Kweb, framework web Kotlin yang saya kerjakan sesekali selama beberapa tahun, terutama dalam hal penanganan state dan pendekatan DSL yang memetakan kode ke HTML. Sejauh ini saya menyukainya
https://freenet.org/
https://kweb.io/
- Keren. Sepertinya saya melihat kweb ketika pertama kali merancang DSL, dan keduanya memang sangat mirip
  Sebenarnya saya penggemar Kotlin, dan saya suka DSL Kotlin serta model konkurensinya
Penasaran bagaimana dibandingkan dengan Tauri
- Saya sudah menuliskannya di README: https://github.com/dioxusLabs/dioxus/?tab=readme-ov-file#dioxus-vs-tauri
  Tauri memasukkan frontend ke dalam webview, dan harus berkomunikasi dengan fungsi Rust native melalui batas IPC, seperti Electron
  Di Dioxus, kode Rust berada di sisi native, jadi operasi seperti membaca file system atau websocket tidak memerlukan IPC. Tauri memaksa frontend dikompilasi ke WASM, dan banyak crate Rust menarik yang tidak bisa dikompilasi ke wasm
  Sulit diungkapkan dengan kata-kata betapa sederhananya pengembangan ketika tidak ada batas IPC. Karena tooling Dioxus hanya menargetkan Rust, Anda bisa pergi dari nol ke .app yang sudah dibundel dalam waktu kurang dari 1 menit. Build baru sekitar 12 detik, bundle baru sekitar 20 detik
  Meski begitu, saya sangat menyukai fleksibilitas yang diberikan Tauri, yaitu bisa memakai apa pun sebagai frontend selama UI-nya kompatibel dengan web, dan Dioxus juga bisa dipakai di dalam aplikasi Tauri
- Saya juga masuk untuk menanyakan hal ini
  Bagus bahwa Dioxus membahasnya langsung di README, tetapi saya juga penasaran dengan pengalaman nyata dari orang-orang yang sudah memakai keduanya
  Saya pernah membuat aplikasi desktop mainan dengan Tauri, dan saya memastikan apakah IPC cukup cepat sehingga frontend web bisa memperbarui dan bekerja di setiap input tombol tanpa lag; jawabannya “ya”. Apakah file besar bisa dikirim dari frontend ke layer Rust lalu dikembalikan ke frontend di setiap input tombol, setidaknya dengan implementasi naif saya, jawabannya “tidak”
  Baik Tauri maupun Dioxus punya banyak use case yang bagus, dan untuk beberapa kasus Dioxus sepertinya lebih baik. Saya ingin mendengar kisah perbandingan seperti “di proyek kami, kami memilih Dioxus atau Tauri karena X dan Y”. Dioxus terlihat sangat keren, jadi saya menantikan untuk mencobanya
Penasaran bagaimana aplikasi native dirender. Apakah masih berjalan di dalam semacam instance browser?
- Bisa memakai webview sistem sebagai renderer, atau memilih engine eksperimental berbasis WGPU yang membawa stylo
  stylo adalah bagian dari Servo yang dibagikan dengan Firefox. Dalam jangka panjang kami ingin memindahkan orang ke renderer WGPU, tetapi itu masih cukup tahap awal, dan banyak perusahaan yang memakai Dioxus secara realistis tahu bahwa webview adalah solusi yang cukup bagus untuk sekitar 90% aplikasi
Pada bagian “selama siklus rilis 0.5, kami berencana menghapus sisa unsafe yang sangat kecil di beberapa dependensi”, saya ingin melihat di mana penggunaannya dan apa motivasinya
Saya mengerti orang kadang memakai unsafe terlalu mudah, tetapi standard library juga penuh dengan unsafe, dan menarik garis di sana kadang terasa seperti menarik garis di atas pasir
- Sebagian besar diperlukan untuk berinteraksi dengan FFI atau mendeklarasikan beberapa tipe sebagai Send/Sync
  Dipakai di tiga tempat. Perbaikan beberapa FFI di iOS, implementasi untuk memungkinkan sintaks pemanggilan fungsi pada signal, dan bagian yang mengimplementasikan Send/Sync untuk ID yang memakai pointer sebagai hash
  Untuk yang terakhir, setelah dilihat lagi sepertinya mungkin bisa dihapus dengan menggantinya memakai usize
- Saya setuju bahwa orang bisa sedikit terlalu takut pada unsafe
  Meski begitu, bukan berarti buruk jika pembuat crate menargetkan penghapusan unsafe dari crate-nya sendiri
  Pembuat crate yang berusaha menghapus semua unsafe sering kali mencoba mengurangi beban kepercayaan yang harus ditanggung pengguna. Saya melihat ini sebagai kekuatan keyword unsafe. Sebenarnya mungkin seharusnya dipisah menjadi blok trust_me dan fungsi check_yourself
  unsafe membatasi percakapan tentang keamanan memori ke lokasi yang sangat sempit dan bisa diaudit dalam kode, sekaligus menciptakan percakapan baru tentang kepercayaan yang dapat dikelola
Saya paham mengapa React membuat konvensi penamaan use* untuk API hook, tetapi saya penasaran mengapa fungsi untuk membuat signal baru di Dioxus bernama use_signal
let mut count = use_signal(|| 0); itu panggilan untuk membuat signal baru, bukan? Signal tidak dibuat ulang di setiap render, dan itulah inti dari signal
Di SolidJS, signal dibuat dengan createSignal seperti const [count, setCount] = createSignal(0), dan ini jauh lebih mudah dipahami
Nama API itu penting. Karena hook state berperilaku berbeda dan bisa memunculkan kebutuhan pelengkap seperti useMemo. Saya penasaran apakah ada alasan Dioxus memilih nama use_signal selain ingin terlihat dekat dengan React
- Dioxus masih me-render ulang komponen, tetapi menerapkan banyak optimasi pada rsx yang dibuat komponen sehingga performanya mendekati Solid
  Lebih dekat ke Preact daripada Solid
  Optimisasinya mencakup memisahkan potongan dinamis UI ke “diff bin” terpisah, memoization bawaan, dan signal yang secara implisit menandai properti sebagai dirty/managed