- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
GravCMS подойдет
Если вдруг Google обновит рекомендации и скажет не использовать border-radius для карточек, мне нужно будет отредактировать только класс card.
Собственно для этого и предназначены классы, для абстракции.
А если пользоваться less\sass и так далее, то поменять наследуемые стили по всему проекту 2 минуты времени, при том писать БЭМ стили с ними тоже намного проще, чем на голом CSS
Это прекрасно, пока вы помните что у вас card это именно то что вам надо, а потом прихожу я и мне надо поменять стиль у конкретно этого card конкретно на этой странице, и? думаете я знаю что card это то что вы запланировали? Методология на то и методология, так сказать правила, БЭМ знаю многие, ваши - никто. БЭМ хорошо переносится между проектами, вы можете взять с любого БЭМ проекта и выдернуть кусок и он будет ровно таким же и никак не повлияет на новый проект. А знаете сколько в общем экономит реюзабельный код времени? С точки зрения абстракции БЭМ конечно же сложнее, он навязывает, но в дальнейшем он просто делает жизнь легче.
Я согласен, что это хорошо, когда нужно внести правки в чужой код, при этом ничего не поломав.
При условии, что отсутствует документация или время на ее чтение.
Только вот в большинстве случаев, на проектах заказчиков уже используется классическое именование классов.
То-есть, я прихожу и к блоку <div class="card red s-hide"> добавляю свое "body__cardredshide".
По сути, присваиваю одному конкретному блоку идентификатор с таким мега сложным именем.
Хотел бы я, чтобы на проектах заказчиков по-умолчанию был БЭМ?
Возможно.
Но на своем проекте, я бы такое не использовал.
Это рушит всю идею абстрактности классов.
С точки зрения гибкости и расширяемость, это то же самое, что писать <div style="">.
под сайт визитку незачем использовать CMS
так с этим никто не спорит. Так cms cms-ке рознь
Cms это как-бы content management system система управления контентом. И если мне, например, нужно будет сделать сайт, состоящий из трех страниц для себя, я напишу тот-же самый CMS (в оригинальном понимании этой аббревиатуры) на каком-нибудь кодигнитрере. (тем более, что у меня уже есть готовая сборка с блекджеком и ... ну в смысле с hmvc расширением и системой регистрации/авторизации/ролей) но это при некоторых вводных условиях.
1. объем написания кода не должен превышать 20 человекочасов
2. администрирование сайта будет производить его автор. То-есть это проект "для себя"
3. проект не является разовой работой.
в противном случае, при передаче проекта заказчику, да еще и без договора на обслуживание, они вас зае**т. Ведь найти девочку, которая в визивиге будет править страницы, это одно, а бородатого мужика в драных джинсах и уставшим взглядом -- это совсем другое, причем как по сложности, так и по цене.
вот как-то так.
Александр И, Вам никто не запрещает делать так как вам нравится. Просто мне непонятна позиция людей: "Я не понял — значит г..". И на этом форуме таких преобладающее количество, которые даже не пробовали, но рассуждают как матерые юзеры обсуждаемых технологий 😂
Просто нет инструментов, особенно популярных, которые делают разработчику во вред. Все инструменты решают ряд задач и если у вас нет таких задач, то инструменты тут не при чем.
Ну а пока не попробуешь, не вникнешь в какойто инструмент, то вряд ли он понравится, так как он выводит человека с зоны комфорта, чего наш мозг всячески избегает и чему противится.
Для сайта-визитки? Устроим гонку: верстальщик предоставил нам архив с файлами index.html, about.html, contact.html, footer.html, header.html. Кто быстрее сделает сайт визитку, я, распаковав архив и залив на хостинг, или ты, разворачивающий свою джангу или что ты там любишь?
Теперь устроим "гонку". Кто быстрей поменяет номер телефона. В цмске или груде файлов.
Ну-ка угадай в каком расположен телефончик :)
Но в целом логично делать визитку на "чистом" коде. Но я считаю, что это удобно только для разработчика. А заказчику потом без знания (да, элементарного, но все равно знания) основ верстки ничерта не подправить..
mmkulikov, ну телефон можно поменять поиском ... это не самый яркий пример, а вот пример, когда сайт состоит из 3 статических страниц и 2х динамических (новостной листинг и страница с телом новости), и всего таких новостй... ну пусть 48 (за год набралось, раз в неделю)
и надо поменять несколько пунктов в меню, при перемещении статических страниц в другие разделы...
вот уж где писец ночует
вообще то, что тут предлагается, мы проходили еще в 2002м. Поверьте. менять меню на сайте из 30 стат.страниц, это алес капут
Нет, всё хорошо. Голый хтмл можно вылизать чтобы он был на 2,5% меньше чем генеренный CMS-кой, и чтобы отдавался на 50мс быстрее. Прекрасно, радостно и понятно. Одно не ясно. Зачем? Нет, я могу объяснить почему у меня в 2005 году разработчик получил взбучку за то что он использовал целый байт(!) оперативной памяти там, где хватило бы полбайта. Всё просто - у нас их всего было 32 байта, проц на 64 байта стоил дороже, но это мелочи, он был больше, больше ножек, перерисовка платы, в общем - ну его нафиг. Полбайта тут, полбайта там, и потом цена изделия вырастает в два раза.
Но вам то это зачем?
Так плохо работаете что клиентов мало и хочется чтобы почаще вас дергали, чтобы больше денег получить? Или что? Или вправду думаете что сайт потребляющий 0.001% от выделенных ему ресурсов хостинга - нужно оптимизировать?
---------- Добавлено 11.01.2017 в 17:45 ----------
вообще то, что тут предлагается, мы проходили еще в 2002м. Поверьте. менять меню на сайте из 30 стат.страниц, это алес капут
инклюд.
Потом хотим выделить активный пункт меню и начинаем постепенно строить свою CMS только без преферанса и поэтесс, ибо мы ведь не CMS делаем, а голый хтмл))
вообще то, что тут предлагается, мы проходили еще в 2002м. Поверьте. менять меню на сайте из 30 стат.страниц, это алес капут
Эту проблему давно решили с помощью шаблонизаторов для nodejs и сборщиков фронтеда. То есть по факту 1 файл с меню, на выходе html страницы еще и с live reload. Верстальщики давно такие штуки юзают
Aisamiery, ну вот мы и приходим к тому, что создаем своего крокодила с пропеллером, только не на стороне сервера, а на стороне клиента