Około 15 lat temu pracowałem w firmie, w której tworzyliśmy aplikacje dla biur podróży, pracowników lotnisk i linii lotniczych. Zbudowaliśmy także własny, wewnętrzny framework dla komponentów interfejsu użytkownika i możliwości aplikacji jednostronicowych. Mieliśmy komponenty do wszystkiego: pola, przyciski, karty, zakresy, tabele danych, menu, elementy datepicker, selekcje i selekcje wielokrotne. Mieliśmy nawet komponent div. Swoją drogą, nasz komponent div był świetny, pozwalał nam na zaokrąglanie rogów we wszystkich przeglądarkach, co – wierzcie lub nie – nie było wówczas łatwe.
Nasza praca miała miejsce w takim momencie naszej historii, kiedy JS, Ajax i dynamiczny HTML były postrzegane jako rewolucja, która przeniosła nas w przyszłość. Nagle mogliśmy dynamicznie aktualizować stronę, pobierać dane z serwera i unikać konieczności przechodzenia do innych stron, co było postrzegane jako powolne i powodowało miganie dużego białego prostokąta na ekranie pomiędzy dwiema stronami. Było takie zdanie spopularyzowane przez Jeffa Atwooda (założyciela StackOverflow), które brzmiało: „Każda aplikacja, którą można napisać w JavaScript, ostatecznie zostanie napisana w JavaScript” – Jeff Atwood
W tamtym czasie wydawało nam się, że mamy odwagę stworzyć takie aplikacje. To było jak ogólna zgoda na robienie wszystkiego z JS. Zrobiliśmy więc wszystko w JS i tak naprawdę nie traciliśmy czasu na szukanie innych sposobów działania. Tak naprawdę nie czuliśmy motywacji, aby właściwie poznać możliwości HTML i CSS. Tak naprawdę nie postrzegaliśmy sieci jako całości rozwijającej się platformy aplikacji. Przeważnie postrzegaliśmy to jako coś, nad czym musimy popracować, szczególnie jeśli chodzi o obsługę przeglądarek. Moglibyśmy po prostu rzucić na to więcej JS, żeby załatwić sprawę. Czy poświęcenie czasu na dowiedzenie się więcej o tym, jak działa sieć i co jest dostępne na platformie, pomogłoby mi? Jasne, prawdopodobnie mógłbym wygolić trochę kodu, który nie był tak naprawdę potrzebny. Ale w tamtym czasie może nie aż tak bardzo. Widzisz, różnice w przeglądarkach były wtedy dość znaczące. Był to czas, gdy Internet Explorer był nadal dominującą przeglądarką, a Firefox znajdował się tuż obok, ale zaczął tracić udział w rynku ze względu na szybki wzrost popularności przeglądarki Chrome. Chociaż Chrome i Firefox dość dobrze uzgadniały standardy sieciowe, środowiska, w których działały nasze aplikacje, sprawiły, że przez długi czas musieliśmy wspierać IE6. Nawet gdy pozwolono nam obsługiwać IE8, nadal musieliśmy radzić sobie z wieloma różnicami między przeglądarkami. Co więcej, ówczesna sieć po prostu nie miała tak wielu funkcji wbudowanych bezpośrednio w platformę.
Przejdźmy szybko do dzisiaj. Wszystko zmieniło się ogromnie. Nie tylko mamy więcej tych możliwości niż kiedykolwiek wcześniej, ale także wzrosło tempo ich udostępniania. W takim razie zadam jeszcze raz pytanie: czy poświęcenie czasu na dowiedzenie się więcej o tym, jak działa sieć i co jest dostępne na platformie, pomogłoby Ci dzisiaj? Absolutnie tak. Dzisiejsza nauka zrozumienia i korzystania z platformy internetowej daje Ci ogromną przewagę nad innymi programistami. Niezależnie od tego, czy pracujesz nad wydajnością, dostępnością, responsywnością, wszystkim razem, czy po prostu dostarczasz funkcje interfejsu użytkownika, jeśli chcesz to robić jako odpowiedzialny inżynier, znajomość dostępnych Ci narzędzi pomoże Ci szybciej i lepiej osiągnąć swoje cele. Niektóre rzeczy, do których możesz nie potrzebować już biblioteki Wiedząc, jakie przeglądarki obsługują obecnie, pojawia się pytanie: z czego możemy zrezygnować? Czy w 2025 r. potrzebujemy komponentu div do zaokrąglania rogów? Oczywiście, że nie. Właściwość border-radius jest obsługiwana przez wszystkie obecnie używane przeglądarki od ponad 15 lat. Wkrótce dostępny będzie także kształt narożnika, który umożliwi zastosowanie jeszcze bardziej wyszukanych narożników. Przyjrzyjmy się stosunkowo nowym funkcjom, które są teraz dostępne we wszystkich głównych przeglądarkach i których można użyć do zastąpienia istniejących zależności w bazie kodu. Nie chodzi o to, aby od razu porzucić wszystkie ulubione biblioteki i przepisać bazę kodu. Jeśli chodzi o wszystko inne, musisz najpierw wziąć pod uwagę obsługę przeglądarki i podjąć decyzję na podstawie innych czynników specyficznych dla Twojego projektu. Poniższe funkcje są zaimplementowane w trzech głównych silnikach przeglądarek (Chromium, WebKit i Gecko), ale możesz mieć inne wymagania dotyczące obsługi przeglądarek, które uniemożliwiają ich natychmiastowe użycie. Jednak teraz jest dobry moment, aby dowiedzieć się o tych funkcjach i być może zaplanować ich użycie w pewnym momencie. Popover i okna dialogowe Interfejs API Popover, element HTML
Jasne, prędkość Twojego połączenia internetowego prawdopodobnie również wzrosła, ale nie dotyczy to wszystkich. Nie każdy ma też takie same możliwości urządzenia. Zamiast tego pobieranie kodu strony trzeciej do rzeczy, które możesz zrobić za pomocą platformy, najprawdopodobniej oznacza, że wysyłasz więcej kodu, a tym samym docierasz do mniejszej liczby klientów niż zwykle. W Internecie zła wydajność ładowania prowadzi do dużej liczby porzuceń i szkodzi reputacji marki. Uruchamianie mniejszej liczby kodu na urządzeniach Co więcej, kod, który wysyłasz na urządzenia swoich klientów, prawdopodobnie działa szybciej, jeśli na platformie wykorzystuje mniej abstrakcji JavaScript. Domyślnie jest też prawdopodobnie bardziej responsywny i bardziej dostępny. Wszystko to sprawia, że klienci są coraz bardziej zadowoleni. Sprawdź roczny blog mojego kolegi Alexa Russella na temat luk w wydajności, z którego wynika, że urządzeń premium w dużej mierze nie ma na rynkach z miliardami użytkowników ze względu na nierówności majątkowe. A różnica ta z biegiem czasu tylko się pogłębia.
Wbudowany układ murowy Jedną z funkcji platformy internetowej, która już wkrótce będzie dostępna i z której jestem bardzo podekscytowany, jest CSS Masonry.
Zacznę od wyjaśnienia, czym jest masoneria. Co to jest masoneria Murarstwo to rodzaj układu, który spopularyzował się na Pintereście wiele lat temu. Tworzy niezależne ścieżki zawartości, w których elementy pakują się możliwie najbliżej początku ścieżki.
Wiele osób postrzega murarstwo jako świetną opcję na portfolio i galerie zdjęć, co z pewnością może zrobić. Ale masoneria jest bardziej elastyczna niż to, co widzisz na Pintereście i nie ogranicza się tylko do układów przypominających wodospad. W układzie murowanym:
Ścieżki mogą mieć postać kolumn lub wierszy:
Nie wszystkie ścieżki treści muszą mieć ten sam rozmiar:
Elementy mogą obejmować wiele ścieżek:
Przedmioty można umieszczać na określonych torach; nie muszą zawsze postępować zgodnie z algorytmem automatycznego umieszczania:
Demo Oto kilka prostych demonstracji, które zrobiłem, korzystając z nadchodzącej implementacji CSS Masonry w Chromium. Demo galerii zdjęć pokazujące, jak elementy (w tym przypadku tytuł) mogą obejmować wiele ścieżek:
Kolejna galeria zdjęć przedstawiająca tory o różnych rozmiarach:
Układ witryny z wiadomościami z niektórymi ścieżkami szerszymi od innych i niektórymi elementami zajmującymi całą szerokość układu:
Tablica Kanban pokazująca, że elementy można umieszczać na określonych torach:
Uwaga:poprzednie dema zostały stworzone z wersją Chromium, która nie jest jeszcze dostępna dla większości użytkowników Internetu, ponieważ CSS Masonry dopiero zaczyna być wdrażany w przeglądarkach. Jednak twórcy stron internetowych z radością korzystają z bibliotek do tworzenia układów murowanych już od lat. Witryny korzystające obecnie z muru Rzeczywiście, masoneria jest dziś dość powszechna w Internecie. Oto kilka przykładów, które znalazłem poza Pinterestem:
I jeszcze kilka mniej oczywistych przykładów:
Jak zatem powstały te układy? Obejścia Jedną ze sztuczek, którą widziałem, jest użycie zamiast tego układu Flexbox, zmiana jego kierunku na kolumnę i ustawienie zawijania. W ten sposób możesz umieścić elementy o różnej wysokości w wielu niezależnych kolumnach, tworząc wrażenie układu murowanego:
To rozwiązanie ma jednak dwa ograniczenia:
Kolejność elementów różni się od tej, jaka byłaby w prawdziwym układzie murowanym. Dzięki Flexboxowi elementy najpierw wypełniają pierwszą kolumnę, a gdy się zapełni, przechodzą do następnej. W przypadku murarstwa przedmioty układałyby się w stosy na dowolnej ścieżce (lub w tym przypadku w kolumnie), na której jest więcej wolnego miejsca. Ale także, co być może ważniejsze, to obejście wymaga ustawienia stałej wysokości kontenera Flexbox; w przeciwnym razie nie doszłoby do zawijania.
Biblioteki murarskie stron trzecich W bardziej zaawansowanych przypadkach programiści korzystali z bibliotek. Najbardziej znana i popularna biblioteka nazywa się po prostu Masonry i według NPM jest pobierana około 200 000 razy tygodniowo. Squarespace udostępnia również komponent układu, który renderuje układ murowany, co stanowi alternatywę bez kodu i korzysta z niego wiele witryn. Obie te opcje wykorzystują kod JavaScript do umieszczania elementów w układzie. Wbudowany mur Jestem naprawdę podekscytowany, że Masonry zaczyna pojawiać się w przeglądarkach jako wbudowana funkcja CSS. Z biegiem czasu będziesz mógł używać Masonry tak samo, jak Grid lub Flexbox, to znaczy bez konieczności stosowania żadnych obejść lub kodu strony trzeciej. Mój zespół w Microsoft wdraża wbudowaną obsługę Masonry w projekcie open source Chromium, na którym opierają się Edge, Chrome i wiele innych przeglądarek. Mozilla była właściwie pierwszym dostawcą przeglądarek, który zaproponował eksperymentalną implementację masonerii w 2020 roku. Apple również był bardzo zainteresowany wprowadzeniem tego nowego, prymitywnego układu sieci Web. Prace nad standaryzacją tej funkcji również postępują naprzód, dzięki porozumieniu w grupie roboczej CSS co do ogólnego kierunku, a nawet nowego typu wyświetlania: grid-lanes. Jeśli chcesz dowiedzieć się więcej o masonerii i śledzić postępy, sprawdź moją stronę z zasobami CSS Masonry. Z czasem, gdy murarstwo stanie się funkcją bazową, podobnie jak siatka czy Flexbox, będziemy mogli po prostu z niej korzystać i czerpać korzyści z:
Lepsza wydajność, Lepsza responsywność, Łatwość użycia i prostszy kod.
Przyjrzyjmy się im bliżej. Lepsza wydajność Utworzenie własnego systemu układu przypominającego masonerię lub użycie zamiast tego biblioteki innej firmy oznacza, że będziesz musiał uruchomić kod JavaScript, aby umieścić elementy na ekranie. Oznacza to również, że ten kod będzie blokował renderowanie. Rzeczywiście albo nic się nie pojawi, albo rzeczy nie będą na właściwych miejscach lub we właściwych rozmiarach, dopóki kod JavaScript nie zostanie uruchomiony. Układ murowany jest często używany w głównej części strony internetowej, co oznacza, że kod spowodowałby, że główna treść pojawiłaby się później, niż mogłoby to mieć miejsce w innym przypadku, co pogorszyłoby wskaźnik LCP, czyli największego wskaźnika zawartości treści, który odgrywa dużą rolę w postrzeganej wydajności i optymalizacji pod kątem wyszukiwarek. Przetestowałem bibliotekę Masonry JS z prostym układem i symulując wolne połączenie 4G w DevTools. Biblioteka nie jest zbyt duża (24 KB, 7,8 KB spakowana gzipem), ale w moich warunkach testowych ładowanie trwało 600 ms. Oto nagranie wydajności pokazujące długi czas ładowania biblioteki Masonry, wynoszący 600 ms, i że w tym czasie nie wystąpiła żadna inna czynność renderowania:
Ponadto po początkowym czasie ładowania pobrany skrypt musiał zostać przeanalizowany, skompilowany, a następnie uruchomiony. Wszystko to, jak wspomniano wcześniej, blokowało renderowanie strony. Dzięki wbudowanej implementacji Masonry w przeglądarce nie będziemy mieli skryptu do załadowania i uruchomienia. Silnik przeglądarki wykona swoje zadanie na początkowym etapie renderowania strony. Lepsza responsywność Podobnie jak przy pierwszym ładowaniu strony, zmiana rozmiaru okna przeglądarki prowadzi do ponownego wyrenderowania układu tej strony. W tym momencie jednak, jeśli strona korzysta z biblioteki Masonry JS, nie ma potrzeby ponownego ładowania skryptu, ponieważ jest on jużTutaj. Jednak kod, który przenosi elementy we właściwe miejsca, musi zostać uruchomiony. Teraz wydaje się, że ta konkretna biblioteka robi to dość szybko, gdy strona się ładuje. Jednakże animuje elementy, gdy muszą zostać przeniesione w inne miejsce podczas zmiany rozmiaru okna, a to robi dużą różnicę. Oczywiście użytkownicy nie spędzają tyle czasu na zmianie rozmiaru okien przeglądarki, co my, programiści. Ale to animowane doświadczenie zmiany rozmiaru może być dość irytujące i zwiększa postrzegany czas potrzebny stronie na dostosowanie się do nowego rozmiaru. Łatwość użycia i prostszy kod Łatwość korzystania z funkcji internetowej i prostota wyglądu kodu to ważne czynniki, które mogą mieć duże znaczenie dla Twojego zespołu. Oczywiście nigdy nie będą tak ważne, jak wrażenia użytkownika końcowego, ale doświadczenie programisty wpływa na łatwość konserwacji. Korzystanie z wbudowanej funkcji internetowej niesie ze sobą ważne korzyści:
Programiści, którzy znają już HTML, CSS i JS, najprawdopodobniej będą mogli z łatwością korzystać z tej funkcji, ponieważ została ona zaprojektowana tak, aby dobrze integrowała się i była spójna z resztą platformy internetowej. Nie ma ryzyka wprowadzenia istotnych zmian w sposobie korzystania z tej funkcji. Ryzyko, że ta funkcja stanie się przestarzała lub przestanie być obsługiwana, jest prawie zerowe.
W przypadku wbudowanego muru, ponieważ jest to prymitywny układ, używasz go z CSS, podobnie jak Grid lub Flexbox, bez użycia JS. Ponadto inne właściwości CSS związane z układem, takie jak przerwa, działają zgodnie z oczekiwaniami. Nie ma tu żadnych sztuczek ani obejść, o których warto wiedzieć, a to, czego się nauczysz, jest udokumentowane na MDN. W przypadku biblioteki Masonry JS inicjalizacja jest nieco złożona: wymaga atrybutu danych o określonej składni wraz z ukrytymi elementami HTML w celu ustawienia rozmiarów kolumn i odstępów. Ponadto, jeśli chcesz rozciągać kolumny, musisz sam uwzględnić rozmiar odstępu, aby uniknąć problemów:
Porównajmy to z tym, jak wyglądałaby wbudowana implementacja murarska:
Prostszy, bardziej kompaktowy kod, który może po prostu używać takich rzeczy jak przerwa i gdzie łączenie ścieżek odbywa się za pomocą rozpiętości 2, tak jak w siatce, i nie wymaga obliczania odpowiedniej szerokości obejmującej rozmiar przerwy. Jak sprawdzić, co jest dostępne i kiedy jest dostępne? Ogólnie rzecz biorąc, pytanie nie brzmi tak naprawdę, czy powinieneś używać wbudowanego Masonry zamiast biblioteki JS, ale raczej kiedy. Biblioteka Masonry JS jest niesamowita i od wielu lat wypełnia lukę na platformie internetowej, ciesząc się wieloma zadowolonymi programistami i użytkownikami. Ma to oczywiście kilka wad, jeśli porównać je z wbudowaną implementacją Masonry, ale nie są one istotne, jeśli implementacja nie jest gotowa. Łatwo mi wymienić te nowe, fajne funkcje platformy internetowej, ponieważ pracuję u dostawcy przeglądarek i dlatego zazwyczaj wiem, co nadejdzie. Ale programiści często, ankieta za ankietą, mówią, że śledzenie nowych rzeczy jest trudne. Utrzymywanie informacji jest trudne, a firmy i tak nie zawsze traktują naukę jako priorytet. Aby Ci w tym pomóc, oto kilka zasobów, które dostarczają aktualizacji w prosty i zwięzły sposób, dzięki czemu możesz szybko uzyskać potrzebne informacje:
Platforma internetowa zawiera witrynę eksploratora: Być może zainteresuje Cię strona z informacjami o wydaniu. Jeśli podoba Ci się kanał RSS, sprawdź kanał informacji o wydaniu, a także kanały Baseline nowo dostępne i szeroko dostępne.
SiećPanel stanu platformy: Być może spodobają Ci się różne strony dotyczące roku bazowego.
Strona z planem działania dotyczącym stanu platformy Chrome.
Jeśli masz trochę więcej czasu, mogą Cię również zainteresować informacje o wydaniach dostawców przeglądarek:
Chrom Krawędź Firefoksa Safari
Aby uzyskać jeszcze więcej zasobów, zapoznaj się z moją ściągawką dotyczącą nawigacji po platformie internetowej. Moja rzecz nadal nie została wdrożona To druga strona problemu. Nawet jeśli znajdziesz czas, energię i sposoby na śledzenie wydarzeń, nadal pojawia się frustracja związana z tym, aby Twój głos został usłyszany i zaimplementowano ulubione funkcje. Być może od lat czekasz na naprawienie konkretnego błędu lub udostępnienie konkretnej funkcji w przeglądarce, której wciąż brakuje. Powiem tylko, że dostawcy przeglądarek słuchają. Należę do kilku zespołów międzyorganizacyjnych, w których cały czas omawiamy sygnały i opinie programistów. Sprawdzamy wiele różnych źródeł opinii, zarówno wewnętrznych u każdego dostawcy przeglądarek, jak i zewnętrznych/publicznych na forach, projektach open source, blogach i ankietach. Zawsze staramy się tworzyć dla programistów lepsze sposoby dzielenia się swoimi konkretnymi potrzebami i przypadkami użycia. Jeśli więc możesz, żądaj więcej od dostawców przeglądarek i wywieraj na nas presję, abyśmy zaimplementowali potrzebne Ci funkcje. Rozumiem, że wymaga to czasu i może być onieśmielające (nie wspominając o wysokiej barierze wejścia), ale też działa. Oto kilka sposobów, w jakie możesz zabrać głos swój (lub swojej firmy): Weź udział w corocznych ankietach dotyczących stanu JS, stanu CSS i stanu HTML. Odgrywają dużą rolę w ustalaniu priorytetów swojej pracy przez dostawców przeglądarek. Jeśli potrzebujesz spójnego wdrożenia określonego interfejsu API opartego na standardach we wszystkich przeglądarkach, rozważ przesłanie propozycji podczas następnej iteracji projektu Interop. Wymaga to więcej czasu, ale zastanów się, w jaki sposób Shopify i RUMvision udostępniły swoje listy życzeń dotyczące Interop 2026. Takie szczegółowe informacje mogą być bardzo przydatne dla dostawców przeglądarek w ustalaniu priorytetów. Aby uzyskać więcej przydatnych łączy mających wpływ na dostawców przeglądarek, zapoznaj się z moją ściągawką Nawigacja po platformie internetowej. Wniosek Na koniec mam nadzieję, że ten artykuł dał Ci kilka rzeczy do przemyślenia:
Podekscytowanie związane z masonerią i innymi nadchodzącymi funkcjami internetowymi. Kilka funkcji internetowych, z których warto zacząć korzystać. Kilka fragmentów kodu niestandardowego lub kodu innej firmy, które możesz usunąć na rzecz wbudowanych funkcji. Kilka sposobów na śledzenie nadchodzących wydarzeń i wpływanie na dostawców przeglądarek.
Co ważniejsze, mam nadzieję, że przekonałem Cię o korzyściach płynących z wykorzystania pełnego potencjału platformy internetowej.
