Пред околу 15 години, работев во компанија каде што правевме апликации за туристички агенти, аеродромски работници и авиокомпании. Исто така, изградивме сопствена внатрешна рамка за компоненти на интерфејс и можности за апликации на една страница. Имавме компоненти за сè: полиња, копчиња, јазичиња, опсези, табели со податоци, менија, избирачи на датуми, селектирања и повеќе селектирања. Имавме дури и див компонента. Нашата див компонента беше одлична, патем, ни овозможи да правиме заоблени агли на сите прелистувачи, што, верувале или не, не беше лесна работа во тоа време.
Нашата работа се одвиваше во момент од нашата историја кога JS, Ajax и динамичниот HTML беа гледани како револуција што не донесе во иднината. Одеднаш, можевме динамично да ажурираме страница, да добиеме податоци од сервер и да избегнеме да се движиме на други страници, што се гледаше како бавно и блесна голем бел правоаголник на екранот помеѓу двете страници. Имаше една фраза, популарна од Џеф Атвуд (основачот на StackOverflow), која гласеше: „Секоја апликација што може да биде напишана во JavaScript на крајот ќе биде напишана во JavaScript“ - Џеф Атвуд
За нас во тоа време, ова се чинеше како смелост да одиме и да ги создадеме тие апликации. Се чувствуваше како целосно одобрение да се направи сè со Ј.С. Така, направивме сè со JS и навистина не одвоивме време да истражуваме други начини на правење работи. Навистина не почувствувавме поттик правилно да научиме што можат да направат HTML и CSS. Ние навистина не ја сметавме мрежата како платформа за апликации што се развива во целост. Претежно го гледавме како нешто на кое треба да работиме, особено кога станува збор за поддршката на прелистувачот. Можеме само да фрлиме повеќе JS за да ги завршиме работите. Дали би ми помогнало одвојувањето време за да дознаам повеќе за тоа како функционираше мрежата и што беше достапно на платформата? Секако, веројатно можев да избричам куп код што навистина не беше потребен. Но, во тоа време, можеби не толку многу. Гледате, разликите во прелистувачите тогаш беа прилично значајни. Ова беше време кога Internet Explorer сè уште беше доминантен прелистувач, при што Firefox беше на второ место, но почна да губи удел на пазарот поради брзо стекнување на популарност на Chrome. Иако Chrome и Firefox беа доста добри во усогласувањето на веб-стандардите, околините во кои работеа нашите апликации значеа дека моравме да поддржуваме IE6 долго време. Дури и кога ни беше дозволено да поддржуваме IE8, сепак моравме да се справиме со многу разлики помеѓу прелистувачите. Не само тоа, туку и мрежата од тоа време едноставно немаше толку многу способности вградени директно во платформата.
Брзо напред до денес. Работите се променија неверојатно. Не само што имаме повеќе од овие способности од кога било досега, туку и стапката со која тие стануваат достапни е зголемена. Дозволете ми да го поставам прашањето повторно, тогаш: Дали би ви помогнало денес да одвоите време за да дознаете повеќе за тоа како функционира веб и што е достапно на платформата? Апсолутно да. Учењето да ја разбирате и користите веб-платформата денес ве става во огромна предност во однос на другите програмери. Без разлика дали работите на перформансите, пристапноста, одговорноста, сите заедно или само испраќате функции на корисничкиот интерфејс, доколку сакате да го направите тоа како одговорен инженер, познавањето на алатките што ви се достапни ви помага побрзо и подобро да ги достигнете вашите цели. Некои работи за кои можеби повеќе не ви треба библиотека Знаејќи што поддржуваат прелистувачите денес, прашањето е: Што можеме да отфрлиме? Дали ни е потребна див компонента за да направиме заоблени агли во 2025 година? Се разбира, ние не. Својството на граничен радиус е поддржано од сите тековно користени прелистувачи повеќе од 15 години во овој момент. Наскоро доаѓа и обликот на аголот, за уште поубави агли. Да ги погледнеме релативно неодамнешните функции кои сега се достапни во сите главни прелистувачи и кои можете да ги користите за да ги замените постоечките зависности во вашата база на кодови. Поентата не е веднаш да ги отфрлите сите ваши сакани библиотеки и да ја преработите вашата база на кодови. Како и за сè друго, прво ќе треба да ја земете предвид поддршката на прелистувачот и да одлучите врз основа на други фактори специфични за вашиот проект. Следниве функции се имплементирани во трите главни мотори на прелистувач (Chromium, WebKit и Gecko), но можеби имате различни барања за поддршка на прелистувачот што ве спречува да ги користите веднаш. Сепак, сега е добро време да се запознаете со овие карактеристики, а можеби и да планирате да ги користите во одреден момент. Поповери и дијалози Popover API,
Секако, брзината на вашата интернет конекција веројатно е исто така зголемена, но тоа не е случај за секого. И не секој ги има истите можности на уредот. Наместо тоа, ако внесете код од трета страна за работи што можете да ги правите со платформата, најверојатно значи дека испраќате повеќе код и затоа ќе допрете до помалку клиенти отколку што обично би правеле. На интернет, лошите перформанси на вчитување доведуваат до големи стапки на напуштање и ја повредуваат репутацијата на брендот. Вклучување помалку код на уреди Понатаму, кодот што го испраќате на уредите на вашите клиенти веројатно работи побрзо ако користи помалку JavaScript апстракции на врвот на платформата. Исто така, веројатно е поодговорно и попристапно стандардно. Сето ова води до повеќе и посреќни клиенти. Проверете го годишниот блог на јазот за нееднаквост во перформансите на мојот колега Алекс Расел, кој покажува дека премиум уредите во голема мера отсуствуваат на пазарите со милијарди корисници поради нееднаквоста во богатството. И овој јаз само расте со текот на времето.
Вграден ѕидарски распоред Една од функциите на веб-платформата што доаѓа наскоро и за која сум многу возбуден е CSS Masonry.
Да почнам со објаснување што е тоа ѕидарство. Што е ѕидарство Ѕидарството е еден вид распоред што беше популарен од Pinterest пред неколку години. Создава независни траки на содржина во кои предметите се спакуваат што е можно поблиску до почетокот на патеката.
Многу луѓе го гледаат ѕидарството како одлична опција за портфолија и фото галерии, што секако може да го направи. Но, ѕидарството е пофлексибилно од она што го гледате на Pinterest и не е ограничено само на распоред како водопад. Во ѕидарски распоред:
Песните може да бидат колони или редови:
Записите од содржината не мора да бидат сите со иста големина:
Ставките може да опфаќаат повеќе песни:
Предметите може да се постават на одредени патеки; тие не мора секогаш да го следат алгоритмот за автоматско поставување:
Демос Еве неколку едноставни демо снимки што ги направив со користење на претстојната имплементација на CSS Masonry во Chromium. Демо галерија на фотографии, што покажува како ставките (насловот во овој случај) можат да опфаќаат повеќе песни:
Друга фотогалерија која прикажува траки со различни големини:
Распоред на страницата за вести со некои записи пошироки од другите и некои ставки што ја опфаќаат целата ширина на распоредот:
Канбан табла која покажува дека предметите може да се постават на одредени патеки:
Забелешка: НаПретходните демонстрации беа направени со верзија на Chromium која сè уште не е достапна за повеќето веб-корисници, бидејќи CSS Masonry штотуку почнува да се имплементира во прелистувачите. Како и да е, веб-програмерите среќно користат библиотеки за да креираат ѕидарски распореди веќе со години. Веб-страници кои користат ѕидарство денес Навистина, ѕидарството е прилично честа појава на интернет денес. Еве неколку примери што ги најдов покрај Pinterest:
И уште неколку, помалку очигледни, примери:
Па, како се создадени овие распореди? Заобиколни решенија Еден трик што видов дека се користи е користење на распоред на Flexbox наместо тоа, менување на неговата насока во колона и поставување на завиткување. На овој начин, можете да поставите предмети со различни висини во повеќе, независни колони, давајќи впечаток на ѕидарски распоред:
Сепак, постојат две ограничувања со овој заобиколен начин:
Редоследот на артиклите е различен од оној што би бил со вистински ѕидарски распоред. Со Flexbox, ставките прво ја пополнуваат првата колона и, кога е полна, потоа одат во следната колона. Со ѕидарството, предметите би се наредени во која било патека (или колона во овој случај) има повеќе простор на располагање. Но, исто така, и можеби уште поважно, овој заобиколен начин бара да поставите фиксна висина на контејнерот Flexbox; во спротивно, не би се случило завиткување.
Ѕидарски библиотеки од трета страна За понапредни случаи, програмерите користат библиотеки. Најпознатата и популарна библиотека за ова е едноставно наречена Масонерија, и таа се презема околу 200.000 пати неделно според NPM. Squarespace, исто така, обезбедува компонента за распоред што дава изглед на ѕидарски, за алтернатива без код, и многу локации ја користат. И двете од овие опции користат JavaScript код за поставување ставки во изгледот. Вграден ѕидарски Навистина сум возбуден што Масонеријата сега почнува да се појавува во прелистувачите како вградена CSS функција. Со текот на времето, ќе можете да го користите Masonry исто како што го користите Grid или Flexbox, односно, без да ви требаат никакви решенија или код од трета страна. Мојот тим во Microsoft имплементира вградена поддршка за ѕидање во проектот со отворен код Chromium, на кој се базирани Edge, Chrome и многу други прелистувачи. Mozilla всушност беше првиот продавач на прелистувачи кој предложи експериментална имплементација на Masonry уште во 2020 година. А Apple исто така беше многу заинтересиран да го направи овој нов веб-распоред примитивен. Работата за стандардизирање на функцијата исто така се движи напред, со договор во рамките на работната група CSS за општата насока, па дури и за нов дисплеј од типот на дисплеј: решетката-ленти. Ако сакате да дознаете повеќе за Масонеријата и да го следите напредокот, проверете ја мојата страница со ресурси за ѕидање CSS. Со текот на времето, кога ѕидарството ќе стане основна карактеристика, исто како Grid или Flexbox, ќе можеме едноставно да го користиме и да имаме корист од:
Подобри перформанси, Подобра реакција, Лесно користење и поедноставен код.
Да ги разгледаме овие подетално. Подобри перформанси Создавањето сопствен систем за распоред сличен на ѕидарски, или наместо тоа користење библиотека од трета страна, значи дека ќе треба да извршите JavaScript код за да поставите ставки на екранот. Ова исто така значи дека овој код ќе биде блокиран на рендерот. Навистина, или ништо нема да се појави, или работите нема да бидат на вистинските места или со правилни големини, додека не се изврши тој JavaScript код. Распоредот на ѕидање често се користи за главниот дел од веб-страницата, што значи дека кодот ќе направи вашата главна содржина да се појавува подоцна отколку што инаку би можело да се појави, деградирајќи го вашиот LCP или најголемата содржина со содржина на боја, што игра голема улога во перцепираните перформанси и оптимизацијата на пребарувачот. Ја тестирав библиотеката Masonry JS со едноставен распоред и со симулирање на бавна 4G врска во DevTools. Библиотеката не е многу голема (24KB, 7,8KB gzipped), но беа потребни 600ms за да се вчита под моите услови за тестирање. Еве снимка со изведба што покажува долго време на вчитување од 600 ms за библиотеката на Масонеријата и дека ниедна друга активност за рендерирање не се случила додека тоа се случувало:
Покрај тоа, по првичното време на вчитување, преземената скрипта потоа требаше да се анализира, компајлира и потоа да се изврши. Сето тоа, како што беше споменато претходно, го блокираше прикажувањето на страницата. Со вградена имплементација на Масонерија во прелистувачот, нема да имаме скрипта за вчитување и извршување. Моторот на прелистувачот само ќе го направи своето за време на почетниот чекор на прикажување на страницата. Подобра реакција Слично како кога страницата првпат се вчитува, промената на големината на прозорецот на прелистувачот води до повторно прикажување на изгледот на таа страница. Меѓутоа, во овој момент, ако страницата ја користи библиотеката Masonry JS, нема потреба повторно да се вчита скриптата, бидејќи веќе еовде. Сепак, кодот што ги преместува ставките на вистинските места треба да работи. Сега оваа конкретна библиотека се чини дека е прилично брза во тоа кога се вчитува страницата. Сепак, ги анимира предметите кога треба да се преместат на друго место при промена на големината на прозорецот, а тоа прави голема разлика. Се разбира, корисниците не трошат време за промена на големината на прозорците на прелистувачот колку што тоа го правиме ние програмерите. Но, ова анимирано искуство со промена на големината може да биде прилично застрашувачко и го зголемува времето кое е потребно за страницата да се прилагоди на нејзината нова големина. Лесно користење и поедноставен код Колку е лесно да се користи веб-функција и колку едноставно изгледа кодот се важни фактори кои можат да направат голема разлика за вашиот тим. Тие никогаш не можат да бидат толку важни како искуството на конечниот корисник, се разбира, но искуството на програмерите влијае на одржувањето. Користењето на вградена веб-функција доаѓа со важни придобивки на тој план:
Програмерите кои веќе знаат HTML, CSS и JS, најверојатно, ќе можат лесно да ја користат таа функција бидејќи е дизајнирана добро да се интегрира и да биде конзистентна со остатокот од веб-платформата. Нема ризик да се нарушат промените што се воведуваат во начинот на кој се користи функцијата. Постои речиси нула ризик таа функција да стане застарена или неодржувана.
Во случај на вградено ѕидарство, бидејќи тоа е примитивен распоред, го користите од CSS, исто како Grid или Flexbox, без вклучен JS. Исто така, другите својства на CSS поврзани со распоредот, како што е јазот, работат како што очекувате. Нема трикови или решенија за да знаете, а работите што ги учите се документирани на MDN. За Masonry JS lib, иницијализацијата е малку сложена: бара атрибут на податоци со специфична синтакса, заедно со скриени HTML елементи за да се постават големини на колоните и празнините. Плус, ако сакате да ги опфаќате колоните, треба сами да ја вклучите големината на празнината за да избегнете проблеми:
<стил> .track-sizer, .точка { ширина: 20%; } .gutter-sizer { ширина: 1рем; } .точка { висина: 100 px; маргина-блок-крај: 1рем; } .item:nth-child(непарно) { висина: 200 px; } .item--width2 { ширина: калк (40% + 1рем); }
Ајде да го споредиме ова со тоа како би изгледала вградената ѕидарска имплементација: <стил> .контејнер { приказ: мрежа-ленти; мрежа-ленти: повторување (4, 20%); јаз: 1рем; } .точка { висина: 100 px; } .item:nth-child(непарно) { висина: 200 px; } .item--width2 { решетка-колона: распон 2; }
Поедноставен, покомпактен код што може да користи работи како што се јазот и каде што се протегаат патеките се прават со распон 2, исто како во мрежата, и не бара од вас да ја пресметате вистинската ширина што ја вклучува големината на јазот. Како да знаете што е достапно и кога е достапно? Генерално, прашањето не е навистина дали треба да користите вградено ѕидарство над библиотека JS, туку кога. Библиотеката Masonry JS е неверојатна и ја пополнува празнината во веб-платформата многу години, и за многу среќни програмери и корисници. Се разбира, има неколку недостатоци ако го споредите со вградена ѕидарска имплементација, но тие не се важни ако таа имплементација не е подготвена. Лесно ми е да ги наведам овие кул нови функции на веб-платформи бидејќи работам во продавач на прелистувачи и затоа имам тенденција да знам што доаѓа. Но, програмерите често споделуваат, анкети по анкети, дека е тешко да се следат новите работи. Да се остане информиран е тешко, а компаниите и онака не секогаш даваат приоритет на учењето. За да помогнете во ова, еве неколку ресурси кои обезбедуваат ажурирања на едноставни и компактни начини за да можете брзо да ги добиете потребните информации:
Веб-платформата има локација за истражувач: Можеби ќе ве интересира страницата со белешки за издавање. И, ако ви се допаѓа RSS, проверете го изворот за белешки за објавување, како и доводите за новодостапни и широко достапни основни линии.
ВебКонтролна табла за статус на платформата: Можеби ќе ви се допаднат нејзините различни страници за основната година.
Страница со патоказ на статусот на платформата на Chrome.
Ако имате малку повеќе време, можеби ќе ве интересираат и белешките за објавување на продавачите на прелистувачи:
Хром Работ Firefox Сафари
За уште повеќе ресурси, проверете го мојот лист за навигација на веб-платформа за измамници. Мојата работа сè уште не е имплементирана Тоа е другата страна на проблемот. Дури и ако најдете време, енергија и начини за следење, сè уште постои фрустрација кога ќе го слушнете вашиот глас и ќе ги имплементирате вашите омилени функции. Можеби сте чекале со години да се реши одредена грешка или одредена функција да се испрати во прелистувач каде што сè уште недостасува. Она што ќе го кажам е дека продавачите на прелистувачи слушаат. Јас сум дел од неколку меѓуорганизациски тимови каде што постојано разговараме за сигналите и повратните информации од програмерите. Разгледуваме многу различни извори на повратни информации, и внатрешни кај секој продавач на прелистувач и надворешни/јавни на форуми, проекти со отворен код, блогови и анкети. И, ние секогаш се обидуваме да создадеме подобри начини за програмерите да ги споделат нивните специфични потреби и случаи на употреба. Затоа, ако можете, побарајте повеќе од продавачите на прелистувачи и притискајте нè да ги имплементираме функциите што ви се потребни. Сфаќам дека е потребно време, а исто така може да биде застрашувачко (да не зборуваме за висока бариера за влез), но исто така функционира. Еве неколку начини на кои можете да го слушнете гласот на вашиот (или на вашата компанија): Земете ги годишните анкети за состојбата на JS, состојбата на CSS и состојбата на HTML. Тие играат голема улога во тоа како продавачите на прелистувачи им даваат приоритет на нивната работа. Ако ви треба специфичен стандарден API кој треба постојано да се имплементира низ прелистувачите, размислете да поднесете предлог на следната итерација на проектот Interop. Потребно е повеќе време, но размислете како Shopify и RUMvision ги споделија своите списоци со желби за Interop 2026. Деталните информации како оваа може да бидат многу корисни за продавачите на прелистувачи да им дадат приоритет. За покорисни врски за влијание врз продавачите на прелистувачи, проверете го мојот лист за навигација на веб-платформа за измамници. Заклучок За крај, се надевам дека оваа статија ви остави неколку работи за размислување:
Возбуда за ѕидање и други претстојни веб-функции. Неколку веб-функции што можеби ќе сакате да започнете да ги користите. Неколку парчиња прилагоден или код од трета страна што можеби ќе можете да ги отстраните во корист на вградените функции. Неколку начини да следите што доаѓа и да влијаете на продавачите на прелистувачи.
Што е уште поважно, се надевам дека ве убедив во придобивките од користењето на веб-платформата до нејзиниот полн потенцијал.
