BEM: una nueva metodología front-end

1. Lecturas adicionales sobre SmashingMag:
2. Principios BEM
3. Principios BEM
4. Dominio de datos unificado
   1. Bloquear
   2. Elemento
5. Medios para describir páginas y plantillas
6. Independencia del bloque
   1. CSS independiente
   2. Plantillas independientes
7. Reiteración de bloques
8. Modificadores para elementos y bloques
9. Abstracción de la materia
10. Consistencia de bloques
11. Ubicación inequívoca del código
12. Niveles de definición
13. Construyendo una página

Este artículo es el sexto de nuestra nueva serie que presenta las herramientas y técnicas más recientes, útiles y disponibles gratuitamente, desarrolladas y publicadas por miembros activos de la comunidad de diseño web. El primer artículo trataba sobre PrefixFree ; el segundo presentó Foundation , un marco responsivo; el tercero presentó Sisyphus.js , una biblioteca para borradores del lado del cliente similar a Gmail, el cuarto cubrió un complemento gratuito llamado GuideGuide y el quinto presentó el generador de cuadrículas responsivo Gridpak de Erskine Design . Hoy nos complace presentar un conjunto de herramientas ideado por Yandex: BEM .

Este artículo es el sexto de nuestra nueva serie que presenta las herramientas y técnicas más recientes, útiles y disponibles gratuitamente, desarrolladas y publicadas por miembros activos de la comunidad de diseño web. El primer artículo trataba sobre PrefixFree ; el segundo presentó Foundation , un marco responsivo; el tercero presentó Sisyphus.js , una biblioteca para borradores del lado del cliente similar a Gmail, el cuarto compartió con nosotros un complemento gratuito llamado GuideGuide y el quinto presentó el generador de cuadrículas responsivo Gridpak de Erskine Design . Hoy nos complace presentar un conjunto de herramientas ideado por Yandex: BEM .

BEM significa "Bloque", "Elemento", "Modificador". Es una metodología front-end: una nueva forma de pensar a la hora de desarrollar interfaces Web. Este artículo profundizará en la teoría y la práctica de la creación de sitios web en Yandex, una de las empresas de Internet líderes en Rusia.

El artículo consta de tres partes: Principios BEM, Reiteración de bloques y Representación del sistema de archivos para un bloque.

Lecturas adicionales sobre SmashingMag:

• Reducción de la metodología BEM para proyectos pequeños
• La evolución de la metodología BEM
• Luchando contra BEM: 10 problemas comunes y cómo evitarlos

Principios BEM

Para empezar, pongamos a BEM en una perspectiva histórica.

Comenzamos a esbozar el marco de trabajo interno de Yandex alrededor del año 2007, comenzando con una sólida convención de nomenclatura CSS y un diseño de sistema de archivos asociado a ella. Dado que la convención de nomenclatura estaba bien estructurada, parecía adecuado desarrollar ciertos asistentes de JavaScript (para trabajar con las clases DOM y CSS en particular, en un nivel más alto de abstracción). Luego utilizamos esos enfoques para crear una biblioteca interna de componentes de interfaz de usuario que podrían compartirse entre nuestros diversos sitios web y aplicaciones enriquecidas, creadas utilizando diferentes pilas de tecnología (XML/XSLT, Python/Django, Perl/TT2).

A medida que nuestras ambiciones, complejidad y requisitos de rendimiento crecieron, apuntamos a reemplazar las plantillas XSLT y Perl con una plantilla declarativa DSL basada en JS, construida sobre Node.js. Junto con esos esfuerzos, buscamos simplificar el flujo de trabajo de desarrollo y desarrollamos un conjunto de herramientas de línea de comandos que ya nos ayudaron a administrar el código de front-end en el sistema de archivos, preprocesar código CSS y JavaScript, etc., etc.

Algunas partes de la pila BEM comenzaron como proyectos de código abierto, mientras que otras (como la biblioteca de componentes de la interfaz de usuario) se están abriendo gradualmente. Nuestro objetivo es publicar la mayoría de ellos durante 2012.

BEM es un conjunto de herramientas que ayudará a abordar y resolver problemas de front-end de forma rápida y eficaz. Está disponible en una variedad de bibliotecas de códigos reutilizables; todas ellas están alojadas en Github y son completamente de código abierto.

Principios BEM

Uno de los ejemplos más comunes de metodología en programación es la Programación Orientada a Objetos . Es un paradigma de programación plasmado en muchos lenguajes. En cierto modo, BEM es similar a OOP: una forma de describir la realidad en código, con una variedad de patrones y una forma de pensar sobre las entidades del programa independientemente de los lenguajes de programación que se utilicen.

Hemos utilizado los principios de BEM para crear un conjunto de técnicas y herramientas de desarrollo front-end que nos permiten crear sitios web rápidamente y mantenerlos durante un largo período de tiempo. Los principios son los siguientes:

Dominio de datos unificado

Imagine un sitio web normal, como el que se muestra a continuación:

Al desarrollar un sitio web de este tipo, es útil marcar los "bloques" que lo componen. Por ejemplo Head, en esta imagen hay bloques Main Layouty Foot. El a su vez Headconsta de Logo, y . contiene a y a :SearchAuth BlockMenuMain LayoutPage TitleText Block

Darle un nombre a cada parte de la página es muy útil cuando se trata de comunicación en equipo.

Un director de proyecto podría preguntar:

• Para hacer el Headmás grande, o
• Para crear una página sin Searchformulario en Head.

Un experto en HTML podría preguntarle a un compañero desarrollador de JavaScript:

• Para hacer Auth Blockanimaciones, etc.

Ahora echemos un vistazo más de cerca a lo que constituye BEM:

Bloquear

A blockes una entidad independiente, un “elemento básico” de una aplicación. Un bloque puede ser simple o compuesto (que contiene otros bloques).

Ejemplo de bloque de formulario de búsqueda:

Elemento

An elementes parte de un bloque que realiza una determinada función. Los elementos dependen del contexto: sólo tienen sentido en el contexto del bloque al que pertenecen.

Ejemplo

Un campo de entrada y un botón son elementos del bloque de búsqueda:

Medios para describir páginas y plantillas

Los bloques y elementos constituyen el contenido de la página. Además de estar presentes en una página, su disposición también es importante.

Los bloques (o elementos) pueden sucederse unos a otros en un orden determinado. Por ejemplo, una lista de productos en un sitio web comercial:

…o elementos del menú:

Los bloques también pueden estar contenidos dentro de otros bloques. Por ejemplo, a Head Blockincluye otros bloques:

Además, nuestros componentes básicos necesitan una forma de describir el diseño de la página en texto sin formato. Para ello, cada bloque y elemento debe tener una palabra clave que lo identifique.

Una palabra clave que designa un bloque específico se llama Block Name. Por ejemplo, Menupuede ser una palabra clave para Menu Blocky Headpuede ser una palabra clave para el Headbloque.

Una palabra clave que designa un elemento se llama Element Name. Por ejemplo, cada elemento de un menú es un elemento Itemdel Menubloque.

Los nombres de los bloques deben ser únicos dentro de un proyecto para designar inequívocamente qué bloque se describe. Sólo las instancias del mismo bloque pueden tener los mismos nombres. En este caso, podemos decir que un bloque está presente en la página dos veces (o 3, 4, veces… etc.).

Los nombres de los elementos deben ser únicos dentro del alcance de un bloque. Un elemento se puede repetir varias veces. Por ejemplo, elementos del menú:

Las palabras clave deben colocarse en un orden determinado. Cualquier formato de datos que admita anidamiento (XML, JSON) servirá:

b:page b:head b:menu ... /b:menu e:column b:logo/ /e:column e:column b:search e:input/ e:buttonSearch/e:button /b:search /e:column e:column b:auth ... /b:auth e:column /b:head/b:page

En este ejemplo, blos eespacios de nombres separan los nodos de bloque de los nodos de elemento.

Lo mismo en JSON:

{ block: 'page', content: { block: 'head', content: [ { block: 'menu', content: ... }, { elem: 'column', content: { block: 'logo' } }, { elem: 'column', content: [ { block: 'search', content: [ { elem: 'input' }, { elem: 'button', content: 'Search' } ] } ] }, { elem: 'column', content: { block: 'auth', content: ... } } ] }}

Los ejemplos anteriores muestran un modelo de objetos con bloques y elementos anidados unos dentro de otros. Esta estructura también puede contener cualquier número de campos de datos personalizados. A esta estructura la llamamos BEM Tree(por analogía con el árbol DOM).

El marcado final del navegador se genera aplicando transformaciones de plantilla (usando XSL o JavaScript) a un árbol BEM.

Si un desarrollador necesita mover un bloque a un lugar diferente en una página, lo hace cambiando el árbol BEM. Las plantillas generan la vista final por sí mismas.

En nuestros productos recientes utilizamos JSON como formato de descripción de página. Luego, un motor de plantillas basado en JS lo convierte en HTML. Las herramientas que utilizamos se enumeran al final de este artículo.

Independencia del bloque

A medida que los proyectos crecen, se tiende a agregar, eliminar o mover bloques en la página. Por ejemplo, es posible que desees intercambiar el Logocon el Auth Blocko colocarlo Menudebajo del Search Block.

Para facilitar este proceso, los bloques deben ser Independent.

Un Independentbloque se implementa de manera que permite una ubicación arbitraria en cualquier lugar de la página, incluido el anidamiento dentro de otro bloque.

CSS independiente

Desde el punto de vista CSS significa que:

• Un bloque (o un elemento) debe tener un "nombre" único (una clase CSS) que pueda usarse en una regla CSS.
• Los elementos HTML no deben usarse en selectores CSS (.menu td), ya que dichos selectores no están inherentemente libres de contexto.
• Deben evitarse los selectores en cascada para varios bloques.

Nomenclatura para clases CSS independientes

Uno de los posibles esquemas de nomenclatura para clases CSS que satisface dichos requisitos es el siguiente:

• La clase CSS de un bloque coincide con su Block Name.

ul .../ul

• La clase CSS para un elemento es a Block Namey Element Nameseparada por algunos caracteres

ul li ... /li li ... /li/ul

Es necesario incluir el nombre del bloque en una clase CSS para que un elemento minimice la cascada. También es importante utilizar separadores de forma coherente para permitir que las herramientas y los ayudantes tengan acceso programático inequívoco a los elementos.

Se pueden utilizar diferentes esquemas de nombres. Eche un vistazo aquí para conocer la convención de nomenclatura que utilizamos.

Plantillas independientes

Desde la perspectiva del motor de plantillas, la independencia de bloque significa que:

• Los bloques y elementos deben estar descritos en los datos de entrada. Los bloques (o elementos) deben tener "nombres" únicos para que cosas como " Menudebe colocarse aquí" se puedan expresar en nuestras plantillas.
• Los bloques pueden aparecer en cualquier lugar de un árbol BEM.

Plantillas independientes para bloques.

Al encontrar un bloque en una plantilla, el motor de plantillas debería poder transformarlo sin ambigüedades en HTML. Por lo tanto, cada bloque debería tener una plantilla para ello.

Por ejemplo, una plantilla puede verse así en XSL:

xsl:template match="b:menu" ul xsl:apply-templates/ /ul/xsl:templatexsl:template match="b:menu/e:item" li xsl:apply-templates/ /lixsl:template

Estamos descartando gradualmente XSLT en nuestros productos en favor de nuestro propio motor de plantillas basado en JavaScript, XJST . Este motor de plantillas absorbe todo lo que nos gusta de XSLT (somos fanáticos de la programación declarativa) y lo implementa con la productividad de JavaScript ya sea en el lado del cliente o del servidor.

Nosotros, en Yandex, escribimos nuestras plantillas utilizando un lenguaje específico de dominio llamado BEMHTML, que se basa en XJST. Las ideas principales de BEMHTML se publican en el club BEM en Ya.Ru (en ruso).

Reiteración de bloques

El segundo Menu Blockpuede ocurrir en el interior Foot Blockde un sitio web. Además, se Text Blockpuede dividir en dos, separados por un anuncio.

Incluso si un bloque fue desarrollado como una unidad singular, el mismo puede aparecer en una página en cualquier momento.

En términos relacionados con CSS, esto significa:

• No se deben utilizar selectores CSS basados ​​en ID. Sólo los selectores de clases satisfacen nuestro requisito de no unicidad.

En el lado de JavaScript significa:

• Los bloques con comportamiento similar se detectan de manera inequívoca: tienen las mismas clases de CSS. El uso de selectores de clases CSS permite seleccionar todos los bloques con un nombre determinado para aplicar el comportamiento dinámico requerido.

Modificadores para elementos y bloques

A menudo necesitamos crear un bloque muy similar a uno existente, pero con una apariencia o comportamiento ligeramente modificado. Digamos que tenemos una tarea:

• Agregue otro Menucon Footerun diseño diferente .

Para evitar desarrollar otro bloque que sea mínimamente diferente de uno existente, podemos usar un archivo Modifier.

A Modifieres una propiedad de un bloque o un elemento que altera su apariencia o comportamiento. Un modificador tiene tanto un nombre como un valor. Se pueden utilizar varios modificadores a la vez.

Ejemplo: un modificador de bloque especifica el color de fondo

Ejemplo: un modificador de elemento cambia el aspecto del elemento "actual"

Desde el punto de vista de los datos de entrada:

• En un árbol BEM, los modificadores son propiedades de una entidad que describe un bloque o un elemento.

Por ejemplo, pueden ser nodos de atributos en XML:

b:menu m_size="big" m_type="buttons" .../b:menu

Lo mismo expresado en JSON:

{ block: 'menu', mods: [ { size: 'big' }, { type: 'buttons' } ]}

Desde el punto de vista CSS:

• Un modificador es una clase CSS adicional para un bloque o elemento.

ul .../ul

.menu_size_big { // CSS code to specify height}.menu_type_buttons .menu__item { // CSS code to change item's look}

Los modificadores de elementos se implementan de la misma manera. Nuevamente, al escribir CSS a mano, es muy importante usar separadores de manera consistente para el acceso programático.

Por ejemplo, el elemento del menú actual se puede marcar con un modificador:

b:menu e:itemIndexe:item e:item m_state="current"Products/e:item e:itemContacte:item/b:menu

{ block: 'menu', content: [ { elem: 'item', content: 'Index' }, { elem: 'item', mods: { 'state' : 'current' }, content: 'Products' }, { elem: 'item', content: 'Contact' } ]}

div ul li divIndex/div /li li divProducts/div /li li divContact/div /li /ul/div

.menu__item_state_current { font-weight: bold;}

Abstracción de la materia

Cuando muchas personas trabajan en un proyecto, deben acordar un dominio de datos y utilizarlo al nombrar sus bloques y elementos.

Por ejemplo, un Tag Cloudbloque siempre lleva el nombre Tags. Cada uno de sus elementos es un Tag. Esta convención se extiende a todos los lenguajes: CSS, JavaScript, XSL, etc.

Desde el punto de vista del proceso de desarrollo:

• Todos los participantes operan en los mismos términos.

Desde el punto de vista CSS:

• CSS para bloques y elementos se puede escribir en un pseudolenguaje que se compila en CSS de acuerdo con la convención de nomenclatura.

 .menu { __layout { display: inline; } __layout-item { display: inline-block; ... } __item { _state_current { font-weight: bold; } } }

En el lado de JavaScript:

• En lugar de utilizar selectores de clases directamente para buscar elementos DOM, se puede utilizar una biblioteca auxiliar especial.

$('menu__item').click( ... );$('menu__item').addClass('menu__item_state_current');$('menu').toggle('menu_size_big').toggle('menu_size_small');

La convención de nomenclatura para clases CSS de bloques y elementos puede cambiar con el paso del tiempo. El uso de funciones especiales de JavaScript para acceder a bloques y elementos (y trabajar con sus modificadores) hace posible cambiar solo estas funciones si cambia la convención de nomenclatura.

Block('menu').elem('item').click( ... );Block('menu').elem('item').setMod('state', 'current');Block('menu').toggleMod('size', 'big', 'small');

El código anterior es abstracto. En la vida real usamos el núcleo JavaScript del i-bembloque de la bem-blbiblioteca de bloques: https://bem.github.com/bem-bl/sets/common-desktop/i-bem/i-bem.ru.html (descrito en ruso )

Consistencia de bloques

Un sitio web tiene un Buttonbloque con cierto comportamiento dinámico.

Cuando se pasa el cursor sobre un bloque, cambia su apariencia.

Un gerente podría preguntar:

• Para usar el mismo botón en otra página.

Tener una implementación CSS de un bloque no es suficiente. Reutilizar un bloque también significa reutilizar su comportamiento, descrito en JavaScript.

Por tanto, un bloque debe “saber” todo sobre sí mismo. Para implementar un bloque, describimos su apariencia y comportamiento en todas las tecnologías que se utilizan; a eso lo llamamos Multilingualism.

MultilingualLa presentación es una descripción de un bloque en todos los lenguajes de programación que son necesarios para implementar la vista y la funcionalidad de ese bloque.

Para tener un bloque presente en una página como elemento de la interfaz de usuario, debemos implementarlo en las siguientes tecnologías:

• Plantillas (XSL, TT2, JavaScript, etc.), que convierten declaraciones de bloques en código HTML.
• CSS que describe la apariencia del bloque.

Si un bloque tiene comportamiento dinámico, lo agregamos a esta lista:

• Una implementación de JavaScript para el bloque.

Todo lo que constituye un bloque es una tecnología, incluidas las imágenes.

Ubicación inequívoca del código

Nomenclatura de archivos

Cuando un proyecto es:

• De larga vida y en constante desarrollo.

Si el equipo de desarrollo:

• Está formado por varias personas.
• Crece y cambia.

Entonces, poder navegar rápidamente por la base del código es crucial.

El código de bloque es más fácil de encontrar cuando se coloca en archivos usando el mismo esquema de nombres que usamos para nombrar nuestras entidades:

menu.xslmenu.jsmenu.css

Expresar bloques en un sistema de archivos

Podría haber una tarea:

• Reutilizar algunos bloques de un proyecto anterior para uno nuevo.

Queremos que el procedimiento de reutilización de bloques sea lo más simple posible, como simplemente copiar los archivos o utilizar la extracción parcial de un repositorio de un proyecto "donante". En ambos casos, es útil tener todos los archivos en el mismo directorio:

menu/ menu.xsl menu.js menu.css

Estructura de archivos de un bloque

Al trabajar en un proyecto es posible que necesitemos cambiar algún bloque en algún momento.

Un gerente podría preguntar:

• Para cambiar el color del Current Menu Item,o
• Para hacer Menureaccionar al pasar el mouse.

Un desarrollador podría preguntarle a su colega:

• Para ayudar con Search Formel estilo para IE.

Para comprender dónde se encuentra el código relevante, siga estas reglas (o similares):

• El código de bloque se coloca en un directorio separado.
  • El nombre del directorio coincide con el nombre del bloque.
  • La implementación se coloca en este directorio.
• Los elementos se colocan en subdirectorios bajo el directorio del bloque.
  • El nombre del directorio coincide con el nombre del elemento.
  • La implementación se coloca en este directorio.
• Los modificadores se colocan en subdirectorios bajo el directorio del bloque.
  • El nombre del directorio coincide con el nombre del modificador.
  • La implementación se coloca en este directorio.
  • El nombre del archivo incluye tanto la clave como el valor del modificador (nuevamente, para acceso programático).

Ejemplo

Estructura de archivos de un Menubloque:

menu/ __item/ _state/ menu__item_state_current.css menu__item_state_current.xsl menu__item.css menu__item.xsl menu.css menu.js menu.xsl

Mantener dicha estructura de archivos manualmente es, obviamente, un inconveniente. Por eso hemos desarrollado herramientas BEM para manejar la carga. Estas herramientas ayudan a crear la estructura del directorio, colocar archivos, generar contenido de marcador de posición, etc.

Agrupar bloques en directorios

Los grandes portales de Internet a menudo necesitan reutilizar los mismos bloques en diferentes sitios web.

Podría haber una tarea:

• Crear el mismo Footeren todos los sitios web de los portales, o
• Crear un nuevo proyecto utilizando bloques de los sitios web existentes.

Trabajar para una agencia de diseño web a menudo significa que hay que utilizar soluciones típicas para páginas web típicas.

Un director de proyecto podría preguntarle:

• Crear una página de pedido con un formulario web como en el proyecto anterior.

Tenemos que realizar estas tareas evitando preferiblemente copiar bloques manualmente. Por eso es bueno tener un repositorio de bloques compartidos que se puedan vincular a un proyecto. Para ello, los bloques deben unirse en un único directorio.

Este directorio suele denominarse Blocks.

P.ej

blocks/ foot/ head/ menu/ page/ search/

Ese directorio se puede vincular a otro proyecto directamente desde el sistema de control de versiones, de modo que podamos realizar cambios en los bloques compartidos en una única ubicación.

Niveles de definición

Si un grupo de bloques (unidos bajo un directorio) está vinculado a un proyecto directamente (a través de un pago parcial, svn:externals, etc.), entonces cada cambio cometido en estos bloques influye en todos los proyectos.

Al desarrollar un sitio web basado en uno existente, es posible que deseemos:

• Para ampliar la fuente en el Headsitio A sin afectar el sitio B.
• Para agregar animación al mostrar un menú desplegable.

Para hacerlo, debemos poder definir o redefinir bloques en diferentes tecnologías solo para un sitio web específico o solo para ciertas páginas. Esto se puede lograr usando Definition Levels.

A Definition Leveles un conjunto de bloques agrupados en un directorio.

Una implementación de cada bloque de la biblioteca se puede cambiar (o redefinir completamente) a nivel de proyecto.

Desde la perspectiva del proceso de creación de páginas:

• Al crear una página, podemos configurar una lista de niveles (directorios) para usar sus bloques en esa página. P.ej,build-page -l blocks-common -l blocks-my my-page.html

Desde el punto de vista de la estructura del archivo:

• Un proyecto puede tener cualquier número de niveles. Pero sólo los niveles que se evalúan durante la construcción estarán presentes en la página. Es posible especificar diferentes conjuntos de niveles de definición para diferentes partes del sitio web.

En el lado de JavaScript:

• Necesitamos definir el comportamiento dinámico de una página en estilo declarativo. El comportamiento final se obtiene de diferentes niveles de definición. P.ej,

/* blocks-common/dropdown/dropdown.js */Block('dropdown', { init: function() { ... }});/* blocks-my/dropdown/dropdown.js */Block('dropdown', { init: function() { this.__base(); ... }});

Desde el punto de vista de un motor de plantillas:

• Para poder no solo definir, sino redefinir una plantilla, es necesario aplicar una implementación de plantilla anterior. Por ejemplo, para XSL:

xsl:template match="b:head" div !-- Node for extra design -- xsl:apply-imports/ /div/xsl:template

Desde el punto de vista arquitectónico:

• Al desarrollar un portal de varios sitios web, podemos extraer una biblioteca de bloques que sirve como uno de los niveles de definición para todos los sitios web que forman parte del portal. Los bloques de un sitio web específico formarán otro nivel.
• El mismo repositorio puede contener bloques de las versiones móvil y de escritorio. Dicho proyecto tendrá los siguientes niveles: común, móvil, escritorio. Diferentes combinaciones de estos niveles dan la implementación resultante, requerida por páginas específicas.

La biblioteca de bloques de código abierto bem-bl (en desarrollo) es un ejemplo de tener varios niveles de definición en un repositorio.

Construyendo una página

Trabajar en términos de bloques significa tener un archivo Subject-Matter Abstraction. Esta abstracción es sólo para desarrolladores y los navegadores obtendrán una versión compilada del código.

Entonces tenemos Code For Peopley Code For Browsers... no son lo mismo.

• Bloques de código de programadores: los navegadores obtienen el código de toda la página.

Para convertirnos Code For Peopleen Code For Browsersnosotros Builduna página.

Building A Pagesignifica generar código HTML, CSS y JavaScript a partir de una declaración de página (escrita en XML o JSON) mediante la aplicación de implementaciones de bloques declarados.

Del lado de CSS:

• Todos los archivos CSS se combinan en un archivo CSS de "una sola página". A pesar de que el CSS de cada bloque, elemento o modificador se almacena en archivos separados, no es necesario vincular estos archivos a la página tal como está. Es posible recopilar todas las implementaciones de CSS necesarias en un solo archivo. Esto también resuelve el conocido problema del "número de importaciones" en IE y reduce el número de solicitudes HTTP. Para combinar CSS usamos borschik .
• El navegador obtiene código minimizado. Al crear CSS, podemos minimizar y optimizar el código CSS utilizando la utilidad CSSO , por ejemplo.
• Cada navegador puede escribir código CSS especialmente para él. También es posible dividir las implementaciones de CSS para diferentes navegadores y entregar solo el código necesario para cada navegador. setochka—actualmente en prototipo puede usarse para eso.

Desde el punto de vista de JavaScript:

• De manera similar a CSS, los archivos JavaScript se pueden combinar en uno solo.

Desde el punto de vista del motor de plantillas:

• Solo se incluyen las plantillas necesarias. El conjunto final de plantillas que se utilizan para mostrar una página incluye solo las plantillas para los bloques requeridos. Esto aumenta el rendimiento de la plantilla y reduce la probabilidad de efectos secundarios.

Desde el punto de vista del proceso de desarrollo:

• Los robots sirven a las personas (no al revés). El desarrollador escribe el código como mejor le parezca. Los "robots" se encargan (en parte) del rendimiento optimizando el código (además de hacerlo ilegible) al crear una página.

En términos de organiza

Tal vez te puede interesar:

1. ¿Deberían abrirse los enlaces en ventanas nuevas?
2. 24 excelentes tutoriales de AJAX
3. 70 técnicas nuevas y útiles de AJAX y JavaScript
4. Más de 45 excelentes recursos y repositorios de fragmentos de código

BEM: una nueva metodología front-end

Lecturas adicionales sobre SmashingMag:Principios BEMDominio de datos unificadoMedios para describir páginas y plantillasIndependencia del bloqueReiteración

programar

es

https://aprendeprogramando.es/static/images/programar-bem-una-nueva-metodologia-front-end-794-0.jpg

2024-12-02

Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente