This week's Grammy Awards is one of the best examples of the high traffic events websites that Acquia is so well known for. This marks the fourth time we hosted the Grammys' website. We saw close to 5 million unique visitors requesting nearly 20 million pages on the day of the awards and the day after. From television's Emmys to Superbowl advertisers' sites, Acquia has earned its reputation for keeping their Drupal sites humming during the most crushing peaks of traffic.
These "super spikes" aren't always fun. For the developers building these sites to the producers updating each site during the event, nothing compares to the sinking feeling when a site fails when it is needed the most. During the recent Superbowl, one half-time performer lost her website (not on Drupal), giving fans the dreaded 503 Service Unavailable error message. According to CMSWire: "Her website was down well past midnight for those who wanted to try and score tickets for her tour, announced just after her halftime show performance". Yet for Bruno Mars' fans, his Acquia-based Drupal site kept rolling even as millions flooded his site during the half-time performance.
For the Grammys, we can plan ahead and expand their infrastructure prior to the event. This is easy thanks to Acquia Cloud's elastic platform capacity. Our technical account managers and support teams work with the producers at the Grammys to make sure the right infrastructure and configuration is in place. Specifically, we simulate award night traffic as best we can, and use load testing to prepare the infrastructure accordingly. If needed, we add additional server capacity during the event itself. Just prior to the event, Acquia takes a 360 degree look at the site to ensure that all of the stakeholders are aligned, whether internal to Acquia or external at a partner. We have technical staff on site during the event, and remote teams that provide around the clock coverage before and after the event.
Few people know what goes on behind the scenes during these super spikes, but the biggest source of pride is that our work is often invisible; our job well done means that our customer's best day, didn't turn into their worst day.
It is with great sadness that we learned last week that Richard Burford has passed away. This is a tragic loss for his family, for Acquia, the Drupal community, and the broader open source world. Richard was a Sr. Software Engineer at Acquia for three and a half years (I still remember him interviewing with me), and known as psynaptic in the Drupal community. Richard has been a member of the Drupal community for 9+ years. During that time, he contributed hundreds of patches across multiple projects, started a Drupal user group in his area and helped drive the Drupal community in the UK where he lived. Richard was a great person, a dedicated and hard-working colleague, a generous contributor to Drupal, and a friend. Richard was 36 years young with a wife and 3 children. He was the sole income earner for the family so a fundraising campaign has been started to help out his family during these difficult times; please consider contributing.
There has been a lot of discussion around the future of the Drupal front end both on Drupal.org (#2645250, #2645666, #2651660, #2655556) and on my blog posts about the future of decoupled Drupal, why a standard framework in core is a good idea, and the process of evaluating frameworks. These all relate to my concept of "progressive decoupling", in which some portions of the page are handed over to client-side logic after Drupal renders the initial page (not to be confused with "full decoupling").
My blog posts have drawn a variety of reactions. Members of the Drupal community, including Lewis Nyman, Théodore Biadala and Campbell Vertesi, have written blog posts with their opinions, as well as Ed Faulkner of the Ember community. Last but not least, in response to my last blog post, Google changed Angular 2's license from Apache to MIT for better compatibility with Drupal. I read all the posts and comments with great interest and wanted to thank everyone for all the feedback; the open discussion around this is nothing short of amazing. This is exactly what I hoped for: community members from around the world brainstorming about the proposal based on their experience, because only with the combined constructive criticism will we arrive at the best solution possible.
Improving Drupal's user experience is a topic near and dear to my heart. Drupal's user experience challenges led to my invitation to Mark Boulton to redesign Drupal 7, the creation of the Spark initiative to improve the authoring experience for Drupal 8, and continued support for usability-related initiatives. In fact, the impetus behind progressive decoupling and adopting a client-side framework is the need to improve Drupal's user experience.
To date, much of our UX improvements have been based on an iterative process, meaning it converges on a more refined end state by removing problems in the current state. However, we also require disruptive thinking, which is about introducing entirely new ideas, for true innovation to happen. It's essentially removing all constraints and imagining what an ideal result would look like.
I think we need to recognize that while some of the documented usability problems coming out of the Drupal 8 usability study can be addressed by making incremental changes to Drupal's user experience (e.g. our terminology), other well-known usability problems most likely require a more disruptive approach (e.g. our complex mental model). I also believe that we must acknowledge that disruptive improvements are possibly more impactful in keeping Drupal relevant and widening Drupal's adoption.
At this point, to get ahead and lead, I believe we have to do both. We have to iterate and disrupt.
Let's forget about Drupal for a second and observe the world around us. Think of all the web applications you use on a regular basis, and consider the interaction patterns you find in them. In popular applications like Slack, the user can perform any number of operations to edit preferences (such as color scheme) and modify content (such as in-place editing) without incurring a single full page refresh. Many elements of the page can be changed without the user's flow being interrupted. Another example is Trello, in which users can create new lists on the fly and then add cards to them without ever having to wait for a server response.
Contrast this with Drupal's approach, where any complex operation requires the user to have detailed prior knowledge about the system. In our current mental model, everything begins in the administration layer at the most granular level and requires an unmapped process of bottom-up assembly. A user has to make a content type, add fields, create some content, configure a view mode, build a view, and possibly make the view the front page. If each individual step is already this involved, consider how much more difficult it becomes to traverse them in the right order to finally see an end result. While very powerful, the problem is that Drupal's current model is "inside-out". This is why it would be disruptive to move Drupal towards an "outside-in" mental model. In this model, I should be able to start entering content, click anything on the page, seamlessly edit any aspect of its configuration in-place, and see the change take effect immediately.
Drupal 8's in-place editing feature is actually a good start at this; it enables the user to edit what they see without an interrupted workflow, with faster previews and without needing to find what thing it is before they can start editing.
Eight years ago in 2007, I wrote about a database product called DabbleDB. I shared my belief that it was important to move CCK and Views into Drupal's core and learn from DabbleDB's integrated approach. DabbleDB was acquired by Twitter in 2010 but you can still find an eight-year-old demo video on YouTube. While the focus of DabbleDB is different, and the UX is obsolete, there is still a lot we can learn from it today: (1) it shows a more integrated experience between content creation, content modeling, and creating views of content, (2) it takes more of an outside-in approach, (3) it uses a lot less intimidating terminology while offering very powerful capabilities, and (4) it uses a lot of in-place editing. At a minimum, DabbleDB could give us some inspiration for what a better, integrated content modeling experience could look like, with the caveat that the UX should be as effortless as possible to match modern standards.
This sort of vision was not possible in 2007 when CCK was a contributed module for Drupal 6. It still wasn't possible in Drupal 7 when Views existed as a separate contributed module. But now that both CCK and Views are in Drupal 8 core, we can finally start to think about how we can more deeply integrate the two. This kind of integration would be nontrivial but could dramatically simplify Drupal's UX. This should be really exciting because so many people are attracted to Drupal exactly because of features like CCK and Views. Taking an integrated approach like DabbleDB, paired with a seamless and easy-to-use experience like Slack, Trello and Backand, is exactly the kind of disruptive thinking we should do.
We shouldn't limit ourselves to this one example, as there are a multitude of Drupal interfaces that could all benefit from both big and small changes. We all want to improve Drupal's user experience — and we have to. To do so, we have to constantly iterate and disrupt. I hope we can all collaborate on figuring out what that looks like.
On December 29, 2000, I made a code commit that would change my life; it is in this commit that I called my project "Drupal" and added the GPL license to it.
A couple weeks later, on January 15, 2001, exactly 15 years ago from today, I released Drupal 1.0.0 into the world. The early decisions to open-source Drupal and use the GPL license set the cornerstone principles for how our community shares with one another and builds upon each other's achievements to this day.
Drupal is now 15 years old. In internet terms, that is an eternity. In 2001, only 7 percent of the world's population had internet access. The mobile internet had not entered the picture, less than 50% of the people in the United States had a mobile phone, and AT&T had just introduced text messaging. People searched the web with Lycos, Infoseek, AltaVista and Hot Bot. Google -- launched in 1998 as a Stanford University research project -- was still a small, private company just beginning its rise to prominence. Google AdWords, now a $65 billion business, had less than 500 customers when Drupal launched. Chrome, Firefox, and Safari didn't exist yet; most people used Netscape, Opera or Internet Explorer. New ideas for sharing and exchanging content such as "public diaries" and RSS had yet to gain widespread acceptance and Drupal was among the first to support those. Wikipedia was launched on the same day as Drupal and sparked the rise of user-generated content. Facebook and Twitter didn't exist until 4-5 years later. Proprietary software vendors started to feel threatened by open source; most didn't understand how a world-class operating system could coalesce out of part-time hacking by several thousand developers around the world.
Looking back, Drupal has not only survived massive changes in our industry; it has also helped drive them. Over the past decade and a half, I've seen many content management systems emerge and become obsolete: Vignette, Interwoven, PHP-Nuke, and Scoop were all popular at some point in the past but Drupal has outlived them all. A big reason is from the very beginning we have been about constant evolution and reinvention, painful as it is.
Keeping up with the pace of the web is a funny thing. Sometimes you'll look back on choices made years ago and think, "Well, I'm glad that was the right decision!". For example, Drupal introduced "hooks" and "modules" early on, concepts that are commonplace in today's platforms. At some point, you could even find some of my code in WordPress, which Matt Mullenweg started in 2003 with some inspiration from Drupal. Another fortuitous early decision was to focus Drupal on the concept of "nodes" rather than "pages". It wasn't until 10 years later with the rise of mobile that we started to see the web revolve less and less around pages. A node-based approach makes it possible to reuse content in different ways for different devices. In a way, much of the industry is still catching up to that vision. Even though the web is a living, breathing thing, there is a lot of things that we got right.
In the end, I feel fortunate that our community is willing to experiment and break things to stay relevant. Most recently, with the release of Drupal 8, we've made many big changes that will fuel Drupal's continued adoption. I believe we got a lot of things right in Drupal 8 and that we are on the brink of another new and bright era for Drupal.
I've undergone a lot of personal reinvention over the past 15 years too. In the early days, I spent all my time writing code and building Drupal.org. I quickly learned that a successful open source project requires much more than writing code. As Drupal started to grow, I found myself an "accidental leader" and worried about our culture, scaling the project, attracting a strong team of contributors, focusing more and more on Drupal's end-users, growing the commercial ecosystem around Drupal, starting the Drupal Association, and providing vision. Today, I wear a lot of different hats: manager of people and projects, evangelist, fundraiser, sponsor, public speaker, and BDFL. At times, it is difficult and overwhelming, but I would not want it any other way. I want to continue to push Drupal to reach new heights and new goals.
Today we risk losing much of the privacy, serendipity and freedom of the web we know. As the web evolves from a luxury to a basic human right, it's important that we treat it that way. To increase our impact, we have to continue to make Drupal easier to use. I'd love to help build a world where people's privacy is safe and Drupal is more approachable. And as the pace of innovation continues to accelerate, we have to think even more about how to scale the project, remain agile and encourage experimentation. I think about these issues a lot, and am fortunate enough to work with some of the smartest people I know to build the best possible version of the web.
So, here is to another 15 years of evolution, reinvention, and continued growth. No one knows what the web will look like 15 years in the future, but we'll keep doing our best to guide Drupal responsibly.
I am confident that adopting a client-side framework through progressive decoupling will give us the best of both worlds. Of course, this does not mean I oppose fully decoupling through any other framework; in fact, I believe we should redouble our efforts toward a first-class API-first Drupal. But progressive decoupling means that we will be able to work toward a next-generation user experience without abandoning much of the work we've done so far.
Special thanks to all of the following experts who provided review and input: Miško Hevery (creator of Angular; Google) and Igor Minar (technical lead for Angular; Google); Ed Faulkner (core maintainer for Ember); Amitai Burstein (Drupal and Elm contributor; Gizra); Sebastian Siemssen (Drupal contributor, Elm and React developer; Zensations); and John Albin Wilkins (Drupal 8 mobile initiative lead), Alex Bronstein (Drupal core maintainer; Acquia), Wim Leers (Drupal core contributor; Acquia), and Preston So (Drupal contributor, Acquia).
First, have we decided on the right criteria regardless of the frameworks themselves? This is probably the most important at this stage. While many organizations choose to adopt client-side frameworks for fully decoupled implementations, Drupal is the first to consider layering a framework on top to allow both richly dynamic and more traditional modules to coexist gracefully through progressive decoupling. What issues around templates, rendering, and client-side caching should we incorporate into these criteria? Is there anything missing or overemphasized?
Finally, have we drawn the right conclusions against these criteria? In other words, did we fill out the cells correctly? While they have been reviewed by some of the frameworks' experts, there might be unexpected gotchas or caveats.
At the moment, the most promising candidates in the comparison matrix appear to be Angular 2, Ember, and React, given their technical robustness, relative suitability for progressively decoupled Drupal, and their strong levels of community support and broader adoption. Given that Backbone is already in core and several modules already rely on it, we have included it too.
What we've learned from talking to the different projects is that they are often converging on similar techniques and best practices; they are by and large adding support for Virtual DOM implementations or rehydration (seamless state transfer), and they are all obsessing over small payload size and performance, better testability, etc. Therefore it is important to focus on the fundamental, often philosophical, differences between the projects that will likely be unchanged in time; key architectural differences, their release cadence and stance on backward compatibility, their license, their governance model, their flexibility and learning curve, etc.
From a quick glance at the criteria and our needs, it seems that Ember is currently our best candidate, as it appears to have a slight technical edge overall. Ember 2.0 has an all-new rendering engine named Glimmer, and it has server-side rendering through FastBoot. On the other hand, however, Ember is quite bulky and opinionated (enforcing patterns for code structure) compared to other candidate frameworks. A more fundamental difference is that unlike Angular and React, which have corporate governance and funding, Ember is a community-driven project like Drupal.
While React is lightweight, it needs integration with a variety of other libraries in the React ecosystem to work as a full-fledged implementation, which gives it a steep learning curve from an implementation standpoint. Because React is a relatively young project, best practices are shifting quickly and making it less attractive. The Virtual DOM, among React's most compelling features, has also seen its core ideas filter into other framework projects. But more importantly, React is licensed with what I believe to be a potentially unacceptable patent clause, which states that an organization can no longer use React once it sues Facebook for any (unrelated) patent infringement. This has already generated some concerted pushback from both WordPress's Calypso and React contributors.
Whatever the result of the debate around which client-side framework to adopt, I believe that Drupal needs to move quickly to embrace a framework that will aid development of a progressively decoupled architecture and corresponding user experience improvements. By providing some baseline criteria and including our accomplished community, I have no doubt we can reach this decision quickly but also intelligently.
Special thanks to Preston So for contributions to this blog post.
As many of my loyal blog readers know, I sit down to write a retrospective at the end of each year. It's helpful from the perspective of seeing how far Acquia has come in a single year, but it should also give you a glimpse of what is in store for Acquia in 2016 and beyond. If you find it interesting to take a look back at previous retrospectives, here they are: 2014, 2013, 2012, 2011, 2010 and 2009. These posts provide a pretty detailed overview of Acquia's trajectory as a company.
Since Acquia started eight years ago, we've believed that open source offers significant advantages over proprietary software because of its faster innovation, higher quality, freedom from vendor lock-in, greater security, and lower total cost of ownership. Early in our life as a company, we made a big bet that open source combined with the cloud, offered through a subscription model rather than perpetual license, would be a very compelling solution for the market. Few people believed us at the time, but now it is clear that our early vision is starting to pay off; perpetual software licenses are on the decline and Deutsche Bank analyst Karl Keirstead recently called cloud and open source the two leading themes in Silicon Valley.
The market demand for Acquia's digital business platform continues to grow; three of the top analyst firms, IDC, Gartner and Forrester have all named digital business transformation a top strategic imperative for the C-suite in 2016 and beyond. Open source, cloud computing, big data, the Internet of Things (IoT), and artificial intelligence are all catalysts for the expansion of digital transformation into all corners of the organization.
Organizations are rapidly expanding the range of digital interactions with their customers and partners, moving Drupal and Acquia to the core of their business. There is a growing focus on personalization and data-driven automation, which bodes well for products like Acquia Lift. In general, I believe that the growing reliance on digital provides Drupal and Acquia with a multi-decade opportunity.
Within the last 12 months, some of the largest technology companies including Apple, Google, Microsoft and Facebook have open-sourced key components of their business. There are many motivations for this shift. According to Apple, the company open-sourced its Swift programming language to extend it to new platforms. Google open-sourced TensorFlow, its artificial intelligence platform to make an even bigger impact outside Google, even though the company employs 2,000 engineers working on artificial intelligence alone. Microsoft open-sourced .NET to increase its relevance with developers and play nicely with other operating systems. In Deutsche Bank's 2016 predictions, Keirstead says "open source keeps eating the world", causing major price deflation for the traditional enterprise software industry. Whether the motive is faster innovation or increased adoption, companies are relying less and less on proprietary software and embracing open source.
Amazon SVP of Web Services, Andy Jassy, explained in his 2015 AWS re:Invent presentation that websites have been a "critical gateway" to AWS' wider cloud adoption in the enterprise. His rationale: nearly every organization has one or more websites, and many aren't considered "mission-critical applications". Therefore, most organizations feel comfortable moving some or all of their websites to the cloud. Websites are an important stepping stone for organizations to build up the knowledge and confidence to migrate their entire businesses to the cloud.
As cloud adoption grows, we're seeing our customers use a mixture of SaaS, PaaS and IaaS. In particular the Platform-as-a-Service (PaaS) model continues to grow fast, which is great news for Acquia Cloud. A growing number of enterprises are choosing PaaS ahead of Infrastructure-as-a-Service (IaaS) to save time and money on building, scaling and maintaining infrastructure so they can focus on building websites. Gartner sizes the PaaS market at $4.1B in 2015, attaining a compound annual growth rate (CAGR) of 65%+ through 2018. We are a few years ahead of our competitors (Adobe, Sitecore, IBM, Oracle) when it comes to PaaS, and I don't see that changing in 2016.
The migration to the cloud is only getting started. When I met with Eric Schmidt this year, he told me that he believes Google's cloud business could outpace its advertising business in five years. To put that in context, Google made more than $65 billion in advertising in 2015, roughly 90% of its total revenue. I don't think Google Cloud can possibly grow that fast, but directionally it's an eye-opening goal. Amazon's cloud business, bigger than its four closest competitors combined (including Google's cloud business), generated roughly $7 billion in revenues in 2015 and is expected to grow 80% year-over-year. Needless to say, it is exciting for Acquia be a "critical gateway" in such a massive movement to the cloud.
As the web evolves, the idea of a "digital business" takes on an entirely new meaning. I've said this before but digital is not just about building websites anymore; many of our customers are using digital to change the way their business operates, automate manual processes, and save millions of dollars in the process. Digital strategies are no longer confined to the marketing department; they're quickly becoming a boardroom priority.
Digital experiences are also getting more sophisticated. What used to be as simple as building a website now involves getting the right information, to the right user, at the right time, in the right context -- an idea I call B2One and talked about as part of my Big Reverse of the Web thesis. It's all about understanding the user's context and preferences to deliver the best next experience. We started investing in this area in late 2013, acquired a personalization company in 2014, and expect this trend to grow really big, especially as big data, the Internet of Things (IoT) and artificial intelligence mature.
Beyond personalization and contextualization, companies have a greater need for flexibility and freedom to integrate a variety of external services, ranging from commerce to marketing automation solutions. While there are plenty of point solutions on the market that achieve pieces of this puzzle, Acquia and Drupal uniquely provide a platform to do it all.
Acquia's growth is an indicator that businesses are already betting big on open source, cloud, personalization, and digital transformation. Looking at our numbers for 2015, it is hard to believe that last year was only our seventh full year as a revenue-generating business. Our new logo subscriptions -- the business that we get from companies new to Acquia -- continued its fast growth, while our renewal rates are among the best around.
To support our growth, we added $55 million in new venture capital funding in 2015, bringing Acquia's total raised to $188.6 million.
We dramatically increased headcount last year. In May, we moved into a beautiful new corporate headquarters in Boston, where we hosted a launch party with mayor Martin J. Walsh that established us as an anchor growth company for the city. Globally, we added 150 more employees in 2015, bringing us to 720 people. The executive team changed substantially in 2015, with the addition of Al Nugent as CISO, Preston Bradford as COO, Heather Hartford as Chief People Officer, and most recently Loren Jarrett as CMO. We also announced the appointment of Christine Komola, CFO of Staples, to Acquia's board of directors. We expanded European operations with the opening of a new office in Munich. Acquia now operates out of 10 global offices on three continents!
We made key investments in talent for our partner team, grew the number of Drupal certifications achieved globally, and strengthened our relationship with agency partners. We were proud to announce our WPP Global Alliance partnership this year, which brings Acquia closer to the organizations building the world's most amazing digital experiences.
Top industry analysts continued to recognize Acquia as a leading provider of digital experience software and services. In October 2015, we were named a "Strong Performer" in The Forrester Wave: Digital Experience Platforms Q4 2015. In August, Gartner named us a "Leader" in the 2015 Magic Quadrant for Web Content Management. This type of external validation supports Acquia as a viable alternative to proprietary solutions provided by companies like Adobe, IBM, Sitecore or Oracle.
Acquia Cloud continues to enable organizations to run their websites securely and reliably, while providing them with the tools to accelerate web development and shorten time to market. We manage over 13,000 AWS instances (virtual servers) powering approximately 197,000 websites. In December 2015, Acquia Cloud served 10.8 billion Apache hits and 6.2 billion Drupal bootstraps (requests handled by Drupal instead of one of different caching layers or the web server directly), with billions more served from our caching layers and Acquia Cloud Edge.
Last year, we launched Acquia Cloud support for the São Paulo, Brazil and Frankfurt, Germany regions. With our German expansion we became the first Drupal PaaS to offer pan-European high availability to accommodate EU data sovereignty requirements.
With the launch of Drupal 8 in late 2015, the Drupal community achieved our most significant release in the history of the platform. We implemented a more modern development framework, reimagined the usability and authoring experience, and made improvements that will help everyone build the multilingual, mobile and highly personalized digital experiences of the future. From how we model content and get content in and out the system, to how we assemble experiences on various devices, to how we scale that to millions of pageviews — it all got much better with Drupal 8.
Now that Drupal 8 is released, I'm convinced that it will attract new developers and site-builders to the platform. Nonetheless, the wait for Drupal 8 has been long and painful, temporarily slowing down much of the commercial Drupal ecosystem. Despite some turbulence, I'm proud that the Acquia team was a force in helping to push Drupal 8 over the finish line.
Acquia employs more than 150 Drupal experts, and has fixed upwards of 1,200 issues in Drupal 8. I reassigned our Drupal team from feature development (i.e. Spark) to working on criticals. This team was a major force in bringing the total number of criticals down from a high of 90 at the beginning of the year to zero in early October, through development, performance work, patch reviews, sprint coordination, and in helping to manage the Drupal 8 Accelerate program. To help jumpstart faster Drupal 8 adoption, Acquia is investing significantly in porting the top 50+ contributed modules. We have always believed in giving back more as a core part of our company's DNA. Our entire team is ready to enable and support companies working with Drupal 8.
Last year was an exciting one when it came to new products. We announced Content Hub, a cloud-based content distribution and discovery service. As more of our customers scale with Acquia across hundreds of sites, Content Hub lets authors and site owners reuse content from internal and external sites. And we added a critical commerce integration through a partnership with Hybris, which provides even more options for enterprises to drive commerce experiences.
We announced a variety of important security and compliance milestones that will be crucial to protecting our customers. First, we introduced Acquia Cloud Edge, a new DDoS security product developed in partnership with CloudFlare to keep our customers safer from external threats. Soon after, Acquia achieved HIPAA compliance upon passing an independent audit of Acquia Cloud Site Factory and Acquia Cloud. HIPAA compliance is significant because of Acquia's roster of healthcare customers, who require certain safeguards for data security and look to scale Acquia Cloud across their portfolio of sites.
In addition to this compliance milestone, our spam-blocking software, Mollom, has blocked over 10 billion spam comments.
Acquia Lift customers challenged some of our original assumptions about personalization. We worked to improve our Acquia Lift personalization product with the help of our customers, creating a new workflow and UX that supported more flexibility and freedom depending on the individual organization. In 2015, we learned a lot about the challenges organizations face when starting out with personalization and doubled down to help our customers become successful. Personalization will continue to be a huge focus of ours in 2016.
This year, we will be rolling out many new products and enhancing existing ones. Acquia Cloud will get a brand-new, responsive, card-based UX in early 2016, and we'll give development teams the ability to create on-demand environments. We will continue to focus on security enhancements from audits like SOC and ISO, as well as key control planes including FedRAMP, Single Sign-On, and much more. Our team was challenged to get the first cloud service running on our new grid architecture by the end of 2015. With a few hours to spare on the 31st, the "Uptime" service is now running on our grid architecture, a major milestone. A continued focus on developer tools, more microservices, personalization and a "jumpstart" Drupal 8 distribution are just some of the technology we will be rolling out in 2016. Overall, you'll see us getting faster, more secure and more efficient, and providing even more options for our customers to create highly personalized digital experiences.
Longer term, I'm very excited about Acquia's opportunity. I believe we've steered the company to be positioned at the right place at the right time. Time will tell, but 2016 promises to be another big year for Acquia.
File this under "better late than never". Before the year closes out, I wanted to post my 2015 DrupalCon Barcelona keynote video and slides. I archive all my DrupalCon keynotes on my site so anyone who is interested in taking a trip to memory lane or studying the evolution of Drupal, can check out all my previous DrupalCon keynotes.
My DrupalCon Barcelona keynote is focused on having a realistic, open and honest conversation about the state of Drupal. In it, I broke down my thoughts on Drupal's market position, development process, and "decoupled Drupal". You can watch the recording of my keynote or download a copy of my slides (PDF, 27 MB).
As user experiences evolve from static pages to application-like experiences, end users' expectations of websites have become increasingly demanding. The Facebook newsfeed, the Gmail inbox, and the Twitter live stream are all compelling examples that form a baseline for the application-like experiences users now take for granted.
Many of Drupal's administrative interfaces and Drupal sites could benefit from a similarly seamless, instantaneous user experience. Drupal's user interfaces for content modeling (Field UI), layout management (Panels), and block management would benefit from no page refreshes, instant previews, and interface previews. These traits could also enrich the experience of site visitors; Drupal's commenting functionality could similarly gain from these characteristics and resemble an experience more like the commenting experience found in Facebook.
As Drupal's project lead, I ask myself: how can our community feel enabled and encouraged to start building rich user experiences?
In recent years, the emergence of decoupled architectures with client-side frameworks and libraries have helped our industry build these experiences. Does that mean we have to decouple Drupal's front-facing site experience (for site visitors or end users) and/or the administration experience (for content editors and site builders)? If so, should Drupal decouple the administration layer differently from the front-facing site experience? By extension, should a client-side framework guide this change?
Here is my current thinking: in the short term, Drupal should work toward a next-generation user experience under progressive decoupling for both the administration layer and the end user experience. At the same time, we should enable fully decoupled end-user and administrative experiences to be built on Drupal too. In my view, the best way to achieve this is to formally standardize on a full-featured MV* framework (e.g. Angular, Ember, Backbone, and Knockout) or a component-based view library (e.g. React, Vue, and Riot). In this blog post, I want to kick off the discussion and walk you through my current position in some more detail.
There is no doubt that Drupal's administration layer is very application-like and would benefit from an experience that is more interactive. For the end-user experience, a decoupled implementation is not always the best option. Some sites may not need or want the application-like interactivity that a client-side framework would provide, since not every site needs interaction. For instance, news sites or blogs do not need much interactivity, custom applications need a great deal, while e-commerce sites lie somewhere in the middle. It's not clear-cut, so let's look at our options in more detail.
|Approach||User experience||Developer experience||Ease of implementation|
No immediate feedback
Theme layer preserved
Modules in mostly PHP
Ad-hoc client-side code
No server-side change
No client-side change
No page refreshes
Theme layer preserved
Unified client-side code
Some server-side change
Some client-side change
No page refreshes
Theme layer replaced
Unified client-side code
Much server-side change
Much client-side change
Drupal's administration layer (content editor and site builder experience) is effectively an application. Fully decoupling may be the appropriate call to achieve the best possible user experience for creating, managing and presenting content. However, rewriting the administration layer from the ground up is a monumental task, especially since its modules provide powerful interfaces that allow site builders to build robust, complex sites without a line of code.
The same expectations for application-like interactivity often hold for the end-user experience: users expect shopping carts, comments, notifications, and searches to be updated instantaneously, without having to wait for a page to load.
For both the administration layer and the end-user experience, I believe the Drupal front end should not be fully decoupled out of the box. We should advance from our traditional paradigm and default to progressive decoupling. It allows us to achieve the user experience we want without significant downsides, since not every use case would benefit from fully decoupling. Through progressive decoupling, Drupal could potentially reach the ideals of the assembled web more quickly by preserving a tight link between Drupal modules and their front-end components.
Nonetheless, we should empower people building fully decoupled sites and applications. Depending on the use case, Drupal 8 is a good match for decoupled applications but we should improve and extend Drupal's REST API, enhance contributed modules such as Services, and shore up new features such as GraphQL (demo video) so more functionality can be decoupled. Front-end developers can then use any framework of their choice — whether it is Angular, Ember, React, or something else — to build a fully decoupled administrative application.
All things considered, I do believe Drupal should standardize on a single client-side framework, but it should only make such an explicit recommendation for progressively decoupled Drupal, not fully decoupled architectures. It would result in a more seamless user experience, better compatibility across interactive components in modules, maximum code reuse, a more consistent front-end developer experience, more maintainable code, and better performance as we don't have to load multiple frameworks.
Despite the potential benefits, there are also good reasons not to embrace a single client-side framework. New front-end frameworks are being created at what feels like an unsustainable pace; every nine months there is a new kid on the block. It's hard for a project as large as Drupal to embrace a single technology when there is no guarantee of its longevity.
For instance, Backbone, with its underlying library Underscore, currently powers interactions in the toolbar and in-place editing in Drupal 8. Though Drupal could expand the scope of Backbone in core and encourage front-end developers to build with it, it means buying even further into a framework that is quite old among its peers.
To deal with the fast-evolving nature of the front-end landscape, we need to be thoughtful about which framework we choose, to reassess our choice from time to time, and to make sure we can migrate fairly easily if we so decide.
Assuming we agree that embracing a single client-side framework makes sense for Drupal, there are actually three additional questions: what framework to standardize on, how to do it, and when to decide.
I'm the first to admit I'm not the best person to answer the first question. As I'm not a front-end developer, I'm looking at you, the Drupal community, to help answer this question. I'd hope that the chosen framework aligns well with both our architecture (modular, flexible) and community (collaborative, community-driven).
The second question — how to standardize on a framework — I can help answer. On the one extreme, Drupal could be opinionated and ship a client-side framework with Drupal core, meaning that every installation of Drupal ships with the chosen framework. This would be much like the adoptions of jQuery and Backbone.js. On the other end of the spectrum, Drupal could recommend a specific framework but not ship with it. Finally, somewhere in between, Drupal could provide a default standard framework in core but make it easy to replace with it a framework of a developer's choice, though the likelihood of this is quite small. This is akin to Drupal core shipping with a template engine (i.e. PHPTemplate) that could be (but was rarely) replaced with another. Ultimately, I think we get the best result if Drupal ships with a specific framework—much like the adoption of jQuery in Drupal 5.
The last question, when to standardize on a framework, is important too. I would recommend we experiment with possible directions as soon as possible in order to decide on a final vision sooner rather than later.
I believe that, for now, it makes more sense to progressively decouple Drupal sites and their administration layer by first building our pages with Drupal. Once the page is loaded, we can let a unified client-side framework take over as much of the page as needed to foster a next-generation user experience without reinventing the wheel or alienating developers.
That is not all! We will need module developers to bring rich interactions to their user interfaces with the help of the framework we choose. We will need designers to guide module developers in building a graceful user interface. We will need front-end developers to demonstrate how they want to develop the user experiences that will define Drupal for years to come. We will need users to test and validate all of our work. It will be tough going, but together, we can ensure Drupal stays ahead of the curve well into the future.
One thing that is exciting to me, is how much we appear to have gotten right in Drupal 8. The other day, for example, I stumbled upon a recent article from the LinkedIn engineering team describing how they completely changed how their homepage is built. Their primary engineering objective was to deliver the fastest page load time possible, and one of the crucial ingredients to achieve that was Facebook's BigPipe.
When a very high-profile, very high-traffic, highly personalized site like LinkedIn uses the same technique as Drupal 8, that solidifies my belief in Drupal 8.
LinkedIn supports both server-side and client-side rendering. While Drupal 8 does server-side rendering, we're still missing explicit support for client-side rendering. The advantage of client-side rendering versus server-side rendering is debatable. I've touched upon it in my blog post on progressive decoupling, but I'll address the topic of client-side rendering in a future blog post.
However, there is also something LinkedIn could learn from Drupal! Every component of a LinkedIn page that should be delivered via BigPipe needs to write BigPipe-specific code which is prone to errors and requires all engineers to be familiar with BigPipe. Drupal 8 on the other hand has a level of abstraction that allows BigPipe to work without the need for BigPipe-specific code. Thanks to Drupal's higher-level API, Drupal module developers don't have to understand BigPipe: Drupal 8 knows what page components are poorly cacheable or not cacheable at all, and what page components are renderable in isolation, and uses that information to automatically optimize the delivery of page components using BigPipe.
It is exciting to see Drupal support the advanced techniques that were previously only within reach of the top 50 most visited sites of the world! Drupal's BigPipe support will benefit websites small and large.
Building Drupal 8 with all of you has been a wild ride. I thought it would be fun to take a little end-of-week look back at some of our community's biggest milestones through Twitter. If you can think of others important Tweets, please share them in the comments, and I'll update the post.
— Cheppers (@cheppers) November 19, 2015
The secretsauce of #drupal isn't code or features or market share, important thought they are. The secret sauce is community.
— Sean Yo (@seanyo) March 10, 2011
— Jeff Geerling (@geerlingguy) March 10, 2011
Drupal 8.0.0 beta 1 released! https://t.co/FwdmRYaZUx Ahh the power of COMMUNITY driven software! :-)
— Doug Vann (@dougvann) October 1, 2014
— Gábor Hojtsy (@gaborhojtsy) October 1, 2014
— xjm (@xjmdrupal) September 19, 2014
Drupal 8.0.x-rc1 release window is today. Good sign of real stability is major issue count going down for 6+ weeks. pic.twitter.com/5VnHGmL9zb
— catch (@catch56) October 7, 2015
— xjm (@xjmdrupal) July 5, 2015
Working on D8 Criticals at the Ghent DA critical sprint, this is how the "My issues" page looks for me right now! pic.twitter.com/y5SnavVtND
— Sascha Grossenbacher (@berdir) December 13, 2014
— Cameron Eagans (@cweagans) March 23, 2012
— Wim Leers (@wimleers) April 8, 2015
And.... there we go! http://t.co/ed6XtMIs MOTHER BLEEPING VIEWS IN MOTHER BLEEPING CORE!
— webchick (@webchick) October 22, 2012
— Alex Pott (@alexpott) February 15, 2014
With Content + Config Translation in core D8 core is more translatable than D7 with all of contrib. #drupal
— Tobias Stöckler (@tstoeckler) November 18, 2013
Amazing to see Drupal 8's multilingual capabilities explained on the multilingual release page (for example Farsi): pic.twitter.com/9owVE3xABo
— Gábor Hojtsy (@gaborhojtsy) November 19, 2015
— Rasmus Lerdorf (@rasmus) April 21, 2015
— Whitney Hess (@whitneyhess) October 7, 2015
— Manuel Garcia (@drupalero) October 7, 2015
Kudos to the 3000+ contributors and to the entire Drupal community that helped make this happen. https://t.co/FtATRtSmCU
— Leslie Glynn (@leslieglynn) October 7, 2015
— Drupal (@drupal) November 10, 2015
— Drupal (@drupal) November 19, 2015
— Taco Potze˙ (@tacopotze) November 19, 2015
— Duo (@DuoConsulting) November 19, 2015
— Shakeel Tariq (@shakeeltariq) November 19, 2015
— Agustin Rojas Silva (@Aguztinrs) November 19, 2015
— HornCologne (@HornCologne) November 19, 2015
— webchick (@webchick) November 19, 2015
— Paul Johnson (@pdjohnson) November 19, 2015
— Dries Buytaert (@Dries) November 18, 2015
— Peter Decuyper (@sgrame) November 23, 2015
Updates from Dries straight to your mailbox