What described below is an broad idea, some thoughts on one way the WordPress ecosystem might evolve in response to the new capabilities of Gutenberg. Huge thanks to Kjell Reigstad and David Kennedy for helping me think through these concepts!
Traditionally, themes have been the only authority when it came to the layout and presentation of a WordPress site. They provided the entire page structure, typography, the color scheme, the menu functionality, the responsive rules, and more. Themes generally had the full power to dictate if and how users could customize each of those elements.
With the advent of Gutenberg, we’ve seen some of those responsibilities shift. Regardless of their theme, users can now add responsive column-based layouts to any page, assign custom colors to most of their content, and insert rich elements anywhere within a post or page. As a result, some of the responsibilities for the design of a site are blurred: The theme takes care of some aspects, while Gutenberg handles others. Much of that architecture is still to be defined as Gutenberg moves into Phase 2 and beyond.
Gutenberg brings many opportunities to WordPress, but the biggest impact comes from the way it can enable a much clearer product architecture — one which enables modularity, consistency, and interoperability — and the positive impact that can have on the end user experience of WordPress.
To that end, it can be helpful to think of layout and presentation not as the “Theme”, but as a set of interrelated pieces, each with their own set of responsibilities, working together to create a site.
Blocks
A block is a component that exists visually a page. It can be a “simple block”, like a paragraph or an embed; or it can be a “complex block”, which has a layout of multiple nested blocks, like a testimonials section. This distinction doesn’t necessarily matter to the user as there’s a unified insertion and discovery mechanism. Blocks can contain placeholder content that is neutral — in other words, they start as a “blank slate”, except for placeholder content that guides users as to how to add content to the block.
A block can contain layout information, including media queries that define how the block behaves responsively in different viewports. A block could conceivably define styles that would override the ones provided by the template or the global styles, in order to create a unique presentation for a particular block.
Templates
While Gutenberg makes it easy to create a custom, complex page layout from scratch, the process of starting with a blank slate and designing a layout that looks good will likely still be daunting for many users. Giving users access to a collection of pre-built Gutenberg page templates would enable them to get started more quickly and simply tweak the template to their needs.
A template would define a collection of blocks in a particular order and layout that make up an entire page. In addition, templates can contain “starter content” — editorial boilerplate text and media so that a user can simply tweak and replace rather than having to start from scratch. The concept of a template library would mean that there could be a core library of basic templates, in addition to non-core templates that can be developed by anyone and installed separately (similar to how blocks work).
Styles
Styles would define the global aesthetics of the site, and would provide a central definition for typography, colors, spacing, icons, and more. Brent Jett has suggested some interesting ideas for how this might manifest on the user-facing side. Styles may also provide some global guidelines for layout, such as global settings for responsive behavior, etc. Layout that is specific to a page template or a block should be defined locally by that element, though.
Themes
Given all the new controls over layout that blocks and templates can provide, what does a theme mean in this new world? It seems that themes can become more lightweight. Perhaps a theme is simply a JSON wrapper that defines the components of that theme — identifying the blocks, templates, and styles that make up the theme. Rather than bundling all of the parts of the theme in a tightly coupled piece of software, the theme could simply be a high-level definition that identifies the modular dependencies (styles, templates, blocks) that need to be installed. When a theme is deactivated, a user could even have the option to keep the templates and blocks in their library for future use. This could allow for greater flexibility but also greater standardization, creating a consistent and modular framework for shaping how sites get built in the future.
We all know that themes will evolve, and this is just one early idea. As we move forward together, WordPress will surely benefit from the sharing of ideas and explorations around the future of themes. If you have a vision yourself, please share it! Feel free to use the comments below, your own blog, Twitter (use the tag #gutenideas), or wherever you can get the word out.
ThemeShaper 
2 responses
Great post.
> identifying the blocks, templates, and styles that make up the theme
I think this might be a gray area between themes and plugins. At the moment, themes are not allowed to add or remove any block. Instead, they have to provide full support for all the blocks come with Gutenberg, even if there are many blocks are not used to make the themes.
Themes become something like block styler and block container.
I really like the whole concept especially the global styles “limitation” that themes can bring to the whole experience, which was something that I thought about, I just didn’t know exactly how to implement.
On top of that something that I think is key is the concept of section templates, that can be seen here: https://youtu.be/uLNL1WGnzWo?t=54, while page templates are good and there is the concept of reusable blocks, having a sort of reusable blocks that aren’t always with the same content is something that I saw users enjoy.