ElementaryUI: Swift Artık Tarayıcıda — WebAssembly Rehberi

Swift artık yalnızca sunucu tarafında çalışan bir dil değil: WebAssembly derlemesiyle tarayıcıda da çalışıyor. Swift 6.4, 15 Eylül 2026'da yayınlandı; resmi Wasm SDK swift.org üzerinden doğrudan dağıtılıyor ve JavaScriptKit üzerinden JavaScript köprüleme performansı bu sürümde önemli ölçüde hızlandı. ElementaryUI, bu altyapının üzerine SwiftUI'ye benzer, state-driven bir arayüz katmanı kuran kütüphanelerden biri. Bu rehberde full-stack Swift'in tarayıcı tarafını — Embedded Swift'ten Cloudflare Worker demosuna kadar — adım adım geziyoruz.

💡 Pro Tip: ElementaryUI ile sunucu-taraflı Elementary kütüphanesini karıştırma — ikisi aynı yazarın farklı projeleri; biri HTML üretir, diğeri tarayıcıda state yönetir. Bu makalede ikisini net ayırıyoruz.

İçindekiler

• Full-stack Swift'in eksik yarısı: tarayıcı
• Neden şimdi önemli
• Elementary (sunucuda HTML) vs ElementaryUI (tarayıcıda state-driven)
• ElementaryUI'nin vaat ettiği API yüzeyi
• Embedded Swift + swift-wasm zinciri nasıl kuruluyor
• İki SDK varyantı
• Neden iki ayrı SDK gerekiyor
• Cloudflare Worker demosunu adım adım çalıştırma
• WASM binary boyutu ve ilk yükleme maliyeti
• Vapor/Hummingbird ile sunucu tarafını bağlamak
• Dürüst değerlendirme: Eylül 2026 itibarıyla ne için kullanılır, ne için kullanılmaz
• SSS
• Swift tarayıcıda çalışır mı?
• ElementaryUI nedir, Elementary'den farkı ne?
• Swift WebAssembly binary boyutu ne kadar?
• Full-stack Swift bugün production'a hazır mı?
• Sonuç
• Kaynaklar

Full-stack Swift'in eksik yarısı: tarayıcı

Swift ekosisteminde sunucu tarafı (Vapor, Hummingbird) uzun süredir olgun; iOS/macOS tarafı zaten Swift'in ana vatanı. Eksik olan parça tarayıcıydı. swift.org'un 4 Eylül 2026 tarihli "What's new in Swift: August 2026 Edition" dijestinde bu boşluk açıkça tarif ediliyor: topluluk, yıllar süren swift-wasm projesi sayesinde Swift'i WebAssembly'ye derlemeyi giderek daha uygulanabilir hale getirdi. Bu birikim, önce sunucu-taraflı HTML render kütüphanesi Elementary'nin doğuşuna, ardından tarayıcıda çalışan ElementaryUI'nin ortaya çıkışına zemin hazırladı.

Bunu bir iOS geliştiricisi gözünden düşünürsen fark daha net görünür: SwiftUI ile arayüz yazmayı, Vapor ile de bir API yazmayı biliyorsun — ama ikisi arasında hâlâ bir dil sınırı vardı, çünkü tarayıcıda çalışan gerçek arayüz katmanı JavaScript'in tekelindeydi. ElementaryUI'nin iddiası tam olarak bu sınırı kaldırmak: aynı @State mantığıyla düşündüğün bir bileşeni artık tarayıcıda WebAssembly üzerinden çalıştırabiliyorsun.

Bu gelişme, Swift 6.0'ın getirdiği concurrency temelinin üzerine kurulu bir sonraki katman gibi düşünülebilir: dil önce eşzamanlılığı, sonra derleme hedeflerini genişletti. Server-side Swift'i zaten Vapor ile backend API kurarak veya genel server-side Swift ekosistemini inceleyerek biliyorsan, tarayıcı tarafı bu resmin eksik yarısını tamamlıyor: artık aynı dilde hem sunucuyu hem istemciyi yazabiliyorsun.

Neden şimdi önemli

Bu konunun 2026 sonunda gündeme gelmesinin somut bir nedeni var: Swift 6.4'ün resmi Wasm SDK dağıtımı ve JavaScriptKit hızlanması, deneysel bir topluluk projesini üretime daha yakın bir noktaya taşıdı. Ama bunu abartmamak gerekiyor — ilerideki bölümlerde göreceğin gibi, ekosistem hâlâ genç.

Elementary (sunucuda HTML) vs ElementaryUI (tarayıcıda state-driven)

Bu ikisini karıştırmak kolay çünkü isimleri neredeyse aynı ve aynı geliştiriciye (Simon Leeb) ait. Ama hedefleri tamamen farklı:

Bu ayrım, Elementary'nin kendi README'sinin girişinde ve hemen altındaki notta şöyle özetleniyor: "Elementary sunucu-taraflı render için inşa edildi" ve "Swift uygulamalarını tarayıcıda çalıştırmak için ElementaryUI'ye bak." Yani bir projeyi diğerinin yerine geçiyor sanmak — ya da GitHub'daki elementary reposunu ElementaryUI zannetmek — teknik bir hata olur. Aynı ayrımı Simon Leeb, swift.org dijestindeki konuk yazısında birebir şöyle koyuyor: "Elementary sunucuda HTML render ederken, ElementaryUI tarayıcının içinde çalışır."

ElementaryUI'nin vaat ettiği API yüzeyi

elementary.codes'un ana sayfasında SwiftUI'ye aşina geliştiricileri hedefleyen deklaratif bir sözdizimi örneği yer alıyor:

1// elementary.codes ana sayfasındaki tanıtım örneği
2@View
3struct LoveCounter {
4    @State var count = 1
5 
6    var body: some View {
7        p { String(repeating: "❤️", count: count) }
8 
9        if count < 10 {
10            button { "More Love" }
11                .onClick { count += 1 }
12        } else {
13            p { "Enough love for you!" }
14            button { "Less Love" }
15                .onClick { count = 1 }
16        }
17    }
18}

Bu örnek, ElementaryUI'nin SwiftUI'nin @State/@Environment mantığını tarayıcıya taşıma niyetini gösteriyor. Sitenin vaadi: Embedded Swift desteğiyle "MB yerine kB boyutlu" wasm paketleri üretmek.

Embedded Swift + swift-wasm zinciri nasıl kuruluyor

Wasm desteği bir gecede gelmedi. swift.org dijestinde anlatıldığı gibi, önce topluluğun swift-wasm projesi Swift'i WebAssembly'ye derlemeyi giderek uygulanabilir hale getirdi; Embedded Swift ise bu zincire deneysel adımlarla katıldı. Resmi SDK dağıtımı ise Swift 6.2'den itibaren mevcut: "Swift 6.2 ve development snapshot'larla Wasm modüllerini kolayca cross-compile edip çalıştırabilirsin."

Swift 6.4 ile bu resmileşme iki koldan ilerledi:

1. Wasm SDK sürümü toolchain ile birlikte swift.org'dan sağlanıyor — 6.4.0 toolchain'i için eşleşen SDK resmi indirme adresinde hazır (dağıtım 6.2'den beri mevcut).
2. JavaScriptKit üzerinden Wasm↔JS köprüleme, 6.4'te belirgin şekilde hızlandı — swift.org'un kendi ifadesiyle "JavaScriptKit üzerinden WebAssembly köprüleme, 40 kata kadar daha hızlı."

İki SDK varyantı

Resmi dokümantasyon, kurulum sırasında iki farklı SDK paketi sunuyor:

Hangisini seçeceğin, hedefin sunucu-taraflı bir edge worker mı yoksa tarayıcıda çalışan bir arayüz mü olduğuna bağlı; ElementaryUI gibi kütüphaneler küçük binary boyutu için embedded varyantı hedefliyor.

Neden iki ayrı SDK gerekiyor

Bu ayrımın nedeni, Embedded Swift'in kendi tasarım felsefesinde yatıyor: dilin runtime'ını küçültmek için bazı dinamik özellikler (tam reflection, bazı Foundation API'leri) bilinçli olarak dışarıda bırakılıyor. swift.org'un dokümantasyonu bu değişimi açıkça bir "kapsam" tercihi olarak sunuyor — tam Wasm SDK'da hiçbir kısıtlama yok, embedded varyantta ise küçük binary karşılığında bazı standart kütüphane özelliklerinden feragat ediyorsun. Bu nedenle bir projeye başlarken önce hangi runtime kısıtlamalarını kabul edebileceğini netleştirmek, SDK seçiminden önce gelen bir adım.

Kurulum, resmi swift.org dokümantasyonundaki desene göre şöyle çalışıyor (aşağıdaki checksum 6.4.0 sürümüne ait; yeni sürümlerde swift.org sayfasındaki güncel değeri kullan):

1# Resmi Wasm SDK kurulumu (swift.org dokümantasyonundaki komut)
2swift sdk install \
3  https://download.swift.org/swift-6.4.0-release/wasm-sdk/swift-6.4.0-RELEASE/swift-6.4.0-RELEASE_wasm.artifactbundle.tar.gz \
4  --checksum f07b7be3c586d92d7a07051fc6d303b87ebea67eadc40640ba59d5a8b79aa86d

Bu komut, Swift toolchain'ine bir cross-compilation hedefi ekler; kurulumdan sonra swift sdk list çıktısındaki SDK ID'sini alıp swift build --swift-sdk swift-6.4.0-RELEASE_wasm biçiminde derleme yaparsın. Embedded varyant için -embedded son ekli ID'yi (swift-6.4.0-RELEASE_wasm-embedded) kullanırsın.

Async/Await ile Swift concurrency temelini zaten biliyorsan, bu derleme zincirinin üstüne oturan kod tarafında yabancılık çekmezsin — tarayıcıda değişen esas olarak runtime hedefi, dilin kendisi değil.

Cloudflare Worker demosunu adım adım çalıştırma

En somut kanıt, ElementaryUI'nin yaratıcısı Simon Leeb'in 25 Ağustos 2026'da Swift Forums'da paylaştığı "Edge of Tomorrow: Full-Stack Swift on Both Sides of Fetch" başlıklı demo. Bu yazı, Swift 6.4'ün resmi çıkışından önceki bir topluluk ön-izlemesiydi — yazar o sırada "Swift 6.4 henüz çıkmadı" diye not düşmüştü. Demonun başlıca bileşenleri şunlar:

• ElementaryUI (frontend): Tarayıcıda çalışan, WebAssembly'ye derlenen arayüz katmanı.
• BridgeJS: JavaScriptKit tabanlı Wasm↔JS interop katmanı; frontend'deki Fetch API networking'i de bu katman üzerinden yürüyor.
• NewCodable (deneysel): Frontend ve backend arasında paylaşılan Swift veri tiplerini kodlamak için.
• Cloudflare Worker (edge backend): Swift mantığının Wasm'a derlenip edge'de çalıştırıldığı sunucu tarafı; Cloudflare fetch handler'ı olarak koşuyor.

Demoyu kendi makinende çalıştırmak istersen, kaynak kod deposunun (elementary-swift/example-cloudflare-worker) README'sindeki "Run locally" bölümü Swiftly ve Node.js 24+ ile dört komuttan oluşuyor:

1# example-cloudflare-worker README, "Run locally" adımları
2swiftly install
3swift sdk install \
4  https://download.swift.org/swift-6.4.x-branch/wasm-sdk/swift-6.4.x-DEVELOPMENT-SNAPSHOT-2026-08-14-a/swift-6.4.x-DEVELOPMENT-SNAPSHOT-2026-08-14-a_wasm.artifactbundle.tar.gz \
5  --checksum 11fabfac6804222569d330fbbb5fa34eef736abda46790e723ac73b256fd1c7a
6npm install
7npm run dev

Canlı demoya https://cloudflare-worker.examples.elementary.codes/ adresinden erişebilirsin. Bu, ElementaryUI'nin frontend'i ile Cloudflare Worker'ın edge backend'inin aynı dilde, aynı repo içinde birlikte çalıştığı somut bir örnek.

WASM binary boyutu ve ilk yükleme maliyeti

Binary boyutu, Wasm tabanlı web geliştirmede her zaman ilk soru. ElementaryUI'nin resmi vaadi net: Embedded Swift desteğiyle "MB yerine kB boyutlu wasm paketleri." Ama bu genel bir slogan — somut bir sayı, elementary.codes'un kendi sayfasında verilmiyor.

Elimizdeki tek somut ölçüm, Cloudflare Worker demosundan geliyor: edge tarafında çalışan wasm fetch handler'ı yaklaşık 107 kB. Burada dikkat etmen gereken önemli bir nüans var — bu, edge worker'ın (backend) binary boyutu; ElementaryUI'nin tarayıcıda çalışan frontend bundle'ı için ne elementary.codes ne de forum yazısı ayrı bir sayı veriyor. Yani "her ElementaryUI uygulaması X kB'dir" gibi bir genelleme yapmak yanlış olur — 107 kB, tek bir gerçek demonun edge tarafına ait somut bir örnek.

Pratik sonucu: kB mertebesindeki binary'ler, geleneksel "Swift'i tarayıcıya taşırsan MB'larca indirme olur" endişesini önemli ölçüde azaltıyor — ama üretim öncesi kendi projenin gerçek bundle boyutunu ölçmek hâlâ senin sorumluluğun.

İlk yükleme maliyetini değerlendirirken tek başına binary boyutuna bakmak da yeterli değil; Wasm modülünün tarayıcıda derlenip (compile) çalıştırılabilir hale gelmesi (instantiate) ayrı bir maliyet kalemidir. swift.org dokümantasyonu da elementary.codes da bu iki aşamayı (indirme ve derleme) ayrı ayrı ölçmediği için, kendi projende hem ağ sekmesinden indirme süresini hem de Performance panelinden Wasm derleme/instantiate süresini ayrı ayrı gözlemlemen, "kB boyutunda = anında yüklenir" varsayımına düşmemen açısından önemli.

Vapor/Hummingbird ile sunucu tarafını bağlamak

Full-stack bir Swift uygulamasında ElementaryUI tek başına yeterli değil — sunucu tarafını da bağlaman gerekiyor. Elementary'nin resmi deposu bunun için iki köprü paket sunuyor:

• hummingbird-community/hummingbird-elementary (from: "0.3.0") — Hummingbird ile Elementary'yi entegre eder.
• vapor-community/vapor-elementary (from: "0.1.0") — Vapor ile Elementary'yi entegre eder.

1// Package.swift — Elementary'nin resmi README'sindeki paket referansları
2dependencies: [
3    .package(url: "https://github.com/elementary-swift/elementary.git", from: "0.6.0")
4    // Sunucu framework'üne göre birini ekle:
5    // .package(url: "https://github.com/hummingbird-community/hummingbird-elementary.git", from: "0.3.0")
6    // .package(url: "https://github.com/vapor-community/vapor-elementary.git", from: "0.1.0")
7]

Cloudflare Worker demosundaki NewCodable (deneysel) tipleri de burada devreye giriyor: frontend (ElementaryUI/Wasm) ve backend (Vapor/Hummingbird veya edge worker) aynı Swift struct'larını paylaşabiliyor — request/response serileştirmesi için ayrı bir DTO katmanı yazmana gerek kalmıyor. Bu, Vapor ile backend API kurarken alışık olduğun tip-güvenliğini frontend'e kadar uzatan bir yaklaşım.

Aynı repo içinde iki farklı derleme hedefi olduğunu unutmamak gerekiyor: frontend (ElementaryUI) genelde wasm-embedded SDK'ya, sunucu tarafı (Vapor/Hummingbird ile çalışan klasik bir backend) ise normal native toolchain'e derlenir. Cloudflare Worker demosunda ise "backend" bile edge'de Wasm olarak çalışıyor; orada hem frontend hem edge worker Embedded SDK ile derleniyor — vite.config.ts tek ayarla ikisini kapsıyor (swiftWasm({ useEmbeddedSDK: true })), forum yazısı da "builds Embedded Swift WebAssembly with 6.4.x and swift-build" diyor. Yani orada iki SDK varyantı değil, tek repoda iki Wasm hedefi var: Package.swift'teki WebApp ve Worker target'ları. SDK seçiminin genel deseni şöyle:

1# Hedefe göre SDK seçimi — genel desen (ID'ler `swift sdk list` çıktısından)
2# Not: Cloudflare Worker demosu her iki hedefte de embedded SDK kullanır.
3swift build --swift-sdk swift-6.4.0-RELEASE_wasm          # tam standart kütüphane gerektiren hedef için
4swift build --swift-sdk swift-6.4.0-RELEASE_wasm-embedded # ElementaryUI frontend için, küçük binary

Bu iki komut, resmi dokümantasyonun tarif ettiği "hedefe göre SDK seç" prensibinin pratikte nasıl göründüğünü özetliyor — birini frontend'in boyut kısıtı, diğerini backend'in tam kütüphane ihtiyacı belirliyor.

Dürüst değerlendirme: Eylül 2026 itibarıyla ne için kullanılır, ne için kullanılmaz

Burada abartıya kaçmamak önemli. Resmi dokümantasyon ve Simon Leeb'in ifadeleri şu tabloyu çiziyor:

Eylül 2026 itibarıyla ne için makul:

• Kişisel projeler, demolar, konferans sunumları (FOSDEM 2026'da bizzat anlatıldı).
• Cloudflare Workers gibi edge ortamlarında küçük, izole Swift servisleri.
• Aynı ekipte hem backend hem frontend'i Swift'te tutmak isteyen deneysel/araştırma projeleri.

Eylül 2026 itibarıyla henüz erken:

• Kritik, yüksek trafikli production frontend'ler. Demoyu paylaşan geliştiricinin kendi ifadesiyle, NewCodable hâlâ deneysel ve Embedded Swift kullanırken "hâlâ birtakım kullanılabilirlik tuhaflıkları" var.
• React/Vue/Svelte gibi olgun ekosistemlerin sunduğu geniş kütüphane/araç desteğini bekleyen ekipler.
• ElementaryUI'nin kendisi de genç bir proje — swift.org dijestinde "ElementaryUI hâlâ genç, inşa edilecek çok şey var" diye özetleniyor.

Swift 6.4'ün resmi Wasm SDK'sı ve JavaScriptKit hızlanması önemli bir olgunluk adımı — ama bu, "production'a hazır" demek değil. Doğru çerçeve: hızla olgunlaşan, deneysel parçaları olan bir ekosistem. Swift Concurrency ve Actors'ı production'da kullanmaya nasıl aşamalı geçtiysen, ElementaryUI'ye de benzer bir temkinle yaklaşmak mantıklı.

Kararını netleştirmek için şu tabloyu kullanabilirsin:

Bu tablo mutlak bir kural değil; Simon Leeb'in forumdaki ifadelerinin ve projelerin resmi statüsünün bir özeti — kendi risk toleransına göre yorumlaman gerekiyor.

SSS

Swift tarayıcıda çalışır mı?

Evet, WebAssembly derlemesiyle. Swift 6.4 itibarıyla (15 Eylül 2026'da yayınlandı) resmi bir Wasm SDK swift.org üzerinden doğrudan dağıtılıyor ve JavaScriptKit üzerinden JS köprüleme performansı bu sürümde belirgin şekilde hızlandı. ElementaryUI gibi kütüphaneler bu altyapının üzerine SwiftUI-benzeri bir deklaratif API inşa ediyor.

ElementaryUI nedir, Elementary'den farkı ne?

İkisi de Simon Leeb'e ait ama farklı hedefler için: Elementary sunucu tarafında tip-güvenli HTML üreten, Hummingbird/Vapor ile entegre bir şablonlama kütüphanesi; ElementaryUI ise WebAssembly ile tarayıcıda çalışan, SwiftUI'ye benzer state yönetimine sahip ayrı bir kütüphane. Elementary'nin kendi belgeleri bu ayrımı doğrudan teyit ediyor: "tarayıcıda çalıştırmak için ElementaryUI'ye bak."

Swift WebAssembly binary boyutu ne kadar?

Kesin bir genel sayı yok. Somut tek örnek, Cloudflare Worker demosundaki edge tarafı wasm fetch handler'ının yaklaşık 107 kB olması. ElementaryUI resmi olarak Embedded Swift sayesinde "MB yerine kB boyutlu" paketler vaat ediyor ama kendi sitesinde ayrı bir sayı vermiyor; kendi projende ölçmen gerekiyor.

Full-stack Swift bugün production'a hazır mı?

Henüz tam değil. Demoyu paylaşan geliştiricinin kendi ifadesiyle NewCodable deneysel ve Embedded Swift'te hâlâ kullanılabilirlik tuhaflıkları var. Swift 6.4'ün resmi Wasm SDK'sı önemli bir olgunluk adımı ama "production-ready" ilanı resmi kaynaklarda yok — hızla olgunlaşan, deneysel parçaları olan bir ekosistem olarak değerlendirmek daha doğru. Kritik bir üretim sistemine geçmeden önce küçük, izole bir modülde (örneğin tek bir edge endpoint veya iç araç) deneyip riski sınırlı tutman, kaynaklardaki genel tona en uygun yaklaşım.

Sonuç

Swift'in tarayıcı tarafı artık soyut bir vaat değil: Swift 6.4'ün resmi Wasm SDK'sı, JavaScriptKit'in hızlanan köprülemesi ve ElementaryUI gibi kütüphaneler, full-stack Swift'in eksik yarısını somut hale getirdi. Ama bu ekosistemi değerlendirirken iki şeyi ayrı tutman gerekiyor: bir yanda Elementary'nin (sunucu) ve ElementaryUI'nin (tarayıcı) birbirinden farklı projeler olduğu gerçeği, diğer yanda "resmi SDK var" ile "production-ready" arasındaki fark.

Eğer Swift Vapor ile backend API kurma deneyimin varsa ve server-side Swift ekosistemini zaten takip ediyorsan, ElementaryUI'yi küçük bir yan projede denemek mantıklı bir sonraki adım. Swift 6.2 ve WWDC26 sonrası concurrency yeniliklerini takip ettiysen, bu Wasm zincirinin üstüne oturan kod tarafı sana yabancı gelmeyecek. Swift Structured Concurrency ve Swift Concurrency ve Actors yazılarımız, tarayıcıda da geçerli olan aynı eşzamanlılık modelini derinlemesine anlatıyor.

Kaynaklar

• Swift 6.4 Released — swift.org — Resmi Wasm SDK dağıtımı ve JavaScriptKit hızlanmasının duyurusu.
• What's new in Swift: August 2026 Edition — swift.org — Elementary ve ElementaryUI'nin resmi tanıtımı, swift-wasm tarihçesi (4 Eylül 2026).
• Edge of Tomorrow: Full-Stack Swift on Both Sides of Fetch — Swift Forums — Cloudflare Worker demosunun orijinal duyurusu (Simon Leeb, 25 Ağustos 2026).
• ElementaryUI — elementary.codes — Tarayıcıda çalışan Swift arayüz kütüphanesinin resmi tanıtım sayfası.
• Elementary — GitHub README — Sunucu-taraflı HTML render kütüphanesi, Vapor/Hummingbird entegrasyon paketleri.
• ElementaryUI — GitHub README — ElementaryUI'nin kendi kod deposu (elementary reposuyla karıştırılmaması gereken adres).
• Wasm SDK Kurulum Dokümantasyonu — swift.org — Resmi swift sdk install komutu ve SDK varyantları.