Khoảng 15 năm trước, tôi đang làm việc tại một công ty nơi chúng tôi xây dựng ứng dụng cho các đại lý du lịch, nhân viên sân bay và các công ty hàng không. Chúng tôi cũng đã xây dựng khung nội bộ của riêng mình cho các thành phần giao diện người dùng và khả năng của ứng dụng một trang. Chúng tôi có các thành phần cho mọi thứ: trường, nút, tab, phạm vi, bảng dữ liệu, menu, bộ chọn ngày, bộ chọn và nhiều bộ chọn. Chúng tôi thậm chí còn có thành phần div. Nhân tiện, thành phần div của chúng tôi rất tuyệt vời, nó cho phép chúng tôi thực hiện các góc tròn trên tất cả các trình duyệt, điều này dù bạn có tin hay không, không phải là một điều dễ dàng thực hiện vào thời điểm đó.
Công việc của chúng tôi diễn ra vào một thời điểm trong lịch sử khi JS, Ajax và HTML động được coi là một cuộc cách mạng đưa chúng tôi đến tương lai. Đột nhiên, chúng tôi có thể cập nhật trang một cách linh hoạt, lấy dữ liệu từ máy chủ và tránh phải điều hướng đến các trang khác, điều này được coi là chậm và nhấp nháy một hình chữ nhật lớn màu trắng trên màn hình giữa hai trang. Có một cụm từ được phổ biến bởi Jeff Atwood (người sáng lập StackOverflow): “Bất kỳ ứng dụng nào có thể viết bằng JavaScript cuối cùng cũng sẽ được viết bằng JavaScript.” – Jeff Atwood
Đối với chúng tôi vào thời điểm đó, điều này giống như một sự dám thực sự dám tạo ra những ứng dụng đó. Cảm giác giống như một sự chấp thuận chung để làm mọi thứ với JS. Vì vậy, chúng tôi đã làm mọi thứ với JS và chúng tôi không thực sự dành thời gian để nghiên cứu các cách làm khác. Chúng tôi không thực sự cảm thấy có động lực để tìm hiểu đúng những gì HTML và CSS có thể làm. Chúng tôi không thực sự coi web là một nền tảng ứng dụng đang phát triển. Chúng tôi chủ yếu coi đó là điều chúng tôi cần phải giải quyết, đặc biệt là khi liên quan đến hỗ trợ trình duyệt. Chúng ta có thể sử dụng thêm JS để hoàn thành công việc. Việc dành thời gian để tìm hiểu thêm về cách hoạt động của web và những gì có sẵn trên nền tảng này có giúp ích được cho tôi không? Chắc chắn rồi, tôi có thể đã loại bỏ một loạt mã không thực sự cần thiết. Nhưng vào thời điểm đó, có lẽ không nhiều đến thế. Bạn thấy đấy, hồi đó sự khác biệt về trình duyệt khá đáng kể. Đây là thời điểm Internet Explorer vẫn là trình duyệt thống trị, Firefox đứng thứ hai nhưng bắt đầu mất thị phần do Chrome nhanh chóng trở nên phổ biến. Mặc dù Chrome và Firefox khá giỏi trong việc thống nhất các tiêu chuẩn web, nhưng môi trường mà ứng dụng của chúng tôi đang chạy có nghĩa là chúng tôi phải hỗ trợ IE6 trong một thời gian dài. Ngay cả khi được phép hỗ trợ IE8, chúng tôi vẫn phải giải quyết rất nhiều điểm khác biệt giữa các trình duyệt. Không chỉ vậy, web thời đó còn không có nhiều khả năng được tích hợp ngay trên nền tảng.
Chuyển nhanh đến ngày hôm nay. Mọi thứ đã thay đổi rất nhiều. Chúng ta không chỉ có nhiều khả năng này hơn bao giờ hết mà tốc độ sử dụng chúng cũng tăng lên. Vậy hãy để tôi đặt lại câu hỏi: Việc dành thời gian để tìm hiểu thêm về cách hoạt động của web và những gì có sẵn trên nền tảng này có giúp ích gì cho bạn ngày hôm nay không? Hoàn toàn có. Học cách hiểu và sử dụng nền tảng web ngày nay mang lại cho bạn lợi thế rất lớn so với các nhà phát triển khác. Cho dù bạn làm việc về hiệu suất, khả năng truy cập, khả năng phản hồi, tất cả chúng cùng nhau hay chỉ cung cấp các tính năng giao diện người dùng, nếu bạn muốn làm điều đó với tư cách là một kỹ sư có trách nhiệm, việc biết các công cụ có sẵn sẽ giúp bạn đạt được mục tiêu của mình nhanh hơn và tốt hơn. Một số thứ bạn có thể không cần đến thư viện nữa Biết được những trình duyệt nào hiện nay hỗ trợ, câu hỏi đặt ra là: Chúng ta có thể bỏ đi những gì? Chúng ta có cần thành phần div để làm tròn các góc vào năm 2025 không? Tất nhiên là không. Thuộc tính bán kính đường viền đã được hỗ trợ bởi tất cả các trình duyệt hiện đang sử dụng trong hơn 15 năm tính đến thời điểm này. Và hình dạng góc cũng sắp ra mắt, dành cho những góc thậm chí còn đẹp hơn. Chúng ta hãy xem xét các tính năng tương đối gần đây hiện có sẵn trong tất cả các trình duyệt chính và bạn có thể sử dụng để thay thế các phần phụ thuộc hiện có trong cơ sở mã của mình. Vấn đề không phải là loại bỏ ngay lập tức tất cả các thư viện yêu thích của bạn và viết lại cơ sở mã của bạn. Đối với mọi thứ khác, trước tiên bạn cần tính đến hỗ trợ của trình duyệt và quyết định dựa trên các yếu tố khác cụ thể cho dự án của bạn. Các tính năng sau được triển khai trong ba công cụ trình duyệt chính (Chromium, WebKit và Gecko), nhưng bạn có thể có các yêu cầu hỗ trợ trình duyệt khác khiến bạn không thể sử dụng chúng ngay lập tức. Tuy nhiên, bây giờ vẫn là thời điểm tốt để tìm hiểu về các tính năng này và có thể dự định sử dụng chúng vào một lúc nào đó. Cửa sổ bật lên và hộp thoại API Popover, phần tử HTML
Chắc chắn, tốc độ kết nối internet của bạn cũng có thể tăng lên, nhưng điều đó không xảy ra với tất cả mọi người. Và không phải ai cũng có khả năng của thiết bị giống nhau. Thay vào đó, việc lấy mã của bên thứ ba cho những việc bạn có thể làm với nền tảng có thể có nghĩa là bạn gửi nhiều mã hơn và do đó tiếp cận được ít khách hàng hơn bình thường. Trên web, hiệu suất tải kém dẫn đến tỷ lệ bỏ qua lớn và làm tổn hại đến danh tiếng thương hiệu. Chạy ít mã hơn trên thiết bị Hơn nữa, mã bạn gửi trên thiết bị của khách hàng có thể chạy nhanh hơn nếu mã đó sử dụng ít phần tóm tắt JavaScript hơn trên nền tảng. Theo mặc định, nó cũng có thể phản hồi nhanh hơn và dễ truy cập hơn. Tất cả điều này dẫn đến ngày càng có nhiều khách hàng hài lòng hơn. Kiểm tra blog về khoảng cách bất bình đẳng về hiệu suất hàng năm của đồng nghiệp Alex Russell của tôi, cho thấy rằng các thiết bị cao cấp hầu như không có mặt ở các thị trường có hàng tỷ người dùng do chênh lệch giàu nghèo. Và khoảng cách này chỉ tăng lên theo thời gian.
Bố cục xây dựng tích hợp Một tính năng nền tảng web sắp ra mắt và tôi rất hào hứng là CSS Masonry.
Hãy để tôi bắt đầu bằng cách giải thích Masonry là gì. xây dựng là gì Masonry là một kiểu bố cục đã được Pinterest phổ biến từ nhiều năm trước. Nó tạo ra các bản nhạc nội dung độc lập trong đó các mục tự sắp xếp càng gần phần bắt đầu của bản nhạc càng tốt.
Nhiều người coi Masonry là một lựa chọn tuyệt vời cho danh mục đầu tư và thư viện ảnh, điều mà nó chắc chắn có thể làm được. Nhưng Masonry linh hoạt hơn những gì bạn thấy trên Pinterest và không chỉ giới hạn ở các bố cục giống như thác nước. Trong cách bố trí Masonry:
Các bản nhạc có thể là cột hoặc hàng:
Các bản nhạc nội dung không nhất thiết phải có cùng kích thước:
Các mục có thể trải dài trên nhiều bản nhạc:
Các vật phẩm có thể được đặt trên các bản nhạc cụ thể; họ không phải luôn tuân theo thuật toán sắp xếp tự động:
Bản demo Dưới đây là một số bản demo đơn giản mà tôi đã thực hiện bằng cách sử dụng triển khai CSS Masonry sắp tới trong Chrome. Bản demo thư viện ảnh, cho thấy các mục (tiêu đề trong trường hợp này) có thể trải rộng trên nhiều bản nhạc như thế nào:
Một thư viện ảnh khác hiển thị các bản nhạc có kích thước khác nhau:
Bố cục trang web tin tức với một số rãnh rộng hơn các rãnh khác và một số mục trải rộng trên toàn bộ chiều rộng của bố cục:
Một bảng Kanban hiển thị các mục có thể được đặt vào các rãnh cụ thể:
Lưu ý: Cáccác bản demo trước đó được tạo bằng phiên bản Chrome chưa có sẵn cho hầu hết người dùng web vì CSS Masonry chỉ mới bắt đầu được triển khai trên trình duyệt. Tuy nhiên, các nhà phát triển web đã vui vẻ sử dụng các thư viện để tạo bố cục Masonry trong nhiều năm rồi. Các trang web sử dụng Masonry ngày nay Thật vậy, Masonry khá phổ biến trên web ngày nay. Dưới đây là một vài ví dụ tôi tìm thấy ngoài Pinterest:
Và một vài ví dụ khác, ít rõ ràng hơn:
Vậy những bố cục này được tạo ra như thế nào? Cách giải quyết Một thủ thuật mà tôi từng thấy là sử dụng bố cục Flexbox, thay đổi hướng của nó thành cột và đặt nó ở chế độ bao bọc. Bằng cách này, bạn có thể đặt các mục có độ cao khác nhau trong nhiều cột độc lập, tạo ấn tượng về bố cục Masonry:
Tuy nhiên, có hai hạn chế với cách giải quyết này:
Thứ tự của các vật phẩm khác với thứ tự trong bố cục Masonry thực sự. Với Flexbox, các mục sẽ điền vào cột đầu tiên trước và khi nó đầy thì chuyển sang cột tiếp theo. Với Masonry, các vật phẩm sẽ xếp chồng lên nhau theo bất kỳ rãnh nào (hoặc cột trong trường hợp này) có nhiều không gian hơn. Ngoài ra, và có lẽ quan trọng hơn, cách giải quyết này yêu cầu bạn đặt chiều cao cố định cho vùng chứa Flexbox; nếu không, sẽ không có sự bao bọc nào xảy ra.
Thư viện Masonry của bên thứ ba Đối với các trường hợp nâng cao hơn, các nhà phát triển đã sử dụng thư viện. Thư viện nổi tiếng và phổ biến nhất cho việc này được gọi đơn giản là Masonry và được tải xuống khoảng 200.000 lần mỗi tuần theo NPM. Squarespace cũng cung cấp một thành phần bố cục hiển thị bố cục Masonry, một giải pháp thay thế không cần mã và nhiều trang web sử dụng bố cục đó. Cả hai tùy chọn này đều sử dụng mã JavaScript để đặt các mục trong bố cục. Xây dựng tích hợp Tôi thực sự vui mừng khi Masonry hiện bắt đầu xuất hiện trong trình duyệt dưới dạng tính năng CSS tích hợp. Theo thời gian, bạn sẽ có thể sử dụng Masonry giống như sử dụng Grid hoặc Flexbox, nghĩa là không cần bất kỳ giải pháp thay thế hoặc mã của bên thứ ba nào. Nhóm của tôi tại Microsoft đã và đang triển khai hỗ trợ Masonry tích hợp trong dự án nguồn mở Chrome, dựa trên đó Edge, Chrome và nhiều trình duyệt khác. Mozilla thực sự là nhà cung cấp trình duyệt đầu tiên đề xuất triển khai thử nghiệm Masonry vào năm 2020. Và Apple cũng rất quan tâm đến việc biến bố cục web mới nguyên thủy này thành hiện thực. Công việc chuẩn hóa tính năng này cũng đang được tiến hành với sự đồng ý trong nhóm làm việc CSS về hướng chung và thậm chí cả loại hiển thị mới: làn đường lưới. Nếu bạn muốn tìm hiểu thêm về Masonry và theo dõi tiến độ, hãy xem trang tài nguyên CSS Masonry của tôi. Theo thời gian, khi Masonry trở thành một tính năng Đường cơ sở, giống như Grid hoặc Flexbox, chúng ta sẽ có thể sử dụng nó một cách đơn giản và hưởng lợi từ:
Hiệu suất tốt hơn, Khả năng đáp ứng tốt hơn, Dễ sử dụng và mã đơn giản hơn.
Chúng ta hãy xem xét kỹ hơn những điều này. Hiệu suất tốt hơn Tạo hệ thống bố cục giống Masonry của riêng bạn hoặc thay vào đó sử dụng thư viện của bên thứ ba, có nghĩa là bạn sẽ phải chạy mã JavaScript để đặt các mục trên màn hình. Điều này cũng có nghĩa là mã này sẽ bị chặn hiển thị. Thật vậy, sẽ không có gì xuất hiện hoặc mọi thứ sẽ không ở đúng vị trí hoặc đúng kích cỡ cho đến khi mã JavaScript đó chạy. Bố cục khối xây thường được sử dụng cho phần chính của trang web, điều đó có nghĩa là mã sẽ làm cho nội dung chính của bạn xuất hiện muộn hơn bình thường, làm giảm LCP hoặc chỉ số Thời gian hiển thị nội dung lớn nhất, đóng vai trò lớn trong hiệu suất cảm nhận và tối ưu hóa công cụ tìm kiếm. Tôi đã thử nghiệm thư viện Masonry JS với bố cục đơn giản và bằng cách mô phỏng kết nối 4G chậm trong DevTools. Thư viện không lớn lắm (24KB, 7,8KB được nén bằng gzip), nhưng phải mất 600ms để tải trong điều kiện thử nghiệm của tôi. Đây là bản ghi hiệu suất cho thấy thời gian tải dài 600 mili giây cho thư viện Masonry và không có hoạt động hiển thị nào khác xảy ra trong khi điều đó đang diễn ra:
Ngoài ra, sau thời gian tải ban đầu, tập lệnh đã tải xuống cần được phân tích cú pháp, biên dịch và sau đó chạy. Tất cả những điều đó, như đã đề cập trước đó, đã chặn việc hiển thị trang. Với việc triển khai Masonry tích hợp sẵn trong trình duyệt, chúng tôi sẽ không có tập lệnh để tải và chạy. Công cụ trình duyệt sẽ chỉ thực hiện công việc của nó trong bước hiển thị trang đầu tiên. Phản hồi tốt hơn Tương tự như khi một trang tải lần đầu tiên, việc thay đổi kích thước cửa sổ trình duyệt sẽ dẫn đến việc hiển thị lại bố cục trong trang đó. Tuy nhiên, tại thời điểm này, nếu trang đang sử dụng thư viện Masonry JS thì không cần phải tải lại tập lệnh vì nó đãđây. Tuy nhiên, mã di chuyển các mục vào đúng vị trí cần phải chạy. Bây giờ thư viện cụ thể này dường như thực hiện việc này khá nhanh khi tải trang. Tuy nhiên, nó tạo hoạt ảnh cho các mục khi chúng cần di chuyển đến một vị trí khác khi thay đổi kích thước cửa sổ và điều này tạo ra sự khác biệt lớn. Tất nhiên, người dùng không mất thời gian thay đổi kích thước cửa sổ trình duyệt của họ nhiều như các nhà phát triển chúng tôi. Tuy nhiên, trải nghiệm thay đổi kích thước hoạt ảnh này có thể khá khó chịu và làm tăng thêm thời gian cần thiết để trang thích ứng với kích thước mới. Dễ sử dụng và mã đơn giản hơn Việc sử dụng một tính năng web dễ dàng như thế nào và mã trông đơn giản như thế nào là những yếu tố quan trọng có thể tạo ra sự khác biệt lớn cho nhóm của bạn. Tất nhiên, chúng không thể quan trọng bằng trải nghiệm người dùng cuối cùng, nhưng trải nghiệm của nhà phát triển ảnh hưởng đến khả năng bảo trì. Việc sử dụng tính năng web tích hợp mang lại những lợi ích quan trọng về mặt đó:
Các nhà phát triển đã biết HTML, CSS và JS rất có thể sẽ có thể sử dụng tính năng đó một cách dễ dàng vì nó được thiết kế để tích hợp tốt và nhất quán với phần còn lại của nền tảng web. Không có nguy cơ phá vỡ các thay đổi được đưa ra trong cách sử dụng tính năng này. Gần như không có nguy cơ tính năng đó không được dùng nữa hoặc không được bảo trì.
Trong trường hợp Masonry tích hợp, vì nó là bố cục nguyên thủy nên bạn sử dụng nó từ CSS, giống như Grid hoặc Flexbox, không liên quan đến JS. Ngoài ra, các thuộc tính CSS liên quan đến bố cục khác, chẳng hạn như khoảng cách, hoạt động như bạn mong đợi. Không có thủ thuật hay cách giải quyết nào cần biết và những điều bạn học được đều được ghi lại trên MDN. Đối với lib Masonry JS, việc khởi tạo hơi phức tạp: nó yêu cầu thuộc tính dữ liệu có cú pháp cụ thể, cùng với các phần tử HTML ẩn để đặt kích thước cột và khoảng trống. Ngoài ra, nếu bạn muốn mở rộng các cột, bạn cần tự bao gồm kích thước khoảng trống để tránh các vấn đề:
Hãy so sánh điều này với việc triển khai Masonry tích hợp sẽ như thế nào:
Mã đơn giản hơn, nhỏ gọn hơn có thể chỉ sử dụng những thứ như khoảng trống và nơi các rãnh kéo dài được thực hiện với nhịp 2, giống như trong lưới và không yêu cầu bạn tính toán độ rộng phù hợp bao gồm cả kích thước khoảng trống. Làm thế nào để biết những gì có sẵn và khi nào nó có sẵn? Nhìn chung, câu hỏi thực sự không phải là liệu bạn có nên sử dụng Masonry tích hợp trên thư viện JS hay không mà là khi nào. Thư viện Masonry JS thật tuyệt vời và đã lấp đầy khoảng trống trên nền tảng web trong nhiều năm và khiến nhiều nhà phát triển cũng như người dùng hài lòng. Tất nhiên, nó có một số nhược điểm nếu bạn so sánh nó với việc triển khai Masonry tích hợp sẵn, nhưng những điều đó không quan trọng nếu việc triển khai đó chưa sẵn sàng. Thật dễ dàng để tôi liệt kê các tính năng nền tảng web mới thú vị này vì tôi làm việc tại một nhà cung cấp trình duyệt và do đó tôi có xu hướng biết điều gì sắp xảy ra. Nhưng các nhà phát triển thường chia sẻ, hết khảo sát này đến khảo sát khác, rằng việc theo dõi những điều mới là điều khó khăn. Luôn cập nhật thông tin là điều khó khăn và các công ty không phải lúc nào cũng ưu tiên việc học hỏi. Để trợ giúp việc này, dưới đây là một số tài nguyên cung cấp thông tin cập nhật theo những cách đơn giản và gọn nhẹ để bạn có thể nhanh chóng nhận được thông tin mình cần:
Nền tảng Web có trang web thám hiểm: Bạn có thể quan tâm đến trang ghi chú phát hành của nó. Và nếu bạn thích RSS, hãy xem nguồn cấp dữ liệu ghi chú phát hành cũng như nguồn cấp dữ liệu Cơ sở mới có sẵn và có sẵn rộng rãi.
WebTrang tổng quan Trạng thái nền tảng: Bạn có thể thích các trang Năm cơ sở khác nhau của nó.
Trang lộ trình của Trạng thái nền tảng Chrome.
Nếu có thêm chút thời gian, bạn cũng có thể quan tâm đến ghi chú phát hành của nhà cung cấp trình duyệt:
Chrome Cạnh Firefox Safari
Để biết thêm tài nguyên, hãy xem Bảng tóm tắt Điều hướng nền tảng web của tôi. Điều của tôi vẫn chưa được thực hiện Đó là mặt khác của vấn đề. Ngay cả khi bạn tìm thấy thời gian, sức lực và các cách để theo dõi, bạn vẫn cảm thấy thất vọng khi nhận được tiếng nói của mình và triển khai các tính năng yêu thích của mình. Có thể bạn đã chờ đợi hàng năm trời để một lỗi cụ thể được giải quyết hoặc một tính năng cụ thể nào đó được đưa vào trình duyệt mà nó vẫn còn thiếu. Điều tôi sẽ nói là các nhà cung cấp trình duyệt sẽ lắng nghe. Tôi là thành viên của một số nhóm liên tổ chức, nơi chúng tôi luôn thảo luận về các tín hiệu và phản hồi của nhà phát triển. Chúng tôi xem xét nhiều nguồn phản hồi khác nhau, cả từ nội bộ của mỗi nhà cung cấp trình duyệt và bên ngoài/công chúng trên các diễn đàn, dự án nguồn mở, blog và khảo sát. Và chúng tôi luôn cố gắng tạo ra những cách tốt hơn để các nhà phát triển chia sẻ nhu cầu và trường hợp sử dụng cụ thể của họ. Vì vậy, nếu có thể, vui lòng yêu cầu nhiều hơn từ các nhà cung cấp trình duyệt và gây áp lực buộc chúng tôi triển khai các tính năng bạn cần. Tôi hiểu rằng việc này cần có thời gian và cũng có thể đáng sợ (chưa kể đến rào cản gia nhập cao), nhưng nó cũng có tác dụng. Dưới đây là một số cách bạn có thể khiến tiếng nói của mình (hoặc công ty bạn) được lắng nghe: Tham gia các cuộc khảo sát hàng năm về Trạng thái JS, Trạng thái CSS và Trạng thái HTML. Họ đóng một vai trò lớn trong việc các nhà cung cấp trình duyệt ưu tiên công việc của họ như thế nào. Nếu bạn cần triển khai nhất quán một API dựa trên tiêu chuẩn cụ thể trên các trình duyệt, hãy cân nhắc việc gửi đề xuất ở lần lặp lại dự án Interop tiếp theo. Việc này cần nhiều thời gian hơn nhưng hãy xem xét cách Shopify và RUMvision chia sẻ danh sách mong muốn của họ cho Interop 2026. Thông tin chi tiết như thế này có thể rất hữu ích để các nhà cung cấp trình duyệt ưu tiên. Để biết thêm các liên kết hữu ích nhằm tác động đến các nhà cung cấp trình duyệt, hãy xem Bảng điều khiển nền tảng web của tôi. Kết luận Để kết thúc, tôi hy vọng bài viết này đã để lại cho bạn một vài điều để suy nghĩ:
Sự phấn khích dành cho Masonry và các tính năng web sắp ra mắt khác. Một số tính năng web mà bạn có thể muốn bắt đầu sử dụng. Bạn có thể xóa một vài đoạn mã tùy chỉnh hoặc mã của bên thứ 3 để sử dụng các tính năng tích hợp sẵn. Một số cách để theo dõi những gì sắp xảy ra và ảnh hưởng đến các nhà cung cấp trình duyệt.
Quan trọng hơn, tôi hy vọng tôi đã thuyết phục được bạn về lợi ích của việc sử dụng hết tiềm năng của nền tảng web.
