Игорь Петров

после того как верстка готова, её нужно порезать на шаблоны серверного шаблонизатора

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

js и scss исходники раскидать по папкам в какой-нибудь resource директории и настроить сборку всего этого добра тем же gulp и webpack, что бы в дальнейшем проект поддерживался уже без отрыва от серверной части.

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

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

Из личного опыта, пользу получают в основном те, у кого компьютер PHP (или PHP-шаблонизатор) не потянул, или автор не осилил установку PHP или не осилили основы PHP/-шаблонизатора этот человек не осилил. Обычно, гораздо проще писать сразу на PHP-шаблонизаторе, в идеале - в купе (совместно) с проектом и сразу же проверять/видеть результат. В нормальной фирме, программисты ни натягиванием вёрстки, ни её разработкой (созданием) не занимаются, этим занимаются исключительно верстальщики. А теперь подумайте, Вы действительно хотите сначала писать шаблоны в jade/pug, а потом перегонять их в Twig например? Такой подход, как Вы описали, обычно применим для команд уровня "1.5 человека", в которых обычно есть "заказчик" и "исполнитель", при этом, в 95% случаев, заказчика мало интересуют исходники, особенно исходники jade/pug.

Могу Вам порекомендовать ознакомиться с проектом nodeJS/Twig, в теории это реализация PHP-шаблонизатора Twig на JS'е. Но, сам не пробовал особо, описать впечатления не могу. Возможно, он способен генерировать/интерпретировать правильный Twig-код, который потом можно будет использовать в PHP.

Есть еще мысли, например, хранить эту верстку отдельно, собирать из исходников готовые js и css файлы в директории с серверным проектом и в случае необходимых правок вносить их сначала в самой верстке, а потом дублировать изменения в серверном шаблонизаторе.

Есть такой "паттерн", называется "сборка проекта", появился он (как практика и ПО для реализации подобных практик) задолго до того, как мир узнал слова Gulp, Grunt, etc. Среди прочего, это ПО умеет собирать SCSS, минимизировать JS-код, склеивать/расклеивать/размазывать/итд его (код) любым возможным образом. Это же касается и оптимизации картинок и всего остального.

Почти всё, что Вы видите в виде модулей для nodeJS и/или Gulp/Grunt, включая их самих - в большинстве случаев, есть либо переписанная на JS существующая ранее программа/утилита (для возможности работать на nodeJS), либо, обёртка поверх них. На мой взгляд, Gulp не лучший конвейерный сборщик проектов, для проектов с длительной поддержкой, для языков отличных от JS. Он скорее лучший сборщик для соло-разработки, когда верстальщик и заказчик - это два человека, и длительная поддержка проекта изначально не планируется. У любого крупного и адекватного проекта, обычно есть сборщики альтернативные Gulp/Grunt, а необходимые корректировки пишутся не дважды, а один раз, на одной конкретной ветке проекта. Не редко, специально для этого поднимаются тестовые стенды, не редко их может быть довольно много, и там Вы можете вносить любые изменения в т.ч. и вёрстку и тут же мониторить результат её реального отображения, а потом делать соотв. пуш, соотв. ветки на соотв. сервер/репозиторий и отправлять проекта на тесты/сборку/итд.

Шаблонизаторы типа Smarty, Twig в 2017 востребованы, если с ними раньше не работал стоит ли смотреть, изучать что бы повысить ценность свою на рынке труда?

Smarty - вряд ли.
Twig - вполне себе актуален, я Вам даже больше скажу, он уже интегрирован "из коробки" в довольно популярную CMS по имени Drupal 8 (т.к. он сделан на базе Symfony) и собственно, в не менее популярный фреймворк под названием Symfony. И, Twig отлично встраивается в очень популярный фреймворк (я имею в виду, в ракурсе PHP-*) под названием Laravel, который в свою очередь так же имеет свой весьма неплохой шаблонизатор, под названием Blade.

Среди прочего, вариация Twig'а есть даже для JS (Node.JS), в качестве альтернативы таким штукам как Pug/Jade например. *По информации одного из наших коллег, такие шаблоны (в JS-вариации интерпретатора) отлично переносятся потом в оригинальный Twig/PHP (имеют хорошую совместимость/переносимость).
*Сам не проверял, но, доверяю словам автора.

Или их нативный php всё же их вытеснил

Из тех шаблонизаторов, что я могу вспомнить, по моему, все "компилируются" (преобразуются) в нативный для системы код (даже Smarty), т.е. если мы говорим про PHP - то соотв. в PHP-код. Парсится шаблон в код не часто и разница в производительности довольно не значительная, в 99% случаев - ей можно принебречь.

или все ушли во Фронтенд шаблонизаторы?

У них обычно немного разные категории задач. Если Вы говорите про шаблонизаторы аля Pug/Jade - то, что из них выходит, в конечный не-JS код, интегрируется плохо. То есть, смысл от этого шаблонизатора только для того, кто делает вёрстку, практической пользы при переносе на PHP-движок (и другие не JS-движки) от него обычно нет, либо очень мало.

Если говорить о чисто клиентских реализациях - генерировать данные на клиенте, в таком объёме, по моему, не кошерно в подавляющем большинстве случаев, с учётом того, что сервер может кэшировать страницу целиком и выдавать сразу готовую (Varnish, например, это если говорить о необходимости высокой производительности), а какой-нибудь полу-мёртвый смартфон, бедолаги, который зайдет на подобный сайт - лопнет от чрезмерного изобилия JS-кода.

Если это webpack, то можно использовать alias-ы:

webpack.config.js

resolve: {
    alias: {
      'Components': path.resolve(__dirname, 'src/components/'),
      '@': path.resolve(__dirname, 'src')
    }
  },

SomeNestedComponent.jsx

import {Something} from '@/styles/MyUiKit';
import SomeComponent from 'Components/SomeComponent';

А в чем сложность повторить алгоритм, но уже на сайте?
Переносите "участников", параметры, делаете интерфейс и все. Я не уверен, что вы сможете как-то "утилизировать" - переиспользовать исходную таблицу из Excel.

Есть конечно бредовый вариант, подключить ее через OLE-интерфейс, но это вообще не вариант - просто работать будет медленно. Так же, параллельно не возможно будет с ней работать.

Вы определитесь где вы это собираетесь считать:
1. Фронт
2. Бэк

На фронте это будет 99% JavaScript, на бэке то на чёт написан бэк.

Ну и при реализации забываем слово "эксель таблица", вам не логику таблицы нужно переносить а выводить формулу расчёта и уже её использовать.

Вы в постановку вопроса хорошенько вдумайтесь. Вы спрашиваете про ТЕХНИЧЕСКОЕ решение, которое не позволит детям использовать телефоны КАК ФОТО- и ВИДЕО-КАМЕРЫ?

Ну, можно заклеивать объективы, например, и вешать плобмы на наклейки. Подойдёт? :-)

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

Здесь только административно:

• Требовать сдавать телефоны как минимум на время физкультуры;
  
• Если кому-то жизненно необходимо наличие телефона рядом постоянно -- ОК, приходите с самым простым телефоном, без камер и прочего;
  
• Самых рьяных рассылальщиков -- сдавать в полицию, по статье "нарушение неприкосновенности частной жизни" (Статья 137 УК РФ. Штрафы там, кстати, весьма весомые -- до 200 тысяч). Когда начнут более или менее регулярно прилетать штрафы -- многие сами задумаются, а надо ли оно им?
  

вы сейчас описали случаи которые можно реализовать на SCSS. И запись вида:

.block{
    .block__header{}
    .block__text{}
}

все равно перекомпилируется в CSS так:

.block{}
.block .block__header{}
.block .block__text{}

Также можно написать:

.block{
    &__header{}
    &__text{}
}

так будет правильнее.

если работа хорошая то норм
год слишком долго
по сути закончили обучение и нет роста зп и прочего увольняетесь и на новую работу

Вообще, реально ли в Москве, например, найти работу с моими компетенциями?

Если ты не можешь ответить на этот вопрос, то нам откуда знать?

Холодная провинциальная смерть в объятьях Битрикса?

Да.

1. Найди вакансии, отправь резюме, пройди онлайн-собеседование.
2. Оцени результаты, сделай поправку на скилл.
3. Возьми отпуск и езжай в Москву и проходи уже очные собеседования. Из этого отпуска ты можешь не вернуться. А можешь и вернуться. В любом случае, что-то произойдет.

Пишу по порядку, как реально нужно.

Поиск по Тостеру, так как схожие вопросы задаются минимум 2-3 раза в неделю.

адаптива не знаю, он у нас и не требуется

Печально уже за такую компанию, которая сейчас пренебрегает адаптивной версткой.
Хотя, быть может (моя последняя надежда) у вас есть мобильная версия сайта.

про бэм и препроцессоры что-то где-то читал, но тоже не знаю

Да не используйте, и не учите. Просто теряете время и ресурсы на написание код (или говнокода, не знаю).
Просто без препроцессоров всё делается долго и нудно, и тяжело структурировать, копаясь в одном файле.
А так, можете не учить, если хочется заморачиваться %)

js так же, на уровне скопировал-вставил

Выскажу свое личное мнение.
Верстальщик без JS, это не верстальщик, это контент-менеджер со знанием HTML.
Любой сайт от лендинга до портала требует JS, правда часто делают хрень, напичканную плагинами, даже если требуется 2-3 строки кода. Не нужно подключать плагины там, где оно не нужно и обратная сторона вопроса, не нужно писать свой код там, где можно использовать готовый плагин (не изобретать велосипед).
Но если есть время, желание и умение, можно писать и свои плагины, для тренировки.

Верстаем display:table/table-cell

Тут буду краток. $^*(&%#(*$%($(%&*(*$#&*%($#%)($)^_*()#&@%$ - вырезано цензурой.

не в одну компанию с такими навыками меня явно не возьмут

Что мешает заниматься самообразованием?
Благо живем в 21 веке, в интернете есть любые учебники, тесты, курсы, да чего только нет.
На крайний случай, можно напросить в подмастерья к какому-нибудь верстальщику (знаю, часто требуются).
Да, работать придется в основном "за еду", но будет опытный наставник, который скажет - так норм, а так не надо.

надо изучать с бустрапа сразу

Не зная принципов адаптивной верстки, использовать Бутстрап не получится.
Так что в ьлюбом случае, понимание адаптивной верстки должно быть, при том "чистое", чтобы можно было разобраться не только в Бутстрапе. Фреймворков для адаптивной верстки еще очень и очень много.

советы от товарищей по цеху, как развивались они и откуда брали инфу

90% опыта приходит вместе с практикой.
Можно прочитать 100 учебников и не понять, что это за свойство, а можно один раз применить и сразу понять.
Нужно просто много и усердно практиковаться. Качать любые шаблоны PSD, верстать, верстать, верстать.
Сначала простые, трехколоночные сайты. Потом посложнее и закончить каким-нибудь паралаксом.
Но повторюсь, для обучения минимум плагинов.

есть ли смысл работать в маленьком городе

Не знаю, что за город у вас. Скажу про свой. Население около 900тыс.
В городе порядка 5 топовых студий по созданию сайтов, не считая 2-3 десятков мелких контор.
Также есть топовые IT компании, но про них говорить не буду, с таким багажом тебя туда пока не возьмут.
Так что в любом городе есть смысл работать.
Да и фриланс, удаленную работу никто не отменял.

вопрос только Москва или оставаться в городе

Что в Москве, медом намазано? Или думаешь, так вакансий больше?
Нифига не больше, потому как и желающих поработать там не меньше чем вакансий.

В общем, резюмируя всё вышесказанное - учись, развивайся.

Удачи.

ЗЫ: Недавно на Хабре опубликовали ссылку.
webmasters.teamdev.com
Чесслово, проникся. Отличный мануал.