Making the Symfony Experience *Exceptional*
June 18, 2014
•
Published by
Ryan Weaver
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!
Help the Symfony project!
As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.
Comments are closed.
To ensure that comments stay relevant, they are closed for old posts.
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
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.
Improving the default controller generator, would go a long way to alleviating the admin generator issues.
A big +1 for adopting Sonata Admin Bundle - much needed feature.
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.