Announcing our plans for ReactPHP v3

[clue]

ReactPHP v3 is going to happen! 🎉

We're committed to work on the next major version, ReactPHP v3! Thanks to everybody who contributed to the ReactPHP wish list, we were able to come up with this rough roadmap for the next major version of ReactPHP.

Our plans

These are our plans with the highlight features we want to see for ReactPHP v3 (details may still be subject to change and we welcome discussions!):

• Blocking APIs and async APIs ^(discussion)

  Async APIs have always been what makes ReactPHP more powerful and efficient than traditional PHP, but always came at the expense of increased complexity. Starting with ReactPHP v3, we will provide new APIs using synchronous return values just like traditional PHP to ease integration. We will continue providing async APIs as well, so you get the best of both worlds and can use whichever style works best for your use case. Synchronous APIs will likely become the new default to make getting started even easier.

  In a gist, you should be able to do this in v3:

  try {
      $response = $http->get('http://www.google.com/');
      var_dump($response->getHeaders(), (string)$response->getBody());
  } catch (Exception $e) {
      echo 'Error: ' . $e->getMessage() . PHP_EOL;
  }

  On top of this, we will keep our async APIs by renaming existing async methods like this:

  $http->getAsync('http://www.google.com/')->then(function (Psr\Http\Message\ResponseInterface $response) {
      var_dump($response->getHeaders(), (string)$response->getBody());
  }, function (Exception $e) {
      echo 'Error: ' . $e->getMessage() . PHP_EOL;
  });

• Type-Safe APIs ^(discussion)

  All our public APIs should use native type declarations to avoid invalid API usage and guide IDEs and static analysis tools. This plays especially well the new blocking APIs that will accept and return native PHP types (no more promises, I promise). A long-awaited improvement which also means it's finally time to say goodbye to legacy PHP versions 👋

• Better error handling defaults ^(discussion)

  We want to improve error and exception handling by making sure all errors should be shown by default unless explicitly hidden. In particular, the new blocking APIs would finally throw exceptions as expected. On top of this, promises would no longer discard uncaught exceptions (as discussed in Detecting unhandled rejections promise#87):

  $promise->then(function () {
      throw new \RuntimeException('I should be shown');
  });

  There are still some other scenarios like exceptions happening in event handlers where we want to apply similar behavior, but we haven't decided on details yet. For more information on this, check out the discussion.

• Better support for PSRs ^(discussion)

  We want to make integrating ReactPHP into your applications, libraries and SDKs as easy as possible. Thanks to the new blocking APIs, implementing PSR interfaces will be much more feasible. In particular, we would love to support PSR-15, PSR-16, PSR-17, PSR-18, and possibly more. We're still evaluating how much of this will make it in time for the v3 release, so make sure to join the discussion.

• PHP 8.1+ recommended, PHP 7.1+ required ^(discussion)

  In order to make use of newer language features, we want to raise our range of supported PHP versions from PHP 5.3+ to PHP 7.1+ with ReactPHP v3. Using PHP 8.1+ is recommended for best performance and interoperability with fiber-based APIs, but we will continue to support PHP 7.1+ to make sure ReactPHP v3 runs absolutely anywhere (no excuses). We believe this compromise will benefit everybody while not affecting >99% of our existing users.

• Default loop ^(discussion)

  We're planning to make our APIs easier to use by making the event loop entirely opaque and by removing all optional loop parameters from our API:

  // old (v1)
  $loop = React\EventLoop\Loop::get(); // or deprecated React\EventLoop\Factory::create();
  $browser = new React\Http\Browser($loop);
  
  // new (v3 and v1.2+)
  $browser = new React\Http\Browser();

• LTS 24+ months ^{(discussion & discussion)}

  We plan to provide at least 2+ years of long-term support (LTS) for v3 or longer depending on the future v4 release. Once v3 is released, we will mark v1 end of life (EOL) after a reasonable transition period. We're currently planning for ~6 months, but if your project or company requires longer-term support for EOL versions, please reach out and we may be able to work this out on a case-by-case basis.

Next steps

Now that our plans are published, we're excited to start working on our upcoming features! We will start with creating v3 branches in all ReactPHP repositories in the next couple of weeks and will share more detailed insights regarding ongoing development along the way.

With the current work load and priorities, we expect early development versions to be available early/mid 2024 and estimate v3 to be ready some time mid/late 2024. [Update: We're still looking for sponsors, so release had to be postponed.]

Working on the next major version involves a lot of work and we're always looking for sponsors to allow us spending more time on ReactPHP. Check out ReactPHP's sponsors profile and consider supporting the ongoing development ❤️

Looking forward to getting this shipped! Let us know what you think! 🚀

[SimonFrings]

The ReactPHP v3 roadmaps are live! 🎉

We are excited to announce the now officially released plans for our ReactPHP v3 components. @clue has created roadmap tickets for all components that will be receiving a v3 update, here is a quick overview:

• Roadmap to Cache v3
• Roadmap to DNS v3
• Roadmap to EventLoop v3
• Roadmap to HTTP v3
• Roadmap to Socket v3
• Roadmap to Stream v3

The features listed in these roadmaps contain a summary of the key features for ReactPHP v3. In order to show the ongoing development, we'll update these tickets as we make progress. Most of the 3.x branches are already in place containing the first v3 additions.

There are certain components that have not yet received a v3 roadmap because we are still in the process of discussing our plans for them. I opened up tickets to address how we can ensure that these components are aligned with the upcoming ReactPHP v3

• ChildProcess with ReactPHP v3
• Datagram with ReactPHP v3
• PromiseStream with ReactPHP v3
• PromiseTimer with ReactPHP v3

As of today (2024-03-18), we're working on a ReactPHP HTTP v1.10.0 to unblock the HTTP v3 development and expect this to go live in the next week(s). There are still some outstanding features important for both HTTP v1 and v3, so to avoid doubling the work and to create a clear cut to ease upgrading, we should finish the v1.10.0 release before creating the 3.x branch.

Working on the next major version involves a lot of work and we're always looking for sponsors to allow us spending more time on ReactPHP. Check out ReactPHP's sponsors profile and consider supporting the ongoing development ❤️

We're more than excited about ReactPHP v3, looking forward to getting this shipped! 🚀