¿Por qué los navegadores no admiten haml y sass?

El tiempo necesario para descargar un sitio web se reduciría significativamente, y el análisis también sería más fácil, creo.

¿Por qué no se imponen estos idiomas como estándar? Obviamente son mejores que html y CSS sin procesar ...

Los navegadores son lo único que nos mantiene alejados de eliminar el código HTML / CSS intermedio.

Otra cosa a tener en cuenta es que las organizaciones de estándares tienen un ancho de banda limitado: solo pueden trabajar en tanto a la vez.

Dadas estas restricciones, preferiría que trabajen para resolver problemas que los desarrolladores web no pueden resolver por sí mismos (como agregar nuevas etiquetas o animaciones CSS). SASS y haml son triviales para compilar en CSS / HTML, por lo que la ventaja del soporte nativo del navegador sería limitada, ya que es muy fácil hacerlo usted mismo.

El punto más fuerte para los lenguajes de preprocesador como Sass o CoffeeScript es el hecho de que compilan a sus contrapartes "estándar". Eso es lo que los atrae: obtienes todos los beneficios de su diseño "obviamente mejor" sin agregar a la miríada de problemas de compatibilidad que los desarrolladores web ya tienen que enfrentar cuando trabajan con CSS o JS estándar. La compatibilidad con versiones anteriores es una gran cosa cuando se trata de desarrollo web, cualquiera que todavía tenga en mente IE6 en su trabajo estará de acuerdo.

El paquete Html / CSS / JavaScript tiene bordes ásperos y cosas que pueden parecer inadecuadas hoy en día, pero proporciona un mínimo básico, pero un mínimo básico ampliamente aceptado, comprendido e implementado, sobre el que podemos construir. Haml / Sass / CoffeeScript hacen precisamente eso y eso es lo que los hace útiles. Prefiero mantener mi lado del servidor Sass que tratar con desarrolladores de navegadores que participan en una guerra de estándares Sass-Less-Stylus que no serviría a nadie;)

"Técnicamente mejor" y "más fácil de usar" son solo dos de los muchos criterios para hacer que algo sea un estándar. Hay muchos otros, como:

• Compatibilidad con los estándares existentes.
• Implementaciones existentes (estándares informales de facto)
• Esfuerzo requerido para implementar
• Base de usuarios existente (y, por lo tanto, apoyo de la comunidad, mano de obra calificada disponible)
• Cadenas de herramientas existentes
• Soporte de la plataforma
• Integración con estándares relacionados

Deberá aceptar que HTML y CSS tienen una ventaja abrumadora frente a cualquier recién llegado con estos criterios.

sassy hamlson no estándares . HTML y CSS son .

Si, y una vez, ambos se convierten en estándares ( y son ampliamente aceptados y utilizados), habrá una razón convincente para que los fabricantes de navegadores agreguen soporte para ellos.

Ningún proyecto de producción puede usar Haml hasta que sea compatible con Firefox, Chrome, Safari e Internet Explorer. Solía ​​ser que las aplicaciones "empresariales" podían ser solo IE, pero creo que los días han terminado. Los estándares no se imponen desde arriba, sino que los aceptan los proveedores de navegadores.

Entonces, para que Haml haya hecho un estándar, es necesario que Apple, Google, la Fundación Mozilla y Microsoft estén de acuerdo. Esto no es trivial. Estas compañías generalmente se concentrarán en expandir las capacidades en lugar de limpiar las características existentes.

Parece agradable trabajar con Haml, pero en realidad no mejorará los lados de descarga ya que todos los navegadores y servidores modernos admiten la compresión. Es probable que Haml y Html comprimido tengan aproximadamente el mismo tamaño. (Además, la mayor parte del tiempo de descarga para el sitio web promedio es descargar imágenes y código de script).

Ahora tenga en cuenta que pocas personas escriben en HTML más. Las personas usan marcos que escupen Html como producto final. Esto no solo perjudicaría la adopción de Haml directamente, ya que ninguno de estos marcos lo admitirá, sino que obvia la necesidad de hacerlo, porque el lenguaje de marcado subyacente solo es visto por la computadora.

Desde el punto de vista del proveedor del navegador, pueden mejorar ligeramente una función existente (al admitir algo como Haml, que proporciona páginas más limpias) o pueden agregar algo completamente nuevo, como WebGL. El último solo tiene más por el dinero.

Sí, se ven más geniales y fáciles de usar que html y CSS. Pero html y CSS existen y se crean desde hace mucho tiempo, muchas aplicaciones tanto en la web como en el escritorio las usan.

Por lo tanto, no es fácil hacer algo estándar. HAML y SASS son realmente divertidos y limpios de usar, pero siendo estándar, tomarán mucho tiempo o nunca. Desde entonces, w3c se preocupa por los desarrolladores, por lo que hacen que html y css sean mejores en html5 y css3.