I love seeing Symfony's success. From its components being used in Drupal 8 and many other projects to new developers and companies building and launching large applications in the Symfony Framework every day. I feel so lucky to have stumbled onto such a great technology and community (way back in the 0.6 days!).
Projects love using the Components because they're well-planned and built with best practices. In other words, they're exceptional, and their success has proven this.
Developers love using the Symfony Framework because it encourages you to write high quality, maintainable apps, stays out of your way and gives you access to a whole world of bundles.
The Symfony Framework Experience
But there's something else that can make a framework exceptional: your experience using it. From first download and installation, to building a page, saving things to the database and figuring out uploads: developer experience measures how easy it is to get work done, how often you have "wtf" moments and how quickly you can find answers.
When Symfony was released, we (the community) thought a lot about the Symfony experience: working on documentation, improving error messages and creating open source bundles. But since then, innovation has slowed down and the Symfony experience has stopped evolving. Today, the Symfony Framework is still the highest quality PHP Framework available. But the Symfony experience has stagnated.
Call to Action and the Good News
The good news is that improving the developer experience is easy, and it involves you!
Most developer experience (DX) issues are small and easy to fix. But as a community, we need to find these issues by questioning every step through the process of accomplishing something:
- Is doing X easy enough?
- Is the documentation for my open source Abc123Bundle clear enough?
- I got stuck doing YYY, how could things have been built (or documented) differently to prevent other people from having this issue?
Of course we'll always maintain what makes the Symfony Framework so great: clarity, simplicity and an architecture that promotes long-term maintainability and satisfaction. But within that, there is a ton of great leaps forward we can make.
How? 4 easy steps... and teamwork!
1) The DX (Developer Experience) Label
As of today, the symfony/symfony issues list has a new "DX" label. If you find a developer experience issue when using Symfony, just open up an issue and we'll tag it with DX. This will let us (the community) focus on ways of making every step of using Symfony great.
Check out the DX label right now: I've already added some things.
2) The DX Label for your Repository
Have a Symfony bundle or open source library? Add a DX label to it so that users can start reporting issues. The Symfony experience goes far beyond just the core: it's about creating a healthy ecosystem of high-quality libraries and documentation.
Using a bundle or library that doesn't have a "DX" label? Open your issue and ask them if they'll add the label.
Then, we can see all the GitHub DX Labels.
3) Community Hack Day
And to tackle these "DX" issues, I want to get the community together (remotely) for the first ever community hack day! This day will be about improving the entire ecosystem, including the open source bundles that we rely on. We'll meet on IRC, give each other remote high-fives and start hacking away on DX issues and anything else important.
If you're interested, we would love to have your help! Mark you calendars for July 5th. I'll create another blog post with more details soon.
(I know the date isn't great for people from the USA like me, but we'll have another hack day!).
4) Being Aggressive, Focusing on Beginners
Protecting backwards compatibility is really really important. But even
so, I hope you'll think aggressively and outside of the box about developer
issues. There are certain things like the template naming syntax (that
AcmeDemoBundle:Default:index.html.twig syntax) that have been around
forever. But if there's a better way to name our templates, let's find it!
This example is already being discussed.
And since a lot of us have been using Symfony for years, we've been able to write blog posts about increasingly complex things. That's great! But don't forget that there are new developers joining Symfony everyday. If you have a clear way to explain how to do something basic in Symfony, blog about it! Beginners will definitely be thankful.
What Else?
Got any other thoughts or ideas? Let me know, and let's keep making Symfony the best and friendliest framework in PHP.
Cheers!
really need the missing admin generator bundle, ( simple, straightforward, always updated with latest core release, and no further external dependencies )
it really feels like the missing feature that used to blow away clients. *they were so blown away, they stuck with 1.x and couldn't see a reason to migrate to 2.x
As a Python/Django developer looking at alternatives I would suggest putting more efforts in the auto-admin feature. SonataAdmin is on the right track but it needs a more stable API and some more polishing...
It would be so cool if (a part of) the Sonata project would be adopted by Symfony. At least the Sonata Admin bundle. Just to attract more contributors and improve it. Its architecture is quite good.
It would also be nice to have more official full-stack framework "editions" (like the default " standard" one), e.g. a very simple/clean one and one with heavy-featured demo bundle(s) as an example how things can be handled in Symfony, to make prototyping easier and to make it easier for new devs to understand what editions are and how small/simple the actual framework in fact is.
Symfony framework experience is trying to achieve an objective using undocumented feature. But the documentation isn't all, we can easily find our way by reading the undocumented sf2 source code.
I agree. The admin generator is sorely missed.
More complex Form component examples would be great. There seem to be almost no implementation examples on the web at all. Expanding AcmeDemoBundle considerably and providing a console task to remove it completely, would be great.
Improving the default controller generator, would go a long way to alleviating the admin generator issues.
+1 for sonata admin adopted by Symfony
Very nice initiative.
A big +1 for adopting Sonata Admin Bundle - much needed feature.
Also, a book would be great! I miss the 1.x books. And a step-by-step tutorial like Jobeet would be great. They helped a lot in the old days.
+1 for a good clear tutorial, I think it would take away lots of headaches when people start using symfony. Used this (http://tutorial.symblog.co.uk) one, like 2,5 years ago.
@Ryan — I'd like to help out in this vein and I'm gald to see you leading the charge. Your tutorials at KnpU definitely guided many of my early breakthroughs with the framework and are worth every penny. The work that you and the community have poured into the official documentation is truly remarkable — cheers all around.
In my own experience it would be valuable to consider the documentation for more seasoned developers coming from different languages with similar frameworks. Since SF2 is rigorously decoupled and flexible it's easy to get deadlocked trying to navigate micro decisions and parse the slightly different styles of documentation when reading about a component vs. the component plugged into the framework and how the parts relate. Add in Composer and the some of the PHP runtime configuration options and it get's pretty intense!
My biggest gripe early on was the lack of coherent macro theme and macro perspective when navigating the official documentation and cookbook. Your KnpU courses do a good job of moving through a real world example and keeping a theme but for intermediate users there is a gap between your step-by-step tutorial and more advanced discussions like Matthias's a Year with Symfony which assumes you already grok how Symfony is put together.
There so many parts orchestrated on a given request, and in retrospect it's all very clear and logical but it took a year of working with the framework, reading a wide variety of blog posts, and coming back to the cookbook often before it clicked. The cookbook is especially great when you understand the macro perspective already.
I've kept wondering where the introduction to the framework was that summarized the high level design patterns and mechanics, something in the vein of Fabien's "Create your own framework... on top of the Symfony2 Components" but inverted to focus on how/why Symfony2 is preconfigured in a certain way. I got in the mix around Symfony 2.2 and been plussed to see things settle down with 2.4 and 2.5.
The modular, highly configurable, non-magical conventions of Symfony2 pulled me back into the PHP community — who knew server side programming could be so much fun?! I think you're on to something with this DX stuff: subtle shifts in fuzzy areas could lead to higher groks per minute for intermediate and beginner developers.