Dentro del análisis cuantitativo se optó por tomar diversas métricas tomadas a partir de los fragmentos de código en ambos ejemplos. Estas técnicas poseen la particularidad de ser mensurables y discretas.
5.1.3.1 Cantidad de líneas de código
Un aspecto importante a la hora de analizar el enfoque de CSS-in-JS planteado en este trabajo es la cantidad de líneas de código resultante de realizar la misma actividad tanto en
debe tener en cuenta además de las líneas de código totales también las líneas de código correspondientes a cada lenguaje de programación utilizado, en este caso se utiliza JavaScript y CSS.
Utilizando el nuevo enfoque se aumenta la cantidad de líneas JavaScript, pero se eliminan totalmente las líneas CSS (Figura 5.9 y Figura 5.10). Esto se da gracias a que con el enfoque de CSS-in-JS el estilo de cada componente se encuentra contenido dentro del mismo junto a su lógica y estructura. También como consecuencia directa se reduce (aunque no de forma significativa) las líneas de código totales.
Figura 5.9: Comparativa cantidad de líneas de código ejemplo 'Hello World'
5.1.3.2 Cantidad de archivos
La cantidad de archivos se ve reducida significativamente al eliminar las líneas de CSS, ya que no es necesario para el programador generar archivos de este tipo, quedando de esta forma sólo un archivo en el enfoque CSS-in-JS (Figura 5.11 y Figura 5.12) que contiene tanto el estilo, como estructura, y lógica del componente.
Esto impacta significativamente en la portabilidad de los componentes, ya que al utilizar el nuevo enfoque (Figura 5.4 y Figura 5.8) es necesario solamente mover el único archivo existente a un nuevo proyecto para que el componente sea integrado. Mientras que en el caso tradicional (Figura 5.2 y Figura 5.6) es necesario mover dos archivos. En el caso que existieran más componentes que comparten estilos dentro de un mismo archivo CSS se debería filtrar solo los estilos necesarios para el componente a extraer.
Figura 5.11: Comparativa cantidad de archivos ejemplo 'Hello World'
5.1.3.2 Dependencias a otros archivos
La dependencia a otros archivos significa si el archivo JS que contiene la estructura y la lógica del componente depende de algún otro archivo para su correcto renderizado, esto no incluye por ejemplo la dependencia al módulo React o a otro componente que esté contenido dentro del componente en cuestión.
El objetivo es detectar si depende de algún archivo extra para poder determinar de forma satisfactoria su estilo, lógica, y estructura. En este caso en el fragmento tradicional se encuentra una dependencia al archivo CSS que posee el estilo del mismo, mientras que en el fragmento basado en CSS-in-JS no existe dicha dependencia (Tabla 5.1). Esta característica es compartida en ambos ejemplos presentados ('Hello World' y página de acceso).
Fragmento tradicional Fragmento CSS-in-JS Dependencia a otros
archivos
Sí No
Tabla 5.1: Dependencia a otros archivos
5.1.3.3 Cantidad de referencias a otros archivos
Las referencias entre archivos se refiere al caso cuando un archivo depende de otro, cuántas veces se hace referencia a un elemento del archivo del cual se depende. A menor cantidad de referencias se aumenta la mantenibilidad del código, ya que al contar con un gran número de referencias si se realiza un cambio se debe propagar el mismo, y esta propagación puede resultar costosa en tiempo en sistemas de gran escala.
Al utilizar el enfoque tradicional se encuentran cinco referencias. Estas referencias son dadas por la asociación de los estilos en el archivo CSS a cada etiqueta de la estructura del componente en el archivo JavaScript. Mientras que el enfoque CSS-in-JS propuesto el número de referencias es reducido a cero (Figura 5.13 y Figura 5.14), permitiendo así que un componente sólo se vea afectado por cambios en el mismo archivo, sin importar el entorno, generando una autocontención del mismo en un solo archivo.
En ambos ejemplos podemos ver que en el enfoque tradicional se encuentran referencias directas entre archivos, lo cual implica mayor trabajo por parte del programador a la hora de propagar cambios en nombres de clases CSS por ejemplo. Otro problema es que los estilos asociados por nombre de clase no verifican la existencia de la clase asociada, y en el caso de no existir la clase asociada simplemente aplica el estilo por defecto propuesto por el navegador, por lo que un error al escribir una referencia a una clase CSS puede acarrear errores difíciles de detectar ya que el renderizado del componente no falla, simplemente no se le asocia el estilo deseado por parte del programador. También esto implica que a la hora de modificar un estilo de un componente se debe acceder al archivo donde la clase CSS es declarada y realizar allí los cambios.
Figura 5.13: Comparativa cantidad de referencias ejemplo 'Hello World'
Figura 5.14: Comparativa cantidad de referencias ejemplo 'Hello World'
5.2 Experimento 2
El segundo experimento se basa en una encuesta realizada a dos grupos de personas. El primero siendo 15 programadores sin especialidad en frontend , y el segundo siendo 83 expertos en el área que han utilizado la herramienta propuesta en este enfoque para el 4 desarrollo de aplicaciones específicas. Ambos grupos fueron evaluados bajo la misma encuesta, en la misma se toma en consideración:
● Preguntas generales:
○ Años de programación en cualquier lenguaje.
○ Años de programación en JavaScript utilizando React. ● Preguntas sobre CSS-in-JS:
○ Conocimiento de existencia de enfoques CSS-in-JS con ejemplo de los mismos.
○ Utilización de enfoques CSS-in-JS con ejemplo de los mismos. ● Preguntas sobre la herramienta propuesta:
○ Legibilidad de fragmento tradicional (Figura 5.2). ○ Legibilidad de fragmento CSS-in-JS (Figura 5.4). ○ Comparativa de legibilidad entre ambos fragmentos.
○ Comparativa de estructura de código entre ambos fragmentos.
○ Comparativa de portabilidad de componentes entre ambos fragmentos. ○ Comparativa de facilidad para modificar componentes entre ambos
fragmentos.