Комментарии 74
Очень вовремя Ваша статья :) Я как раз решил посмотреть в сторону jade. Все очень доходчиво и понятно. Большое спасибо за статью!
Самое неприятное в Jade это писать конструкции такого плана:
Возникает проблема с пробелами между тегами. Тут или html'ными тегами писать внутри p (что странно в контексте использования jade) или вставлять явные
<p>Text <a href="#">link</a> <b>bold text</b></p>Возникает проблема с пробелами между тегами. Тут или html'ными тегами писать внутри p (что странно в контексте использования jade) или вставлять явные
. Есть ещё варианты?
Чем официальная дока не зашла?
Использую в ряде своих проэктов на Django и хочу сказать, что на обычном HTML после него вообще не хочется писать.
Хоть он и делался для ноды, но библиотека
Например:
Причем можно даже наследовать из .jade-файлов обычные джанговские .html и наоборот.
Изьянов еще не заметил ни одного. В крайнем случае иногда можно использовать инлайн-код джанговского шаблонизатора. Продумано гениально.
Хоть он и делался для ноды, но библиотека
pyjade отлично со всем справляется.Например:
- load static
!!! 5
html
head
title
block title
body
block menu
for link in links
a(href="{{ link.url }}", class="{% if link.current %}current{% endif %}")
= link.title|truncatechars:"50"
block content
h1 Hello world!
| {% some specific Django template tag. %}Причем можно даже наследовать из .jade-файлов обычные джанговские .html и наоборот.
Изьянов еще не заметил ни одного. В крайнем случае иногда можно использовать инлайн-код джанговского шаблонизатора. Продумано гениально.
Линк: https://github.com/SyrusAkbary/pyjade
Установка классическая — pip install pyjade, добавить в INSTALLED_APPS и добавить в в TEMPLATES[...].OPTIONS['loaders'].
Установка классическая — pip install pyjade, добавить в INSTALLED_APPS и добавить в в TEMPLATES[...].OPTIONS['loaders'].
Нельзя использовать js в шаблоне — это убивает всю малину
Проблема появилась, когда я начал использовать сторонние батарейки, где во views были прописаны только .html файлы на рендер, и у меня постоянно вылетало Cannot Render a Template. Так же когда пытался использовать built-in views от джанго.
del
Препроцессоры это хорошо конечно, особенно, когда добавляются как дополнительная прослойка над джанговским шаблонизатором, как справедливо заметили выше… Но не проще ли ограничиться использованием чего-то вроде Emmet'а и не добавлять еще одну точку отказа/тормозов?
Emmet очень хорош, когда нужно написать разметку. Помимо этого разметку еще будут читать и править (в стандартном случае). Но шаблонизаторы кроме "чистоты", требуют знания собственного синтаксиса и транслятора в HTML, что можно отнести к минусам.
Emmet хоть и прост и даже схож с jade, но всё равно требуется "выучить" его, приспособится к нему, особенно к конструкциям вида ul>li.item$*3 или (.foo>h1)+(.bar>h2)
К тому же он преобразует сокращения в HTML текст, что в итоге снова приводит к избыточности HTML, особенно когда придет время редактировать написанное
Но в целом всё это не очень важно, потому что шаблонизатор нужен в любом случае. Jade выступает не просто как препроцессор или упрощенный HTML редактор, а как шаблонизатор с лаконичным синтаксисом и удобными mixin'ами
Так как jade сделан для expressjs в режиме NODE_ENV=production, в котором все шаблоны единожды будут скомпилированы и изменить без перезагрузки их уже нельзя (в обычном режиме jade не очень быстр), то неясно есть ли в pyjade какие-то оптимизации для продакшена
К тому же он преобразует сокращения в HTML текст, что в итоге снова приводит к избыточности HTML, особенно когда придет время редактировать написанное
Но в целом всё это не очень важно, потому что шаблонизатор нужен в любом случае. Jade выступает не просто как препроцессор или упрощенный HTML редактор, а как шаблонизатор с лаконичным синтаксисом и удобными mixin'ами
Так как jade сделан для expressjs в режиме NODE_ENV=production, в котором все шаблоны единожды будут скомпилированы и изменить без перезагрузки их уже нельзя (в обычном режиме jade не очень быстр), то неясно есть ли в pyjade какие-то оптимизации для продакшена
До сих пор не понимаю почему на картинке HTML а не JADE?
Идя писать прозрачную разметку отличная, но сам Jade я вспоминаю как страшный сон.
PS: кстати Jade уже практически переименовали в Pug
PS: кстати Jade уже практически переименовали в Pug
Какие трудности были, что как страшный сон? Мне с практической точки зрения
- Были трудности c mixin и extends при переносе шаблонов из другого шаблонизатора
- Код для запуска в рантайме получался крайне неоптимизированным и медленным.
- Иногда на выходе код был просто невалидным.
- Последние годы проект вообще не развивался.
- При всей лаконичности синтаксиса &attributes просто вымораживало писать.
- Нельзя было экспандить переменные в комментариях.
- C доктайпом была какая-то беда, сейчас уже не вспомню.
- Ну и напоследок, из-за переноса проекта пропали все тикеты.
Согласен как минимум с 2, 5, 6
А какой в итоге шаблонизатор используете?
А какой в итоге шаблонизатор используете?
Дополнение к вышесказанному
Было бы неплохо в статью добавить причину переименования:
«Unfortunately, these people have a trademark for the word "jade" referring to software, so we've been forced to change our name. Fortunately, @davidglivar has kindly donated the name "pug" to us. I've claimed pug and pugjs everywhere I could think of so hopefully we shouldn't have any problems getting the name.»
«Unfortunately, these people have a trademark for the word "jade" referring to software, so we've been forced to change our name. Fortunately, @davidglivar has kindly donated the name "pug" to us. I've claimed pug and pugjs everywhere I could think of so hopefully we shouldn't have any problems getting the name.»
спасибо за статью, теперь можно будет давать на нее ссылку)
Второй вариант кажется более коротким и элегантным.
Элегантнее там выглядят стерильные примеры из документации. В реальной сложной верстке, на мой вкус, получается нечитаемый ад. Примерно как большие регулярные выражения. Даже помесь html+php и та понятнее выглядит.
Я пробовал Jade. И не один вечер, а минимум неделю просидел в попытках с ним подружиться. Ну есть, конечно, плюсы. Но минусы их надежно нейтрализуют. Есть много раздражающих мелочей, об которые регулярно спотыкаешься. И думаешь — черт, да мне проще и быстрее это сделать врукопашную, чем возиться с чудо-шаблонизатором!
С какими минусами вы столкнулись? Опять же интересуюсь с практической точки зрения
Из того что помню навскидку по прошествии времени (всё тот момент, может сейчас что-то пофиксили):
- Очень неудобный контроль над пробелами и переносами строк. Фактически, штатных средств для этого нет, есть только хаки-костыли. А часто бывает нужно, чтобы между тегами строго был пробел, чтобы они не слиплись. И бывает нужно наоборот, чтобы они стали строго вплотную.
- Громоздко и неудобно писать inline-тэги. Когда нужно вложить друг в друга несколько тэгов a/i/b — это удобнее сделать в нативном html.
- Переменные-структуры и массивы можно было писать только в одну строку. Это убивало на корню удобство от генерации однотипных блоков по массиву.
- Нельзя было оставить пустые строки для визуального разделения блоков, компилятор считал это ошибкой.
- Непредсказуемое поведение отступов при использовании миксинов.
- В целом не очень консистентный и шумный синтаксис.
- В jade по сравнению с html код имеет тенденцию к укорачиванию строк, но сильному (в разы) увеличению их количества. Листинги становятся длинными простынками. Миксины частично компенсируют, но лишь частично.
Тоже с этим сталкивался, в каком-нибудь шаблонизаторе есть хорошее решение для этого? Или просто какой вы в итоге используете?
3 пункт не понял, можете чуть подробнее развернуть?
3 пункт не понял, можете чуть подробнее развернуть?
Наверное автор комментария имел ввиду, что нельзя писать многострочный код в Jade, но здесь нужно учесть, что это шаблонизатор, а не язык программирования — стоит пробрасывать данные в шаблоны извне, а не создавать данные прямо в коде шаблона (применение инструмента не по назначению).
По (2) инлайновые теги я считаю наоборот удобными, вместо того чтобы менять название тега в двух местах — я меняю всего лишь в одном.
По (4) — проверил на версии Jade 1.0.2 — можно использовать пустые строки для разделения — главное соблюдать отступы. Или вы имели что то другое ввиду — покажите пример.
По (5) — тоже хочется увидеть пример.
По (7) — пользуйтесь инлайнами время от времени, будет вполне вменяемое количество строк.
Я видел, что автор активно сравнивает Jade с HTML, где по моим субъективным оценкам верстка в разы не удобней потому что необходимо контролировать закрывающие теги везде, внесение или вынесение, изменение вложенности кода занимающего несколько экранов превращается в поиск и подсчет закрывающих тегах. В некоторых IDE частично решена эта проблема, но опять таки: если разработчиков несколько, или вы работаете со старым не отформатированным HTML кодом — появляется проблема определения вложенности, существует огромный риск забыть закрыть тег. Для этого применяются дополнительные ресурсы в виде IDE и последующей проверке у W3C.
Если автор укажет на более продвинутый шаблонизатор — можно с радостью его попробовать и обсудить.
По (2) инлайновые теги я считаю наоборот удобными, вместо того чтобы менять название тега в двух местах — я меняю всего лишь в одном.
По (4) — проверил на версии Jade 1.0.2 — можно использовать пустые строки для разделения — главное соблюдать отступы. Или вы имели что то другое ввиду — покажите пример.
По (5) — тоже хочется увидеть пример.
По (7) — пользуйтесь инлайнами время от времени, будет вполне вменяемое количество строк.
Я видел, что автор активно сравнивает Jade с HTML, где по моим субъективным оценкам верстка в разы не удобней потому что необходимо контролировать закрывающие теги везде, внесение или вынесение, изменение вложенности кода занимающего несколько экранов превращается в поиск и подсчет закрывающих тегах. В некоторых IDE частично решена эта проблема, но опять таки: если разработчиков несколько, или вы работаете со старым не отформатированным HTML кодом — появляется проблема определения вложенности, существует огромный риск забыть закрыть тег. Для этого применяются дополнительные ресурсы в виде IDE и последующей проверке у W3C.
Если автор укажет на более продвинутый шаблонизатор — можно с радостью его попробовать и обсудить.
Ну массив надо писать строго в одну строчку, даже если в нем 1000 значений, нельзя написать каждый элемент в своей строке. Не знаю, может сейчас уже пофиксили. Но на тот момент это был популярный вопрос, висели issues на гитхабе, но не было понятно, есть ли этот фикс у авторов хотя бы в планах.
Радом пишут, что массивы надо передавать в шаблон, а не писать прямо там, а иначе мол не по назначению. Но сейчас модно использовать jade (и несколько его аналогов) именно для верстки, а не программирования — я имел в виду именно этот случай. На Codepen вон поддерживается и так далее. Если говорить о применении шаблонизатора именно для программирования MVC, то и в этом случае мне больше нравятся шаблонизаторы с синтаксисом другого стиля. Более классическим что ли. Типа dust.
А для верстки в итоге не использую никакой шаблонизатор, верстаю в нативном HTML. Slim очень похож на Jade плюс-минус, Haml какой-то вообще странный. Старый добрый HTML рулит. Да, немножко более громоздко, но гораздо читаемее, понятее и всё предельно четко контролируется. Проблему закрывания тегов считаю преувеличенной. Ну да, бывает изредка, что где-то забыл закрыть и ищешь почему поломалось. Но это бывает редко. Главное — контроль над материалом. Всегда всё можно сделать как нужно, не ломая голову над тем, как нужно извратиться и подкостылить, чтобы обойти особенность шаблонизатора.
Радом пишут, что массивы надо передавать в шаблон, а не писать прямо там, а иначе мол не по назначению. Но сейчас модно использовать jade (и несколько его аналогов) именно для верстки, а не программирования — я имел в виду именно этот случай. На Codepen вон поддерживается и так далее. Если говорить о применении шаблонизатора именно для программирования MVC, то и в этом случае мне больше нравятся шаблонизаторы с синтаксисом другого стиля. Более классическим что ли. Типа dust.
А для верстки в итоге не использую никакой шаблонизатор, верстаю в нативном HTML. Slim очень похож на Jade плюс-минус, Haml какой-то вообще странный. Старый добрый HTML рулит. Да, немножко более громоздко, но гораздо читаемее, понятее и всё предельно четко контролируется. Проблему закрывания тегов считаю преувеличенной. Ну да, бывает изредка, что где-то забыл закрыть и ищешь почему поломалось. Но это бывает редко. Главное — контроль над материалом. Всегда всё можно сделать как нужно, не ломая голову над тем, как нужно извратиться и подкостылить, чтобы обойти особенность шаблонизатора.
Скажем так, я очень ценю краткость Jade, и считаю что это плюс ради которого собственно его выбирают (побочные плюсы — легче проводить мерджи конфликтов, не страдает валидность).
Имхо, разница очевидна — лично мне второй вариант как наглядней, так и поддерживать проще (коррекция вложенности, наглядная иерархия классов).
Для верстки я использую достаточно простой gulp-скрипт, прикрутить к темплейту данные можно при помощи например gulp-data. Серьезно верстку при помощи codepen не воспринимаю.
Jade
.event-overview
.row
.columns.large-4
.event-overview-side...HTML
<div class="event-overview">
<div class="row">
<div class="columns large-4">
<div class="event-overview-side">
...
</div>
</div>
</div>
</div>Имхо, разница очевидна — лично мне второй вариант как наглядней, так и поддерживать проще (коррекция вложенности, наглядная иерархия классов).
Для верстки я использую достаточно простой gulp-скрипт, прикрутить к темплейту данные можно при помощи например gulp-data. Серьезно верстку при помощи codepen не воспринимаю.
Прошу прощения — ошибка, конечно же вариант с Jade наглядней. :)
Я не говорил, что нужно верстать в Codepen — это была просто иллюстрация того, что люди используют Jade не как шаблонизатор для программирования, а как что-то типа html-препроцессора.
По поводу примера — да, я уже писал выше, что Jade действительно подкупает своей лаконичностью и мимимишностью на простеньких примерах. Но на реальной сложной верстке она куда-то теряется. Зато вылазят проблемы с контролем материала, читаемостью и усиливается зависимость от рабочего окружения.
По поводу примера — да, я уже писал выше, что Jade действительно подкупает своей лаконичностью и мимимишностью на простеньких примерах. Но на реальной сложной верстке она куда-то теряется. Зато вылазят проблемы с контролем материала, читаемостью и усиливается зависимость от рабочего окружения.
Думаю, что переключиться из Jade и продолжить верстать в старом добром HTML на любом этапе никто запретить не может. А зависимость от окружения практически такая же, как допустим у SCSS.
Здесь главное потратить немного времени на настройку билд-окружения (и проброску рыбы в нужные места). Ну и конечно же научиться дробить весь шаблон на partials (компоненты), делать базовый layout, а контент страницы пробрасывать через блоки. Тогда простыни можно легко избежать. В заключении хотел бы попросить (если это возможно) ссылку на пример вашей верстки на Jade — очень интересно посмотреть на средний размер страницы.
Здесь главное потратить немного времени на настройку билд-окружения (и проброску рыбы в нужные места). Ну и конечно же научиться дробить весь шаблон на partials (компоненты), делать базовый layout, а контент страницы пробрасывать через блоки. Тогда простыни можно легко избежать. В заключении хотел бы попросить (если это возможно) ссылку на пример вашей верстки на Jade — очень интересно посмотреть на средний размер страницы.
Какова сфера применения?
Имею ввиду, для какого масштаба проектов (лэнд, визитка, проект с десятками уникальных страниц)?
Почему не эммет, который закрывает сам тэги и упрощает читаемость?
Имею ввиду, для какого масштаба проектов (лэнд, визитка, проект с десятками уникальных страниц)?
Почему не эммет, который закрывает сам тэги и упрощает читаемость?
Мне просто интересно, чем руководствовался минусующий? Я лишь задал интересующие меня вопросы…
Если я не ошибаюсь Jade писался с прицелом на использование в ExpressJs. Полагаю, что писать на Jade можно проекты любой сложности — главное чтобы вас и вашу команду все устраивало в плане синтаксиса.
Лично применяю Jade просто для ускорения верстки — очень нравится, что можно определить базовый шаблон, миксины для повторяющихся блоков.
Поправьте если я не верно понял — Emmet это плагин для IDE чтобы генерировать HTML на основании CSS селекторов?
Тогда сравнивать эти два инструмента некорректно. В случае с Jade, если ты делаешь на нем верстку с постоянно меняющимися требованиями — тебе достаточно изменить код в одной из миксин — чтобы код блока изменился по всему проекту. В случае с Emmet — это просто "ускорялка" помогающая писать кусочки кода, а не полноценный шаблонизатор.
Лично применяю Jade просто для ускорения верстки — очень нравится, что можно определить базовый шаблон, миксины для повторяющихся блоков.
Поправьте если я не верно понял — Emmet это плагин для IDE чтобы генерировать HTML на основании CSS селекторов?
Тогда сравнивать эти два инструмента некорректно. В случае с Jade, если ты делаешь на нем верстку с постоянно меняющимися требованиями — тебе достаточно изменить код в одной из миксин — чтобы код блока изменился по всему проекту. В случае с Emmet — это просто "ускорялка" помогающая писать кусочки кода, а не полноценный шаблонизатор.
Люблю indent-шаблонизаторы. Но, как правило, в них не удобно реализована работа с множеством аттрибутов. Передо мной очень часто встаёт ситуация, когда, у одного тега 3-5 аттрибутов. Некоторые из которых опциональны или же могут принимать несколько вариаций. Проблема в том, что это не очень красиво ложится на indent-шаблоны. Для себя лично решил проблему путём расширения синтаксиса. Получилось очень грубо, но наглядно:
Где ko-text распакуется в data-bind="visible: param.variable, click: $root.remove". Т.е. "велосипед" для удобного использования knockoutJS. А attr-class и attr-src будут прицеплены просто как &attributes.
Что мне не нравится в таком подходе: приходится мешать детей и аттрибуты на одном и том же уровне. Что нравится — без таких уродливых велосипедов код получается очень громоздким, трудным для чтения и написания. Пример привёл нарочисто простым, чтобы не запутать, а просто показать суть.
Ну и как правило сказали, ещё 1 проблема, ― это пробелы между тегами. Для себя лично решил её тем, что весь финальный HTML тег склеен тег к тегу. Читаемость нулевая, но и лишних проблем не возникает при inline-block вёрстке.
.some-el
attr-src= 'Что-то длинное и неформатное'
if obj.blabla
attr-class+ blabla
ko-visible: param.variable
ko-click: $root.remove
!= htmlГде ko-text распакуется в data-bind="visible: param.variable, click: $root.remove". Т.е. "велосипед" для удобного использования knockoutJS. А attr-class и attr-src будут прицеплены просто как &attributes.
Что мне не нравится в таком подходе: приходится мешать детей и аттрибуты на одном и том же уровне. Что нравится — без таких уродливых велосипедов код получается очень громоздким, трудным для чтения и написания. Пример привёл нарочисто простым, чтобы не запутать, а просто показать суть.
Ну и как правило сказали, ещё 1 проблема, ― это пробелы между тегами. Для себя лично решил её тем, что весь финальный HTML тег склеен тег к тегу. Читаемость нулевая, но и лишних проблем не возникает при inline-block вёрстке.
Думаю когда нибудь сделают такой модуль в Angular, было бы интересно на него взглянуть в больших проектах.
Прекрасный шаблонизатор, мы его заюзали в одном большом проекте и я очень даже счастлив по этой причине.
При перечислении атрибутов не обязательно ставить запятые, кстати. Такой вариант вполне приемлем в Jade(Pug):
img(src='/img/oceans-11.png' class='movie-poster' alt='123')
Подробнее об этом в ишью: https://github.com/pugjs/jade/issues/2229
При перечислении атрибутов не обязательно ставить запятые, кстати. Такой вариант вполне приемлем в Jade(Pug):
img(src='/img/oceans-11.png' class='movie-poster' alt='123')
Подробнее об этом в ишью: https://github.com/pugjs/jade/issues/2229
Не могли бы расписать преимущества, кроме сокращение количества тегов при написании.
Уточню, что не количество тегов, а количество символов. :)
Из минусов:
Лично делал несколько подходов к этому темплейтеру. И здесь мне кажется лучше без фанатизма — я определил ему область применения только для личных нужд, верстки для фриланс проектов.
- Проще производить мердж конфликтов в гите
- Проще менять иерархию вложенности; более наглядная структура страницы
- Это темплейтер: extends/block, include, mixins
- Генерирует валидный HTML, избавляет тебя от необходимости контролировать закрывающие теги
- Расширения
Из минусов:
- Без подсветки трудновато читаем, требуется время чтобы привыкнуть
- Неудобно работать с большим количеством атрибутов у тега
- Под вопросом работа с инлайновыми атрибутами — некоторым это не нравится
Лично делал несколько подходов к этому темплейтеру. И здесь мне кажется лучше без фанатизма — я определил ему область применения только для личных нужд, верстки для фриланс проектов.
Проще менять иерархию вложенности; более наглядная структура страницы
Не проще. В XML я делаю коллапc блока, затем переношу блок в нужное мне место. Все эти действия IDEA позволяет выполнить либо клавиатурой, либо мышкой. Дале ⌥+⌘+l помогает вернуть требуемое форматирование. С Jade с форматированием беда, все придется делать ручками и молиться как бы не нарушить структуру кода.
Проще производить мердж конфликтов в гите
Не проще, поскольку опять же упираемся в форматирование.
Это темплейтер: extends/block, include, mixins
И что? XML-темплейтеров нет что ли?
Инструкция include:
- Не следит за копипастом, сколько раз будет вызван include столько реальных вставок и будет (имеется ввиду прекомпиляция для запуска в рантайме)!
- Если например Jade используется поверх друго шаблонизатора, например Django, что не редкость, то можно огрести много проблем из-за желания сменить расширение с .jade на скажем .tpl!
Генерирует валидный HTML, избавляет тебя от необходимости контролировать закрывающие теги
У меня были случаи когда JS-код для запуска в рантайме был невалидным (не могу сейчас найти тикет, поскольку проект перенесли)
А что касается самом проблемы, то она более чем надумана — IDEA сразу сигналит о незакрытом теге. И даже при изменении названия достаточно менять только <ТУТ_МЕНЯЕМ_НАЗВАНИЕ_ТЕГА></ЗДЕСЬ_САМО_ИЗМЕНИТСЯ>.
Тоже самое касается атрибутов, которые IDEA любезно подскажет и пути к файлам зарезолвит.
Вы не подумайте, что я адепт XML-ля — отнюдь. После уймы потраченного времени на Jade, я переключился на HAML, но там оказалось все еще хуже.
Сейчас я смотрю на код Jade и лезу в справочник чтобы воскресить забытые знания, с XML такого не может случиться в принципе.
С Jade с форматированием беда, все придется делать ручками и молиться как бы не нарушить структуру кода.
А в чём беда? У меня в sublime-text с jade кодом и коллапсы есть, и tab, shift+tab работает тем же образом. Про нарушить структуру кода тоже не понял, гхм — как? Собственно и подсветка во многих редакторах в наличии.
В IDEA мне не нужно заботиться о форматировании XML-кода. Я на автомате жму ⇧⌘- + ⌥⇕ + ⌥⌘l чтобы "схлопнуть" и переместить нужный мне блок с сохранением форматирования. C Jade мне бы потребовалось после все отбить с помощью ⇥ или ⇥⇧.
Т.е. я не считаю указанные выше плюсы преимуществом.
Т.е. я не считаю указанные выше плюсы преимуществом.
Понятно. Суть в том что Jade код отформатирован по определению. Т.е. такой задачи не стоит в принципе. Не понимаю, почему вы это в минус записываете.
Мы видимо друг-друга не поняли...
Jade
HTML
Так вот, если понадобится перенести .baz на уровень .foo, то .baz придется выравнивать по .bar. Если вложенность будет глубокая, то это может создать трудности, поскольку закрывающего элемента нет и ориентироваться придется по коллапсингу (сворачивая последовательно блоки).
В XML этой проблемы не будет, можно даже и не форматировать код (⌥⌘l) — он просто будет работать.
Jade
.foo
.bar
.bazHTML
<div class="foo">
<div class="bar">
<div class="baz"></div>
</div>
</div>Так вот, если понадобится перенести .baz на уровень .foo, то .baz придется выравнивать по .bar. Если вложенность будет глубокая, то это может создать трудности, поскольку закрывающего элемента нет и ориентироваться придется по коллапсингу (сворачивая последовательно блоки).
В XML этой проблемы не будет, можно даже и не форматировать код (⌥⌘l) — он просто будет работать.
Если вложенность сильно большая — значит есть архитектурные проблемы — дробление на partials или вынесение в миксины решает эти проблемы.
Мы видимо друг-друга совсем не понимаем… вы работали с очень большими хайлоад проектами, которые весят по 600мб?
Все в миксины не вынести, хотя бы потому, что это значительно увеличивает объем результирующего кода. Переписать весь старый код тоже никто не позволит. Да и этот микроменеджмент никому не сдался — куча папок и файлов не решают основных проблем.
Например, у нас сейчас в проекте такая БЭМ-структура:
И даже с такой простой структурой каждая папочка создает массу накладных расходов.
Это только ОДИН блок, который еще не скомпелирован!
Все в миксины не вынести, хотя бы потому, что это значительно увеличивает объем результирующего кода. Переписать весь старый код тоже никто не позволит. Да и этот микроменеджмент никому не сдался — куча папок и файлов не решают основных проблем.
Например, у нас сейчас в проекте такая БЭМ-структура:
блок
__элемент
_модификаторИ даже с такой простой структурой каждая папочка создает массу накладных расходов.
Это только ОДИН блок, который еще не скомпелирован!
Для понимания:
Подсветка невалидных цветовых палитр:
Автокомплит цветовых палитр:
Вывод цвета прямо в атрибут:
Можно изменять название тега с закрывающего
Автокомплит по атрибутам:
По клику на элемент парная подсветка:
Резолвиг путей (автокомплит + валидация):
Где бы у меня не находился курсор абсолютно всегда понятна структура документа
C Jade, редакторы работают как с обычным текстовым файлом, а не как с полноценным проектом.
Подсветка невалидных цветовых палитр:
Автокомплит цветовых палитр:
Вывод цвета прямо в атрибут:
Можно изменять название тега с закрывающего
Автокомплит по атрибутам:
По клику на элемент парная подсветка:
Резолвиг путей (автокомплит + валидация):
Где бы у меня не находился курсор абсолютно всегда понятна структура документа
C Jade, редакторы работают как с обычным текстовым файлом, а не как с полноценным проектом.
Вы уперлись в то, что вам этот язык не подходит, потому что нет полноценной поддержки в IDE, но эмоционально называете его страшным сном. Но на самом деле это не является недостатком языка, а является недостатком IDE. Так же с BEM, если вам неудобно работать с Jade в контексте проекта — значит он вам не нужен, но это никак не говорит о том, что язык плохой и нужно отказываться от него.
Для меня Jade вполне ускоряет разоработку верстки на фриланс проектах. Автокомплит при верстке Jade-ом я не использую. В реальном проекте использую JSX и XML-подобное описание элементов, там и приходится часто юзать автокомплит. И никакого диссонанса от использования двух темплейтеров — не ощущаю.
Каждому инструменту свое применение.
Для меня Jade вполне ускоряет разоработку верстки на фриланс проектах. Автокомплит при верстке Jade-ом я не использую. В реальном проекте использую JSX и XML-подобное описание элементов, там и приходится часто юзать автокомплит. И никакого диссонанса от использования двух темплейтеров — не ощущаю.
Каждому инструменту свое применение.
Отсутствие полноценной поддержки в редакторах это один из минусов — весьма существенный, но не далеко не единственный.
Лично я и еще ряд моих коллег сделали однозначный вывод, что Jade непригоден для использования в серьезных проектах. Этому подтверждению есть разумные объяснения, которые я привел выше.
Проект долгое время не развивался, баги не фиксили. И я не слышал ни об одной серьезной компании где бы его использовали.
Мне тоже не нравится XML, но есть вещи, которые нужно выбирать проводя сравнительный анализ. В Jade только компактный синтаксис, на этом его преимущества заканчиваются.
Лично я и еще ряд моих коллег сделали однозначный вывод, что Jade непригоден для использования в серьезных проектах. Этому подтверждению есть разумные объяснения, которые я привел выше.
Проект долгое время не развивался, баги не фиксили. И я не слышал ни об одной серьезной компании где бы его использовали.
Мне тоже не нравится XML, но есть вещи, которые нужно выбирать проводя сравнительный анализ. В Jade только компактный синтаксис, на этом его преимущества заканчиваются.
Я не предлагаю использовать Jade в больших проектах.
Да, один из минусов с точки зрения большого проекта, но косвенно является минусом языка. Я же хотел обсудить реальные минусы самого языка, как например атрибуты или баги компилятора, или неудобства при работе с определенным количеством кода.
IDE очень хорошо научены XML, поэтому если мы хотим выбрать/обсудить альтернативный язык-шаблонизатор, то мне кажется неуместно считать недостатком плохую поддержку IDE. Здесь XML будет практически всегда выигрывать по этому параметру. Тогда смысл в обсуждении?
Отсутствие полноценной поддержки в редакторах это один из минусов — весьма существенный
Да, один из минусов с точки зрения большого проекта, но косвенно является минусом языка. Я же хотел обсудить реальные минусы самого языка, как например атрибуты или баги компилятора, или неудобства при работе с определенным количеством кода.
IDE очень хорошо научены XML, поэтому если мы хотим выбрать/обсудить альтернативный язык-шаблонизатор, то мне кажется неуместно считать недостатком плохую поддержку IDE. Здесь XML будет практически всегда выигрывать по этому параметру. Тогда смысл в обсуждении?
Если позволите, то я бы хотел добавить, что такие препроцессоры как SASS, Less и Stylus весьма активно используются в больших корпорациях. А все потому, что они реально решают конкретные проблемы. Jade не решает ни одну из проблем!
Вместо этого он их создает:
Это чисто недостатки по каким-то отрывочным воспоминаниям, но даже их достаточно чтобы не использовать этот шаблонизатор.
Вместо этого он их создает:
- Отсутствие полноценной интеграции с редакторами
- Требуется обучение сотрудников
- Крайне неэффективный результирующий код для динамической шаблонизации.
- Сложно интегрируется с другими шаблонизаторами
— В том же Django использование pyJade несет огромные накладные расходы на компиляцию в рантайме, а прекомпиляция Jade под Djando тот еще гемморой.
— Также, во многих шаблонизаторах принято давать расширение шаблонам типа *.tpl (если рассматривать Jade как подсистему). На сколько я помню, в Jade шаблоны которые экстендятся должны быть без расширения или иметь расширение *.jade. Возможно эту проблему уже решили, но она была точно.
— Попытка прикрутить Jade к React вместо JSX выглядит как какой-то оксюморон - Лишние накладные расходы (в серьезных проектах стараются максимально сократить количество зависимостей в CI)
- Из-за слабой поддержки редакторами повышается вероятность возможных ошибок (с идентацией это более чем правда).
- Сборка с помощью grunt-contrib-jade невозможна (позавчера закрыли таск, который был поставлен 2 года назад, и то не факт, что починили!).
- grunt-contrib-jade делает экспорт только в AMD. Попытки сделать кастомный экспорт не находят поддержки.
Это чисто недостатки по каким-то отрывочным воспоминаниям, но даже их достаточно чтобы не использовать этот шаблонизатор.
(1), (2) — по этим параметрам можно завернуть любой мало-мальски свежий язык.
(3) — пожалуйста, разъясните, имеется ввиду скомпилированный в JS код? В чем заключается неэффективность?
(4) — сложно судить о применении с Django (скорей всего потому что родная среда для Djade все таки JS). Про расширения согласен — это очевидный косяк компилятора. Прикручивание к реакту — это уже несколько экзотика пошла… :)
(5) — конечно можно работать без шаблонизатора, это минус шаблонизатора?
(6) — все таки если работать без редактора — то Jade все таки помогает снизить вероятность получить невалидный HTML с точки зрения закрывающих тегов. Вложенность — это значимая единица языка, как в python. Те кто пишут на питоне вменяют этому параметру минус?
(7), (8) — не знаю, но вроде бы правда — можно списать на молодость самого языка.
По всем этим параметрам да, использовать в крупных проектах — вопрос. Но разве плохо использовать этот язык для проектов, где разработчик один? Этот язык настолько плох, что не решает совершенно ни одной задачи?
Я думаю, что язык молод и у него еще все впереди. Как альтернатива Haml. Ведь есть поклонники у языков где отступы значимы, я думаю вполне логично использовать и на стороне шаблонов что то со значимыми отступами и упрощенной разметкой. Так что какое ни какое будущее у языка есть.
(3) — пожалуйста, разъясните, имеется ввиду скомпилированный в JS код? В чем заключается неэффективность?
(4) — сложно судить о применении с Django (скорей всего потому что родная среда для Djade все таки JS). Про расширения согласен — это очевидный косяк компилятора. Прикручивание к реакту — это уже несколько экзотика пошла… :)
(5) — конечно можно работать без шаблонизатора, это минус шаблонизатора?
(6) — все таки если работать без редактора — то Jade все таки помогает снизить вероятность получить невалидный HTML с точки зрения закрывающих тегов. Вложенность — это значимая единица языка, как в python. Те кто пишут на питоне вменяют этому параметру минус?
(7), (8) — не знаю, но вроде бы правда — можно списать на молодость самого языка.
По всем этим параметрам да, использовать в крупных проектах — вопрос. Но разве плохо использовать этот язык для проектов, где разработчик один? Этот язык настолько плох, что не решает совершенно ни одной задачи?
Я думаю, что язык молод и у него еще все впереди. Как альтернатива Haml. Ведь есть поклонники у языков где отступы значимы, я думаю вполне логично использовать и на стороне шаблонов что то со значимыми отступами и упрощенной разметкой. Так что какое ни какое будущее у языка есть.
(1), (2) — по этим параметрам можно завернуть любой мало-мальски свежий язык.
Jade не такой уж и новый язык. Те же JetBrains практически всегда прислушиваются к сообществу в плане поддержки той или иной возможности. Примером этому служат Stylus и Sass. C Jade, увы, это не произошло.
(3) — пожалуйста, разъясните, имеется ввиду скомпилированный в JS код? В чем заключается неэффективность?
Код, который заранее компилуется в JS для исполнения в рантайме. Я с Jade давно расстался поэтому пример уже не приведу.
(5) — конечно можно работать без шаблонизатора, это минус шаблонизатора?
Если вы имеете ввиду что-то вроде React JSX, то да, это отличный пример!
(6) — все таки если работать без редактора — то Jade все таки помогает снизить вероятность получить невалидный HTML с точки зрения закрывающих тегов.
К сожалению, интеграционные тесты довольно часто отстают от релиза. Это дает потенциальную возможность внести баг при неправильном разрешении конфликтов (в больших проектах релиз-инженер может собирать релиз до 3-х недель и допустить ошибку в запарке вполне реально. Если конфликты разрешает сам разработчик, то это тоже не исключает ошибок — проходили и ни раз).
Вложенность — это значимая единица языка, как в python. Те кто пишут на питоне вменяют этому параметру минус?
Я уже отвечал на этот вопрос. Поскольку я сам пишу на Python, то подобных проблем с редакторами нет, да и сам программный код значительно читабельней нежели разметка.
Но разве плохо использовать этот язык для проектов, где разработчик один? Этот язык настолько плох, что не решает совершенно ни одной задачи?
Любое решение, должно решать какую-то проблему. А Jade по своей сути ничего не дает кроме накладных расходов.
Из опыта могу сказать, что следует использовать то решение, которое позволит запустить проект без создания новой системы. Здесь я имею ввиду, что если вы привыкли использовать Jade для создания промо-страниц, и вам дали заказ на "завод", то вы потратите огромное количество времени на получение опыта в поисках правильного решения.
Иными словам, перед тем как выбрать тот или иной продукт нужно составить таблицу с требованиями, противоречиями и критериями проверки выполнения условий. Если Jade удовлетворяет всем вашим критериям, то проблем нет…
Я ведь тоже когда-то повелся на лаконичный синтаксис Jade и HAML))
Дело в том, что лично я применяю Jade: 1) не в масштабах производства или конвейера 2) Jade у меня НЕ используется как что то постоянно генерящее HTML на сервере. Более того — конечному заказчику я просто вручаю сгенеренный один раз HTML. :)
А тот плюс — лаконичность здесь использую можно сказать "по-полной" и в моей ситуации Jade все таки оказывается полезным.
У нас просто различные требования к этому языку-шаблонизатору — вот и все.
А по поводу реальных проектов — полностью согласен — необходимо прорабатывать все требования к используемым технологиям.
А тот плюс — лаконичность здесь использую можно сказать "по-полной" и в моей ситуации Jade все таки оказывается полезным.
У нас просто различные требования к этому языку-шаблонизатору — вот и все.
А по поводу реальных проектов — полностью согласен — необходимо прорабатывать все требования к используемым технологиям.
WebStorm Вам в помощь и будет полноценная поддержка Jade, работая с XML&XSLT по старой памяти сижу в Eclipse, все что с веб(Jade и SCSS), то это WebStorm и очень доволен.
Теперь понял, про что вы. tab, shift+tab, alt+shift+arrows и все подобные задачи решаются за секунду две. Причём из-за indent ещё и очень наглядно. Вот в случае HTML мне бы пришлось помучаться, т.к. закрывающие теги могут располагаться сильно далеко от открывающих. К тому же авто-форматирование может привести код не к тому виду, который хотелось бы, особенно в случае больших тегов (много-много аттрибутов).
Вот в случае HTML мне бы пришлось помучаться, т.к. закрывающие теги могут располагаться сильно далеко от открывающих.
Это как раз не проблема, IDEA показывает текущую позицию курсора (относительно документа, родителя и текущего элемента — зависит от позиции курсора и выбора элемента):
Потеряться с такими подсказками невозможно, а с Jade проще-простого. Если у элемента много модификаторов и прочих атрибутов, которые выставляются по различным условиям, то разметка Jade превращается в "мясо". Ориентироваться в таком коде без подсказок со стороны редактора крайне сложно.
В XML-e все элементарно — открыл элемент и добавляешь нужные атрибуты по различным условиям, в Jade это реально будет нечитаемые и неподдерживаемый код!
К тому же авто-форматирование может привести код не к тому виду, который хотелось бы, особенно в случае больших тегов (много-много аттрибутов).
Не знаю о каких проблемах вы говорите, потому что автоформатирование настраивается и как жить без него вообще не представляю.
PS: У нас получается какой-то спор ради спора, только вот я реально понимаю на собственном опыте, что Jade непригоден для серьезных проектов — вообще не пригоден. Это сложно понять если вы делаете промо-странички, в которых нет тем, модификаторов, массы атрибутов, которые выставляются по условиями и пр.
Вы предлагаете разбивать код на мелкие фракции тем самым внося путаницу в существующую архитектуру. И более такого, это еще и увеличит объем результирующего кода, поскольку каждый миксин к этому обязывает. Конечно же есть какие-то общие блоки, которые могут выставлять базовые атрибуты, но просто так код никто не станет дробить на мелкие кусочки чтобы решить проблему шаблонизатора…
Писать код с Jade быстрей вы не станете ибо есть Emmet. Наглядности он тоже никакой не даст если коде конечно не теги с одним атрибутом. Дальше, все — только ограничения.
Еще раз повторюсь — Jade не решает ни одной проблемы, а только создает.
Это как раз не проблема, IDEA показывает текущую позицию курсора (относительно документа, родителя и текущего элемента — зависит от позиции курсора и выбора элемента):
Честно говоря, мне нет дела до Idea :) А в sublime поддержка HTML оставляет желать лучшего. К тому же, в вашем же примере нужно и курсор установить туда, и чтобы финальный тег оказался в видимой части, а не где-то за скроллом ниже. Проблема такая в XML есть, IDE могут только смягчать её. Одно дело когда закрывающий тег есть, а другое когда его нет в принципе.
Если у элемента много модификаторов и прочих атрибутов, которые выставляются по различным условиям, то разметка Jade превращается в «мясо»
Работа с большим кол-вом аттрибутов ― недостаток Jade. Лично я для себя его решил. Выше об этом писал. А ещё не ясно, что вы имеете ввиду под "различные условия"? XSLT что-ли? Судя по коду это какой-то язык выросший из XSLT. Я года два использовал XSLT. С тех пор ненавижу и его самого и XML в частности. Это издевательство над живыми людьми, я считаю :) Как и БЭМ.
PS: У нас получается какой-то спор ради спора, только вот я реально понимаю на собственном опыте, что Jade непригоден для серьезных проектов — вообще не пригоден. Это сложно понять если вы делаете промо-странички, в которых нет тем, модификаторов, массы атрибутов, которые выставляются по условиями и пр.
Я работаю и над сложными и над простыми проектами. Просто я не столь категоричен. Использую Jade и свои велосипеды над ним уже лет 5. Весьма доволен результатом. Аттрибутов использую массу, логики в шаблонах (UI-ой) бывает очень много. Вы не "реально понимаете", вы "так думаете", но есть люди, которые "думают иначе". Давайте на этом и закончим. А то мне кажется скоро и до перехода на личности дойдёт :) Раз уже затронули промо-странички всякие. Кю.
А ещё просьба ― все эти здоровенные скриншоты лучше под спойлер. Так будет всем удобнее.
Не проще. В XML я делаю коллапc блока, затем переношу блок в нужное мне место. Все эти действия IDEA позволяет выполнить либо клавиатурой, либо мышкой. Дале ⌥+⌘+l помогает вернуть требуемое форматирование. С Jade с форматированием беда, все придется делать ручками и молиться как бы не нарушить структуру кода.
Сворачивание блока работает как в Sublime Text 2 (https://yadi.sk/i/4b1qU1n6py6Yo) так и в PhpStorm (https://yadi.sk/i/nGEFZo8apy6nL). Так же отлично работает Tab и Shift+Tab — увеличивает и уменьшает indent.
Не проще, поскольку опять же упираемся в форматирование.
Проще, потому что нам не нужно искать закрывающие теги. Так как язык основывается на вложенности — можно легче определить семантику вложенности. Код написанный другими людьми подчиняется правилам вложенности, следовательно у другого человека меньше шансов поменять другие строки, которые могут вызывать конфликты. Но да, с кодом нужно работать более аккуратным образом в плане отступов. Почему вы этому пункту вменяете недостаток — неясно.
И что? XML-темплейтеров нет что ли?
Просто некоторые думают, что это не темплейтер, а что-то для верстки. Но сам по себе extends/block и то что Jade это поддерживает в более менее неплохом состоянии — для меня плюс. Насчет include — добавляйте свою функцию include_your_template() и опишите там логику подключения. Хоть с изоляцией и передачей параметров. И это не так сложно. Кто мешает?
У меня были случаи когда JS-код для запуска в рантайме был невалидным (не могу сейчас найти тикет, поскольку проект перенесли)
Было бы лучше если бы вы завели тикет на этот баг в трекере Jade.
<ТУТ_МЕНЯЕМ_НАЗВАНИЕ_ТЕГА></ЗДЕСЬ_САМО_ИЗМЕНИТСЯ>.
Тоже самое касается атрибутов, которые IDEA любезно подскажет и пути к файлам зарезолвит.
Не у всех есть IDEA, а в некоторых случаях под рукой только примитивный блокнот без подсветки.
С XML такого не может случиться в принципе.
Так и не понял чего не может случиться.
Сворачивание блока работает как в Sublime Text 2
Ответил выше.
Проще, потому что нам не нужно искать закрывающие теги.
Зачем искать закрывающийся тег? Если это действительно нужно, то клик по тегу в большинстве редакторов решает проблему.
Но да, с кодом нужно работать более аккуратным образом в плане отступов. Почему вы этому пункту вменяете недостаток — неясно.
В программном коде я сторонник идентации, но в разметке код становится менее читабельным (на мой вгляд). Если в программном коде не вызывают вопросы лишние переводы строк, то в разметке они выглядят нелепо, а без них код с большой вложенностью напоминает "ёлочку".
Это лично мои ощущения и к недостаткам я идетацию как таковую не относил.
Так и не понял чего не может случиться.
Синтаксис Jade при отсутствии постоянной практики забывается на раз, XML забыть невозможно. И это очень важно, особенно когда проект большой и люди в нем регулярно меняются. Как минимум не требуется время на изучение особенностей синтаксиса.
Ребята, jade это тихий ужас, и понимание об этом приходит через недельки две. Тут было несколько комментариев по минусы, это реальные проблемы, с которыми сложно работать.
Одно удовольствие использовать jade в приложениях на angular. HTML как страшный сон после этого вспоминается.
Мне одному второй вариант из начала статьи кажется ужасным?
Лично мне Jade понравился. Зависимость вложенности от табуляции напоминает python, а так же позволяет более четко структурировать код верстки.
По поводу большого количества атрибутов у тега мне проблема не совсем понятна. В официальной доке в третьем сверху примере и внизу, в блоке "&attributes" все достаточно удобно и понятно расписано.
Так же по поводу вставки больших кусков JS кода в шаблон можно сделать следующим образом:
И интересно, что в статье (как в оригинале, так и можно было добавить от переводчика) не упомянуты Extends, которые позволяют разбить шаблон на "запчасти" и собирать из них то что необходимо для текущей страницы. А так же Filters, которые могут, например, вставлять в шаблон тексты отформатированные в markdown
По поводу большого количества атрибутов у тега мне проблема не совсем понятна. В официальной доке в третьем сверху примере и внизу, в блоке "&attributes" все достаточно удобно и понятно расписано.
Так же по поводу вставки больших кусков JS кода в шаблон можно сделать следующим образом:
script.
console.log('start log');
for (var i = 0; i < 10; i++) {
console.log('log in for - first row');
}
console.log('finish log');И интересно, что в статье (как в оригинале, так и можно было добавить от переводчика) не упомянуты Extends, которые позволяют разбить шаблон на "запчасти" и собирать из них то что необходимо для текущей страницы. А так же Filters, которые могут, например, вставлять в шаблон тексты отформатированные в markdown
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Туториал по Jade для начинающих