Привет, коллеги!
В этой статье я сделаю обзор NativePHP, который появился на Laracon US 2023. Видеообзор, который я сделал, вызвал большой интерес у аудитории, и я решил оформить статью про NativePHP, для тех кто любит читать. Кто больше любит видео, то оно тут:
Что из себя представляет NativePHP? Перед нами фреймворк, который позволяет нам писать нативные десктоп приложения, используя PHP. Приложения кроссплатформенные - можно писать под Mac, Windows и Linux. И все это с использованием нашего любимого PHP с использованием Laravel. Но как обещают разработчики в будущем появятся и другие драйверы.
В целом вы просто пишете приложение на Laravel, устанавливаете NativePHP и компилируете его в десктоп приложение. Далее прямо в операционной системе запускаете приложение и перед вами откроется тот же самый проект, который Вы писали. Под капотом используется Electron или Tauri. Пока что у нас NativePHP в Альфа версии, и пока что доступен только Electron.
Electron - это фреймворк для разработки десктопных приложений с использованием HTML, CSS и JavaScript. В Electron уже встроены Chromium и Node.js, и это позволяет вам поддерживать только JavaScript код и создавать кроссплатформенные приложения, которые будут работать как на Windows, так и на macOS и Linux без необходимости иметь собственный опыт разработки.
Что под капотом - мы используем веб-технологии HTML, JS, CSS, чтобы скомпилировать итоговое приложение. И если мы говорим о Electron, то под капотом будет использоваться Chromium и Node.js, поэтому приложение в целом получится объемное, так как каждый раз будет подтягиваться Chromium и размер итоговой аппки будет большой. С появлением Tauri тут уже получше, использоваться будет встроенный браузер, webview и в итоге получится более легковесное и быстрое приложение. Но пока работаем с Electron.
Еще в NativePHP есть поддержка базы данных SQLite - мы когда скомпилируем приложение будем использовать внутреннюю базу и это также интересно.
Для создания нативного приложения я буду использовать свой проект MoonShine.
Установка
Что нам потребуется для установки?
PHP 8.1
Laravel 10 и выше
npm
Linux либо MacOs.
Давайте с помощью Composer для начала установим NativePHP:
composer require nativephp/electron
Далее нас просят выполнить следующую команду по установке NativePHP уже внутри фреймворка Laravel:
php artisan native:install
С помощью npm за нас установят Electron и прочие зависимости которые требуются (необходимо подтвердить свое согласие выбрав “Yes”). После этого нас спрашивают запустить ли NativePHP сервер? Следуем рекомендациям и выбираем “No”. Установка выполнена, смотрим на результат (публикации confrg и serviceProvider).
Давайте посмотрим на конфиг (/config/nativephp.php) - тут можно кастомизировать наше приложение.
Заглянем в ServiceProvider (/Providers/NativeAppServiceProvider.php) - здесь будет твориться вся магия.
Видим Window::Open, то есть как только мы запустим наше приложение, у нас откроется окошко, в котором будет соответственно та веб-версия, которую мы написали на Laravel.
Возвращаемся к процессу установки и следующая команда как раз запускает сервер в режиме разработки:
php artisan native:serve
Приложение запускается! В правом нижнем углу на MacOS отобразится иконка Electron. Пока наше приложение выглядит не очень:
Для отображения приложения используется Chromium, одновременно демонстрируется devtools в правой части браузера с HTML, CSS, JS. Видим ошибку:
Нет таблицы. Есть ощущение что миграции не выполнены. В консоли предупреждение, что DataBase миграции пока пропущены, выполните для миграций команду вручную.
Странно, что про это ничего не сказано в разделе установка. И если бы не заглянул в терминал, ничего бы не понял. В доке в разделе Database нашел что надо делать. Выполняем команду (с опцией seed):
php artisan native:migrate --seed
Отображается ошибка о наличии миграции.
Догадался, что проблема в Telescope. Отключаем его:
Пробуем выполнить миграции еще раз. Не помогло. Пробую выполнить другую команду:
а native:migrate_fresh
На момент написания статьи команда native:migrate_fresh вызывает ошибку самой команды т.е. команда не работает. Давайте разберемся. Найдем эту команду в NativeServiceProvider.php - обнаруживаем, что команда вообще не объявлена! То есть в документации есть - пользуйтесь ребята, но в самом релизе она отсутствует. Давайте добавим её сами, вручную.
И выполним еще раз:
а native:migrate_fresh
Разбираемся что не так. Исходя из содержимого FreshCommand.php - видно, что база данных database хранится в определенном файле из конфига и при fresh она просто удаляется.
Находим файл с базой sqlite (database/nativephp.sqlite) и попросту удаляем его.
Выполняем команду
native:migrate
Сервис провайдер сервиса Telescope при регистрации своего провайдера выполняет миграции. Убираем его, чтобы не мешал.
Выполняем команду
composer:update
Далее удаляем базу данных nativephp.sqlite из /database.
Еще раз пробуем выполнить миграции. В терминале выполняем
native:migrate
Миграции выполнены. Открываем приложение, видим что оно не обновилось. Но если начать что-либо менять в nativePhpServiceProvider, то произойдет hard reload и мы вынудим приложение обновиться. Давайте изменим ширину окна:
Открываем приложение, видим что произошла перезагрузка. Отлично что-то нарисовалось.
Видим главную страницу и devtools. Давайте скроем его. Для этого установим параметр:
ShowDevTools:false
Открываем приложение. DevTools пропал, видим главное окно сайта. Давайте через роут изменим стартовую страницу приложения и заодно размеры окна.
Давайте попробуем залогиниться. Не получается. Миграции мы сделали, но не сделали сиды. Выполним команду:
a native:migrate --seed
Проверяем. Отлично, авторизация выполнена.
Видим, что база данных работает и мы попадаем в админ-панель. Всё доступно и работает.
Заголовок и меню
Согласно документации мы можем кастомизировать окно с приложением. Давайте поменяем заголовок:
Window::open()
->title(title:'MoonShine');
Видим что тайтл изменился на заданный нами.
Меню бар (меню сверху, справа)
Практически пока не работает и вызывает кучу багов.
MenuBar::create();
В результате у нас появляется вверху пункт при клике на который появляется главная страница (т.е. содержимое меню сверху у нас формируется за счет определенного роута нашего веб-приложения, по умолчанию - главная страница).
также будет присутствовать метод route() при помощи которого мы можем задать что-то другое.
Давайте посмотрим что еще можно сделать с MenuBar:
отобразить
MenuBar::show();
скрыть
MenuBar::hide();
изменить label
MenuBar::label('Status: Online');
Давайте протестируем:
Как результат появляется лейбл справа от иконки
Кроме того доступны команды:
изменить url
MenuBar::create()->url('https://google.com');изменить route
MenuBar::create()->route('home');изменить иконку
MenuBar::create()-> icon(storage_path('app/menuBarIconTemplate.png'));изменить размер
MenuBar::create()->width(800)->height(600);постоянно отображать сверху
MenuBar::create()->alwaysOnTop();есть возможность добавлять контекстное меню
Через метод ->withContextMenu указываем, что присутствует контекстное меню и добавляем пункты меню с помощью объекта Menu: ставим лэйблы, разделители, можно сделать активную ссылку.
Меню приложения
Меню которое обычно вверху окна. Вставляем код из примера в документации и посмотрим что получится.
В результате получаем application menu - наименования и пункт меню который добавили Native PHP и ссылку на документацию (при клике на которую переходим на страницу с документацией). Прикольно:
Диалоги
Можем открывать диалог по выбору файла из файловой системы. Мы можем вызывать события и тем самым открывать диалог прямо из NativePHP. Берем код
use Native\Laravel\Dialog;
Dialog::new()
->title('Select a file')
->open();
Приложение перезагружается и при запуске приложения теперь открывается файловый менеджер системы с диалогом выбора файла.
Нативные уведомления
На тестируемом приложении MoonShine есть уведомления: например при сохранении записи в базу данных. Давайте так же вместе с ним вызовем уведомление через нативное приложение. Открываем код и в метод с flash уведомлением добавим Notification из NativePHP (не забываем добавить use Native\Laravel\Facades\Notification;)
Давайте перейдем в статьи и нажмем сохранить. Видим, что уведомление появилось и контент как раз соответствует тому который указан по умолчанию. Работает.
Горячие клавиши
Как раз здесь таится ответ на вопрос о том что вообще делать с диалогами и прочим? Как вообще взаимодействовать с Native PHP? Взаимодействие происходит через события, а события у нас простые - те же самые ивенты, которые мы используем в Laravel. И скажем вот как в данном примере: мы объявляем горячие клавиши, затем когда они срабатывают, вызывается event, а уже в нём мы открываем дополнительное окошко с dialog, notification т.е. все то, что нам необходимо для взаимодействия с нашим приложением.
Итоговый Building
Скомпилируем наше приложение в итоговый файл и посмотрим сколько этот файл будет занимать места. В документации указано, что при Building поддерживается Electron/Tauri (но пока только Electron) и кроссплатформенность MacOS, Windows, Linux (Windows пока нет).
Останавливаем наше приложение в режиме разработки и выполним команду для запуска процесса компиляции, при этом копируется приложение в указанную в настройках директорию (у меня это dist):
php artisan native:build win
По результату скомпилированное приложение занимает более 1Gb, что чрезвычайно много для простого web приложения.
Посмотрим на саму аппку:
Проблема большого веса простейшего приложение скорее всего заключается в Electron т.к. он подтягивает Chromium - огромный браузер. Пробуем запустить приложение, оно запускается довольно шустро.
При попытке войти возникает проблема из которой становится понятно, что при компиляции не были выполнены seed (думаю что это из-за alfa версии). Со временем появятся дополнительные опции и при компиляции мы сможем выполнять seed.
При запуске в режиме разработки можем посмотреть на наше творение ???? Все работает!
Итоги
Интересный проект. Но еще сыроватый - в процессе тестирования вылезло очень много багов. Сделать нативное приложение получилось, но пришлось попотеть. Понятно, что еще альфа версия, но рассчитывал на более стабильную работу.
Также заметил, что последний месяц нет активности в репозитории проекта NativePHP, настораживает.
В завершение статьи хотел бы у вас спросить - а как вы думаете, есть ли будущее у проекта и какие можно задачи решать с его помощью? Давайте обсудим в комментариях.
Данил Щуцкий, автор проекта CutCode.
Комментарии (50)
savostin
01.10.2023 09:47Т. Е. Там и браузер, и php, и node? Кажется не хватает только MySQL, а лучше Postgres. Да и Docker классный, давайте и его…
kovserg
01.10.2023 09:47Можно еще OS запихнуть в образ виртуалки, чего уж там.
Вот полноценная ОС вместе гуями, браузером и всем необходимым помещалась в 30Мб
slitaz-3.0-xvesa.iso [29 МБ] — Полнофункциональное окружение рабочего стола с использованием крошечного графического сервера Xvesa, предоставляющая хороший набор ПО для повседневных задач
https://www.youtube.com/watch?v=mtbTMaFxOQM
https://www.youtube.com/watch?v=o9Xp1cy4XPI&list=PL208CA99ED2E18645
Format-X22
01.10.2023 09:47+2Ещё вроде как что-то в районе 2012 было, на asm.js ещё, поднимали винду 3.1 и некоторые из линуксов и бсд прямо в браузере, виртуализовав это дело и получая пусть и не самую быструю, но полноценную ОС. И в ней открыть браузер. Так что можно запустить сайт > в браузере > в фрибсд > в электроне > в хроме > в винде > в виртуалке > в линуксе > в вдс > в облаке.
Hakhagmon
01.10.2023 09:47Смешно читать комментарии, тут же явно не про то чтобы использовать приложение на десктоп, а про то что laravel можно запихнуть в приложение. И у тебя из коробки все возможности laravel.
Ранее был Jphp проект, который был нацелен на изучение ООП по сути.ну и не стоит забывать cs на php, который тоже для демонстрации возможностей делали
yoda_code
01.10.2023 09:47Да, жаль, что в основе лежит Electron. Получается, что каждое сделанное приложение от микро до макро будет +размер дистрибутива chrome и +размер оперативной памяти используемый chrome. Для программ подобных Obsidian с таким есть готовность мириться. Но если вам нужно небольшое приложение, и есть желание в минимум потребления памяти и небольшой размер дистрибутива, такой вариант не подойдет.
mrSOB
01.10.2023 09:47+2Вай, счастье то какое.
Кто ж разработчик сего чуда? Хотелось пожать их крепкие, кривые руки. Очередной webview весом на 1 GB. И самое главное, для чего?
Я понимаю свиминг в лужах, хоккей на траве, но это уж простите, перебор в извpaщении.
WondeRu
Огребу, но не могу сдержаться:
Что только ни делают PHPшники, чтобы не учить нормальные языки))
lkoida
Да нормальный PHP язык, просто его ниша это далеко не нативные десктопные приложения. Попытки натягивать сову на глобус настигали и другие языки, кто то пытается сайт на плюсах или, упаси господи, на ассемблере писать.
rsashka
Как по мне, то PHP был нормальным раньше, а сейчас со всеми современными наворотами, мне он не зашел. Раньше для тестовых страничек я его использовал довольно часто, а сейчас проще на Python с какой нибудь Django, что-то наваять, чем разбираться в наворотах PHP.
lkoida
Ну так и PHP можно взять с какими-нибудь ларавелем, или прям совсем простым Slim. Там до сих пор все просто.
rsashka
Можно. Но заем пытаться запрыгнуть в уехавший поезд?
PHP развивается и рано или поздно нововведения появятся в ларавелем, или прям совсем простым Slim. Поэтому гораздо проще не мучатся, а сразу обрубить хвост целиком и начать использовать что-то более подходящее.
bel1k0v
Django это мощный фреймворк, а не "какой-нибудь герой в катке подпивас", причём по сложности и монструозности не уступающий ни Symfony (оба с 2005 года существуют) ни Laravel. Это не навороты, а все те части веб-приложения, которые могут иметь место быть, если это потребуется. Разбираться имеет смысл в веб-разработке, а не в отвёртках, которыми будете прикручивать (каждому своя).
rsashka
"Какой нибудь", это не пренебрежительное отношение к Django, а указание на выбор среди множества подобных (Django, FastAPI, Web2Py, Tornado, Bottle, Flask и т.д.)
bel1k0v
FastApi только для создания API, скудная функциональность
Web2Py, документация ужос, моё почтение тем, кто его использует
Tornado - расширяемый, неблокирующий веб-сервер и фреймворк
Bottle тоже что-то "лёгкое"
Flask опять же "микро"
У PHP есть Slim (micro Symfony)? Остальные как раз реализуют MVC, давая вам более высокоуровневые абстракции, как и Django.
Т.е. есть класс полноценных фреймворков и микро. Поэтому Django я бы не ставил в один ряд
rsashka
Я не занимаюсь профессиональной разработкой под Web и подобный тонкости мне без разницы. Нужно было сделать тестовую страничку или простенький сайт для проверки гипотезы, беру и делаю, и чем проще - тем лучше.
Раньше можно было поднять apache и что-то быстро накидать на PHP, но учить только ради этого целый фреймворк, да еще при постоянном "улучшении" синтаксиса PHP? Ну уж нет, мне подобных улучшательств в C++ хватает.
bel1k0v
Хм, как вариант в docker быстро поднять нужное окружение
rsashka
Это нарушает принцип KISS :-)
bel1k0v
Как?
rsashka
Что как? Как нарушает принцип придерживаться простых решений?
Мне это кажется очевидном. Ведь нужно использовать дополнительную сущность, без которой можно обойтись.
bel1k0v
Если это удобно и решает ваши задачи, почему нет?
Не совсем очевидно, если для продакшен целей, то возможно будет оверхед, но если для тестов, это будет быстрее. Можно и на прод натянуть, я лично не фанат, но для тестов и локального использования действительно есть от этого профит. Попробуйте.
janson
А что сейчас вам мешает поднять апач/nginx и что-то быстро накидать на PHP? Я всё время так делаю, это по прежнему работает.
Изменения в синтаксисе языка не обязывают вас использовать прям всё сразу. На простых набросках я даже не втыкаюсь в какие-то нюансы. А в крупных проектах - да, там при миграциях риск поймать что-то из новенького заметно выше. Но в последнее время проект на php7.2 перевезли на php8.2 и воткнулись в собственном коде только в новое зарезервированное слово match, которое у нас было использовано как имя одного из классов. Все изменения и проблемы при переезде были связаны с обновлениями пакетов, но я уверен что в любом фреймфорке любого языка при повышении мажорной версии языка начинаются интересности.
rsashka
Чистый PHP, как и чистый Python, тут не помогут, так как требуется сделать немного больше, чем простой hello world.
А раз нужно использовать какой нибудь framework, или не дай бог какую нибудь кроссязыковую функциональность, например вызов из C\C++ библиотеки, то при выборе между PHP и Python, я выбираю последний.
bel1k0v
Есть такое
rsashka
Спасибо, я знаю, что это есть, просто мне изначально не зашел новый синтаксис PHP с его классами и слешами. Поэтому и решил с ним распрощаться, так как мне проще было использовать другие инструменты.
s5656
То есть вы сравниваете php8 и... php4? Просто те самые "классы и слеши" ввели в php5... Это было лет 15 назад...
rsashka
Во первых "классы и слеши" начали использовать в различных фреймворках не сразу после их выхода и потребовалось какое-то время, чтобы их переписать под новые версии синтаксиса и возможности языка.
А во вторых, я перестал пользоваться PHP не сейчас, а как раз тогда, когда и начали во фреймворки затаскивать эти "улучшения".
s5656
Ну я плохо помню, конечно, уже, но вроде ZF2 оперативно релизнулся и использовал неймспейсы.
А вы и в других языках в неймспейсы не умеете? К чему такая нелюбовь?
rsashka
При чем тут не умете? Мне не нравиться синтаксис через слеш, который реализовали в PHP. Конечно, это дело вкуса, но мне он не зашел.
FanatPHP
Послушайте, ну не нравится вам РНР — так и напишите. Это как раз будет приемлемое объяснение. Но зачем вы пытаетесь подводить какую-то базу и выставляете себя клоуном?
В предыдущем комментарии вам прекрасно хватало "что-то быстро накидать на PHP". Почему сейчас вдруг резко перестало? Вы определитесь — или РНР вас и раньше не устраивал, или сейчас вы точно так же можете "накидать".
Вы сами не понимаете, что всё выглядит как капризы пятилетнего ребенка?
rsashka
Так я именно это и написал. А особо дотошным даже рассказал, почему не нравится. Если вам нравится PHP ну и пишите на нем. Мне он не нравится, то я писать не буду.
И мне не нужно вашего разрешения или дозволения, чтобы высказать собственное мнение. Вообще не понял ваших претензий. Что у вас так порвало?
FanatPHP
Нет, вы написали другое. Если бы вы остановились на вкусовых предпочтениях, никто бы вам и слова не сказал. Но вы решили подвести под них какие-то смехотворные обоснования.
Во-первых, вы написали что что "PHP был нормальным раньше", а некие "современные навороты" почему-то мешают вам его использовать сейчас. При том что эти "навороты" (ОМГ, неймспейсы объявлены непостижимыми наворотами) никто вас не заставляет использовать, вы можете писать без них. В вашем заявлении нет логики.
Во-вторых, вы нигде не писали, что ваши задачи усложнились, и РНР перестал подходить для них. Наоборот, вы четко писали про "тестовые странички" и "быстро накидать". При том что РНР в этом плане совершенно не изменился и точно так же можно "быстро поднять apache и что-то быстро накидать на PHP". И небыстро тоже. Вы прекрасно понимаете, что на РНР прекрасно пишется "немного больше, чем простой hello world." Зачем вы передергиваете?
FanatPHP
Какие-то странные претензии.
Сейчас точно так же можно поднять "apache и что-то быстро накидать на PHP". "Учить фреймворк" или использовать "улучшения синтаксиса" вас никто насильно не заставляет. Какие именно улучшения вам мешают говнокодить на РНР?
rsashka
Это не претензии, так как PHP мне ничего не должен. Но так как "меня никто не заставляет говнокодить на PHP", я решил это делать с помощью более простых и понятных инструментов.
derwin
у пхп есть микро. А зачем?
Чтобы что? чтобы быстрее? ставишь поверх лары roadRunner (Laravel Octane) и у тебя из коробки респонсы за 2мс, и нагрузка +1000% к RPS на контейнер.
После нормальной лары уже как то и не хочется на "микро".
bel1k0v
Микро нужен, если у вас 4 таблицы в БД и можно не сильно заморачиваться на бизнес-логику. Для прототипирования подойдёт.
Октан даёт немного другое понимание работы приложения на Laravel, оно теперь имеет runtime, пока не использовал, такое до прода ещё донести надо.
derwin
На "микро" ты потратишь больше времени чем на ларе.
bel1k0v
Уже тратил, вообще немного, но выкинуть пришлось. У меня и так всё на ларе из последнего.
alexeydg
видимо вы не работале с ларавелем, джанго убогий недоделок, по сравнению с ларавелем, после перехода с пхп на питон с их джанго и фаст апи был шок их убогости по сравнению с пхпшными фреймворками
Alexufo
Сайт на плюсах можете сделать на drogon framework
MihaOo
Я не думаю что стоит обращать внимание на комментарий человека у которого 2 из 4 статей на хабре про JS. Ещё про РНРшников что-то пишет...
А с вами согласен, десктоп это вообще не о РНР имхо
SerafimArts
Тащемта написать нативное (именно нативное, а не то что в статье) приложение на PHP с нативными вызовами winapi (или чего другого) будет попроще, нежели на тех же плюсах (например). Другое дело, что в PHP просто нет экосистемы, которая бы упрощала всё это дело (вроде Qt, XAML, JavaFX, etc.), а работать с лоу-левел вызовами функций ОС — это боль.
simenoff
Как будто в нормальных языках проблем с GUI разработкой нет
s5656
А какие проблемы с GUI разработкой на C++, C#, Java и прочих подобных?