Hola, I’m Hieu, a Software Engineer

flutter build web --wasm trông như một cờ bạn bật lên cho nhanh. Thực chất nó gần với đổi runtime hơn. Đứng sau cờ đó là dart2wasm , một compiler khác dart2js, sinh mã cho một cỗ máy khác, với một tập thư viện lõi khác hẳn. Code hôm qua build được hôm nay có thể hỏng — không phải vì nó sai, mà vì nó import một thư viện không còn tồn tại trên target mới. Chi phí migration hầu như không nằm ở code của bạn. Phần lớn code ứng dụng không đụng trực tiếp vào dart:html ; nó gọi một package, package đó gọi một package khác, và cái cuối cùng mới đụng. Nên lần build --wasm đầu tiên của một app thật thường chết ở đâu đó ba tầng sâu trong cây dependency, trong một file bạn chưa từng mở, thuộc một package bạn không hề chủ động chọn. Và nằm sau tất cả những chuyện đó là điều không cờ biên dịch nào thay đổi được: app Flutter web vẽ lên một canvas. Thứ tới trình duyệt là một ứng dụng, không phải một tài liệu. Riêng sự thật đó kéo theo hầu hết các giới hạn thẳng thắn ở dưới — first paint, SEO, tìm t...

flutter build web --wasm reads like a flag you turn on for speed. It is closer to switching runtimes. Behind it sits dart2wasm , a different compiler from dart2js, emitting code for a different machine, with a different set of core libraries available to you. Code that compiled yesterday can stop compiling today — not because it is wrong, but because it imports a library that no longer exists on the target. The migration cost is almost never in your own code. Most application code never touches dart:html directly; it calls a package, which calls a package, which does. So the first --wasm build of a real app usually fails somewhere three levels down your dependency graph, in a file you have never opened, in a package you did not choose deliberately. And past all of that sits the part no compiler flag changes: a Flutter web app paints into a canvas. The bytes that arrive in the browser are an application, not a document. That single fact drives most of the honest limitations below —...