fidzu : wordpress

Over the past two weeks, Matt Mullenweg and Jamstack community leaders have forged a new rivalry, after Mullenweg told The New Stack that he sees Jamstack as "a regression for the vast majority of the people adopting it."

"The usability and functionality is actually lower," Mullenweg said to Richard MacManus in an email. "Even rebuilding sites in Jamstack harkens back to the Movable Type days, where the bigger your site gets the slower it is to rebuild or update templates."

Mullenweg also described a "fragile" chain of services required to run Jamstack sites.

"You can patch together a dozen services, each with its own account and billing, for hundreds of dollars a month, to get a similar result you'd have for a few dollars a month using WordPress on shared hosting," he said. "And it would be more fragile, because the chain is only as strong as its weakest link. You are chaining together different toolsets, logins, billing, hosting… any part of it going down can break the entire flow."

Mullenweg has since further clarified his comments while also doubling down on his original premise, saying that "there isn't a vast number of people adopting Jamstack in the first place, and those who do are probably fully aware of the tradeoffs." He outlined how he sees WordPress providing a better experience for users in terms of performance, security, scaling, and developer experience.

Mullenweg's provocative remarks set off a chain of open letters from the CEO's of Jamstack-related services. They are convinced that the LAMP stack is on its way out and that Jamstack is on the precipice of replacing its incumbent as the most dominant architecture of the web.

Ohad Eder-Pressman, co-founder and CEO of Stackbit, was the first to fire back. He believes that Jamstack is a "disruptive innovation" that may appear to be inferior now because it is still relatively low level and new when compared to a 17-year old product like WordPress.

"We should be asking whether Jamstack is a better architecture than LAMP and what gaps currently exist with products and solutions built on top of the Jamstack," Eder-Pressman said. He agreed that Jamstack tools are still largely focused on developers but makes a bold prediction on the stack's future reach:

The achievements of WordPress in terms of market share and how it democratized early web publishing are amazing. When it comes to architecture I think it was best in class for the early 2000s but it's time to move forward. We already see cohorts of websites where Jamstack adoption crosses 20% - it's no longer a question of if the Jamstack becomes the predominant architecture for the web but a question of when. The cliche is a cliche but it also rings true - First, they ignore you, then they laugh at you (we are here), then you win.

Eder-Pressman agreed with Mullenweg regarding Jamstack's lower usability and functionality but touted the architecture as "infinitely more resilient" due to being hosted on a CDN. He admitted that rebuilding larger sites can be slow but cited developments like build parallelization, build cache, partial rebuild, and incremental static regeneration as optimizations as efforts the Jamstack ecosystem is exploring to solve this known issue.

Netlify CEO Mathias Biilmann, who originally coined the term "Jamstack," goes so far as to hail "the end of the WordPress era" in his article refuting Mullenweg's remarks.

"There's often a moment right around the time when an old technology is about to be displaced by the next thing, where the main leader in the field goes out and makes a strong argument that absolutely nothing is happening," Biilmann said. "A moment that ends up looking like a turning point where the new was undeniably present enough to be worth being in denial about."

The Bet: By September 2025, what will be the predominant architecture for the web?

In a brief exchange on Twitter, Mullenweg and Eder-Pressman made a wager for five years into the future, to see if Eder-Pressman's prediction will hold up, as measured by the Alexa top 10k. In order for Jamstack to become the predominant architecture for the web, it will need to surpass WordPress' numbers, which are currently hovering at 39.75% (via BuiltWith) and 38.4% (via w3techs).

"I'm happy to make a long bet: 1 year, 5 years, 10 years," Mullenweg said in another thread in response to Netlify's CEO. "We're building and rebuilding WordPress to be generational. We've navigated and created bigger architectural shifts in the past, and will do so in the future."

"I'm a developer, founder, and investor in the space of web technologies - if I'm not willing to engage in a public discussion and share my predictions for where the web is heading then what merit does my work have?" Eder-Pressman said when I asked him why he was willing to make this public wager.

"I felt compelled given Mullenweg's comments and what I believe is the lack of appreciation for how much adoption and momentum Jamstack technologies already have. If anything I would say that my bet is actually pretty cautious."

Eder-Pressman and his team at Stackbit are working on a tool to track Jamstack adoption across the web, as BuiltWith does not yet have a Jamstack stat panel that correctly aggregates all the technologies associated with this relatively new category of websites.

"We've built an internal tool that tracks adoption of Jamstack technologies across different cohorts of websites which we find informative," he said. "This isn't unlike what say Builtwith provides except that we track a few technologies that they don't and we bundle this into a Jamstack adoption indicator. We've used this internally up until now and are planning to release some public facing version of it later this year."

As the CEO of Stackbit, a service that cranks out Jamstack sites in 60 seconds while bypassing any requirement to use the command line or download npm packages, Eder-Pressman is actively engaged in trying to bring this technology stack to the masses. The company aims to solve the very problems that Mullenweg identified in his critical comments, as is evident in the marketing copy on the Stackbit website. It acknowledges that piecing together a Jamstack website can be challenging even for developers:

"In a fragmented Jamstack environment, developers struggle to glue products together when trying out the latest tech. Stackbit connects the best tools on the market, and helps them play together."

A year ago, Stackbit caught my attention and I contacted them to find out when WordPress would land among their list of CMS import options. At that time they said they were considering WordPress as a headless CMS option but did not have it on the immediate roadmap. One year later, Stackbit is no closer to building import capabilities for the most popular CMS on the web.

"It's on the horizon but its not something we've prioritized," Eder-Pressman said. "WordPress is a full blown monolithic CMS. It has been used before as a headless CMS but there are better headless CMS choices out there. Even Mullenweg agrees it's a complicated premise."

When asked if his recent conversations have changed the company's plans to support WordPress imports, he said, "No, it doesn't make us want to do this any more or less. I really enjoyed the conversation and am glad that Mullenweg recognizes the rise of the Jamstack so much so that he found it necessary to take aim at it. We as a company are driven by the market, user demand, growth opportunities and a healthy vision for the future of the web."

Jamstack will need to make itself accessible to the wide world of non-technical website owners if its advocates hope to capture any meaningful segment of the Alexa top 10k marketshare. Stackbit, for one, is still grossly underestimating WordPress' ability to sustain its phenomenal growth, and doesn't see the necessity for creating a simple path to convert WordPress users. Eder-Pressman believes that making Jamstack accessible starts with developers.

"The Jamstack is an architecture which is winning the minds of developers around the world and across the web development stack," he said. "Adoption for new architectures often begins with developers so I'm excited to see a company like say Netlify boast over 1 million developers on its Jamstack platform."

Eder-Pressman's tool for measuring Jamstack adoption will need to produce some compelling data on the stack's growth, if his bet is going to materialize. While nearly every offering in the Jamstack ecosystem still falls squarely within the realm of experienced developers, it doesn't seem likely that five years is enough time for it to overtake WordPress as the predominant architecture for the web. WordPress hasn't achieved its dominance by prioritizing developer happiness over usability.

Looking at the numbers five years from now, will we see Jamstack overtake WordPress as the most popular way to build a website? Will Jamstack grow with developer usage and then plateau once it fails to reach regular people who don't have a git-based workflow at the top of their wishlists? Are we going to find Jamstack and WordPress neck and neck in the battle for the predominant architecture for the web? Those who work with a hybrid of both technologies see no need for this kind of rivalry.

Shifting the conversation towards collaboration: "Jamstack can be an opportunity for our industry, rather than a threat."

"Reading Mullenweg's comments and the responses from CEOs in the Jamstack community make me feel caught in the middle and a bit frustrated," Shifter COO Daniel Olson said. "I see friction between two communities that have so much in common."

Olson has been a proponent of using Jamstack with WordPress for the past four years since launching Shifter, a static site generator and hosting company that supports headless WordPress sites on the Jamstack.

"If you look for the most secure, cost-effective way to build and host a high-traffic website today, the cross-section you'll arrive at is the Jamstack. Looking at how it offers each of those benefits, you will find inspiration and ways WordPress could do the same," Olson said. "Rather than write something off wholesale, see what you can learn and apply it."

Olson said his mission is to bridge the gaps between WordPress and the benefits Jamstack offers, while working through its early days and messy parts, innovating on the tools that work.

"We should be working together to address specific challenges and worry less about how we get there," Olson said. "Some technologies are indeed a better fit for solving each of those challenges but you don't need to leave one ecosystem for the other to do it. You can share knowledge and best practices and discover what's possible. There's a good chance you'll end up creating something new, which is part of that innovation we need in our communities."

Jamstack hosting services for WordPress are eager to remind users that they don't have to go all in on the technology. You can have your JAM and spread it on top of WordPress, accommodating developers' love for experimenting with new frontend technologies, while preserving the dynamic publishing power that has been refined over the past 17 years. These hybrid hosting companies aim to enable this without leaving users behind.

"Matt is absolutely right that the usability and functionality of the Jamstack is lower," Strattic co-founder and CEO Miriam Schwab said. "The Jamstack is a great example of technology that is incredibly appealing to developers, but the actual end users - writers, marketers, business owners - cannot use it. I've heard many stories of major companies that have come to the decision to adopt Jamstack for all web development as a company-wide policy, only to find that their marketing team has gone rogue and is installing WordPress sites in order to get their job done.

"The reason for this is like Matt said: every Jamstack site is a compilation of layers of services, and each layer has dozens of options available: you need a static site generator, a CMS, static hosting, and a CDN - and you need to tie it all together with version control. This is all cool and shiny, and the output is truly fantastic because when you have a site that's a collection of pre-rendered static files served up through a CDN it's fast, secure, scalable and stable. But then along comes marketing and they want to set up a landing page and they are totally dependent on their dev team and can't move forward without them. That defeats the purpose of a CMS-driven website! With WP, you get all the layers in one platform…but you don't get the awesome output."

Schwab said she sees WordPress having its age work both for it and against it, but ultimately she believes in enabling real world users to manage their own websites without having to rely on developers.

"I've seen many companies abandon WP for the shiny new stack, and then come back to it," Schwab said. "Github is a good example of this - yes Github, the modern repository of cutting-edge code moved their blog off of WordPress, and then came back because it truly is the best tool for just getting your content out there. There aren't a zillion steps and integrations - you write content, click Publish, and that's it. It gets the job done, and the fanciest tools will never beat something that just gets the job done."

At the same time, WordPress needs to be open to enabling diverse frontend implementations, if it wants to remain relevant for the next decade. "WP is running on legacy architecture," Schwab said. "It's showing its age, and it's not appealing to new generations of developers. We need to keep WordPress appealing and interesting to developers in order to secure its future for years to come. If we don't make developers excited, we will inevitably see a decline." She encourages the WordPress community to embrace Jamstack as "a breath of fresh air."

"Jamstack can be an opportunity for our industry, rather than a threat," Schwab said. "There are ways for the two industries to collaborate, like in the case of headless WP deployments using Gatsby."

Unlike many other Jamstack service companies, the team behind Gatsby has more readily embraced WordPress as a data source and a critical component of its continued success. The company hired Jason Bahl, creator of the GraphQL for WordPress project, to work on WPGraphQL (and its immediate ecosystem) full-time, while providing a bridge to the WordPress world.

"Maybe I'm getting caught up in semantics, but the JAM in JAMStack means JavaScript, APIs and Markup," Bahl said. "It wasn't long ago when Matt prescribed the WordPress ecosystem to 'Learn JavaScript Deeply,' and not long after that when a Jamstack application called Gutenberg was merged into WordPress core, along with React. Gutenberg is the JavaScript, the WP REST API is the API and the end result is markup. Jamstack isn't a regression, it's a future that Automattic is helping drive WordPress toward."

When Mullenweg says he is ready to build and rebuild WordPress to be generational, it's a promise he has already delivered on by introducing the React-based Gutenberg editor two years ago, successfully pushing past an enormous amount of resistance from the developer community.

Bahl said he sees this continued legacy of improvement happening over and over again in various ways, made possible by WordPress' pluggable system:

WordPress ships with a lot of APIs, but often they are replaced with something newer and better. For example, it's common for sites to offload images to a CDN instead of use the built-in file system for media. Or instead of using built-in WordPress MySQL search, users will reach for ElasticSearch, Algolia or Solr. In the case of WordPress and the JAMStack, reaching for Next, Gatsby or Gridsome to replace the built-in Theme API isn't a regression, it's using newer technology to handle things that built-in parts of WordPress might not do as well. The Theme API of WordPress is just one API and replacing it with technology that does the job better isn't a regression.

Gatsby's build step, which has received negative attention in the news recently, is one example of what Bahl thinks Mullenweg was referring to as a regression for users. Bahl is working with Gatsby to reduce the friction associated with decoupled architectures when using WordPress as the API in Jamstack.

"I don't see Jamstack competing against WordPress," Bahl said. "In my mind, Jamstack with WordPress as the API is the future of the web. WordPress is the best CMS. Gatsby specifically is trying to embrace this. This isn't a zero sum game. If the Gatsby + WordPress experience can allow users to use the best CMS in the world while using modern dev tooling, it's a win all around."

19 Sep 2020 6:54pm GMT

Two weeks ago, Matt Mullenweg made some pointed remarks in an article from The New Stack, calling Jamstack "a regression for the vast majority of the people adopting it." In preparation for an upcoming article that will include comments from leaders across both the WordPress and Jamstack communities, I asked Mullenweg if he stands by his remarks characterizing Jamstack as a regression. His response was lengthy and is printed here in its entirety to preserve cohesion.

Q: Do you stand by your remarks that Jamstack is a regression for the vast majority of the people adopting it?

Answer:

"Vast majority of people adopting it" was probably too harsh, because there isn't a vast number of people adopting Jamstack in the first place, and those who do are probably fully aware of the tradeoffs. There are some good reasons, for certain situations, to decouple and add complexity to your architecture, and WordPress' REST API works fantastically as a backend there. But I worry they are over-selling the promise of what's really an architectural decision. If you look at the benefits they purport, it's better performance, security, scaling, and developer experience:

Better Performance: You can achieve the same performance by putting a great CDN like Cloudflare on top of WordPress, and your life will be infinitely easier when you want to add dynamic features like a store or comments. You can also easily find a static WordPress host like Strattic or Shifter.

Higher security: I don't believe that introducing a number of proprietary and sub-scale SaaS services like Netlify into your stack will make your site more secure. I believe the most secure thing you can do is run fully open source code, as widely vetted and used as possible, on servers you control, or from the fewest number of vendors possible. WordPress securely runs some of the most attacked websites on the internet, including major media, Facebook, and WhiteHouse.gov. Having this many moving parts doesn't inspire confidence:

Cheaper, easier scaling: CDNs are more expensive than normal hosting accounts, and you can get WordPress running on a decent host for less than $5/mo. And there are even more powerful offerings: The personal plan on WP.com can serve tens of millions of visitors per day, to the website or the headless API, includes a global CDN, and a domain name for $4/mo, and we still have a profit margin. GraphCMS starts at $29/mo and only gives you "5,000 entities," whatever that means. Contentstack is $3,500/mo. And that's just for the headless CMS part! You still need to sign up and pay for a bunch of the other stuff in that graphic before you have a website a human can visit in a browser.

Better developer experience: If your developer wants to copy and paste updates from marketing to the website, sure, but if they want people to be able to update the website without their help, they should go with something easier for users like WordPress. If you're curious about the developer experience, or an investor thinking about this space, I really suggest you watch this three hour and thirty minute tutorial to really understand what is being sold under the premise of "better":

Have I ever built stuff like that? Totally! It can be a ton of fun, like building a rocket at home or fixing up an old car. I've seen some awesome sites built on decoupled architectures or static publishing, using headless WordPress rather than the CMS's above, but still a similar idea. People are trying to paint me as being against Jamstack, but that is as foreign to me as being against duct tape - it's good for some things, bad for others, and it's not going away. I just wish they would be more intellectually rigorous and honest when marketing it. I expect a Jamstack-like approach to exist forever, just like the ideas behind Jamstack pre-date it getting jammed down our throats by Netlify's marketing team.

Biilmann has got the Ballmer / iPhone story backwards - Microsoft's mistake there was they made something too complicated, and the iPhone simplified it. Jamstack introduces numerous vendors, build steps, network calls, interfaces, even billing relationships for something that's a single button press in WordPress.

The reason services like WordPress.com and Shopify are growing so much is they are taking things that were complicated and making them simpler and accessible to a much wider audience. My mission is to democratize publishing and commerce, to make it radically accessible to everyone regardless of technical or economic ability, and increase the freedom and openness on the internet. As I said on Twitter, the first 15 years of WordPress were just the first few chapters. I'm looking forward to building and rebuilding the platform the rest of my lifetime, and when that comes to an end I hope future generations will carry the torch.

18 Sep 2020 10:49pm GMT

Adjusting padding on a Group block.

When Gutenberg 9.0 landed earlier this week, it came with an experimental padding control for the Group block. Most users will not see it unless their theme has opted into supporting the feature using the experimental-custom-spacing flag.

This was not the first that we have seen of the padding option on a block. Gutenberg 8.3 introduced it for the Cover block. Since then, nothing has changed with the implementation.

The problem with the custom spacing/padding option is that it creates an inline style that does not adjust based on the design of the theme. Fortunately, the feature is still experimental. This means that we have time to reevaluate how it works.

Unless we're doing away with any remaining illusion that themes will play an important aspect of WordPress's future and front-end design becomes fully entrenched within core, theme authors need some level of control. And, even if themes are going the way of the dinosaur, custom padding numbers on the block level will create design consistency issues down the road. Using 100 pixels of padding might make sense within a site's current design, but 96 pixels might make sense within a future design. When a user adds dozens or hundreds of blocks with custom padding today, it will wreak havoc on tomorrow's spacing and rhythm.

Besides that, the average user has little concept of design rules. Having a standardized system for spacing would give theme authors control over the output while giving end-users the ability to customize the look.

I have argued that WordPress needs some sort of design framework. For example, Tailwind CSS has specific padding classes. So does Bootstrap and nearly every other CSS framework. The web development community has been down this road. It is a well-trodden path, and WordPress is not innovating by using inline styles.

If the WordPress platform is going to put this sort of power into the hands of its users, it should do so in a way that allows designers to do their thing and not push users toward semi-permanent, inline-style soup in their content.

Pre-Gutenberg, I would have been entirely against the idea of WordPress introducing any sort of CSS or design framework. However, the platform is consistently moving toward becoming a UI-based design tool rather than simply a way to manage content. Users will have design-related options on a global scale all the way down to individual blocks. Users should absolutely have the ability to adjust a block's padding in such a system. They should not need an understanding of CSS to do so. Instead, for most use cases, users should be able to adjust padding based on whether they want larger or smaller spacing, not specific CSS values.

I propose a full set of standardized padding classes. The same would go for margins or other design-related options down the road. Gutenberg/WordPress should create a set of default values for these classes, which theme authors could override based on their design.

This is not a new concept. Dave Smith, a developer for Automattic, introduced a patch in 2019 that used named selectors for spacing on the Group block. He gave the following reasoning for choosing this approach over absolute values:

Imagine you are a Theme designer. You craft your CSS with spacing that is perfect for the design. You want to ensure that is consistent throughout your Theme, even if the page layout is being created by the end-user in the Block Editor.

With the approach I've taken here, when a size is selected only classes are added to the Block in the DOM. This affords the Theme creator the opportunity to provide custom sizes in CSS that are suitable for their Theme. If they opt not to do this then sensible defaults are provided.

With the pixels approach, we're locking users of the Block into absolute values and asking them to make a lot of decisions that they'd probably prefer not to have to make. It could also lead to an inconsistent visual experience.

This ship has already sailed and sunk with custom colors and font sizes. Gutenberg had an opportunity to standardize class names for these options but left it to theme authors. As a result, there is no standard across the theme market, which means that choosing the "large" font size or the "blue" text color provided by the theme will likely not carry across to the user's next theme. Now, we are on the cusp of far more design-related options as WordPress moves toward full-site editing. It is time to consider some standards on design-related class names and provide a framework that all themes can use.

Gutenberg could still provide a custom padding option just like it does for colors and font sizes. Users who choose to go this route would be making an explicit choice to work outside of the standard. But, let's not go down this road of allowing users to set absolute spacing values as the default option.

18 Sep 2020 6:49pm GMT