nepster09: gulp позволяет более логично организовать таски, а с выходом gulp4 вообще сказка будет (сейчас у галпа проблемы со сложными комбинациями паралельных и последовательных запусков тасков).
В частности использование gulp (code over configuration) решает массу проблем с тем как собирается фронт. Обычно там для продакшена просто добавляются отдельные стэпы, или конфиги подсовываются другие или еще чего... это пара строчек js.
Что до вопросов религии - это конечно да, но gulp дает намного больше контроля за тем что происходит и поддерживать инфраструктуру сборки проще.
Игорь Самохин: и да и нет, vm не подходят так как нам нужно именно высоту вьюпорта и не 90% а 50%. Ну это надуманный кейс, но суть та же - использование относительных единиц измерений не избавляет вас от медиа запросов, так как перестраивать лэйаут вам всеравно придется.
что до поддержки в мобильных браузерах - там с этим все хорошо (только ie тормозит, но есть полифилы).
Realetive: ну я упарываюсь по DDD, да и бизнес логикой фронтэнды редко блещут, да и различается она все же, хоть и по мелочи. Я в свое время пробовал метеор так как идея отсутствия дублирования радовала, но расстраивало то что писать приходится на богомерзском JS (сейчас есть хотя бы ES2015 и typescript) при помощи довольно отвратных вещей... сложную бизнес логику слишком легко превратить в кашу.
Павел Кононенко: капибара + хром это и есть E2E тесты, и я как раз от этого этой структурой и хотел избавиться - нормальное покрытие тестами обойдется слишком дорого (для меня прогон тестов в минуту это уже дико долго). У меня так же команда, и я навязываю эту структуру как раз таки что бы люди перестали писать как придется... Но у меня нет проблем с фреймворками и прочим.
Павел Кононенко: я не знаю зачем вам рельсы) если бы я решил уйти в руби я бы брал синатру, а рельсы я не переношу (надо будет глянуть что там в 5-ой версии планируют)
Что до структуры проекта - простой вопрос, вы пишите юнит тесты? Только e2e? Как у вас с поддержкой этих 20+ проектов? Я сам использовал такую структуру где-то полтора года, но все же такой подход позволяет сильно связать руки разработчику в плане того как он может косячить со структурой. Да и с код ревью проще, и тесты проще писать, а это как по мне самый главный аргумент.
Леонид Гилькович: там есть возможность задержку установить, скажем подождать 2 секунды и потом рендрить. Можно методом тыка задержку подобрать. Если хочется чего-то более гибкого - phantomjs - по сути тоже самое но есть возможность управления всем этим добром.
Realetive: для прототипа я бы смотрел исключительно в сторону PHP и Symfony так как я с этим стэком работаю. node.js там так же присутствовал бы (возможно) как шина данных или какой-нибудь свитч для очередей или воркеры простенькие на нем делать... писать что-то сложное (в плане бизнес логики) на ноде - боже упаси... обработка данных и работа с вводом/выводом - это да.
Я стараюсь придерживаться этих рекомендаций, они реально помогают держать код под контролем. Еще я упарываюсь по изоляции изменений и т.д. Скажем у меня все что касается маршрутизации и т.д. заперто в модуле navigation, и там только темплейты к маршрутам цепляются. Контроллеры для стэйтов/раутов используются исключительно для того что бы передать параметры в нужном виде в атрибуты директив. Логика UI раздроблена на независимые директивы которые легко покрыть тестами.
вот корявенький пример директивки реализующей логику просмотра какого-то элемента с навигацией туда-сюда. В теории это дело можно разделить на две дерективы но это уже излишняя избыточность.
Виталий: все старое актуальное... в целом в контексте JS вам надо разобраться с такой штукой как event loop, не так страшен черт. А вот управление потом исполнения в контексте event loop это да, поинтереснее, собственно я в ответе все перечислил, вариантов не особо много.
Павел Кононенко: причем тут организация кода в проектах? И да, то что вы привели это тип плохая практика.
Realetive: вы сами себе противоречите. Я как раз таки мыслю масштабно и прекрасно понимаю те ограничения которые накладывает CMS на разработчика (потому с ними и не работаю уже лет 6).
С другой стороны без должной технической экспертизы, без сильной команды, разницы начем будет реализовать проект вовсе нет - wordpress, modx или symfony - 99% что на выходе будет неподдерживаемый трэшачек и всеравно все придется переписывать в случае успеха проекта. А в этом случае лучше брать какое-то решение которое проще поддерживать - в случае автора вопроса это будет CMF так как хрен его знает что там за самапальный фреймворк.
Я с modx пересекался очень давно и это было мимолетное свидание с его нутром после которого я решил сразу же забить на него. Drupal 8-ой хоть все еще и отстой и требует набора кастылей, суппортить теоритически проще, а еще будет проще постепенно переводить проект с Drupal на Symfony или Laravel (по сути на любой PSR-7 или HttpKernel совместимый фреймворк).
Realetive: все это есть во многих других CMS и в частности в Drupal. И готовые решения там так же есть. И кастыли свои придется всеравно пилить.
Что до "архитектура намного сложнее" - это не так, все упирается в функционал соц сети. В былые времена соц сети плодили пачками, есть специализированные движки для соц сетей, есть куча готовых решений и т.д. Это все достаточно просто, вопрос только масштабов и того насколько будет легко развиваться дальше.
vladamir smertniy: ну вот это замыкание и есть контроллер. И по сути больше он ничего делать не должен, ну он может еще попросить какой другой сервис сформировать нужное представление данных на выход, еще поюс строчка две.
Контроллер это медиатор между слоями и только, его обязанность преобразовать данные из формата интерфейса (http, cli, etc) в формат приложения (то что кушают сервисы). Не больше. Никакой логики там быть не должно, только то что относится к слою интерфейса.
miy: ну на самом деле в контексте контроллеров печальки нет, печалька тут в другом - инстанцирование контроллера по сути у вас происходит в контроллере. Что не правильно с идеологической точки зрения.
Если уж хочется делать контроллеры тонкими, можно делать так (в silex)
$app->get('/main/{param}', function (Request $request, Application $app) {
return $app['main_provider']->getMain($request->get('param'));
});
А в сервисах мы уже делаем конкретные задачи и реализуем операционный слой (или application layer)
В частности использование gulp (code over configuration) решает массу проблем с тем как собирается фронт. Обычно там для продакшена просто добавляются отдельные стэпы, или конфиги подсовываются другие или еще чего... это пара строчек js.
Что до вопросов религии - это конечно да, но gulp дает намного больше контроля за тем что происходит и поддерживать инфраструктуру сборки проще.