React Three Fiber v9.7, WebGPU và hướng đi mới cho game web

React Three Fiber (R3F) đang có hai chuyển động đáng chú ý đối với developer làm game và trải nghiệm 3D trên web: nhánh ổn định vừa nhận bản v9.7.0 với một loạt sửa lỗi ở reconciler, trong khi nhánh v10 vẫn ở trạng thái thử nghiệm nhưng đã xác định rõ hướng WebGPU/TSL. Song song với đó, tổ chức pmndrs đang xây dựng react-three-examples, một repository chính thức nhằm chuyển các ví dụ Three.js sang React Three Fiber theo hướng WebGPU-first.

Điểm đáng quan tâm với indie developer không phải là “WebGPU đã thay WebGL” — điều đó chưa thể kết luận từ các nguồn hiện tại — mà là hệ sinh thái R3F đang chuẩn hóa dần cách viết, cách test và cách cung cấp ví dụ để một dự án 3D web có thể tiến tới WebGPU mà không phải đánh đổi sự ổn định của production ngay hôm nay.

Điều gì thực sự mới ở React Three Fiber?

Theo release page chính thức của pmndrs, R3F v9.7.0 được phát hành ngày 31/07/2026 và hiện là bản stable mới nhất trên GitHub. Đây không phải một bản thay đổi renderer lớn. Trọng tâm của v9.7.0 là “harden” reconciler — lớp chịu trách nhiệm đồng bộ cây React với object graph của Three.js.

Release notes liệt kê các thay đổi chính gồm: sửa đồng bộ children nội bộ sau keyed reorder, sửa reset pierced props, đồng bộ host props, harden việc reconstruction nhiều instance trong cùng một lượt cập nhật, đưa event priority về gần cách react-dom xử lý và bổ sung hỗ trợ reconciler microtasks. Những thay đổi nghe có vẻ thuộc nội bộ framework, nhưng với game web chúng chạm đúng vào các khu vực thường xuyên bị stress: entity sinh/hủy liên tục, object được reorder, UI React chồng lên canvas 3D và component có cấu hình thay đổi trong runtime.

Keyed reorder quan trọng hơn vẻ ngoài của nó

Trong một game dùng React để biểu diễn scene hoặc UI 3D, danh sách enemy, projectile, loot, marker hay object tương tác thường được render từ array có key. R3F v9.7.0 sửa trường hợp React đã reorder children nhưng bản đồ children nội bộ của R3F không theo kịp, từ đó có thể tạo ra lỗi khó đoán. Đây là fix trực tiếp được maintainer mô tả trong release notes, không phải benchmark hiệu năng.

Với developer, ý nghĩa thực tế là nên kiểm thử lại những scene từng có bug “object đúng state nhưng sai thứ tự hoặc sai attachment” sau các thao tác reorder. Nếu trước đây dự án có workaround thủ công để ép remount, không nên xóa ngay; hãy viết regression test trước rồi mới dọn code.

Pierced props và host props được làm chắc hơn

R3F cho phép viết nested property theo cú pháp pierced props, ví dụ position-x hoặc những property sâu hơn. Release v9.7.0 sửa trường hợp khi một pierced prop bị gỡ, reconciler có thể reset nhầm vào object gốc thay vì property mục tiêu. Cùng lúc, host props như dispose và onUpdate cũng được đồng bộ chính xác hơn khi thay đổi.

Đây là loại bug dễ xuất hiện trong editor 3D, configurator hoặc game có nhiều state mode hơn là trong demo tĩnh. Một weapon attachment, camera rig hoặc effect component có thể thay đổi props theo trạng thái gameplay; việc unset một prop không còn là chi tiết nhỏ nếu nó để lại state cũ trong object Three.js.

Batch instance reconstruction và event priority

Release notes còn nhắc đến một edge case khi hai instance cùng cần reconstruction do args thay đổi nhưng một nhánh update bị bail out bởi React.memo hoặc cơ chế tương tự. v9.7.0 harden việc batch reconstruction để tránh mất một update trong trường hợp đó. Không có số liệu chính thức cho thấy thay đổi này tăng FPS bao nhiêu, vì vậy nên xem đây là fix về tính đúng đắn của reconciler chứ không phải một “performance boost” được định lượng.

Ở lớp input, R3F cũng đưa event priorities về cùng logic với react-dom và hỗ trợ reconciler microtasks. Với game web dùng HUD DOM bên ngoài canvas nhưng vẫn có pointer event trong scene, đây là nền tảng tốt hơn để hành vi input giữa hai thế giới nhất quán. Nó không tự giải quyết toàn bộ bài toán input architecture, nhưng giảm số khác biệt bất ngờ giữa React DOM và R3F.

R3F v10 đang ở đâu?

Điểm cần nói thật rõ: R3F v10 chưa phải stable. Release page hiện đánh dấu v10.0.0-alpha.1 là pre-release. Alpha này được công bố từ tháng 1/2026, không phải là bản thay thế trực tiếp vừa phát hành sau v9.7.0.

Dù vậy, v10 cho thấy định hướng kiến trúc rất rõ. R3F chuyển từ giả định chỉ có WebGL renderer sang hỗ trợ cả WebGLRenderer và WebGPURenderer; state trước đây quen gọi là gl được đổi theo hướng trung lập renderer hơn. Nhánh này cũng có scheduler mới và đưa WebGPU/TSL thành first-class với các hook như useUniforms, useNodes, useLocalNodes và usePostProcessing.

Alpha còn bổ sung truy cập camera frustum cho spatial query, các lifecycle liên quan visibility như Visible/Framed/Occluded, camera tham gia scene graph, render target không phụ thuộc renderer và scheduler có thể chạy ngoài cây R3F. Chính maintainer cảnh báo các feature này còn experimental và có thể thay đổi, bị loại bỏ hoặc mở rộng.

Điều đó có nghĩa gì cho game web?

Với game production, v10 hiện phù hợp hơn cho branch thử nghiệm, prototype renderer hoặc R&D. Với tool nội bộ, visualizer hoặc vertical slice, đây lại là thời điểm tốt để đánh giá những assumption đang khóa kiến trúc vào WebGL. Ví dụ: post-processing đang phụ thuộc WebGL-specific package hay dùng abstraction trung lập? Shader đang viết trực tiếp GLSL hay đã có lớp node/TSL? Game loop có bị buộc chặt vào Canvas hay có thể tách scheduling của simulation và rendering?

Khuyến nghị hợp lý là không “migrate vì v10 mới hơn”, mà lập một compatibility branch nhỏ để kiểm tra những hệ thống khó chuyển nhất: custom shader, post-processing, render target, GPU picking, instancing, physics debug rendering và UI tương tác. Khi v10 tiến tới beta/stable, bạn đã biết migration cost thực tế thay vì dự đoán.

react-three-examples: mảnh ghép mới đáng theo dõi

Repository pmndrs/react-three-examples hiện tự mô tả là “Official threeJS examples ported to r3f”. Tài liệu SPEC được đánh dấu FINAL ngày 26/07/2026 và cho thấy đây không chỉ là một folder demo nhỏ. Mục tiêu của dự án là xây lại các ví dụ Three.js bằng R3F v10 theo hướng WebGPU-first, đồng thời làm cho cấu trúc đủ rõ để cả developer lẫn coding agent có thể đọc và tái sử dụng.

Theo inventory ghi trong SPEC tại thời điểm 26/07, upstream Three.js có 595 example được khảo sát: 221 thuộc nhóm WebGPU, 296 WebGL và 77 có mặt ở cả hai phía. Phase 1 dự kiến tập trung vào tập WebGPU sau khi bỏ các stress/internal test, với quy mô ước tính khoảng 190–200 port. Phase 2 mới xem xét nhóm WebGL-only còn giá trị kỹ thuật riêng, thay vì máy móc chuyển mọi ví dụ.

Cách tiếp cận này quan trọng với game dev vì ví dụ chính thức thường là nơi developer kiểm tra API khi cần giải quyết một vấn đề cụ thể: shadow, loader, compute, post-processing, material, particle, BVH, decal, multiple view hay path tracing. Nếu corpus R3F v10 được hoàn thiện theo đúng kế hoạch, khoảng cách giữa “Three.js có ví dụ nhưng R3F phải tự dịch imperative sang declarative” sẽ nhỏ hơn đáng kể.

Không chỉ dành cho người đọc: examples được thiết kế cho coding agent

SPEC mô tả khá chi tiết lớp dành cho agent: cấu trúc file nhất quán, AGENTS.md, manifest examples.json, hướng dẫn extraction và các đường mở project trong agent hoặc môi trường code. Đây là một điểm đáng chú ý cho indie dev đang dùng Claude Code, Codex, Copilot hoặc Cursor: chất lượng code do agent sinh ra phụ thuộc mạnh vào reference corpus mà agent được cung cấp.

Một corpus WebGPU/R3F có convention rõ ràng có thể hữu ích hơn việc để agent học từ hàng nghìn snippet cũ trên web. Tuy nhiên, đó là mục tiêu thiết kế của repository, không phải bằng chứng rằng agent đã trở nên chính xác hơn bao nhiêu phần trăm. Hiện chưa có benchmark chính thức trong SPEC cho claim đó.

Stack và CI của dự án nói gì về WebGPU production?

SPEC chọn TypeScript, Vite, React Router và Playwright. Phần CI đáng chú ý hơn: tài liệu ghi nhận WebGPU có thể khởi tạo qua SwiftShader trên runner Linux, nhưng headless Chrome có vấn đề khiến canvas WebGPU không được present đúng và tạo screenshot đen. Giải pháp dự kiến là chạy headed Chromium dưới Xvfb, dùng readiness signal thay vì sleep và tách smoke test khỏi screenshot regression.

Đây là bài học hữu ích nếu bạn đang xây game web WebGPU: test “page load không crash” là chưa đủ. Pipeline nên ít nhất kiểm tra renderer khởi tạo, canvas không đen, không có exception quan trọng và một số scene representative render được. Nếu dùng golden screenshot, cần cố định cùng một đường render để tránh so ảnh từ GPU thật với SwiftShader rồi tưởng đó là regression.

SPEC cũng nói rõ dự án không đặt pixel parity với Three.js upstream làm mục tiêu chính. Các port được ưu tiên “idiomatic R3F”, tức dùng composition và abstraction phù hợp với React thay vì dịch từng dòng imperative code. Với game codebase, đây là cách suy nghĩ đáng học: migration tốt không phải là copy API cũ sang wrapper mới, mà là xác định state ownership, lifecycle và boundary giữa simulation với renderer.

Tác động thực tế với indie developer

Nếu đang làm một web game nhỏ bằng Three.js/R3F, bạn có thể chia quyết định thành ba tầng.

Production hiện tại: ưu tiên R3F stable

v9.7.0 là tín hiệu tích cực cho các dự án đang ở v9.x vì những thay đổi của nó chủ yếu làm reconciler ổn định hơn. Nhưng vẫn nên nâng cấp theo branch riêng, chạy replay/test các luồng có reorder entity, remount object, thay args, pointer event và custom attachment. Đừng nâng version trực tiếp vào branch release chỉ vì đây là patch/minor trong cùng major.

Prototype tương lai: thử WebGPU nhưng giữ đường lùi

Nếu game cần compute, shader graph/TSL hoặc muốn đi sớm với WebGPU, hãy tạo một scene benchmark của chính game thay vì benchmark tổng hợp. Chọn các workload thật: số draw call, số skinned mesh, particle, post-processing, shadow, texture bandwidth và physics debug. Kết quả mới có giá trị cho quyết định sản phẩm của bạn.

Đồng thời giữ renderer boundary đủ sạch để có thể quay về WebGL khi cần. R3F v10 đang hướng tới abstraction renderer trung lập hơn, nhưng alpha vẫn là alpha; API có thể đổi.

AI-assisted development: đưa nguồn chính thức vào context

Khi dùng coding agent để viết Three.js/R3F, nên ưu tiên release notes, docs và repository chính thức thay vì prompt chung chung “hãy dùng API mới nhất”. Một agent rất dễ lẫn API v9 với v10 alpha, hoặc đưa package WebGL-only vào pipeline WebGPU. react-three-examples đang được thiết kế để giảm đúng loại sai lệch này, nhưng cho đến khi corpus hoàn thiện, developer vẫn cần kiểm tra dependency/version và build thực tế.

Checklist nên làm ngay

Kiểm tra phiên bản hiện tại: nếu đang dùng R3F v9, đọc changelog v9.7.0 và xác định có workaround nào liên quan keyed reorder, pierced props hoặc host props.
Tạo regression scene: gom các case nhiều entity, reorder, pointer event và instance reconstruction vào một route test riêng.
Không đưa v10 alpha thẳng vào production: dùng branch hoặc prototype riêng, khóa version chính xác và ghi lại breaking change gặp phải.
Đánh giá WebGPU bằng workload của game: không dùng cảm giác “renderer mới chắc nhanh hơn” thay cho profiling.
Theo dõi react-three-examples: khi một technique bạn cần được port chính thức, so sánh nó với implementation nội bộ trước khi thay.
Chuẩn hóa context cho coding agent: ghim link release, migration guide và examples đúng version trong prompt/repo instruction.
Thiết kế CI cho renderer thật sự: nếu test WebGPU trên Linux, kiểm tra cả khả năng present canvas và hình ảnh đầu ra, không chỉ DOM state.

Kết luận

R3F v9.7.0 và dự án react-three-examples cho thấy hệ sinh thái Three.js + React đang bước vào giai đoạn chuẩn bị nghiêm túc hơn cho WebGPU, nhưng chưa phải lúc tuyên bố WebGL đã lỗi thời hay v10 đã sẵn sàng production. Tin tốt cho indie developer là có thể giữ nền tảng stable hiện tại, đồng thời bắt đầu đo migration cost bằng một branch WebGPU riêng và theo dõi corpus example chính thức đang được xây dựng.

Nếu mục tiêu là ship game, thứ tự ưu tiên vẫn nên là tính đúng đắn của game loop, input, asset pipeline, loading, memory và khả năng chạy ổn trên thiết bị người chơi. WebGPU là một hướng kỹ thuật đáng đầu tư, nhưng renderer chỉ thực sự có giá trị khi nó phục vụ được sản phẩm thay vì trở thành mục tiêu tự thân.