Sergiu Mitu

Я стараюсь делить. Другие не делят. На вопрос невозможно дать однозначный ответ. Зависит от проекта, команды и настроения того, кто пишет :)

Дополню ответ: Если есть какой-то участок кода, который нужно использовать повторно, очевидно лучшим решением будет вынести его в отдельный модуль / функцию и т.п.. Деление на чистые компоненты и компоненты с логикой по сути и делается для того, чтобы вынести повторяющийся код в отдельный компонент. Иногда проще скопировать простой участок кода и не заморачиваться, а иногда лучше вынести куда-то. Так что зависит от задач и особенностей проекта.

если именно брать как "идеал" и частично этого придерживаться, то нормальный алгоритм. но в реальных условиях слишком дотошный алгоритм.
если ты все это мастерски отточил и щелкаешь как семечки - мое уважение.
но если это уменьшает скорость верстки (а при реальных условиях это очень сильно может уменьшить скорость верстки) - то тут уже лучше подумать и не быть таким дотошным. потому что такой "идеал" не нужен никому кроме тебя самого.
т.е. если брать твои 15 страниц, о которых ты ведешь речь и верстаешь их неделю - это уже можно считать, что долго. и за эту неделю ты бы мог сверстать в 2 раза больше страниц и получить также в 2 раза больше денег.

про SASS, PUG, GULP и пр. спорить не буду. если нужно будет - сам дойдешь до этого со временем.

В целом согласен. До пункта №7.

Я обычно придерживаюсь принципа верстки независимыми блоками.
Поэтому после анализа макетов, я делаю одну-две-три (смотря по объему макетов) вспомогательных страниц, на которых верстаю:

1. Базовые элементы. Общая типографика, кнопки, ссылки и т.п.
2. Общие блоки. То что повторяется на нескольких страницах и/или может быть переиспользовано, какие-то виджеты, менюшки, и т.п.

Все это занимает основную часть времени работы. И к окончанию этих этапов я имею своего рода набор, или конструктор, из готовых блоков. Остается только написать лейауты для разных страниц и раскидать по ним имеющиеся блоки.

Для этого всё закидываю на гитхаб-пейдж, чтобы по ссылке я мог открыть с телефона или попросить знакомого проверить на другой ОС c телефона

Это лишняя трата времени. Пусть небольшая, но все же. Плюс, отслеживать качество верстки все-таки удобнее в процессе, а не по окончании подкручивать.
Поэтому используем browser-sync. Поднимается сайт, доступный по IP в домашней локалке с любого устройства. Совет: использовать всегда один порт в browser-sync, а на устройствах сделать закладки на этот адрес. Любой сайт, который в данное время разрабатывается, открывается одним тапом по закладке.
Кроме того BS дает бонус в виде синхронизации действий сразу на всех устройствах: клики, прокрутка, ввод. Это мега-удобно — кликаешь на компе, краем глаза смотришь в планшет и телефоны, сразу видишь там все изменения и поведение.

Всё готово, сжимаю CSS, JS. через веб-сервисы.

Опять тратите время. Настроенный Gulp в одну команду проделает все оптимизации (на больших проектах даже кофе можно успеть сделать, пока собирается билд=).

Еще обратите внимание на инструмент lighthouse в инструментах разработчика.



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

Про CMS ничего не скажу. Клиенту удобнее кнопочки тыкать в условном вордпрессе.

Я не упомянул SASS-фигас и т. д, так как не увидел практической пользы для проектов на 1-15 страниц.

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

Ну вот зачем PUG? Как конкретно он помогает на небольших проектах 1-15 шаблонов страниц.

Помогает. Нет, конкретно Pug я очень не люблю. Но другой, более "хэтээмэльный" шаблонизатор бывает полезен. Я уже упомянул выше о верстке независимыми блоками. Шаблонизатор позволит не копипастить эти блоки, а использовать их как компоненты.

Префиксы? В кодовом редакторе они и так есть.

Я считаю, что исходный код должен быть чистым, без префиксов. Это лишний визуальный мусор. Пусть лучше автопрефиксер этим занимается. К тому же этот плагин использует актуальную базу caniuse на основе вашего .browserlist. Пусть профит и не большой, но все же поменьше на выходе неактуальных свойств.

const WebSocket = require('ws');

const ws = new WebSocket('wss://dallas.tx.publicsearch.us/ws', {
  headers: {
    "Origin": "https://dallas.tx.publicsearch.us",
    "Cookie": "authToken=51f69ac5-67c5-41ac-8943-cace7ebc6b3c; authToken.sig=x9S_G8Lwy6KHaB2Ek4PT1PR7jhE;"
  }
});

ws.on('open', () => {
  console.log('Соединение открыто');
});

ws.on('close', (code, reason) => {
  console.log('Соединение закрыто', code, reason);
});

у всех сайтов свои тараканы будут) к примеру в том что я скинул выше. Тебе обязательно передавать в заголовке запроса Origin и Cookie. Если с первым все ясно, то первая проблема будет с куками. Их как я понял можно получить сделав обычный GET запрос на главную. Тебе эти куки передадут в Response Headers


https://www.npmjs.com/package/ws

После удачного коннекта, не забывай потом слать пинги ) Формат пингов уже посмотришь во вкладке Network в браузере

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

background: url(../images/other/decor-figure-1.svg) no-repeat 53% 6%,
            url(../images/other/decor-figure-2.svg) no-repeat 45% 22%,
            url(../images/other/decor-figure-3.svg) no-repeat 82% 22%,
            url(../images/other/decor-figure-4.svg) no-repeat 45% 96%,
            url(../images/other/decor-figure-5.svg) no-repeat 83% 82%

Держи, немного поправил один из своих старых набросков.

Принцип работы примерно, как описал Максим Морев в своем ответе.

Вот здесь, например, делал когда-то такую вещь (блок "Этапы создания корпоративного сайта").



Идея, вкратце:

1. Элементы размещаете просто в сетку с помощью inline-block/float/flex/grid - как привычнее.
   
2. Родителю задаёте относительное позиционирование, в него помещаете абсолютный элемент на всю ширину/высоту с небольшим запасом, на котором будете рисовать SVG.
   
3. Как нарисуется - на js считаете ключевые точки (координаты), через которые нужно провести линии.
   
4. Динамически рисуете SVG по вашим ключевым точкам.
   О том, какие варианты вообще есть, можно почитать на MDN, например.
   Выглядеть это будет примерно так:
   
   
   
   В вашем случае рекомендую использовать кривые Безье. Здесь мне нужно было сделать полукруг, поэтому я использовал дуги, у вас же просто статичная величина закругления.
   
5. На ресайз окна считаете ключевые точки заново и перерисовываете SVG.
   
6. Опционально заморачиваетесь и добавляете сверху ещё один путь, который по скроллу будет "заполняться"
   

Это в целом чёрная магия, можно полдня убить, но красиво :)
Если это всё очень сложно, то просто картинкой вставьте, высоту элементов фиксируйте, и меняйте картинку для адаптивных вариантов.

Готовых вариантов тут в общем-то вы вряд ли найдёте, нужно взять и разработать.
У меня была идея оформить это в какую-то библиотеку, но как и все остальные идеи - и ныне лежит в туду-листе на 60+ пунктов. :)

В общем, поигравшись немного с предоставленным кодом, стало понятно следующее:

Это явно проблема браузера, так что имеет смысл сообщить о ней разработчикам, написав bug report в их трекер.

При этом проблема несколько не в том месте где ожидалось: элементы страницы позиционируются правильно, а вот отрисовываются некорректно:



Здесь видно, что картинка с точки зрения браузера находится в одном месте, а по факту нарисована в другом.

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

Я подготовил пример, демонстрирующий вариант решения. По сути он сводится к добавлению стиля, который производит визуально почти незаметное изменение стилей, которое, однако, заставляет браузер перерисовать всю область:

.chat-item__content.force-repaint .content-chat-content__message {
    opacity: 0.99;
}

Остаётся только "дёрнуть" CSS класс force-repaint на элементе контейнера - и всё сразу встаёт на место, поскольку осуществляется перерисовка. Например вот так:

function forceRepaintToFixChrome89Issue() {
    if (!navigator.appVersion.match(/\sChrome\/(89|9\d)\./)) {
        // Apply only for Chrome 89 and 90+
        return;
    }
    window.requestAnimationFrame(function () {
        const e = document.querySelector('.chat-item__content');
        if (!e) {
            return;
        }
        const fr = 'force-repaint';
        e.classList.add(fr);
        window.requestAnimationFrame(function () {
            e.classList.remove(fr);
        });
    });
}

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

Разумнее всего обсудить с заказчиком и дизайнером идею, что тексты под картинкой должны быть независимы от текста в оставшихся 2х колонках. Благо первый столбец и так вполне обособлен.
И показывать так как на макете только на очень ограниченной ширине окна, а на остальных перестраивать вариантами попроще.

Из того, что пришло в голову:

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

Как вебмастер говорю, а не как покупатель:

В 2008-2013 годах сайт с тиц 50 и ~30 страницами давал в сутки около 50 рублей.
Сайт с тиц 2000 давал в сутки 1000-1500 рублей

За все эти годы я вывел около 1 500 000 рублей на серии совсем простых сайтов.

Последняя попытка (2-3 года назад) продажи этих сайтов на сапе не дала ничего.

ИМХО, направление умерло.

Для БД при инициализации и разработке могут использоваться миграции.
В чем суть миграций БД?
Миграции БД в nodejs

Не знаю как в ноде, но в ASP.NET можно и предпочтительно делать проект используя подход Code First, который предполагает использование миграций для генерации таблиц из кода в БД.