Comments 42
А что если к велосипеду прицепить кабину? Будет же как автомобиль
Круто блин, хайп вокруг ноды и хайп вокруг ларавела встретились.
Ну да, хипстеры, которым нравится и то и то будут довольны, а больше и не надо ничего.
Ну да, хипстеры, которым нравится и то и то будут довольны, а больше и не надо ничего.
большой программный коллайдер сталкивает частицы сверхвысоких энергий
UFO just landed and posted this here
Ой, не буду холиварить, а то прибегут хомячки Тейлора, ну нафиг.
В двух словах из хорошего фреймворка выкинули сложные для изучения компоненты и заменили кривыми поделками, а потом еще развели хайпа.
В двух словах из хорошего фреймворка выкинули сложные для изучения компоненты и заменили кривыми поделками, а потом еще развели хайпа.
Да, но писать по всем Enterprise паттернам простые и средние приложения на фреймворке который нельзя называть Symfony — вам не кажется оверхедом? У каждого инструмента своя ниша и пустоту, которая была в мире PHP занял тот фреймворк — который больше подходил большинству разработчиков. Не больше не меньше. Не нужно фанатеть — это в корне разные инструменты для разного уровня задач.
Ну все, началось.
Оверхед на компонентном фреймворке, на котором есть minimal edition? Или под оверхедом вы подразумеваете использование библиотек? Или то что для простой задачи не придумывают простой велосипед, если уже есть решение которое справляется и с простой и со сложной задачей?
Давайте не будем про нишу фреймворков в пхп, где их как собак не резаных, и вот чего, а пустоты нам нету уже давно, сейчас тут такой-же ужас как в ноде, где тоже не знаешь что выбрать.
Не нужно вам фанатеть по поводу ларавеля, раз уж не понимаете что это обычный хайп. Обычный средний фреймворк, со своими поделками и косяками. Какие у него плюсы простите, из-за которых он вдруг стал резко подходить большинству разработчиков?
Оверхед на компонентном фреймворке, на котором есть minimal edition? Или под оверхедом вы подразумеваете использование библиотек? Или то что для простой задачи не придумывают простой велосипед, если уже есть решение которое справляется и с простой и со сложной задачей?
Давайте не будем про нишу фреймворков в пхп, где их как собак не резаных, и вот чего, а пустоты нам нету уже давно, сейчас тут такой-же ужас как в ноде, где тоже не знаешь что выбрать.
Не нужно вам фанатеть по поводу ларавеля, раз уж не понимаете что это обычный хайп. Обычный средний фреймворк, со своими поделками и косяками. Какие у него плюсы простите, из-за которых он вдруг стал резко подходить большинству разработчиков?
пустоту, которая была в мире PHP занял тот фреймворк
Даже интересно, где это такая пустота которую вдруг заполнил ларавел?
UFO just landed and posted this here
UFO just landed and posted this here
Интересно, сколько же лет должно пройти, чтобы Node.js непременно не ассоциировалась с этими "хипстерами"
UFO just landed and posted this here
Вопрос не в «сколько лет», а в зрелости технологии…
Почти, только еще добавлю что не за новинками, а за разрекламированными вещами, причем бездумно, используя вешь потому что она популярна. Как бы ничего в новинке плохого нет, если нормальная штука, а вот если вокруг проекта поднялся хайп, то это повод на него обратить внимание и разобрать, может и норм, а не бросаться на нем в продакшен сразу, потому что может и г.
UFO just landed and posted this here
[facepalm.jpg]
Мы против изпользования всякого г только потому что это разрекламированная шняга.
Ларавел это пример разрекламированной шняги, у которой есть куча недостатков и почти нету преймуществ, но вокруг которой развели хайп.
Какие у него плюсы простите, из-за которых он вдруг стал таким замечательным?
Мы против изпользования всякого г только потому что это разрекламированная шняга.
Ларавел это пример разрекламированной шняги, у которой есть куча недостатков и почти нету преймуществ, но вокруг которой развели хайп.
Какие у него плюсы простите, из-за которых он вдруг стал таким замечательным?
Ну раз стал таким популярным, значит свои плюсы определенно есть. Странно это отрицать
Просто что бы начать им пользоваться почти ничего из ООП знать и не надо да как и самим PHP в принципе, отсюда популярность исходящая из банальной простоты. Если взять допустим программистов на Laravel и дать им Symfony, я думаю большинство просто не разберется (само собой с доступом к документации) как Bundle правильно сконфигурировать, написать CompilerPass, Форму создать, сделать фабрику, DataMapper и чистые модели без магии? Нормальный шаблонизатор, хотя бы Twig? Зачем, сделаем свой неполноценный Blade потому что опять нужна была сверх простота для создания расширений потому что люди не хотят разбираться в сложных библиотеках (фильтр или функцию в Twig объяявить проще простого, свои токены уже посложнее). Зачем, есть же Laravel! ООП неотъемлемая часть например в Symfony, Zend, в Laravel это все на втором плане т.к людям трудно в этом разобраться а делать сайты нужно уже сейчас! Тут уже упоминали что каких то супер преимуществ у Laravel нет, так и есть, кроме того что все проще простого (от сюда куча гемороя в сложных проектах). Проработал год над проектом не связанным с созданием простого блога на PHP, больше никогда такие проекты на Laravel делать не буду, only Symfony! Laravel вполне подходит для простых сайтов и каких нибудь средних монолитов, ИМХО. Просто те кто пишут на Larvael наверно еще не делали таких проектов где могут проявится его слабости и минусы, потому они и кричат что Laravel лучший + пиар :)) Все решает опыт разработчика, я бы даже визитку или блог делал на Symfony + MikroKernel, получаем все преимущества платформы + легковесность и возможность в будущем легко расширять свой блог без геморроя.
Ну, я бы сказал, что контейнер в Symfony — вещь не из простых. В Laravel гораздо проще его настроить. А Twig при желании можно и к Laravel прикрутить, с этим проблем нет. Что касается Blade, не считаю его ущербным)
А в чем был геморрой, связанный с Laravel?
Ну вобщем да, с контейнером еще можно жить, тут не спорю. Хотя на уровне ларавеля симфонийский контейнер не сложнее.
Blade некорректно обрабатывает include — в нем нельзя изолировать контекст
как пример — попробуйте в цикле вставить шаблон с переопределенными секциями.
Основной геморрой был с фасадами и с orm.
Blade некорректно обрабатывает include — в нем нельзя изолировать контекст
как пример — попробуйте в цикле вставить шаблон с переопределенными секциями.
Основной геморрой был с фасадами и с orm.
franzose согласен на первый взгляд кажется сложно, но только на первый (все новое всегда кажется сложным). Вот вы можете привести конкретный пример сложности в контейнере Symfony или его понимания? Просто единственное что может показаться сложным на мой взгляд это описание структуры конфига (config.yml) через DI Configuration. И опять же, это только на первый взгляд. Все возможные и не возможные примеры описания структуры конфига есть в бандлах для Symfony (у каждого бандла есть Acme\DemoBundle\DependencyInjection\Configuration), нужно просто чуть чуть почитать документацию и залезть внутрь. Сложно говорите? Возьмите PhpStorm + Symfony plugin + конфиги сервисов в XML, вы получаете полноценный автокомплит по всем сервисам и параметрам контейнера в любом месте в вашем проекте! Даже есть в контекстном меню создать services.(xml|yml) за вас! IDE делает половину работы за вас.
Что касается Blade, просто примитивный шаблонизатор. Никаких преимуществ, очередной свой велосипед, почему было не взять Twig, хотя бы Smarty? Многие дизайнеры с ним знакомы, он удобный и легко расширяем, проверен временем!!! Вопрос зачем? Я отвечу, никто не хочет разбираться как добавить какой то там Twig_Extension, можно ведь просто сделать в любом месте приложения (конечно нужно как минимум в ServiceContainer) Blade::extend() и получаем какой то простенький тег. Blade просто не умеет крутых штук, например множественное наследование на сколько знаю там хреново работает, получить весь контент предыдущих блоков не возможно (могу ошибаться, давно не проверял). Blade это просто красивая обертка для использования
внутри шаблонов, ведь вы спокойно можете внутри Blade {{… }} вызвать любую PHP функцию или исполнить код. Какой это к черту шаблонизатор? PHP сам по себе изначально шаблонизатор, так чем Blade лучше? Согласен на примитивных задачах вполне подойдет, но я более чем уверен вы не разделяете логику и отображение нормально используя Blade. Вспомнил, там не нет даже тега {% spaceless.%}. Я всегда ставил Twig вместо Blade если была возможность.
Да при желании вообще то к Larvael можно любой компонент или библиотеку прикрутить. Doctrine, Twig, FormBuilder, Yaml есть как пакет для Laravel. Можно запустить Laravel внутри Symfony (есть готовый Bundle), можно запустить Symfony внутри Laravel. Я даже хотел прикрутить Symfony Container в Laravel и настроить двухстороннюю связь между ними и вы не поверите получилось!!! Даже дошел до того что можно использовать любой бандл Symfony внутри Laravel, использовать его сервисы внутри Laravel как будто они зарегистрированы в его контейнере (ну допустим serializer или annotaion_reader). И знаете что? Я просто начал использовать Symfony :)
Геморрой был связан:
1. Для Api есть пакет DingoApi. Как только мы регистрируем провайдер для всего приложения он тупо перезаписывает стандартный ExceptionHandler который будет выводить ошибки как JSON ответ. Уже нужны какие то хаки что бы провайдер подключался только на определенный путь. Т.е в ServiceProvider что то вроде:
Использование Request для определения необходимости подключения провайдера это уже какой то хак, можно конечно в на стороне веб сервера сделать ENV_VAR если путь начинается с /api/ и потом проверять по этому флагу, но по сути какая разница как, какие то хаки начинаются сразу. И да, если мы не подключаем DingoApiServiceProvider на все приложение, а где то в приложении вне /api/ используется что то из пакета DingoApi мы получаем ошибку.
Symfony Serializer в сто раз удобней чем Transformer'ы в DingoApi, тут просто стоит попробовать и все понять самому :)
2. ORM. Да она простая и для блога катит, но это тяжелейший класс который тянет за собой каждая модель. Допустим вам нужно добавить 1000 новых записей, вам что бы использовать их в связях с другими моделями нужно внимание сделать save() на каждой сущности (конечно можем обернуть в транзакцию и все же это не то что предоставляет нам Doctrine, делаем persist() и когда надо flush() при этом спокойно работаем с моделями как будто они в базе...).
Во вторых, честно говоря уже не помню в чем именно было дело, но когда мы пытаемся сделать Translatable, Softdeletebale, Metable и еще что нибудь в одной модели это начинается ПРОСТО АД потому что они жуть как мешают друг другу, все завязаны на события внутри одной модели и т.д, в общем жуть. Конечно если вам надо просто вытащить или положить данные в базу несколько строк вполне подойдет :)
3. Всякие мелочи которые решались каким то костылями потому что иначе никак. И все это вытекает из максимального упрощения кода и архитектуры, он просто не всегда расширяем.
В общем суть в том что сторонние пакеты иногда начинают мешать работе в местах где до них все было хорошо, хотя они не должны этого делать.
Что бы собрать вместе все пакеты которые нужны для крупного проекта придется доставать бубен и плясать. Можно и самому написать все пакеты, так может сразу еще один свой фреймворк? :)
Что касается Blade, просто примитивный шаблонизатор. Никаких преимуществ, очередной свой велосипед, почему было не взять Twig, хотя бы Smarty? Многие дизайнеры с ним знакомы, он удобный и легко расширяем, проверен временем!!! Вопрос зачем? Я отвечу, никто не хочет разбираться как добавить какой то там Twig_Extension, можно ведь просто сделать в любом месте приложения (конечно нужно как минимум в ServiceContainer) Blade::extend() и получаем какой то простенький тег. Blade просто не умеет крутых штук, например множественное наследование на сколько знаю там хреново работает, получить весь контент предыдущих блоков не возможно (могу ошибаться, давно не проверял). Blade это просто красивая обертка для использования
<?php echo ... ?>
внутри шаблонов, ведь вы спокойно можете внутри Blade {{… }} вызвать любую PHP функцию или исполнить код. Какой это к черту шаблонизатор? PHP сам по себе изначально шаблонизатор, так чем Blade лучше? Согласен на примитивных задачах вполне подойдет, но я более чем уверен вы не разделяете логику и отображение нормально используя Blade. Вспомнил, там не нет даже тега {% spaceless.%}. Я всегда ставил Twig вместо Blade если была возможность.
Да при желании вообще то к Larvael можно любой компонент или библиотеку прикрутить. Doctrine, Twig, FormBuilder, Yaml есть как пакет для Laravel. Можно запустить Laravel внутри Symfony (есть готовый Bundle), можно запустить Symfony внутри Laravel. Я даже хотел прикрутить Symfony Container в Laravel и настроить двухстороннюю связь между ними и вы не поверите получилось!!! Даже дошел до того что можно использовать любой бандл Symfony внутри Laravel, использовать его сервисы внутри Laravel как будто они зарегистрированы в его контейнере (ну допустим serializer или annotaion_reader). И знаете что? Я просто начал использовать Symfony :)
Геморрой был связан:
1. Для Api есть пакет DingoApi. Как только мы регистрируем провайдер для всего приложения он тупо перезаписывает стандартный ExceptionHandler который будет выводить ошибки как JSON ответ. Уже нужны какие то хаки что бы провайдер подключался только на определенный путь. Т.е в ServiceProvider что то вроде:
if (Str::startsWith(Request::path(), 'api')) {
$this->app->reg.....
}
Использование Request для определения необходимости подключения провайдера это уже какой то хак, можно конечно в на стороне веб сервера сделать ENV_VAR если путь начинается с /api/ и потом проверять по этому флагу, но по сути какая разница как, какие то хаки начинаются сразу. И да, если мы не подключаем DingoApiServiceProvider на все приложение, а где то в приложении вне /api/ используется что то из пакета DingoApi мы получаем ошибку.
Symfony Serializer в сто раз удобней чем Transformer'ы в DingoApi, тут просто стоит попробовать и все понять самому :)
2. ORM. Да она простая и для блога катит, но это тяжелейший класс который тянет за собой каждая модель. Допустим вам нужно добавить 1000 новых записей, вам что бы использовать их в связях с другими моделями нужно внимание сделать save() на каждой сущности (конечно можем обернуть в транзакцию и все же это не то что предоставляет нам Doctrine, делаем persist() и когда надо flush() при этом спокойно работаем с моделями как будто они в базе...).
Во вторых, честно говоря уже не помню в чем именно было дело, но когда мы пытаемся сделать Translatable, Softdeletebale, Metable и еще что нибудь в одной модели это начинается ПРОСТО АД потому что они жуть как мешают друг другу, все завязаны на события внутри одной модели и т.д, в общем жуть. Конечно если вам надо просто вытащить или положить данные в базу несколько строк вполне подойдет :)
3. Всякие мелочи которые решались каким то костылями потому что иначе никак. И все это вытекает из максимального упрощения кода и архитектуры, он просто не всегда расширяем.
В общем суть в том что сторонние пакеты иногда начинают мешать работе в местах где до них все было хорошо, хотя они не должны этого делать.
Что бы собрать вместе все пакеты которые нужны для крупного проекта придется доставать бубен и плясать. Можно и самому написать все пакеты, так может сразу еще один свой фреймворк? :)
Не холивара ради интересуюсь.
Чем по вашему мнению плох ларавел?
Пс он же вроде не такой уж и новый
Тем что это простое решение для написания бложиков. Просто когда у вас бложик то вам вообще пофигу на чем писать. Как правильно заметил wendel в комментарии выше — сделаем свои неполноценные замены, чтобы только как можно проще для бложика.
Год поработал с большим проектом на ларавеле — больше никогда не буду связываться.
Почему многие кричат что ларавель лучше? Потому что эти многие клепают мелкие сайтики и просто не работали с крупным проектом, уровень среднего разработчика ларавеля — джуниор, уровень среднего разработчика симфони — он сам ларавель написать может, плюс еще разработчики ларавеля сравнивают свою икону со всякими вордпресами и кодеигнайтерами, разумеется он лучше их, все-таки не до конца испортили симфони.
Еще такая забавная вещь — в ларавеле по сути два типа модулей/компонентов либо своя кривая поделка (элоквент, конфиг, blade) либо прибитый гвоздями компонент симфони (или либа) обернутый в самый базовый вариант использования (роутер, реквест, консольные команды)
Год поработал с большим проектом на ларавеле — больше никогда не буду связываться.
Почему многие кричат что ларавель лучше? Потому что эти многие клепают мелкие сайтики и просто не работали с крупным проектом, уровень среднего разработчика ларавеля — джуниор, уровень среднего разработчика симфони — он сам ларавель написать может, плюс еще разработчики ларавеля сравнивают свою икону со всякими вордпресами и кодеигнайтерами, разумеется он лучше их, все-таки не до конца испортили симфони.
Еще такая забавная вещь — в ларавеле по сути два типа модулей/компонентов либо своя кривая поделка (элоквент, конфиг, blade) либо прибитый гвоздями компонент симфони (или либа) обернутый в самый базовый вариант использования (роутер, реквест, консольные команды)
Вы не конструктивно критикуете, а эмоционально. Хотелось бы о конкретных слабостях Laravel услышать, по вашему мнению.
franzose, в целом плюсую, это выглядит как-то так «Все что не Симфони — плохо». Хотелось увидеть нечто иное. И да, ларавел действительно прост, но я не уверен что это его минус. Тем не менееiborzenkov спасибо вам за вашу критику)
Я не говорю что «Все что не Симфони — плохо», я говорю что плохо брать компоненты мощного фреймворка и прикручивать их как в ларавеле. Разумеется я буду сравнивать ларавел с симфони потому что половина его компонентов это обертки над компонентами симфони, причем такие что до сложного функционала не добраться. И критики было бы меньше, если бы просто ларавел взял компоненты симфони и нормально их использовал не создавая такие обертки.
Ларавел прост и это его огромный минус на хоть сколько больших проектах, просто на том что пишет 90% фанатов ларавела этот минус не заметен. Это именно та простота что выкинем функционал потому что для простых сайтов он не особо нужен.
Вобщем если вы не планируете писать крупный проект, а уверены что будете делать сайты пачками в веб студии, то да, ларавел вам подойдет.
Вот еще пачка минусов
1) Очень слабая ORM — это свалка — в одной только model находится сама модель, выборки коллекций, построитель запросов, менеджер коннекшенов, работа с событиями, сериализация.
Причем все это сделано так, что ломает автокомплит и вводит слишком много магии — всякие where(), scope, туда же еще прикрутили таймштамы и softDelete.
2) blade — это по сути смарти — постая замена тегов на php в файле, больше ничего нету, да, для начала 2000-х было нормально, сейчас уже есть нормальные шаблонизаторы
3) разработчик берет компоненты симфони и пишет для них свои обертки, причем только для самого базового использования — например роутер — только один вариант использования — через php в одном файле объявить сразу весь, причем под капотом используется симфоневый, который поддерживает разные форматы ресурсов, и достаточно мощный
4) Фасады — кривейший паттерн, ломает нафиг автокомплит и работать хоть как-то можно с костылями ide_helper — при этом хомячки кричат что это не синглетон и можно подменять — какое блин счастье, подменять можно, а все другие минусы забыли — по сути это очень криво реализованный контейнер, в котором нужно прописывать каждый объект отдельным фасадом.
Согласен, если в фирме сидят студенты, то начать на ларавеле будет проще, только нужно понимать это и не пытаться писать на нем большие проекты.
Ларавел прост и это его огромный минус на хоть сколько больших проектах, просто на том что пишет 90% фанатов ларавела этот минус не заметен. Это именно та простота что выкинем функционал потому что для простых сайтов он не особо нужен.
Вобщем если вы не планируете писать крупный проект, а уверены что будете делать сайты пачками в веб студии, то да, ларавел вам подойдет.
Вот еще пачка минусов
1) Очень слабая ORM — это свалка — в одной только model находится сама модель, выборки коллекций, построитель запросов, менеджер коннекшенов, работа с событиями, сериализация.
Причем все это сделано так, что ломает автокомплит и вводит слишком много магии — всякие where(), scope, туда же еще прикрутили таймштамы и softDelete.
2) blade — это по сути смарти — постая замена тегов на php в файле, больше ничего нету, да, для начала 2000-х было нормально, сейчас уже есть нормальные шаблонизаторы
3) разработчик берет компоненты симфони и пишет для них свои обертки, причем только для самого базового использования — например роутер — только один вариант использования — через php в одном файле объявить сразу весь, причем под капотом используется симфоневый, который поддерживает разные форматы ресурсов, и достаточно мощный
4) Фасады — кривейший паттерн, ломает нафиг автокомплит и работать хоть как-то можно с костылями ide_helper — при этом хомячки кричат что это не синглетон и можно подменять — какое блин счастье, подменять можно, а все другие минусы забыли — по сути это очень криво реализованный контейнер, в котором нужно прописывать каждый объект отдельным фасадом.
Согласен, если в фирме сидят студенты, то начать на ларавеле будет проще, только нужно понимать это и не пытаться писать на нем большие проекты.
1) Никто и не скрывает, что Eloquent реализует шаблон ActiveRecord.
Это и есть объединение слоя бизнес-логики и слоя работы с БД. Применяется такой шаблон преимущественно в целях RAD.
Doctrine же реализует шаблон DataMapper, UnitOfWork и многое другое, что очень полезно для Domain Driven Development. Но, думаю, Вы согласитесь что для проектов малого и среднего уровня это просто из пушки по воробьям.
2) Я сталкивался с некоторыми проблемами в Blade (в Laravel 4), связанными в основном с наследованием и подключением файлов. Но в целом он достаточно удобен.
Цель — сделать синтаксис шаблонов более читаемым по сравнению со стандартным PHP (по-сути синтаксический сахар).
Кроме того, в Blade вы можете сразу вызывать любой PHP код используя тот же самый синтаксис, в отличие от Twig, который заставляет добавлять собственные функции/конструкции, если требуется что-то новое.
Причина такого подхода, опять же, указана в первом пункте (RAD).
3) То что Laravel базируется на некоторых компонентах Symfony, говорит лишь о том, что эти компоненты написаны хорошо и грех их не использовать, для того чтобы написать более простую и удобную обертку.
4) Фасады в Laravel — точно такой же синтаксический сахар для разработчика, как и шаблонизатор Blade. Исторически в PHP разработчики привыкли использовать статические классы, потому что этот подход был реализован во многих фреймворках, но используя этот подход приложение тяжело тестировать.
Таким образом, фасады — это просто "палочка выручалочка", когда хочется статических классов и при этом нужно писать тесты. Количество кода при использовании таких фасадов немного сокращается.
Кроме того, никто не заставляет использовать фасады — все можно решить через контейнер сервисов. Например в Lumen фасады по-умолчанию отключены.
В заключении можно сказать что Laravel — это developer-centric фреймворк (именно так) в котором огромное внимание уделяется красоте и лаконичности кода, удобству использования, а также скорости написания приложений.
Поэтому, ИМХО, Laravel'у быть, и никакой это не "хайп", в отличие, например, от Angular 1, который Google поматросил и бросил.
Собственно, даже само описание фреймворка очень емко и лаконично описывает его суть:
Laravel — The PHP framework for web artisans
Поэтому рекомендую Вам поближе ознакомиться с этими принципами и использовать их по назначению.
Если большой проект, реально большой, аля фейсбук или гугл. То лучше уж писать не на фреймворке, а с нуля условно говоря свой фреймворк.
Ну ладно гироскутеры, ладно смузи, но бороды то за что?
Да вот только node.js и laravel уже давно не новинки, а зрелые и устоявшиеся технологии… ну по меркам веба.
А приложений с их помощью написано много по любым меркам.
А не позволите поинтересоваться а чем так плох laravel? Может статьи есть какие на эту тему?
П.С. Просто сейчас присматриваюсь к миру разработки после долгого перерыва.
П.С. Просто сейчас присматриваюсь к миру разработки после долгого перерыва.
Нынче модны только те фреймворки, которые от корпораций. У них есть средства хайп поднять, и все дружным хороводом идут за ними, даже если это полное ггг.
осталось теперь переписать с генераторов на родные с v7.6 async / await.
Порт Yii на js помёр, надеюсь с этимм портом будет другая учесть
Недавно наткнулся на аналогичный фреймворк для ноды, только в духе Symfony: nodefony
Несмотря на то что php активно развивается, js во многом обогнал его. Достаточно взглянуть на фронтенд и его фреймворки. Один VueJS чего стоит.
Голословное утверждение.
Высокая производительность
Я провел несколько своих маленьких тестов, и NodeJS их все выиграл.
Опять мимо. Какого рода тесты? Может быть это узконаправленные тесты чтобы показать превосходство NodeJS
Sign up to leave a comment.
NodeJS фреймворк с синтаксисом Laravel (и без лапши в коде)