Mokhirzon Naimov: то есть php изучать не нужно что-ли? Не смешите. Вот из-за таких мыслей в среднем качество решений на PHP (на Laravel или любой другом фреймворке) оставляет желать лучшего. Люди вбивают себе в голову эту чушь по поводу того что что-то проще, и радуются.
Mokhirzon Naimov: а у вас есть опыт работы с чем-то оличным от Laravel? Другие подходы и т.д.? Фразы вроде "нет более оптимального" весьма себе глупо звучат.
rustf: я как PHP разработчик посоветую PHP. Рубист посоветует руби.... тенденцию вы поняли. Скажу так, сложность возникает только с поиском разработчиков и у каждой технологии есть определенные особенности. В частности Ruby будет чуть дороже, но по скорости разработки и качеству в среднем выходит лучше. Это не значит что рисков того, что разработчик выдаст вам ужасный результат нет. В случае с Python есть свои нюансы, я этот язык использую исключительно для ресерчей и скриптов автоматизации, так что ничего не могу сказать. PHP - очень легко словить неадекватных разработчиков, больше рисков. Но если с разработчиком повезет, будет и быстро и в плане производительности/масштабируемости хорошо.
То есть тут как раз таки надо смотреть на рынок труда больше а не на стэк технологий. Есть еще такие нюансы, если разработчик предполагает использовать PHP + MySQL то риски тут выше чем PHP + PostgreSQL. То есть есть определенные особенности в плане комбинации стэка, которые уже могут как-то судить о уровне разработчика.
Еще стоит уточнять методологии разработки и т.д. Так же это важно и для вас, со стороны клиента, знать как вообще работают процессы разработки ПО. Так скажем можно организовать разработку так, что бы видеть результат уже через неделю-две, по которому можно уже судить норм разработчик или нет.
Евгений Петров: В твоем примере у тебя есть логический блок, элемент списка, товар. В целом мне больше нравится вариант когда лэйблы со статусом товара имеют свои классы и никак не зависят от родителя, но да, иногда бывает что это оверхэд.
Но когда у людей есть правила, согласно которым они меняют положение элементов страницы от класса body (этим любят страдать wordpress и joomla разработчики), скажем для одной страницы так, а для другой по другому, то это уже превращается в ад. Я много ужасов повидал, и могу сказать что следование БЭМ эти проблемы решает. А далее уже надо полагаться на собственное чутье. Проблема в том что у большинства нет достаточно опыта. Словом, пусть уж будет "обезьянка видит обезьянка делает" чем давать ей в руки гранату, которая превратит стили в неподдерживаемое гуано.
Евгений Петров: причем тут производительность? Мне надоело видеть неподдерживаемый CSS с дикой связанностью. Проблема именно в этом, а не в том что что-то там медленнее отрабатывает.
Евгений Петров: большинство разработчиков не умеют пользоваться каскадом, так что лучше для них отказаться. В идеале каскад стоит применять в рамках блоков, но не глобально. Словом, я не говорю что от каскада надо избавляться, просто использовать его надо ооочень осторожно. Ну и да, от style точно надо отказываться.
shipovalovyuriy: еще поправка, стоит только тогда, когда надо подписаться на события или их генерировать, но не для того что бы работать с данными в скоупе.
raiboon: дочитайте абзац. Не для всех SPA вообще это нужно. А даже если и нужно, Angular не поддерживает server-side рэндринг, а стало быть, нужно для поисковиков подключать page fragments api + через какой phantomjs генерить эти фрагменты. Да и готовые решения есть.
Сергей Цалоев: ну как, не совсем. Контроллер это слой, который разделяет представление и модель. А уж куда вы воткнете логику - это ваше дело. Можно и в контроллер, а можно куда-то еще, сохраняя этот разделяющий слой как можно тоньше.
Артём Щурин: по дефолту ангуляр разрешает юзать директиву как элемент или атрибут для элемента. За этим вопросом лучше обратиться к документации или к одной из сотен статей в интернетах.
sitev_ru: отправлять по частям. Отправили пол мегабайта, следующий сокет и т.д. Потом выбираем сокеты в которых уже можно отправлять еще, отправляем еще кусок... ну и т.д.
