Чому браузери не підтримують haml та sass?


11

Час, необхідний для завантаження веб-сайту, було б значно скорочено, і аналіз також буде простішим, я думаю.

Чому ці мови не нав'язуються як стандарт? Очевидно, вони кращі, ніж сирі HTML та CSS ...

Веб-переглядачі - це єдине, що не дає нам усунути проміжний код HTML / CSS.


2
Причин дуже багато, але відстала сумісність - велика.
sevenseacat

вони могли виявити html на основі вчення та haml на основі іншого ключового слова ..
Alexa


Я не знайомий з Haml, але взагалі з іншими двигунами шаблонів, вам все одно потрібно буде проаналізувати шаблон на сервері, щоб вставити дані у виведений HTML. Зрозуміло, браузерам стає простіше це робити, але я думаю, що це не те, що скоро піде.
Джеремі Хайлер

Я думаю, що SCSS слід запускати в браузери. Можливо, вони чекають явного переможця, який з’явиться між Менше і SCSS ...
MSC

Відповіді:


15

Інша річ, яку слід врахувати, полягає в тому, що організації з стандартизації мають обмежену пропускну здатність - вони можуть працювати лише надто багато за один раз.

Враховуючи ці обмеження, я б скоріше працював над вирішенням проблем, які веб-розробники не можуть вирішити самостійно (наприклад, додавання нових тегів або CSS-анімацій). SASS та haml є тривіальними для компіляції до CSS / HTML, тому перевага підтримки рідного браузера буде обмежена, оскільки це так легко зробити самостійно.


9

Найсильніший момент для мов препроцесора, таких як Sass або CoffeeScript, - це те, що вони компілюють зі своїми "стандартними" аналогами. Ось що їх переконливо - ви отримуєте всі переваги їх "очевидно кращого" дизайну, не додаючи до безлічі питань сумісності, з якими веб-розробникам вже доводиться стикатися, працюючи зі стандартними CSS або JS. Зворотна сумісність - це велика річ, коли справа стосується веб-розробок, кожен, хто все ще має на увазі IE6 на своїй роботі, погодиться.

У пакеті Html / CSS / JavaScript є нерівні краї та речі, які сьогодні можуть відчувати себе неадекватними, але він дає голий мінімум - але голий мінімум, який широко прийнятий, зрозумілий та впроваджений - на якому ми можемо будувати. Haml / Sass / CoffeeScript роблять саме це, і саме це робить їх корисними. Я вважаю за краще тримати мою серверну частину Sass, ніж мати справу з розробниками браузерів, які беруть участь у війні стандартів Sass-Less-Stylus, яка нікому не послужить;)


5

"Технічно краще" та "простіше у використанні" - це лише два з багатьох критеріїв для того, щоб зробити щось стандартним. Є багато інших, таких як:

  • Сумісність із існуючими стандартами
  • Існуючі реалізації (неофіційні стандарти де-факто)
  • Зусилля, необхідні для здійснення
  • Існуюча база користувачів (а отже, підтримка громади, наявна кваліфікована робоча сила)
  • Існуючі ланцюги інструментів
  • Підтримка платформи
  • Інтеграція із відповідними стандартами

Вам доведеться погодитися, що HTML і CSS мають переважну перевагу перед будь-яким новачком за цими критеріями.


4

sassі неhaml є стандартами . HTML і CSS є .

Якщо і колись обидва стануть стандартами ( і вони широко приймаються та використовуються), то для розробників браузерів буде важлива причина, щоб вони підтримали їх.


1
Що робить щось стандартним? Кількість людей, які використовують цю річ. Якщо браузери додадуть підтримку haml і sass, кількість користувачів збільшиться, і з часом стандарт стане офіційним на w3c ..
Alexa

1
@Alexa - Або офіційний орган зі стандартів (або галузевий консорціум) складає стандарт.
Одід

2
@Alexa: Ні, якби це працювало таким чином, тег <blink> став би офіційним.
user16764

1
@ user16764, але я думаю, що Alexa має рацію. HTML5 - це лише компіляція матеріалів, які браузери вже робили. Вони просто викладають це приємними словами.
Артуро Торрес Санчес

3

Жоден виробничий проект не може використовувати Haml, поки його не підтримають Firefox, Chrome, Safari та Internet Explorer. Раніше це було, що "корпоративне" додаток могло бути лише IE, але я думаю, дні цього закінчилися. Стандарти не нав'язуються із-за високого рівня, вони погоджуються постачальниками браузерів.

Щоб справді Хамл склав стандарт, вам знадобиться змусити Apple, Google, Mozilla Foundation та Microsoft погодитись. Це не банально. Ці компанії, як правило, зосереджуються на розширенні можливостей, а не на очищенні існуючих функцій.

З Haml виглядає приємно працювати, але він фактично не покращить сторони завантаження, оскільки всі сучасні браузери та сервери підтримують стиснення. Стислі Haml і Html, ймовірно, будуть приблизно однакового розміру. (Плюс до цього, більшість часу на завантаження середнього веб-сайту припадає на завантаження зображень та код скрипту.)

Тепер майте на увазі, що мало хто вже пише в Html. Люди використовують рамки, які виплювають Html як кінцевий продукт. Це не тільки зашкодить прийняттю Haml безпосередньо, оскільки жодна з цих рамок не підтримає його, але й уникне необхідності в ньому, оскільки основну мову розмітки бачить лише комп'ютер.

З точки зору постачальника браузера, вони можуть дещо покращити існуючу функцію (підтримуючи щось на зразок Haml, який дає більш чисті сторінки), або вони можуть додати щось зовсім нове, наприклад, WebGL. В останньому просто більше накладу долара.


2

Так, вони виглядають крутіше і простішими у використанні, ніж html та CSS. Але html та CSS існують і створюються давно, багато багатьох додатків як в Інтернеті, так і на робочому столі їх використовують.

Тому зробити щось стандартне непросто. HAML і SASS - це дійсно весело і зручніше у використанні, але, будучи стандартними, це займе багато часу або ніколи. Оскільки w3c дбає про розробників, тому вони дійсно роблять html та css кращими в html5 та css3.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.