Сергей Протько

1) что угодно, у вас тут конкретно можно "выдавить" (extrude) из 2d формы. Такие штуки удобно делать во всяких autocad-ах и тд.

2) three.js - там есть примеры и загрузчики моделек.

крупные проекты бывают разные. Если у вас сложная бизнес логика то лучше взять Doctrine2. Если очень много запросов на чтение и сложные выборки, и при этом бизнес логика примитивна (crud) - можно просто взять doctrine/dbal и не париться, мэпить данные прямо на какие-то transfer object-ы. В этом ключе всякие там недо-ормки подходят хорошо, так как упрощают мэппинг при записи.

В мире PHP есть только одна нормальная ORM - доктрина (как это не печально, но похожая ситуация и в других языках, python - только SQLAlchemy, java - только hibernate по сути. Связано это с тем что правильная ORM с дата мэппером это ооочень сложно). Все остальное это так... не серьезно. Просто упрощалки которые позволяют работать с таблицами. На реально крупных проектах которые пишут бородатые дядьки, возьми они Active Record и вынесут в отдельный слой что бы не трогало даже приложение, будут использовать эту штуку тупо как DTO между приложением и базой. Собственно многие так и доктрину используют, но это уже детали.

p.s. в ридми не правильно трактуется закон Парето и делаются не совсем правильные выводы.

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

Еще вариант - если у вас приложение грамотно разбито на директивы (а не контроллеры отдельные с вьюшками) то можно попытаться сделать ленивую подгрузку сервисов в фабриках + ленивую подгрузку директив. Чисто теоритически это возможно и чисто теоритически так можно подгружать лениво большую часть проекта.

p.s. вроде как обещали в angular 1.5 сделать что-нибудь с этим но я не следил - для меня это без надобности. В Angular2 это будет по сути из коробки доступно так как в качестве системы модулей используется стандартные ES2015 модули.

https://gist.github.com/fesor/226fce4a4aee5fb30454 - например так.

Либо в директиве подписываться на $stateChangeSuccess и подменять классы. Был у меня такой примерчик где-то но потерялся...

как бы сделали вы?

базовые стили (общие) в header, остальное в модификаторы в зависимости от нужд. Ну и да, не привязывайте именование модификаторов к контексту, для того что бы скажем добавить заголовкам маргин сверху от слайдера у вас элементы есть (slide__header)

В целом если сделать так:

<div class="page">
  <div class="page__header">
    <h1 class="header">Заголовк страницы</h1>
  </div>
  <div class="page__slider">
    <div class="slider">
          <div class="slider__item slide"> 
            <h1 class="slide__header header header--small" >Заголовк слайда</h1>
          </div>
    </div>
  </div>
<div>

ну вот как-то так... для более нагладного примера лучше привести макет или что-то упрощенное но передающую суть проблемы.

p.s. Да.

Проект развивается итерациями и фичи нагромождаются и код, естественно, не самый изящный и простой для понимания и анализа.

Тесты, TDD, рефакторинг, SOLID. И тогда нет боли. Но это увы далеко не на каждом проекте встретишь.

Потому, как, тебя просят добавить или починить функцию А, ты ее чинишь, но попутно, возможно, ломаешь явно фичу Б и неявно В

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

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

Баги это хорошо, регрессионные баги это плохо, это показатель того что с нашим кодом что-то не так. Уменьшить количество багов просто - нужно больше тестов с учетом различных инвариантов. Но иногда это избыточно, и проще просто словить и пофиксить баг.

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

1) выкинуть codeigniter и переписать все на reactphp
2) вместо того что бы выдумывать наркоманию не парьтесь и делайте как все, stateless апишки и все такое. keep-alive минимизируют расходы на установление http соединения, а для оптимизации работы с базой можно просто использовать persistent connections и тд.
3) выкинуть codeigniter и переписать на любом фреймворке использующим PSR-7 или symfony/httpkernel, вооружиться php-pm.

Когда узнал что ReactJS, это не аналог angularjs не очень-то и расстроился.

Вам бессовестно соврали, там различия конечно есть, особенно в части отслеживания изменений и т.д. но они не настолько кординальные. В общем и целом один и тот же подход может быть реализован и там и там.

нет поддержки ts у текущей версии

blog.mgechev.com/2015/07/05/using-jsx-react-with-t...
https://github.com/Asana/typed-react/

отсутствия свойств уровня класса.

ну грубо говоря классов в JS как небыло так и нет...

но нет понимания роутинга.

Так же как и в angular - https://github.com/strml/react-router-component

Никаких пробелов. Для ангуляра к слову такая же примерно штука есть, официальная замена всяким там uiRouter-ам.

С AngularJS я не задумывался вообще не о чем

Это главная проблема angular, люди не думают что делают....

p.s. Реакт в отличии от ангуляра это библиотека. Flux - тоже можно назвать библиотекой. Ангуляр (если мы берем 1.x ветку) - монолитный фреймворк. Вот и вся разница. С реактом вы берете только то что вам нужно.

вам нужен не фреймворк а библиотека. vue.js норм.

ммм.... зависит от задачи. Из вашего описания вам нужен один бэкэнд разработчик (ruby) и один фронтэнд разработчик. Либо фулстэк, коих мало нормальных в такой комбинации (да и в любой другой).

Что должен уметь бэкэндер - настроить окружение, возможно штуки для автоматизации (ansible/puppet), должен знать что такое и зачем нужен vagrant (то что разработка на mac os ничего не значит, деплоиться вы будете на линукс, и выкиньте дурные мысли о использовании соляриса). Может быть docker... но это уже пусть девелопер решает.

Вместо apache по умолчанию берем nginx, вместо mysql может быть postgresql, может вам еще elasticsearch придется вкатить... в зависимости от задачи выбираются базы данных и прочий мусор. Это все всего-лишь инструменты.

Отдельно хочу заметить что помимо того что девелопер должен знать что такое "Agile Software Development", это так же должны знать вы. И это не скрамы/канбаны, хотя это тоже полезно. Лучше пусть у человека здравый смысл будет.