Fa uns 15 anys, treballava en una empresa on vam crear aplicacions per a agents de viatges, treballadors d'aeroports i companyies aèries. També hem creat el nostre propi marc intern per a components d'interfície d'usuari i capacitats d'aplicacions d'una sola pàgina. Teníem components per a tot: camps, botons, pestanyes, intervals, taules de dades, menús, selectors de dates, selectes i multiseleccions. Fins i tot teníem un component div. Per cert, el nostre component div va ser fantàstic, ens va permetre fer cantonades arrodonides a tots els navegadors, cosa que, ho creieu o no, no era una cosa fàcil de fer en aquell moment.
El nostre treball va tenir lloc en un moment de la nostra història en què JS, Ajax i HTML dinàmic es van veure com una revolució que ens va portar al futur. De sobte, podíem actualitzar una pàgina de manera dinàmica, obtenir dades d'un servidor i evitar haver de navegar a altres pàgines, que es veia lent i mostrava un gran rectangle blanc a la pantalla entre les dues pàgines. Hi havia una frase, popularitzada per Jeff Atwood (el fundador de StackOverflow), que deia: "Qualsevol aplicació que es pugui escriure en JavaScript s'escriurà eventualment en JavaScript." - Jeff Atwood
En aquell moment, ens va semblar un atreviment d'anar a crear aquestes aplicacions. Em va semblar una aprovació general per fer-ho tot amb JS. Així que ho vam fer tot amb JS, i realment no ens vam prendre el temps per investigar altres maneres de fer les coses. Realment no vam sentir l'incentiu per aprendre correctament què podien fer HTML i CSS. Realment no percebíem el web com una plataforma d'aplicacions en evolució en la seva totalitat. Ho vam veure principalment com una cosa que havíem de solucionar, sobretot quan es tractava del suport del navegador. Podríem llançar-hi més JS per fer les coses. M'hauria ajudat prendre el temps per aprendre més sobre com funcionava la web i què hi havia disponible a la plataforma? Per descomptat, probablement hauria pogut afaitar un munt de codi que realment no era necessari. Però, en aquell moment, potser no tant. Ja veieu, les diferències del navegador eren bastant importants en aquell moment. Aquesta va ser una època en què Internet Explorer encara era el navegador dominant, amb Firefox en segon lloc, però començava a perdre quota de mercat a causa de que Chrome guanyava popularitat ràpidament. Tot i que Chrome i Firefox eren bastant bons per posar-se d'acord en els estàndards web, els entorns en què s'executaven les nostres aplicacions van fer que haguéssim de suportar IE6 durant molt de temps. Fins i tot quan ens van permetre donar suport a IE8, encara vam haver de fer front a moltes diferències entre navegadors. No només això, sinó que la web de l'època no tenia tantes capacitats integrades directament a la plataforma.
Avancem ràpid fins avui. Les coses han canviat enormement. No només tenim més d'aquestes capacitats que mai, sinó que també ha augmentat el ritme a què estan disponibles. Aleshores, permeteu-me que torni a fer la pregunta: us ajudaria avui prendre-vos el temps per obtenir més informació sobre com funciona el web i què hi ha disponible a la plataforma? Absolutament sí. Aprendre a entendre i utilitzar la plataforma web avui en dia us ofereix un gran avantatge respecte a altres desenvolupadors. Tant si treballeu en rendiment, accessibilitat, capacitat de resposta, tots junts, com si només envieu funcions de la interfície d'usuari, si voleu fer-ho com a enginyer responsable, conèixer les eines que teniu disponibles us ajudarà a assolir els vostres objectius més ràpid i millor. Algunes coses per a les quals potser ja no necessiteu una biblioteca Sabent quins navegadors admeten avui dia, la pregunta, doncs, és: què podem abandonar? Necessitem un component div per fer cantonades arrodonides el 2025? Per descomptat, no ho fem. La propietat border-radius ha estat compatible amb tots els navegadors que s'utilitzen actualment durant més de 15 anys en aquest moment. I la forma de cantonada també arribarà aviat, per a racons fins i tot més elegants. Fem una ullada a les funcions relativament recents que ara estan disponibles a tots els navegadors principals i que podeu utilitzar per substituir les dependències existents a la vostra base de codi. La qüestió no és abandonar immediatament totes les biblioteques estimades i reescriure la base de codi. Pel que fa a la resta, primer haureu de tenir en compte el suport del navegador i decidir-ho en funció d'altres factors específics del vostre projecte. Les funcions següents s'implementen als tres motors principals del navegador (Chromium, WebKit i Gecko), però és possible que tingueu diferents requisits de suport del navegador que us impedeixin utilitzar-los immediatament. Ara bé, encara és un bon moment per conèixer aquestes funcions, i potser planejar utilitzar-les en algun moment. Popovers i diàlegs L'API Popover, l'element HTML
Per descomptat, probablement la vostra velocitat de connexió a Internet també ha augmentat, però aquest no és el cas de tothom. I tampoc tothom té les mateixes capacitats del dispositiu. Introduir codi de tercers per a coses que podeu fer amb la plataforma, en canvi, probablement vol dir que envieu més codi i, per tant, arribeu a menys clients del que faríeu normalment. Al web, un mal rendiment de càrrega comporta grans taxes d'abandonament i perjudica la reputació de la marca. Executant menys codi als dispositius A més, el codi que envieu als dispositius dels vostres clients probablement s'executi més ràpid si utilitza menys abstraccions de JavaScript a la part superior de la plataforma. També és probable que sigui més sensible i més accessible per defecte. Tot això porta a més clients i més feliços. Consulteu el bloc anual de bretxa de desigualtat de rendiment del meu col·lega Alex Russell, que mostra que els dispositius premium estan en gran part absents dels mercats amb milers de milions d'usuaris a causa de la desigualtat de la riquesa. I aquesta bretxa no fa més que augmentar amb el temps.
Disseny de maçoneria incorporat Una característica de la plataforma web que arribarà aviat i que m'entusiasma molt és CSS Masonry.
Començaré explicant què és la maçoneria. Què és la maçoneria La maçoneria és un tipus de disseny que Pinterest va popularitzar fa anys. Crea pistes independents de contingut en les quals els articles s'embalen tan a prop de l'inici de la pista com poden.
Molta gent veu la maçoneria com una gran opció per a carteres i galeries de fotos, cosa que sens dubte pot fer. Però Masonry és més flexible que el que veieu a Pinterest i no es limita només a dissenys semblants a una cascada. En una disposició de maçoneria:
Les pistes poden ser columnes o files:
Les pistes de contingut no han de ser totes de la mateixa mida:
Els elements poden abastar diverses pistes:
Els articles es poden col·locar en pistes específiques; no han de seguir sempre l'algoritme de col·locació automàtica:
Demos Aquí hi ha algunes demostracions senzilles que vaig fer utilitzant la propera implementació de CSS Masonry a Chromium. Una demostració de la galeria de fotos que mostra com els elements (el títol en aquest cas) poden abastar diverses pistes:
Una altra galeria de fotos que mostra pistes de diferents mides:
Un disseny del lloc de notícies amb algunes pistes més amples que altres i alguns elements que abasten tota l'amplada del disseny:
Un tauler kanban que mostra que els elements es poden col·locar en pistes específiques:
Nota: ElLes demostracions anteriors es van fer amb una versió de Chromium que encara no està disponible per a la majoria dels usuaris web, perquè CSS Masonry tot just comença a implementar-se als navegadors. Tanmateix, els desenvolupadors web ja fa anys que utilitzen biblioteques per crear dissenys de maçoneria. Llocs que utilitzen maçoneria avui De fet, la maçoneria és força comú a la xarxa avui dia. Aquí hi ha alguns exemples que he trobat a més de Pinterest:
I uns quants exemples més, menys evidents:
Aleshores, com es van crear aquests dissenys? Solucions alternatives Un truc que he vist utilitzat és utilitzar un disseny Flexbox, canviar-ne la direcció a la columna i configurar-lo per embolicar-lo. D'aquesta manera, podeu col·locar elements de diferents altures en múltiples columnes independents, donant la impressió d'una disposició de maçoneria:
Tanmateix, hi ha dues limitacions amb aquesta solució alternativa:
L'ordre dels elements és diferent del que seria amb un disseny de maçoneria real. Amb Flexbox, els elements omplen primer la primera columna i, quan estigui plena, després aneu a la següent columna. Amb Masonry, els elements s'apilarien a qualsevol pista (o columna en aquest cas) que tingui més espai disponible. Però també, i potser el més important, aquesta solució requereix que establiu una alçada fixa al contenidor Flexbox; en cas contrari, no es produiria cap embolcall.
Biblioteques de maçoneria de tercers Per a casos més avançats, els desenvolupadors han estat utilitzant biblioteques. La biblioteca més coneguda i popular per a això s'anomena simplement Masonry, i es descarrega unes 200.000 vegades per setmana segons NPM. Squarespace també proporciona un component de disseny que representa un disseny Masonry, com a alternativa sense codi, i molts llocs l'utilitzen. Ambdues opcions utilitzen codi JavaScript per col·locar elements al disseny. Maçoneria encastada Estic molt emocionat que Masonry comenci a aparèixer als navegadors com a funció CSS integrada. Amb el pas del temps, podreu utilitzar Masonry com ho feu Grid o Flexbox, és a dir, sense necessitat de cap solució alternativa ni codi de tercers. El meu equip de Microsoft ha implementat el suport de Masonry integrat al projecte de codi obert Chromium, en què es basen Edge, Chrome i molts altres navegadors. De fet, Mozilla va ser el primer proveïdor de navegadors que va proposar una implementació experimental de Masonry el 2020. I Apple també s'ha mostrat molt interessada a fer que aquest nou disseny web sigui primitiu. El treball per estandarditzar la funció també avança, amb un acord dins del grup de treball CSS sobre la direcció general i fins i tot una nova pantalla de tipus de pantalla: carrils de graella. Si voleu obtenir més informació sobre Masonry i fer un seguiment del progrés, consulteu la meva pàgina de recursos de CSS Masonry. Amb el temps, quan Masonry es converteixi en una característica de base, igual que Grid o Flexbox, podrem utilitzar-la simplement i beneficiar-nos de:
Millor rendiment, Millor capacitat de resposta, Facilitat d'ús i codi més senzill.
Fem una ullada més de prop a aquests. Millor Rendiment Fer el vostre propi sistema de disseny semblant a Masonry, o utilitzar una biblioteca de tercers, vol dir que haureu d'executar codi JavaScript per col·locar elements a la pantalla. Això també significa que aquest codi bloquejarà la representació. De fet, no apareixerà res, o les coses no estaran als llocs adequats o de la mida adequada, fins que s'hagi executat el codi JavaScript. El disseny de maçoneria s'utilitza sovint per a la part principal d'una pàgina web, el que significa que el codi faria que el vostre contingut principal aparegués més tard del que podria tenir d'una altra manera, degradant el vostre LCP o mètrica de pintura de contingut més gran, que té un paper important en el rendiment percebut i l'optimització del motor de cerca. Vaig provar la biblioteca Masonry JS amb un disseny senzill i simulant una connexió 4G lenta a DevTools. La biblioteca no és molt gran (24 KB, 7,8 KB comprimit), però va trigar 600 ms a carregar-se sota les meves condicions de prova. Aquí hi ha una gravació d'actuació que mostra el temps de càrrega de 600 ms llarg de la biblioteca Masonry i que no s'ha produït cap altra activitat de renderització mentre passava:
A més, després del temps de càrrega inicial, calia analitzar, compilar i executar l'script descarregat. Tot això, com s'ha esmentat abans, bloquejava la representació de la pàgina. Amb una implementació de Masonry integrada al navegador, no tindrem un script per carregar i executar. El motor del navegador només farà les seves coses durant el pas inicial de representació de la pàgina. Millor resposta De la mateixa manera que quan es carrega per primera vegada una pàgina, canviar la mida de la finestra del navegador fa que el disseny torni a mostrar-se en aquesta pàgina. En aquest punt, però, si la pàgina utilitza la biblioteca Masonry JS, no cal que torneu a carregar l'script, perquè ja ho és.aquí. Tanmateix, el codi que mou els elements als llocs adequats s'ha d'executar. Ara, aquesta biblioteca en particular sembla ser bastant ràpida a l'hora de fer-ho quan es carrega la pàgina. Tanmateix, anima els elements quan necessiten moure's a un lloc diferent en el canvi de mida de la finestra, i això marca una gran diferència. Per descomptat, els usuaris no passen temps redimensionant les finestres del seu navegador tant com ho fem nosaltres els desenvolupadors. Però aquesta experiència de canvi de mida animada pot ser bastant molesta i augmenta el temps percebut que triga la pàgina a adaptar-se a la seva nova mida. Facilitat d'ús i codi més senzill El fàcil que és utilitzar una funció web i el senzill que sembla el codi són factors importants que poden marcar una gran diferència per al vostre equip. No poden ser mai tan importants com l'experiència de l'usuari final, per descomptat, però l'experiència del desenvolupador afecta el manteniment. L'ús d'una funció web integrada comporta avantatges importants en aquest sentit:
Els desenvolupadors que ja coneixen HTML, CSS i JS probablement podran utilitzar aquesta funció fàcilment perquè s'ha dissenyat per integrar-se bé i ser coherent amb la resta de la plataforma web. No hi ha cap risc que s'introdueixin canvis trencats en l'ús de la funció. Hi ha gairebé zero risc que aquesta funció quedi obsoleta o no es mantingui.
En el cas de la maçoneria integrada, com que és un disseny primitiu, l'utilitzeu des de CSS, igual que Grid o Flexbox, sense JS implicat. A més, altres propietats CSS relacionades amb el disseny, com ara gap, funcionen com esperíeu. No hi ha trucs ni solucions alternatives per conèixer, i les coses que aprens estan documentades a MDN. Per a la lib Masonry JS, la inicialització és una mica complexa: requereix un atribut de dades amb una sintaxi específica, juntament amb elements HTML ocults per establir les mides de columna i espai. A més, si voleu abastar columnes, heu d'incloure la mida de l'espai per evitar problemes:
Comparem això amb com seria una implementació de maçoneria integrada:
Codi més senzill i compacte que només pot utilitzar coses com la bretxa i on les pistes que abasten es fa amb l'abast 2, igual que a la quadrícula, i no requereix que calculeu l'amplada correcta que inclou la mida de l'espai. Com saber què hi ha disponible i quan està disponible? En general, la pregunta no és realment si hauríeu d'utilitzar Masonry integrada sobre una biblioteca JS, sinó quan. La biblioteca Masonry JS és increïble i ha estat omplint un buit a la plataforma web durant molts anys i per a molts desenvolupadors i usuaris feliços. Té alguns inconvenients si el compareu amb una implementació de maçoneria integrada, per descomptat, però aquests no són importants si aquesta implementació no està preparada. És fàcil per a mi enumerar aquestes noves funcions interessants de la plataforma web perquè treballo en un proveïdor de navegadors i, per tant, acostumo a saber què m'arriba. Però els desenvolupadors sovint comparteixen, enquesta rere enquesta, que fer un seguiment de les coses noves és difícil. Mantenir-se informat és difícil i, de totes maneres, les empreses no sempre prioritzen l'aprenentatge. Per ajudar-vos amb això, aquí teniu uns quants recursos que proporcionen actualitzacions de manera senzilla i compacta perquè pugueu obtenir la informació que necessiteu ràpidament:
La plataforma web inclou un lloc explorador: Potser us interessarà la seva pàgina de notes de llançament. I, si us agrada l'RSS, consulteu el canal de notes de la versió, així com els canals de base recentment disponibles i àmpliament disponibles.
La WebTauler d'estat de la plataforma: Potser us agraden les seves diverses pàgines de l'any de referència.
Pàgina de full de ruta de Chrome Platform Status.
Si teniu una mica més de temps, també us poden interessar les notes de llançament dels proveïdors de navegadors:
Chrome Edge Firefox Safari
Per obtenir encara més recursos, consulteu el meu full de trucs de navegació per la plataforma web. La meva cosa encara no s'ha implementat Aquesta és l'altra cara del problema. Fins i tot si trobeu el temps, l'energia i les maneres de fer un seguiment, encara hi ha frustració per fer escoltar la vostra veu i implementar les vostres funcions preferides. Potser fa anys que espereu que es resolgui un error específic o una funció específica que s'enviï en un navegador on encara falta. El que diré és que els venedors de navegadors escolten. Formo part de diversos equips entre organitzacions on discutim els senyals i els comentaris dels desenvolupadors tot el temps. Observem moltes fonts de comentaris diferents, tant internes a cada proveïdor de navegadors com externes/públiques en fòrums, projectes de codi obert, blocs i enquestes. A més, sempre estem intentant crear millors maneres perquè els desenvolupadors comparteixin les seves necessitats i casos d'ús específics. Per tant, si podeu, exigiu més als proveïdors de navegadors i pressioneu-nos perquè implementem les funcions que necessiteu. Entenc que requereix temps i també pot ser intimidant (per no parlar d'una gran barrera d'entrada), però també funciona. Aquí teniu algunes maneres de fer sentir la vostra veu (o la de la vostra empresa): feu les enquestes anuals sobre l'estat de JS, l'estat de CSS i l'estat d'HTML. Tenen un paper important en la manera com els venedors de navegadors prioritzen la seva feina. Si necessiteu una API basada en estàndards específica per implementar-se de manera coherent en tots els navegadors, penseu a enviar una proposta a la propera iteració del projecte Interop. Requereix més temps, però tingueu en compte com Shopify i RUMvision van compartir les seves llistes de desitjos per a Interop 2026. Informació detallada com aquesta pot ser molt útil perquè els venedors de navegadors prioritzin. Per obtenir enllaços més útils per influir en els proveïdors de navegadors, consulteu el meu full de trucs de navegació per la plataforma web. Conclusió Per tancar, espero que aquest article us hagi deixat amb algunes coses per pensar:
Entusiasme per Masonry i altres funcions web properes. Algunes funcions web que potser voldreu començar a utilitzar. Alguns fragments de codi personalitzat o de tercers que podeu eliminar a favor de les funcions integrades. Algunes maneres de fer un seguiment del que ve i influir en els proveïdors de navegadors.
Més important encara, espero haver-vos convençut dels avantatges d'utilitzar la plataforma web al màxim.
