La encarnación en 2019 de theguardian.com comenzó su vida hace aproximadamente seis años, comenzando como un punto-m y aumentando gradualmente sus puntos de corte y vistas de página hasta que representó todo el sitio.
Al momento de escribir este artículo, ha pasado de 0 a 62,783 líneas de Sass. Ese Sass genera decenas de miles de reglas que pretenden describir un conjunto de respuestas sostenibles a problemas de negocios y diseño.
Individualmente, representan decisiones consideradas durante media década por ingenieros hábiles y dedicados.
En resumen, , presentan una pesadilla precaria, tambaleante, de mantenimiento.
¿De qué manera? Por un lado, es mucho más fácil agregar un nuevo CSS que editarlo o eliminarlo.
En segundo lugar, no está claro cómo debe abordar las ediciones.
Algunos de nuestros selectores son utilidades que describen la presentación (por ejemplo, .hide-on-mobile ) y otros describen características (por ejemplo, [19659002) .facia-card ). Cuando se introduce una nueva característica que deriva su estilo visual de una característica existente, hay varios enfoques que podría copiar: por ejemplo, ¿debería reutilizar las reglas existentes o debería duplicarlas?
Ambos enfoques están en la base del código, y ambos tienen sus inconvenientes.
Si reutiliza algo, tendrá que anular partes de él para capturar cualquier diferencia y estar sujeto a cualquier actualización (potencialmente involuntaria) del original.
Si duplica algo, no heredará ninguna actualización al original que deseaba y la página se vuelve más pesada: la descarga demora más y el lector cuesta más, el árbol de renderización se demora más y el CSSOM ocupa más memoria .
Podría extraer las características comunes en nuevos selectores de utilidades, pero luego suponga que otra persona necesita tomar prestados aspectos de la apariencia de una nueva característica no relacionada y deciden duplicar una de las dos instancias anteriores, para mantener su característica segura de actualizaciones no relacionadas. Cuando la característica original necesita un ajuste de diseño, los tres no están sincronizados, y el segundo también está ahora (probablemente) roto.
En este punto, está seguro de que haga lo que haga, no puede eliminar ninguno de ellos, porque Nadie puede entender realmente cómo todo se interrelaciona. Para evitar romper cualquier cosa, debe conocer todas las funciones del sitio, cómo deben mirar y cómo deben ver después de su cambio.
Usted sin embargo, sabe que si agrega algunas reglas nuevas, protegidas por sus selectores BEM, (probablemente) no romperá nada y nada lo romperá, por lo que se convierte en la cosa más fácil de hacer.
Esto es prácticamente donde estamos ahora.
Para agravar esto, a medida que el CSS se ha vuelto cada vez más espinoso, el apetito por las funciones y la experimentación en todo el Guardian ha crecido. Estos son en gran parte administrados por equipos dedicados a los OKR de un cuarto de longitud que necesitan iterar de forma rápida y segura.
Un sistema complejo de estilo que, en última instancia, solo es seguro si lo agrega no puede sostener esto. Esto conduce a un bajo rendimiento en los dispositivos de nuestros lectores, lo que en última instancia devalúa tanto su experiencia de lectura como el periodismo, y es desagradable de desarrollar.
¿Y ahora qué?
Para abordar esto, y evitar terminar de nuevo aquí en unos pocos En primer lugar, necesitamos entender cómo llegamos aquí.
Cuando fue concebido, el sitio existente fue construido por alrededor de diez desarrolladores utilizando herramientas y técnicas de última generación (un desarrollador incluso se dedicó a mantener un El marco interno de CSS y se interesó especialmente en los cambios que lo utilizaban).
A medida que el enfoque de la ingeniería pasó de crear un sitio web a iterar aspectos del mismo, aumentó la cantidad de personas que tocaban el código y la amplitud de sus cambios. Ya no es posible que una persona actúe como portero. Con seis años de rotación de desarrolladores, también se ha vuelto cada vez más difícil entender el contexto de su cambio en la base de código más amplia: ¿qué puede hacer? ¿Qué han hecho otras personas? ¿Qué debería hacer?
A medida que pasa el tiempo, estas preguntas se vuelven cada vez más difíciles de responder, y el motivo es que sus respuestas se basan en convenciones .
El problema con la Convención [19659018] Los sistemas que intentan contener la complejidad durante largos períodos de tiempo por convención tenderán inevitablemente a la entropía, porque una característica importante de la convención es que es trivialmente sencillo romper una.
Ni siquiera necesita ser malicioso. Una convención no es una línea en la arena . Puede tener un buen caso para romper o estirar uno, pero una vez que una convención ya no se cumple por completo, los casos subsiguientes para romperla o estirarla son automáticamente más fuertes, porque la convención ya está debilitada. Cuanto más sucede esto, más se debilita.
En nuestro caso, las convenciones que existían para fomentar la simplicidad se volvieron borrosas. Por ejemplo, nuestro Sass está destinado a seguir a BEM, pero en los casos en los que los requisitos de diseño crearían demasiados selectores, volverá de forma predeterminada a la cascada.
Al mismo tiempo, se supone que todas las ediciones simpatizan con el rendimiento, Porque esa ha sido durante mucho tiempo otra convención. Pero un equipo de OKR dedicado a mover una métrica de ingresos podría justificar razonablemente el privilegio de las conversiones sobre la velocidad de la página o el desarrollo a más largo plazo, especialmente si la función es de corta duración o la compensación es pequeña.
La consecuencia de nuestra confianza en la convención para manejar esto es que nuestro Sass se ha vuelto muy difícil de trabajar, y el CSS es demasiado grande como para enviarlo.
¿Qué podríamos hacer?
Podríamos tratar con el Sass siendo más estrictos con respecto a nuestra adhesión a BEM , trabajando efectivamente en un estilo hiper-modular, implementando un acoplamiento extremadamente estricto de selectores a elementos DOM, es decir, pensando en componentes. Esto significaría que podría estar seguro de que sus ediciones afectaron solo los elementos que conocía a sus selectores, y también podría saber que si eliminara una plantilla, podría eliminar el Sass relevante.
Esto resolvería el mantenimiento a expensas del rendimiento : la cantidad de duplicación y el número de selectores se dispararían.
Alrededor del momento en que empezamos a ver esto, empezaron a aparecer los marcos de CSS atómicos. Los enfoques como el Atomic CSS de Yahoo y el Tachyons de Adam Morse significan que puede estar seguro de que el CSS que envía a su usuario será muy, muy pequeño, casi tan pequeño como podría ser. [19659002] Ya que requieren que usted mismo diseñe elementos, en lugar de crear reglas que se apliquen a los elementos, también facilitan mucho el mantenimiento. La presentación se acopla directamente al contenido: si actualiza o elimina una plantilla, no se verá afectado nada más. En el caso de CSS atómico, las declaraciones no utilizadas ni siquiera se generarán.
Ambos enfoques fueron muy atractivos, pero muy difíciles de adoptar con nuestra pila existente. Nuestro HTML es generado por las plantillas Twirl en Play, que está escrito en Scala. Esto significa que el CSS atómico, que administra sus plantillas con Nodo, sería muy difícil de instalar.
Al mismo tiempo, el Scala en juego se compila a los binarios de Java. Si bien esto significa que la reproducción es muy rápida en producción, la edición de una plantilla en desarrollo requiere una recompilación antes de que pueda ver el cambio, lo que suele llevar hasta diez segundos. El uso de un sistema como Tachyons, que requiere que usted estilice sus elementos directamente usando el atributo de clase, sería increíblemente lento para nosotros.
Ambos también requerirán una reescritura total de nuestras plantillas, y la imposición de un nuevo estilo de desarrollo . Si pudiéramos encontrar una manera de aplicar el pensamiento en los enfoques atómicos a un estilo hipermodular de escritura Sass, podríamos mantener la familiaridad de la pila mientras solucionamos los problemas.
Inicio falso
Revisando nuestras diferentes hojas de estilo y pensando en el enfoque atómico, se nos ocurrió que todos nuestros CSS de envío deben poder reducirse a un conjunto de declaraciones únicas.
Si pudiéramos haber recreado el sitio reemplazando nuestro Sass con un conjunto de clases funcionales preexistentes (Tachyons-style), entonces deberíamos poder modificar el enfoque de CSS atómico para que podamos mantener nuestro Sass existente, reescribirlo en parte para requerir duplicación (y así hacer las ediciones seguras) pero analizar la ¿Hojas de estilo resultantes y uso del selector durante el proceso de compilación de producción para reducir esa duplicación a clases de utilidad de uso único?
En desarrollo, solo podríamos servir una enorme hoja de estilos, lo que significa que no hay una recompilación de Scala y mantener la actual Sass rec
Luego, en producción, deberíamos ser capaces de 'atomizar' nuestro CSS a instancias únicas de declaraciones durante la compilación, construir un mapa desde las reglas originales hasta las únicas, y utilizarlo en el Twirl. plantillas en el punto en que escribimos el atributo de clase.
Creamos un 'CSS atomizado' postcss plugin que tomaría una hoja de estilo normal y devolvería una atomizada, y un método para usar ese mapa en el Gire las plantillas y, durante un tiempo, envió una pequeña instancia de en producción.
Se diseñó para que cualquier selector que no pudiera ser atomizado (cualquier cosa que no sea una sola clase, básicamente) pase. directamente, por lo que en teoría deberíamos haber podido agregarlo sin realizar ningún cambio en el Sass, obteniendo los beneficios inmediatamente posibles y pudiendo eliminar gradualmente todos los selectores más complejos hasta que todo estuviera atomizado .
El bit 'en teoría' fue la parte de miedo! Esta técnica significó completamente reescribiendo la hoja de estilo mucho después de que el último desarrollador hubiera tocado el código fuente. Para poder enviar eso con confianza, tendríamos que escribir un conjunto de pruebas que comparara los efectos del original con las hojas de estilo atomizadas, en un DOM que capturó un control y una variante para cada ruta posible en el original. ¡Esa no es una tarea imposible, pero en el momento en que comenzamos a escribir eso, realmente tuvimos que preguntarnos si este era el enfoque más inteligente!
CSS en JS
Sabíamos que estos problemas ya se estaban solucionando, por más y gente más inteligente, en JavaScript land, pero todavía estábamos trabajando con un modelo en el que DOM, CSS y JS existen de forma autónoma. En ningún momento de sus ciclos de vida es consciente del otro. El DOM es la fuente de la verdad cuando se trata del contenido (todo es procesado por el servidor) pero las intenciones expresadas en el CSS y JS solo se realizan si sus suposiciones sobre el DOM son correctas.
Es decir, de esta forma de trabajo, el DOM, CSS y JS se interoperan completamente mediante el contrato . Es decir, un reconocimiento de que los humanos que escriben el código mantendrán ciertas convenciones:
-
el DOM debe proporcionar ganchos para el JS, que debe encontrar un DOM que entiende
-
que el JS puede parchear el DOM para reflejar un nuevo estado, pero debe ser de una manera que el CSS pueda personalizar
-
el CSS debe poder adaptarse a cualquier DOM que encuentre
Como vimos anteriormente, esto significa que las actualizaciones del sitio deben comprender el contexto técnico. de cada edición, no solo cómo resuelven un problema de dominio.
A su vez, esto hace que las actualizaciones sean más complicadas de completar y aumenta la probabilidad de que los errores entren en producción.
Más importante para nosotros, ya que los procesos que generan CSS y HTML no se entienden entre sí, cualquier optimización como aislar CSS crítico es, en el mejor de los casos, propensa a errores y, en el peor de los casos, imposible.
La belleza del trabajo que se está realizando en los distintos marcos CSS-in-JS es que [19659054] JS se hace cargo de manag Ingrese el DOM y tanto en el cliente como en el servidor.
Es una forma de pensar completamente diferente: en lugar de escribir código para el navegador para interpretar, escriba El código que le dice a tu marco cómo quieres que se vean las cosas, y se encarga de generar el código para el navegador para ti.
De esta forma de trabajo, el código comienza a convertirse en una descripción más orientada a las personas de cómo desea resolver los problemas de dominio, no en una orientada al navegador. Al abstraer el código de nivel del navegador, se vuelve más fácil para un desarrollador hacer lo correcto en lugar de lo incorrecto. La arquitectura, y nuestros requisitos de rendimiento y mantenibilidad, son gestionados por el marco, no por el ingeniero.
Así que eso es lo que estamos haciendo. Después de muchas pruebas, hemos decidido (al menos por ahora) el moviendo nuestro nivel de representación a React and Emotion . Esto sin duda generará un nuevo de desafíos, pero esperamos que al menos resuelvan el conjunto que tenemos ahora.
Hay otras publicaciones en el blog que se escribirán sobre cómo resolvimos estos dos aspectos. ; cómo lo encajaremos en la pila; y cómo hemos progresado desde que comenzamos este proyecto.
.
No comments:
Post a Comment