Pourquoi les navigateurs ne prennent-ils pas en charge haml et sass?

Le temps nécessaire pour télécharger un site Web serait considérablement réduit, et l'analyse serait également plus facile, je pense.

Pourquoi ces langues ne sont-elles pas imposées comme standard? Évidemment, ils sont meilleurs que le HTML brut et le CSS ...

Les navigateurs sont la seule chose qui nous empêche d'éliminer le code HTML / CSS intermédiaire.

Une autre chose à considérer est que les organismes de normalisation ont une bande passante limitée - ils ne peuvent travailler que sur tant de choses à la fois.

Compte tenu de ces contraintes, je préférerais qu'ils travaillent sur la résolution de problèmes que les développeurs Web ne peuvent pas résoudre eux-mêmes (comme l'ajout de nouvelles balises ou d'animations CSS). SASS et haml sont faciles à compiler en CSS / HTML, donc l'avantage de la prise en charge native du navigateur serait limité, car il est si facile de le faire soi-même.

Le point le plus fort pour les langages de préprocesseur tels que Sass ou CoffeeScript est le fait qu'ils compilent vers leurs homologues "standard". C'est ce qui les convainc - vous bénéficiez de tous les avantages de leur conception "évidemment meilleure" sans ajouter à la myriade de problèmes de compatibilité que les développeurs Web doivent déjà traiter lorsqu'ils travaillent avec du CSS ou du JS standard. La rétrocompatibilité est une grande chose quand il s'agit de développement Web, toute personne qui doit encore penser à IE6 dans son travail sera d'accord.

Le package HTML / CSS / JavaScript a des bords rugueux et des choses qui peuvent sembler inadéquates aujourd'hui, mais il fournit un strict minimum - mais un strict minimum largement accepté, compris et mis en œuvre - sur lequel nous pouvons nous appuyer. Haml / Sass / CoffeeScript font précisément cela et c'est ce qui les rend utiles. Je préfère garder mon serveur Sass côté que de faire face à des développeurs de navigateurs s'engageant dans une guerre des normes Sass-Less-Stylus qui ne servirait à personne;)

«Techniquement meilleur» et «plus facile à utiliser» ne sont que deux des nombreux critères pour faire de quelque chose une norme. Il y en a beaucoup d'autres, comme:

• Compatibilité avec les normes existantes
• Implémentations existantes (normes de facto informelles)
• Effort requis pour mettre en œuvre
• Base d'utilisateurs existants (et donc, soutien communautaire, main-d'œuvre qualifiée disponible)
• Chaînes d'outils existantes
• Prise en charge de la plateforme
• Intégration avec les normes associées

Vous devrez accepter que HTML et CSS ont un avantage écrasant contre tout nouvel arrivant sur ces critères.

sasset nehaml sont pas des normes . HTML et CSS le sont .

Si et une fois que les deux deviennent des normes ( et sont largement acceptées et utilisées), il y aura une raison impérieuse pour les fabricants de navigateurs d'ajouter leur support.

Aucun projet de production ne peut utiliser Haml tant qu'il n'est pas pris en charge par Firefox, Chrome, Safari et Internet Explorer. Auparavant, les applications "d'entreprise" pouvaient être uniquement IE, mais je pense que l'époque est révolue. Les normes ne sont pas imposées d'en haut, elles sont acceptées par les fournisseurs de navigateurs.

Donc, vraiment pour avoir Haml fait une norme, vous devez obtenir l'accord d'Apple, Google, la Fondation Mozilla et Microsoft. Ce n'est pas anodin. Ces sociétés vont généralement se concentrer sur l'expansion des capacités plutôt que sur le nettoyage des fonctionnalités existantes.

Haml semble agréable à travailler, mais cela n'améliorera pas réellement les côtés de téléchargement car tous les navigateurs et serveurs modernes prennent en charge la compression. Les formats Haml et Html compressés sont probablement de la même taille. (De plus, la plupart du temps de téléchargement pour le site Web moyen consiste à télécharger des images et du code de script.)

Maintenant, gardez à l'esprit que peu de gens écrivent plus en Html. Les gens utilisent des frameworks qui crachent du HTML comme produit final. Non seulement cela nuirait directement à l'adoption de Haml, car aucun de ces cadres ne le prend en charge, mais il en élimine le besoin, car le langage de balisage sous-jacent n'est vu que par l'ordinateur.

Du point de vue du fournisseur de navigateur, ils peuvent légèrement améliorer une fonctionnalité existante (en prenant en charge quelque chose comme Haml, qui donne des pages plus propres) ou ils peuvent ajouter quelque chose de complètement nouveau, comme WebGL. Ce dernier a juste plus pour son argent.

Oui, ils ont l'air plus cool et plus faciles à utiliser que le HTML et le CSS. Mais le HTML et le CSS existent et sont construits depuis longtemps, de nombreuses applications sur le Web ou sur le bureau les utilisent.

Par conséquent, il n'est pas facile de créer quelque chose de standard. HAML et SASS sont vraiment amusants et plus propres à utiliser, mais étant standard, cela prendra du temps ou jamais. Depuis, w3c se soucie des développeurs, donc ils améliorent en effet html et css en html5 et css3.