qué - ¿No entran en conflicto las opciones de atributos de datos utilizados en Bootstrap, Angular.js y Ember.js con los principios discretos de Javascript?
que es una directiva en angular 5 (2)
Javascript discreto es una buena práctica para muchos lugares en la web. Los frameworks que mencionas se usan a menudo para crear aplicaciones de JavaScript completas. En muchas de estas aplicaciones, la experiencia sin Javascript suele ser una página en blanco. En ese entorno, el valor de separar su marcado de Javascript es relativamente bajo.
Siempre me han dicho que es una buena práctica (ala ''javascript no intrusivo'') separar JavaScript del marcado HTML. Sin embargo, he estado viendo la tendencia opuesta con varios frameworks nuevos y populares como Bootstrap, Angular.js y Ember.js. ¿Puede alguien decirme por qué esto no se considera una mala práctica?
Me estoy haciendo la misma pregunta y he llegado a la siguiente conclusión:
HTML es el lenguaje de marcado para presentar documentos. La semántica a la que todo el mundo se refiere está en realidad relacionada con la representación de documentos enriquecidos. Esto incluye imágenes y enlaces que permiten una experiencia más rica. Los mismos principios se pueden aplicar a los documentos de Word, donde en lugar de marcar un texto específico como rojo, puede marcarlo como énfasis y luego marcar el énfasis como rojo, que será la forma semánticamente correcta de expresar la intención.
El problema surge porque HTML en realidad incluye elementos que permiten la interacción del usuario - formas. El diseño inicial fue para permitir que no profesionales creen interfaces de usuario interactivas simples. Cuando revisé diferentes frameworks de GUI de escritorio no existe la separación entre la vista real y la lógica de vista, porque cuando construyes la GUI no necesitas esa separación.
Para mí, la importancia es cuánto de lo que estás escribiendo está basado en contenido o GUI. Debido a que el HTML tiene dos propósitos, es difícil saber qué servir desde el servidor. Básicamente sitios como Wikipedia, e incluso están orientados al contenido. Esto significa que si quieren ser accesibles a un rango más amplio de clientes, como bots y navegadores más antiguos, deberían poder transmitir html puros. Estoy pensando en dos posibles estrategias cuando desee proporcionar contenido y una experiencia de interfaz de usuario más rica, como el texto donde estoy escribiendo este comentario. El primero es server el html y luego inicializar la GUI. Esto también se conoce como JavaScript no intrusivo y HTML semántico. Esto es lo que hacen la mayoría de los sitios orientados al contenido. Esto es principalmente para poder beneficiarse de los navegadores y bots que permitirán que su contenido sea más accesible. La otra estrategia será identificar el tipo de cliente y servir contenido diferente, que solo se puede lograr de manera confiable solo por parte del cliente, porque en ambos casos se servirá html. Esto todavía está cerca de la primera estrategia, debido a la forma en que se usa / abusa HTML como contenido y representación de la GUI.
Si está escribiendo una aplicación que no proporciona contenido sino un servicio / proceso real, la arquitectura como AngularJS y similares es más adecuada.
En mi experiencia, la mayoría de los negocios tienen que proporcionar ambos. Supongamos que tiene una aplicación que utiliza HTML / Javascript para permitir a los usuarios crear dibujos. Esta aplicación no necesita seguir ninguna guía discreta, pero tampoco se podrá ejecutar en navegadores antiguos. Pero si proporciona un intercambio social de los sorteos entre los usuarios, permitiendo comentarios y otro contenido, entonces es mejor escribir esta parte del sitio de manera que los bots y otros clientes puedan acceder al contenido fácilmente.