- Web uygulamaları ve TypeScript koduyla oluşturulan Deno projeleri, platforma özgü yeniden dağıtılabilir masaüstü uygulama ikilileri olarak paketlenebiliyor
- Çıktı; uygulama kodunu, Deno runtime'ını ve web render motorunu birlikte içeriyor; Deno v2.9.0'a eklendi ancak henüz kararlı sürüm değil
- Varsayılan WebView backend'i, küçük ikilileri hedeflemek için işletim sisteminin yerleşik webview'ini kullanıyor; render tutarlılığı gerekiyorsa Chromium(CEF) backend'i seçilebiliyor
- Next.js, Astro, Fresh, Remix, Nuxt, SvelteKit, SolidStart, TanStack Start ve Vite SSR projelerini algılayarak release modu ile
--hmr geliştirme moduna uygun şekilde sunucuyu çalıştırıyor
- Deno kodu ile webview arasındaki iletişimde soket tabanlı IPC yerine in-process kanallar kullanılıyor; çapraz derleme ve bsdiff tabanlı otomatik güncellemeler de kapsam içinde yer alıyor
deno desktopun rolü ve mevcut durumu
deno desktop, Deno projelerini kendinden içerikli masaüstü uygulamalarına dönüştürüyor
- Girdi, tek bir TypeScript dosyasından Next.js uygulamasına kadar değişebiliyor
- Çıktı, platforma özgü yeniden dağıtılabilir bir ikili dosya oluyor
- İkili dosya; uygulama kodunu, Deno runtime'ını ve web render motorunu içeriyor
- Bu özellik Deno v2.9.0 içinde yer alıyor ancak henüz kararlı sürüm değil
- Şu anda denemek için
deno upgrade canary ile canary derlemesini kurmak gerekiyor
- Komutlar, yapılandırma anahtarları ve TypeScript API'si kararlı hale gelene kadar değişebilir
Backend seçimi ve web projelerini çalıştırma
- Web teknolojilerini masaüstü UI araç takımı olarak kullanırken, mevcut web stack tabanlı masaüstü uygulama araçlarının trade-off'larını azaltmayı hedefliyor
- Electron, Tauri ve Electrobun gibi araçlarda büyük ikililer, eksik platform desteği, JavaScript ekosisteminin olmaması, yerleşik güncelleme eksikliği veya framework entegrasyonu eksikliği gibi trade-off'lar olabiliyor
- Varsayılan WebView backend'i, işletim sisteminin webview'ini kullanarak küçük ikilileri hedefliyor
- Deno'nun Node uyumluluk katmanı üzerinden npm ekosistemi kullanılabiliyor
- macOS, Windows ve Linux'ta aynı render sonucu gerekiyorsa paketlenmiş Chromium olan CEF backend'i seçilebiliyor
- Framework otomatik algılama, mevcut web projelerini kod değişikliği olmadan masaüstünde çalıştırma yaklaşımı sunuyor
- Hedefler arasında Next.js, Astro, Fresh, Remix, Nuxt, SvelteKit, SolidStart, TanStack Start ve Vite SSR bulunuyor
- Release modunda production sunucusu çalıştırılıyor
--hmr modunda hot reload destekli geliştirme sunucusu çalıştırılıyor
Runtime iletişimi, derleme ve güncellemeler
- Backend ile UI arasındaki iletişim için in-process kanallar kullanılıyor
- Değerler, çağrı sınırını geçerken encode ediliyor
- Deno kodu ile webview arasında süreçler arası gidiş-geliş bulunmuyor
- Tek bir makineden macOS, Windows ve Linux için çapraz derleme yapılabiliyor
- Backend'ler yerelde derlenmiyor, gerektiğinde indiriliyor
- Otomatik güncelleme,
latest.json manifesti ve bsdiff yamaları kullanan yerleşik ikili fark güncelleme yöntemiyle sağlanıyor
- Runtime; polling, uygulama ve başarısız çalıştırmalar için rollback işlemlerini yönetiyor
Basit örnek ve dokümantasyon yapısı
- Tek dosyalı bir masaüstü uygulaması,
Deno.serve() ile HTML yanıtı döndüren bir main.ts oluşturulup deno desktop main.ts çalıştırılarak yapılabiliyor
Deno.serve(() =>
new Response("Hello, desktop
", {
headers: { "content-type": "text/html" },
})
);
deno desktop main.ts
- Derlenmiş ikili dosya,
Deno.serve() handler'ına bağlanan yerel HTTP sunucusunu işaret eden bir pencere açıyor
- macOS/Linux'ta
./main ile çalıştırılıyor
- Windows'ta
.\main.exe ile çalıştırılıyor
Deno.serve(), webview'in gittiği adrese otomatik olarak bind edildiği için port veya host adı vermek gerekmiyor- İlgili dokümantasyon; yapılandırma, backend'ler, HTTP serving, framework'ler, pencere yönetimi, binding'ler, menü, tray ve dock, diyaloglar, bildirimler, HMR, DevTools, otomatik güncellemeler, hata raporlama, dağıtım, karşılaştırmalar ve CLI referansı olarak ayrılıyor
Deno.BrowserWindow pencere yaşam döngüsü, çoklu pencere ve event'lerle ilgiliDeno.autoUpdate() manifest, bsdiff ve rollback ile ilgilibindings.() webview içinden Deno kodunu çağırmak için kullanılan binding yöntemi
1 yorum
Hacker News yorumları
Deno Desktop bu tür ödünleşimleri oldukça iddialı biçimde belirlemiş gibi görünüyor: “varsayılan küçük, Node uyumluluğu tam”
Yazıdaki 5 satırlık Hello World ile
deno desktop index.tsdenedim; Windows 10'da sonuç 442MB olduElectron derlemesinden daha küçük olur sanmıştım ama çok daha büyük çıkmasına şaşırdım;
libcef.dll247MB, Hello World'ü içerendeno-test.dllise 78MB idiAcaba yanlış yaptığım bir şey mi var diye merak ediyorum
Bu yüzden OS webview gibi bir şeyi yeniden kullanarak 20MB altı bir çözüm çıkmasını umuyordum ama 400MB'ı aşması biraz yanıltıcı hissettiriyor
Ayarı yanlış yapmış olabilirim;
deno desktop test.tsdışında başka bir şey yapmak gerekiyor mu diye merak ediyorum“Her uygulamanın CEF'i ayrı ayrı paketlemesi yerine paylaşılan bir CEF runtime yönetilirse uygulama başına ikili boyutu birkaç MB'a düşebilir ve bu yol haritasında var” kısmı ilginç
CEF'i çok iyi bilmediğim için sürüm yönetiminin nasıl olacağını merak ediyorum
Her uygulamanın ihtiyaç duyduğu CEF sürümü farklıysa sonunda yine Electron'daki gibi her uygulamanın kendi tarayıcısını taşıdığı modele mi dönülüyor, yoksa böyle durumlarda da paylaşılan runtime'ın avantajı kalıyor mu, öğrenmek isterim
https://docs.deno.com/runtime/desktop/comparison/
https://github.com/chromiumembedded/cef
Sonuç çok iyi olmamıştı ama bunun CEF teknolojisinin kendisinden mi yoksa başka bileşenlerden ya da süreçlerden mi kaynaklandığını bilmiyorum
https://www.riotgames.com/en/news/architecture-league-client...
Masaüstündeki Electron uygulamaları fiilen neredeyse tamamen farklı Chromium sürümleri kullanıyor ve yükseltmelerde bozulma riski yüzünden eski sürümlerde kalanlar da var
Windows tarafında bu, WebView2 gibi bir yaklaşım olurdu
Deno etkileyici olmaya devam ediyor
Deno olmadan yeni bir projeye başlayalı epey oldu ve artık Node.js'ten ziyade Deno ekosistemini tamamen destekler hâle geldim
Bu özelliği ne kadar sık kullanırım bilmiyorum ama bir seçeneğin daha ortaya çıkmış olması gerçekten güzel
Etkileyici bir çalışma
vibe coding ile masaüstü uygulamaları yapmak için oldukça ilginç olabilir
Lovable, Bolt, v0 gibi araçlar web uygulamaları oluştururken zaten varsayılan olarak TypeScript kullanıyor; bu yüzden buraya iyi uyuyor gibi görünüyor
Küçük masaüstü uygulamalarında Chromium ve Node paketlemek yerine Go/Wails kullanıyordum; Electron da işini yaptı ama o büyük paketler bende kesin olarak ciddi bir iticilik oluşturuyordu
Deno'nun en büyük güçlü yanlarından biri olan izin sistemiyle bunun nasıl entegre olduğunu merak etmiştim
Özellikle ajanların cihazımda istediği gibi dolaşmasına izin verirken bu önemli
CLI referans belgelerinde “derleme sırasında verilen izinler derlenmiş ikiliye gömülür” deniyor
Kullanıcının hangi izinleri vereceğini bilip karar verebilmesi için bunun görünür kılınması iyi olurdu
https://docs.deno.com/runtime/reference/cli/desktop/#runtime...
Bu durumda Deno izin istemi gösterilirse, o izinlerin bütünlüğü garanti edilmediği için bunun aksine yanlış bir güven duygusu verebileceğini düşünüyorum
Dosya sistemi veya ağ erişiminde izin istemi göstererek Deno izin sistemini masaüstü sandbox'ına uygulayan bir yaklaşım
Yayınlamak için akıllıca bir özellik
Hangi platformu kullanacağıma karar verirken kesinlikle değerlendireceğim bir seçenek gibi görünüyor
küçük kurulum boyutu ve çapraz platform desteğiyle Electron ya da Tauri'ye iyi bir alternatif gibi görünüyor
“Web teknolojileri dünyada en yaygın bilinen UI araç takımıdır” ifadesinin pek uygun olduğunu düşünmüyorum
Electron uygulamalarının çok eleştirilmesinin nedeni, UI araç takımının tam tersine daha yakın olmaları
Çoğu zaman ana işletim sisteminin UI kalıplarını düzgün takip edemiyorlar
Web teknolojileri sadece web teknolojileridir; düğme render edebilirler ama stil verilmemiş bir düğmenin bile OS’in yerel öğeleri gibi görüneceğinin garantisi yoktur ve tarayıcıya göre değişir
Amaç hiçbir zaman sadece “UI araç takımı” ya da “ana işletim sisteminin UI kalıplarını takip etmek” olmadı
Chromium içinde inanılmaz derecede çok özellik barındırıyor ve Electron bu faydayı aynen getiriyor; bu da bir avantaj
Örneğin video işi yaptıysanız, modern bir tarayıcının tüm yeteneklerini masaüstü uygulamasının içinde kullanmanın oyunun kurallarını değiştirdiğini bilirsiniz
Sadece video oynatma değil, modern web ve WebCodecs ile mümkün olan transcoding’i de doğrudan kendiniz uygulamak çok büyük bir iş; Windows/macOS/Linux’ta çalışması gereken bir masaüstü uygulamasıysa daha da zor
Electron ile onlarca saatte yaptığım bir uygulama var; başka bir yaklaşımla muhtemelen onlarca gün sürerdi ve yapay zekayı kullansam bile video uzmanı değilseniz zor olurdu
Hiçbir zaman “native” UI olduğunu iddia etmediler
Linux’un yerel UI’ı bana hep oldukça çirkin görünmüştür; iyi düzenlenmiş bir HTML+CSS layout kullanmanın çok daha iyi olduğunu düşünmüşümdür
Benim deneyimimde Electron daha çok şişkin ve yavaş olduğu için eleştiriliyor; native olmaması ise insanların ayrıca eklediği bir nokta
Uzun zamandır HTML+CSS ile düzen kullanıp JavaScript runtime gerektirmeyen doğrudan bir tarayıcı entegrasyonu yapmak istiyordum
Servo’nun ne kadar hafif olduğunu bilmiyorum ama bir gün böyle bir fikrin gerçeğe dönüşmesi güzel olurdu
Kullanıcı olarak çok memnunum; erişilebilirlik gibi temel özellikler hâlâ eksik olsa da yakında ekleneceğini düşünüyorum
Geliştirici açısından Rust dışında giriş engelinin ne olduğunu pek bilmiyorum; aynı zamanda Rust bunun ayırt edici yanı da
Bu yaklaşık 25 yıl öncesinin konusu; Microsoft bile umursamayı bıraktıktan sonra kimse pek önemsemedi
Uygulamamın farklı işletim sistemlerinde farklı görünmesini istemiyorum
Tüm cihazlarda test edecek kaynağım yok ve bir sistemde test ettiğim ekranın diğer sistemlerde de aynı görünmesi çok büyük avantaj
Bu alanda bir rakip çıkmasına sevindim
Özellikle Deno’nun mevcut Node uygulaması gibi sadece tipleri silmek yerine gerçek TypeScript’i doğrudan çalıştırabilmesi hoşuma gidiyor
Yine de bu, Tauri’nin pazarından epey pay alacak gibi görünüyor
Artık neden Tauri kullanayım ki?
Çoğu internet bağlantısında paket boyutunun 150MB artması indirme süresinde sadece 1-10 saniye fark yaratıyor ve karşılığında güvenilir bir render motoru alıyorsunuz
Tip denetimi yapmak istiyorsanız
deno run --checkile çalıştırmanız veya ayrıdeno checkalt komutunu kullanmanız gerekirGeliştirme sırasında IDE genelde tip denetimini ve linting’i otomatik yaptığı için büyük bir sorun değil
Aslında JavaScript kullanmanız da gerekmiyor
Ayrıca Astro, Nuxt, UV, Bun, Vite gibi geliştirici framework startup’larının birçoğunun satın alındığını gördük
Yıllarca bakım görmesi ve desteklenmesi gereken yazılımlar için bu tür akımlar pek güven vermiyor
Deno Desktop ile Tauri’nin ikisi de sistem webview kullanmıyor mu?
Neden bunu kullanıp Electron kullanmayalım?
Deno’nun yayımladığı materyaller arasında en çok karşılaştırma bölümü hoşuma gitti
Son satırda iOS/Android desteği Electron için “no”, Deno için “not yet” olarak yazıyor; bunu gerçekten başarabilirlerse çok daha büyük olur
Web oyunlarını Steam uygulaması ya da çevrimiçi satın alma uygulaması olarak dağıtmak için gerçekten iyi olabilir
Denemeyi düşünüyorum