Хорошая очень штука Vuetify. Очень много компонентов, удобно делать полноценное веб-приложение. Есть проблемы со встроенной версткой правда, кастомизировать сложно, но если к дизайну приложения придирок особых нет, то быстро и удобно. На Ларе, кстати, собирается на раз два mix'ом
Потому что если сравнивать. То возможности самих фреймов. А если говорить о различных надстройках, то вообще можно придти к выводу что все имеют одинаковые возможности с разной реализацией просто.
Мейкер был. А вот вебпака вроде не было, до недавних пор. Может я ошибаюсь, но это все равно не то. Мейкер тут точно такой же как в Ларавел, точнее в Ларавел он заимствован из симфони скорее всего. А вебпак все равно надо настраивать, как с миксами легко не получится. Но это не в минус, это как раз больше к свободе действий.
Не поймите меня не правильно. Симфони я очень уважаю. Но для типовых проектов, которые мне приходилось делать быстрее сделать на Ларе или Юии. Симфони лучше подходит для планирования хорошей архитектуры и мощных нагруженных проектов. Для толстых проектов, совмещающих в себе кучу мелких, я бы бесспорно выбрал Симфони. А если писать что-то типа Алибабы, Ебэя или Что-то еще более крупное. Лучше вообще избегать фреймворков, поскольку тут очень важно продумать свою разумную архитектуру, чего не делает один человек. Не думаю что Гугл или Яндекс пишут на каких-то фреймворках, скорее разрабатывают свои. Но это лично мое мнение
Разговор про с коробки! Доставить можно все что угодно. И в Симфони правильно делают что не ставят в коробку. В последней версии вообще много чего выпилили с того, что было раньше, все можно поставить, но отдельно, и по мере надобности. Мне нравится такой подход. Но разговор шёл про «из коробки». Здесь не о чем спорить. Для многих типовых решений есть куча отдельных библиотек написанным самими SensioLab и сторонние решения.
Это совсем не то, что делает Yii. Этот генерирует только php файлы с классами, а у Yii это и модели и контроллеры сразу с данными и готовое сверстанное представление
Приведу пример. В Симфони есть генератор готовых интерфейсов? Встроенный удобный сборщик фронтенда как у Ларавел? Помельче: хелперы для работы с конфигами, или какими-то данными. А интерфейсы для данных — это вполне типовая задача.
Да это понятно. Так в любом решении, можно любой пакет заменить на другой или собрать по частям. Речь о работе из коробки, без лишних заморочек и для типовых задач. Когда человек выбирает фреймворк, на котором он будет учиться писать, он не собирается делать Highload проекты и пересобирать фреймворк. До этого еще дойти надо!
Ай, ну как же не понять то. Низкоуровневый — не значит хуже или что то невозможно реализовать или чего-то не предоставляет. Низкоуровневый язык программирования означает, что ты можешь работать с данными не на уровне объектов и чисел и строк, а на уровне дампов памяти, битов, положения битов в кластере и тому подобные вещи. В аналогии с фреймворками я имел ввиду, что для Симфони ты будешь больше писать ручками, для осуществления каких-то типовых задач, которые в свою очередь в Ларе и Юии имеют готовые решения.
С первой страницы официального сайта симфони. Означает, что используются не компоненты, а именно фремворк. А Вот Yii использует именно компоненты.
А низкоуровневый — это как аналогия языков программирования. Типа PHP, JAVA, PYTHON языки высокого уровня, а C, C++ или Асемблер низкоуровневые языки. Тут дело в доступности данных низкого уровня (дампы или ячейки памяти, отдельные биты в кластерах), а не в том, как роуты задаются
Сложно сказать. Может я не знаю, но способ получить подключение к базе можно так же через сервис локацию
$connection=Yii::app()->db;
Но это как раз через фасады, которые в конфиге задаются. Либо расширением класса ActiveRecord, чем и являются модели. Тут просто не доктрина, поэтому сложно провести аналогию, принцип немного другой.
А в той же ларе или симфони, можно получить низкоуровневый объект PDO
Я не совсем об этом речь вел. Модели я чисто для примера взял. В Ларе например и в роутах используются методы Route::post(/***/), которые по факту не являются статичными. Я в общем о том, что такие явления есть
Ха, про выстрел в ногу точняк. Это даже с виджетами для фронта можно соеденить. Соберешь фронт себе на бек и будешь сам его потом палкой ковырять, а когда проект разрастется и потребуется разделить обязанности, будут большие сложности, вот это и есть выстрел себе в ногу, поэтому я и назвал это и минусом и плюсом
Безспорно. Можно и свои расширения с виджетами написать и тем же функционалом и юзать например bulma вместо бутстрапа. Но речь то о том, что у него встроенно из коробки, а не установлено из вне.
Спасибо за комментарий. Я не видел смысла вдаваться в дебри смысла работы фасадов, скорее это предупреждение, что придется с этим столкнуться, поскольку ни в Yii2 ни в Symfony этого нет. Но то, что вы описали в комментарии — очень хорошо. Спасибо за дополнение!
Я бы сказал наоборот, в плане архитектуры — не очень много позволяет. Если это про расположения файлов в проекте. Тут с Ларой они одинаковы. Симфони самый развязанный в плане архитектуры. А по поводу QueryBuilder'a скажу, что чистый доктриновский да, немного сложноватый, за счет непривычности описания в аннотациях, но в Ларе например он переорганизован и ничем не хуже Yii-шного, даже немного похож, поэтому их я даже не сравнивал
При использовании компонетной системы Vue и сборки с помощью «Сборщиков» (например webpack), как на jquery работать не получится. Но в целом, вы правы. Если подключить его как облачное, и выводить переменные в глобальную область видимости, для переброса между компонентами, так и будет как в jQuery. Даже парочка примеров есть, которые я встречал на некоторых сайтов
Чувак, ты вроде бы понял, но как то не полностью. Да, я действительно backend — разработчик, которому время от времени приходится разбираться с фронтендом. И эта статья не призыв к действию или методика разработки. Я лишь пишу, с чем было сложно разобраться, мне как бекендщику, ибо таких как я довольно много. Если ты без проблем все понял, и прочитав две страницы официальной доки, флаг тебе и респект, но извини, фронт требует немного другого подхода и склада мысли, нежели бэк. Не для тебя просто эта статья, а унижать собрата своего по коду — это как минимум не вежливо. Не нравится статья, хорошо! Критика это всегда хорошо. Но вот про школьные каникулы и прочую лабуду — это пожалуй сильно лишнее. Да в ней нет много чего, про взаимодействие компонентов, но это и не тема данной статьи. Все в одну не упихаешь. У меня не было сложности разобраться с обратным обменом, от дочернего компонента, к родительскому, поэтому об этом я не писал, там сложного ничего нет, когда понимается сама суть работы либры, остальное не сложно понимается! За критику спасибо, но вот с излишествами не стоит!
Потому что если сравнивать. То возможности самих фреймов. А если говорить о различных надстройках, то вообще можно придти к выводу что все имеют одинаковые возможности с разной реализацией просто.
Не поймите меня не правильно. Симфони я очень уважаю. Но для типовых проектов, которые мне приходилось делать быстрее сделать на Ларе или Юии. Симфони лучше подходит для планирования хорошей архитектуры и мощных нагруженных проектов. Для толстых проектов, совмещающих в себе кучу мелких, я бы бесспорно выбрал Симфони. А если писать что-то типа Алибабы, Ебэя или Что-то еще более крупное. Лучше вообще избегать фреймворков, поскольку тут очень важно продумать свою разумную архитектуру, чего не делает один человек. Не думаю что Гугл или Яндекс пишут на каких-то фреймворках, скорее разрабатывают свои. Но это лично мое мнение
Это совсем не то, что делает Yii. Этот генерирует только php файлы с классами, а у Yii это и модели и контроллеры сразу с данными и готовое сверстанное представление
С первой страницы официального сайта симфони. Означает, что используются не компоненты, а именно фремворк. А Вот Yii использует именно компоненты.
А низкоуровневый — это как аналогия языков программирования. Типа PHP, JAVA, PYTHON языки высокого уровня, а C, C++ или Асемблер низкоуровневые языки. Тут дело в доступности данных низкого уровня (дампы или ячейки памяти, отдельные биты в кластерах), а не в том, как роуты задаются
Но это как раз через фасады, которые в конфиге задаются. Либо расширением класса ActiveRecord, чем и являются модели. Тут просто не доктрина, поэтому сложно провести аналогию, принцип немного другой.
А в той же ларе или симфони, можно получить низкоуровневый объект PDO
Я не совсем об этом речь вел. Модели я чисто для примера взял. В Ларе например и в роутах используются методы Route::post(/***/), которые по факту не являются статичными. Я в общем о том, что такие явления есть