Игорь Самохин: и да и нет, 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)
vladamir smertniy: я не сервисную архитектуру предлагаю, я предлагаю регистрировать контроллеры как сервисы. Если они зарегистрированы как сервисы вы сами можете спокойно разруливать что куда там передается в конструктор, хоть App хоть только то что нужно. Ну и опять же вы можете сделать одну фабрику для всех контроллеров если хотите.
Далее все происходит ровно по вашему сценарию. Вы прописываете какой метод какого контроллера-сервиса дернуть, далее уже на основе рефлексии будет произведен подбор того что вам там нужно, App, Request или еще чего...
В целом же вместо всех этих извращений реально лучшим решением будет сделать сервисный слой и тонкие контроллеры, тогда их можно будет просто как замыкания использовать и не париться.
jetu: да, это более чем нормальный генерируемый код. Хотите оптимизировать - вынесите это в метод. По другому эту штуку реализовать довольно проблематично, только если в полифил запихнуть, что в прочим вам никто не мешает сделать. Да и на самом деле важно только то что слева.
Что до Set/Map/WeakMap и т.д. они поддерживаются полифилами, в принципе проблем с их использованием не будет, разве что поведение только эмулируется... Но зато где-нибудь через годик определенный процент разработчиков смогут это дело дропнуть и юзать в нэйтиве.
что до поддержки в мобильных браузерах - там с этим все хорошо (только ie тормозит, но есть полифилы).