- Sự xuất hiện của các tính năng CSS hiện đại như View Transitions API khiến giờ đây không còn cần cấu trúc SPA để có được chuyển trang mượt mà
- Phần lớn website SPA trên thực tế không mang lại hiệu năng hay trải nghiệm mượt như kỳ vọng, mà ngược lại còn có xu hướng làm suy giảm trải nghiệm người dùng do mã JavaScript nặng nề
- Trên các trình duyệt dựa trên Chromium, có thể tận dụng chuyển trang native và Speculation Rules để triển khai điều hướng nhanh và tự nhiên mà không cần JavaScript
- Cấu trúc phức tạp của SPA cản trở tối ưu hóa của trình duyệt, vì vậy với các website thực tế, cấu trúc MPA lấy HTML và CSS làm trung tâm sẽ nhanh hơn và dễ bảo trì hơn
- Trong thời gian tới, cần hạn chế áp dụng SPA không cần thiết và tận dụng CSS hiện đại cùng các tính năng native để phát triển website hiệu quả và dễ bảo trì
Mở đầu: Sự cáo chung của SPA và sự xuất hiện của CSS hiện đại
- Gần đây, với việc đưa vào sử dụng các tính năng CSS mới như View Transitions API, những lợi thế chính mà SPA (ứng dụng một trang) từng mang lại nay đã không còn cần thiết nữa
- Dù nhiều đội ngũ phát triển vẫn chọn các framework SPA như React hay Vue, cốt lõi của quyết định đó thường không phải là hiệu năng mà là ngộ nhận về tương tác và trải nghiệm điều hướng mượt mà
- Quan niệm cho rằng SPA là điều bắt buộc để có điều hướng mượt mà thực chất đã là một cách nghĩ lỗi thời
Ảo tưởng và thực tế của SPA
- SPA từng là cách duy nhất để hiện thực hóa chuyển trang tự nhiên nhất, nhưng giờ điều đó không còn đúng nữa
- Nhiều SPA gặp các vấn đề sau:
- Chỉ có hiệu ứng mờ dần ở trạng thái tải chứ thiếu sự mượt mà thực sự trong chuyển đổi nội dung
- Vấn đề khôi phục vị trí cuộn và xử lý focus thiếu nhất quán
- Độ trễ điều hướng do chậm render/hydration
- Layout shift và nội dung bật ra, skeleton loading, v.v.
- Độ phức tạp không cần thiết và lạm dụng JavaScript trong khi hiệu quả thu được về hiệu năng là rất nhỏ
- Các framework SPA tiêu biểu như Next.js, Gatsby, Nuxt đang thêm vào lượng lớn mã JS để mô phỏng hành vi native cơ bản của trình duyệt
- Kết quả là chúng hy sinh sự tự nhiên vốn có của nền tảng, làm trang chậm hơn và còn ảnh hưởng xấu tới SEO
Sự phát triển của nền tảng web và vai trò thay đổi của CSS
- Các trình duyệt hiện đại dựa trên Chromium (Chrome, Edge, v.v.) hiện hỗ trợ chuyển trang native theo kiểu khai báo
- Với View Transitions API, có thể tạo hoạt ảnh mượt giữa các tài liệu hoặc toàn bộ trang mà không cần JavaScript
- Các khả năng cốt lõi gồm:
- Hiệu ứng fade giữa các trang (chỉ cần 3~4 dòng CSS)
- Hoạt ảnh phần tử dùng chung như chuyển tự nhiên từ thumbnail sang ảnh chi tiết
- Duy trì các phần tử thường trực như header, navbar
- Do vẫn là URL thật và chuyển trang thật, khả năng tương thích với SEO, chia sẻ liên kết, back/forward cache, v.v. được tối đa hóa
Cách tận dụng đầy đủ sức mạnh kết hợp giữa CSS và JS
- Nếu cần, vẫn có thể dùng JS để gọi thủ công View Transition cho các chuyển đổi bên trong trang
- Ví dụ: đổi theme, bật/tắt tab, chuyển dark mode với lượng JavaScript tối thiểu
Speculation Rules và điều hướng tức thời
- Speculation Rules cho phép trình duyệt preload/prerender trang từ trước, dự đoán hành vi người dùng (ví dụ: rê chuột) để mang lại điều hướng gần như tức thời
- Có thể cấu hình theo kiểu khai báo thông qua
<script type="speculationrules">
- Điều kiện tiên quyết: khi trang nhẹ và được tối ưu tốt thì hiệu quả tối đa hóa hiệu năng sẽ rất rõ rệt; nếu trang nặng thì ngược lại có thể gây lãng phí tài nguyên
Tôn trọng khả năng vốn có của trình duyệt và bfcache
- bfcache (Back/Forward Cache) cho phép khôi phục ngay toàn bộ trang dưới dạng ảnh chụp nhanh khi người dùng bấm quay lại/tiến tới
- Điều kiện: cần có kiến trúc sạch, dựa trên HTML và CSS thuần; với cấu trúc chặn routing như SPA thì không thể áp dụng
- Nói cách khác, trình duyệt hiện đại đang tiến hóa theo hướng thưởng cho những website đơn giản và vững chắc
So sánh hiệu năng giữa SPA và MPA
- Một SPA trung bình (theo chuẩn Next.js):
- Kích thước JS bundle: 1~3MB
- TTI (thời điểm có thể sử dụng): 3.5~5 giây
- Chuyển route: giả lập/mô phỏng
- SEO: phức tạp, khó duy trì
- Hành vi scroll/anchor: thiếu ổn định
- Một MPA hiện đại (áp dụng CSS transitions và Speculation Rules):
- JS bundle: 0KB (chỉ bổ sung tùy chọn)
- TTI: khoảng dưới 1 giây
- Chuyển route: hành vi native thực sự
- SEO: rất dễ
- Cuộn thông minh, focus, history: hành vi mặc định của trình duyệt và được hỗ trợ hoàn hảo
Cần xem lại sự khác biệt giữa website và app, cũng như mức độ phù hợp
- Phần lớn website thực tế không phải là một “app” đúng nghĩa và không cần shared state, client-side routing hay tương tác phức tạp
- Với trang marketing, cổng tài liệu, thương mại điện tử, blog, v.v., cấu trúc đơn giản, tải nhanh, lấy HTML làm trung tâm phù hợp hơn
- Nếu áp dụng stack SPA cho mọi dự án, có thể gây ra độ phức tạp quá mức và suy giảm hiệu năng
- Yêu cầu “trông giống app”
- Đưa framework vào
- Thêm client-side routing và độ phức tạp
- Hiệu năng đi xuống và cần tối ưu bổ sung
- Nhưng thực tế vẫn chậm hơn cấu trúc dùng liên kết native + hoạt ảnh CSS
Kết luận và khuyến nghị
- SPA từng gần như là một biện pháp tạm thời để vượt qua giới hạn của nền tảng trong quá khứ, nhưng giờ những ràng buộc đó không còn nữa
- Giờ đây có thể chủ động tận dụng các tính năng native như:
- Chuyển đổi thật giữa các trang
- Prerender tức thời thông qua Speculation Rules
- Cấu trúc bền vững trước việc suy giảm tính năng theo hướng tiến dần
- Markup gọn gàng, tải nhanh, dùng URL thật
- Cấu trúc tận dụng tối đa sự hỗ trợ của nền tảng
- Nếu tiếp tục bám vào SPA chỉ vì lý do “mượt mà”, cái giá phải trả sẽ là độ phức tạp, hiệu năng và khả năng bảo trì
- Bằng cách áp dụng server rendering, trang thật, hoạt ảnh dựa trên CSS, preload có chủ đích và lượng JS tối thiểu, có thể xây dựng những website nhanh hơn và dễ chịu hơn, phù hợp với thời đại hiện nay
- Với công nghệ của năm 2025, đã đến lúc hướng tới trải nghiệm web nhanh hơn, đơn giản hơn và dễ được mọi người đón nhận hơn
10 bình luận
Ngay từ đầu, trong những trường hợp người ta cân nhắc SPA chỉ vì lý do “mượt” thì tôi vốn sẽ bỏ luôn cái sự “mượt” đó và viết bằng MPA, nên cũng không thấy quá đồng cảm...
Điểm còn đáng tiếc của bài viết này
Diễn giải thu hẹp mục đích thực sự của SPA
View Transitions API thực sự rất ấn tượng, nhưng chỉ riêng điều đó không có nghĩa là không còn cần SPA.
Nhìn mọi website theo cùng một tiêu chuẩn
Trang marketing ≠ dashboard ≠ ứng dụng thương mại điện tử ≠ công cụ cộng tác thời gian thực
Mỗi loại đều có những yêu cầu kiến trúc khác nhau.
Trong thực tế, SPA + SSR + MPA đang cùng tồn tại
Các framework hybrid như Next.js đang cho thấy điều đó rất rõ.
Tài sản tĩnh dùng SSG, dashboard sau đăng nhập dùng CSR/SPA, phần cần đáp ứng công cụ tìm kiếm dùng SSR — cần một sự kết hợp linh hoạt như vậy.
Tôi cho rằng SPA không chỉ phục vụ trải nghiệm người dùng mà còn gần như là kết quả của việc cải thiện kiến trúc.
Với những trang không cần SPA, MPA + modern CSS có thể là một lựa chọn tốt, nhưng xét về kiến trúc, trạng thái, khả năng mở rộng và khả năng bảo trì thì SPA vẫn là yếu tố thiết yếu. Tôi nghĩ modern CSS có thể "bổ trợ" cho SPA, nhưng không thể "thay thế" SPA.
Trong các trường hợp bạn nêu ra, thứ gần như duy nhất không thể thay thế SPA bằng view transition các thứ là công cụ cộng tác thời gian thực, nhưng phần lớn website không phải là công cụ cộng tác thời gian thực. Các site marketing, dashboard, ứng dụng thương mại đều có thể được xây dựng mà không dùng framework SPA, miễn là giữ các điều kiện như server rendering, trang đầy đủ, animation dựa trên CSS, preload có chủ đích và chỉ đưa vào lượng JS tối thiểu. Phía Rails theo đuổi hướng này cũng có Hotwire, và đã có các trường hợp production là Basecamp và HEY. Quản lý trạng thái thì sao? Trừ khi là dạng công cụ cộng tác thời gian thực, còn không các phương pháp phía server như URL parameter, server session hoặc local storage là đã đủ. Cũng rõ ràng có những trường hợp áp dụng SPA chỉ vì chuyển trang (ví dụ như site chính thức của AGF, trong khi Astro cũng đã đủ nhưng vẫn dùng React), nên không thể phủ nhận rằng một trong những lợi điểm tiêu biểu của SPA thường được nhắc đến chính là chuyển trang.
Đúng là các framework SPA hiện nay và xu hướng frontend dựa trên chúng vẫn cần phải tiếp tục cảnh giác với sự phi tiêu chuẩn hóa, đồng thời cũng dễ dẫn tới over-engineering và tiêu tốn tài nguyên không cần thiết…
Nhưng tôi cũng có chút nghi ngờ liệu người viết có đang nhìn khái niệm SPA quá hẹp hay không, và hơn thế nữa, có thực sự hiểu các framework SPA ảnh hưởng đến toàn bộ quá trình phát triển như thế nào hay không.
Nói rằng chỉ cần có CSS cùng một View Transition API là đủ, nếu nói cách khác thì có nghĩa là mọi tính năng không liên quan đến điều đó, cũng như toàn bộ paradigm để đạt được chúng, đều vô nghĩa — tôi thấy đó là một góc nhìn khá ngạo mạn.
Đây lại là một vấn đề khác hẳn với chuyện over-engineering khi dùng React để làm một website chỉ ở mức thay thế brochure.
Tôi đồng ý rằng phần lớn các dự án quy mô nhỏ không nhất thiết phải cần framework SPA, nhưng với những dịch vụ lấy yêu cầu làm các tương tác phức tạp, trải nghiệm người dùng liên tục, cũng như việc bảo trì và cải tiến lâu dài đi kèm, thì tôi không nghĩ như vậy, bất chấp sự phát triển của CSS.
Thành thật mà nói, điều đó nghe giống như kiểu bảo về Rust hay Haskell dù còn chưa từng chạm vào rằng “mấy thứ đó không cần đâu, giờ C++ là làm được hết rồi”.
Hmm, tôi không chắc. Chẳng phải mục đích dùng framework SPA là để xử lý những tương tác phức tạp với người dùng hơn là chỉ để chuyển cảnh mượt mà sao?
Chắc chắn có những trường hợp người ta đưa framework SPA vào chỉ vì một tương tác mượt mà. Rất nhiều trang web áp dụng SPA thực ra không cần các tương tác phức tạp.
Rất đồng ý
Ví dụ điển hình là bản thân React cũng là Spring của frontend
Nó nặng và phức tạp; có vẻ như giúp công việc thuận tiện hơn, nhưng thực ra lại là kiểu tiện lợi kỳ lạ khi dựng sẵn một quy trình phức tạp hơn chỉ để làm những việc vốn nhẹ nhàng, rồi còn cố làm cho chính quy trình bị làm phức tạp đó trở nên tiện hơn
Tôi đồng ý. Nếu không phải là một web app phức tạp như Google Docs, thì ngay cả Hotwired do hệ sinh thái Rails tạo ra cũng là đủ, và với các trang tĩnh thì Astro cũng là đủ.
Ý kiến trên Hacker News
SPA chỉ thực sự có ý nghĩa khi người dùng dành một phiên dài trong cùng một ứng dụng, tức là tải một bundle lớn một lần rồi sau đó có thể dùng ứng dụng chỉ với các yêu cầu mạng nhỏ; hiệu ứng chuyển cảnh mượt mà chỉ là phần thêm vào, không phải vấn đề cốt lõi mà SPA giải quyết, nói rằng client-side routing là để chuyển trang là hiểu sai mục đích của SPA; nếu bạn dùng SPA dựa trên tiền đề sai đó thì bài này đúng thật, nhưng SPA xuất hiện từ thời jQuery để phục vụ các ứng dụng phức tạp, với đống mã jQuery khổng lồ nơi mỗi
divhoạt động như một ứng dụng mini và đồng bộ bằng nhiều yêu cầu mạng nhỏ, nhờ vậy có thể dùng hiệu quả trong bối cảnh trình duyệt cũ và Internet chậm mà không phải tải lại toàn bộ mã mỗi lần; về sau các framework như React phát triển giúp việc xây dựng ứng dụng có cấu trúc dễ hơn, và lợi thế cốt lõi của SPA là cache một bundle lớn cho người dùng có phiên dài rồi giảm tối đa lưu lượng mạng về sau(Trích từ ý kiến trên: "...if you shared that misunderstanding of SPAs and used them to solve the wrong problem, this article is 100% correct.") Hoàn toàn đồng ý, tác giả là chuyên gia tư vấn SEO nên có vẻ chỉ tập trung vào website marketing, còn các ứng dụng thực tế (không phải website marketing) có thể hưởng lợi rất lớn từ SPA; thử tưởng tượng làm Google Maps mà không có SPA thì chỉ cần thêm animation chuyển trang thôi cũng đủ làm UX tệ đi nghiêm trọng
Có câu kiểu “chỉ chất thêm mì spaghetti jQuery”, nhưng thực tế tôi từng áp dụng các pattern thiết kế JS đời đầu như IIFE để tổ chức mã, lazy-load module, obfuscation mã, v.v.; và theo trải nghiệm của tôi thì AngularJS là nỗ lực lớn nhất trong việc cấu trúc hóa frontend, cũng hấp dẫn các lập trình viên Java vì tính mô-đun, DI và khả năng kiểm thử; lúc đầu khi làm app với Backbone tôi không quá chú trọng test vì nghĩ phần lớn chức năng nằm ở backend, nhưng về sau khi rebuild bằng AngularJS thì số lượng test frontend tăng lên rất nhiều; dĩ nhiên giờ tôi cũng thấy khó chịu với sự dài dòng, phức tạp và mức độ gián tiếp của code Angular hiện nay hay code Java
Tôi nghĩ kết nối mạng chậm và môi trường cache tích cực là một trong những lý do rất mạnh để cần SPA, đặc biệt với application hơn là website; nếu có kết nối đủ tốt để tải toàn bộ frontend một lần và cache lại, thì việc sử dụng về sau có thể diễn ra với băng thông tối thiểu
Nếu bạn làm ở nơi dùng pipeline CI/CD hiện đại, thì mỗi lần deploy nhiều lần trong ngày, bundle JS lớn đó rất dễ bị rebuild và invalid cache; HTTP2 đã là mặc định trên trình duyệt suốt 10 năm, và nhờ multiplexing nên không còn lý do gì phải gộp JS thành các bundle lớn nữa; cách làm SPA tạo bundle lớn không tận dụng được các tính năng hiện đại của trình duyệt và server
Tôi tò mò thực tế có bao nhiêu trường hợp mà các yêu cầu mạng sau khi tải xong thật sự trở nên rất nhỏ; phần lớn SPA tôi từng gặp vẫn có nhiều request lớn ngay cả sau khi load, và chậm hơn rất nhiều so với việc gửi HTML trực tiếp; lập luận rằng JSON bằng cách nào đó nén tốt hơn HTML cũng không đứng vững, HTML cũng nén rất tốt; trên thực tế, lý lẽ rằng SPA tốt hơn vì vấn đề mạng gần như là tuyên truyền hay mê tín
Tôi nghĩ giá trị của SPA không chỉ là chuyển cảnh mượt mà mà còn ở chỗ phần lớn hành trình người dùng được xử lý phía client, khiến ta hầu như không phải bận tâm đến server; ví dụ, đến tận 2025 mà phần lớn cửa hàng online vẫn phải reload toàn bộ trang và tải lại dữ liệu mỗi khi đổi bộ lọc hay vào danh mục khác thì thật khó chịu; trong tình huống người dùng qua lại giữa các danh mục và tạo nhiều request, nếu có thể tải toàn bộ catalog xuống client một lần rồi lọc mà không cần giao tiếp thêm với server thì UX sẽ tốt hơn nhiều; tất nhiên sẽ có phản biện là dữ liệu lớn, nhưng phần lớn danh mục của cửa hàng chỉ cần vài KB, còn nhỏ hơn cả một ảnh sản phẩm; tôi đã làm những app kiểu này từ 2005 mà đến giờ vẫn không hiểu vì sao UX như vậy chưa phổ biến hơn
Theo tôi, điểm khó chịu nhất của việc phải full reload trang không nằm ở kích thước dữ liệu mà ở hiệu suất tổng thể của site; dữ liệu thực tế chỉ vài KB nhưng bản thân trang lại tải 100MB và trình duyệt ngốn 1GB RAM; ví dụ Hacker News chủ yếu điều hướng bằng reload mà vẫn chạy tốt trên laptop cũ, trong khi một SPA như DoorDash trên cùng thiết bị mất tới 30 giây, và để đặt được món ăn thật sự thì mất hơn 3 phút; phải chờ 2,5 phút chỉ để giao diện hiện ra, mà hầu như không phải do full reload
Các công cụ như HTMX giải quyết khá nhiều vấn đề này; tôi nghĩ cách làm SPA rốt cuộc dẫn đến việc phải xây hai ứng dụng riêng: frontend và backend; tôi cảm thấy tốt hơn nếu xử lý phần lớn ở server side, còn phía client chỉ thêm các hiệu ứng tương tác đơn giản như hiện/ẩn, mở rộng/thu gọn, hiệu ứng, v.v.; tất nhiên vẫn có những nơi SPA hữu ích
Tôi cũng có trải nghiệm tương tự: một vài dự án cá nhân được host trên static web server; thay vì render hàng chục nghìn trang riêng lẻ, tôi dùng một file JSON rồi render phía client trong SPA; cũng tận dụng Github Pages; gần đây còn thử nghiệm cấu trúc dùng bản build wasm của cơ sở dữ liệu sqlite để chỉ lấy các trang cần thiết bằng HTTP Range Requests; Full Text Search của sqlite cũng chạy được, nhưng với truy vấn ngắn thì vẫn phải tải cả bảng nên hơi tiếc; có lẽ tải toàn bộ DB về rồi tạo bảng FTS cục bộ còn tốt hơn
Cũng có ví dụ phản biện, chẳng hạn khi Shift-click mở danh mục “sci-fi” trong tab mới, với MPA thì gần như không cần nỗ lực gì, còn SPA phải tự xử lý nên phiền hơn; nếu không có link danh mục mà chỉ truy cập qua Select Box thì UX sẽ không hay
Nói chung các công ty không muốn người dùng tải toàn bộ catalog, vì đối thủ có thể phân tích dễ dàng hơn; ngoài ra với những trường hợp như bán sách có hàng trăm nghìn đầu sách, việc chuyển tất cả một lần vừa kém hiệu quả về UX vừa tốn băng thông/bộ nhớ
Mục đích của SPA tuyệt đối không phải là chuyển trang; hầu như không có SPA nào thực sự triển khai tốt chuyển trang; ví dụ trong Next.js, cách tải route khiến việc làm page transition gần như bất khả thi; tôi từng thật sự thêm tính năng chuyển trang tử tế vào Next.js và đó là cơn ác mộng; theo tôi, SPA có hai ưu điểm rõ ràng, thứ nhất là đa số app đều cần một mức độ tương tác nào đó nên HTML/CSS thuần là không đủ, và việc trộn React với HTML thuần là cực hình, nhất là khi cần global state; thứ hai, nếu tải sẵn toàn bộ cấu trúc trang thì việc tải dữ liệu về sau nhanh hơn, và phản hồi tức thời kèm màn hình loading sau cú click mang lại UX tốt hơn việc chờ tới 500ms mới có phản ứng, dù nếu chỉ dưới 100ms thì lại khác; vì không phải vẽ lại toàn bộ trang nên hiệu năng frontend mà HTML thuần mang lại không theo kịp; vẫn có những ví dụ như Basecamp xây web app phức tạp tốt mà không dùng SPA, nhưng chỉ cần bấm qua lại 30 giây là thấy không theo kịp hiệu năng của SPA; tôi cũng muốn web vận hành đúng bản chất của web, nhưng dù Next.js và SPA làm tăng thêm độ phức tạp, khiến phát triển vất vả hơn và tạo ra bundle lớn, thì chúng cũng giúp app nhanh hơn và phản hồi tốt hơn; dù vậy tôi vẫn nghĩ chỉ HTML thôi chưa thể đạt tới hiệu năng của SPA
Tôi không biết tác giả SEO consultant này đang sống ở vũ trụ nào nữa; lấy Next và Nuxt làm ví dụ tiêu biểu đối lập với SPA là hoàn toàn sai; 1. Next gần như thống trị hoàn toàn ở Mỹ/phương Tây, và khi nói về app React mới thì đa phần là đang chỉ Next; phía Vue thì Nuxt gần như là tiêu chuẩn, Nuxt = Next của hệ Vue; tức là mọi người đang vô thức chọn Next và chiến lược MPA; con lắc đã nghiêng quá mạnh về MPA nên ngược lại tôi còn muốn khuyên hãy thử SPA đi; 8 năm qua là giai đoạn cuồng MPA, và giờ ngay cả Facebook cũng chính thức khuyến nghị Next trong tài liệu thay cho Create React App; 2. Những lời phàn nàn về độ phức tạp của Next thực chất là nói về độ khó của chiến lược MPA hiện đại, còn phía SPA thì câu chuyện gần như đứng yên suốt 10 năm; 3. Phát triển MPA khó hơn SPA rất nhiều vì phải tách bạch server và client nghiêm ngặt hơn; 4. Nếu muốn dùng SPA mà lại tải dữ liệu theo kiểu MPA thì đó là lựa chọn của lập trình viên, và họ phải tự chịu ưu nhược điểm; cũng có thể preload dữ liệu để điều hướng trong SPA diễn ra tức thì; 5. Ngoài frontend chính thật sự cần SEO, còn có rất nhiều dashboard hoặc app nội bộ khác; lập trình viên React thường ở những chỗ đó, nên điều quan trọng là đừng tự mang thêm gánh nặng chỉ vì muốn tối ưu tuyệt đối khung hình đầu tiên
Tôi thấy giọng điệu hạ thấp SPA là không công bằng; đúng là SPA đòi hỏi nhiều công sức hơn, nhưng rõ ràng cũng có nhiều ưu điểm hơn; trong thời gian dài, SPA là cách duy nhất để tạo ra UX mang cảm giác như ứng dụng; tác giả có nhắc tới app fatigue, nhưng nếu thật sự muốn mang lại trải nghiệm ‘application’ thì SPA gần như là lựa chọn duy nhất; so sánh một SPA nặng với một website nhẹ (static site) là không phù hợp; nếu ai đó có thể làm một website nhẹ thì họ cũng có thể làm một SPA nhẹ; dù là SPA hay website, làm kém hiệu quả thì đều sẽ chậm và nặng như nhau; với tư cách người từng đầu tư rất nhiều vào SPA, tôi cũng rất quan tâm đến những cách tạo ra cùng trải nghiệm với ít công sức hơn, nhưng bài này hơi giống một chút tô vẽ bề ngoài; phần polish thì có giá trị, nhưng chưa đủ ảnh hưởng để quyết định có dùng SPA hay không
Bảo rằng “hãy thử làm linear.app mà không có framework SPA” thì tôi thấy là bất khả thi, và mệnh đề “Native CSS transitions đã giết lợi thế lớn nhất của SPA là client routing” cũng không có lý
Tôi nghĩ Linear là một trường hợp rất đặc biệt ngay cả trong thế giới SPA; không phải là cấm SPA hay đòi loại bỏ hoàn toàn JS khỏi trình duyệt; Linear nhanh vì được thiết kế theo hướng “offline first”, nhưng có rất ít dịch vụ làm vậy; còn bán vé, diễn đàn, tin tức, blog, website thông tin thì theo tôi phát triển dựa trên SSR tốt hơn nhiều; chỉ dùng SPA ở nơi thật sự cần, còn lại thì làm nhanh bằng SSR rồi dùng CSS để tạo cảm giác giống SPA sẽ hiệu quả hơn nhiều
Không phải SPA không có chỗ đứng, nhưng 99% còn lại của các site không cần là SPA
SPA không tồn tại vì view transition; bài gốc (TFA) ngầm ám chỉ rằng chuyển cảnh hào nhoáng giữa các trang là điều quan trọng, đó là suy nghĩ sai; thay vì đổ lỗi cho “CMO” hay “brand manager”, cần làm rõ giá trị cốt lõi của SPA; SPA là framework tuyệt vời cho logic phía client, cho việc tách biệt mối quan tâm giữa logic frontend và backend, cải thiện DX và từ đó tăng tốc độ phát triển, cùng nhiều ưu điểm khác; những bài kiểu này xuất hiện nhiều có lẽ vì cấu trúc của chúng dễ khơi ra tranh cãi như bình luận của tôi đây, nhưng thật ra tôi không nghĩ nó đáng được chú ý đến vậy
Với tôi, lời hứa chính của SPA không phải là chuyển cảnh mượt mà mà là xây dựng một data API và frontend tách biệt hoàn toàn với backend, nên tôi không thích việc trộn SSR với client rendering; hoặc là website, hoặc là app hẳn hoi
Tôi cũng thắc mắc “tiêu chí phân biệt SPA và MPA là gì?”; site cá nhân dùng Next.js của tôi thực ra render server-side gần như mọi thứ, technically là SPA, nhưng khi bật JS thì RSC và client-side navigation hoạt động, còn tắt JS thì các component chỉ dành cho client, ví dụ trình tạo mã QR, sẽ hiện nội dung thay thế, và phần còn lại vẫn được render hoàn toàn bằng SSR nên tuy hơi chậm hơn nhưng vẫn hoạt động tốt; theo tôi, cố tình không render component ở server mới là cách tốn công hơn; progressive enhancement là tốt nhất
Window loadcủa app xảy ra bao nhiêu lầnTôi cũng rất bức bối khi giới SEO hay các lập trình viên web mới vào nghề sau đại dịch cứ liên tục hiểu sai và hạ thấp SPA; với góc nhìn của người phát triển từ thập niên 2000, nguồn gốc thật sự của SPA không phải vì “lời hứa giả tạo” như bài gốc nói, mà vì từ cuối những năm 2000 đến đầu những năm 2010, chiến lược mobile-first lan rộng khiến frontend và backend phải được tách hẳn ra; trước đó frontend thường chỉ là render HTML bằng template phía server rồi rắc thêm chút jQuery, nhưng giờ cả app mobile lẫn desktop đều phải dùng chung business logic và DB, nên cấu trúc REST, bài luận của Roy Fielding, kiến trúc hướng dịch vụ và việc phơi bày API ra bên ngoài trở thành xu hướng chủ đạo; cũng có yếu tố tối ưu chi phí; trong giai đoạn này các framework web full-stack như Ruby on Rails hay Django từng rơi vào thời kỳ chững lại; Node.js đi lên, còn trình duyệt và thiết bị di động ngày càng mạnh, cho phép đẩy nhiều business logic lên phía “edge device”, tức client; đó mới chính là cốt lõi của SPA, và tôi không nghĩ CSS có thể thay thế nhu cầu đó