Flutter Web'de Wasm 2026: Ne Zaman Açmalı?

Flutter web projelerinde derleme hedefini JavaScript'ten WebAssembly'e çevirmek tek satırlık bir bayrak (--wasm) kadar kolay görünür, ama gerçekte üç ayrı kararı birden verdiğin bir eşiktir: paket ekosistemini package:web'e taşımak, tarayıcı desteğindeki boşlukları kabul etmek ve henüz stabilleşmemiş bir derleme yolunu production'a sokup sokmayacağına karar vermek. Bu yazı "Flutter web wasm kullanmalı mıyım" sorusuna Eylül 2026 itibarıyla resmi Flutter/Dart dokümantasyonuna dayanarak, uydurma benchmark olmadan cevap veriyor.

💡 Pro Tip: --wasm bayrağını CI'a eklemeden önce flutter build web (bayraksız) çalıştır — Flutter otomatik bir "Wasm dry run" yapıp uyumsuz paketleri non-fatal bir uyarıyla önceden gösteriyor.

İçindekiler

• Wasm'ın Flutter Web'deki Mevcut Durumu
• Neden "varsayılan değil, opt-in" önemli
• Denemeye Nereden Başlamalı: Hazır Örnek, index.html ve flutter run
• index.html hazırlığı
• Geliştirme ve test: flutter run --wasm
• --wasm İle Derleme ve Çıktı Farkı
• Fonksiyon adlarını koruma maliyeti
• Gerçekten Wasm'de mi çalışıyor doğrulaması
• dart:html'den package:web'e Göç
• Engelleyen tek kitaplık dart:html değil
• Adım adım göç
• Otomatik dönüşüm ve List uyumsuzluğu
• Element mi, HTMLElement mi?
• Wasm'de değişen çalışma zamanı davranışları
• Geçiş dönemi için koşullu import
• Deneysel Deferred Loading İle Modül Bölme
• Hâlâ olgunlaşma aşamasında
• Otomatik uyumluluk kontrolü
• Tarayıcı Desteği ve Fallback Davranışı
• Fallback otomatik, sessiz ve şeffaf
• Multi-thread render için header gereksinimi
• Bundle Boyutu ve İlk Yükleme Gerçeği
• Kendi verini nasıl üretirsin
• Hangi Projede Aç, Hangisinde Açma
• Ölçüm: Gerçek Chrome Trace ile Önce/Sonra
• SSS
• Flutter web Wasm production'da kullanılabilir mi?
• dart:html yerine package:web'e nasıl geçilir?
• Flutter web Wasm ile ne kadar hızlanıyor?
• Wasm deferred loading nasıl açılır?
• Wasm açtığımda eski tarayıcılarda uygulama çöker mi?
• Sonuç
• Kaynaklar

Wasm'ın Flutter Web'deki Mevcut Durumu

Flutter ekibi, 12 Ağustos 2026 tarihli Flutter 3.47 duyurusunda "Setting course for Wasm by default" başlığını kullanarak hedefi net koydu: WebAssembly'i Flutter web uygulamaları için varsayılan derleme hedefi yapmak. Ancak bu, şu anda varsayılan olduğu anlamına gelmiyor — ekip kendi ifadesiyle "actively working toward enabling WebAssembly (Wasm) by default" diyor, yani hâlâ opt-in aşamasındasın.

Wasm derlemesi için minimum sürüm şartı Flutter 3.24 ve üzeri; 3.47 bunun çok üzerinde olduğu için sürüm engeli pratikte yok. Opt-in derlemeyi şu komutla tetikliyorsun:

1flutter build web --release --wasm

Neden "varsayılan değil, opt-in" önemli

Bir özelliğin resmi blog yazısında "varsayılan yapmaya çalışıyoruz" diye anons edilmesi ile gerçekten varsayılan olması arasındaki fark, production kararını doğrudan etkiler. Wasm hâlâ opt-in olduğu sürece: mevcut CI pipeline'ın JS derlemesiyle çalışmaya devam eder, --wasm eklemek senin bilinçli tercihindir ve geri dönüş tek bir bayrağı silmek kadar basittir.

Denemeye Nereden Başlamalı: Hazır Örnek, index.html ve flutter run

Kendi projende uğraşmadan önce Wasm ile derlenmiş çalışan bir Flutter uygulaması görmek istersen resmi doküman hazır bir tane gösteriyor: Wonderous demo uygulaması Wasm çıktısıyla yayında. Bu demoyu hedeflediğin tarayıcılarda açmak, tarayıcı tarafındaki destek durumunu kendi kodunu hiç değiştirmeden birkaç dakikada gözlemlemeni sağlar.

index.html hazırlığı

Wasm'a geçmeden önce bakman gereken ilk dosya uygulamanın web/index.html'i. Doküman bunu açıkça şart koşuyor: uygulamanın web/index.html'i, Flutter 3.22 ve sonrası için geçerli olan güncel Flutter web uygulaması başlatma (initialization) biçimine güncellenmiş olmalı. Yıllar önce üretilmiş, elle düzenlenmiş bir index.html burada sessiz bir arıza kaynağına dönüşür — uygulama JS'te çalışmaya devam ederken Wasm yolunda takılabilir.

Varsayılan hâli kullanmakta sakınca görmüyorsan doküman kestirme bir yol veriyor: web/ dizininin içeriğini silip yeniden üretmek.

1flutter create . --platforms web

Dikkat: index.html'ine özel bir script etiketi, meta etiketi ya da splash ekranı eklediysen bu komut onları da götürür. Ben genelde bu adımı ayrı bir commit olarak atıp diff'i satır satır gözden geçirmeyi tercih ederim — böylece hangi özelleştirmeyi geri koyman gerektiği ortada kalır.

Geliştirme ve test: flutter run --wasm

--wasm yalnızca build komutuna özel bir bayrak değil. Doküman geliştirme ve test için flutter run ile kullanılmasını da anlatıyor:

1flutter run -d chrome --wasm

Bunun pratik değeri büyük: CI'a --wasm eklemeden haftalar önce günlük geliştirme döngünü Wasm üzerinde çalıştırarak uyumsuzlukları tek tek, sıcağı sıcağına yakalarsın. Ekip içinde "Wasm'ı deneyelim" kararının ilk adımı CI değil, bir geliştiricinin flutter run -d chrome --wasm ile bir hafta çalışması olmalı.

Çıktı tarafında sürpriz yok: flutter build web --wasm komutu da tıpkı flutter build web gibi paket kökünün altındaki build/web dizinine üretiyor. Yani dağıtım script'lerinde, CI artifact yollarında veya CDN yükleme adımlarında bir yol değişikliği yapman gerekmiyor.

--wasm İle Derleme ve Çıktı Farkı

--wasm bayrağı eklediğinde çıktı dizini tek bir JS bundle yerine bir dizi .wasm + destekleyici JS dosyasından oluşur. Bu ikili çıktı, tarayıcı WasmGC desteklemiyorsa devreye giren otomatik JavaScript fallback'i mümkün kılar:

"Even with the --wasm flag, Flutter will still compile the application to JavaScript. If WasmGC support is not detected at runtime, the JavaScript output is used so the application will continue to work in all major browsers."

Yani --wasm derlemesi tek çıktı değil, iki çıktı üretir: Wasm yolu ve JS yedek yolu. Kullanıcı tarayıcısı hangisini destekliyorsa o çalışır.

Fonksiyon adlarını koruma maliyeti

Wasm release build'leri varsayılan olarak debug sembollerini siliyor ve source map üretmiyor. Resmi dokümantasyon iki ayrı yol öneriyor: hata izleme servislerinde sembolizasyon için --source-maps (production'da önerilen), konsolda okunabilir fonksiyon adları için --no-strip-wasm (staging/QA). İkincisinin somut bir bedeli var — Wasm binary boyutunu yaklaşık %47 artırıyor:

1flutter build web --wasm --source-maps
2flutter build web --release --wasm --no-strip-wasm

Bu tek başına, "her ortamda --no-strip-wasm açık dursun" kararının neden yanlış olduğunu gösteriyor: staging'de aç, production'da --source-maps tarafına geç.

Gerçekten Wasm'de mi çalışıyor doğrulaması

Derlemenin gerçekten Wasm'e gittiğini teyit etmek için dart2wasm environment değişkenini kontrol edebilirsin — Flutter ekibinin önerdiği yöntem bu:

1const bool runningOnWasm =
2    bool.fromEnvironment('dart.tool.dart2wasm');

Doküman bu yolu "preferred" diye işaretliyor. Alternatif bir yol daha tarif ediyor: native (Wasm) sayı temsilinin kullanılıp kullanılmadığını sayı temsillerindeki farklardan test etmek.

1final isRunningWithWasm = identical(double.nan, double.nan);

İkisi arasındaki fark yalnızca stil değil. Birincisi derleme zamanı sabiti olduğu için const bağlamlarında kullanılabiliyor ve ölü kod eleme (tree shaking) buna bakarak dalları budayabiliyor; ikincisi çalışma zamanında hesaplanan bir final, dolayısıyla const isteyen bir yere koyamazsın. Bayrağı sadece loglamak için değil, kod yollarını ayırmak için kullanacaksan bool.fromEnvironment tarafında kal.

dart:html'den package:web'e Göç

Wasm derlemesinin önündeki en büyük pratik engel performans değil, kod tabanının dart:html bağımlılığı. Dart'ın resmi dokümantasyonu bunu açıkça yazıyor:

"Dart core web libraries, like dart:html and dart:svg, are deprecated and not supported when compiling to Wasm."

Çözüm package:web — dart:js_interop tabanlı olduğu için Wasm ile uyumlu.

Engelleyen tek kitaplık dart:html değil

Göç planını yarım bırakmanın en yaygın yolu, kapsamı yalnızca dart:html'den ibaret sanmak. Flutter dokümantasyonu sınırı net çiziyor: "This prevents Dart code that uses dart:html or package:js from compiling to Wasm." Yani package:js kullanan kod da Wasm'e derlenemiyor ve karşılığı package:web değil, ayrı bir çözüm.

Pratikte bu, iki ayrı tarama demek: import satırlarında dart:html aramak yetmez, @JS() anotasyonlarını ve package:js bağımlılığını da aramalısın. Kendi kodunda ikisi de yoksa bile bağımlılık ağacındaki paketlerden biri kullanıyor olabilir — aşağıda anlatacağım otomatik dry run tam da bunun için var.

Adım adım göç

1// Önce
2import 'dart:html' as html;
3 
4void logTitle() {
5  html.window.console.log(html.document.title);
6}

1// Sonra
2import 'dart:js_interop';
3 
4import 'package:web/web.dart' as web;
5 
6void logTitle() {
7  web.console.log(web.document.title.toJS);
8}

Dikkat: console, package:web'de window altında değil, top-level getter. $Console.log da JSAny? beklediği için String'i .toJS ile dönüştürmen — yani dart:js_interop import'u — şart.

Paketi eklemek için dart.dev göç rehberinin verdiği komut yeterli:

1dart pub add web

pub.dev kaydına göre paketin güncel sürümü 1.1.1 (26 Şubat 2025 yayınlandı), yani bu yazıdan iki yılı aşkın süre önce 1.0'a ulaşmış, oturmuş bir paket.

Otomatik dönüşüm ve List uyumsuzluğu

Çoğu isim değişikliğini elle yapmana gerek yok:

1dart fix --dry-run

Dikkat etmen gereken tek pürüz: package:web'in Element.querySelectorAll, Element.children gibi metodları döndürdüğü değerler List implement etmiyor. List gerektiren bir API'ye veri geçirmen gerekiyorsa JSImmutableListWrapper ile sarmalaman gerekiyor.

Element mi, HTMLElement mi?

dart:html, tiplerin bir kısmını Dart stiline uydurmak için yeniden adlandırmıştı; package:web ise IDL'deki özgün adları kullanıyor. En sık çarpacağın örnek Element: dart.dev göç rehberine göre Element artık HTMLElement, ama Element adı da HTMLElement, SVGElement gibi tiplerin ortak temel tipi olarak varlığını sürdürüyor. querySelector bir Element döndürüyor, çünkü HTMLElement dışındaki alt tipleri de döndürebiliyor — HTMLElement'a özgü üyelere erişeceksen aşağı çevrim (downcast) yapman gerekiyor:

1import 'package:web/web.dart';
2 
3void highlightSelected(Element element) {
4  // Her iki kitaplıkta da geçerli: className temel Element üyesi.
5  element.querySelector('#selectme')!.className = 'test';
6 
7  // style HTMLElement'a özgü, bu yüzden downcast şart.
8  (element.querySelector('#selectme') as HTMLElement).style.color = 'red';
9}

Bu kural tek bir satırı değil, DOM'a dokunan her yardımcı fonksiyonu etkiliyor. Göçe başlamadan önce kod tabanındaki querySelector çağrılarını arayıp hangilerinin HTMLElement'a özgü üye kullandığını listelemek, sonradan derleme hatalarını tek tek kovalamaktan çok daha hızlı ilerletir.

Wasm'de değişen çalışma zamanı davranışları

Göç, import satırlarını değiştirmekle bitmiyor. Flutter dokümantasyonu bunu ayrıca uyarıyor: Wasm'e derlerken "runtime differences in JS interop types (such as is/as type casts and Zone propagation in callbacks)" konusunda dikkatli ol. İki somut davranış farkı var.

Birincisi tip testleri. dart:html tiplerinde is ve as, nesnenin @Native anotasyonundaki JS tipinde olup olmadığını doğruluyordu. package:web tiplerinin hepsi ise JSObject olarak somutlaşıyor, yani aynı çalışma zamanı testi aynı sonucu vermiyor. dart.dev rehberi karşılığını veriyor: instanceOfString ya da Dart 3.4'ten itibaren gelen daha tipli isA yardımcısı.

1import 'dart:js_interop';
2 
3import 'package:web/web.dart';
4 
5bool isTextInput(Element element) {
6  // dart:html karşılığı: element is InputElement
7  return element.isA<HTMLInputElement>();
8}

İkincisi daha sinsi, çünkü derleme hatası vermiyor: dart:html'de callback'ler otomatik olarak zone'a bağlanıyordu, package:web'de bağlanmıyor. Zone'a bağlı değerlere güvenen bir kodun varsa callback'i elle bağlaman gerekiyor.

1import 'dart:async';
2import 'dart:js_interop';
3 
4import 'package:web/web.dart' as web;
5 
6void listenZoned(web.Element element) {
7  element.addEventListener(
8    'click',
9    Zone.current.bindUnaryCallback((web.Event event) {
10      // Zone'a bağlı değerler burada korunur.
11    }).toJS,
12  );
13}

Bu iki fark, "derleniyor" ile "doğru çalışıyor" arasındaki boşluğu açıklıyor. Göç sonrası doğrulamanı yalnızca derleme çıktısına bakarak yapma; tip testine ve zone'a dayanan akışları davranış seviyesinde test et.

Geçiş dönemi için koşullu import

Hem eski hem yeni interop katmanını aynı anda desteklemen gerekiyorsa:

1import 'fallback.dart'
2    if (dart.library.js) 'legacy_web_interop.dart'
3    if (dart.library.js_interop) 'wasm_web_interop.dart';

Deneysel Deferred Loading İle Modül Bölme

3.47 duyurusu, Wasm'a özel deneysel bir deferred loading desteği getirdi: büyük web uygulamalarını daha küçük, tembel yüklenen modüllere bölme imkânı. Bu özellik şu an yalnızca main kanalda, bir bayrak arkasında:

1flutter build web --release --wasm --enable-wasm-deferred-loading

Hâlâ olgunlaşma aşamasında

Bunun somut kanıtı flutter/flutter deposundaki 193069 numaralı issue: 20 Eylül 2026'da stable kanaldaki Flutter 3.47.5'te bu komut Could not find an option named "--enable-wasm-deferred-loading". hatası verdi; issue aynı gün kapatıldı. Pratik sonuç: main kanal dışında bu bayrağı kullanamazsın ve stable kanala inmeden production'da güvenmemen gerekir.

Otomatik uyumluluk kontrolü

--wasm eklemeden flutter build web çalıştırsan bile Flutter arka planda bir Wasm dry run yapıyor; uyumsuz bir paket varsa non-fatal bir uyarı basıyor. Uyarının biçimi birebir şöyle:

1Wasm dry run failed:
2Found incompatibilities with WebAssembly.
3 
4package:my_app/main.dart 1:1 - dart:html unsupported (0)

Dikkat et: bu dry run uyarısında yapılandırılmış bir bağımlılık ağacı yok — yalnızca dosya, satır ve desteklenmeyen kitaplığın adı var. Yapılandırılmış Context ağacı bundan ayrı bir çıktı: flutter build web --wasm ile derleme başarısız olduğunda, uzun exception stack trace'inin yukarısında beliriyor ve hangi paketin hâlâ dart:html kullandığını main.dart => package:my_app => dart:html şeklinde bir zincirle gösteriyor. Resmi dokümantasyonun tavsiyesi de bu: uzun stack trace'i yok say, çıktının en üstüne kaydır.

Tarayıcı Desteği ve Fallback Davranışı

Wasm derlemesi çalışıyor olması, her tarayıcıda Wasm yolunun kullanılacağı anlamına gelmiyor. Flutter'ın Wasm çıktısı WasmGC (Wasm Garbage Collection) gerektiriyor ve bu desteğin tarayıcı bazında durumu eşit değil.

Fallback otomatik, sessiz ve şeffaf

Bu tablo korkutucu görünebilir ama pratikte kullanıcı hiçbir şey fark etmiyor: --wasm ile derlenmiş bir uygulama, WasmGC olmayan bir tarayıcıda otomatik olarak JavaScript çıktısına düşüyor. Firefox 120+ ve Safari'de ise WasmGC var ama Flutter'ın Wasm renderer'ını engelleyen ayrı bir bug bildirildi — bu iki tarayıcıyı hedefliyorsan davranışı kendi ölçümünle doğrula.

Bunun ölçüm tarafında bir bedeli var: kullanıcılarının ne kadarının gerçekten Wasm yolunda olduğunu tahmin edemezsin, ölçmen gerekir. Yukarıdaki bool.fromEnvironment('dart.tool.dart2wasm') sabiti yalnızca derlemenin Wasm'e gidip gitmediğini söyler, o derlemenin kullanıcının tarayıcısında hangi yola düştüğünü değil. Gerçek dağılımı görmek istiyorsan analitik olaylarını tarayıcı ve sürüm kırılımıyla toplayıp WasmGC destekleyen segmentin payını kendin çıkarman gerekiyor; aksi hâlde "Wasm açtık" cümlesi, trafiğinin büyük bir kısmı için hiçbir şey ifade etmeyebilir.

Multi-thread render için header gereksinimi

Wasm ile çoklu-thread render açmak istiyorsan sunucunun şu header'ları göndermesi gerekiyor:

Bundle Boyutu ve İlk Yükleme Gerçeği

Burada dürüst olmak gerekiyor: Flutter ve Dart'ın resmi kaynaklarında Wasm'ın JS'e kıyasla ilk yükleme süresini veya bundle boyutunu ne kadar değiştirdiğine dair yayınlanmış bir kıyaslama sayısı yok. Blog yazısı yalnızca "native-like performance" gibi niteliksel bir ifade kullanıyor, somut milisaniye ya da KB farkı vermiyor.

Elimizdeki tek resmi rakam, boyut artışı yönünde: --no-strip-wasm fonksiyon adlarını koruduğunda binary boyutu yaklaşık %47 büyüyor. Bu, "Wasm küçük çıktı üretir" gibi genel bir iddiaya körü körüne güvenmemen gerektiğinin somut kanıtı.

Kendi verini nasıl üretirsin

Uydurma bir benchmark yerine kendi projende ölçüm yap: Chrome DevTools performans trace'i ile aynı sayfayı --wasm'lı ve --wasm'sız build'lerde 4x CPU throttle + Slow 4G ağ emülasyonuyla karşılaştır. Kendi projen için güvenilir tek yöntem bu — üçüncü taraf blog yazılarındaki genel yüzdelere güvenme.

Hangi Projede Aç, Hangisinde Açma

Buraya kadarki bütün teknik ayrıntıyı tek bir karar tablosuna indirgemek gerekirse: Wasm'ı açmak, kazancı belirsiz ama maliyeti somut bir yatırım. Maliyet tarafı net — package:web göçü, index.html güncellemesi, gözlemlenebilirlik ayarı. Kazanç tarafı ise hem resmi olarak sayısallaştırılmamış hem de kullanıcı kitlenin tarayıcı dağılımına bağlı. Aşağıdaki liste bu dengeyi somut vakalara çeviriyor:

• Aç: Hesaplama-yoğun, çok sayıda widget rebuild'i olan dashboard veya oyun benzeri arayüzler; kullanıcı kitlen ağırlıklı masaüstü Chrome ve Edge kullanıyorsa.
• Aç: dart:html bağımlılığın zaten yok veya küçükse ve package:web'e göç maliyeti düşükse.
• Açma (şimdilik): Kullanıcı kitlende önemli oranda Safari veya iOS Chrome trafiği varsa — iOS Chrome sessizce JS'e düşer, Safari'de ise renderer bug'ı yüzünden Wasm yolunun çalışacağına güvenemezsin.
• Açma (şimdilik): Deferred loading'e ihtiyaç duyan büyük bir uygulaman varsa — bu özellik main kanalda deneysel, stable'da yok.
• Açma (şimdilik): CI'da --no-strip-wasm olmadan production hatalarını okuyabilecek gözlemlenebilirlik altyapın yoksa; stack trace'ler Wasm'de JS'e göre daha zor okunuyor.

Ölçüm: Gerçek Chrome Trace ile Önce/Sonra

--wasm açık ve kapalı iki build'i aynı ortamda karşılaştırmadan "hızlandı" demek, bu yazının başında eleştirdiğimiz uydurma benchmark hatasına düşmek olur. Adımlar:

1. İki ayrı release build üret: biri --wasm olmadan, biri --wasm ile.
2. Her ikisini aynı statik sunucudan, aynı CDN önbellek durumuyla serve et.
3. Chrome DevTools'ta 4x CPU throttle + Slow 4G ile performans trace'i kaydet.
4. LCP, TTI ve toplam JS/Wasm indirme boyutunu karşılaştır.
5. Sonucu kendi projenin gerçek kullanıcı dağılımına (hangi tarayıcı, hangi cihaz) göre yorumla — genel bir yüzde başka projeye taşınmaz.

SSS

Flutter web Wasm production'da kullanılabilir mi?

Kısmen. --wasm bayrağı Flutter 3.24 ve üzerinde kullanılabilen, resmi olarak opt-in bir derleme yolu; flutter build web --release --wasm ile production build üretebilirsin, ama Flutter ekibi bunu henüz varsayılan yapmadı — 3.47 duyurusunda "WebAssembly (Wasm)'ı varsayılan olarak etkinleştirmeye doğru aktif olarak çalışıyoruz" deniyor. Deferred loading gibi ölçeklenebilirlik özellikleri ise main kanalda deneysel durumda, production için henüz önerilmiyor.

dart:html yerine package:web'e nasıl geçilir?

dart:html import'unu kaldırıp package:web/web.dart eklemen, pubspec.yaml'a web paketini yazman gerekiyor. dart fix --dry-run çoğu isim değişikliğini otomatik gösteriyor; List implement etmeyen dönüş tiplerinde JSImmutableListWrapper kullanman gerekebilir.

Flutter web Wasm ile ne kadar hızlanıyor?

Resmi kaynaklarda somut bir yüzde yayınlanmadı — bu konuda net bir sayı vermek uydurma olur. Flutter'ın resmi ifadesi "native-like performance" gibi niteliksel; tek somut resmi rakam tam tersi yönde, --no-strip-wasm bayrağının binary boyutunu yaklaşık %47 artırması. Kendi projen için gerçek kazancı yalnızca kendi Chrome trace ölçümün gösterir.

Wasm deferred loading nasıl açılır?

flutter build web --release --wasm --enable-wasm-deferred-loading komutuyla, ama bu yalnızca main kanalda mevcut deneysel bir bayrak — stable veya beta kanalında değil. flutter/flutter 193069 numaralı issue'da görüldüğü gibi stable 3.47.5 bu bayrağı tanımıyor; stable kanala inmeden production'a almamanı öneririm.

Wasm açtığımda eski tarayıcılarda uygulama çöker mi?

Hayır. WasmGC desteklemeyen bir tarayıcı tespit edildiğinde Flutter otomatik olarak JavaScript çıktısına düşüyor, uygulama çalışmaya devam ediyor — yalnızca Wasm'ın potansiyel performans kazancından faydalanmamış oluyorsun.

Sonuç

Wasm'ı açmak teknik olarak mümkün ama üç ayrı olgunluk seviyesini aynı anda taşıyorsun: derleme yolu stable kanalda ama opt-in, deferred loading deneysel, tarayıcı desteği parçalı. Kod tabanını Flutter 3.47: material_ui ve cupertino_ui Paketlerine Geçiş yazısındaki aynı sürüm dalgasıyla birlikte package:web'e taşımak, iki göçü tek seferde yapman için iyi bir fırsat. Render motorunun genel performans tablosuna dair Flutter 4 Impeller: Yeni Render Engine ve Performans Devrimi yazısına, Dart tarafındaki modern söz dizimi değişiklikleri için Dart 3.13 Primary Constructor ve Dart 3 Yenilikleri yazılarına bakabilirsin. 60fps hedefiyle ilgili daha geniş bir performans çerçevesi istiyorsan Flutter Performans Optimizasyonu: 60fps Garanti Rehberi yazısı, mimari kararların Wasm göçünü nasıl kolaylaştırdığını görmek istiyorsan Flutter Clean Architecture yazısı tamamlayıcı olacaktır.

Kaynaklar

• Flutter 3.47 duyurusu — Wasm varsayılan hedefi, --wasm bayrağı ve deferred loading duyurusu.
• Flutter Web Wasm dokümantasyonu — tarayıcı desteği, fallback davranışı, --no-strip-wasm maliyeti.
• package:web geçiş rehberi — dart:html desteksizliği, dart fix, JSImmutableListWrapper.
• package:web pub.dev sayfası — paket sürümü ve yayın tarihi.
• Flutter sürüm notları — minimum sürüm ve genel sürüm takibi.
• flutter/flutter issue #193069 — stable 3.47.5'te --enable-wasm-deferred-loading bayrağının tanınmaması.