Какие технологии использовать для быстрой верстки?

Question

[Иван Антонов]

Какие технологии могут упростить и ускорить верстку html страниц?
знаю только для css - SCSS.

Answer 1

[Евгений Лебедев]

Emmet - ускоряет формирование html.
SASS, LESS, Stylus - CSS препроцессоры (также есть постпроцессоры).
Gulp, Grunt, Webpack - помогают собирать проекты. По сути менеджеры задач по компиляции sass, less, coffee и т.д. и сборки этого всего в пару файлов.
Для ускорения верстки также порекомендовал бы использовать CSS фреймворки типа Bootstrap, Foundation. Но не злоупотреблять стилями по-умолчанию =)

Answer 2

[Назар Мокринский]

Веб-компоненты очень помогают - много кода можно потенциально наследовать и повторно использовать целиком либо по частям. Никаких шаблонизаторов не нужно - всё нативно, порублено на логические кусочки.

А то я вижу, комментаторы выше вам стандартные шаблонные ответы фигачат, вы такие за 30 секунд поиском нашли бы.

Comments

[teotlu]

Точно-точно, разработка в разы ускоряется. У меня, к примеру, есть стандартный набор веб-компонентов, который постоянно пополняется, и они очень легко переиспользуются. Особенно когда используешь методологию (БЭМ, MCSS, или что-то своё), очень легко подключать компонент в новый проект, остаётся только его стилизовать, и он уже работает.

[Назар Мокринский]

teotlu: А я уж начал переживать, никто больше не пользуется ими среди здесь присутствующих)

[teotlu]

Назар Мокринский: да пользуются все, просто все понимают разные вещи под этим. Да и я от проекта к проекту под словом "компонент" зачастую понимаю разные вещи. В данном случае я имел в виду готовую структуру кода, которую привык использовать, скажем, для форм. Определённые названия классов для всех инпутов и контролов, определённую переиспользуемую структуру вёрстки, плагин валидации, заранее настроенный на всё это. Ну, это в случае с формами. В случае с другими вещами — аналогично.

[Назар Мокринский]

teotlu: Да не понимают разные вещи, веб-компоненты это устоявшийся термин и значит вполне определённую вещь. Структура верстки и стилей не является веб-компонентом в общем понимании...

[teotlu]

Назар Мокринский: меня подвело плохое знание терминологии, видимо. Вы про стандарт веб-компонентов, разработанный гуглом?

[teotlu]

Назар Мокринский: почитал про них, подход чем-то напомнил ReactJS (не знаю чем, различия достаточно большие).

[Назар Мокринский]

teotlu: Да, именно их имел ввиду. Они не только гуглом разрабатываются, но в целом да, активно продвигают.

[teotlu]

Назар Мокринский: спасибо за наводку, при случае обязательно их попробую) Выглядит интересно. Правда, полно споров по поводу совмещения стилей, вёрстки и скриптов в одном месте. Но в обсуждениях Реакта споры точно такие же, а инструмент тем не менее крутой.

[Иван Антонов]

я думал этот что-то тривиальное и даже не стал обращать внимание, но почитав коментарии решил загуглить, и О БОЖЕ - Polymer, я раньше думал что же гугл предложит разработчикам, так они это сделали уже давно! Почитал, поэкспериментировал; в общем порадовал меня этот инструмент. Теперь нужно определиться: БЭМ или веб-компоненты использовать :)

[Moe Green]

teotlu "... У меня, к примеру, есть стандартный набор веб-компонентов, который постоянно пополняется, и они очень легко переиспользуются. ..." - для меня эта тема на данный момент актуальная. хочу и пробую собрать такой набор. Подскажите, как правильно его сделать, организовать? Может быть, есть готовые примеры (подозреваю - укажете в сторону Bootstrap и Foundation?) ?

[Moe Green]

teotlu мне думается сделать такие компоненты с минимальным набором стилей (стили только для придания функциональности компонентам). Готовые фреймворки - они (разработчики) туда понапихали своих стилей, которые мне нафиг не нужны. А так (html+функциональный css) - было бы весьма недурно, однако!

[Назар Мокринский]

Valery Semenencko: Вы не в ту ветку по ходу написали...

[Moe Green]

Назар Мокринский: может быть, хотя "целился" аккуратно вроде )) но это дело не слишком меняет, не правда ли? ))

[Moe Green]

Назар Мокринский: я хотел бы совета и подсказки по моему вопросу - для меня он актуален

[teotlu]

Valery Semenencko: мне готовые примеры не очень подходили, из-за большой переизбыточности кода и стилей в них, а так же из-за КРЕАТИВНОСТИ наших замечательных дизайнеров, которые либо не делают сетку вообще из каких-то своих соображений, либо делают какую-то хитрую свою. Т.е. всё равно пришлось бы много переделывать в стилях этих фреймворков.

Просто со временем у меня для большинства типовых элементов выработались некоторые паттерны, которые мне показались удобными, и которые я стал переносить из проекта в проект.

Проекты у нас достаточно небольшие в основном, поэтому тот же БЭМ был бы слишком громоздким, и пришлось придумать свою достаточно простую систему организации стилей, которая в связке с этими самыми html-паттернами и дала эти переиспользуемые кусочки.

А вот с переопределением уже созданных кем-то стилей зачастую морока та ещё, и своя методология тут не помогает: приходится либо использовать неправославный !important, либо через девтулс смотреть вес селекторов и как-то его перебивать своими. Либо уже лезть в их стили и убивать то, что мешает, но это во многих случаях опасно делать: есть вероятность использования этих стилей в каком-то совершенно другом месте, где всё возьмёт и полетит в таком случае.

[teotlu]

Иван Антонов: т.е. по сути вам нужно решить, принимаете вы сторону Яндекса или Гугла XD

[Иван Антонов]

teotlu: так оно и есть. но у каждой среды свои плюсы, и совмещать их кажется непосильной задачей.

[teotlu]

Иван Антонов: совмещать их на одном проекте достаточно глупо, на мой взгляд. БЭМ слишком самодостаточен (я про bem-tools и прочие приколы), чтобы дополнять его совершенно другой с идеологической точки зрения разработкой. А вот в зависимости от требований проекта использовать либо одно, либо другое — уже более оптимально. Но учить придётся и то и то тогда :)

Answer 3

[Homsa Toft]

для css ещё - less, stylus.. less наверное самый простой, плюс есть bootstrap-less.
для html шаблонизаторы - jade например.

системы сборки grunt, gulp, brunch.

ну и node.js что бы всё это крутить... а ну и кучу времени что бы всё это освоить настроить и понять что там лишнее..

Comments

[teotlu]

Чего там осваивать и настраивать, сейчас статей на хабре море по этой тематике. Вот, к примеру, самая популярная: habrahabr.ru/post/250569
Правда, в представленном в ней варианте сборщика есть недостатки:
— Не глотает ошибки, т.е. при любом неправильно написанном коде вылетает livereload и watch, что при прямых руках и наличии гугла правится мгновенно;
— Пересобирает даже не изменившиеся файлы, что легко решается с помощью gulp-cached;
— Не собирает спрайты (что тоже допиливается очень легко с помощью соответствующих пакетов).

А ещё можно воспользоваться yeoman.io , где очень много разных вариантов сборщиков под любые запросы.

[Homsa Toft]

Я читал эту статью... картинка смишная. Что-то в ней для меня лишнее, чего то не хватает. В еомэне нашёл в своё время только один подходящий для меня сборщик который и то, требовал нормального такого допила, хотя сейчас надобы ещё пробежаться..

Осваивать и настраивать всегда есть что.. хочу такуюже но с перламутровыми пуговицами .)

[Иван Антонов]

teotlu: спасибо за gulp-cached - взял на вооружение, ток можно ли его настроить для stylus?

[teotlu]

Иван Антонов: а какая разница? Он просто сравнивает исходный файл с закэшированным. Если поставить там флаг optimizeMemory, то сравнивать будет по контрольной сумме. Я его нарыл вот в этой статье, если что: ymatuhin.ru/front-end/see_into_gulp — там много ещё чего полезного. Но сам мой сборщик работает на основе статьи, которую я указал в первом комменте, и я его постепенно наращиваю всякими фишками.

Answer 4

[globuzer]

БЭМ

Answer 5

[Богдан Духевич]

Технологий уйма. Я вижу, что ребята выше написали вообще все, что только можно.

Но если говорить о скорости, то, в первую очередь, нужно все инструменты объединить в одном месте. Для этого лучше всего подходит Gulp.

1. SASS - компилируется на ~150% быстрее чем LESS (при условии компилирования с помощью libsass), имеет интуитивно понятный синтаксис (речь о функциях и операторах, а не о CSS-возможностях).
2. Gulp (указываю плагины, касающиеся именно повышения скорости разработки):
- gulp-sass;
- browser-sync - обновление стилей/изобр/скриптов без перезагрузки страницы (как статика, так и CMS)
- генератор спрайта (как png, так и svg), при статике так же еще возможно обновление html;
- оптимизация изображений (png, jpg, svg);
3. Редактор кода - Sublime Text. Стабильный, быстрый, легковесный:
- Emmet;
- сниппеты;
- Gulp плагин - для быстрого запуска тасков (самый удобный хоткей - CTRL + SHIFT + M - для запуска дефолтного таска, CTRL + ALT + M - для остановки всех тасков, CTRL + M - для вызова выпадающего списка с тасками);
4. Методологии - SMACSS, как по мне, одна из самых удачных, но еще лучше разработать свой собственный подход. Верстать все максимально модульно, это даст огромный прирост скорости как на поздних этапах разработки, так и в дальнейшем при поддержке проекта.

Ну и всегда думайте, как можно унифицировать тот или иной момент. В таком случае от проекта к проекту ваша скорость будет всегда расти, а значит времени на что-то новое будет все больше.

Comments

[Иван Антонов]

Речь идет о скорости разработки, а не о скорости компиляции.
Добавлю от себя:
SASS не лучшее решение, эти причины можно найти здесь
habrahabr.ru/company/yandex/blog/169415
редактору Sublime Text, я бы предпочел WebStorm, по-моему самое функциональное IDE для web.

[Богдан Духевич]

Ну я описал то, что применяю сам. Ведь ключевое слово в Вашем вопросе - скорость.
Компиляция - это составляющая процесса разработки, разве нет?

Ну а причины против SASS, описанные в статье, меня насмешили :)

[Иван Антонов]

Богдан Духевич: чем насмешили? так как с этим препроцессором лично не знаком, интересно ваше мнение

[Богдан Духевич]

Иван Антонов:

Правило хорошего тона в любом препроцессоре - не использовать больше двух вложенностей (не учитывая простые теги, речь больше о сущностях/модулях + их элементах). Так вот, следуя этому, нет необходимости в использовании тех изощренных родительских селекторов, описанных в статье (как этот - button&).

Злоупотреблять родительскими селекторами на мой взгляд вообще не стоит. Чем сложнее и запутаннее структура, в которой используется &, тем больше вероятность, что другой человек может потратить лишнее время на то, чтобы разобраться в этом.

Ну и четкое и легкочитаемое использование &, имхо, предпочтительнее, нежели то, что описывали ребята из Яндекса. Как фичи возможно этого в Сассе и не хватает, но если уж будет, то лучше как отдельная реализация, не затрагивающая &.

Ну и так как это единственный "аргумент" против сасса, потому и насмешило)

Хотя я не так хорошо знаком со стилусом, и, пожалуй, стоит ознакомиться со всеми его особенностями ;)

Answer 6

[Евгений Соловьёв]

jade + stylus + webpack + react