Можно ли написать сайт на php без фреймворков
Хотите улучшить этот вопрос? Обновите вопрос, чтобы он был сосредоточен только на одной проблеме, отредактировав этот пост .
Закрыто 6 лет назад .
Действительно ли фреймворки необходимы в PHP?
Каковы преимущества и недостатки его использования?
Нет, но они хороши
Плюсы : экономия времени без необходимости перестраивать код самостоятельно. Используйте множество функций, функций и структур данных, созданных кем-то другим, которые применимы к вашему проекту.
Минусы : отсутствие самостоятельной сборки кода может быть потерей при лучшем понимании, на основе которого работает ваш проект.
но проблема в том, что изо дня в день появляется множество фреймворков, которые я не знаю, какой из них использовать Выбор платформы зависит от вас, исходя из потребностей вашего приложения и вашего стиля кодирования. Также спросите себя: нужна ли вам среда для запуска собственного приложения или CMS (Joomla, Drupal и т. Д.)? Вы должны быть осторожны с "неизвестными неизвестными". Если вы не используете фреймворк, велик риск забыть или не знать о некоторых вещах, которые фреймворки решают для вас. Например, правильно ли вы боретесь с предотвращением атак CSRF? Ваше приложение будет работать без такой профилактики, но его легко взломать. Выбор основной структуры (любой из них) означает, что вы извлекаете выгоду из всего, что касается веб-приложений, даже если вы еще не узнали об этом.Фреймворки веб-приложений так же хороши, как ваш опыт работы с ними.
У каждого фреймворка есть кривая обучения, пока вы не преодолеете эту кривую, вы, вероятно, в конечном итоге будете делать вещи настолько задом наперед, что сводите на нет все преимущества использования фреймворка. Ваше приложение будет излишне медленным для разработки, будет трудно следовать коду, и все это сломается, когда выйдет новая версия фреймворка. Я бы рекомендовал не пытаться использовать незнакомую среду (или любую незнакомую технологию) для проектов с жестким сроком.
Как можно лучше использовать фреймворки?
Вам придется создать несколько ужасных приложений и выполнить итерацию. В конце концов вы поймете причуды, и использование фреймворка позволит вам сократить время разработки и лучше организовать код.
Стоит ли использовать PHP-фреймворк?
Каждый, кто кодирует достаточно PHP, в конечном итоге использует фреймворк. Вопрос в том, будете ли вы использовать свой собственный фреймворк или тот, который разработан третьей стороной? По моему опыту, вы, вероятно, никогда не разработаете свою собственную инфраструктуру, которая будет соответствовать надежности и качеству сторонней платформы. Тем не менее, разработка собственного фреймворка, кажется, является правом прохода в сообществе PHP, поэтому не позвольте мне отговорить вас от написания собственного класса абстракции базы данных.
Вот полезный график:
Ну, это действительно зависит от размера вашего проекта. Домашняя страница без базы данных и не более 10 страниц, фреймворк будет слишком много, в основном потому, что фреймворки всегда требуют большой конфигурации и настройки в большинстве случаев, чтобы соответствовать конкретным потребностям. И в некоторых ситуациях они могут быть немного медленнее, чем несколько страниц, включенных в файл (подумайте обо всех фреймворках, которые необходимо загрузить, чтобы использовать его функции.).
Теперь, если вы планируете сайт среднего / большого размера, с взаимодействиями с базой данных, веб-сервисами и т. Д., Вам понадобится инфраструктура, которая поможет вам взаимодействовать с различными технологиями и упорядочивать код таким образом, чтобы в случае поломки вы имели habilitie, чтобы быстро обнаружить и восстановить его. Кроме того, если вы думаете о клиентах, они всегда меняют свое мнение о программном обеспечении, поэтому, если клиенту нужно изменить или добавить новую функцию, вам не нужно разбираться со всем вашим кодом и думать о том, как подключить эту новую функцию ко всем это сфагетти.
Есть много других плюсов и минусов, но это те, которые впервые пришли мне в голову.
Редактировать: я использую фреймворк Symfony в повседневной работе, а также выполнил работу с php для университета (у меня было несколько курсов по веб-разработке, которые не позволяли использовать какую-либо фреймворк), поэтому большая часть этого получена из этого опыта.
У меня есть для вас непростое задание. Когда в следующий раз начнёте новый проект, постарайтесь обойтись без PHP-фреймворка. Я не собираюсь перечислять недостатки фреймворков, и это не проявление синдрома неприятия чужой разработки: в этом руководстве мы будем использовать пакеты, написанные разработчиками нескольких фреймворков. Я всецело уважаю инновации в этой сфере.
Но эта статья не о них. Она о вас. О возможности стать лучше как разработчик.
Возможно, главным плюсом отказа от фреймворка станет знание, как всё работает под капотом. Вы будете видеть, что происходит, не полагаясь на фреймворк, который заботится о вас настолько, что вы не можете что-то отладить или до конца понять.
Возможно, ваша следующая работа не позволит вам насладиться запуском нового проекта без фреймворка. Многие важные, критические для бизнеса PHP-задачи подразумевают использование уже существующих приложений. И неважно, будет это приложение, построенное на современном фреймворке вроде Laravel или Symfony, на одной из старых платформ вроде CodeIgniter или FuelPHP — либо это удручающе широко распространённое легаси PHP-приложение с «include-oriented архитектурой»: если сейчас вы будете разрабатывать без фреймворка, то окажетесь лучше подготовлены к любому будущему PHP-проекту.
Но сегодня благодаря стараниям PHP-FIG в сфере автозагрузки и взаимной совместимости вы можете разрабатывать без фреймворка, не создавая его попутно. Существует множество замечательных, взаимно совместимых пакетов, написанных многочисленными разработчиками. И собрать их в единую систему гораздо проще, чем вы думаете!
Как работает PHP?
Прежде всего важно понять, как PHP-приложения взаимодействуют с внешним миром.
PHP исполняет серверные приложения в цикле запрос/ответ. Всё взаимодействие с приложением — из браузера, командной строки или REST API — приходит в него в качестве запросов. При получении запроса приложение загружается, обрабатывает запрос и генерирует ответ, который передаётся обратно клиенту, а приложение закрывается. И так происходит при каждом обращении.
Контроллер запросов
Вооружившись этим знанием, начнём с фронт-контроллера. Он представляет собой PHP-файл, обрабатывающий все запросы к вашему приложению. То есть это первый PHP-файл, в который попадает запрос, и (по сути) последний PHP-файл, через который проходит ответ приложения.
Давайте воспользуемся классическим примером с Hello, world!, обслуживаемым встроенным в PHP веб-сервером, чтобы проверить, всё ли настроено корректно. Если вы этого ещё не сделали, то удостоверьтесь, что в среде установлен PHP 7.1 или выше.
Создадим директорию проекта, в ней сделаем вложенную директорию public , а внутри неё — файл index.php с таким кодом:
Обратите внимание, здесь мы объявляем строгую типизацию — это нужно делать в начале каждого PHP-файла вашего приложения, — потому что подсказки типов (type hinting) важны для отладки и ясного понимания теми, кто будет заниматься кодом после вас.
Далее с помощью инструмента командной строки (вроде Terminal на MacOS) перейдём в директорию проекта и запустим встроенный в PHP веб-сервер.
Отлично. Переходим к следующему шагу!
Автозагрузка и сторонние пакеты
Когда вы впервые начали работать с PHP, то, вероятно, использовали выражения include или require для получения функциональности или конфигураций из других PHP-файлов. В целом этого лучше избегать, потому что другим людям потом будет гораздо труднее разобраться в коде и понять, где находятся зависимости. Это превращает отладку в кошмар.
Выход — автозагрузка. Это означает, что, когда вашему приложению нужно использовать какой-то класс, PHP знает, где его найти, и автоматически загружает в момент вызова. Эта возможность существует со времён PHP 5, но стала активно применяться только с появлением PSR-0 (стандарта автозагрузки, сегодня заменён PSR-4).
Можно было бы пройти через тягомотину написания собственного автозагрузчика, но раз мы выбрали Composer для управления сторонними зависимостями, а в нём уже есть очень удобный автозагрузчик, то его мы и будем использовать.
Проверьте, что у вас установлен Composer. Затем настройте его для своего проекта.
После этого пройдите через интерактивное руководство по генерированию конфигурационного файла composer.json . Затем откройте его в редакторе и добавьте поле autoload , чтобы получилось так, как показано ниже (тогда автозагрузчик будет знать, где искать ваши классы).
Теперь установите для этого проекта Composer, которые подтянет все зависимости (если они уже есть) и настроит для нас автозагрузчик.
Обновите public/index.php для запуска автозагрузчика. В идеале это одно из нескольких выражений include, которые вы используете в приложении.
Если перезагрузить приложение в браузере, вы не увидите никакой разницы. Однако автозагрузчик работает, просто он не делает ничего тяжёлого. Давайте перенесём пример с Hello, world! в автоматически загружаемый класс, чтобы проверить, как всё работает.
В корне проекта создадим папку src и вставим в неё файл HelloWorld.php с таким кодом:
Теперь в public/index.php замените выражение echo вызовом метода announce в классе HelloWorld .
Что такое внедрение зависимостей?
Внедрение зависимостей — это методика, при которой каждая зависимость предоставляется объекту, которому она требуется, вместо того чтобы объект обращался наружу за получением какой-то информации или функциональности.
Допустим, методу класса нужно считать из базы данных. Для этого надо к ней подключиться. Обычно новое подключение создаётся с учётными данными, полученными из глобального пространства.
Но это не лучшее решение. На чуждый метод возлагается ответственность за создание объекта нового подключения к БД, получения учётных данных и обработки любых проблем в случае сбоя подключения. В результате в приложении дублируется масса кода. А если вы попытаетесь прогнать этот класс через модульное тестирование, то не сможете. Класс тесно взаимосвязан со средой приложения и базой данных.
Давайте с самого начала не будем усложнять работу с тем, что требуется классу. Просто в первую очередь потребуем, чтобы объект PDO был внедрён в класс.
Получилось гораздо чище и проще для понимания, меньше вероятность ошибок. Благодаря подсказке типов и внедрению зависимостей метод объявляет именно то, что ему нужно для выполнения задачи, и получает необходимое без вызова из себя внешней зависимости. А когда речь пойдёт о модульном тестировании, мы окажемся готовы к моделированию подключения к БД и спокойно пройдём тест.
Контейнер внедрения зависимости — это инструмент, в который вы обёртываете всё ваше приложение ради создания и внедрения этих самых зависимостей. Контейнер не является необходимым, но значительно облегчает жизнь по мере роста и усложнения вашего приложения.
Мы воспользуемся самым популярным DI-контейнером для PHP с изобретательным названием PHP-DI. (Надо отметить, что в его документации внедрение зависимостей описано иначе, и кому-то так будет понятнее.)
Контейнер внедрения зависимостей
Поскольку мы настроили Composer, установка PHP-DI пройдёт практически безболезненно. Для этого снова обратимся к командной строке:
Обновите public/index.php для конфигурирования и сборки контейнера.
Ничего особенного пока не произошло. Это лишь простой пример, где всё необходимое помещено в один файл для удобства наблюдения.
Мы конфигурируем контейнер, поэтому нужно явно объявить зависимости (а не использовать автоматическое внедрение или аннотации) и извлечь из контейнера объект HelloWorld .
Заметка на полях: автоматическое внедрение зависимостей может быть полезной фичей в начале создания приложения, но в дальнейшем оно усложняет сопровождение, поскольку зависимости остаются относительно скрытыми. К тому же возможно, что через несколько лет другой разработчик подключит какую-нибудь библиотеку, и в результате несколько библиотек будут реализовывать один интерфейс. Это сломает автоматическое внедрение зависимостей и приведёт к непредсказуемому потоку багов. Разработчик, внёсший изменение, может их вообще не заметить.
Давайте ещё больше всё упростим, импортировав пространства имён там, где это возможно.
Пока что выглядит всё так, словно мы устроили суматоху ради выполнения того, что уже делали раньше.
Не беспокойтесь, контейнер нам пригодится, когда добавим несколько других инструментов, помогающих передавать запросы напрямую через приложение. Эти инструменты будут использовать контейнер для загрузки правильных классов по мере необходимости.
Middleware
Если представить приложение в виде луковицы, в которой запросы идут снаружи к центру, а ответы в обратном направлении, то middleware — это каждый слой луковицы, который получает запросы, вероятно, что-то делает с ответами и передаёт их в нижний слой либо генерирует ответ и отправляет в верхний слой. Такое случается, если промежуточный слой проверяет запросы на соответствие каким-то условиям вроде запроса несуществующего пути.
Если запрос проходит до конца, приложение обработает его и превратит в ответ. После этого каждый промежуточный слой в обратном порядке будет получать ответ, возможно, модифицировать его и передавать следующему слою.
Варианты использования промежуточных слоев:
- Отладка проблем при разработке.
- Постепенная обработка исключений в production.
- Ограничение частоты входящих запросов.
- Ответы на запросы неподдерживаемых медиатипов.
- Обработка CORS.
- Маршрутизация запросов в соответствующие обрабатывающие классы.
Промежуточный слой — это единственный способ реализации инструментов для обработки всех этих ситуаций? Вовсе нет. Но реализации middleware позволяют сделать цикл запрос/ответ гораздо понятнее, что сильно упростит отладку и ускорит разработку.
Мы воспользуемся промежуточным слоем для последнего сценария: маршрутизации.
Маршрутизация
Маршрутизатор применяет информацию из запроса, чтобы понять, какой класс должен его обработать (например, URI /products/purple-dress/medium должен быть обработан с помощью класса ProductDetails::class с передаваемыми в качестве аргументов purple-dress и medium ).
Наше приложение будет использовать популярный маршрутизатор FastRoute через реализацию промежуточного слоя, совместимого с PSR-15.
Диспетчер middleware
Чтобы наше приложение стало работать с каким-либо промежуточным слоем, нам понадобится диспетчер.
PSR-15 — это стандарт, определяющий интерфейсы для middleware и диспетчеров (в спецификации они называются «обработчики запросов»), обеспечивающий взаимосовместимость широкого спектра решений. Нам лишь нужно выбрать диспетчер, совместимый с PSR-15, и он будет работать с любым совместимым middleware.
В качестве диспетчера установим Relay.
Подготовим Relay к приёму промежуточных слоев.
В строке 16 мы с помощью ServerRequestFactory::fromGlobals() будем собирать всю информацию, необходимую для создания нового запроса и передачи его Relay . Здесь запрос попадает в стек промежуточных слоев.
Теперь добавим FastRoute и обработчика запросов ( FastRoute определяет, валиден ли запрос и может ли он быть обработан нашим приложением, а обработчик запросов передаёт запрос тому обработчику, что сконфигурирован для этого маршрута).
А теперь определим маршрут для класса обработчика Hello, world. Здесь мы воспользуемся маршрутом /hello , чтобы продемонстрировать возможность использования маршрута, отличающегося от базового URI.
Чтобы всё заработало, нужно обновить HelloWorld , сделав его вызываемым классом, то есть чтобы этот класс можно было вызвать как функцию.
Обратите внимание на добавленный exit; в магическом методе __invoke() . Скоро вы поймёте, к чему это.
Клей, который всё скрепляет вместе
Проницательный читатель заметит, что DI-контейнер, несмотря на все трудности его конфигурирования и сборки, на самом деле ничего не делает. Диспетчер и промежуточное ПО могут работать и без контейнера.
Так зачем он нужен?
А что, если — как это почти всегда бывает в реальных приложениях — у класса HelloWorld есть зависимость?
Давайте её добавим и посмотрим, что произойдёт.
Перезагрузим браузер, и.
Это происходит потому, что для функционирования HelloWorld требуется при его создании внедрить строковое значение, а у нас это повисло в воздухе. И здесь на помощь приходит контейнер.
Давайте определим зависимость в контейнере и передадим его в RequestHandler для разрешения.
Вуаля! При перезагрузке браузера вы должны увидеть Hello, bar world!.
Помните, я упомянул о выражении exit в HelloWorld ?
Это простой способ удостовериться, что мы получили простой ответ, но всё же это не лучший способ отправки выходных данных в браузер. Такой грубый подход заставляет HelloWorld делать лишнюю работу по отдаче отчетов — а этим должен заниматься другой класс, — что слишком усложняет отправку заголовков и кодов статуса, а также приводит к закрытию приложения, не давая шансов запуститься промежуточному ПО, идущему после HelloWorld .
Обновим HelloWorld для возвращения Response .
Обновим определение контейнера, чтоб HelloWorld предоставлялся со свежим объектом Response .
Если мы сейчас обновим страницу, то получим пустой экран. Приложение возвращает из диспетчера промежуточных слоев правильный объект Response , а потом… что?
Просто ничего с ним не делает.
Нам нужен ещё один инструмент: эмиттер. Он находится между приложением и веб-сервером (Apache, nginx и т. д.) и отправляет ваш ответ клиенту, сгенерировавшему запрос. Эмиттер просто берёт объект Response и преобразует в инструкции, доступные для понимания серверным API.
Для простоты примера мы используем здесь очень простой эмиттер. Хотя он может быть гораздо сложнее, но в случае больших загрузок реальное приложение должно быть сконфигурировано для автоматического использования потокового эмиттера. Это хорошо описано в блоге Zend.
Обновим public/index.php для получения Response от диспетчера и передачи в эмиттер.
В строке 15 заканчивается цикл запрос/ответ и вступает в работу веб-сервер.
Завершение
Мы углубились в некоторые технологии и аргументацию, но я надеюсь, вам очевидна простота программы начальной загрузки нового приложения без сопутствующего хлама фреймворка. Также надеюсь, что вы теперь лучше готовы к применению этих технологий в существующих приложениях.
Использованное в статье приложение лежит в репозитории, можете свободно форкать и скачивать.
первый вариант дает знание всей подноготной, но требует достаточного времени. второй менее затратный. но дает точно такой же эффект.
что я хочу сказать: если у вас много лишнего времени, то ваш вариант, хоть и трудоемкий, но для личного развития просто неоценим. но если со временем у вас напряг, то использование фрейморков сильно упростит работу (так как, все уже изобретено до вас), а полученный сейчас опыт, вам еще не раз окупится
Ну почему же. Вы сделали свой велосипед, он ездит и даже вперёд (ну я надеюсь на это). Остаётся вопрос поддержки и добавления фич и поддержка, с фреймворками иногда это проще. Блин, фреймворк-то надо выбирать еще правильно.Нахватался человек слов Zend, Symphony, ну или еще чего-то.
если мне нужен нормальный High Perfomance с плюшками, чтобы за пояс затыкал все вышеобозначенные, тогда я выберу Phalcon
Тест на жизнеспособность: будет ли нужно многим на постоянной основе именно то, что Вы предлагаете? Принесет ли это прибыль бизнесу? Какую?
Всегда есть 100500 всевозможных конструкторов, CMS, CRM, новых фреймворков и т. п. аналогичных продуктов и 9999 демпингующих азиатских программистов на фрилансе и в аутсорсе, которые могут сделать Вашу работу за Вас )
Велосипед это крайне полезный индивидуальный опыт.
Вы с языком как он есть поработали. Чтобы разницу понять между PHP и другими языками, попробуйте именно свой проект (ведь вы его знаете от и до) перенести на другой серверный язык. На ROR или NODEJS перепишите. Это будет еще более полезно, поскольку быстро поймете как в ROR или NODEJS такие же функции реализуются, как в PHP, ну и возможно, примите решение использовать Рельсы или Ноду. В ноде можно вообще делать изоморфные приложения. Советую обратить внимание именно на тему изоморфных веб-приложений. За ними большое будущее.
Хотя разработчики фреймворков подготовили типовые решения для повторного использования, это не означает, что такие решения не надо будет оптимизировать, переделывать или писать что-то свое, или знание фреймворков перекрывает знание обезжиренного языка.
Предположим, у Вас CMS, ориентированная на MySQLi. Если вы перепишите код так, чтобы можно было миграции делать между разными базами данными, т. е. не MySQL использовать, какую-то другую базу данных, то у Вас получится что-то вроде ORM/ActiveRecord и модели появятся сами собой. Ну просто потому что по-другому не получится, все равно к этому подходу Вы придете рано или поздно. Т. е. фреймворк - квинтэссенция опыта разработчиков.
От использования фреймворков проект не становится жизнеспособней, потому как уровень программиста-пользователя фреймворка и опыт разработчиков фреймворка не сопоставим. А фреймворки рождаются и умирают. Где например, сейчас CodeIgniter или Kohana ) Ну а если разработчик радикально интерфейсы переделает, проект придется переписывать. Такие вещи надо учитывать и быть к ним готовы. Идеальный вариант - не прибивать гвоздями проект к какому-то фреймворку. Вы не застрахованы от ошибок, которые не совершил бы опытный программист. Можно использовать супермодный фреймворк и в результате получить невразумительный результат с труднообнаружимыми ошибками, багами и т. п. Личный опыт (сын ошибок трудных) приходит со временем. Это тем более касается PHP, у которого нет строгой типизации.
Т. е. это тоже такой хороший момент для развития - делаете серверный продукт, напишите к нему клиентскую программу на Mono, FreePascal или QT, сделайте API. И если это CMS какая-то, да не важно, возможно, людям будет удобнее пользоваться таким клиентом, а не браузер открывать.
С другой стороны, представьте себе что 1) надо проекты делать быстро 2) их много. Тогда Вы придете к идее завтоматизировать рутинные процессы. Что и делается с помощью утилит для скаффодинга, кодогенераторов. Например, в MEAN стеке это решается с помощью утилиты yeoman.io и менеджера зависимостей npm,
в ROR с помощью конструкций типа
rails create blabla
bundle install
rails generate model .
rails generate controller
rake db:migrate
и т. п.
В Yii такие функции выполняет gii.
Поэтому не только на фреймворки внимание обращайте. Ищите инструменты, которые Вам время высвободят. Посмотрите редакторы Bracket, Atom, LightTable.
Они превратят в сказку работу с исходным кодом.
В этой статье не рассматриваются технические термины и концепции, чтобы обеспечить ее содержание простым. Если вы программист, позвольте мне рассказать вам, почему вы должны предпочесть использовать фреймворки вместо чистого PHP для своих проектов. Если вы являетесь предпринимателем, позвольте мне рассказать, почему так важно настаивать на том, чтобы ваш разработчик программного обеспечения разрабатывал веб-приложения и веб-сайты с помощью PHP фреймворков.
Сравнение чистого PHP и PHP фреймворка может быть похоже на математику.
Чтобы решить сложную задачу в математике, вы можете либо взять лист бумаги, либо использовать научный калькулятор для ее решения.
Нахождение решения математической задачи на бумаге похоже на кодирование на чистом PHP, использование же научного калькулятора похоже на кодирование с использованием фреймворков.
Так что я имею в виду?
Нативный PHP - Математика с бумагой
Хороший студент может решить задачу за несколько шагов. Уровень точности - от 75% до 100%.
Посредственный студент сможет или не сможет решить задачу, он запишет несколько шагов для решения одной и той же задачи. Здесь уровень точности - от 50% до 75%.
Плохой студент не сможет решить задачу вовсе. Тем не менее, он будет записывать много и много шагов для решения проблемы. Уровень точности - от 0% до 50%.
Научный калькулятор
Каждый студент может решить проблему с точностью 100%, как только они узнают, как использовать калькулятор. Предопределенные формулы в калькуляторе будут давать точные результаты быстрее.
Проблема с чистым PHP
Чистый PHP становится сложным, когда люди начинают писать свою собственную логику. Кто-то сможет решить поставленную задачу в несколько строк кода, а кто-то не сможет и в несколько сотен. А в результате оба они не могут читать код друг друга. Итак, проблема, которая зарождается здесь, это несогласованность.
Почему выбирают фреймворки?
Фреймворк обеспечивает надежность, согласованность и большую экономию времени. Он имеет богатый набор функций, поэтому вам не нужно повторно изобретать колесо. У вас будет практически все функциональные возможности для разработки веб-приложения PHP. Поскольку он был разработан в стиле ООП, вы можете расширить существующую функциональность, чтобы иметь полный контроль над приложением. Фреймворк не позволит вам писать плохой код, если, конечно, вы намеренно это не делаете. Когда вы работаете в команде, интеграция всего вашего модуля становится очень легкой, а также фреймворк помогает в понимании кода друг друга.
Когда вы начинаете разработку проекта, есть много вещей, о которых вы должны заботиться. Фреймворк делает все за нас, поэтому можно быть уверенным, что приложение является чистым и безопасным. Шаблон MVC является одним из ключевых элементов любого современного PHP фреймворка, разделение логики и представления - очень хорошая практика.
Модификация проекта
Рано или поздно, если вы оставили о себе хорошее впечатление, клиент вернется к нам, чтобы улучшить сайт. И здесь наступает важный момент - если проект был выполнен на чистом PHP, вам придется либо очень сильно напрячься, чтобы выполнить новые пожелания клиента либо вовсе отказаться от дальнейшей работы с проектом. Но если проект был выполнен в рамках фреймворка, то в данном случае вы почувствуете всю мощь и красоту выбранной технологии. Все, что вам нужно будет сделать, это внести изменения и отдать обновленный проект обратно клиенту.
Тогда неужели чистый PHP так плох?
Абсолютно нет. Чистый PHP помогает понять логику фреймворка. Ваше логическое мышление может быть улучшено с помощью чистого PHP. Однако нативный PHP становится плохим только тогда, когда он попадает на стол плохого программиста. Не погружайтесь в фреймворк без опыта кодирования на чистом PHP. Также, убедитесь, что вы прочитали полную документацию по фреймворку, прежде чем начинать кодирование в нем, так как в настоящее время стало “модно”, использовать нативный PHP внутри фреймворка, но это абсолютно неверный путь использования такого полезного инструмента.
А вообще, проще всего разобраться с тем, что такое фреймворки можно с помощью моего курса Фреймворк Yii 2.0 с нуля. Пример создания сайта.
Причём тут первый рендер, если для него нужен только html и css.
ошибаешься, js, картинки и прочее тоже участвуют в процессе первого рендера. Причем для js еще можно указать, чтобы он был исключен из первого рендера и вообще грузился асинхронно без первого приоритета.
NazarPunk:
Я при сборке проэкта тоже получаю всего два файла .js и .css, которые успешно попадают в кэш.
не забывай о размере бандла, при чистом виде он будет минимальным. Один только jquery весит 87 Кб, функций которые ты почти не используешь, а мы умещаем в этот размер целое приложение с нехилой функциональностью полноценным дизайном и поддержкой всех не модных брузеров
Чтобы успешно сложить и использовать кеш тебе нужен стабильный интернет и постоянный пользователь. Если рассматривать мобильных юзеров и стандартный поток клиентов на сайт, то твоя теория сильно наворачивается.
NazarPunk
NazarPunk
Один только jquery весит 87 Кб, функций которые ты почти не используешь
Я смотрю просто адские размеры без gzip, что ни один браузер их не потянет,
alexprey
alexprey
То что ты говоришь, это не каждый чих, а разбивка на чанки, чтобы при обновлении кода, обновлялся не весь бандл, а только определенный чанк
NazarPunk
NazarPunk
Кем приветствуется? Если там появилось мультиплексирование, то это не значит, что его нужно юзать гденипопадя.
Если бы оно так сильно приветствовалось, то я бы каждый селектор css вынес бы в отдельный файл и грузил бы их скопом, но что-то так никто не делает.
Raised
Raised
Пока вижу роутинг одной из ключевых проблем: как правило роутер определяет что рисовать при каком запросе, на время сессии запоминает список доступных* и посещенных/загруженных страниц. С MPA вся логика находится на сервере. Чтоб получить все преимущества SPA (PVA, например) нужен роутер на клиенте.
На всякий случай выведу оперативное определение роутера:
определяет что рисовать при каком запросе, на время сессии запоминает список доступных* и посещенных/загруженных страниц (полу-PVA, хотя полноценный PVA отсюда вывести несложно).
При таком подходе загруженный роутером скрипт инициирует вьюху и делает ее активной/текущей (пряча все остальные). Прирост производительности получается за счет того что уже посещенную страницу можно просто вытащить из списка, вместо отправки очередного запроса на сервер и гуфа единственного контейнера. Ясное дело подразумевается что нужны опции, позволяющие указать стоит ли пытаться подгрузить более актуальную версию вьюхи с сервака, каков должен быть интервал между запросами и т.д.
Есть только одна проблема: в некоторых случаях некоторые части страницы остаются неизменными. Вот представим кейс с information-dense сайдменюхой с вкладками и мейн контейнером со списком статтей для вьюхи. Я позволю себе усомнится в целесообразности перерисовки всей страницы при переключении вкладки => смене роута. Тут нужен рекурсивный подход и чтоб помимо "Что?", роутер определял и "Где?" это рисовать. То есть определение придется расширить и как-то рекурсивно проходить по чему-то при смене роута. Но как и по чему именно я так пока и не додумался.
Постараюсь ка-то прикинуть решение как будет на это время.
Raised
Raised
Есть обновления. Пожалуй, стоит начать с того что при описанном выше подходе помимо роутинга на клиенте была еще одна проблема: пререндеринг на сервере, SEO.
Ну а чтоб решить эту проблему пришлось разобраться с роутингом на сервере. Так как параллельный массив с захардкодженными парами вида <реквест: страница>не достаточно гибок, пришлось подумать что еще можно с этим сделать. В итоге остановился на подходе, аналогичном react-router:
С примера выше понятно что в ход пошли шаблонная строка + асинк/авэйт. Не буду нудить деталями имплементации и как все умно и красиво все сделано, пока что скажу что это работает таким же образом как и реактовский роутер, грубо говоря — динамично и в результате получается древообразная структура.
Осталась проблема синхронизации DOM-референсов сгенерированной страницы с клиентом. Ну а так как виртуальный DOM я не хочу да и вряд ли могу с таким подходом, надо придумать какой-то алгоритм для передачи референсов. Есть одна идея которую буду сегодня тестировать, но она мне кажется немного упоротой. Пример синхронизации хуков клиента с сокетами, сгенерированными на сервере:
Метод node, генерирует бандл для клиента, присваевает ему указанное имя или имя, сгенерированное с названия узла и инжектит ссылки на файл в тело страницы.
Все это происходит при запуске сервера. Генерируются отрендерренные версии узлов, генерируются бандлы для узлов и компонентов. Генерируется статичный ассоциативный массив вида <запрос: файл>, и сгенерированные ассеты уже обслуживаются по нему.
Думаю, стояло бы нарисовать схему и углубится в имплементацию, но честно говоря, не думаю что все это будет хоть кому-либо интересно. Юзай фреймворк n, добавь магии в свою жизнь.
Читайте также: