NativePHP: A framework for building desktop apps using PHP
nativephp.comThe documentation says it builds “truly native” apps, so I was expecting direct PHP bindings to native APIs and for the UI to be fully native (AppKit, GTK, etc.). On closer inspection, though, it’s just a PHP framework on top of Electron? A bit disingenuous.
Yeah, super disingenuous. Especially considering PHP is already native (unless you mean specifically compiled code). It also has direct bindings to GTK:
And other native libraries.
This project seems to conflate "native" with "has its own window" (versus running in a browser). While I would argue the more common understanding is "native" meaning "running outside of a sandbox/closed environment and directly on the OS". Ironically, using the latter definition, this project is less native than just coding PHP directly.
Never let the truth get in the way of good marketing.
NativePHP comes from a well-known member of the Laravel community, and the Laravel approach to promotion makes the hype in the early days of Ruby on Rails look tame.
I mean, it's from the same well-known group in the Laravel community that builds and abandons packages pretty quickly. Based on that track record alone, this should be a hard pass.
As a Laravel dev, sadly I have to agree, the developers other packages (which are not paid) are abandoned quickly :(
I recognize Marcel's name, but not the other copyright holder. I used to really like tinkerwell, though haven't needed it for some time. I'm curious, what else has this group built and a abandoned?
I have been out of the php game for a while, but I long for the Laravel ecosystem and community. I've yet to find things in other languages as cohesive or intuitive.
I guess you just can't forget your first love.
Wait, this PHP-GTK thing is abandonware! Last release in 2008, and only supports PHP 5.5.
Currently, and for most purposes (especially for new projects), PHP 7 is already being considered old... the amount of work that went into PHP 8 vs. PHP 5 is simply staggering.
PHP 5.5 is just too old to develop against!
The same applies to https://php-qt.org/ which "gives you" Qt 4 on PHP 5.1.
Fortunately enough, for those seeking a GUI toolkit for PHP, there's also WxPHP [1]:
https://github.com/wxphp/wxphp
[1] EDIT: WxPHP is being actively developed to support PHP 7 and 8 (there are no builds available yet)
When they said native, they actually just meant local.
No, they didn't. Unless you can Explain how:
Is any more local than:./Electron.app
Especially considering the former spins up an entire browser + PHP server instance, while the latter runs the code directly.php ./MyApp.pharWhat is more "native" about the former?
Nothing. In fact, it's less native (by most definitions, given it's running in a sandboxed environment). That's the whole point of this thread.
What's more native? Running a Python app that uses PyQT, or running a single purpose web browser in a window that calls a sandboxed+bundled Python server and renders HTML widgets?
In addition, OP was talking about locality. In both of the aforementioned examples, they're equally localized (both executing on the machine they're loaded on).
Yeah, when I saw the title I was hoping this was a revival or renewal of one of these projects.
"Contained PHP server that opens an electron window" is not exactly exciting or interesting.
I guess PHP is native in the same way JS/HTML is native?
PHP is native in the same way Python, Red, Java, etc are native. They have a VM, but otherwise interface directly with the OS.
It is in no way similar to JS/HTML in a browser (or Electron).
Is Nodejs native?
JS executed in a browser is not. The constraints were pretty specific.
PHP itself is more native than that in the sense that you can basically run PHP scripts on top of your OS, just like Python or Ruby
How is that not true for JS given node?
It's technically true, but JS/HTML is different from Node. JS/HTML is interfacing through the browser's DOM, while Node interfaces with the operating system itself.
But you specified JS/HTML, that's through the browser, and it doesn't have APIs for interacting with the OS as a normal language runtime does. JS on Node is about the same as PHP in this regard.
You can have script interpreted by a binary. Without a browser involved.
Electron is native. If you use windows APi or appkit, you are writing assembly code.
/s
What exactly is "native" about this?
I remember there was PHP bindings for GTK [0], which at least looked sort of native on Linux.
This could be cool if you can ship a large PHP backend codebase, allowing a web app to become an offline desktop app. You'd probably have to bundle a MySQL instance many cases though :)
> This could be cool if you can ship a large PHP backend codebase, allowing a web app to become an offline desktop app
Isn't this exactly that, just sqlite instead of mysql, html for the frontend
Hm. Maybe ODBC or just shopping a PHP client library could do it. It would be a little unusual, but something like PostgreSQL might be particularly well suited.
If it's running locally, just use an abstraction around the database and swap in SQLite for local builds.
I was thinking if you were using this as a client for a server-based database. If not, SQLite could certainly be the right choice.
Is GTK native? Isn't it just another library out of many you can utilize? Is it any more native than QT or wxwidgets?
For Windows and Mac OS native is clearly defined by the OS libraries that arenpvoded by the company.
For Linux to look very native you need to define the desktop environment. For stock Debian and Gnome desktop GTK bindings will look native. For OpenSuse with KDE QT will look more native.
Imho, in the context of a GUI library, native would mean it has the native look and feel of the platform and the performance.
This usually means the app is written in exactly the same language/framework/libraries as the built-in, pre-installed core apps.
Nowadays, users don't seem to care all that much though, and will tolerate a lot of crap and bloated apps, as long as it gets the job done.
Especially, shiny UI (which I hear many of my colleagues mix with UX) seems more important than anything for many; performance, latency/snappy-ness, memory use, cpu use, battery consumption etc. I can present a high performance, native, tiny binary product with excellent UX but shite UI and a slow, heavy, battery sucking product with horrible UX but great UI and most will pick the latter.
Now it's much easier to make that bloated shiny product, as you don't have to think about UX, performance, latency, memory leaks etc; you just stomp something together quickly, wrap Electron and ship. People who carefully weigh all the options and spend time making something great, generally don't get paid for their efforts. So why would they?
I’m a huge PHP fan. But hell, no.
Why don’t we use tools for the things they are good at? PHP as a backend server language is great, because it was built for it. Just like JavaScript is intended for web frontend applications. In my opinion, nodeJS was a mistake. It’s built upon layers of workarounds, and NativePHP looks exactly the same, just the other way around.
It’s not that hard to learn another programming language once you’ve learned one, so why not learn to code in a language that’s designed for your task, instead of trying to frankenstein some monster just so you don’t have to learn a new language?
Seen plenty of nice nodejs backends. Seen also some serious frankenstein PHP projects. Language really doesnt matter. The people behind it do.
I would say that the truth lies somewhere in the middle. Of course, people behind projects matter a lot. You can have robust and beautifully crafted PHP projects, and also horribly running, bloated and hacky Rust or Java projects. But, AndroTux has an absolutely valid point with saying that PHP was designed to run websites. Most languages have a clear focus of what they should and can do. There's the neat quote "your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should" and it pretty much sums up the matter. Some languages should stay with what they are made for.
Well said. I don't necessarily think that PHP can and should only do HTML rendering. Laravel for example includes a nice job queue which in my opinion makes perfect sense, as it is tightly integrated with the rest of the system, even if it's technically not what PHP was designed to do. But if you have to ship the interpreter and an entire browser just to make it work, maybe it's time to consider other options. And yes, that applies to JavaScript Electron apps as well. I can see the value in them from a business standpoint, but the amount of wasted PC resources just bugs me a lot. I don't want to waste 1 GB of memory just for a chat client.
You missed the point of this project. This lets you build a native desktop app using php and whatever front end technology you want.
I haven’t seen anyone talking about how this supports Tauri yet, so I’ll start: that’s pretty great!
For anyone who hasn’t heard of it yet, Tauri is a really nice Electron-like alternative that uses the system webview instead of shipping an entire copy of Chromium, and it’s written in Rust, so I’d presume there’ll be some way to call out to Rust from PHP.
I’m excited to see Tauri get more adoption. I’ve been building/selling a video editor with it for the past couple years and while it’s not always perfect, it suits my needs and I like that native performance is always an option when I need it. I’ve yet to run into a performance problem that is completely out of my control. Not to say my app is perfect, just that where it’s slow, it’s not JavaScript’s fault.
Isn't the problem with Tauri and similar solutions that any update of the webview can breake your app?
With Electron you know exactly which version of the browser engine you are using.
Sort of! On Windows, it's WebView2, which is more or less Chromium. On Mac it's the system's Safari, which I'm pretty sure is frozen at the OS release (or maybe gets updated with OS updates). So I'm less worried that it'll break with an update, but I've had to fix a few issues when someone is running on macOS 10.13 or something like that, where Safari is just missing some modern JS thing. I've solved that with polyfills and Babel and it's been alright.
CSS is the other issue, where old Safari doesn't support grid and some other stuff. So I stick to flexbox and well-supported stuff.
On macOS, Safari releases are independent of OS releases and show up as separate updates as and when they’re released. They may coincide on the date sometimes. It’s not like iOS where Safari updates never show up as separate updates, and are bundled with iOS updates.
Do you happen to know if the WKWebView always uses the latest Safari that's been installed? That's been the thing I'm uncertain about, where I think I've run into situations where the installed Safari should support some JS thing, but Recut doesn't actually have access to it, and I've suspected that WKWebView is just frozen at whatever the OS came with.
I don't really see how is that a problem. Webapps work pretty well despite the fact we have a bunch of different browsers – why the Tauri situation should be any different?
Thanks for this interesting info..
Also, Recut looks very nice. Do you mind if I ask what the full tech stack is for a video-editing app like that?
Thanks! It's Svelte, TypeScript, WebGL (for the timeline) and Tailwind on the UI side, and Rust for the backend that calls out to the libav libraries for the audio/video encoding/decoding. And there's a little Swift in there for some native Mac stuff.
Where is it slow? I'm assuming libav/libffmpeg stuff - or maybe just in IO cause videos are fat.
That's one place for sure, yeah. Video decoding is just resource intensive, especially if it's being done in software. Switching to hardware decoding is a big thing that's still on my todo list.
Beyond that, drawing the timeline efficiently took some work. I spent a bunch of time rewriting it to use WebGL recently, and before that it was some 2D canvas stuff. Plain old DOM elements slow to a crawl when there's 10k+ of them :D
Another little wrinkle is that calling between JS and Rust has a fair bit of overhead, so I try to minimize that and avoid sending lots of data back and forth. I think Tauri v2 is supposed to improve that a lot, but right now it's basically serializing everything to JSON and back. There's an alternative where you can send raw binary back and forth, and I'm using that in some spots. (re: the sibling comment about browser compatibility, I've got some fallbacks in place because old Safari didn't support it, heh)
Nice! I remember using a tool called Appcelerator Titanium about 15 years ago. It was like a precursor to Electron, and you could use various languages to build desktop and mobile apps - including PHP. It blew my mind at the time that this was possible.
https://benramsey.com/blog/2009/10/building-titanium-with-ph...
Glad to see the PHP desktop app dream has been kept alive :)
Shame that project went the way that it did. A bit ahead of its time if you ask me. There were a lot of controls that phones just didn't support well enough which complicated the project. It was more of a Cordova or Haxe than an Electron though.
Unbelievably, Haxe is still actively maintained. I keep saying I'll get into it, but I never do.
Thanks for sharing. Can you help me understand the difference between Cordova/Haxe and Electron? I mostly do web dev.
Your Scientists Were So Preoccupied With Whether Or Not They Could, They Didn’t Stop To Think If They Should.
On a serious note, this is absolutely badass. In the spirit of hacking, kudos!
The ideal market for this seems to be people with only PHP web app experience that need or want to build a "native" app, that otherwise wouldn't be able to do so with existing tools.
Some people with coding experience just like PHP.
I have pushed production apps in php, go, .net, java, and j/ts. Touched some Django and Rails along the way. For fun I have played with elixir and more I can't think of at the moment.
I'm personally never as productive and happy as when Laravel happens to be the right tool.
Exactly. I’ve been writing JavaScript as long as I have been writing php and I prefer PHP by a lot.
Laravel is an incredibly productive framework and being able to build desktop apps with Laravel is a dream!
I agree Laravel is a great framework. I use elixir Phoenix as well (similar philosophy). But that doesn't seem like a good model for a desktop app, especially when there are tools like electron where you could build a SPA. The whole route based model makes a lot of sense for web, but on a desktop?
Native is such an overused word. Lately I have to argue with clients what’s really native or not.
GenPop thinks native means an app one can download and run, with tight integration with OS services.
Not things like native WM, or os supplied libs/tooling.
Native describes the user-feeling, not the developer-technology-analysis.
If I can download and install Discord on my PC, I would describe it as a "desktop app". We have the desktop, we have mobile, and we have the web.
The word "native" shouldn't even be in a user's vocabulary. And I believe it wasn't until Electron polluted the world with inefficient wrappers around a Chrome tab with a custom icon slapped on top.
Once we were living that nightmare, developers of apps aimed at power users, who actually bothered to create a good experience, started differentiating themselves by offering "native apps", as in, "we actually coded an app for your OS". And as the time went by, the Electron web app resellers adopted the term as well.
Yah, and in this particular case it’s not.
Bummer. Quick and dirty desktop app in php might be something interesting
I am a bit surprised by the critical tone in the comments here. Phpdesktop [1] is, for example, a very nice application, and the ability of php to just make some simple scripts on the go and have something that works, is wonderful (compared to js where you often have to build etc, the threshold of getting started on a new computer is high). I have several times needed to make simple applications with a database, and php is perfect for that usecase. Making it simpler to share these applications to non-technical users for offline use is nice
Honestly excited about this, I am one of those people that really love PHP from the old days and I still use it from time to time to build small web apps and api's. I don't get the hate that PHP usually gets, I've always kinda liked it.
These days I mostly program in C, CAPL and Python but I would love to build apps in PHP.
PHP in 2023 is a great language, I always scoff when somebody tries to imply that Python or JS are "clearly superior" languages to PHP (which, to me, is a clear sign of illiteracy). But I am also kind of "the right tool for the job" proponent. Now is PHP the right tool to build Desktop Apps?
- It is cumbersome to distribute. Rarely people have PHP installed outside of a docker container, and given quite short development lifecycle chances are their version of PHP is already outdated.
- Concurrency support in PHP is still very poor. That seems quite a big deal for a desktop app.
- NativePHP is anything but native. It relies on Electron, which is somewhat questionable on its own (even though very common nowadays).
- …And, since it pretty much is just Electron, why do I need a Laravel app underneath anyway?! If there is a job for JS, it's exactly programming UIs (primarily because there are millions of UIs and thousands UI-targeted libraries written in JS by now)
So, I am very skeptical.
> But I am also kind of "the right tool for the job" proponent. Now is PHP the right tool to build Desktop Apps?
If you work in a largely PHP shop and want a quick internal tool to solve some business need or something, sure.
I mean, you are completely right. Those are very valid points. But this still sounds sorta fun to me, I like crazy projects :)
>> why do I need a Laravel app underneath anyway?!
I don't know much about nativephp/electron/desktop ui's, but I would guess Filament is a pretty decent reason.
Good point, building a desktop app with filament would probably be quite fast!
NativePHP solves the distribution problem, I’d say that’s precisely why it exists. Plus Laravel + Livewire is incredibly fun and fast to build with.
php years ago was a great lang...
The fact that is less popular now, being replaced as the "new shiny" by JS and Python as gotten alot of new devs out of the space which is what caused the vast majority of the negative press around php, it was never the language, but the fact that is was very approachable and very forgiving for new devs so alot of them did stupid things
> it was never the language
That's just, not correct. I programmed web sites primarily in PHP back in the PHP3-5 days (and have had some jobs and contracts since, in PHP7+).
PHP, pre-5.3ish, was a bad language. It had terrible design decisions, a polluted global space, bad default configurations, weird scoping rules, function/objects with massive security holes that the developer had to patch around (the MySQL functions, being notorious) and a terrible object model. PHP5-5.3 did a lot to fix that, and 5.3+ became a usable language. PHP7 finally did a ton of work to clean up the global environment, deprecate and toss out old/buggy libraries, clean up the ABI and improve performance. They also reworked the object model completely. It is now a genuinely decent language. But it was not "always great".
It wasn't great, but it was available and that is what got it to levels of popularity that other language eco-systems can only dream of.
Laravel has a dedicated marketing page specifically targeted towards JS-first developers:
Besides echoing the sentiment that PHP ~3-5 was definitely NOT a good language, I don't know what you mean by new shiny. JS is like 6 months newer than PHP and python is like 4 years older.
The age of the lang is not the point, the popularity / adoption of it is.
Lost of things are created and never get exposure for decades after their creation
Totally agree, modern PHP is quite fun.
I kinda hope PHP would adopt java-like types for strings etc, to somewhat clean up the mess of its functions, e.g for strings - instead of str_contains, strtr, substr_compare you can do $myString->contains("test");
https://github.com/nikic/scalar_objects provides it as a plugin, but its not fully fleshed out.
No please no. PHP is a top layer of C. Not Java.
Laravel has a Str class that does exactly that.
I've used PHP daily for over 10 years. Honestly, my favorite language, along with Python. "It just works" on pretty much every Linux distro out of the box.
So, I’m incredibly enthusiastic about this.
It’s ok if you aren’t, but I am.
Development is easier when we keep more things the same. It saves energy for a Laravel developer to deploy to Mac using the same code, tools, and architectures as their web app. This won’t be true for all mac apps, but certainly will be for some.
Maybe NativePHP turns into a big deal and helps a lot of people deliver great experiences or maybe it doesn’t…but I’m grateful to the team for their effort pushing the boundaries.
Alas. If only it were possible to host a Laravel app on the internet.
There are often times you want something that runs offline easily or can be distributed per-user without dealing with multi tenancy, etc.
Sure, but packaging a web app with a PHP framework in a Chromium wrapper to accomplish that is still ridiculous.
I don't care how ubiquitous the whole "web apps are now native apps" paradigm becomes, it will never not be ridiculous.
Somehow related, I've been using pywebview for some internal tools: https://github.com/r0x0r/pywebview
Probably not as full-featured as Electronjs, but since we have a bunch of python scripts to convert to desktop apps, it's very useful.
dang can you update the title to reflect that this is a framework for building Electron apps in PHP? The name they've chosen is unfortunate and some are feeling misled.
Should be called ElectronPHP
Pretty much. Why would I use this instead of vanilla Electron?
It bundles the PHP run time for you.
I like PHP, bit even I have to ask... Why not just use JS that comes with electron rather than bundling a third party language?
Because of Laravel and Livewire.
How awful.
Meh. Compared to electron itself it’s probably not much. But calling it native is kinda weird.
photon
PHPoton
or ElectronLaravel
> NativePHP is taking the world by storm…
I like PHP, but this made me chuckle.
Great. PHP became a very good programming language. Sadly it has to fight with a bad reputation from its past.
In the same kind of spirit but for Python I recently discovered pywebview. It really is amazing how simple and fast these tools make developing little apps that can be run locally, without your users needing to manually launch a server or you worrying about the browser.
Are there any screenshots anywhere to understand what kind of app this is for?
Building native apps when you learned to program in 2005 and refuse to learn anything new.
theForger's Win32 API Programming Tutorial [1] was available in 2001 according to archive.org, showing how to build actual native applications without anything even remotely new.
$NativePHP: A $framework for $building $desktop $apps $using PHP
Uncaught error: Undefined constant "A" Uncaught error: Undefined constant "for" Uncaught error: Undefined constant "PHP"
So it ships Electron and a PHP runtime - What else can we include?
Apache
A k8s implementation
k10k (aka the "kitchen sink")
large language model
jvm too, so we can write once run anywhere
It ships with two web servers, per the Security page.
Wordpress
Don’t give them any ideas.
Everyone is focusing on the fact that `native` is not applicable to the current implementation. I think if done right, It can come quite handy
I'm a bit confused by the fact that all code samples in the docs are missing PHP tags.
I assume they're still required since leaving them out would probably mess up all editor and tooling support.
Despite the great improvements PHP has seen lately it will always be a template language for me as long as you have to write your code between those tags.
There is nothing 'native' about this at all. Just a PHP library on top of Electron against the claim of "truly native" apps.
why php though?
Many people enjoy working with it, it's perfectly fine for almost everything and it's fast enough? I mean, why not?
Other apps bundle entire runtimes for other languages, I don't see how PHP would be any different
Speaking as a security professional, for the love of God, why?
(1) because they could
(2) because it runs on top of electron so it is mostly a local affair
(3) because some people might want to build a desktop app but don't have overlapping skills with desktop programming languages
I don't see why they shouldn't be doing this. But, since you are a security professional, please point out why this is more or less secure than anything else built on top of electron?
PHP is notoriously insecure. https://www.cvedetails.com/vulnerability-list/vendor_id-74/p...
Just because it runs on a desktop doesn’t mean that it won’t be exposed to malicious code.
Why do people keep trying to resurrect PHP?
Resurrect? PHP never died. It’s still going strong today with frameworks like Laravel.
I guess because we keep cashing fat checks with it?
Does anybody think that something like this is useful except as an academic exercise? I can't get there.
There are many languages better suited to delivering native apps. The pitfalls of electron are already well understood. If you need electron ANYWAY, then you might as well just use electron.