Fatally, CSS in Javascript! 19.4.16
La opinión de un cuñado que tiene un blog sobre la idea y aproximación a "todo en javascript".
Fatally, CSS in Javascript!
Qué es CSS en Js
El concepto CSS in Javascript
no se refiere al clásico uso de Js para añadir alguna declaración CSS, cambiar algún valor o añadir o retirar clases a elementos del HTML. Por lo general tras algún tipo de evento.
Tampoco lo asocies al uso de herramientas para manejar CSS. Tipo procesadores. Ya sean "pre", "pro" o "post".
La expresión CSS in Js
se está empleando últimante para describir algo completamente diferente a lo anterior. Un fenómeno o tendencia que consiste en eso, en embutir todo lo relacionado con los estilos de una página (no lo llamo CSS) en Js perdiendo por el camino hasta la sintaxis, estructura y formas propias de CSS.
"CSS en Javascript" se refiere a la pretensión de escribir todo (estilos incluidos) dentro de y a la manera de Javascript.
Lo último en apuntarse ha sido lo que su autor llama CSSX. Bueno, si no es el último sí que es el que estos días está rulando por el artículo aparecido en smashingmagazine.com (púlpito amplificador como pocos otros altavoces web): Finally, CSS in JavaScript! Meet CSSX.
CSS in Js
no deja de ser un paso más del fenómeno más amplio que podríamos llamar All in Js
, donde en `all´ esta metido todo, también el HTML. Como el JSX de Facebook.
All in Js: mete todo el "back & front end" en Javascript.
Un futuro déjà vu
¿A nadie más que a mi esto no le recuerda un pasado no muy lejano en el que el All in PHP
reinaba? ¿Es este el futuro que pretende el All in Js
?
¿De qué ha servido todo el esfuerzo y trabajo invertido en la famosa separación de contenido, presentación y funcionalidad (marcado HTML, CSS y Js) incluido su almacenamiento (o archivos en los que se encuentran).?
¿Estaban equivocados y hemos de superar conceptos como marcado limpio y semántico, CSS mantenible y escalable, Js no "intrusivo"?
Y los pobres desarrolladores de navegadores ¿qué van a hacer con sus mejoras de motores especializados en manejar el Html, el CSS y el Js? ¿Para qué tanto esfuerzo?
Una opinión personal
Desde mi más que notoria y total ignorancia de amateur (cuñadismo en estado puro) creo que algo se nos está yendo de las manos (y mucho). Que no es que no piense y diga que este tipo de herramientas y enfoques no puedan ser útiles y efectivos en algún que otro desarrollo. Pero eso sí, minoritarios. Ya sean por su tamaño o complejidad.
Pero como práctica general no alcanzo a verle el beneficio de su uso. Me lo imagino como si alguien pretendiese que todos los contables del mundo mundial usasen todo lo que sea que usen los contables de Google o Microsoft para llevar las cuentas al día.
Fruto de esta sensación fue mi respuesta pueril y sin meditar de ayer en Twitter en forma de imagen. Es la que abre este post y con la misma que lo cierro. Que no deja de ser, repito, otra que cosas de un "cuñado" que tiene un blog ;-)
Kseso
the obCSServer ᛯ Ramajero Argonauta, Enredique Amanuense de CSS.#impoCSSible inside
Dicen que, en español, EsCss es el mejor blog de CSS. Posíblemente exageren.
@Kseso EsCss Kseso
Una vez más, completamente de acuerdo contigo y, dicho sea de paso, con el comentario de ayer (en G+) de Furoya.
ResponderEliminarMe parece un despropósito, una manera de perder el control y un intento de hacer que las cosas funcionen sin conocimiento de cómo o porqué.
Expandiendo un poco la idea, me parece que es lo mismo que hacen los "framework" en casi cualquier disciplina.
Espero que este nuevo intento, fracase igual que el mencionado All in PHP.
😟😟
El concepto de framework no tiene nada que ver con esto.
ResponderEliminarDicho esto, esta idea me parece muy a contramano del camino que parece seguir CSS. Alguno quizá le encuentre utilidad pero dudo que se imponga cuando la tendencia es la opuesta. Me parece a mi, por lo poco que entendí, que esta persona piensa que meter todo el css en js es como extender el comportamiento de los web components a css, creo que esta razonando afuera del tarro como quien dice.
Muy descriptiva la imagen :)
Saludos.
Hola todos.
ResponderEliminarYa vi tu +1, HenryGR, por él supuse que estabas de acuerdo con mi planteo y te agradezco. Para quien no sepa de qué hablamos, el enlace a la entrada de Kseso es
https://plus.google.com/u/0/107861690109455510615/posts/RATDcBbhrFZ
Pensaba seguir un poco más ahí con algunos ajustes de ideas, especialmente porque escribí de CSSinJS como si fuera un framework. Y es verdad, Lisandro, no lo es. Es bastante más profundo, lo que no quita que sea innecesario, porque se puede hacer perfectamente en un archivo .js común y corriente con su sintaxis estándar. De hecho, lo hacemos; porque hay casos en que es necesario, y realmente aparecen ante nosotros unos estilos que no están en el código, por lo general en elementos que tampoco están en el código. Y entonces vamos entendiendo cuál es la finalidad de crear CSS al vuelo.
No precisamente para reemplazar al CSS en el documento, sino para complementarlo en efectos más bien extremos, rayando el borde de lo que se podría sólo con lenguaje de estilos. Desde hace un año me están permitiendo mostrar ejemplos de esto en el blog EsCss, así que supongo no será necesario aburrirlos con otros casos aquí, en el presente comentario.
Pero ya que mencionaron a All in PHP, sí los voy a aburrir con otra historia muy vieja, que empezó con alguna discusión en un foro donde supuse que debatía con gente mejor preparada (y eso que no tiene mayor mérito saber más que yo, ¡pero en esos años todavía menos!).
En el cruce de chicanas mandé algo sobre documentos web sin etiquetas, donde uno solamente tipeaba contenido plano y en el editor/navegador se veía con formato. Cuando me quisieron explicar que "los procesadores de texto tipo Word o WordPerfect hacen documentos con marcas de formato que no se ven en la aplicación" ya no seguí porque iba a ser imposible explicarles el concepto de HTML/CSS in JS. Que ni se llamaba así, pero era eso mismo que tratan de imponer ahora, aunque se están quedando a mitad de camino.
El verdadero negocio es formatear un archivo de texto plano asociando un documento con instrucciones para insertar las etiquetas, estilos y escripts en algún lenguaje de programación (que en principio podría ser JS) y así en el navegador se vería como página web. El modo más simple es contar caracteres y guardar esas referencias de posición para editar al vuelo. Algo que en su momento fue nada más una idea, aunque el hecho de que los navegadores empezaran a incorporar consolas con inspector DOM, de CSS y JS con capacidad de edición local, hizo suponer que alguien realmente lo pensó a futuro.
Pero hoy sigue siendo un juego, un experimento. Documentos de este tipo usan demasiados recursos para algo —repito— tan innecesario.
No entiendo el planteamiento del autor de la mencionada librería, tampoco eso del negocio de formatear archivos de texto plano.
ResponderEliminarA ver, el cuñado de alguien se ha inventado un problema y lo ha resuelto en su tiempo libre en apenas un mes. El resultado te golpea en la cara. Creo que no entiende el concepto de los web components, ni la tendencia a desacoplar el código: lo que es visual para un lado, lo que es lógica para el otro, la información aparte y asi las demás cosas. Es solo una mala idea con poco futuro sin duda, nada mas descriptivo que la imagen de Kseso.
Pero lo de los documentos en verdad que no lo he entendido Furoya: hacer una pagina web no es mas que escribir un texto plano con algunas instrucciones como etiquetas, y/o estilos, y/o js. Que tántas instrucciones vayas a necesitar depende de la complejidad que requieras. Podría ser algo como los componentes web? Ahí tu pones una etiqueta mínima y el código hace 'la magia'. Claro que antes tenes que crear 'la magia' xD.
Para mi el verdadero negocio sería una librería que estandarice navegadores de forma eficiente, así uno codea lo que se supone debe codear y se va a dormir temprano.
Creo que el objetivo de una library semejante es poner en práctica una idea. No tiene que funcionar en la realidad, y muy probablemente no lo haga más que en algún grupo de experimentación. Porque justamente va en contra de las políticas generales de los desarrolladores. Sería mostrar otro camino, nada más.Si de verdad lo quieren imponer, es para ver si consiguen un párrafo en la Historia de la Web, o al menos que sus nombres aparezcan en medio de la lista de curiosidades al pie.
EliminarLo de hacer páginas en texto plano hay que verlo en su contexto. Hace mucho el principal objetivo de la red era crear una base de información a la que se pudiera acceder desde cualquier lugar con internet. La mayoría de la data estaba en texto plano, Y las página web no son texto plano, porque tienen intercaladas etiquetas. El código se considera "texto plano" porque solamente se crea con ASCII, pero el documento no se puede leer a simple vista como si lo hubiesen hecho en una máquina de escribir.
Y la idea de formatearlo sin modificarlo viene de ahí, porque en HTML se puede mejorar la estructura con negrita, cursiva, tamaño, resaltado, ...
Lo más interactivo era el hipervínculo que le da el nombre al lenguaje.
Hoy las páginas son multimedia y no sirven solamente para hacer circular información. Si alguien inventa un modo de formatear documentos de texto plano será para casos muy específicos. O porque se inventó un problema para resolver en su tiempo libre.
Amigo Furoya:
EliminarTu idea de texto plano + js para aplicar estilos tiene una aplicación más que interesante "ACCESIBILIDAD".
¿A que me refiero?
Simplemente un lector de texto o a un TTY (lo que en la prehistoria llamábamos teletipo) podría leer la página como documento, y los afortunados verla a todo color con virguerías incuídas.
Saludos.
¡Pero sí, Manuel Rosendo Castro Iglesias! Justamente la accesibilidad y compatibili ... zación de documentos fue lo que inició esta idea. Que en realidad no fue mía, pero yo la defendí dentro de sus límites. Y dentro de los límites de quien me leyera.
EliminarHoy hasta los procesadores de texto pueden hacer documentos usando XML, que es un etiquetado. Ya es más universal y parece extraño que exista un lector que no discrimine entre texto y etiqueta. Creo que un invento así sería práctico para un caso personaizado, un sistema que use texto plano de base y en algún momento haya que convertirlo a imprimible o navegable sin perder el original.
El editor sí sería complicado. Hay que usar WYSIWYG, y el resultado sería un archivo *.js (o similar) para combinar con el original. Los lectores llamarían a ese archivo de programación que es quién traería el de texto.
La verdad es que no sé si alguien no lo hizo ya. ¡Estamos debatiendo sobre ideas que tienen más de un lustro!
Un abrazo, mi amigo. Y gracias por el comentario.
Amigo Furoya.
EliminarLa idea tiene mucho más que un lustro.
Pero hoy se ha puesto de moda, ¡por fin!, el tema de la accesibilidad, que es algo que siempre he defendido.
Las ideas viejas no explotadas son aquellas que poco a poco con el tiempo, vuelven de vez en cuando a la vida.
Ya habrá alguien que se le ocurra como aplicarlas.
P.S.
Una pregunta ¿Hay forma con js o para distinguir si una letra es minúscula o mayúscula?
Bueno, la última consulta no tiene mucho que ver con el tema, pero la respuesta es: "masomenos".
EliminarLa verdad es que no recuerdo si en las actualizaciones agregaron esa funcionalidad a las expresiones regulares, pero en caracteres ASCII se puede hacer un (A-Z) y solamente va a reconocer o encontrar caracteres en mayúscula de la "A" a la "Z". Eso excluye las vocales acentuadas en mayúscula, tanto como las eñes o demás caracteres que no pertenezcan al alfabeto "básico". Por supuesto que si te tomás el trabajo de listar todas esas mayúsculas, se pueden agregar a la serie (A-Z). Después hay que comparar caracter por caracter, si tu interés está en las letras, o dejar que la RegEx la busque en toda la cadena si te interesa que aparezca al menos una.