• Новые темы в этом разделе публикуются автоматически при добавлении файла в менеджер ресурсов.
    Ручное создание новых тем невозможно.
iDaBuilder — Сборка Gulp + PostCSS

iDaBuilder — Сборка Gulp + PostCSS 1.0.0

Нет прав для скачивания

L2Banners

Front-End Developer
VIP
Участник Новогоднего Фонда 2023
Победитель в номинации 2023
Победитель в номинации 2022
Победитель в номинации 2021
Победитель в номинации 2020
Победитель в номинации 2019
Сообщения
356
Розыгрыши
2
Репутация
305
Реакции
467
Баллы
1 483
L2Banners добавил(а) новый ресурс:

iDaBuilder — Сборка Gulp + PostCSS - Автоматизация процесса верстки

Посмотреть вложение 40658

Автоматизация рабочего процесса во время верстки это одна из самых важных необходимостей, которая помогает сэкономить время и уделить больше внимания деталям. В зависимости от задачи используют различные системы сборки, я же в основном использую Gulp. Каждый год я собираюсь духом, выделяю время и начинаю обновлять свою сборку внедряя фичи, которых мне не хватало, убираю лишнее или вообще пишу все заново. Поскольку я фрилансер и не ограничен какими-либо...

Узнать больше об этом ресурсе...
 

Спасибо, для создания статической верстки думаю удобно.
Можно поковырять как пример своих сборок.
Но на реальных проектах будет бесполезно.

Почему jquery лежат файлами в репозитории?
 
Спасибо, для создания статической верстки думаю удобно.
Что в твоем понимании статическая верстка?

Можно поковырять как пример своих сборок.
Но на реальных проектах будет бесполезно.
А как по твоему выглядят сборки в реальных проектах? Мне вот доводилось работать с разными сборками в разных компаниях и там довольно много спорных извращений. Эта сборка заточена под верстку и со своей задачей справляется отлично.

Почему jquery лежат файлами в репозитории?
Рабочий пример того как подключать библиотеки отдельными файлами, а не в один бандл.
HTML:
<!-- Libs  -->

<!-- jquery -->
<script src="./libs/jquery/jquery-3.4.1.min.js"></script>

<!-- Main app -->
<script src="./js/app.js?ver=0.0.1"></script>
 
А как по твоему выглядят сборки в реальных проектах? Мне вот доводилось работать с разными сборками в разных компаниях и там довольно много спорных извращений. Эта сборка заточена под верстку и со своей задачей справляется отлично.
Именно.
Тут заточено под верстку. к этому не каких вопросов и не было.
На выходе у тебя будет несколько страниц, со слайдерами, поп апами и т.п.
Но весь текст у тебя будет статичен, просто лежать в файлике.
Картинка будет такая, какую прописали в файле и положили рядом.

Маккет\шаблон с жсом и стилями я и назвал "статической версткой"

Он подходит чтобы показать заказчику, или сделать какой-то ленгдинг.
Да и для лендинга уже нужна формочка контакт аз)

"Статическую верстку" потом же натягивать на фреймворк \ цмс \ другой апликешен.
В нормальных фреймах необходимо использовать свои шаблоны, свой жс, свою генерацию.
Например на разных страницах разные библиотеки)
И поэтому для для проектов ( не для лендинга или сайта визитки где у тебя 2 статик страницы) прийдется все переделывать почти все.

Рабочий пример того как подключать библиотеки отдельными файлами, а не в один бандл.

Вопрос все тот же, почему файлы лежат в репозитории?)

почему не
"jquery": "^3.3.1",
 
Маккет\шаблон с жсом и стилями я и назвал "статической версткой"
Статическая верстка - это верстка с фиксированными размерами не реагирующая на размеры экрана
Но весь текст у тебя будет статичен, просто лежать в файлике.
Это ты имеешь ввиду статический/динамический контент, в целом это не проблема верстки.
Например на разных страницах разные библиотеки)
Так давно уже не делают, только в специфических проектах, а если говорить о фреймворках с SPA, то это вообще бессмысленно
"Статическую верстку" потом же натягивать на фреймворк \ цмс \ другой апликешен.
Любую верстку сначала надо сделать, потом натянуть на cms, если же хочется верстать прямо в cms или продолжить разработку в cms после адаптации верстки, то ничего не мешает прописать нужные пути, а вместо встроенного шаблонизатора в сборщике использовать шаблонизатор cms этот процесс не будет отличаться ничем от других сборок просто настрой как тебе надо, конфиг с путями лежит отдельно.
Да и для лендинга уже нужна формочка контакт аз)
Можно без проблем прикрепить php файл или любой другой, я это делаю постоянно
И поэтому для для проектов ( не для лендинга или сайта визитки где у тебя 2 статик страницы) прийдется все переделывать почти все.
Ничего не придется переделывать, главное изначально понимать чего ты хочешь и как этого добиться.

Вопрос все тот же, почему файлы лежат в репозитории?)

почему не
"jquery": "^3.3.1",
Потому что я так хочу. Начиная с версии 3.5.1 появились проблемы совместимости с другими либами поэтому я подтягиваю ту версию которая мне нужна, тем способом который мне удобен.
 
Потому что я так хочу.
Как ответ на половину вопросов.

Я не говорю что это плохо, или т.п.
Каждый дрочит как он хочет.

Я попытался где-то показать бестп практис, и показать что стоит делать, а что нет.
Статическая верстка - это верстка с фиксированными размерами не реагирующая на размеры экрана
Это ты имеешь ввиду статический/динамический контент, в целом это не проблема верстки.
Я и не говорил что проблема верстки или нет, проблема процесса разработки)


Начиная с версии 3.5.1 появились проблемы совместимости с другими либами поэтому я подтягиваю ту версию которая мне нужна, тем способом который мне удобен.
Указать конкретную версию так же можно.
будет конкретно нужная тебе версия.

Любую верстку сначала надо сделать, потом натянуть на cms, если же хочется верстать прямо в cms или продолжить разработку в cms после адаптации верстки, то ничего не мешает прописать нужные пути, а вместо встроенного шаблонизатора в сборщике использовать шаблонизатор cms этот процесс не будет отличаться ничем от других сборок просто настрой как тебе надо, конфиг с путями лежит отдельно.
Это сложный путь с двойной работой, который плодит дополнительные баги, и только замедляет разработку.
Фронты делают сами что-то, потом беки начинают это переносить.
В более менее групных проектах, ты уже интегрируешь свои наработки в фрейм или цмс, и там очень часто уже есть билдер, который используется.
Простой пример: переводы через жс, тебе во время билда нужно их сгенерировать, подключить фрейморовский жсник, в котром будет логика переводов.
 
Я попытался где-то показать бестп практис, и показать что стоит делать, а что нет.
Не заметил бест практикса)
Я и не говорил что проблема верстки или нет, проблема процесса разработки)
Это вообще не проблема и я вроде объяснил почему

Это сложный путь с двойной работой, который плодит дополнительные баги, и только замедляет разработку.
Фронты делают сами что-то, потом беки начинают это переносить.
В более менее групных проектах, ты уже интегрируешь свои наработки в фрейм или цмс, и там очень часто уже есть билдер, который используется.
В более-менее командных проектах разработка ведется параллельно и интеграция с бекендом во время верстки невозможна впринципе, потому что бекенда на том момент нет. Если тебе удобно верстать сразу интегрируя в условный WP, то это не значит что все так делают, верстка на то и верстка она не должна отвлекать на то чего нет в данный момент и это значительно ускоряет процесс, а не усложняет его.

Указать конкретную версию так же можно.
Еще раз:
я подтягиваю ту версию которая мне нужна, тем способом который мне удобен.
 
В более-менее командных проектах разработка ведется параллельно и интеграция с бекендом во время верстки невозможна впринципе
не вижу смысла что ли писать вообще после этой фразы (выделена).
Удачи в работе.
 
Назад
Сверху Снизу