Splitting Laravel Boost guidelines across multiple files
https://laracraft.tech/blog/splitting-laravel-boost-guidelines-across-multiple-files
https://redd.it/1sryize
@r_php
https://laracraft.tech/blog/splitting-laravel-boost-guidelines-across-multiple-files
https://redd.it/1sryize
@r_php
Laracraft
Splitting Laravel Boost guidelines across multiple files
Laravel Boost only reads a single core.blade.php per package, so extra sibling files get silently dropped. Here is the minimal pattern for splitting your guidelines into organized partials using a Blade view namespace.
What does your PHP stack actually look like in 2026?
I've been building PHP applications professionally for 10+ years, and I'm curious what everyone here is using these days.
Our current stack at work:
* PHP 8.3 + Laravel
* Vue.js on the frontend
* MySQL + Redis for caching
* Docker for local dev and deployments
* GitHub Actions for CI/CD
* AWS for hosting
We've tried moving parts to Node.js a couple of times, but honestly, keep coming back to Laravel for anything business-critical. The ecosystem is just too mature and productive to give up.
A few things I've noticed in 2026:
* PHP 8.3 JIT is genuinely fast now, the performance gap with Node is much smaller than people think
* GraphQL adoption in PHP projects has grown a lot
* Redis has basically become a default part of every stack
Curious what others are doing, are you still on Laravel or have you moved to Symfony, Slim, or something else entirely? Anyone running PHP in a microservices setup with Docker and Kubernetes?
Drop your stack below. 👇
https://redd.it/1ssct11
@r_php
I've been building PHP applications professionally for 10+ years, and I'm curious what everyone here is using these days.
Our current stack at work:
* PHP 8.3 + Laravel
* Vue.js on the frontend
* MySQL + Redis for caching
* Docker for local dev and deployments
* GitHub Actions for CI/CD
* AWS for hosting
We've tried moving parts to Node.js a couple of times, but honestly, keep coming back to Laravel for anything business-critical. The ecosystem is just too mature and productive to give up.
A few things I've noticed in 2026:
* PHP 8.3 JIT is genuinely fast now, the performance gap with Node is much smaller than people think
* GraphQL adoption in PHP projects has grown a lot
* Redis has basically become a default part of every stack
Curious what others are doing, are you still on Laravel or have you moved to Symfony, Slim, or something else entirely? Anyone running PHP in a microservices setup with Docker and Kubernetes?
Drop your stack below. 👇
https://redd.it/1ssct11
@r_php
Reddit
From the PHP community on Reddit
Explore this post and more from the PHP community
Guest Post: Why We Chose NativePHP Over Flutter for Bagisto's Mobile Admin
https://nativephp.com/blog/nativephp-not-flutter-for-bagisto-mobile-admin-app
https://redd.it/1ssflmx
@r_php
https://nativephp.com/blog/nativephp-not-flutter-for-bagisto-mobile-admin-app
https://redd.it/1ssflmx
@r_php
Nativephp
Why We Chose NativePHP Over Flutter for Bagisto's Mobile Admin
One weekend was all it took
The latest and greatest in postcardware at Spatie
https://spatie.be/blog/the-latest-and-greatest-in-postcardware-at-spatie
https://redd.it/1ssgdwu
@r_php
https://spatie.be/blog/the-latest-and-greatest-in-postcardware-at-spatie
https://redd.it/1ssgdwu
@r_php
spatie.be
The latest and greatest in postcardware at Spatie
Earlier this year at Spatie, we spend a full day hacking away on fun sideprojects during our hackathon. The goal was to create something fun and functional by the end of the day.
We (Nick and Dries) decided to create a digital version of our postcard wall.…
We (Nick and Dries) decided to create a digital version of our postcard wall.…
I tested every PHP parallel library on Windows. Only one actually worked without making me want to quit.
Background: I'm a PHP dev primarily on Windows and I needed real parallelism and just async, actual CPU-bound tasks running in separate processes simultaneously for my csv parser that process billions of items using cross platform pure PHP solution.
Here's what I found going through the options:
**spatie/async** : nope. Depends on `pcntl` which doesn't exist on Windows. It silently falls back to running everything synchronously. No warning, no error. Just... slow.
**nunomaduro/pokio** : this one looked promising. Nuno Maduro (the guy behind Pest, Pint, Laravel Zero) released it recently with a really clean API:
```php
$promiseA = async(fn() => heavyWork());
$promiseB = async(fn() => otherWork());
[$a, $b] = await([$promiseA, $promiseB]);
```
Looks great. But under the hood it uses PCNTL to fork and FFI for shared memory IPC. On Windows, neither exists. The docs say it "automatically falls back to sequential execution" and which sounds polite but means it silently stops being parallel entirely. Same problem as spatie/async, just with a nicer API.
**ext-parallel** : nope need external extension, and wont even work on windows and need ZTS build.
**pcntl_fork() directly** : Unix only and too complex. Not even worth trying.
**amphp/parallel** : technically works on Windows, but the DX is painful. To run anything in parallel you have to define a dedicated Task class, implement a `run()` method, make sure it's autoloadable in the worker, serialize your inputs manually, and wire up a worker pool on top. Just to run a task in another process and it has high cognitive load:
```php
class MyTask implements Task {
public function __construct(private readonly string $url) {}
public function run(Channel $channel, Cancellation $cancellation): string {
return file_get_contents($this->url);
}
}
// in a separate script
$worker = Amp\Parallel\Worker\createWorker();
$execution = $worker->submit(new MyTask('https://example.com'));
$result = $execution->await();
```
That's a lot of ceremony. And `echo` inside workers isn't reliable and the Amp docs explicitly say ordering is not guaranteed and it's "not recommended."
**Laravel Concurrency facade** — this one is actually clean and works on Windows:
```php
[$users, $posts] = Concurrency::run([
fn() => DB::table('users')->get(),
fn() => DB::table('posts')->get(),
]);
```
But there are two big problems. First, the name is misleading plus it's not actually concurrency in the traditional sense. Under the hood it's just spawning separate PHP processes via `artisan`, which is parallelism, not shared-memory concurrency. Second and more importantly: to use it you have to pull in the **entire Fat Laravel framework**. All of it. Just to run closures in parallel. If you're already in a Laravel project it's a decent option, but using it standalone purely for parallelism means booting a full framework on every worker spawn. The overhead is real and the dependency is enormous for what it actually does. Also, using print statement inside parallel task crash its json based ipc.
Then I found **hiblaphp/parallel**, released literally days ago. The author specifically handled Windows by switching to socket pairs for IPC instead of anonymous pipes (which don't support non-blocking mode on Windows). and it has great serialization
I was skeptical so I benchmarked it:
```
100 runs, persistent pool of 10 with booted workers on Windows:
Median: 0.583ms per task
Avg: 0.839ms per task
P95: 1.036ms
```
Sub-millisecond. On Windows. I did not expect that.
The API couldn't be more different from Amp's:
```php
echo "Main PID " . getmypid() . PHP_EOL;
$result = await(
parallel(function () {
sleep(1);
$pid = getmypid();
echo "PID: " . getmypid(). PHP_EOL;
return $pid
})
);
$pool = Parallel::pool(size: 4)->boot();
$result = await($pool->run(fn() => $processItem($data)));
$pool->shutdown();
Parallel::task()
Background: I'm a PHP dev primarily on Windows and I needed real parallelism and just async, actual CPU-bound tasks running in separate processes simultaneously for my csv parser that process billions of items using cross platform pure PHP solution.
Here's what I found going through the options:
**spatie/async** : nope. Depends on `pcntl` which doesn't exist on Windows. It silently falls back to running everything synchronously. No warning, no error. Just... slow.
**nunomaduro/pokio** : this one looked promising. Nuno Maduro (the guy behind Pest, Pint, Laravel Zero) released it recently with a really clean API:
```php
$promiseA = async(fn() => heavyWork());
$promiseB = async(fn() => otherWork());
[$a, $b] = await([$promiseA, $promiseB]);
```
Looks great. But under the hood it uses PCNTL to fork and FFI for shared memory IPC. On Windows, neither exists. The docs say it "automatically falls back to sequential execution" and which sounds polite but means it silently stops being parallel entirely. Same problem as spatie/async, just with a nicer API.
**ext-parallel** : nope need external extension, and wont even work on windows and need ZTS build.
**pcntl_fork() directly** : Unix only and too complex. Not even worth trying.
**amphp/parallel** : technically works on Windows, but the DX is painful. To run anything in parallel you have to define a dedicated Task class, implement a `run()` method, make sure it's autoloadable in the worker, serialize your inputs manually, and wire up a worker pool on top. Just to run a task in another process and it has high cognitive load:
```php
class MyTask implements Task {
public function __construct(private readonly string $url) {}
public function run(Channel $channel, Cancellation $cancellation): string {
return file_get_contents($this->url);
}
}
// in a separate script
$worker = Amp\Parallel\Worker\createWorker();
$execution = $worker->submit(new MyTask('https://example.com'));
$result = $execution->await();
```
That's a lot of ceremony. And `echo` inside workers isn't reliable and the Amp docs explicitly say ordering is not guaranteed and it's "not recommended."
**Laravel Concurrency facade** — this one is actually clean and works on Windows:
```php
[$users, $posts] = Concurrency::run([
fn() => DB::table('users')->get(),
fn() => DB::table('posts')->get(),
]);
```
But there are two big problems. First, the name is misleading plus it's not actually concurrency in the traditional sense. Under the hood it's just spawning separate PHP processes via `artisan`, which is parallelism, not shared-memory concurrency. Second and more importantly: to use it you have to pull in the **entire Fat Laravel framework**. All of it. Just to run closures in parallel. If you're already in a Laravel project it's a decent option, but using it standalone purely for parallelism means booting a full framework on every worker spawn. The overhead is real and the dependency is enormous for what it actually does. Also, using print statement inside parallel task crash its json based ipc.
Then I found **hiblaphp/parallel**, released literally days ago. The author specifically handled Windows by switching to socket pairs for IPC instead of anonymous pipes (which don't support non-blocking mode on Windows). and it has great serialization
I was skeptical so I benchmarked it:
```
100 runs, persistent pool of 10 with booted workers on Windows:
Median: 0.583ms per task
Avg: 0.839ms per task
P95: 1.036ms
```
Sub-millisecond. On Windows. I did not expect that.
The API couldn't be more different from Amp's:
```php
echo "Main PID " . getmypid() . PHP_EOL;
$result = await(
parallel(function () {
sleep(1);
$pid = getmypid();
echo "PID: " . getmypid(). PHP_EOL;
return $pid
})
);
$pool = Parallel::pool(size: 4)->boot();
$result = await($pool->run(fn() => $processItem($data)));
$pool->shutdown();
Parallel::task()
->onMessage(fn($msg) => print($msg->data . "\n"))
->run(function () {
echo "task running\n";
emit('Processing batch 1...');
emit('Processing batch 2...');
return 'done';
})
->wait();
```
No Task classes. No autoloading gymnastics. No framework. Just a closure.
I also tested `echo` inside workers and it works and streams in **real time**. Each line appeared live as the worker was sleeping, not buffered and dumped at the end. Concurrent workers don't garble each other's output either because each `echo` is wrapped in a structured JSON frame before being sent back to the parent. The would really extremely useful on CLI tooling applications and would benifit massively from its cross platform pool stability and realtime output streaming.
Other things it does that the alternatives don't:
- **"Self-healing pools and crash detection"** : if a worker segfaults or OOMs, the pool auto-respawns it and fires an `onWorkerRespawn` hook
- **"Exception teleportation"** : exceptions thrown inside workers come back to the parent with the original type and a merged stack trace showing both sides
- **"PHP-FPM like safety"** : you can literally configure a pool of workers to have limited timeout, memory, and max respawn rate.
- **Zero Heavy framework dependencies** : `composer require hiblaphp/parallel` and you're done
This project deservee much recognition and should be shown to many young people on how Pure PHP can do cool things. PHP Foundation and PHP influencers should promote open source projects that benefit the whole PHP in general not just frameworks and AI slop, to show that PHP can still compete with other languages in the realm of concurrency and parallelism. I'm glad that there's still people make PHP a better language as a whole and thinking forward.
https://redd.it/1sshzsp
@r_php
->run(function () {
echo "task running\n";
emit('Processing batch 1...');
emit('Processing batch 2...');
return 'done';
})
->wait();
```
No Task classes. No autoloading gymnastics. No framework. Just a closure.
I also tested `echo` inside workers and it works and streams in **real time**. Each line appeared live as the worker was sleeping, not buffered and dumped at the end. Concurrent workers don't garble each other's output either because each `echo` is wrapped in a structured JSON frame before being sent back to the parent. The would really extremely useful on CLI tooling applications and would benifit massively from its cross platform pool stability and realtime output streaming.
Other things it does that the alternatives don't:
- **"Self-healing pools and crash detection"** : if a worker segfaults or OOMs, the pool auto-respawns it and fires an `onWorkerRespawn` hook
- **"Exception teleportation"** : exceptions thrown inside workers come back to the parent with the original type and a merged stack trace showing both sides
- **"PHP-FPM like safety"** : you can literally configure a pool of workers to have limited timeout, memory, and max respawn rate.
- **Zero Heavy framework dependencies** : `composer require hiblaphp/parallel` and you're done
This project deservee much recognition and should be shown to many young people on how Pure PHP can do cool things. PHP Foundation and PHP influencers should promote open source projects that benefit the whole PHP in general not just frameworks and AI slop, to show that PHP can still compete with other languages in the realm of concurrency and parallelism. I'm glad that there's still people make PHP a better language as a whole and thinking forward.
https://redd.it/1sshzsp
@r_php
Reddit
From the PHP community on Reddit
Explore this post and more from the PHP community
Utilizing Claude Skills in client projects
https://spatie.be/blog/utilizing-claude-skills-in-client-projects
https://redd.it/1ssglln
@r_php
https://spatie.be/blog/utilizing-claude-skills-in-client-projects
https://redd.it/1ssglln
@r_php
spatie.be
Utilizing Claude Skills in client projects
Building Custom Modules for PerfexCRM (CodeIgniter)
​
Hello,
I have experience with the CodeIgniter framework and I am now looking to start developing custom modules for PerfexCRM.
While I am familiar with the MVC structure, I want to ensure I follow Perfex’s specific architecture. Could you provide guidance on:
Hooks & Filters: What is the standard way to inject custom code into the admin UI without modifying core files?
Module Boilerplate: Is there a recommended starter kit or documentation for setting up the directory structure and the init.php file?
Database Migrations: How should I handle table creation and schema updates upon module activation?
If there are specific resources for CodeIgniter developers transitioning to Perfex module development, please let me know!
https://redd.it/1sskg9d
@r_php
​
Hello,
I have experience with the CodeIgniter framework and I am now looking to start developing custom modules for PerfexCRM.
While I am familiar with the MVC structure, I want to ensure I follow Perfex’s specific architecture. Could you provide guidance on:
Hooks & Filters: What is the standard way to inject custom code into the admin UI without modifying core files?
Module Boilerplate: Is there a recommended starter kit or documentation for setting up the directory structure and the init.php file?
Database Migrations: How should I handle table creation and schema updates upon module activation?
If there are specific resources for CodeIgniter developers transitioning to Perfex module development, please let me know!
https://redd.it/1sskg9d
@r_php
Reddit
From the PHP community on Reddit
Explore this post and more from the PHP community
Migrator is a global CLI tool that analyses the complexity of upgrading or migrating a PHP project.
https://github.com/Kerrialn/migrator
https://redd.it/1ssjz21
@r_php
https://github.com/Kerrialn/migrator
https://redd.it/1ssjz21
@r_php
GitHub
GitHub - Kerrialn/migrator: CLI analysis tool to check the complexity of your PHP project for migration or upgrading.
CLI analysis tool to check the complexity of your PHP project for migration or upgrading. - Kerrialn/migrator
Your thoughts on reduced config files?
Hello there
I have been upgrading the Laravel with the Laravel Shift tool, but what it did was it removed e-v-e-r-y-t-h-i-n-g from my config files that represented default values.
It removed 90% of the content including comments.
Now I am wondering if I should follow this way, or keep them as they were before.
Personally I think that these configs are documenting stuff that me or some of my team friends could forget that are configurable at all, like i.e. cache prefix, BUT on the other hand this may be a hard fight for the future to keep these configuration files present without breaking the core.
Would appreciate the opinion of people who kept these config files unchanged and these who followed the way of "slimification". Which one seems to be better for you?
https://redd.it/1ssnggg
@r_php
Hello there
I have been upgrading the Laravel with the Laravel Shift tool, but what it did was it removed e-v-e-r-y-t-h-i-n-g from my config files that represented default values.
It removed 90% of the content including comments.
Now I am wondering if I should follow this way, or keep them as they were before.
Personally I think that these configs are documenting stuff that me or some of my team friends could forget that are configurable at all, like i.e. cache prefix, BUT on the other hand this may be a hard fight for the future to keep these configuration files present without breaking the core.
Would appreciate the opinion of people who kept these config files unchanged and these who followed the way of "slimification". Which one seems to be better for you?
https://redd.it/1ssnggg
@r_php
Reddit
From the laravel community on Reddit
Explore this post and more from the laravel community
Your Projections Will Fail — Make Them Resilient
https://medium.com/@dariuszgafka/your-projections-will-fail-make-them-resilient-e996650f56cf
https://redd.it/1sso588
@r_php
https://medium.com/@dariuszgafka/your-projections-will-fail-make-them-resilient-e996650f56cf
https://redd.it/1sso588
@r_php
Medium
Your Projections Will Fail — Make Them Resilient
There is a design decision that separates projections that recover from crashes automatically from ones that needs manual intervention.
Your Projections Will Fail — Make Them Resilient
https://medium.com/@dariuszgafka/your-projections-will-fail-make-them-resilient-e996650f56cf
https://redd.it/1sso4rw
@r_php
https://medium.com/@dariuszgafka/your-projections-will-fail-make-them-resilient-e996650f56cf
https://redd.it/1sso4rw
@r_php
Medium
Your Projections Will Fail — Make Them Resilient
There is a design decision that separates projections that recover from crashes automatically from ones that needs manual intervention.
Wonderful world of worktrees (and Laravel)
https://joeymckenzie.tech/blog/wonderful-world-of-worktrees-and-laravel
https://redd.it/1sssp7n
@r_php
https://joeymckenzie.tech/blog/wonderful-world-of-worktrees-and-laravel
https://redd.it/1sssp7n
@r_php
Announcing Plans for a PHP Ecosystem Survey and Report
https://thephp.foundation/blog/2026/04/22/announcing-plans-for-a-php-ecosystem-survey/
https://redd.it/1sstqzi
@r_php
https://thephp.foundation/blog/2026/04/22/announcing-plans-for-a-php-ecosystem-survey/
https://redd.it/1sstqzi
@r_php
thephp.foundation
Announcing Plans for a PHP Ecosystem Survey and Report
The PHP Foundation — Supporting, Advancing, and Developing the PHP Language
Laravel Reverb + Nuxt 3: Real-Time Messaging, Full Chat App Tutorial
https://youtu.be/bjcM8E5s8p0
https://redd.it/1ssveyq
@r_php
https://youtu.be/bjcM8E5s8p0
https://redd.it/1ssveyq
@r_php
YouTube
Laravel Reverb + Nuxt 3: Real-Time Messaging | Full Chat App Tutorial
In this video, we’ll build a complete real-time chat app using Laravel Reverb for the backend and Nuxt 3 for the frontend. I’ll walk you through the process of creating separate front-end and back-end projects that communicate seamlessly for real-time messaging.…
BETA laravel-permissions-redis v4.0.0-beta.1 — Redis-backed permissions, looking for feedback
Hi ,
Maintainer of [laravel-permissions-redis\](https://github.com/scabarcas17/laravel-permissions-redis) here. Just cut v4.0.0-beta.1 and I'm looking for people to test before I cut stable.
Quick context on what it is
Spatie's laravel-permission is great and it's what most people should use. This package is for a specific case: when you're doing so many permission checks per request (think: a complex admin panel rendering 200+ ACL-gated widgets, or API gateways authorizing fan-out calls) that the DB roundtrips from Spatie become measurable latency.
All reads go to Redis. The DB is only touched on cache miss (warm) or on write (assign/revoke). Writes invalidate and re-warm via events.
What's new in v4.0*
\- Permission `group` metadata preserved in Redis — previously `PermissionDTO::group` was always null, now it's backed by a Redis hash
\- `Role::hasPermission()` — direct role-level check via SISMEMBER
\- Blade directives accept guard override: `@role('admin', 'api')`
\- Queue-backed warming (`--queue` flag on the warm commands)
\- Multi-user-models — `user_model` config accepts an array (useful for User + Admin separation)
\- UUID/ULID role IDs
\- LRU eviction in the in-memory resolver cache + warm cooldown (protects long-running workers and DB storms)
\- `TransactionFailedException` — Redis EXEC failures are observable instead of silently dropped
Breaking
`PermissionRepositoryInterface` gained 3 methods for permission group metadata. If you only use the package as a consumer (not implementing the interface yourself), no code changes required — just run `php artisan permissions-redis:warm --fresh` after upgrade.
Install the beta
composer require scabarcas/laravel-permissions-redis:\^4.0@beta
Release notes: https://github.com/scabarcas17/laravel-permissions-redis/releases/tag/v4.0.0-beta.1
Honest disclaimers
\- This is beta. Don't deploy to prod yet.
\- If your app does <50 permission checks per request, Spatie is probably simpler and fine.
\- Needs Redis. If you can't run Redis, this is not for you.
Open to feedback on: API ergonomics, the upgrade path, whether the new interface methods feel natural, anything else. Will roll feedback into beta.2 or rc.1.
Thanks!
https://redd.it/1ssz0sd
@r_php
Hi ,
Maintainer of [laravel-permissions-redis\](https://github.com/scabarcas17/laravel-permissions-redis) here. Just cut v4.0.0-beta.1 and I'm looking for people to test before I cut stable.
Quick context on what it is
Spatie's laravel-permission is great and it's what most people should use. This package is for a specific case: when you're doing so many permission checks per request (think: a complex admin panel rendering 200+ ACL-gated widgets, or API gateways authorizing fan-out calls) that the DB roundtrips from Spatie become measurable latency.
All reads go to Redis. The DB is only touched on cache miss (warm) or on write (assign/revoke). Writes invalidate and re-warm via events.
What's new in v4.0*
\- Permission `group` metadata preserved in Redis — previously `PermissionDTO::group` was always null, now it's backed by a Redis hash
\- `Role::hasPermission()` — direct role-level check via SISMEMBER
\- Blade directives accept guard override: `@role('admin', 'api')`
\- Queue-backed warming (`--queue` flag on the warm commands)
\- Multi-user-models — `user_model` config accepts an array (useful for User + Admin separation)
\- UUID/ULID role IDs
\- LRU eviction in the in-memory resolver cache + warm cooldown (protects long-running workers and DB storms)
\- `TransactionFailedException` — Redis EXEC failures are observable instead of silently dropped
Breaking
`PermissionRepositoryInterface` gained 3 methods for permission group metadata. If you only use the package as a consumer (not implementing the interface yourself), no code changes required — just run `php artisan permissions-redis:warm --fresh` after upgrade.
Install the beta
composer require scabarcas/laravel-permissions-redis:\^4.0@beta
Release notes: https://github.com/scabarcas17/laravel-permissions-redis/releases/tag/v4.0.0-beta.1
Honest disclaimers
\- This is beta. Don't deploy to prod yet.
\- If your app does <50 permission checks per request, Spatie is probably simpler and fine.
\- Needs Redis. If you can't run Redis, this is not for you.
Open to feedback on: API ergonomics, the upgrade path, whether the new interface methods feel natural, anything else. Will roll feedback into beta.2 or rc.1.
Thanks!
https://redd.it/1ssz0sd
@r_php
GitHub
GitHub - scabarcas17/laravel-permissions-redis: A Redis-powered roles and permissions package for Laravel designed to eliminate…
A Redis-powered roles and permissions package for Laravel designed to eliminate repetitive database queries and deliver high-performance authorization. - scabarcas17/laravel-permissions-redis
PHP will get an AOT compiler from the Swoole team in 2027
>Swoole Compiler v4 introduces a native AOT (Ahead-of-Time) compiler that radically changes the landscape. The AOT compiler abandons traditional PHP interpretation and allows code to be compiled directly into native binary executables. Performance can increase by orders of magnitude compared to the classic interpreter, reaching levels comparable to Rust and Go.
News has appeared in the Chinese segment that Swoole Compiler 4 plans to release a real PHP AOT compiler, roughly 95% compatible with PHP. Some natural limitations like
We have effectively already entered the era of AOT compilation for scripting languages. Similar efforts are emerging for Python and Ruby, and TypeScript already has an AOT compiler.
What does this mean?
It means it will be possible to get rid of the PHP VM and JIT in favor of native code packages that can reach maximum performance. It also means that, in the future, PHP may have multiple runtime environments. And it means that if moving to a compiled language is not part of your plans, you risk being left behind.
I urge the entire professional community to take this trend seriously.
https://mp.weixin.qq.com/s/05I3xe4pgRJufSBG-8Gz6w
https://redd.it/1stb4o3
@r_php
>Swoole Compiler v4 introduces a native AOT (Ahead-of-Time) compiler that radically changes the landscape. The AOT compiler abandons traditional PHP interpretation and allows code to be compiled directly into native binary executables. Performance can increase by orders of magnitude compared to the classic interpreter, reaching levels comparable to Rust and Go.
News has appeared in the Chinese segment that Swoole Compiler 4 plans to release a real PHP AOT compiler, roughly 95% compatible with PHP. Some natural limitations like
$$, eval, and extract are understandable.We have effectively already entered the era of AOT compilation for scripting languages. Similar efforts are emerging for Python and Ruby, and TypeScript already has an AOT compiler.
What does this mean?
It means it will be possible to get rid of the PHP VM and JIT in favor of native code packages that can reach maximum performance. It also means that, in the future, PHP may have multiple runtime environments. And it means that if moving to a compiled language is not part of your plans, you risk being left behind.
I urge the entire professional community to take this trend seriously.
https://mp.weixin.qq.com/s/05I3xe4pgRJufSBG-8Gz6w
https://redd.it/1stb4o3
@r_php
Reddit
From the PHP community on Reddit
Explore this post and more from the PHP community
Your SQLite database is silently getting wiped on every Forge deploy
https://laracraft.tech/en/blog/sqlite-on-laravel-forge-with-zero-downtime-deployments
https://redd.it/1stdcqk
@r_php
https://laracraft.tech/en/blog/sqlite-on-laravel-forge-with-zero-downtime-deployments
https://redd.it/1stdcqk
@r_php
Laracraft
Your SQLite database is silently getting wiped on every Forge deploy
Running SQLite on a Laravel Forge site with zero-downtime deployments? Every deploy quietly throws your entire production database away. Here is why it happens and how to fix it by moving the database into the shared storage directory.
PHPverse is back: the free online conference for the whole PHP community on June 9th!
https://jb.gg/w3z4ck
https://redd.it/1stdvqc
@r_php
https://jb.gg/w3z4ck
https://redd.it/1stdvqc
@r_php
JetBrains: Developer Tools for Professionals and Teams
JetBrains PHPverse 2026 – Bringing the PHP Community Together
Join us for a free virtual event bringing together developers, ideas, and energy from across the ecosystem. Enjoy insightful talks, exciting announcements, and a look at the future of PHP development.