Wow, đúng là một chương trình tuyệt vời. Có vẻ như tác giả là người Na Uy. Thật đáng khâm phục khi lại tạo ra một chương trình chất lượng cao như vậy chỉ vì niềm vui rồi còn công khai nó. Càng cảm nhận rõ hơn rằng thế giới rộng lớn và có rất nhiều thiên tài. Các nhà phát triển Hàn Quốc cũng hãy cố gắng để một lần tạo ra thứ tuyệt vời như thế này rồi công khai nhé.
Bản thân ý tưởng này thì thỉnh thoảng tôi cũng từng thấy, nhưng trang web được làm rất thú vị và được sắp xếp khéo léo để có thể trải nghiệm tính năng ngay trong một cái nhìn, nên tôi đã khá bất ngờ.
Đang lúc buồn ngủ mà mắt bỗng sáng hẳn lên, đúng là một trải nghiệm vui.
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...
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.
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.
Không phải mọi thứ đều là endofunctor. Những kiểu có nhiều tham số kiểu như Result<T, E> thì không phải là 𝒞 → 𝒞, mà là Result : 𝒞 × 𝒞 → 𝒞, nên những cái như vậy là bifunctor.
Đúng là một nhận xét rất chính xác!
Có vẻ như đã có sự hiểu nhầm trong quá trình áp dụng nội dung được viết bằng ngôn ngữ khác theo tiêu chuẩn của Rust.
Vì hệ thống kiểu của Rust tạo thành một phạm trù đơn, nên có lẽ việc phân biệt giữa endofunctor và functor thông thường là không có nhiều ý nghĩa.
Thật tiếc là blog không có chức năng bình luận, nên tôi sẽ phải hỏi xem có thể yêu cầu chỉnh sửa hay không.
Có vẻ người này đang nói về chi phí đăng ký IDE. FLCC không được cung cấp trong phiên bản miễn phí.
Nhưng cũng không phải mọi người trả tiền chỉ vì mỗi thứ đó.
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.
Wow, đúng là một chương trình tuyệt vời. Có vẻ như tác giả là người Na Uy. Thật đáng khâm phục khi lại tạo ra một chương trình chất lượng cao như vậy chỉ vì niềm vui rồi còn công khai nó. Càng cảm nhận rõ hơn rằng thế giới rộng lớn và có rất nhiều thiên tài. Các nhà phát triển Hàn Quốc cũng hãy cố gắng để một lần tạo ra thứ tuyệt vời như thế này rồi công khai nhé.
Bên đó cũng chỉ đông người thôi chứ làm việc thì ở đâu cũng như nhau cả haha
Đây đúng là cuộc sống thường nhật của một đất nước quen thuộc, bắt đầu bằng "Hàn" và kết thúc bằng "Quốc".
Bản thân ý tưởng này thì thỉnh thoảng tôi cũng từng thấy, nhưng trang web được làm rất thú vị và được sắp xếp khéo léo để có thể trải nghiệm tính năng ngay trong một cái nhìn, nên tôi đã khá bất ngờ.
Đang lúc buồn ngủ mà mắt bỗng sáng hẳn lên, đúng là một trải nghiệm vui.
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...
Thật ra cũng có một số người chẳng có việc gì làm nhưng vẫn cố chạy đa phiên để tận dụng cho bõ tiền...
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.
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.
Không phải mọi thứ đều là endofunctor. Những kiểu có nhiều tham số kiểu như
Result<T, E>thì không phải là 𝒞 → 𝒞, mà là Result : 𝒞 × 𝒞 → 𝒞, nên những cái như vậy là bifunctor.Đúng là một nhận xét rất chính xác!
Có vẻ như đã có sự hiểu nhầm trong quá trình áp dụng nội dung được viết bằng ngôn ngữ khác theo tiêu chuẩn của Rust.
Vì hệ thống kiểu của Rust tạo thành một phạm trù đơn, nên có lẽ việc phân biệt giữa endofunctor và functor thông thường là không có nhiều ý nghĩa.
Thật tiếc là blog không có chức năng bình luận, nên tôi sẽ phải hỏi xem có thể yêu cầu chỉnh sửa hay không.
Bài viết hay đấy! Tuy nhiên, phần giải thích liên quan đến endofunctor có lỗi nên sẽ tốt hơn nếu được đính chính: https://x.com/simnalamburt/status/1950074970647761168?s=46
king - man + woman = queen
Những tính năng mà cứ nghĩ là “giá mà có thì tốt” đều có đủ cả. Chỉ riêng nó thôi mà đã làm được mọi việc của một NAS rồi.
Chỉ nhìn trang demo thôi cũng đã thấy cực kỳ ấn tượng. Với đoạn mã thật sự rất ngắn mà vẫn hỗ trợ được nhiều tính năng đa dạng.
Namuwiki...
Tôi không hiểu làm sao xác minh độ tuổi và bảo vệ quyền riêng tư có thể đi cùng nhau được..
Ngay khoảnh khắc thực hiện xác minh thì chẳng phải ít nhất một lần tôi cũng đã để lại chữ ký của mình ở đó rồi sao?
Nếu thật sự muốn bảo vệ quyền riêng tư thì phải có thể dùng ẩn danh chứ
Tuyệt vời. Tôi rất thích cách tiếp cận này.
Đây đúng là một phương pháp tối ưu hóa không dựa trên ML khá đáng mừng.
Có vẻ người này đang nói về chi phí đăng ký IDE. FLCC không được cung cấp trong phiên bản miễn phí.
Nhưng cũng không phải mọi người trả tiền chỉ vì mỗi thứ đó.
Đ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.