65536

Когда я решил попробовать себя в этой сфере, я накидал себе план обучения. Что то типа html > css > js > php. Ну разумеется для начала общие сведения обо всем этом. Так как вообще не понимал что и для чего. Потом много смотрел видео уроков и сам тренеровался. Научился делать (как мне тогда казалось) интернет магазин и пошел устраиваться на работу. Взяли стажером и оказалось что я очень мало знаю. Мало из того что я учил мне пригодилось. На практике все оказалось немного иначе. Я проработал там пол года, затем ушел в другую компанию (более крупную) с мыслью "ну теперь то я кое что могу). И придя на новое место снова оказалось что я совсем новичок. так как инструменты которые тут использовались были другими. Я менял еще несколько мест, каждый раз находя более профессиональный коллектив. И каждый раз узнавал много нового. Я к тому что самый лучший способ научиться делать хорошо - работать с теми, кто лучше вас. Это конечно может быть сложно, но это будет в десятки раз продуктивнее, чем развиваться самому.

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

Потому что с <? много проблем. Рендринг XML документов (да, бывает и такое), еще какие-нибудь вещи, конфликты и т.д. По этой причине по умолчанию оно выключено в php.ini. И по этой причине в стандарте прописано вообще не использовать оный тег.

Тем, что там можно писать мало там, где мы привыкли писать много. Подобный "конвеншн овер конфигурейшн" - он помимо прочего оставляет ощущение, что автор пишет не сферическую вещь в вакууме, которая якобы должна подойти всем, а для нас, для простых рабочих пацанов с окраин, со своими вполне конкретными юзкейсами. Т.е. он 1. человек умный и 2. знает жизнь. Это подкупает.

Например, в output идет то, что возвращено из контроллера, а если возвратить ORM-объект или массив (точнее коллекцию) ORM-объектов, то будет отдан json, причем со всеми связанными объектами. Масса нужных в хозяйстве вещей, которые идут из коробки (миграции, редис, кэш с множеством провайдеров, работа с очередями, консольная тулза artisan для разнообразных обслуживающих вещей). Изкоробочная работающая сборка вьюх в лейаут, минимум возни с авторизацией. Скоупы в ORM. Кусочки конфигов в файлах, которые удобно ставить в .gitignore. В общем, масса такого вот, мелкого, но очень удобного.

На Laravel ОДНОВРЕМЕННО можно уйти в глубины аццкого хадкора по Фаулеру, с тестированием всего и вся, с интерфейсами, депенденси инжекшнами, репозиториями, обсерверами, ентитями, гексагональными сценариями итд, итп, _подставить_любимый_паттерн_, И в то же время забить на это всё, сгенерить _ide_helper для подсказок по "фасадам" в IDE и фигачить код со статическими вызовами, как будто весь фреймворк написан на статике, как Кохана. Т.е. и сайт-знакомому-за-вечер и огроменный кровавый энтерпрайз делаются на одном фреймворке - в зависимости от того, насколько глубоко исполнитель хочет погружаться в свой продукт. Подобная гибкость - это, имхо, очень круто.

И еще - как показала практика фреймворкостроительства, или ты двигаешься вместе с развитием php, либо ты делаешь "более лучшее, удобное и грамотное" решение и тихо загниваешь с своем междусобойчике за пару лет. Laravel двигается максимально близко к php - следование psr, composer-платформа в качестве базы, фрейморк ставится оттуда и пакеты расширения тоже имеют composer-формат. Что говорит о том, что у фреймворка есть все шансы прожить долгую и счастливую жизнь.