Comments 22

Жив. Основные части 3.0 уже можно даже запустить. Но пока там много работы, не хотим раздувать новостей из ничего...

Если коротко: время перемен: 2.0 уже порядком устарел, а нового 3.0 еще нет.

Стало очевидно что нужно переделывать компоненты (как минимум, отделять от ядра) и менять подходы (например, названия и версионирование), убирать зависимости от jquery, bootstrap. Убирать тот же pjax.
Нужно как-то решить вопрос с типизированием потому что компоненты принимают все подряд в аргументах.
Многое уже сделано, многое еще предстоит сделать, поэтому ждать 3.0 раньше начала-середины 2019 я бы точно не стал.

А еще интересный момент в концепции фреймворка. С одной стороны, Александр когда-то заявлял что фрейм создан для RAD-разработки и до сих пор это успешно работало. С другой стороны, тренд движется в сторону разработки более высокого уровня с использованием репозиториев, etc, что видно на примере Symfony и, особенно, Laravel. Многие уже наломали дров с тем же AR, видимо.

Собственно, мое видение как наблюдающего за всем этим.
С другой стороны, тренд движется в сторону разработки более высокого уровня с использованием репозиториев, etc, что видно на примере Symfony и, особенно, Laravel. Многие уже наломали дров с тем же AR, видимо.
Лично я не понимаю, зачем в одном проекте смешивать http и ORM — это же никак не связанные вещи.

Symfony в этом плане отлично поступил и просто не имеет прослойки модели.
И то, что выкинули фронтенд — тоже замечательно, в современном вебе фронтенд и бекенд — обычно разные проекты. Никто же не добавляет код Android или iPhone приложений в репозиторий бекенда? Так чем фронтенд хуже?
Я думаю все упирается в скорость разработки, просто у нас уже принято дефакто фул стек разработчик может делать и фронт и бек, и вот фреймворки в этом помогали, чтобы делать все вместе, без смены контекста

А с Android и ios уже другой вопрос, если бы фул стеки еще знали swift или kotlin, то почему нет?)

Да, тренд диктует что нужно делать в разных корзинах фронт и бек, с чем я и согласен
А с Android и ios уже другой вопрос, если бы фул стеки еще знали swift или kotlin, то почему нет?)
Чтобы не делать гору из кода, грамотно управлять задачами, релизами (релизить части системы по-отдельности).
А что касается фулстека, то есть проекты и побольше, где уже выгоднее брать профессионалов.
(релизить части системы по-отдельности)

Монорепы это хорошо.


где уже выгоднее брать профессионалов.

А вот сейчас обидно было.

Монорепы это хорошо.
Как вы одновременно обновляете бекенд и iOS приложение, с учетом того, что требуется апрув приложения?

А вот сейчас обидно было.
Почему? Если проекты сравнимого качества, а два человека сравнимой обучаемости, то профессионалом будет тот, кто углубился в своей области, а не кто везде понемногу пробует. Так что почему обидно?
Как вы одновременно обновляете бекенд и iOS приложение

зачем одновеменно? нужно же независимо


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

Мне не нравится что вы смешиваете понятие "обучаемость", "узкой специализации" и "профессионализм". Я понимаю что имелось ввиду, но категорически не согласен с формулировкой.


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


Только не стоит забывать что большая часть знаний и опыта из одной сферы прекрасно ложится на другую. Что делает все чуть сложнее.

Никто не запрещает и не мешает вам релизить части системы по отдельности из одного большого репа. С другой стороны гораздо проще провести большой релиз бэкенда и клиента одновременно.
> может делать и фронт и бек

Не в этом идея, а в полном отделении провайдеров данных от UI компонентов. Уж извините, но все эти виджеты из yii морально устарели, плохо скейлятся и я не вижу никакого смысла их использовать в 2018-ом году. Почти все эти компоненты доступны независимо под любой UI фреймворк.

Что до отдельных репозиториев — у меня вот монореп, где лежат рядом и бэк, и фронт, и андроид и ios. И нет никаких проблем, и удобно, и все такое. И фулстэк не фулстэк — проблема yii в том что php файлики влияют на отображение js компонентов и вообще отвечают за рэндринг. Фу.
Спасибо за подборку! Очень жаль, что новостей по Yii2 нет уже второй выпуск подряд.
Спасибо за дайджест!

mougrim/php-xdebug-proxy — Dbgp Xdebug прокси. Подробнее об использовании прокси можно почитать тут. Прислал mougrim.

От себя добавлю, инструмент написан на php и расширяем, что позволяет вносить правки на знакомом языке.
Из любопытного, под капотом асинхронный фреймворк amphp.
CodeIgniter 4.0.0 alpha1

Интересно насколько реально актуальна и востребована его разработка в 2018 году? Или ей занимаются энтузиасты, исходя из каких то ностальгических соображений?
ностальгических соображений?

религиозных.


На самом деле конкуренция никому не повредит, но вот делать тоже самое что было и раньше — плохая инвестиция как по мне.

Не вижу я тут предпосылок для конкуренции.
Если они будут разрабатывать продукт в соответствии с идеями оригинального codeigniter(насколько я помню максимальнго успеха вторая версия добилась), то боюсь, что ударятся в то, что прогресс за упущенный период времени сделал некотоыре шаги вперёд.
А если это будет очередная компоновка компонентов симфони с каким то сахаром, под именем популярного в прошлом бренда то… смысл менять кому-то шило на мыло?
Своя аудитория всё равно найдётся. Ну и в конечном счёте, где гарантия, что их «сахар»
не повляет на дальнейшее развития событий?)
Пускай развиваются, мало ли ещё чем-то удивят в будущем. Или нет (но это будет уже другая история). Так или иначе, сахар над симфони компонентами может быть весьма популярным ;)
Only those users with full accounts are able to leave comments. Log in, please.