NativePHP: A framework for building desktop apps using PHP
nativephp.com
nativephp.com
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.
./Electron.app
php ./MyApp.phar
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).
It is in no way similar to JS/HTML in a browser (or Electron).
"Contained PHP server that opens an electron window" is not exactly exciting or interesting.
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 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.
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)
/s
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 :)
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.
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.
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?
Isn't this exactly that, just sqlite instead of mysql, html for the frontend
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?
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.
Also, Recut looks very nice. Do you mind if I ask what the full tech stack is for a video-editing app like that?
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)
With Electron you know exactly which version of the browser engine you are using.
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.
https://benramsey.com/blog/2009/10/building-titanium-with-ph...
Glad to see the PHP desktop app dream has been kept alive :)
Unbelievably, Haxe is still actively maintained. I keep saying I'll get into it, but I never do.
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.
I'm personally never as productive and happy as when Laravel happens to be the right tool.
Bummer. Quick and dirty desktop app in php might be something interesting
Not things like native WM, or os supplied libs/tooling.
Native describes the user-feeling, not the developer-technology-analysis.
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.
These days I mostly program in C, CAPL and Python but I would love to build apps in PHP.
https://github.com/nikic/scalar_objects provides it as a plugin, but its not fully fleshed out.
- 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.
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
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".
Lost of things are created and never get exposure for decades after their creation
If you work in a largely PHP shop and want a quick internal tool to solve some business need or something, sure.
I don't know much about nativephp/electron/desktop ui's, but I would guess Filament is a pretty decent reason.
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.
I don't care how ubiquitous the whole "web apps are now native apps" paradigm becomes, it will never not be ridiculous.
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.
I like PHP, but this made me chuckle.
Uncaught error: Undefined constant "A"
Uncaught error: Undefined constant "for"
Uncaught error: Undefined constant "PHP"A k8s implementation
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.
Other apps bundle entire runtimes for other languages, I don't see how PHP would be any different
(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?
Just because it runs on a desktop doesn’t mean that it won’t be exposed to malicious code.
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.