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

модель - это очень абстрактное слово. Заглянем в словарь:

Модель - представление предмета, системы...

Итого - "моделью" в контексте MV* является... модель вашего приложения, то есть что собственно приложение делает. Главное не заблуждаться что это "способ доступа к данным", там по сути все что относится к обработке данных. То есть контроллеры максимум могут просить модель что-то сделать или дать представление каких-то данных, что бы контроллер сформировал из этого view (HTTP ответ в контексте PHP фреймворка).

Есть еще такая штука - Action-Domain-Responder называется, там чуть меньше "абстрактных слов" но суть примерно та же что и у MVC.

Но вернемся к вопросу

Не могу до конца понять как использовать модели, где они хранятся.

Это вам решать. Slim - это очень простой HTTP фреймворк. Его задача - дать вам контроллеры, а модель - ваша задача ее реализовать. Вы можете вооружиться контейнером зависимостей или сервис локатором даже, и дергать нужные сервисы, которые уже будут делать дела.

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

Ссылку на "зачем нужна инъекция зависимостей" вам уже привели, я лишь добавлю более-менее полезное чтиво на тему разделения ответственноси и слоеных архитектур в slim: codereview.stackexchange.com/questions/93914/slim-...

В целом сразу вас расстрою, то что вы хотите нельзя "разобрать" за пару месяцев. На это уйдет пару тройку лет. И книги которые стоит по этой теме прочитать имеет смысл перечитывать. Ну и практика практика практика.

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

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

но совершенно не имею представления о правильной архитектуре приложений на php

"Правильно" не бывает, все зависит от задачи. "Правильная" архитектура является:

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

Вот и все. Далее уже есть принципы SOLID (читать Роберта Мартина), GRASP (Крэйг Ларман), GoF (лучше тут почитать head first design patterns или даже начать с Мэта Зандстры, у него помимо паттернов еще про процессы мельком рассказано).

Ну и смысла в этом всем нет если вы еще до конца не осознали что есть инкапсуляция и полиморфизм. Многие могут рассказать что значат эти термины, но на практике эти знания они не могут применить (чаще всего страдает инкапсуляция)

или написании чего-то своего с нуля на чистом php

Такое решение может принимать только разработчик у которого уже есть за плечами хотя бы пяток лет опыта работы с различными (не одним) фреймворком и языками. В противном случае вы только будете заниматься бесполезным велосипедостроительством.

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

Берете Symfony или Zend и вперед. Все остальные фреймворки "проще". То есть скрывают больше от разработчика. После них уже можно брать что угодно.

p.s. еще прочитайте тут: www.phptherightway.com

да и не вся информация запомнится

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

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

вам сейчас не фреймворк нужен а просто изучать PHP, ООП и структурное программирование, поучиться еще тесты писать, GIT освоить..... composer, PSR и т.д. а вот потом уже фреймворки.

что есть хорошее в фреймворках

- принцип единой ответственности
- принцип открытости/закрытости
- принцип подстановки Барбары Лисков
- сегрегация интерфейсов
- инверсия зависимостей (не путать с dependency injection)

за основу взят CodeIgniter.

это путь в никуда.

react - библиотека для работы с компонентами. Ее основная фишка - отказ от работы с DOM напрямую. Альтернатива (более лояльная) - polymer, основанная на web-компонентах.

angular - полноценный фреймворк. В нем есть смысл если вы все приложение будете на нем писать а не кусок.

jquery - удобная библиотека для работы с DOM.

Вывод - учите javascript, пользуйтесь jquery.

Есть решения?

50 милисекунд это не так уж много. Средний человек реагирует на событие после примерно 200 милисекунд. Так что либо вы привели не верные цифры, либо не знаю.

В целом вам нужно почитать в wiki галпа (или в его README) про инкрементную сборку и решения вроде gulp-cache и gulp-newer. Либо хранить все файлы в памяти и уменьшить количество чтений с диска, либо компилировать только измененные файлы. Ну и неплохо совместить эти два подхода).

та что в гугле, не лишена маркетинговых трюков, да и свежесть не та.

ashleynolan.co.uk/blog/frontend-tooling-survey-201...

Собственно моя команда использует Angular уже где-то два с половиной года, и в принципе мы довольны. Особенно радует Angular2, который судя по тому что можно видеть, уже не особо страдает болячками 1.x версии. Не вижу смысла переходить на ReactJS, хотя он в списке потыкать (уже год). Основная боль - привить разработчику компонентный подход в Angular и с таким раскладом жить становится не так уж плохо. Особенно с ES6/7 в варианте babel. На Ember смотрел но опять же не вижу смысла. Кроме ember-data там для меня нет ничего особо интересного.

Для сборки ранее использовали просто gulp и кучу тасков, сейчас это scss/less в зависимости от проекта и webpack в качестве бандлера. Я все надеюсь перевести все на jspm + system.js но увы пока ранова-то.

Для тестов пока используется mocha, потихоньку хочется перейти на cucumber.js (на бэкэнде используем Behat, так что подружить их вместе и гонять одни и те же фичаспеки кажется логичным).

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

PDO

PDO? PHP Data Objects?

php.net/manual/en/book.pdo.php

хотя в целом лучше взять готовый dbal, например doctrine/dbal

семинары по ООП

Есть книжки, есть лекции. Например есть неплохие лекции от Сергея Немчинского (пример), у него конечно по Java но суть от этого не меняется. Более того, почти вся стоящая литература ориентирована на Java, но спроэцировать эти знания на PHP проблемы не составляет.

И с какого PHP фреймворка лучше начать обучаться?

Ни с какого, сначала освойте PHP и ООП на базовом уровне. Потом освойте git, composer. Потом попробуйте тесты пописать (TDD попрактиковать еще можно, хорошо для обучения), всякие там phpunit/phpspec/peridot/etc. А уже потом можно... уже брать какой-нибудь фреймворк.

Какие JS-фреймворки нужны начинающему?

Никакие. Сначала JS на нормальном уровне освойте. Судя по тому что у вас был опыт с Python это не должно вызвать больших затруднений.

но особо не понял для чего они

А зачем фреймворки в Java, Python?

какие фреймворки вы используете для работы, и в паре слов для чего они предназначены

использую Angular в контексте single page application, нужен он для работы.

Хорошо ли он подружится с React.js?

А в react.js уже есть http клиент? Эта библиотека только для view layer. Так что как приготовите взаимодействие с API так и будет дружить.

А стоит ли тратить время на написание REST API ?

https://parse.com/