Cloud Platform
10 Reasons To Start Projects with Drupal 8
Sorry Drupal 7, it's not you, but it's time to move on... (to Drupal 8).
As developers, we sometimes forget that we live in a tech bubble. In our highly technical world we assume things that not everyone sees.
For example, there are still reasons that clients frequently cite to justify staying in an old version of Drupal, in this case Drupal 7, instead of starting a new project straight away in Drupal 8. This is true even when we are talking about starting a brand new project (as opposed to just migrating).
Most of the time these reasons are business-related, or politically-related reasons -- not technical. And the problem is that without having the right technical background, these reasons often cause clients to underestimate the impacts and benefits that are achieved by making the right choice based on the technology.
In this post, I'll try to give you enough reasons (ten to be precise) to overcome these non-technical roadblocks to starting your next project in Drupal 8 (or decide that the time has arrived to migrate to Drupal 8).
Being in Drupal 8 means embracing innovation itself. Of course, there are shiny new features in Drupal 8 that are not available in Drupal 7. This is not unique to Drupal. In any new software release there are new features that were not present in the previous iterations, and these new features should improve different aspects of the product, from user experience to editorial experience to development experience, just to name a few.
But, coming back to Drupal 8, there is another major reason to start a new project (or upgrade any existing project) in Drupal 8: the new release strategy that was launched with Drupal 8. This means that we can expect not just big changes, when moving from one major version to another (that is, from 6 to 7, from 7 to 8, or from Drupal 8 to Drupal 9 whenever that happens). Since Drupal 8, the new release process allows Drupal to introduce major features in the current release, which in my opinion is a game changer, and not just for developers.
For example, let's see some of the changes introduced:
- Drupal 8.2: Outside-In, a new experimental module provides the ability to change the most common configuration from the Drupal front-end (see https://www.drupal.org/node/2786039)
- Drupal 8.3: BigPipe became stable, which provides an advanced caching implementation based on Facebook's BigPipe. It also introduces Workflows and Layout.
- Drupal 8.5: Introduction of Layout Builder, which provides editors the ability to customise the layout of their content (see https://www.drupal.org/node/2924128). BigPipe also will be enabled by default in the Standard profile.
- Drupal 8.6: Introduction of Workspaces, which should improve the way editors release content to production (see https://www.drupal.org/node/2968491). That in itself is going to be a game changer.
Drupal 8.6 will also see a new way of installing Drupal much easier and following just a single step, which should pave the way for new adopters (see https://www.drupal.org/node/2969396)
I think you get the idea.
For more visibility on the features that are coming in Drupal 8, this filter can help: https://www.drupal.org/list-changes/drupal/published?keywords_description=new+experimental+module&to_branch=&version=&created_op=%3E%3D&created%5Bvalue%5D=&created%5Bmin%5D=&created%5Bmax%5D=
So far we've been talking a lot about Drupal 8, understanding this as the core code. But what about one of the most important things in the ecosystem, the contributed modules?
There are great, very smart, minds out there contributing and making this bigger and bigger. And, you know what? Most of them (if not all) are, as the rest of the community, focused on Drupal 8. What matters is that the bulk of the community has already forgotten about Drupal 7 and are focusing all their efforts on making Drupal 8 great.
In the next months you'll see that many of the most exciting, amazing ideas, and the most creative solutions to vexing problems, are not not available in Drupal 7.
If you consider that Drupal 7 End Of Life is around the corner, maybe around 2021, starting a new project in Drupal 7 can result in a shameful (and expensive?) way to underutilize your resources.
This means that whatever you are doing in Drupal 7, it will have to be rewritten whenever Drupal 7 gets deprecated and runs out of grace.
What about the cost of ownership? In Open Source we often neglect the costs of running projects, because licenses are non-existent or weird to have. But there is a cost of maintenance that can't be ignored.
Drupal 8's new release cycle may increase, in some cases, short-term maintenance. That is, we may need to upgrade the site more often, involving more frequent release upgrades. However, the promise is that those new minor releases strategy should get relatively easier and painless as the new platform matures, and in exchange they will provide a healthier/cleaner codebase.
Long term maintenance, by contrast, avoids the huge cost of having to migrate from a major version to another, such as from Drupal 6 to Drupal 7, or Drupal 7 to Drupal 8.
Since the launch of Drupal 8, migrating to new major releases is not that difficult anymore. It also helps that modules are now compatible between immediate major versions (see point 8 for more information on this), so no more I cannot upgrade to Drupal 9 because my favourite module is only in Drupal 8. Chances are that the Drupal 8 module is already compatible with Drupal 9, it just will contain some deprecated --not breaking -- functions that should be addressed before the next major release, in this case Drupal 10.
Yes, all releases are covered, and big security issues have provided patches even for Drupal 6, but be aware that the focus of the community efforts is with Drupal 8.
Drupal 8 has all the attention now, all the community is focused on improving it, making it faster, more secure, and easier to use. Remember that major new security flaws are normally discovered in the current stable version, Drupal 8 in this case, and if they are really critical, they get backported to Drupal 7 (and in some rare occasions even Drupal 6 as we saw in the latest #drupalgeddon events).
If you care about your users, you should make the move to Drupal 8. I am talking about both users: final users affected directly by the frontend that you are building, and admin users too.
For a start, Drupal 8 has been from day one focused on the user experience, bringing initiatives like mobile first to the front lines.
But it's not just about the end user. Site builders and editorial teams in general play a hugely important role in our ecosystem, and we can see how their experiences are starting to be prioritised with initiatives like admin UI and JS initiative. See: https://www.drupal.org/about/strategic-initiatives/admin-ui-js https://github.com/jsdrupal/drupal/wiki/Follow-the-Initiative-&-Get-Involved
If you are interested to know what is coming down the road in Drupal 8, this repository is a very interesting place to start. You can even install a Proof of Concept which shows how the new admin interface will work: https://github.com/jsdrupal/drupal-admin-ui
Keep in mind that there are two main actors playing here: the developers on one hand, but also the site builders or the users who will be in charge of administering the site.
Developers: Who does not love the latest shiny thing? The highest difficulty in moving to Drupal was the high amount of what has been named as Drupalisms, which normally made the transition harder, with the tendency of isolating those developers on the Drupal island.
Drupal 8 has taken a path of a more conventional and standardized architecture, with Symfony packages in the core, but also with the modules taking an Object Oriented approach. That means that developers stop talking about hooks, and instead talk about events, or about extending objects, etc⦠A vocabulary that anyone in the PHP world would immediately understand.
That means two things. On one hand it should be easier to recruit Drupal developers now, as Drupalisms are not as present as before and the learning curve is not as steep for a developer coming from other frameworks (like Symfony or Laravel) as it was before.
On the other hand, Drupal developers already in the Drupal 7 world should not have many difficulties understanding what we already have in Drupal (modules, hooks, â¦), even as they learn the new concepts that are being introduced, such as how modules are now built, how they are registered, how we can hook into the block system, the event system inherited from Symfony, etc...
What it also means to this group of developers is that, whatever they have to learn, it's a path that opens them to the world, making them less Drupal-specific and more complete developers, introducing them to tools and concepts that are not Drupal- but PHP-specific. It makes the knowledge they learn more re-usable, even for the roles they are in at the moment.
With all these things in mind, any Drupal 7 developer should be pretty excited to learn Drupal 8, and the cost for the company to train them should not be extremely high. As we've already seen, Drupal 8 is not a completely new world after all.
From site builder perspective, while Drupal 8 has a familiar interface and allows easy transition, there are ongoing initiatives that provide major usability improvements and refinements (see point 4 for references to the initiatives).
So if you check a Drupal 7 and a Drupal 8 admin interface, you'll notice that very few things are different there. For now, although some work and research or training may be needed to understand the new paradigms, if you are working in Drupal 7 you will find yourself on familiar land while working with Drupal 8.
Yes, I know I said that Drupal 8 now introduces big changes between minor versions. The Admin UI initiative may be introduced sooner rather than later, it could even happen in Drupal 8, and that would mean dramatic improvements (and changes) on the administration interface. However, whenever that happens, it's likely to be a smooth transition in which an administrator can decide to switch to the new interface now or wait to have that in later versions or on a more convenient moment for their projects and/or timelines.
As we have already mentioned, Drupal is less Drupal-centric now, with more work shared with other communities like Symfony.
At the same time, developers don't want to get stuck in a single technology stack (or they should not want to) . If you keep them in that same stack for too long, they'll leave or -- what is worse for your company -- they will stay. Both are bad because they can lead to complacency, and a tendency not to research beyond the problems immediately ahead, causing things like stagnation and lack of innovation.
And what about developers? The experience has dramatically improved for them too. It is now much simpler to accomplish both very easy and out-of-the-box tasks like building artifacts for deployment, and also building tests, finding regressions faster, etc.
See for example Acquia's BLT tool, not available in D7: https://github.com/acquia/blt/.
Some other nice features introduced in Drupal 8 are, for example, the registration forms. In Drupal 8 they are much more customisable by the site builder, while in Drupal 7 most of the time we had to do this from the backend via code, and it could not be changed unless a developer was involved in the process. Also the layout initiative, as we saw, is improving dramatically the UI for the site builders, so building pages like landing pages is becoming easier, more robust and more powerful than in D7. And, oh my God, how cool is to have a single command which result gives you a URL with your new site ready to rock?
And, of course, there are all those niceties that we already know come boxed in Drupal 8, like REST API based, JSON integration, OOP, etc.
Whenever a new version of Drupal is shipped you will read tons of articles saying that the new version is slower than the previous one. Drupal 8 vs. Drupal 7 is not exempt from this, but not being careful with the comparison is just missing the bigger picture.
Drupal 8 has a lot more functionality included in its core. This doesn't mean that the core is more heavy, it just means that 96% of the sites in Drupal 7 were delivered with modules that now are included in Drupal 8.
And that's where the problem lies: comparisons don't typically consider that fact, and they don't include common Drupal 7 modules that are not included on those performance measurements and hence, they end up comparing different footprints.
If you are interested in this topic I'd recommend you to read this article from Jeff Geerling: https://www.jeffgeerling.com/blog/2016/yes-drupal-8-slower-drupal-7-heres-why
But pesky performance tests apart, what is true is that Drupal brings big improvements in performance for the average site. In Drupal 7 for example, talking about caching meant talking about caching for anonymous users. But let's be honest here, isn't Drupal designed to have authenticated users in mind? What happens with the traffic for those users' growth?
Well, you were basically in trouble. You could do things like leveraging caching on the auth_cache module, but if you did not have that in mind while designing your site, the level of work to ensure the users were receiving the expected experience is far from a small effort.
Drupal 8 has things like Bigpipe and authenticated users cache, which would make the effort of delivering the content to auth and anon users a breeze compared to what that meant in Drupal 7.
In general, if performance is a concern for you, you should have in mind that Drupal 8 comes with PHP7 support, which is much faster than previous versions; caching and loading speed has also been improved.
In a lot of meetings and audits, we get the question, Why don't we just wait for Drupal 9? This is something some companies do to avoid big migration costs every few years, and it applies not just Drupal, but any other software package.
Sometimes that makes sense, but in this case, the Drupal 8 architecture and the new life cycle promises very smooth transitions from now on, so forget about the pain of those big release changes when you move from Drupal 8 to Drupal 9. As we have seen, that is history now.
Saving costs this way was a very valid argument before Drupal 8. Why migrate from Drupal 6 to Drupal 7 when you could wait, migrate directly to Drupal 8 and save one iteration of migrations and costs, right? In big (and not that big) projects that could mean HUGE savings.
As we have already mentioned, Drupal 8 has a new release cycle, with lots of new improvements in the current stable release, and with an interesting improvement on the way that major releases are included in the family. From Drupal 9, major versions will not be completely incompatible between them.
That means that your Drupal 8 modules will still work in Drupal 9. You'll just get notices advising you to upgrade libraries, function calls, and anything else in your code that would make your module incompatible with a Drupal 10 version. But, theoretically, nothing that would break your module/site.
This black magic is possible basically because now we don't get libraries simply removed from the core, and instead they get deprecated following a model that has been successful in other open source projects like Symfony. Drupal, as you already probably know, has inherited a lot of code from Symfony. Now we are also inheriting good practices.
Let's be honest, technical decisions should be lead by the technical teams. You and your company should trust your team, or re-think why you hired them at first, right?
Well, it would be great if the world would be that easy. Unfortunately a lot of the time companies have lots of other constraints and problems. It is up to the tech team, the agencies, or the consultancies to provide the best guidance for the people in business, the stakeholders, etc. to make the best decision possible.
Believe the hype. One of the things I personally like most about Drupal 8 -- and something that everyone is quite excited about -- is the API-first initiative.
As Preston and Dries have put it, the web has changed. No, really the web has changed a lot. Not that many years back, Desktop was the thing. Later on, everyone was talking about the mobile revolution... Nowadays we have hundreds of connected devices, and everything is much more complicated.
That means that it's time we stop talking about devices and just think about Content first -- the same way we used to talk about Mobile first. And, guess what, your CMS should be able to adapt to those new changing scenarios.
Companies have hugely demanding and changing requirements. What was acceptable yesterday -- just having a website --is no longer enough. Today we we need to spread the information among very different devices. From the desktop, to mobile and tablets, to watches, to screens in the street -- and don't forget the IoT revolution.
Having a CMS that is able to deliver on that promise basically ensures that we won't have to spend thousands of dollars again in the future, and most important, that we'll be able to deliver in this changing environment as quickly as the requirements and devices change.
And, while you could flex Drupal 7 to adapt to this changing environment (I've worked on projects like that) the real power and flexibility comes with having a Drupal 8 architecture where this flexibility is already in the core. That has implications for performance, adaptability, simpler architecture of services around Drupal, etc.
So, if you think you just need a website, that's completely fine. But if you have the slightest inkling that you may need a mobile app, content that can be reused in who knows what future devices, then you should probably rethink your strategy and think decoupled. And, yes, you guessed my next point: Drupal 8 is the perfect platform for that.
Let's not forget that in general, as everything in life, what fits one project may not fit another one.
In some situations it may still make sense to stay in Drupal 7. For example for small projects where you are launching a site re-using a big percent of custom functionality.
Notice that I wrote custom functionality in bold. That's because it's up to the technical team to show the business what is custom and what is contrib.
You may learn that by moving to Drupal 8 you are saving a lot of money, because actually, what we have in our hands is just a lot of contrib modules and just a couple of customizations, so the effort of building the new site would be the same in both platforms (and hence, the long-term savings exposed in 2nd and 7th points, above, would lean clearly towards Drupal 8).
And, if you are still not sure where the balance stands between both technologies, I'd recommend you build a table like the one I have used in similar decisions, which also helps the conversation with your company or client.
Cloud Platform