Drupal 8 won't kill your kittens: part 3 of 4 - Why the fear?
by Jeffrey A. McGuire
Part 3 of 4 – On October 4/5, 2013 (depending on your time zone), I hosted a live Hangout on Air with three major Drupal core contributors: Lee Rowlands (larowlan), Tim Plunket (tim.plunkett / @timplunkett), and Daniel Wehner (dawehner / @da_wehner). We talked about what's going on in Drupal 8 and how you will benefit from all the new stuff. This post is the third of four that cover the details of that conversation.
In part 1, you can meet Lee Rowlands, Daniel Wehner, and Tim Plunkett and hear about the events that led to this conversation.
In part 2, you can read, see, and hear about wins for developers in the entity/field and plugin systems in Drupal 8.
Backstory – Lee Rowlands felt "We do a lot of introspection and critical analysis in open source and Drupal, that's what makes it great. But sometimes I think we don't stop and celebrate the wins. And that some of the noise going on around the Drupal 8 developer experience didn't touch on all the wins that we're getting from the changes in Drupal 8. He wrote a blog post and gave a presentation at the Melbourne users group outlining some of the many ways Drupal 8 will be a great experience for developers.
Why do some people think Drupal 8 is "too hard"?
Daniel Wehner - object oriented code - "Drupal has always been this old, procedural, 'simple' system. Nowadays with Drupal 8, everything has been rewritten, so they don't know any particular code. So they have to relearn a lot of code, but [take heart!] not all of the concepts changed."
Lee Rowlands - comparison with moving from Drupal 6 to 7 - "I can relate to those concerns, having gone through the same thing between Drupal 6 and 7. People probably say there wasn't that big a shift, but I felt that there was. I can completely understand that people would feel uneasy about having all these Drupal 7 skills and when they look at Drupal 8, they feel that they might not be relevant anymore. But the underlying concepts are still there. It's really module developers who are going to experience the changes, but I think it's well worth learning because the things that they do learn will bring their PHP and programming skills to modern standards."
"Drupal 7 was built to run on old versions of PHP, so there were concepts we couldn't use in Drupal," namespaces for one. Now that Drupal 8 requires PHP 5.3, "it brings Drupal up to date with a lot of what the 'modern' PHP world is doing. It's a worthwhile investment."
Lee also points out that the Drupal community is full of experts willing to help others learn new skills and techniques, "You're not on your own."
Tim Plunkett - "A lot of what I've heard is the 'we're adding Symfony, we're adding this and that and that's all making it more complicated.' That's funny because a lot of the Symfony stuff is the easier part for me because their documentation is so good and there's other examples. A lot of the hard and confusing parts are just us modernizing to PHP 5.3. A lot of the concepts like dependency injection, dependency injections containers and all is what everyone else is doing." For the Drupal community, "it's just a little bit of growing pains. Symfony is not to blame. It's us finally getting pulled kicking and screaming into modern, object oriented programming."
On "Tribal Skills"
We also discuss "tribal skills" and the fact that Drupal 7's core is obsolete in that "no one writes code like that anymore". The potential danger here is that anyone whose knowledge and experience of coding is limited to Drupal 7 hasn't got much to offer outside of that niche. Whereas, someone who knows her way around Drupal 8 code, has useful, up-to-date development knowledge and a skill set that will be relevant and applicable to a wider range of activities.
Core Planning and Coordination
In response to the question, "How do core generalists get to give feedback on the big picture of Drupal 8 architectural decisions, as opposed to battling it out at the patch level day to day?" Tim Plunkett responds that, "That's what DrupalCon and BADCamp is for. We have these big round-table discussions where we step back and regroup, because most of it is done one by one in issues. Most of the real retrospective stuff happens in person because it has to."
Daniel Wehner adds, "I think what really helped in Drupal 8 was the concept of initiatives, so at least each initiative has its own big picture in mind."
Lee Rowlands has a different perspective on this, thanks to the fact that (as he puts it), "I'm kind of lower level than that ... The stuff that I maintain in core are modules in core and they are kind of the 'use case' for these things or the proof-of-concept. These modules are our real world test case for the new APIs. I'm kind of a consumer on that level, but I'm happy with that."
Won't D8 be "Code Heavy"?
In response to statements that "D8 will be really code-heavy. Writing custom D8 code will require many more lines of code than a D7 equivalent," Tim Plunkett (grinning) said, "If you count white space, you're right. If you don't, then you're wrong. Because we're using methods and not massive, monolithic functions, there's a lot more space in your files, but that actual, functional lines of code are equivalent or less. They're also better, more self-documenting. Anyone who is saying that isn't writing code."
"Another point," adds Daniel, "is that with CMI [which removes configuration from the database and into file, making it exportable and versionable] and the new routing system, a lot of things are now configured in YAML files. So instead of writing code, you just have to adapt a single line in a YAML file, that's it."
Lee makes an important point about the new architecture and the state of development in Drupal 8 (the fact that D8 is not yet a finished, polished, full release), "If you do find stuff where there is duplication, because we have object inheritance now, we can create bass classes that encapsulate a lot of that. If you do find places – recently we've had ControllerBase, FormBase, PluginBase ... These contain common things. We were seeing boilerplate and that allowed us to trim all that down. There's some patches for the config entity stuff to reduce the amount of boilerplate that you need for those ... We're not saying it's perfect, but if there are places you think you see some opportunity for optimization," let the core folks know!
"We've been loosely following the Rule of Three," Tim references a coding practice described well by Anthony Ferrara (@ircmaxell) in his session at DrupalCon Prague, "Where you write something once; if you need it again, you might just copy/paste it; but if you need it a third time, then you refactor. People come in and look at some code and say, 'This is nuts!' but it's only the first time we've had to do it. If we refactor too early, it's gonna be crap and we'll have to do it again." The Drupal 8 codebase is maturing on an ongoing basis, "Every time we regroup and write new base classes. Now is the time we can draw conclusions about how we're using things, how to make it all more accessible, and what is a complete one-off. This is a good time to help with that."
Example of how Drupal 8's architecture reduces "code weight" between Drupal 7 & 8 - Lee gives us a great, practical example of what we're talking about, "We wrote an entity view routing functionality: If you need to output the view of any entity in a particular view mode, there's a one liner you can put in your routing file to do that. We needed a render controller for that entity type, but because we have object inheritance, most of those can just inherit from the base class. The change notice for that is the telling difference between the amount of code required: For Drupal 8, you need a YAML file with 6 lines in it. For Drupal 7, looking at the amount of code that goes into the node view page (example.com/node/1), there were at least 7 functions required to do that and the change notice says what you need to do in Drupal 7 and it's a chunk of text this long [holds hands a meter or more apart], but in Drupal 8, it's like this [holds hands very close together]. That highlights what object inheritance gives us in terms of manageability."
The topics we covered
- Meet Lee, Tim, and Daniel, and how the conversation came about (part 1)
- The Drupal 8 entity system (part 2)
- The Drupal 8 plugin system (part 2)
- Why some people are worried about Drupal 8 and how we see things. (part 3)
- How Drupal core developers coordinate and cooperate. (part 3)
- Will Drupal 8 be more code-heavy? (part 3)
- Theming in Drupal 8 (part 4)
- Where's the Drupal 8 module upgrade info? (part 4 - Answer: it's a little early as of October 2013)
- What's the most compelling feature in Drupal 8? (part 4)