The 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:
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.
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.
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.
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).
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.
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 :)
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.
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.
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?
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?
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.
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.
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! 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.
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.
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.
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.
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.
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?
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.
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)
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".
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.
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");
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.
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.
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.
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.
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.
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.
(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?
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.
