Desarrollo web front-end: ¿cuál es su configuración de flujo de trabajo / proyecto css?

¡Hola de nuevo! 🙂 Mi flujo de trabajo no está tan formalizado como su escenario. Ha evolucionado orgánicamente con el tiempo, se podría decir. He estado haciendo CSS durante mucho tiempo, y he pasado por varios restablecimientos de CSS, todo tipo de formas de organizar el código, pasar de CSS2 a CSS3, surgir HTML5, varios enfoques de codificación receptiva, etc.

Vea el código de alguien que le guste, luego adáptelo al gusto

A través de la experimentación y la experiencia, he elegido las cosas que funcionan mejor para mí. Por ejemplo, he tomado ideas de marcos que me gustan, pero no he encontrado la necesidad de aplicar siempre un marco completo, cualquiera de los cuales termina empujándolo en ciertas direcciones de la interfaz. Me gusta usar solo lo que necesito. Eso se convierte en mi CSS base. Si surge algo nuevo, puedo codificarlo sin demasiado alboroto. Eso está en desacuerdo con todos los reverentes discípulos de Bootstrap que impregnan a Quora. 🙂

La organización es buena

En cuanto a la forma de organizar el código, no encontrará un acuerdo universal. Lo que hago es bastante popular, solo tengo las cosas de reinicio / inicialización en la parte superior, y luego divido el código en secciones para la forma que desee categorizar, tal vez desde el encabezado, la navegación, el contenido, la barra lateral, el pie de página , y así sucesivamente, con un código receptivo en la parte inferior. Hablando de eso, tengo mi código organizado para dispositivos móviles primero.

Escuché una conversación en línea donde 2 codificadores de CSS hablaron sobre cómo siempre alfabetizan sus cosas, al menos dentro de una declaración, y se mostraron bastante firmes al respecto. ¡Eso es demasiado TOC para mí! 🙂 Sin embargo, intentaré agrupar las cosas por función, como tener un conjunto de declaraciones relacionadas con la fuente.

¡El sitio de Leon se está haciendo más grande!

Dicho esto, puede haber buenas razones para usar esas otras herramientas. Digamos que estaba trabajando en un sitio enorme con una gran variedad de elementos de interfaz que necesitaban estilo. Los preprocesadores SASS o LESS podrían ser muy útiles allí, proporcionando variables, algunas operaciones lógicas y otras características que ayudan a organizar y codificar el código CSS.

Tener un sitio muy grande puede justificar el uso de un marco como Bootstrap o Foundation para ayudar a administrarlo.

Cuando tienes enormes montañas de código, cualquier tipo de organización que ayude a los pobres idiotas que tienen que mantenerlo es bueno. Eso es exactamente lo opuesto al tema CSS de Themeforest, que generalmente está cargado de hinchazón, hacks y declaraciones importantes en todas partes, lo que hace que el código sea desagradable para trabajar.

Sala de control a mayor Tom

Normalmente tengo el lujo de ser el único codificador de CSS. Si hay más personas que usted en él, algún control de versión sería extremadamente útil, como GIT.

Gracias por el A2A.

Build / Tasks: puede variar según las especificaciones del proyecto, pero generalmente uso Gulp con BrowserSync y ESLint. También NPM para descargar / instalar cosas.

Estructura del proyecto: cada proyecto está estructurado de manera diferente y tampoco tengo una opción preferible. Simplemente elija cuál es más conveniente para cada caso.

Arquitectura CSS: mi arquitectura CSS es bastante simple:

  • Base (Normalizar, fuentes y cosas que vendrían primero en CSS)
  • Componentes (elementos que veo que se repiten, como bloques reutilizables)
  • Ayudantes (aquí pongo todas las extensiones, funciones y mixins)
  • Diseño (encabezado, pie de página, barra lateral, también un lugar para hackear IE)
  • Páginas (cosas particulares para páginas específicas)
  • Temas (cosas para personalizar el back-end)

Frameworks: a menos que se especifique previamente, no utilizo ningún framework front-end.

Preprocesadores: SCSS (Gulp-SASS), pero confieso que es solo por conveniencia de anidación y SECO. Utilizo la versión SASS adaptada de FlexBoxGrid, hecha por Huge.

Estructura del código: para JS trato de seguir el patrón del módulo. Para HTML5 sigo algunas buenas prácticas.

Confío en webpack en estos días. Dado que mis proyectos tienden a ser tan pequeños, confío solo en CSS vainilla con una convención de nomenclatura aproximada. Si hiciera proyectos más grandes, probablemente adoptaría Módulos CSS, ya que resuelven un punto importante de CSS: los globales. Cuando todo es local por defecto, no tiene que preocuparse por las colisiones de espacios de nombres.

He escrito más sobre el tema y las técnicas involucradas en SurviveJS – Webpack. Especialmente en el mundo React, el estilo es uno de esos aspectos que aún se debate. Siento que gran parte de la discusión gira en torno a cómo superar las debilidades de CSS.

Debido al diseño básico, tenemos que confiar en procesadores CSS, convenciones, etc. Esta es la razón principal por la que estoy tan entusiasmado con los módulos CSS. Se salta muchos problemas al cambiar los axiomas. Todavía podemos usar nuestras habilidades de CSS. El enfoque se adapta bien a las aplicaciones, pero no es una bala de plata.

Depende del proyecto. Pero pase lo que pase, siempre usaré Sass. Me gusta que mi Sass sea modular para poder usarlos donde se necesiten, no solo en todas partes.

Si estoy creando una aplicación y escribiendo el servidor, podría usar Gulp con Node Sass. Mi plantilla HTML generalmente ha sido entre HandlebarsJS pero creo que me cambiaré a EJS (JavaScript incorporado). El editor de texto que uso es Atom, y mi navegador preferido es Chrome (con el almacenamiento en caché desactivado cuando las herramientas de desarrollo están abiertas).

Eso es.