30 Years of PHP and FrankenPHP  ## Metadata - Author: [[PHP Annotated]] - Full Title: 30 Years of PHP and FrankenPHP - Category: #articles - Document Note: --- tags: - #php - #frankenphp - #webdevelopment Author: Rasmus Lerdorf, Kevin Bond, and PHP Foundation contributors Source: Transcript of "30 years of PHP and FrankenPHP" YouTube livestream (https://www.youtube.com/watch?v=ftvZWgMt6kM) Reference: Transcript and official PHP blog posts from June 2025 date created: 2025-06-11 12:00 --- # Title: 30 Years of PHP and Introduction to FrankenPHP ## Table of Contents:  - 🎉 [Summary of PHP's 30 Years](#summary-of-phps-30-years) - 🚀 [Introduction and Features of FrankenPHP](#introduction-and-features-of-frankenphp) - 🧑‍💻 [Community Discussion on PHP Version Support](#community-discussion-on-php-version-support) - ⚙️ [FrankenPHP Setup and Usage Demonstration](#frankenphp-setup-and-usage-demonstration) - 🔧 [Worker Mode and Performance Considerations](#worker-mode-and-performance-considerations) - 📦 [Embedding Applications and Static Binaries](#embedding-applications-and-static-binaries) - 🐳 [Docker and Deployment Challenges](#docker-and-deployment-challenges) - 🔮 [Future Outlook and Ecosystem Integration](#future-outlook-and-ecosystem-integration) ### References: - [YouTube: 30 years of PHP and FrankenPHP](https://www.youtube.com/watch?v=ftvZWgMt6kM) - [PHP Foundation Blog on FrankenPHP](https://php.net/blog) - Kevin Bond's FrankenPHP GitHub repository - Discussions from PHP Verse 2025 event ## 📝 Summary: This transcript covers a livestream discussion celebrating 30 years of PHP, focusing on the announcement and exploration of FrankenPHP—a modern, high-performance PHP application server integrated with the Caddy web server. The presenter addresses community concerns regarding PHP version support in packages, setup and usage of FrankenPHP, performance comparisons, and deployment strategies including static binary embedding and Docker usage. The talk also highlights the challenge of maintaining legacy PHP applications and stresses the importance of sustainable maintenance practices and modern tooling. ## 📖 Main Content: The talk opens with remarks about PHP's 30th anniversary and upcoming events celebrating its legacy. The presenter stresses the need for modern PHP version support in active packages while recognizing real-world challenges in upgrading legacy applications. A key part of the discussion is a community comment reflecting on the difficulty of maintaining large, old codebases, and the balance needed between forcing upgrades and preserving stability. FrankenPHP is introduced as a major step forward, combining PHP with the Caddy web server to simplify deployment, improve performance, and reduce hosting costs. Features such as worker mode (keeping apps in memory), native real-time protocol support, and embedding PHP apps into static binaries for easy distribution are explored. The livestream demonstrates downloading, installing, and running FrankenPHP in classic mode, including troubleshooting and performance comparisons with Nginx. The presenter highlights the ease of setup, configuration, and potential benefits for PHP development and deployment workflows. Challenges around DevOps and Docker are candidly discussed, acknowledging the complexity but also showing practical steps to build and deploy PHP apps with FrankenPHP. ## 🗒️ Notes ### 🎉 Summary of PHP's 30 Years [0:18 - 3:58] - PHP released June 8, 1995 by Rasmus Lerdorf. - Powers a significant portion of the web (~70% estimated). - Community events like PHP Verse celebrate PHP's ecosystem. - Recognition of PHP's evolution and increasing complexity. ### 🚀 Introduction and Features of FrankenPHP [25:00 - 29:40] - FrankenPHP joins PHP Foundation organization. - Combines Caddy server with PHP interpreter into a single binary. - Features include improved performance, lower hosting costs, real-time capabilities via Mercure protocol. - Allows extension with Go, C, C++. - Simplifies deployment on bare metal or cloud environments. ### 🧑‍💻 Community Discussion on PHP Version Support [5:00 - 23:00] - Debate over forcing minimum PHP version support (8.1+). - Real-world challenges maintaining decade-old apps with legacy dependencies. - Consequences of delayed upgrades include code rot and security risks. - Advocates for scheduled annual upgrade windows. - Calls for companies to financially support open-source maintainers. - Forking abandoned packages as a practical workaround. ### ⚙️ FrankenPHP Setup and Usage Demonstration [32:00 - 42:00] - Downloading and moving FrankenPHP binary. - Running FrankenPHP server in classic mode (drop-in replacement for PHP-FPM). - Serving local PHP projects (e.g., Tempest framework). - Basic configuration and port assignment. - Quick success with serving a PHP app on localhost. ### 🔧 Worker Mode and Performance Considerations [37:00 - 45:00] - Worker mode boots app once and keeps in memory for faster response. - Challenges with managing persistent DB connections. - Laravel and Symfony support planned. - Early benchmarks show slight speed improvements over Nginx local setup. ### 📦 Embedding Applications and Static Binaries [45:00 - 51:00] - FrankenPHP can embed PHP apps and assets into static binaries. - Self-contained binaries include PHP interpreter and Caddy server. - Production-ready builds require stripping dev files, setting env vars. - Supports custom config files for embedded apps. - Deployment can use GitHub Actions or build servers. ### 🐳 Docker and Deployment Challenges [55:00 - 64:00] - Use of Docker for static binary builds discussed. - Performance and image size considerations. - Presenter openly shares DevOps learning curve and frustrations. - Docker images can be large (~1GB layers). - Potential for simpler production deployments without Apache/nginx. ### 🔮 Future Outlook and Ecosystem Integration [29:40 - 30:40; 60:00 - 64:00] - Anticipation of PHP's future integration with FrankenPHP. - Event announcements at PHP Verse highlighting roadmap. - Potential for PHP to be compiled to a binary for production. - Streamlined real-time support via Mercure protocol. - Collaboration between PHP Foundation, Caddy team, and Letier company. ## 📖 References: - [PHP Foundation Blog: FrankenPHP Announcement](https://php.net/blog/frankenphp-announcement) - [FrankenPHP GitHub Repository](https://github.com/php/frankenphp) - [Caddy Web Server Official Site](https://caddyserver.com/) - [Mercure Protocol for Real-Time Communication](https://mercure.rocks/) - [PHP Verse 2025 Conference](https://phpverse.com/) ## 🗣️ Paraphrase: 1. Original: "FrankenPHP offers features unique in the PHP ecosystem: drastically improved performance, real-time capabilities through native protocol support, and easy deployment across bare metal or cloud environments, all bundled in a single binary with the Caddy web server." Paraphrase: FrankenPHP brings unprecedented features to PHP, including significantly enhanced speed, built-in real-time communication, and straightforward deployment on any infrastructure. It combines the PHP interpreter and the Caddy server into one compact executable. 2. Original: "Maintaining legacy PHP applications is challenging because forced upgrades can break dependencies, leaving large, complex codebases stranded without migration paths, and unpaid maintainers struggle to keep pace with rapid version changes." Paraphrase: Upgrading old PHP apps is difficult since mandatory updates risk breaking critical dependencies, trapping extensive and complicated projects without clear upgrade routes. Moreover, many maintainers lack compensation, making it tough to keep up with fast-evolving PHP releases. ## 📰 Newsletter: Hey WordPress fam! 🎉 This week we’re celebrating 30 years of PHP—the language powering over half the web! To mark this milestone, a game-changer called FrankenPHP has officially joined the PHP Foundation. Imagine PHP bundled with the blazing-fast Caddy server in a single binary, offering insane performance boosts and real-time features powered by Mercure. Plus, deployment just got way simpler—whether on bare metal or cloud. 🚀 If you’re maintaining legacy PHP projects, you’ll relate to the struggle with version upgrades breaking dependencies. The community’s buzzing about - Summary: Today we take a look at FrankenPHP! #php #webdev #oss - URL: https://www.youtube.com/watch?v=ftvZWgMt6kM Oh, heat. Huh? Hey, hey, hey. Good morning. Good morning, everyone. Hey, say hi in chat if you're here. Hello, Adrian. Good to see you on Twitch. There are a couple of people on YouTube as well. Glad you're here. I hope that uh intro thingy waiting queue thing was good. I don't know. Experimenting. And uh yeah, today we're going to do some experimentation as well with Franken. PHP intro was nice is is uh what Adrian says. That's good. That's good. Hey Yoges, you're here as well on YouTube. Good to see you. Good to see you. It's a beautiful day outside and I'm here in my room. I've got the blinds closed and I'm ready to spend an hour in front of my computer talking to you. That's uh what I plan on doing and I'm looking forward to it. I'll spend some time outside later today, but right now it's a it's a good time to uh to sit down and have a good time together. So, hey folks, PHP uh has turned 30 um last weekend, I believe, June 6, 7th, something like that. And um yeah, I'm so looking forward to next week where we'll have PHP verse, which will be a live stream event. You might have heard of it already. Um I'm going to host it. It's going to be a six to seven hour live stream. It's going to be tiring, but it's going to be great. We'll have some awesome speakers, Nicholas Greas and uh Taylor Otwell, some people from the education scene as well. And then there will uh be Kevin Douglas as well, who is the creator of Franken PHP. So, that's pretty nice. It all works out as if it is planned, which like this stream wasn't. I woke up today and I was like, "Hey, I still need to look at Franken PHP." And it might be like a good time to do it now before uh PHP verse starts, right? So uh so yeah, Yuris is here on uh on Twitch as well. David, and I'm sorry if I pronounce your name incorrectly, Ausu, I reckon. Uh something like that on YouTube. Hey, it's good to see all of you. Thanks for joining. So Franken PHP. Well, actually before we dive into Franken PHP, oh, I need to there there is something I need to talk about real quickly. Um, I I made this video yesterday, right? Um, a short snippet of of my stream. And actually, let me uh let me do this over here. Um, so I made this video um a summary of of the stream we did two weeks ago about um package versions, right? And how packages in PHP uh a lot of packages still support very outdated PHP versions. And there was this one comment that I really liked. um not because I agree with it because but you know it it it highlights a couple of good things and I wanted to read it here um because I think it's important to you know talk about the other side as well. So, um, so yeah, setting the scene real quickly before we dive into into Frank and PHP, right? But, um, I talked about, um, I I look at at the top thousand packages on packages, active packages. Uh, that's important. And I check their composer JSON version and see what the minimum required PHP version is um that they support basically. And my vision, my point of view is that package authors of actively maintained packages should really push forward to more um modern PHP versions. Um supported PHP versions. I'm not saying you should support 8.4. Although I would do that and just only support 8.4, but 8.1 at a minimum, you know, the versions that still get security updates. Um and that really like for the majority of packages that's not the case. Um, and um, yeah, this is something people disagree on and I have I have a lot of respect for that. And there was one comment uh that came on this video that uh, yeah, I wanted to look into. By the way, Adrian here on on uh, Twitch says, "This video motivated me to write my own statistics uh, version thing last night." I know. And I saw you sending a message on Twitter about that, Adrian. I actually want to check it out because the way I'm parsing statistics is uh it works but that's all there is to say about it. Um well maybe it doesn't work. Maybe there there are slight bugs in it. Although um like I did test this out quite quite a lot. So you know it is pretty accurate. There might be some mistakes here and there but like for the majority of of stats over here um it looks to be pretty accurate. So, but uh let's see let's let's take a look at this comment here. I disagree with forcing the latest PHP version, which is basically what I'm saying. Or if you don't want to go only latest version support like uh only the versions, the PHP versions that are actively maintained or still get security releases. So 8.1 that's four PHP releases, right? Four years of um supporting PHP versions. Um but let's read read here. It's a naive fix that ignores real world dev challenges. Most PHP devs aren't YouTubers. Check. Framework authors. Checked. Or scriptkitties chasing trends. I don't think I'm a script kitty chasing trends. I don't know. They're maintaining massive decade old apps under tight constraints. Now, I know a thing or two about these kinds of apps. I'm not working on that kind of projects right now, but uh I I have done so for 10 years. So uh force upgrades break dependencies stranding 100k plus line code bases with no migration path. Countless packages get abandoned because unpaid maintainers can't get up can't keep up with relentless new versions. This is this is this is gold. But okay, let me read the whole comment first. This churn pushes devs and packages out of the PHP ecosystem, shrinking it. themes end up freezing PHP versions isolating systems in VMs and adding firewalls to avoid security disasters. Consultants jumping between short-term gigs don't get the long-term grind of legacy systems. Their mindset creates junk otherers have to support. I think this is a really valuable comment and that's why I I I did want to like start this stream just taking some time and and talking about it. Um because there there are a a lot of things to to unpack here. Um first I I agree that like I'm not working on any big client projects anymore. That's part of like result of the job I'm doing right now being a developer advocate for PHP. But it's really important. This is actually part of my job description to keep in touch with uh the community and these kinds of projects because I am trying to represent like the PHP community or a part of that. Um so it is really important for me to to properly understand what's going on. So it's really valuable. This comment is really valuable to me. Um although I don't think I'm a script kitty. Um but they're like real real life things. Uh projects massive decade old apps under tight constraints forced updates break dependencies stranding a 100k line code bases with no no migration path. So first thought here is that the longer like this is a problem that that only becomes worse over time like the longer you um don't touch a codebase it will rot code rot right it's a thing you cannot explain this to to people who don't code but you just you don't touch a codebase for a year things will break and that's because of dependencies dependencies update and um you rely on external factors you Um, but the longer you wait, the longer you hold off on um, actually getting up to date with stuff only the the bigger the problem becomes. And from what I'm reading here, um, in like I don't know the the the concrete context, but uh, I would say that I I've seen these kinds of projects as well, like where you where you just don't feel like doing the update right now and a year later you're like, "Oh, no, now it's become such a big thing. Let's just not touch it because it's working, right?" But this eventually leads to two projects that still work that are a mess to maintain. And I would say that's not because of like the third parties evolving, right? We're talking PHP, but we're also talking like just everything basically, web servers, um um operating systems, server operating systems, like there are so many things that you build on top of and that you cannot really control. People like projects need to move forward. software needs to evolve because otherwise they end up in the same place you end up. Right? So, so you cannot get around this fact that in order to for a codebase to stay healthy, you need to move along there. You you cannot like own everything basically. So, uh this this it all starts with a mindset, right? And I totally get it that once you're down a path in a 10-year-old codebase that never that never accepted or or never started with that mindset of we're going to properly maintain this then yes of course it is going to be a big pain because and and then you end up in I like this I like this where the isolated systems in VMs and firewalls to avoid security disasters like these are all like patches but don't really solve the problem Right. Um so so while I I I I have a lot of respect for people working in such systems because I know it's not always super fun. Um it's also something that that I don't think the problem isn't caused by the root problem. I mean isn't caused by um you know software updating which I say is a good thing. No, it's caused by um probably manage upper management or or you know company owners or clients deciding I don't want to invest into a healthy codebase anymore and then it starts to rot. So for for me at least the problem lies there and and it's not with software um just you know updating. I'm going to read the comments in a second, but I want to finish. I see comments flashing by, but I'm I'm I'm going to to come back to you, but I want to finish with one more thought here because uh countless packages get abandoned because unpaid maintainers can't keep up with relentless new versions. Now, this this part I really disagree with. I worked at Spassi for 5 years. We had 300 Laravel packages. We had a week every year when uh and we we usually did this a month. No, no, no, no. We did this right when the new major Laravel release uh got released. We went we had a big Excel sheet. We went through all our packages and we updated them and we put in the work. That's the commitment we made. Now on the other side, right, uh you know, if your company is relying on open-source software uh and you're you're claiming that oh, they packages get abandoned because maintainers are uh unpainted. Well, we all have a part in that, don't we? Um, so yeah, I mean, I'm just going to throw the ball back at you. Uh, basically just then then start paying for to to support maintainers or, uh, what you can also do, and I've run into this multiple times, you know, if you run into an abandoned package, just fork it. You know, maybe just keep a copy within the project. That's fine. You don't like it if if the package is abandoned. Of course, um you don't need to feel the pressure to start a new open source project. You can just fork it privately and then start working on on it over there. I've run into countless packages that, you know, did an update to the latest PHP version. And the first step is to, you know, submit a pull request and and try to get in touch with the maintainer to to have it updated. But if that doesn't happen after, you know, a while, you just fork it. It's fine. That's open source, right? So, so that shouldn't be a blocker, but still you should pay open source maintainers from a company company's point of view, right? So, so yeah, th those are my thoughts and I might actually wrap this up in a small video as well because I I yeah, I think it's it's a really valuable comment, right? It it highlights a real world problem. And I'm not denying that these problems exist, but I don't think that we can we can blame software trying to stay up to date for these kinds of problems. That's that's that's the core of my message here. Uh let's see what chat is saying here. You're you're going wild. Good morning from South Africa. Um I agree with the comment. Okay. Our codebase is 24 years old with nearly 1 million lines of code and we are trapped on old versions and upgrading right now which is a nightmare. Hey, but good for you on finally like biting the the sour apple. Is that like we say that in Dutch? I don't know. Um we are uh strangler strangler figing from I don't know what that means but from PHP 7 to Laravel 12 using a complex set of docker maintainers. Yeah. Yeah. Software is complex indeed. Uh we absolutely should have kept of course and that's a plan should have kept up to date I reckon you mean but keeping up is not trivial in the real world. Um, so again I'm circling back to to what I'm experienced with. Um at Spassi we did our own projects where we put in the time we we uh marked our calendar this is one week or two weeks of update time and we do we don't work on anything else and it costs us money and then we had client projects as well and we just you know drafted in the contract if you want a you want us to maintain your project for the coming years uh you will have to budget uh the time that uh it takes us to update every year and we keep up to date with the latest PHP version and latest Laravel Uh those were the two big things, right? So you just you someone has to pay for it. I agree. Um I would say that it it pays out in the end. So I think at least the versions that are current should be supported. Fair enough. Even trying hard to keep up uh we sometimes end up with the version behind for a while. Fair enough. Although I would say like if you if you wait two years there's more work to be done to get up to date again. So just updating every year is the easiest thing to do. So um again this like this mindset of uh we just let let the work pile up for a while. It's not going to win you time in the long run. Um, so, so yeah, that that that for me is the biggest argument to say like let's just only support the latest version because, you know, it doesn't really matter anyway. If people wait too long, they're going to have more work. So, you don't win anything there. And then, uh, Richard, this was all Rich's Richard's uh, um, point of view. I, by the way, thank you for pitching pitching in uh, Richard, but yes, I agree with your point of view as well. we definitely should have kept up to date and are paying for it now. And so so yeah, that's that's kind of and you know I'm not like trying to shift blame here because and you're paying for it now. The thing is these these decisions are often made by you know people that you don't control as a developer. So we're developers here. Although if someone who's like um in upper management watching like decision makers this is really valuable information I would say for you as well. I think um everyone will be more happy in the long run clients and and uh like agencies companies um you will be happier in the long run but it it's like yeah it takes it an investment. That's true. Um although it's an investment that pays off really quickly and really well. I think many PHP devs started with learning by doing and did many things wrong. Uh Gloomy Art says the newer versions of PHP are on uh on site way more uh restrictive but on the on one side way more restrictive and on the other side conceptually more easy to program stuff. Yeah, I don't know if they're they're easy necessarily, especially with all the new syntax we we're getting, which I like, but I reckon like things are can become quite complex in PHP these days. Um, but uh yeah, I would definitely say I like the newer PHP versions more. Um, and the thing is like many PH when you say that many PHP developers started with learning by doing and did many things wrong. Um, I I don't think that's specific to PHP there. PHP does have a lower entry level, so you might attract more people like just trying to hack something. Um, but that's the same goes for other languages. And uh, like I mentioned at the start of this stream, we're we're having PHP verse next week where we actually, let me put on the website here, PHP verse. Um and uh we'll have let's see here a panel over here about PHP education with Jeffrey Weey from Larcast Corup from uh YouTube Laravel Daily and Kevin Bond from Symphfony and I'm really looking forward to to this part as well because we see that um or at least my impression is that more and more people getting into PHP are really into properly learning the language as well. So that's really interesting. I find that really interesting. Um so yeah. Um circling back to Twitch for a second. Um where Adrian is uh is talking about his his tool that he wrote and he said like his tool to to scan the top thousand most popular packages. He says, "I ged min uh minmax min version max version last release time and nearly all top thousand packages support up to 8.4." This is an interesting point because um I'm that's absolutely true. Uh the thing is with when I start Oh, my website slow. Oh no, it's backing. Okay. uh when I made this graph, I was really contemplating whether I should focus on minimum supported versions or maximum supported version. But what I the story I wanted to tell with this is that as long as packages support all the versions, you're not forcing people to update, right? And so that's the problem I want to highlight with this. It's not about um uh whether they support 8.4 or not. It's about whether they still support outdated versions. And it's actually a good argument uh that most packages support 8.4 because that's one less reason for people to say they shouldn't update. Right now, this is top thousand packages. If you're relying on like very um like exotic uh weird packages to do very specific thing, chances are they won't get regular updates. But this is interesting as well like during software development right um you the moment you compose a require a dependency you should like give some serious thought to that because you are basically adding well a dependency in your codebase you're basically saying uh this is uh something I want to rely on now and when you're designing a project you need to like give good like thought to that like in in most companies you already need to check out the the the licensing, right? Whether you're allowed to use it in your context. That's that's the first step. But you should also look at is this package package actually actively maintained? Is there a community there uh where we can fall back on? Because you're you're basically you're you're if you're building commercial projects, right? It is quite like a a big thing to just rely on something where you don't know know the author where you uh don't have any guarantees whether the thing will still uh be actively maintained in the future. So yeah that's why docker was invented adrien says to run old WordPress sites based on PHP 5. I don't know I are you kidding or is that for real? I don't know. Um, y is here. We upgraded all of our all of our I I cannot again we upgraded all of our microservices from PHP 74 to 8.3. Recctor was a huge help and we had PHP standard properly. So this is also a thing. If you have like the the the tools in place that um that you know make the process easier, you'll just be a lot happier and you will also make a lot more like like update a lot faster because you know it's not that big a deal as it used to be. You can automate a lot of things these days. So yeah, Adrian says, "I wanted to know if maybe just half of the packages don't support the latest version, which would be crucial. I guess you're circling back to a previous point, Adrien." Um, which I don't remember what that was about. So yeah, could be. I don't know. That would be crucial. Yes. Hey. Okay. So that's my uh that's my small uh rant about like followup on on PHP versions. I really appreciate like I probably make this into a YouTube snippet as well. So so um Aamoon I really appreciate you pitching in. Um this was really good comments. Thanks for sharing that and thanks for allowing me to um react to it. So, uh, appreciate it and definitely if you're watching this and you're like, I have some more follow-up thoughts, leave them in the comments below and, uh, that way we can learn from each other. So, thank you. Thank you a lot. Okay, let's, uh, let's head over here. I'm going to dive into something new. Now, I saw this post on Reddit. 30 years of PHP, Franken PHP is now part of the PHP organization. This news was already like out two weeks ago, but um uh the foundation now also wrote a blog post about it. Um so it's a small blog post. Let's let's read through it. On June 8th, ah June 8th, here's a date. Rasmus Larardov released the first version of the PHP language. Over time, PHP has become the most popular serverside programming language with now powering over six 70% of websites. I don't know how accurate this number is. Roman who wrote yeah Roman that's my colleague by the way Roman um he's talking on on PHP vers as well uh but um 70% of I don't know how accurate that number is I I it's fair to say that a large part part of the uh web is powered by PHP but 70% I'm not sure about that anymore and you know people like these these websites they base their numbers on uh publicly accessible like header file in header request and response header information, right? But if you like configure your server to not expose that information, then you get skewed data. And as far as I understand, there's like most servers outside of PHP don't expose their version information. So I I think this this number is really um skewed towards PHP while it shouldn't. Although it's fair to say there is a big part of the web powered by PHP. Exactly 30 years 30 years after the first release of PHP, we are proud to announce that Franken PHP, a modern and high performance application server based on caddy is now part of the PHP organization on GitHub. As a reminder, Franken PHP offers features that are unique in the PHP ecosystem. Simplify the development of applications written in PHP. I'm curious about that. I don't know. Uh just drastically improve performance while consider considerably reducing hosting costs, finan this is for the upper management. Um facilitate deployment in production whether on bare metal servers or cl cloudnative environments. Easily develop real-time features thanks to native mer I don't know what is this protocol support. Uh it's it's by the same authors as frank PHP. We'll look into it. We'll try to look into it. Extend PHP apps with Go, C, and C++. Oh, that's interesting. Support the PHP programming language in any application written in Go. Oh, yeah. So, you can use PHP in Go. Okay, it's interesting as well. The move of Franken PHP into the PHP organization allows uh follows the announcement of Franken PHP support by the Yeah. Okay. In collaboration with Letier uh who are the that's the company behind Franken PHP and the team maintaining the caddy web server. That's actually interesting. CD is involved in this then as well or not I don't know. Uh oh. That's definitely a lie. Someone says here point two drastically improve performance while consider cons considerably reducing hosting costs energy consumption I don't know I'm just reading the blog post tell do share your thoughts in the comments um RSF on YouTube here um or in chat if if you have like any follow-up here I don't know my my reasoning was that franken PHP is faster so uh you naturally need less stuck servers to run the same amount to be able to handle the same amount of traffic. But I don't know. I haven't used rank PHP yet. Like I hope in five minutes I will have. Um the road map and new features. Oh, hang on. This is the first step towards greater integration of Franco PHP I reckon into the language ecosystem. This is interesting. I I wonder what this is about like what the next steps are. And actually I don't know like Roman is my colleague but I don't know the the next um the next steps. So interesting interesting um I'm getting it. Hang on. Can we pause this show controls? No. Uh okay we cannot show the controls. I'm getting like I know this is the event I'm hosting but like having this on loop kind of annoys me. The road map and new features that are likely to change the way PHP applications are developed will be announced at the Oh yeah, at PHP first uh on June 17th. Mark your calendars. That's next week, Tuesday. Uh I hope I'm not like making too much um like promoting it too much, but I'm just really excited about this event, folks. I'm hosting it. So yeah, happy birthday PHP. Okay, so yeah. Okay, we can uh do that. I've never used Caddyy either, so I wonder I hear that it's pretty good. I use engine X, but okay, we'll have to look into that. And then Mercur, is that pronounced correctly? Mercural time made easy uh is an open solution. I know the company is French, right? So I suppose you pronounce it mercur instead of mercur uh is an open solution for real-time communications designed to be fast. So I guess this is okay instead of instead of websockets. Interesting. I don't I wonder like why would anyone wants want to use this over websockets which is which like websockets are like the the Yeah. Okay. Um, Adrien says here, I hope that PHP serve will utilize Frank and PHP in the future. Yeah, that would be interesting, right? So, if like the maybe the default way or or like an optin way to have just use franken PHP from the built-in um PHP binary uh because franken PHP is production ready, right? And from what I get, it has like the caddy server built in. You don't have to do anything. uh you just you know deploy your binary basically. Um so that would be really interesting. It would really make PHP like just you know comp compile I reckon to a binary for production. You you don't need it for local development but when you're going to production you you compile your whole project into a binary and just push that to a server and done. Um of course it doesn't account for things like databases and stuff. Um, so yeah, let's take a look at Franken PHP because I want to try it out and I hope it's just like super smooth because uh yeah. Oh no, I have I have a problem here. That's okay. We're going to ignore that problem. So yeah, this is this is this is Tempest. Um which does have have like uh oh uh uses oh uh let's say localhost 81 81. Oh no no no. Oh I haven't I haven't fixed this yet. Okay. Um, so yeah, this is the built-in PHP server. Uh, and now I want to try to run it on uh thingy frank PHP. I'm also thinking let's let's maybe run the docs tempest uh let's run this website actually. And now serve won't work as well. Yeah. Okay. uh localhost uh 8080 8181. Okay, I I guess this makes more sense. Uh so I want to run this with Franken PHP basically. Let's see if it works. Um Aaron says here Kevin who's the author of Franken PHP is also the top five caddy contributor. Interesting. Yeah, I I I reckon there is some overlap there. Um, that makes sense. Um, the modern PHP app server written in Go get by the way, look at this comment here. Hang on. Someone here. Uh, where is it? Maybe it's Yeah, that's a lot of work. This was on Reddit, right? That's a lot of work just to not learn the easiest simple the easiest simplest language. lol referring to go on a PHP subpar. Okay. Um that was just a troll. So uh let's see. Okay. Mercure we're going to ignore um for now. Frank Okay, this is getting started, right? Yes. Franken PHP is a modern application server for for PHP built on caddy. Franco PHP gives superpowers to your PHP apps thanks to its stunning features, early hints, worker mode, real-time capabilities. Okay. Yeah. Learn more on Franco PHP in the slide. How to get Okay. Getting started. Standalone binary. We provide static Franken PHP binaries for Linux and Mac OS containing PHP 8.4 support and most popular PHP extensions. Yes. Download Franken PHP or copy this line in your terminal. I mean, what could go wrong, right? Copying random shell scripts. Oh, it will be fine. It'll be fine. Oh, come on. Um, so we're downloading Frank and PHP and we're also increasing the zoom a little bit more so you can read properly. Um, RFS says, "Yeah, it's also kind of annoying when setting up a new server." Oh, I missed a part, I think. Um, it's okay. So, Franken PHP is kind of annoying annoying when setting up a new server with full package and then removing Apache 2, right? But isn't that just because like setting up new servers these days, like depending on how you set it up, but they install Apache by default because of PHP and now you don't need it anymore. So, you just need a clean server. I don't know. I'm I'm really I'm I suck at DevOps. Honestly, I don't want to do anything with DevOps. And here I am installing Frank and PHP. Okay. Franken PHP downloaded successfully. Move the library. Move the binary to Yes. Let's just do that. Mhm. Okay. And then we can say to serve the content of the current directory run Frankenph PHP server. Okay. So I have to go to public here. public. Uh okay it's already in use. Yes. Okay. You can also run command docker images. Yeah. But I don't want to use docker docs classic mode. Let's start there. Without any additional conf configuration. Franken PHP operates in classic mode. In this mode, Franken PHP functions like a traditional PHP server directly serving PHP files. This makes it a seamless drop-in replacement for PHP FBM. Yes. Similar to Caddy, Franken PHP accepts an unlimited number of connections. Okay. Yeah. And uses a fixed number of threads to serve them. The number of accepted and cued connections is limited only by the available system resources. Okay. The PHP thread pool operates with a fixed number of threads initialized at startup compared to the static mode. Yeah. Of PHP FPM. Yes. Um. Yes. So that's classic mode and worker mode is boot your application once and keep it in memory. I know for sure that this won't work yet with Tempest, but that's on Tempest side and that's we we do want to add support for that. I know Symphony has support, Laravel has support, but the thing is like there there are a couple of of things you need to keep in mind when you're uh having long running processes in PHP. So you only boot a framework once, right? Uh but like for things like for example um the database connection is is a tricky one because that's booted but then it times out after a while and then you need to refresh it. Um we we're already already doing that for tests but not yet for um it's not like trivial to do in in with worker mode. So but yeah how does worker mode work? Set the value of franken with docker with standalone binary franken php worker path to your worker script. Yes. Um, if your PHP app is embedded in the binary, you can add a custom caddy file in the root root of your app. Yes. Okay. I don't know what embedded in the binary means, but yeah, that's further down the docs. It's also possible to restart worker restart the worker on file changes with the watch option. Okay. Symph Symphfony Laravel custom apps. A yeah, so this is interesting. Let me let me actually just check this out for a second because I am curious what needs to happen. Um so uh okay so we you need to ignore user board. You need to boot your app kernel. Yes, this is this is basically what's happening in uh over here. Um but yeah in tempest I have to change some things here to make this work of course. Handler outside the loop for better performance. Doing less work. Yes. So you create a handler and then you handle. Okay. Okay. Yeah. I'll need to do some refactoring to get this to work but that's fine. Uh max requests if number of requests is uh zero or okay. and have four number of requests. So we'll loop over the yeah okay and then there is this function handle request. Sure. And then we do something after sending an HTTP response response collect cycles and well not keep running is break. Okay. And then shut down. Okay. So it doesn't seem too complicated honestly. Um, I would need to make some changes in Tempest, but super doable. Super doable. Uh, and then you start it and then you restart. Okay. So, but hang on because we were getting started and I just I need to know how to how to use another port. Uh, let's see is if if like help is available. or someone in chat can say let's see uh add package build info compilation completion environment file server f hash password help list modules man page yeah that's for caddy run a php command yeah actually I I need the help for for PHP server, right? Listen, so I reckon it's something like this. Listen, localhost 8181. Hey, I mean, look at me. Or oh, you could also do something via env. Uh, Adrian says, "Okay, but this seems to work, I guess." Let's see. Let's see if it works. Let's go to It works. That's That's nice. Seamless. It just works. Okay, that's pretty cool. Now, what I'm wondering about another big thing. So, so worker mode I need to I'll I need to make some changes. Compare the speed, Adrian says. Yeah, but the thing is um okay, yeah, I have enginex running locally as well. So, okay, let's compare the speed. So, this is hang on. This is uh tempest php.est. Yes, this is engineext, right? Uh and then but I don't know how how accurate this is. Of course, this is local development, but okay, let's let's just see. And then we have localhost 80 8181. Oh, this is actually going Yeah, this is going. Yeah. Okay, but I'm sorry I'm rambling. Okay. Oh, what's the problem? Should I do it like this? No. Huh? Why doesn't that work? Invalid argument. I probably did something wrong. Should I ditch the HTTP? No. Huh? I don't know. AB invalid argument. Why is it in Dutch? Change to English. Yes, I am a human. Oh, you need to use really http 12700 0. Okay. Okay. Let's see here. So, we had with EngineX five requests per second, 200 milliseconds. But I don't know if this will just work like be better out of the box. I reckon like okay with worker mode it should be faster. But uh let's see. Uh ah okay. It is it is a little faster but it's local development, right? So, I didn't expect like miracles here, but okay. It is it is faster. That's that's good. Very interesting. Also, by the way, you know, the fact that you have to do this. Come on. It's 2025 and and like if you can't figure out local host is is the same as 127001. Yeah. Y sex. I don't know. Okay. So, interesting. Um, worker mode. That's where we were before Adrian distracted us. Um, worker mode needs some work. But, uh, this is what I wanted to look into as well. Franken PHP has the ability to embed the source code and assets of PHP applications in a static self-contained binary. This is really interesting. Um yeah so thanks to this feature PHP applications can be distributed as standalone binaries that include the application itself the PHP interpreter and caddy a production level web server. Yes for embedding Laravel applications. Okay. Yeah we're not doing that. Preparing your app. Before creating the self-contained binary be sure that your app is ready for embedding. For instance you likely want to install the production dependencies. Dum the os loader. Okay. Yeah. Yeah. Yeah. That that makes sense. Let's You know what we're going to do? Get remote-f uh this one. And we'll uh get clone in uh tempest php.com production something like that right because I I have to do some work here. tempestphp.com-production because we have to install composer install node defaf and we have to composer uh dump dump autoload I guess. Oh yeah and I think you have to do it like this optimize. Yes. Um enable production mode of your application if any. So what do they do with env files? I reckon that's still just on the server. Of course, strip unneeded files such as Git or tests to reduce the fi the size. Okay, let's let's do that. I mean trying things out. Um also let's um open let's open the project here. What's it called? Tempest speech production. Uh this window please. Um so we can remove quite a lot of things here. We can remove this. We can remove tests. Um source uh kind of needed. Uh yes. Yes. Uh I need to burn install true and then bun bun bun bun run build as well. That's also part actually I can just read the deploy script. Right. What needs to happen here? Um bun discovery generates. Oh. Uh, yeah. Hang on. I need to tempest php.com/index. No, no, no, no, no, no. Hang on. It's this. I need to do this. And then bund build. I know what's uh what I need to do to deploy my own website. Of course. Yes. Uh, Stefan says, "Docs look amazing. Props for the design." Are you talking about Franklin PHP or Tempest PHP? Because personally, I like our docs more, honestly. But that's fine. Okay. So, we run builds. We've done uh Oh, we need to static generate also. Yeah. Yeah. Yeah. Definitely. I don't know. This is interesting. How will um Oh, this is so slow. Oh, I have Hang on. No. Huh? Hang on. Static generates. Yeah. Okay. I'll I'll just wait. Tempest docs. Thank you, Stefan. We've we do put a lot of effort into it. After PHP verse, we're ready to like almost tag 1.0, but that's after PHP verse. Little bit too many things going on right now for me to uh like properly do all of that. Okay, so we've done uh build and static generate. Yes. Well, that's going. I don't know why it's so slow honestly but it works. Um then yeah what about database stuff but they don't really use database which is unfortunate but tempest cache clear discover yeah yeah discovery generate should we do that as well? Yeah, but discovery cache is disabled. So, I probably need to um production and then base URI tempest.php.com cache. Uh yeah, can be this true. Ah, no, hang on. This is still the old uh framework uh install framework. It is install framework uh framework. Yes. Yes. And then we can just now end up is it the same? Oh, I already updated it. Okay. All caches on and then discovery generate. Discovery generate please. Yes. Gloomy art here. I think Tempest could be I hope you're talking about Tempest could be the PHP framework of the future. Thank you. I've already set up a dev environment but I didn't have time to write a single line of code yet. That's fine. you will in the future. Everyone will win it. I'm kidding. Um, I've totally lost track. I think this is production ready now. So, if we go to tempestphp.com-production.est, this is running with um thingy uh engineext, right? But yeah, this is all Oh, I don't know why that happened. It's fine. Yeah. Okay. So, let's just say this is production ready. Uh, strip unneeded files. Yeah, we could remove a lot of things here, but this is something you would do on your like a build server, right, with a GitHub action probably. Um yeah, for instance, oh hang on, set proper environment value. Yeah, so you do need like to set environment stuff, but that's because you Yeah, optimize. How does that work? No, this is for Symphfony specific probably. Customizing the configuration. to customize the configuration. You can put a caddy file as well as PHPini in the main directory of the app to be embedded. That's pretty cool. So, it's like it really becomes something on its own. It's really nice. Okay. Creating a Linux binary. Creating a binary for other oss. Yeah. I mean, we can do it with Linux, I guess, with Docker. I hope. Is it easier to do it if you don't want to use Docker? I don't or want to build a Mac OS binary, use the shell script we provide. Ah, okay. Okay. Okay. Let's Let's try to do that. Frankenphals. Okay. And then would this work? No, probably not. What? Uh home. Hang on. Hang on. Uh tempestphp.com I don't want to this. This is what I need. Now we go back to frankenph and then we say uh embed equals Oh no. and then build static. Let's go. Interesting. I don't know how long this will take. It's updating homebrew. Oh, no. Folks, it's been good knowing you. Um, maybe some some last words here before we uh wait for hours maybe. I don't know. It's updating Homebrew. Who knows what will happen. Uh, automatically fixing build tools. Go ahead. I'm starting to doubt whether I should have done this. Maybe like Docker would have been easier because it's doing things I But hey, I told you I'm like I'm a DevOps noob, right? So, it's still it's still doing it's still working. So, as far as I'm concerned, it's well still working, right? Um yeah create an I can also try to do the docker thing static builds dod docker file. Ah you know I never removed. Now it is uh and then we need to paste this in my static build from platform. Yes. Copy your app work there. Yes. So that's my pwd I guess. But docker will be slow as well. Build the static binary. Where should we put it? tempestphp.com. Let's do underscores. You can tell the person is in love with PHP when the device doesn't have package config installed. I will see. We'll see what what's fastest. Oh, I don't even have Docker. No, I do have Docker. Oh, no. I know. I'm on a clean Mac. It was fine as it was. Oh. Ah. Okay. Okay. Okay. Get it. I don't need to change these parts. Thank you, Zerka. Install Docker. Um, do I need to install um Docker Desktop? Yeah. Yeah. With an Apple silicon. Apple silicon chip. Sorry. You know, I can just blame that this is a new Mac, you know, and I haven't had time to set up all all the things I needed. Um, something like that. We'll see what works fastest, but I know with Docker, you can tell a person is a real dev when they don't know anymore on which machine they're on. Hey, I don't think I've ever claimed I'm a real dev. Well, I did claim I'm I'm not a script kitty, so no, but honestly, I'm I'm really bad at I have to I do admit this. I I'm really bad at DevOps stuff. It's just not I'm like totally not interested in it. So that's why like with Tempest um new like we have quite a lot of workflows here. Where's their integration test thing? This is these are in my mind complex but like Aiden helps out with these a lot. like that's basically his his real time is his real life job, right? Is writing these things as far as I know. So, uh yeah, it's just maybe I maybe it makes me a very bad developer. Yeah. Okay. So, Docker, we have Docker. To me, DevOps is just another buzz word to sell stuff. Yeah, except I guess Docker desktop automatically. Yes. Why don't I allow I guess work. Skip. Skip. Oh no. Docker franken PHP. I don't know if this will Let's see. Now we have to wait for Docker, right? And this also takes a while because it has to download all the stuff, but it's probably faster. What does package config actually do? Yeah, I have no idea why it's so slow. Go away. Go away. Go away. Um, so yeah, how is everyone doing? Uh, oh, this is like great content. I guess this is a time to grab a coffee if uh if anyone wants to. and and maybe there are some questions in chat. Anyone know when Jun is coming to remote development? No, I don't know. Sorry. Uh shouldn't be that slow. RFS says it it like like I said, this is a new mech, right? So like it's two months old now, but it might actually be the first time. I'm properly running Brew. I don't know. No, no, because I've installed Git, right? And I've installed Did I do that with Brew? I've installed PHP, which is I think with Brew. Yeah, we'll see. We'll see. Yeah. What else? While this is running, we can uh we can check out now I remember the comments here. Um someone who hasn't tried it out. Hey, hi. That's just like me. Uh a good candidate if Apache or NGX are bottlenecking. That's interesting. But this is this is the kind of things I want to read. Actually, I would say that Franken PHP's biggest strengths are not only performance but essentially the ease of setup. I know. Yes. Look at No, this is this is my my doing early hints. Yes. Uh is this compression broadly compression? Uh super simple config. I recently made the Franken PHP directive optional. A minimum production ready config for a PHP app is now four lines of caddy file config. five with worker mode, Mercur for real-time communication, a single binary containing it all, and all of CD's native features like HTTP3, trivial zero downtime deployments, automatic SSL, and more. Yes. Okay, so that's that's interesting. Docker is done, huh? No. Oh, why is it putting a 1 gigabyte image layer? I don't know. I just copy pasted what they told me to do. I don't know. Yeah, this is this is unfortunate. I don't know what this is doing either. I'm going to let's try to run this with output. See what happens. Maybe it was just hanging on like Yeah, let's try that again actually. You know, I think I I think it was just waiting for me to do something. Maybe um the the thing that was happening here with the 1 GBTE image, it's just it's the image that builds the binary. It's not the binary itself as far as I understand. But I don't know what's going on here and I'm don't want to look into it. I was hoping this would be faster honestly. So be aware I sometimes use a class property as cache. Yeah, it will be cleared at the end anyway. A static. Yeah, but not in Franken PHP environment. This is an interesting one. you do need to like if you have your environment booted always, you have to do some things to make it like work. This lead to some strange issues after switching which are not easy to spot. Yeah. Uh so definitely on like if you're writing a framework that's super important to take into account been using Franco PHP for over a year never going back. Meanwhile I don't know this isn't normal, right? Would it be easy to convert from EngineX in Docker Kubernetes to Franken PHP and see if I can go from two containers to one? I'd prefer that. CD's documentation takes a bit of time to get used to. Once you do, everything becomes super easy. Interesting. Um, deployed an app last week with it. It works really smooth with Laravel Octane. Only wish Docker documentation work better. Docker. Okay. So, I'm I feel like many people are are interested uh and and are excited about it. So, that's cool. Now, You know, when it's when it's like doing things, it's uh you get the feeling that okay, we're at least like we're waiting but not in vain. And now we're just waiting. I do I we can try out uh let's see here. Oh, index worker.php PHP can look a bit into uh getting worker mode to work. Um although I'm a bit scared of it. Prevent worker uh script. Yes. Okay. So let's see. We have our framework kernel here. But that's not really how Tempest boots. Although I can make a new boot thing like we have HTTP application right uh with with some imports that should be removed but doesn't matter. Um yeah, we can skip all of this and we can just do framework kernel boot kernel kernel kernel equals framework kernel boot and then the root directory. Uh let's see how I resolve that. That's just this, right? Yeah. Okay. And then discovery locations. Hang on. Yeah. Yeah. That's just empty array. Okay. And then Okay. Then we have our kernel. Fine. Then we have to I think that's all we need here actually. Handler. Yeah. Yeah. And then we need to like handle whatever our HTTP. So we um wow basically we need to do this. Mhm. Now so actually we can just do app equals um HTTP application boot, right? And then echo app. The thing is run. What do we do here? Yeah, it might. It might work just like that. So that's our handler. Sure. Okay. Max request stuff. And then we have app. Yeah, we don't really have like a terminator that's already done during the run thingy. Uh, let's add braces. I say app. Ah, yeah. See, but this is the problem here. So this line should probably go here. Then we need to move that in other places as well. Symfony has a reset interface you implement to get your services back to their initial state if that's needed between requests. So that's indeed something your framework has to provide or take care of. Yeah. Yeah. Yeah. Yeah. There are like the the small details, right? that that um might uh mess this up, but I think it should be able to start at least. Um I think so. Oh. Oh, come on. Worker equals public index worker. No, that's an error. Uh oh. Yeah, that's an error. Hang on. Let's also check up on our uh Yeah. Uh oh. Okay. So it's always the same error. I think worker script has not reached handle request. It did have like Okay. Shouldn't matter. Mhm. What's this? H but now yeah server is already hang on uh listen local host oh let's see 127 00 oh no I pressed enter one 81 81 Yeah, this will probably probably take some debugging as well. I don't know why. Oh, hang on. There it is. Failed loading. Yes, yes, yes. Of course. Uh ah ah it works. Yeah, I think it works. Let's see. Uh no, it doesn't work. But let's one 81 81. No caddy serving on I'm not mistaken right no it doesn't give any any logging either so I'm not sure what happens there can I like write out some things here. It is writing some stuff here. And that's my dump thingy. So, let's see actually if this works. Uh, Tempest Tail. Yeah. Yeah. Yeah. Okay. So, it's never coming here because max request is zero. What if I put it at two? Okay, now it's two. It's still it's not really doing anything. So it is looping there which makes sense. Um so for number of requests if not keep running. Let's see what happens here. Keep running. Let's keep keep running. It's also uh uh splits splits right. Okay. Yeah, it might not be Yeah. No, it will take some uh some more work, I'm afraid. And this is still I don't know. Let's go away. Yeah, I'm done. No, this is this is has nothing to do with Frank Franco PHP probably. It has all to do with my like total inability to do proper DevOps. So Aiden will watch this live stream afterwards because I think he's sleeping and then he will shout at me. That's what's going to happen. Ah, okay. No, but like all in all, I'm a little sad that I didn't get it to work just first try. Although we did manage to run it in classic mode which was already more performant locally which is interesting and yeah I'm sure like worker mode it will just take like a couple of hours of debugging and trying things out to get it to work and then it will just work. Um because I like I don't foresee any big issues. I I'm already aware of a couple of issues in the framework that should be fixed but yeah should should be uh should be fine. So yeah that's Franken PHP it is it is really interesting like imagine this being a little like working a little smoother with little less setup even and um you know just working out of the box with PHP in the future. That's um I that wouldn't be pretty cool, right? Uh I really think this is a really great step forward. I'm not sure what the the the future plans are um towards greater integration of the tool into the language ecosystem, but I feel like it's it's yeah, more more things are going to happen. Um, oh hang it changes will they will be announced at PHP first. I I swear you I didn't know that. I I know I read it at the start of the stream, but I I just didn't really understand what was said here. I was reading I was reading on autopilot. Okay, so Kevin will probably give some more insights into the future. Okay, that's pretty cool. So, everyone attend PHP verse. It will be uh livereamed, but you'll also be able to re rewatch it for free afterwards on YouTube. So, uh it will be on the Jet Brains TV channel, but I'll share it share it on on this channel as well. Like I'll share a link and make a post. Um so, yeah, pretty cool. Very nice. I'm excited about this. That's uh Franken PHP and uh that was me for this stream. Uh, no folks. I'll uh I'm glad I got to spend some time here talking and rambling about Frank and PHP. Talking and rambling also a bit about like version management stuff. I'll I'll make that into a new video probably as well. So folks, thanks for watching. Thanks for being here and uh see you next time. Bye-bye., 30 Years of PHP and FrankenPHP, PHP Annotated, 01jxgcyjspk495s61zznq1940e.