Dlaczego przeglądarki nie obsługują Haml i Sass?

Czas potrzebny do pobrania strony internetowej zostałby znacznie skrócony, a parsowanie byłoby również łatwiejsze.

Dlaczego te języki nie są narzucane jako standard? Oczywiście są lepsze niż surowy HTML i CSS ...

Przeglądarki są jedyną rzeczą, która powstrzymuje nas przed wyeliminowaniem pośredniego kodu HTML / CSS.

Inną rzeczą do rozważenia jest to, że organizacje zajmujące się standardami mają ograniczone pasmo - mogą nad tym pracować tylko tyle naraz.

Biorąc pod uwagę te ograniczenia, wolałbym, aby pracowali nad rozwiązywaniem problemów, których twórcy stron nie mogą rozwiązać samodzielnie (np. Dodając nowe tagi lub animacje CSS). SASS i haml są trywialne w kompilacji do CSS / HTML, więc zalety natywnej obsługi przeglądarki byłyby ograniczone, ponieważ tak łatwo jest to zrobić samodzielnie.

Najmocniejszą stroną języków preprocesorów, takich jak Sass lub CoffeeScript, jest fakt, że kompilują się one ze swoimi „standardowymi” odpowiednikami. Właśnie to jest w nich przekonujące - zyskujesz wszystkie zalety ich „wyraźnie lepszej” konstrukcji bez dodawania mnóstwa problemów z kompatybilnością, z którymi programiści muszą sobie poradzić podczas pracy ze standardowym CSS lub JS. Kompatybilność wsteczna jest bardzo ważna, jeśli chodzi o tworzenie stron internetowych, każdy, kto nadal musi mieć na uwadze IE6 w swojej pracy, zgodzi się.

Pakiet HTML / CSS / JavaScript ma ostre krawędzie i rzeczy, które mogą dziś wydawać się nieodpowiednie, ale zapewnia absolutne minimum - ale absolutne minimum, które jest powszechnie akceptowane, rozumiane i wdrażane - na którym możemy budować. Haml / Sass / CoffeeScript robią dokładnie to i to czyni je przydatnymi. Wolę trzymać Sassa po stronie serwera niż zajmować się twórcami przeglądarek biorących udział w wojnie w standardzie Sass-Less-Stylus, która nikomu nie służy;)

„Technicznie lepszy” i „łatwiejszy w użyciu” to tylko dwa z wielu kryteriów, które sprawiają, że coś jest standardem. Istnieje wiele innych, takich jak:

• Zgodność z istniejącymi standardami
• Istniejące wdrożenia (nieformalne faktyczne standardy)
• Wysiłek wymagany do wdrożenia
• Istniejąca baza użytkowników (a zatem wsparcie społeczności, dostępna wykwalifikowana siła robocza)
• Istniejące łańcuchy narzędzi
• Obsługa platformy
• Integracja z powiązanymi standardami

Będziesz musiał zgodzić się, że HTML i CSS mają ogromną przewagę nad każdym nowicjuszem w zakresie tych kryteriów.

sassi niehaml są standardami . HTML i CSS są .

Jeśli i kiedy oba staną się standardami ( i będą powszechnie akceptowane i używane), twórcy przeglądarek będą mieli ważny powód, aby dodać ich obsługę.

Żaden projekt produkcyjny nie może używać Haml, dopóki nie będzie obsługiwany przez Firefox, Chrome, Safari i Internet Explorer. Kiedyś aplikacje „korporacyjne” mogły być tylko IE, ale myślę, że minęły już czasy. Standardy nie są narzucane przez użytkowników, są one uzgadniane przez dostawców przeglądarki.

Tak naprawdę, aby Haml opracował standard, musisz zgodzić się na Apple, Google, Mozilla Foundation i Microsoft. To nie jest trywialne. Firmy te zazwyczaj będą koncentrować się na rozszerzaniu możliwości, a nie na czyszczeniu istniejących funkcji.

Haml wygląda miło z nim współpracować, ale tak naprawdę nie poprawi stron pobierania, ponieważ wszystkie nowoczesne przeglądarki i serwery obsługują kompresję. Skompresowany Haml i Html prawdopodobnie będą miały ten sam rozmiar. (Ponadto większość czasu pobierania dla przeciętnej witryny to pobieranie obrazów i kodu skryptu).

Pamiętaj, że niewiele osób pisze już w HTML. Ludzie używają frameworków, które wypluwają HTML jako produkt końcowy. Nie tylko zaszkodziłoby to adopcji Haml bezpośrednio, ponieważ żaden z tych frameworków nie będzie go obsługiwał, ale eliminuje potrzebę, ponieważ podstawowy język znaczników jest widziany tylko przez komputer.

Z punktu widzenia dostawcy przeglądarki mogą nieznacznie ulepszyć istniejącą funkcję (obsługując coś takiego jak Haml, co daje czystsze strony) lub mogą dodać coś zupełnie nowego, na przykład WebGL. Ten ostatni ma po prostu większy huk za grosze.

Tak, wyglądają fajniej i są łatwiejsze w użyciu niż HTML i CSS. Ale HTML i CSS istnieją i są budowane przez długi czas, wiele aplikacji zarówno w Internecie, jak i na komputerze z nich korzysta.

Dlatego nie jest łatwo zrobić coś standardowego. HAML i SASS są naprawdę przyjemne i czystsze w użyciu, ale będąc standardem, zajmie to dużo czasu lub nigdy. Ponieważ w3c troszczy się o programistów, więc rzeczywiście poprawiają HTML i CSS w HTML5 i CSS3.