0
0
Lập trình
Admin Team
Admin Teamtechmely

Chuyển Đổi Web: Tại Sao SPA Đang Chiếm Lĩnh?

Đăng vào 7 tháng trước

• 6 phút đọc

Giới thiệu

Trong bài viết trước, chúng ta đã thấy cách AJAX và jQuery đã biến đổi web từ mô hình tĩnh, yêu cầu - phản hồi thành một điều gì đó động và tương tác hơn rất nhiều.

Tuy nhiên, khi các ứng dụng trở nên phức tạp hơn, các đoạn mã jQuery, thao tác DOM tuần tự và logic rải rác bắt đầu trở nên khó quản lý. Chúng ta cần nhiều hơn những đoạn mã nhỏ — chúng ta cần một cấu trúc rõ ràng.

Đó là lúc Ứng dụng Một Trang (SPA) ra đời.


SPA là gì?

Một Ứng dụng Một Trang là một ứng dụng web mà:

  • Tải một trang HTML duy nhất ban đầu
  • Sử dụng JavaScript để quản lý định tuyến, hiển thị và cập nhật dữ liệu
  • Tương tác với máy chủ qua APIs (thường là JSON qua HTTP)
  • Tránh hoàn toàn việc tải lại toàn bộ trang

Trong SPA, trình duyệt trở thành môi trường thực thi — không chỉ là lớp hiển thị.


Sự Chuyển Đổi Cốt Lõi

Dưới đây là cách mà trách nhiệm đã thay đổi từ máy chủ sang trình duyệt:

Toàn bộ ứng dụng giờ đây sống ở phía frontend.


Điều Gì Đã Thay Đổi Trong Trải Nghiệm Phát Triển?

SPA đi kèm với các framework JavaScript đã giới thiệu những ý tưởng mạnh mẽ mới:

Thành phần

Giao diện người dùng được chia thành những phần nhỏ, có thể tái sử dụng với logic và trạng thái riêng.

Virtual DOM & Kết xuất Khai báo

Thay vì thay đổi DOM một cách thủ công, bạn định nghĩa giao diện người dùng nên trông như thế nào, và framework sẽ tự động tìm cách cập nhật nó.

Định tuyến phía client

Không còn tải lại trang — các framework như React Router quản lý điều hướng trong trình duyệt thông qua API Lịch sử.

Quản lý trạng thái Frontend

Các thư viện như Redux và Vuex quản lý trạng thái và hành vi phức tạp ở phía client.


Quá Nhiều jQuery → Một Cơn Lũ Các Framework

jQuery đã mang lại sức mạnh — nhưng nó không phù hợp cho các ứng dụng lớn.

Các nhà phát triển đã:

  • Chọn thủ công các phần tử DOM
  • Thay đổi giao diện người dùng dựa trên trạng thái
  • Viết mã hỗn độn với callback và logic nội tuyến

Sự hỗn loạn này tạo ra nhu cầu về cấu trúc. Và điều đó đã khơi dậy sự bùng nổ của các thư viện và framework:

  • Backbone.js – cung cấp cấu trúc cho mô hình, chế độ xem và router
  • Knockout.js – giới thiệu các liên kết khai báo với data-bind
  • AngularJS – cung cấp dữ liệu hai chiều và cấu trúc ứng dụng đầy đủ
  • React – tập trung vào việc kết hợp các thành phần và luồng dữ liệu một chiều
  • Vue – kết hợp sự đơn giản với cấu trúc, nhanh chóng trở nên phổ biến

Tất cả những điều này đều là câu trả lời cho cùng một vấn đề: “jQuery rất mạnh, nhưng chúng ta cần nhiều kỷ luật hơn.”


Ví Dụ Thực Tế: Một Bảng Điều Khiển

Trong thế giới SPA, một bảng điều khiển không tải lại — nó cập nhật trực tiếp:

  • Nhấp vào các liên kết bên sẽ không tải lại trang
  • Dữ liệu được lấy ở nền và hiển thị ngay lập tức
  • Các modal, dropdown và form đều sống trong bộ nhớ
  • Toàn bộ giao diện có thể tái sử dụng và thay đổi động

Người dùng giờ đây mong đợi mức độ mượt mà này theo mặc định.


Nhưng Có Những Đánh Đổi

Xác Thực Trở Thành Trách Nhiệm Chung

Trong các ứng dụng được render trên máy chủ truyền thống, xác thực chỉ xảy ra ở phía backend. Nếu bạn gửi một form với email không hợp lệ hoặc trường trống, máy chủ sẽ từ chối và gửi lại lỗi.

Trong SPA, người dùng mong đợi phản hồi ngay lập tức.

Điều đó có nghĩa là:

  • Frontend phải xác thực đầu vào trước khi gửi (để tăng tốc và cải thiện trải nghiệm người dùng)
  • Backend vẫn cần xác thực dữ liệu (để đảm bảo an ninh và tính chính xác)

Vì vậy, giờ đây, logic xác thực bị trùng lặp — trong hai ngôn ngữ khác nhau (JavaScript và PHP/Node/etc.). Điều này làm cho phát triển trở nên phức tạp và dễ gặp lỗi, đặc biệt là đối với các nhóm cố gắng giữ nhất quán.


SEO Bị Ảnh Hưởng — Và Chúng Tôi Đã Cố Gắng Khắc Phục

Một trong những nhược điểm lớn nhất của SPA là SEO.

Các ứng dụng nhiều trang truyền thống đã render HTML trên máy chủ, mà các công cụ tìm kiếm có thể dễ dàng thu thập và lập chỉ mục. Nhưng SPA chỉ tải một <div id="app"> trống và dựa vào JavaScript để xây dựng giao diện người dùng — có nghĩa là các bot thấy một trang trống.

Đây là một vấn đề lớn đối với:

  • Blog
  • Trang web marketing
  • Nền tảng thương mại điện tử
  • Bất kỳ nội dung công khai nào cần có khả năng khám phá

Những Nỗ Lực Giải Quyết

Để khắc phục SEO trong SPA, các nhà phát triển đã thử nhiều cách giải quyết:

  1. Tiền render / Tạo tĩnh: Đối với các trang không thay đổi thường xuyên (như trang đích), các công cụ như prerender.io, Gatsby, hoặc tính năng tạo tĩnh của Next.js sẽ xuất ra HTML thuần tại thời điểm biên dịch.
  2. Render phía máy chủ (SSR): Các framework như Next.js (React), Nuxt.js (Vue), và Angular Universal cho phép các ứng dụng JavaScript chạy trên máy chủ và trả về HTML đã được render đầy đủ cho bot và người dùng.
  3. Hydration: Sau SSR hoặc tạo tĩnh, JS phía frontend "hydrat" trang — gán các listener sự kiện và kích hoạt lại tính tương tác. Điều này mang lại cả hai thế giới: HTML sẵn sàng cho SEO và giao diện người dùng động.
  4. Render động cho Bot: Một số nhóm đã thiết lập logic để phát hiện bot và phục vụ HTML đã được tiền render, trong khi phục vụ SPA cho người dùng thực. Điều này khá phức tạp và dễ mắc lỗi, nhưng đôi khi là cần thiết.

Mặc dù những chiến lược này đã giúp ích, chúng lại tạo ra sự phức tạp, chi phí công cụ và thường xuyên gặp phải các vấn đề về hiệu suất. Rõ ràng rằng SPA không phải lúc nào cũng là lựa chọn mặc định tốt nhất — đặc biệt là đối với các trang đầu tiên về nội dung.


Backend Bị Giảm Xuống Chỉ Còn APIs

Khi frontend đảm nhận nhiều trách nhiệm hơn — render, định tuyến, trạng thái, xác thực — backend đã bị đẩy vào nền.

Vai trò mới của nó:

  • Cung cấp các tệp tĩnh (index.html, JS bundles)
  • Cung cấp RESTful APIs hoặc endpoints GraphQL
  • Xử lý xác thực, lưu trữ dữ liệu và xác thực trên máy chủ

Backend không còn kiểm soát trải nghiệm người dùng — nó chỉ đơn thuần là nhà cung cấp dữ liệu.

Sự chuyển đổi này đã tạo ra các thuật ngữ như:

  • “Backend đầu”
  • “Kiến trúc API-first”
  • “Ứng dụng nặng phía frontend”

Tại Sao Giai Đoạn Này Quan Trọng

SPAs đại diện cho đỉnh cao của kiến trúc tập trung vào frontend. Trong gần một thập kỷ, “phát triển web hiện đại” có nghĩa là:

  • Xây dựng mọi thứ bằng JavaScript
  • Giao tiếp với APIs
  • Gửi các gói
  • Hydrate DOM

Tư duy này đã chi phối công cụ, framework, tuyển dụng và trải nghiệm người dùng.

Nhưng giờ đây, ngành công nghiệp đang chuyển mình một lần nữa — hướng tới việc tái cân bằng trách nhiệm, cải thiện hiệu suất và khám phá lại sức mạnh của việc render HTML đầu tiên.


Tóm tắt

SPAs đã thay đổi cuộc chơi bằng cách:

  • Mang lại đầy đủ định tuyến và render cho trình duyệt
  • Đưa JavaScript trở thành trung tâm của trải nghiệm web
  • Khởi đầu một kỷ nguyên mới của các framework frontend

Nhưng với sức mạnh đó đi kèm với những vấn đề mới — và đó chính là những gì đã đặt nền tảng cho giai đoạn chuyển tiếp tiếp theo.

Trong phần 4, chúng ta sẽ xem web đang hướng tới đâu — với việc render phía máy chủ, khả năng tiếp tục và sự chú ý trở lại vào sự đơn giản và tốc độ.


Nếu bạn thấy bài viết này hữu ích, hãy xem xét việc hỗ trợ công việc của tôi — điều đó có ý nghĩa rất nhiều.

Gợi ý câu hỏi phỏng vấn
Không có dữ liệu

Không có dữ liệu

Bài viết được đề xuất
Bài viết cùng tác giả

Bình luận

Chưa có bình luận nào

Chưa có bình luận nào