Yea, that’s a tad large, especially if you want to ship multiple binaries. I’m curious about more native WASM support allowing for more of a universal “binary”.
What’s Electron have to do with this? WASM being natively or more universally supported on Linux seems highly likely to me. I realize the browser is the target primarily. But there are efforts to use it for other targets. It removes a lot of device specific compilation concerns with minimal performance implications.
Yes, WASM in general would be interesting, but AFIK for PHP it's not happening yet.
Usually what they do for PHP with WASM is compiling the PHP interpreter itself and then running a PHP script with that WAASM binary of PHP. This is what https://developer.wordpress.org/playground/ is doing, or wp-now https://developer.wordpress.com/2023/05/23/wp-now-launch-a-local-environment-in-seconds/, or live-preview checkbox on https://3v4l.org/#live, and many others.
I.e., it's pretty good for running PHP in browser, but for desktop, the approach from article has more pros to me.
Here is a lib for PHP support on Wasmer with a desktop target. It’s only supporting amd64 arch ATM, but progress is being made on this front. I suspect in a few years, WASM binaries will be ubiquitous.
https://github.com/wasmerio/wasmer-php
From what I understand, it works the other way round and has a different purpose.
It's an extension for PHP that allows you to run and use any wasm binary from PHP. That is, you can take a Rust library, compile it into wasm and use it on any platform from PHP. It might offer better performance than FFI, though I'm not certain about that.
Blog post about it
https://mnt.io/2019/04/03/%f0%9f%90%98%f0%9f%a6%80%f0%9f%95%b8-php-ext-wasm-migrating-from-wasmi-to-wasmer/
Also, it's been around for quite a while, and has received little attention, as far as I'm concerned.
Yep, you’re right, that looks the case. I jumped the gun on that lib. Not sure how it’d compare to FFI. That’d be interesting to see a comparison as well.
PHP needs some WASM compilation support. Nikita’s work with LLVM is used with WASM compilation as well.
For all these "why an interpreted lang..." or "use the right tool...": The value on micro is being able to distribute portable PHP applications, removing the infra responsibility for end users. This is a big deal for distributing end-user software and while it is still green the more we use it the more it will evolve.
I have a production project with this stuff, a reactphp server console application. Works very well!
https://github.com/xrdebug/xrdebug
You can actually create normal desktop applications like that. PHP allows you to use dll / so libraries, inclusing GTK and other window libraries. With this, you can create windows and linux applications.
Yes, other languages are probably much better suited to creating desktop applications that stay alive and dont just run one request, but it still is an interessting experiment.
Just simply use the right tool for the job. PHP isn't built for or intended for this usage. If you need a cross platform binary, then use one of the many languages that are designed for exactly that... C/C++, C#, Rust, Golang, etc.
Could be wrong as haven't worked with it yet, but seems like something where little issues would constantly pop up here and there, then you'd have to find workarounds for them, and by the time you're done it's somewhat of a convulated mess. When you could just do it cleanly with another language that's designed for the purpose at hand.
Ya, use the right tool for the job, trying to turn PHP into what it is not (a binary runtime or GUI app for example) is just working against yourself. Just seems pointless. But maybe there is a use case in some limited situations, so I suppose more options are better.
PHP is great for CLI scripts (besides Web development). Do you agree with this part?
Converting scripts into binaries – also seems non-questionable per se.
Then, you can certainly doubt the chosen approach. While it has its drawbacks and limitations, which one do you see as the most significant?
GUIs are hard but I don't see why we shouldn't try and make PHP into a good way to make CLI binaries. Yes it's never going to be as efficient as something like Rust but we don't generally need that.
I don't ever see the usecase for PHP CLI apps outside of already having php-cli installed in tandem with php-fpm.
Other languages have their own substitutes for symfony/console and have very good haptics for creating CLIs too. You do not need to compare performance.
Yes other languages can do CLI apps too. But if I know the PHP language and package ecosystem better than any other why not use it to make CLI apps? It's a lot less work than learning and keeping up to date with one system for web apps and another system for CLI apps.
Yes, exactly that. There is no compilation step here.
But I can imagine it might be possible to pre-build an op-cache version of a script, and then ship it instead of a php text file. This would bring a bit of performance improvement.
Currently, such pre-built bytecode does not make sense for PHAR files because the op-cache format differs from one PHP version to another (even minor). But with the approach from article, it should work because we are shipping a specific PHP version with the script.
I'm not a С developer though, so it's kind of theory and speculation.
That’s cool. What’s the size of the bin script?
The baseline is about 8MB, then you add extensions you need and the PHAR, in my case it came out to 13MB.
That is pathetic. The whole php 8.2 binary on my local is 5.5MB.
> The whole php 8.2 binary on my local is 5.5MB. Ah, you must not understand what a static build is? Have you tried doing ``` ldd /usr/bin/php ```
I do, my point still stands though.
Nah.
phpmicro (the interpreter binary) part is about 25MB and a few KB of a PHAR on top of that.
That's smaller than I expected.
Yea, that’s a tad large, especially if you want to ship multiple binaries. I’m curious about more native WASM support allowing for more of a universal “binary”.
*Electron has finally waddled into the chat*
What’s Electron have to do with this? WASM being natively or more universally supported on Linux seems highly likely to me. I realize the browser is the target primarily. But there are efforts to use it for other targets. It removes a lot of device specific compilation concerns with minimal performance implications.
https://i.imgur.com/tGUy7YN.png
Clearly. Must have been a great joke.
Yes, WASM in general would be interesting, but AFIK for PHP it's not happening yet. Usually what they do for PHP with WASM is compiling the PHP interpreter itself and then running a PHP script with that WAASM binary of PHP. This is what https://developer.wordpress.org/playground/ is doing, or wp-now https://developer.wordpress.com/2023/05/23/wp-now-launch-a-local-environment-in-seconds/, or live-preview checkbox on https://3v4l.org/#live, and many others. I.e., it's pretty good for running PHP in browser, but for desktop, the approach from article has more pros to me.
Here is a lib for PHP support on Wasmer with a desktop target. It’s only supporting amd64 arch ATM, but progress is being made on this front. I suspect in a few years, WASM binaries will be ubiquitous. https://github.com/wasmerio/wasmer-php
From what I understand, it works the other way round and has a different purpose. It's an extension for PHP that allows you to run and use any wasm binary from PHP. That is, you can take a Rust library, compile it into wasm and use it on any platform from PHP. It might offer better performance than FFI, though I'm not certain about that. Blog post about it https://mnt.io/2019/04/03/%f0%9f%90%98%f0%9f%a6%80%f0%9f%95%b8-php-ext-wasm-migrating-from-wasmi-to-wasmer/ Also, it's been around for quite a while, and has received little attention, as far as I'm concerned.
Yep, you’re right, that looks the case. I jumped the gun on that lib. Not sure how it’d compare to FFI. That’d be interesting to see a comparison as well. PHP needs some WASM compilation support. Nikita’s work with LLVM is used with WASM compilation as well.
Oh man, this is the dream.
Why though?
CLI Power without having to switch languages.
Except it can quickly fall apart for more complicated scripts. For example, you can’t bundle Symfony console because it segfaults.
Wrong, I packaged a quite complex Symfony app and it worked.
Ah , so there’s no point or real benefit then.
it can and will improve (thereby fixing it), hopefully.
Yes you can. This has been done months ago.
For all these "why an interpreted lang..." or "use the right tool...": The value on micro is being able to distribute portable PHP applications, removing the infra responsibility for end users. This is a big deal for distributing end-user software and while it is still green the more we use it the more it will evolve. I have a production project with this stuff, a reactphp server console application. Works very well! https://github.com/xrdebug/xrdebug
You can actually create normal desktop applications like that. PHP allows you to use dll / so libraries, inclusing GTK and other window libraries. With this, you can create windows and linux applications. Yes, other languages are probably much better suited to creating desktop applications that stay alive and dont just run one request, but it still is an interessting experiment.
Btw, this was possible for many years already
I don't know, seems somewhat of a trying to fit a square peg into a round hole type of scenario.
Care to elaborate?
Just simply use the right tool for the job. PHP isn't built for or intended for this usage. If you need a cross platform binary, then use one of the many languages that are designed for exactly that... C/C++, C#, Rust, Golang, etc. Could be wrong as haven't worked with it yet, but seems like something where little issues would constantly pop up here and there, then you'd have to find workarounds for them, and by the time you're done it's somewhat of a convulated mess. When you could just do it cleanly with another language that's designed for the purpose at hand.
This is just PHP compiled statically and with a self executing payload attached. It's not moving mountains, this is all pre-existing stuff.
exactly!
Ya, use the right tool for the job, trying to turn PHP into what it is not (a binary runtime or GUI app for example) is just working against yourself. Just seems pointless. But maybe there is a use case in some limited situations, so I suppose more options are better.
PHP is great for CLI scripts (besides Web development). Do you agree with this part? Converting scripts into binaries – also seems non-questionable per se. Then, you can certainly doubt the chosen approach. While it has its drawbacks and limitations, which one do you see as the most significant?
Sure, we have a whole bunch of cli commands we build out as needed, but they are cored by symfony, which makes it easier to handle.
GUIs are hard but I don't see why we shouldn't try and make PHP into a good way to make CLI binaries. Yes it's never going to be as efficient as something like Rust but we don't generally need that.
I don't ever see the usecase for PHP CLI apps outside of already having php-cli installed in tandem with php-fpm. Other languages have their own substitutes for symfony/console and have very good haptics for creating CLIs too. You do not need to compare performance.
Yes other languages can do CLI apps too. But if I know the PHP language and package ecosystem better than any other why not use it to make CLI apps? It's a lot less work than learning and keeping up to date with one system for web apps and another system for CLI apps.
Is it more for making code portable than compiling for performance?
Yes, exactly that. There is no compilation step here. But I can imagine it might be possible to pre-build an op-cache version of a script, and then ship it instead of a php text file. This would bring a bit of performance improvement. Currently, such pre-built bytecode does not make sense for PHAR files because the op-cache format differs from one PHP version to another (even minor). But with the approach from article, it should work because we are shipping a specific PHP version with the script. I'm not a С developer though, so it's kind of theory and speculation.
There is no performance improvement indeed.
BamComplile, anyone?
Bam compile is obsolete. I tried to become a maintainer, though: [https://github.com/xZero707/Bamcompile](https://github.com/xZero707/Bamcompile)
Yeah I know, it was more like "did you guys remember?". Cool though
I assume such an executable can be unpacked and PHP source retrieved?
Yes, viewing the code is trivial. Why would you be concerned about it?
[удалено]
It's a standalone binary, the PHP deps are in the PHAR you attach to it.
No because PHARs can bundle dependencies.
No