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.
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”.
Đú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.
Theo tôi biết, khi dùng trong Kotlin, có thể sẽ có vấn đề về hiệu năng vì primitive bị bọc bằng wrapper nên được lưu trên heap thay vì stack. Tất nhiên, trong phần lớn use case, khả năng bảo trì vẫn được ưu tiên hơn. Ngoài ra, có thể giảm thiểu vấn đề hiệu năng bằng cách sử dụng value class.
LLM không phải là không có nhược điểm, nhưng khó mà đồng ý rằng mọi dịch vụ AI đều không có khả năng sinh lời. Tôi nghĩ rằng trong vòng 5 năm tới, gần như tất cả các dịch vụ nền tảng hiện nay sẽ phần lớn được thay thế bởi các AI agent.
Có muốn tôi soạn riêng bản tóm tắt này theo định dạng báo cáo tóm tắt PDF (tổng quan tóm tắt - mở đầu - nội dung chính - kết luận) không?
Vì đây là người vốn cũng thường xuyên đăng nhiều bài, nên có vẻ họ cố ý chèn cái này vào nhỉ ha ha ha
Đúng là một bài viết thú vị. Có lẽ tốt hơn là nên tự động não trước rồi mới dùng LLM.
Ưu điểm của Ada phần lớn nghiêng về phía “ổn hơn C”. Trong C, có khá nhiều thứ được cho phép vì tin tưởng vào lập trình viên. Những thứ như chuyển đổi kiểu ngầm chẳng hạn. Nhưng có vẻ đa số lập trình viên vẫn thích C hơn vì đã quen với nó...
Có thể đây là đặc điểm của codebase mà tôi đang làm việc, nhưng chúng tôi khai báo và sử dụng gần như mọi thứ bằng các kiểu riêng biệt. Kiểu cơ bản gần như chỉ dùng cho chỉ số mảng.
Đ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.
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”.
Đú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ật tuyệt vì có nhiều nội dung đáng để suy ngẫm khi làm việc với tìm kiếm vector.
Theo tôi biết, khi dùng trong Kotlin, có thể sẽ có vấn đề về hiệu năng vì
primitivebị bọc bằng wrapper nên được lưu trên heap thay vì stack. Tất nhiên, trong phần lớn use case, khả năng bảo trì vẫn được ưu tiên hơn. Ngoài ra, có thể giảm thiểu vấn đề hiệu năng bằng cách sử dụngvalue class.Tham khảo thêm ticket hỗ trợ Rust: https://github.com/android/ndk/issues/1742
Mong là C++ cũng có mấy thứ như thế này!
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?
Vì chạy cục bộ nên có vẻ sẽ không cần trả phí.
Chỉ để làm việc đó mà tốn $20 ~ $200 mỗi tháng thì hơi…
Trong khi đó, Pass:
Hmm... ^^;;; Tôi đã mắc lỗi.. Lần sau tôi sẽ xem lại kỹ hơn một chút rồi đăng lên..
LLM không phải là không có nhược điểm, nhưng khó mà đồng ý rằng mọi dịch vụ AI đều không có khả năng sinh lời. Tôi nghĩ rằng trong vòng 5 năm tới, gần như tất cả các dịch vụ nền tảng hiện nay sẽ phần lớn được thay thế bởi các AI agent.
Vì đây là người vốn cũng thường xuyên đăng nhiều bài, nên có vẻ họ cố ý chèn cái này vào nhỉ ha ha ha
Đúng là một bài viết thú vị. Có lẽ tốt hơn là nên tự động não trước rồi mới dùng LLM.
Đúng là độ chính xác và cảm giác làm chủ đều thấp.
Ngay cả phần tóm tắt cũng là llm..
Tôi hiểu rồi, cảm ơn bạn.
Ưu điểm của Ada phần lớn nghiêng về phía “ổn hơn C”. Trong C, có khá nhiều thứ được cho phép vì tin tưởng vào lập trình viên. Những thứ như chuyển đổi kiểu ngầm chẳng hạn. Nhưng có vẻ đa số lập trình viên vẫn thích C hơn vì đã quen với nó...
Có thể đây là đặc điểm của codebase mà tôi đang làm việc, nhưng chúng tôi khai báo và sử dụng gần như mọi thứ bằng các kiểu riêng biệt. Kiểu cơ bản gần như chỉ dùng cho chỉ số mảng.
Cho tôi hỏi vì tò mò. Ngoài ra còn có những ưu điểm khác biệt so với các ngôn ngữ kiểu dữ liệu phổ biến khác không? (
kotlin,rust,typescript, ...)Tôi đồng ý.