17 Comments

  1. Anish Badajena
    · Reply

    As a total non-developer, I am Team Mark on this one. I do not understand the conversation around static and dynamic pages, and speed “issues” in WordPress. If I use a caching plugin, doesn’t that also output a “static” page without hammering the database or PHP or whatever else causes poor performance? How are these cached pages different from Jam Stack pages? I also don’t see performance issues in WordPress sites that are up-to-date with a good theme, minimal plugins, proper caching, PHP 7+, and a good host. I pay $2/month for a shared hosting plan, my sites have 90+ PageSpeed score, and could easily handle thousands of visitors a day if they somehow got popular (I wish!).

    Report

    • Russell Aaron
      · Reply

      What we’re talking about here is no longer using PHP to power the front end of the WordPress site. Using JavaScript frameworks to render pages quickly and pulling in data from an API to populate the content.

      I wrote an article that you can read. This will help better understand what we’re talking about.

      https://blog.nexcess.net/headless-wordpress-what-is-it/

      Report

      • Rob Ruiz
        · Reply

        Russel – you are correct, that is kind of what Jamstack is attempting to achieve. However, what many that snicker or cringe at WordPress fail to understand or keep up with is the recent WP enhancements and the current efforts and milestones already set to address these problems. Just because WordPress historically had issues that more modern approaches solve doesn’t mean you need a whole new CMS architecture. It just means the currently leading CMS needs some enhancements to adopt that new way of rendering content – which WP is currently already doing with Gutenberg and also full-site block editing coming soon.

        So…yes, I am team WP all the way. However, it’s still imperfect. If I can state one BIG thing that would really help push WP and CMS into the future, it is what major WordPress hosting providers include on their server architecture. Right now, most WordPress hosts don’t include technologies necessary for server-side rendering of JS heavy UIs. If WordPress is to include components that are more futuristic, this needs to change in order for WordPress to remain SEO friendly and continue to deliver content that is rendered on the server in certain situations. Without Node installed on all WP servers, this because impossible to consider. The day WordPress can rely on Next.JS or other like technologies more is the day we will see a bigger and better WordPress emerge. This will destroy most Jamstack benefits.

        Report

  2. Leonardo Losoviz
    · Reply

    One of the benefits of the Jamstack is to go serverless, then we don’t need to worry about maintaining the server.

    But hey, there’s also serverless PHP, like Laravel’s Vapor, and Bref. If WordPress can get serverless, then it can attain the most important benefits of the Jamstack, without leaving its comfort zone of relying on dynamic code via PHP, and being a monolith.

    With serverless PHP, you got covered the “no webhosting needed” part, and your hosting bill will get down to cents per month. (You still need a server for the DB, that’s unavoidable)

    And the “serve from a CDN to make the site faster” part can be achieved nowadays, without having to deploy static files to a CDN. Just route the site through AWS Cloudfront and, the first time the page is accessed, Cloudfront can pull the content from the origin server, and serve it from its cache from then on. Have Cloudfront ignore the routes for the WP REST API endpoints, and you access dynamic functionality too (eg: post comments, and then lazy-load them)

    So the most important confrontation (if there is one) is not really between WordPress and the Jamstack. It’s more between WordPress and WordPress: how can WordPress provide support for these amazing new features, which are really just around the corner?

    Instead of emulating the Jamstack, WordPress will get better results, and way faster, by emulating Laravel. Adopting modern PHP practices (bumping up min PHP version, adopting Composer, using autoloading, using PHP Standards Recommendations) could take WordPress a long way to getting several of the benefits from the Jamstack, with minimal effort.

    Report

  3. Russell Heimlich
    · Reply

    This tweet sums up my feelings on the whole dynamic vs static site debate.

    At the end of the day people are going to pick the tool that can get the job done to the best of their knowledge.

    Report

  4. Álvaro
    · Reply

    Unless we’re all going to be developers, I don’t see how JAMstack can oppose WordPress. WordPress is (was?) a DIY technology, that empowers everyone to build on the web and publish their content (on their own, on their server). You don’t have to know a single programming language (it helps, but isn’t mandatory). JAMstack is a highly specialised technology, ran by developers. Sure, you can do it without being a developer tout court, but that’ll be the exception. There’s no way you can build a website in a day with JAMstack without knowing some programming language and the way all this stuff glues together (services, APIs, …).

    WordPress and JAMstack can work together, but there’s still a long way to make it user friendly. IMHO, WordPress needs to care both to the entry-level user, improving its UI/UX and overall experience, and the developer that embraces new and future technologies (but still needs to rely on a proven user-friendly way to get things done, content published, etc.).

    Not that it matters, but I still believe the transition to WP 5 and the introduction of Gutenberg should have been done with some kind of fork, which could allow WordPress to overcome some of its tech debt. It would be a risk, of course. But, maybe, it would allow to bring in more developers interested in newer technologies, and to integrate them more organically and with less need to reconcile with old code and methods. It would have opened up the field, instead of being almost just within the community itself. Also, it could have captivated people who are interested in other ways of publishing content, which is, in my opinion, the biggest challenge that lies ahead.

    Report

    • Joy
      · Reply

      There’s no way you can build a website in a day with JAMstack without knowing some programming language and the way all this stuff glues together (services, APIs, …).

      Yes, there is! Stackbit was mentioned in the article, but there is also
      Sitesauce
      Directus
      TakeShape
      Agility CMS
      Netlify CMS
      SiteLeaf
      (not all equal solutions)

      Report

      • Taj Royer
        · Reply

        Comparing Stackbit’s 10 themes to WordPress’ 1000’s just doesn’t seem right. While I look forward to the future of JAMstack, for a non-technical person it is limiting. The current problem I see with JAMstack is its lack of extensibility without the need for a developer. Want to make your site an e-commerce platform? Plugin. Want to integrate stripe? Plugin. Want to add a funky carousel to your home page? Plugin. At the moment the biggest hurdle I see to get non-technical users to use JAMstack is making it easier for them to tweak themselves. Most small and mid business don’t want to/ can’t afford to call a developer every time they want to make functionality changes to their site.

        Report

  5. George Stephanis
    · Reply

    I think the sheer number of upstart solutions that have declared that WordPress is over and done and will be dead in the next couple years … has sort of jaded us all to the idea.

    So when some relatively new technology comes up, declaring they’re going to take everything over … we’ve all heard dozens of similar solutions make the same claim over the years. Sometimes it’s genuine, sometimes it’s an attempt to get publicity by picking a fight with the market leader. But it never pans out, the world moves on, and the next system declares they’re the future of the web and WordPress is already dead, but that we don’t realize it yet.

    Shrug.

    Move on, keep doing the work to support our users. If something shifts, it will, but it doesn’t change our goals.

    Report

  6. Arūnas
    · Reply

    Reading through Matt’s arguments, I agree with most of it, except one – WordPress is not developer-friendly. Hasn’t been for a long while now. Especially for new developers, who come into WordPress development from. Laravel or JS – our developer tooling looks like its from the stone age, dependency management and environment management is non-existent or rudimentary at best. I think it turns away a lot of good new talent and we’ll start to feel the real harm of that in the next 3-5 years.

    Report

  7. Skylar Kunde
    · Reply

    Does Cloudflare increase the speed of the WordPress site?

    Report

  8. Hendrik
    · Reply

    The speed of the site itself? No. (At least not in the lower tiers.)

    But cloudflare helps you to deliver static assets like styles and images faster. It also mitigates unwanted bot traffic, which might free up ressources on the server.

    So in general you can say that cloudflare does not make the server faster, but it helps you deliver the site faster to where it needs to go.

    Report

  9. Luke Cavanagh
    · Reply

    You can easily enough set page rules in Cloudflare to static HTML content and exclude URLs from being cached. Also if using Cloudflare you can minify CSS and JavaScript at the CDN edge and deal with image optimization at the CDN edge.

    Report

  10. John Rom
    · Reply

    At WordCamp US 2015 or 2016, I stood up and asked Matt during the QA if he thought people would eventually build theme / plugin templates in JavaScript. He quickly responded that it wasn’t going to happen. Now, Gutenberg builds part of the frontend of the site with JavaScript, while WordPress’ archaic template hierarchy continues to render the header, the footer, the sidebars (are those still a thing?).

    Fast forward to 2020, I build websites using React and whatever CMS is relevant. Sometimes that’s WordPress. Or bring your own CMS. I haven’t thought about going to a WordCamp in 3 years, even though my job would probably pay for it because when I went it was pretty exclusive of the rest of the stack. That’s OK, but WordPress isn’t the full stack.

    Many people are drawing a false equivalency between the future of the web and “JAMstack”. Microservices are the future. Headless CMSes are the future. The backend doesn’t matter to the front-end, only the API surface does. These are the reasons I’m not as excited about WordPress anymore, not because of marketing by headless CMS companies. The tooling of the modern front-end is amazing.

    WordPress can fit perfectly well into the modern front-end, but the people at the top shouldn’t hold it back by starting silly fights and instead learn from modern tech. WordPress can add a lot to the modern front-end, and Gutenberg is a great start. I still can’t fathom handing over another CMS for a client to manage. But I’d like to see WordPress strive to provide an interface to interact with the rest of the front-end and not argue how front-end should be done in the first place because that’s absolutely not where it excels.

    Report

  11. Timothy Jacobs
    · Reply

    I think what is particularly exciting about Gutenberg is that everything serializes to HTML. I’m not sure exactly where Full Site Editing is at the moment, but it looks like it might also be something that can be serialized to HTML. But in a manner where we can say which bits are dynamic and which bits aren’t.

    So I think a particularly exciting form of Jamstack is not completely API powered by structured data, where you re-implement your block styling. But one where Gutenberg does the compilation and rehydrating of bits that need to be dynamic.

    Report

  12. ts
    · Reply

    Back in 1994 a “hello world” webpage was about twice the size of the content in code and could be written in any editor. With WP, it’s a 5 minute install and data base and a theme, “hello world” in react requires 80 MByte of JS script tools being processed.

    I think we have to realize that tooling complexity, for many developers, isn’t a bug, it’s a feature. It’s fun, but also a way of keeping what developers do “magic”, and pricy. And of course, there are situations where it’s not just preferences but technologically indicated.

    And WordPress does have a strategic problem on that front to the extent that keeping non-tech users and low-tech web designers happy with page/themebuilders that use the database, is making it harder for developers to sell complex backend theming services. Which in turn makes them root for different tech stacks. Quite understandably. Which in turn creates an eco system around it.

    But that ecosystem also has a strategic problem: it cannot get much simpler, because if it does, it loses its developer friendliness which is, again, based on its complexity.

    And that probably means that both worlds will find different corners and co-exist rather peacefully, potentially even by co-operating. And I’m pretty sure Matt Mullenweg knows that very well. Just as the JAMstackers…

    Report

  13. Will Sokolowski
    · Reply

    I love Jamstack…I work with it daily…I just don’t see how it’s ever going to ‘disrupt’ WordPress in any definitive way. Or other solutions like the various site builders out there with market share, Shopify, etc. I started with WordPress in 2004…and while they don’t have it all figured out, they’re clearly still innovating…and the community is strong. Jamstack rocks…I’ll keep at it…putting a dent in WP though? Not so sure on that.

    Report

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: