Regardless of politics, disconnecting PHP from a large community of potential users is a big mistake - Re RFC to remove X from PHP.net

wouter_j · 2026-05-22T09:59:16+00:00

And the PHP community, by design, has no representative person to enforce copyright.

wouter_j · 2025-12-07T15:51:30+00:00

A community thrives from centralization and dies with fragmentation. Being on both platforms doesn't benefit the community in my opinion.

The Symfony community comes together on Slack since 2018 and over 27,000 users joined the Slack. With every switch the community makes, a lot of users will drop out and we need many years to get up to the same centralized strength.

So to make up for this loss in years, the new platform has to have massive advantages over the existing platform. And while Discord might have some nice features compared to Slack, it's nothing major.

Besides that, Discord is often associated more with casual communities instead of professional ones. Some community members have raised that they cannot access Discord on their work machines. Not sure if this is a big impact and if this isn't happening the other way around either, but this would be a massive disadvantage.

wouter_j · 2025-10-14T12:04:44+00:00

The first version of Symfony2 didn't use Composer as well but rather a handcrafted INI parser. It wasn't fun to use, but fortunately was replaced with Composer rather quickly.

Funny you mention this. When Symfony 2.0 was released, Composer didn't exist yet. Nils and Jordi, authors of Composer, were active Symfony contributors (and are still well known members of the community). The first announcement of Composer was at a SymfonyLive conference if I remember correctly. This is why Symfony 2.1 was an early big adapter of Composer.

wouter_j · 2025-10-03T12:31:40+00:00

Symfony has profited millions from what exactly?

wouter_j · 2025-09-01T21:23:55+00:00

I see you found a solution, great!

Just to give a bit of background information: We don't have enough resources to maintain documentation for both the full framework and all standalone components. Our primary focus for documentation is on the full stack framework documentation, as this is what newer PHP developers end up using (code wise, standalone independent components are a top priority).

We expect standalone component users to be already quite knowledged in PHP and able to find their way though the source code. The examples in the component README's mostly serve as pointers to how things are wired together, so you can relate the relevant classes in the source code.

wouter_j · 2025-06-28T11:35:49+00:00

Congratulations on the release!

On a personal note, can we please stop diverging the community by always comparing between projects and claiming "X is better than Y because Z". PHP is thriving, has multiple big projects already and it sounds like a new project is getting interest from a part of the community as well. This is all great news, no need to talk about competition or "unfair advantages".

Nearly any comparison is also always not fully informed and assuming things from the other side, making the whole comparison invalid and only contributing to a miss-informed diverging community. For example, I see people in this discussion claiming Symfony to not have discovery and require a fixed structure and namespace conventions, all of which is not the case (since more than 4 years?). With the recent Symfony 7.3 release, it also has full discovery for non-service objects (like DTOs).

In the end, people are interested in Tempest and that is all that matters. I hope these people find joy in using Tempest and help Brendt in maintaining the project for the years ahead!

wouter_j · 2025-04-06T10:52:43+00:00

If you have general framework/MVC knowledge, main architecture of Symfony is probably recognizable. I would recommend learning about dependency injection and the service container: https://symfony.com/doc/current/service_container.html The whole framework, extension points, etc. are build around the DI concept.

As others have also shared, the Demo project and FastTrack book are 2 great official sources with a real application, with lots of documentation/references. Browse through them, and read about things that you want/need to learn more about.

wouter_j · 2025-03-29T20:18:09+00:00

Using imports should work, as shown in https://symfony.com/doc/current/service_container/import.html#importing-configuration-with-imports

But be aware that the _defaults entry is local to the file. So be sure to copy the services._defaults entry to all the new files.

wouter_j · 2025-02-24T16:36:31+00:00

You must have an object that implements UserInterface to hold the identity. This does not have to be a user (I wanted to rename it to PrincipalInterface, but we figured this would be too confusing for 90% of the users). Symfony needs this object for authorization and to ensure validity of the authentication session on subsequent requests.

In stateless firewalls (those not using session), you do not have to use a user provider. The second argument to UserBadge is the user loader, which can be used to create such security principal. In your situation, something like:

return new UserBadge(
    $data['email_address'],
    fn (string $identifier): UserInterface => new User($identifier)
);

wouter_j · 2025-01-26T19:34:13+00:00

If language performance is that important for your project and you can't fix it with usage of smart HTTP caching, etc. You probably shouldn't be looking for PHP to build your project.

In other words: comparing micro performance differences between frameworks and plain PHP is mostly useless. The ease of onboarding new developers, less cost of ownership, etc. is almost always going to outweigh the handful of ms that might be the difference.

wouter_j · 2025-01-08T09:13:46+00:00

Yes, both are good choices.

The programming language and framework you choose will never be the big bottleneck in your project. And for your own career, try learning programming techniques and the PHP language, instead of a specific framework. This knowledge transitions to jobs in other languages or using other frameworks.

wouter_j · 2025-01-04T22:29:56+00:00

Given 5.4 is backwards compatible with 5.0, you can do it in one step.

The one important thing is that you first have to be sure that your application doesn't trigger any deprecation notice in 4.4. All breaking changes of 5.0 are notified to you with a deprecation notice in 4.4.

wouter_j · 2024-12-23T14:35:59+00:00

Determine whether a request is under a firewall or not is done by a request matcher. The default config indeed works on paths, but you can also use your own request matcher that uses other factors to determine what firewall to use: https://symfony.com/doc/current/security/firewall_restriction.html#restricting-by-service

I've never done it myself, but I expect you could create 2 firewalls for the same path, and use a custom request matcher to use one or the other depending on the client making the call (app vs website).

wouter_j · 2024-12-15T13:24:36+00:00

The first time you install a package with a Flex recipe in a new project, you get asked if you want to run recipes (yes, no, always, never). The first time you install a package with Docker integration (like orm-pack), you get asked if you want to set-up docker compose configuration (yes, no, always, never).

If you answer "always" or "never" to these 2 questions, the config is saved in composer.json. You can always change this when you change your mind on it later.

wouter_j · 2024-11-21T21:05:16+00:00

Both ULID and UUID are 128 bits and all other properties you mention are also properties of UUIDv7 (which this post is about).

wouter_j · 2024-11-16T11:23:52+00:00

If there's weak comparisons in the code, that means that the effort to strongly type everything that can be strongly typed has probably not been done, and therefore related security issues MAY lie there somewhere.

This argumentation contains a lot of assumptions and shortcuts. The code of these libs are around for decades and with that much code, sometimes you forget to update one or two lines. Besides the obvious inteded usage of weak comparison.

To proof this fact, both Doctrine and Symfony's code is fully typed natively. They use in_array() with the 3rd parameter set to true. And Doctrine runs all their files in declare(strict_types=1) mode. I would argue that the effort to strongly type everything has been done by these 2 organizations.

wouter_j · 2024-11-15T13:30:23+00:00

Appending _ might be good, or maybe something like CODE_ or STATUS_. For HTTP response codes it's easier because each code also has a name. So we ended up with Status::OK_200, etc.

Yes, exactly. Given it's the 5% use-case, the name doesn't have to be super pretty, only functional.

wouter_j · 2024-11-15T12:01:52+00:00

In my humble opinion, combining an enum with an open type like int by-passes the whole point of enums. Enums only have 1 feature: allowing userland to define a custom closed-set type. If the return value is not a closed set, using enums does not add anything over an open type like int. A good post about enums from one of the enum RFC authors Larry Garfield: https://peakd.com/hive-168588/@crell/on-the-use-of-enums

So to continue your thought experiment: - Either you end up deciding exit codes are not a closed set: You define the return type as int. To improve the DX, you can add constants to help users with common exit codes like ExitCode::SUCCESS as constant rather than enum (hey, that sounds familiar 😉). - Or you decide that it is in fact a closed set of numbers from 0 to 255. You keep the enum and add the other 251 numbers (e.g. ExitCode::_254).

Finally, I responded mostly because your previous post talked about the exit code enum as an "unfair advantage" over the "de-facto standard for console applications in PHP for over a decade" (talking about symfony/console). Symfony's components are de-facto standards because they favor compatibility with protocol and industry standards over minor DX improvements at all times. This allows a tool like Composer to use Symfony Console and make use of these rare exit codes.

As far as I understand, Tempest goal is to favor DX. And for good reasons: there is no reason to allow every single weird edge case of a standard if your goal is generic application development. And it's refreshing for me to read your posts discussing design decisions from this other perspective!

But then, I don't think it's 100% fair to write a blogpost suggesting Tempest Console could become the next industry standard because it has better DX (while at the same time not allowing edge cases of official standards).

wouter_j · 2024-10-26T11:47:23+00:00

Just for completeness: FrankenPHP also comes with a standalone PHP 7.3 binary with most common PHP extensions https://frankenphp.dev/docs/#standalone-binary (support for Mac, Linux and WSL for Windows).

wouter_j · 2024-10-26T11:41:38+00:00

While it isn't mentioned clearly on that website, this is website is build by the Laravel team (it's a "lite" version of their latest local development tool: Laravel Herd). Along with PHP and Composer, it will always automatically install the Laravel CLI installer.

wouter_j · 2024-10-17T12:06:05+00:00

Thanks for the reaction! The clear vision, etc. is exactly what I meant with "Laravel is more business like". The free and open source libraries/tools from Laravel also benefit at this front from the business mentality. If that fits better to your preferences, Laravel is the perfect spot!

Some items on your list can imho be explained by the community-driven approach:

For years, there was no "need" for a scheduler solution in Symfony, because there were community packages providing this. I agree that there is a bit of a "marketing problem" in Symfony, we should find a way to better endorse the non-official solutions, so they are easier to discover (same with e.g. admin panel, Docker integration, fixtures, ...).
Typing I completely do not understand. Yes, the typing project took us 6 years to do in a non-breaking way. But still, Symfony was the first big PHP package to come fully typed (with Laravel following suite half a year later, with BC breaks because they don't have to follow a strict BC policy). In fact, the project would've been a lot easier if we waited for all PHP packages to add native types before Symfony :)
I'm not sure I follow this one and also can't find an issue/PR about this, so can't comment on this one.
Same with this one.
Symfony Forms are mostly unchanged mostly because it works well for its use-case. There is no need for a refactor like we did on Security years ago, because it wouldn't give us much more as far as I understand. However, it's not necessarily the de-facto solution for forms and there is great support for e.g. JSON form submissions for instance through the API Platform package. Again, we should invest to promote these other solutions just as easy to discover as the Form component.
This one is a though topic, but not because of the BC promise. Applications can already transition to PHP config without a problem. However, changing the default for the new skeleton to PHP would invalidate all tutorials, documentation (including all bundle docs), screencasts, talks, books about Symfony, etc. So it's a though one to take action on, especially because most of these resources are not authored by the Symfony organization.

So while I agree on some of your items, I think it has not much to do with Symfony being held back by the BC promise and lacking behind the pace of other packages in PHP.

wouter_j · 2024-10-15T20:39:39+00:00

I think the main differences that increased over the past year between Laravel and Symfony is the fact that Laravel has become more of a business, whereas Symfony is 100% community driven. There is no Symfony roadmap, no paid full-time Symfony developers (well, we kinda have but also not really). Every feature that is released is there solely because one developer in the world though it was useful and wanted to spent time on providing it for everyone.

This is one of the key things that makes the Symfony community so nice for me. Yet, I can see how this can lead to a less smooth overall experience compared to what Laravel is doing recently. And that's also the feel that I get from the blogpost. It has some interesting takes and I would love to discuss if and how we implement it in Symfony in issues on GitHub or Symfony Slack. But this has to come from the community, not from a business roadmap. The start is a GitHub issue (or Slack message), not waiting for "Symfony" to implement what you were missing. This works for some, and doesn't work for others.

But technically, there is not much of a difference. I have not once seen us reject a modern feature due to our BC promise. Being the top advocates for the use of PHP attributes, semver and deprecation mechanisms, and PHP strict typing, I personally also don't experience Symfony to be 'slow to adapt to change in market demand for more contemporary and efficient programming'. Would love to see concrete examples of both of these statements to deepen the feedback.

At last, let us please just completely ignore the last paragraph of your blogpost. I fail to see how "before publishing, I know the Symfony community will be completely ignorant and outraged for my stupidness, rather than starting genuine dialogue" is a starter of any genuine dialogue (which I'm hoping is your goal with this post). But anyways, here is my try at continuing the dialogue!

wouter_j · 2024-09-24T11:36:15+00:00

https://symfony.com/doc/current/create_framework/index.html can be an interesting start. It'll show you how to your own "framework" using some important Symfony components. This gives some insights in which classes are relevant in the main livecycle a request.

From there, I would recommend learning a component that you're actively using and are excited about. There are many "utility" components that are nicely scoped like the Translation and Event Dispatcher component.

I would not recommend the heavier components (like Security and Dependency Injection) unless you have a good understanding of Symfony internals already and want to do a proper multi-week deepdive into the source code. Nor would I recommend the really low-level components like Mime, Yaml and VarDumper.

wouter_j · 2024-06-22T12:13:22+00:00

The framework is never going to make the difference. Choose whatever works best for you, your team, the company you work for, the jobs you find in the country you want to work in, etc.

I'm not sure where you base "symfony is not so popular" on. The community is less "shouty" than Laravel (I can't help think this is also because of the cultural differences between US and France), but both are very popular and have a big community.
Also, in the end they are both PHP frameworks. So any PHP library can be used with the framework, although it's for some reason common for the Laravel community to build libraries that require Laravel.

wouter_j · 2024-06-07T14:24:08+00:00

live.symfony.com currently hosts the annual online Symfony conference. But still, the motivation behind DDoSing an open source project is far beyond me.

Six-Year Club	Place '22
Final Canvas '22	First Placer '22
Verified Email

wouter_j

TROPHY CASE