1. Improved code quality.
Drupal’s core maintainer team changed their entire development philosophy early in the design stages for D8. Prior to this, there was an overall attitude that Drupal should only contain code written by the Drupal maintainers themselves. This served them well in the Drupal 4 and 5 days, when the PHP open source ecosystem was in its infancy, and code quality could not be relied upon. But with the rise of composer (PHP’s de-facto package manager) and with the introduction of PHP language improvements such as namespaces and autoloading, the Drupal community was falling behind; many packages were in wide use, providing the same functionality as bits of the Drupal monolith, but with improved code quality and performance. The core team decided to re-architect the entire application built on components (most notably Symfony) which could be integrated easily using composer. This meant that Drupal was no longer an open source pariah, but a coequal player in the Open Source ecosystem. In fact, during the PHP 7.0 development cycle, the Drupal 8 test suite played a big part in revealing bugs and shortcomings within PHP itself; many of those tests are shipped as part of the PHP source tarball.
Additionally, D8 has moved away from its rudimentary testing framework, Simpletest, to the most widely-used testing framework in the PHP world, PHPUnit.
Because of Drupal’s entrance into the wider Open Source world, integration with other PHP software became much more widespread. Since Drupal has a seat on the Framework Interoperability Group (PHP-FIG), they can both influence the direction of cross-platform standards as well as implement the standards agreed upon by others. An example of this is D8’s Logger component. Because it is coded against a standardized interface, you can easily replace it with any other component implementing that interface, such as Monolog, a highly-regarded off-the-shelf component with its own development and maintenance team.
2. Improved performance
Drupal 8 has a much more sophisticated cache system than any previous versions. This was necessary in order to compensate for some of the overhead introduced by Drupal’s code finally becoming truly object-oriented (see point 1 above). Additionally, with the introduction of BigPipe and its stabilization within Drupal core, even highly user-personalized pages can be served mostly from cache, with the user-specific parts streamed after page load. This yields a significant improvement in perceived page-load time.
3. Improved templating
Very early in the D8 planning process, before D7 even reached its first stable release, the Drupal core team decided to replace its old templating engine phpengine with Twig, a highly-cached template language shipped as part of Symfony. Twig forces separation between code logic and display rules, because PHP can no longer be embedded in the templates. Twig also allows for construction of customized filters, allowing the developer to offload complex display twiddling to external functions. Finally, Twig also allows for template and block inheritance, leading to a much smaller and more maintainable set of templates in situations in which, for example, different content-types need different templates.
