Преди около 15 години работех в компания, в която създавахме приложения за туристически агенти, летищни работници и авиокомпании. Ние също така изградихме собствена вътрешна рамка за компоненти на потребителския интерфейс и възможности за едностранично приложение. Имахме компоненти за всичко: полета, бутони, раздели, диапазони, таблици с данни, менюта, инструменти за избор на дати, избори и множествени избори. Дори имахме компонент div. Между другото, нашият div компонент беше страхотен, позволяваше ни да правим заоблени ъгли във всички браузъри, което, вярвате или не, не беше лесно нещо за правене по онова време.
Нашата работа се проведе в момент от нашата история, когато JS, Ajax и динамичният HTML бяха разглеждани като революция, която ни доведе в бъдещето. Изведнъж успяхме да актуализираме страница динамично, да получим данни от сървър и да избегнем необходимостта да навигираме до други страници, което се видя като бавно и мига голям бял правоъгълник на екрана между двете страници. Имаше фраза, станала популярна от Джеф Атууд (основателят на StackOverflow), която гласеше: „Всяко приложение, което може да бъде написано на JavaScript, в крайна сметка ще бъде написано на JavaScript.“ – Джеф Атууд
За нас по онова време това се стори като смелост да отидем и създадем тези приложения. Чувствах се като пълно одобрение да правя всичко с JS. Така че направихме всичко с JS и наистина не отделихме време да проучим други начини за правене на нещата. Наистина не чувствахме стимул да научим правилно какво могат да направят HTML и CSS. Ние всъщност не възприемахме мрежата като развиваща се платформа за приложения в нейната цялост. Най-вече го видяхме като нещо, което трябва да заобиколим, особено що се отнася до поддръжката на браузъра. Можем просто да хвърлим повече JS, за да свършим нещата. Бихте ли ми помогнали да отделя време да науча повече за това как работи мрежата и какво е налично на платформата? Разбира се, вероятно бих могъл да премахна куп код, който не беше наистина необходим. Но по онова време може би не толкова. Виждате ли, разликите в браузърите тогава бяха доста значителни. Това беше време, когато Internet Explorer все още беше доминиращият браузър, като Firefox беше вторият, но започна да губи пазарен дял поради бързо набиращата популярност Chrome. Въпреки че Chrome и Firefox бяха доста добри в съгласуването на уеб стандартите, средите, в които се изпълняваха нашите приложения, означаваха, че трябваше да поддържаме IE6 за дълго време. Дори когато ни беше позволено да поддържаме IE8, все още трябваше да се справяме с много разлики между браузърите. Не само това, но мрежата от онова време просто нямаше толкова много възможности, вградени направо в платформата.
Бързо напред до днес. Нещата се промениха изключително много. Не само, че имаме повече от тези възможности от всякога, но и скоростта, с която те стават достъпни, също се е увеличила. Позволете ми да задам въпроса отново тогава: Ще ви помогне ли днес да отделите време, за да научите повече за това как работи мрежата и какво е налично на платформата? Абсолютно да. Да се научите да разбирате и използвате уеб платформата днес ви поставя в огромно предимство пред другите разработчици. Независимо дали работите върху производителност, достъпност, отзивчивост, всички заедно, или просто предоставяне на функции на потребителския интерфейс, ако искате да го направите като отговорен инженер, познаването на инструментите, които са ви на разположение, ви помага да постигнете целите си по-бързо и по-добре. Някои неща, за които може вече да не се нуждаете от библиотека Знаейки какви браузъри поддържат днес, въпросът е: Какво можем да изоставим? Имаме ли нужда от div компонент, за да правим заоблени ъгли през 2025 г.? Разбира се, ние не го правим. Свойството border-radius се поддържа от всички използвани в момента браузъри повече от 15 години към този момент. А ъгловата форма също идва скоро, за още по-красиви ъгли. Нека да разгледаме сравнително скорошни функции, които вече са налични във всички основни браузъри и които можете да използвате, за да замените съществуващи зависимости във вашата кодова база. Въпросът не е веднага да се откажете от всичките си любими библиотеки и да пренапишете кодовата си база. Що се отнася до всичко останало, първо трябва да вземете предвид поддръжката на браузъра и да решите въз основа на други фактори, специфични за вашия проект. Следните функции са внедрени в трите основни двигателя на браузъра (Chromium, WebKit и Gecko), но може да имате различни изисквания за поддръжка на браузъра, които ви пречат да ги използвате веднага. Сега обаче все още е добър момент да научите за тези функции и може би да планирате да ги използвате в даден момент. Изскачащи прозорци и диалози API Popover, HTML елементът
Разбира се, скоростта на вашата интернет връзка вероятно също се е увеличила, но това не е така за всички. Освен това не всеки има еднакви възможности на устройството. Изтеглянето на код на трета страна за неща, които можете да правите с платформата, вместо това най-вероятно означава, че изпращате повече код и следователно достигате до по-малко клиенти, отколкото обикновено. В мрежата лошата производителност на зареждане води до големи нива на изоставяне и вреди на репутацията на марката. Изпълнение на по-малко код на устройства Освен това кодът, който доставяте на устройствата на клиентите си, вероятно работи по-бързо, ако използва по-малко JavaScript абстракции върху платформата. Също така вероятно е по-отзивчив и по-достъпен по подразбиране. Всичко това води до повече и по-щастливи клиенти. Проверете годишния блог на моя колега Алекс Ръсел за разликата в неравенството в производителността, който показва, че премиум устройствата до голяма степен отсъстват от пазарите с милиарди потребители поради неравенството в богатството. И тази разлика само нараства с времето.
Разпределение на вградената зидария Една функция на уеб платформата, която идва скоро и от която съм много развълнуван, е CSS Masonry.
Нека започна с обяснение какво е масонството. Какво е масонство Зидарията е тип оформление, което беше направено популярно от Pinterest преди години. Той създава независими песни със съдържание, в които елементите се опаковат възможно най-близо до началото на песента.
Много хора виждат Масонството като чудесен вариант за портфолио и фото галерии, което със сигурност може да направи. Но Masonry е по-гъвкав от това, което виждате в Pinterest, и не се ограничава само до оформления, подобни на водопад. В оформление на зидария:
Следите могат да бъдат колони или редове:
Не е необходимо всички записи на съдържание да са с еднакъв размер:
Елементите могат да обхващат няколко песни:
Елементите могат да бъдат поставени на определени писти; не е нужно винаги да следват алгоритъма за автоматично поставяне:
Демонстрации Ето няколко прости демонстрации, които направих с помощта на предстоящото внедряване на CSS Masonry в Chromium. Демонстрация на фотогалерия, показваща как елементите (заглавието в този случай) могат да обхващат няколко песни:
Друга фотогалерия, показваща различни по големина писти:
Оформление на новинарски сайт с някои песни, по-широки от други, и някои елементи, обхващащи цялата ширина на оформлението:
Канбан дъска, показваща, че артикулите могат да бъдат поставени на определени писти:
Забележка: Theпредишните демонстрации бяха направени с версия на Chromium, която все още не е достъпна за повечето уеб потребители, тъй като CSS Masonry едва започва да се внедрява в браузърите. Въпреки това уеб разработчиците с удоволствие използват библиотеки за създаване на масонски оформления от години. Сайтове, използващи зидария днес Наистина масонството е доста често срещано в мрежата днес. Ето няколко примера, които намерих освен Pinterest:
И още няколко, по-малко очевидни примера:
И така, как са създадени тези оформления? Заобиколни решения Един трик, който съм виждал използван, е използването на Flexbox оформление вместо това, промяната на посоката му на колона и настройката му да обвива. По този начин можете да поставите предмети с различна височина в множество независими колони, създавайки впечатлението за оформление на зидария:
Има обаче две ограничения с това решение:
Редът на елементите е различен от този, който би бил с истинско оформление на масонството. С Flexbox елементите първо запълват първата колона и когато се напълни, преминават към следващата колона. С Masonry елементите ще се подреждат в която и да е песен (или колона в този случай), където има повече свободно място. Но също така, и може би по-важно, това решение изисква да зададете фиксирана височина на контейнера Flexbox; в противен случай няма да се получи обвиване.
Масонски библиотеки на трети страни За по-напреднали случаи разработчиците използват библиотеки. Най-известната и популярна библиотека за това се нарича просто Masonry и се изтегля около 200 000 пъти седмично според NPM. Squarespace също така предоставя компонент за оформление, който изобразява оформление на Masonry, за алтернатива без код, и много сайтове го използват. И двете опции използват JavaScript код за поставяне на елементи в оформлението. Вградена зидария Наистина съм развълнуван, че Masonry вече започва да се появява в браузърите като вградена CSS функция. С течение на времето ще можете да използвате Masonry точно както използвате Grid или Flexbox, тоест без да имате нужда от заобиколни решения или код на трета страна. Моят екип в Microsoft внедрява вградена поддръжка на Masonry в проекта с отворен код Chromium, на който са базирани Edge, Chrome и много други браузъри. Mozilla всъщност беше първият доставчик на браузъри, който предложи експериментална реализация на Masonry през 2020 г. И Apple също беше много заинтересована да направи това ново уеб оформление примитивно. Работата по стандартизирането на функцията също върви напред, със съгласие в работната група на CSS относно общата посока и дори нов дисплей тип дисплей: решетки. Ако искате да научите повече за масонството и да проследите напредъка, вижте моята страница с ресурси за CSS масонството. След време, когато Masonry се превърне в базова функция, точно като Grid или Flexbox, ще можем просто да я използваме и да се възползваме от:
По-добра производителност, По-добра отзивчивост, Лесна употреба и по-прост код.
Нека ги разгледаме по-отблизо. По-добра производителност Създаването на ваша собствена система за оформление, подобна на Masonry, или използването на библиотека на трета страна вместо това означава, че ще трябва да стартирате JavaScript код, за да поставите елементи на екрана. Това също означава, че този код ще блокира изобразяването. Наистина, или нищо няма да се появи, или нещата няма да бъдат на правилните места или с правилните размери, докато този JavaScript код не се изпълни. Оформлението Masonry често се използва за основната част на уеб страница, което означава, че кодът ще накара основното ви съдържание да се появи по-късно, отколкото би могло иначе, влошавайки вашия LCP или показателя за рисуване на най-голямо съдържание, който играе голяма роля във възприеманата производителност и оптимизацията на търсачките. Тествах библиотеката Masonry JS с просто оформление и чрез симулиране на бавна 4G връзка в DevTools. Библиотеката не е много голяма (24KB, 7,8KB gzipped), но отне 600ms за зареждане при моите тестови условия. Ето запис на производителност, показващ това дълго време за зареждане от 600 милисекунди за библиотеката Masonry и че не се е случила друга дейност по изобразяване, докато това се е случвало:
В допълнение, след първоначалното време на зареждане, изтегленият скрипт трябваше да бъде анализиран, компилиран и след това стартиран. Всичко това, както беше споменато по-горе, блокира изобразяването на страницата. С вградена имплементация на Masonry в браузъра, няма да имаме скрипт за зареждане и изпълнение. Енджинът на браузъра просто ще свърши работата си по време на първоначалната стъпка на изобразяване на страницата. По-добра отзивчивост Подобно на това, когато страницата се зарежда за първи път, преоразмеряването на прозореца на браузъра води до изобразяване на оформлението в тази страница отново. На този етап обаче, ако страницата използва библиотеката Masonry JS, няма нужда да зареждате отново скрипта, защото той вече етук Въпреки това кодът, който премества елементи на правилните места, трябва да работи. Сега тази конкретна библиотека изглежда доста бърза в това, когато страницата се зарежда. Той обаче анимира елементите, когато трябва да се преместят на друго място при преоразмеряване на прозореца, и това прави голяма разлика. Разбира се, потребителите не отделят време за преоразмеряване на прозорците на браузъра си толкова, колкото ние, разработчиците. Но това изживяване с анимирано преоразмеряване може да бъде доста смущаващо и да увеличи възприеманото време, необходимо на страницата да се адаптира към новия си размер. Лесна употреба и по-прост код Колко лесно е да използвате уеб функция и колко прост изглежда кодът са важни фактори, които могат да направят голяма разлика за вашия екип. Разбира се, те никога не могат да бъдат толкова важни, колкото крайното потребителско изживяване, но опитът на разработчиците оказва влияние върху поддръжката. Използването на вградена уеб функция идва с важни предимства на този фронт:
Разработчиците, които вече познават HTML, CSS и JS, най-вероятно ще могат лесно да използват тази функция, защото е проектирана да се интегрира добре и да бъде съвместима с останалата част от уеб платформата. Няма риск от нарушаване на промените, въведени в начина на използване на функцията. Има почти нулев риск тази функция да бъде остаряла или да не се поддържа.
В случай на вградено Masonry, тъй като това е примитивно оформление, вие го използвате от CSS, точно като Grid или Flexbox, без включен JS. Освен това други CSS свойства, свързани с оформлението, като пропуск, работят както бихте очаквали. Няма трикове или решения, за които да знаете, а нещата, които научавате, са документирани в MDN. За Masonry JS lib инициализацията е малко сложна: тя изисква атрибут на данни със специфичен синтаксис, заедно със скрити HTML елементи, за да зададете размерите на колоните и пропуските. Освен това, ако искате да обхващате колони, трябва сами да включите размера на празнината, за да избегнете проблеми:
<стил> .track-sizer, .item { ширина: 20%; } .gutter-sizer { ширина: 1 rem; } .item { височина: 100px; margin-block-end: 1rem; } .item:nth-child(odd) { височина: 200px; } .item--width2 { ширина: calc(40% + 1rem); }
Нека сравним това с това как би изглеждало вграденото изпълнение на Masonry: <стил> .container { дисплей: решетка-ленти; решетка-ленти: повторение (4, 20%); междина: 1 rem; } .item { височина: 100px; } .item:nth-child(odd) { височина: 200px; } .item--width2 { решетка-колона: обхват 2; }
По-опростен, по-компактен код, който може просто да използва неща като празнина и където обхващащите пътеки се извършват с интервал 2, точно както в мрежата, и не изисква да изчислявате правилната ширина, която включва размера на празнината. Как да разберете какво е налично и кога е налично? Като цяло, въпросът всъщност не е дали трябва да използвате вграден Masonry над JS библиотека, а по-скоро кога. Библиотеката Masonry JS е невероятна и запълва празнина в уеб платформата в продължение на много години и за много щастливи разработчици и потребители. Той има няколко недостатъка, ако го сравните с вградено изпълнение на Masonry, разбира се, но те не са важни, ако това изпълнение не е готово. За мен е лесно да изброя тези страхотни нови функции на уеб платформата, защото работя в доставчик на браузъри и следователно съм склонен да знам какво предстои. Но разработчиците често споделят проучване след проучване, че следенето на нови неща е трудно. Да бъдеш информиран е трудно и компаниите не винаги дават приоритет на ученето. За да помогнете с това, ето няколко ресурса, които предоставят актуализации по прости и компактни начини, така че да можете бързо да получите необходимата ви информация:
Уеб платформата разполага със сайт за изследване: Може да се интересувате от страницата с бележки по изданието. И ако харесвате RSS, вижте емисията с бележки по изданието, както и емисиите Baseline New Available и Widely Available.
МрежатаТабло за управление на състоянието на платформата: Може да харесате различните му страници за базова година.
Страница с пътна карта за състоянието на платформата Chrome.
Ако имате малко повече време, може да се интересувате и от бележките за изданието на доставчиците на браузъри:
Chrome Ръб Firefox Safari
За още повече ресурси вижте моя лист за навигация в уеб платформата. Моето нещо все още не е внедрено Това е другата страна на проблема. Дори и да намерите време, енергия и начини да следите, все още има разочарование от това да чуете гласа си и да внедрите любимите си функции. Може би сте чакали с години да бъде разрешена конкретна грешка или да бъде изпратена конкретна функция в браузър, където все още липсва. Това, което ще кажа, е, че доставчиците на браузъри слушат. Аз съм част от няколко междуорганизационни екипа, където обсъждаме сигнали и обратна връзка от разработчици през цялото време. Разглеждаме много различни източници на обратна връзка, както вътрешни за всеки доставчик на браузъри, така и външни/публични във форуми, проекти с отворен код, блогове и проучвания. И ние винаги се опитваме да създадем по-добри начини за разработчиците да споделят своите специфични нужди и случаи на употреба. Така че, ако можете, моля, изисквайте повече от доставчиците на браузъри и ни притискайте да внедрим функциите, от които се нуждаете. Разбирам, че отнема време и може да бъде смущаващо (да не говорим за висока бариера за влизане), но също така работи. Ето няколко начина, по които можете да чуете гласа си (или на вашата компания): Участвайте в годишните проучвания за състоянието на JS, състоянието на CSS и състоянието на HTML. Те играят голяма роля в това как доставчиците на браузъри приоритизират работата си. Ако имате нужда от конкретен базиран на стандарти API, който да бъде внедрен последователно в браузърите, помислете за изпращане на предложение при следващата итерация на проекта за взаимодействие. Изисква повече време, но помислете как Shopify и RUMvision споделиха своите списъци с желания за Interop 2026. Подробна информация като тази може да бъде много полезна за доставчиците на браузъри, за да дадат приоритет. За повече полезни връзки, за да повлияете на доставчиците на браузъри, вижте моя лист за навигация в уеб платформата. Заключение В заключение, надявам се, че тази статия ви е оставила няколко неща, върху които да помислите:
Вълнение за Masonry и други предстоящи уеб функции. Няколко уеб функции, които може да искате да започнете да използвате. Няколко парчета персонализиран код или код на трета страна, които може да успеете да премахнете в полза на вградени функции. Няколко начина да следите какво идва и да повлияете на доставчиците на браузъри.
По-важното е, че се надявам да съм ви убедил в ползите от използването на уеб платформата в пълния й потенциал.
