If I had to use one word to describe Drupal 8 compared to other Drupal versions, it would be: order. This order comes with some obvious and not so obvious changes to our way of thinking about Drupal. These are my initial thoughts.
Classes Using classes implies many changes. The most obvious being that one cannot just go in and modify data directly. Setting and getting data will be done via class methods. You cannot just grab an array and start setting and reading keys. Render arrays are the obvious exception but their use and domain has been better defined, which is nice.
One obvious advantage of using classes is that D8 can be more easily unit tested. Previous versions could be tested but it felt like you were going against the Drupal grain and felt a bit forced, in my opinion.
Services Service containers are great. Now we can get to data that we need in an easier manner. We don’t have to bend over backwards to get some needed data from Drupal. We just get the service that provides the data we need and go to town. On the other hand, finding and knowing who provides the data we need is a bit tedious, but I imagine that this problem will slowly go away as we get familiar with these services.
Services also help in unit testing as we can replace services with mock versions that we can control. This helps test classes as we can design and implement tests with known data and expected results.
Twig I love Twig. One of my headaches with PHP as a template language is that it is such an eyesore. I’ve seen D7 templates with a lot of PHP logic baked right in, which is… not good. Twig limits the explicit logic you can use and it’s a good thing. You only feed data to the Twig templates and that is also a good thing. Sure, you can define Twig filters but that is done outside of the template file, which is, again, a good thing as the separation of concerns makes everything clearer to designers and developers. To be honest, this change to use Twig as a templating language is one of the best things about D8.
Conclusion Drupal 8 will need some mental adjustment but, as a whole, I feel it’s a huge step forward. Order and hierarchy help us easily understand other people’s code, even our own past code, as there are fewer ways to do things. This is a huge plus, in my view because it speeds up maintenance of our code base. The architectural decision of using the Symfony framework as the underlying base is also spot on as it will make developers of said framework have an easier time to start developing Drupal solutions and better adoption means good things for our community.