Category: Web Stack

  • Headless CMS Options: ContentStack

    I got a chance to look at another one of the major headless CMS (hCMS—the ‘h’ is decapitated) contenders, namely ContentStack. In a world where it’s hard to tell one hCMS from another, a couple of ContentStack’s differentiators are what it calls ‘modular blocks,’ an intuitive setup for managing multi-language environments, and ‘environments’ that allow you to keep development, testing, staging and production sites (or whatever arrangement you prefer) cleanly side by side.

    It’s probably also fair to say that ContentStack is the hCMS that most squarely positions itself as a primarily enterprise solution, something that’s reflected in its pricing model. There’s no free tier to rope in the dev community (there’s a free trial, but only for two weeks). The “Start” plan is $995 per month; the “Grow” plan is a stiff $4500 per month. If you want to run more than one site on an account, you’ll need the “Scale” plan, which, um, costs more. Other gating factors among the plans are limits on API calls, the number of content types you use, and how many entries and assets you manage within the service.

    All plans involve the modular blocks support, which some of ContentStack’s rivals don’t have, but which is analogous to the Gutenberg editor that WordPress introduced in their 2018 5.0 release. In both arrangements, a web page is conceived of as a stack of blocks from the top of the page to the bottom, with options for some blocks to be set side by side, giving you the ability to create columns within your pages. You can drag the blocks to where you want them on the page, or click on them to edit their content and configuration options.

    The content type editor at ContentStack.

    The left column shows you the types of blocks you might add to a content type; the right column shows you the properties of the currently selected block.

    This is fairly similar to popular block-oriented editors in the WordPress environment, such as Elementor and Divi. Here, for instance, is a “template view” of a page in Divi (when editing in Divi, the default WordPress editor is overridden).

    Divi calls this “wireframe mode”

    Note that you don’t really get any sense of what the blog entry or the WordPress page is going to look like when you use a “block grid” view like these. In the headless CMS world, this is solved by having a staging site where you can generate the updated site and view it by way of the resulting pages. In a Divi or Elementor scenario, the editor can be toggled into a WYSIWYG mode that is possible precisely because the editor is constrained to what’s possible to produce within WordPress. You get, not surprisingly, a far clearer sense of what your work is going to look like on the actual site. Here, for instance, is the page shown in a block grid above when viewed in Divi’s more commonly used mode.

    In this mode, you can edit text directly, as it will appear in the published page. Other things require you to click on the options and edit in a modal view.

    One thing that has to be admitted is that putting this sort of editor on top of the WordPress framework, which is already arguably a little jumbled from years of adding bits and pieces, creates an editing environment that has mysterious moments of sluggish response, lots of quirks, and more than its fair share of bugs. It is almost certainly easier to create a clean, reliable headless CMS (even one that mimics some of the look and functionality of traditional WordPress, as some hCMS’s do) than it is to perch one atop the venerable WP platform.

    It’s possible, within ContentStack, to create new block types, including ones that call out to third-party services. At the recent GatsbyConf 2021, a brief demo of personalization vendor Uniform’s integration with ContentStack showed that it was easy to embed Uniform blocks that would either make notes about a user’s behavior on a site (remembering which entries in a blog they’d looked at, for instance), or alternately display content with different versions chosen according to the notes previously made. The ability to perform this sort of integration without writing it in custom code on the static generator side of the equation could well prove interesting to potential ContentStack customers as these sorts of integrations proliferate. As for Uniform itself, we’ll tackle that on another day.

    In summary, here are key characteristics of ContentStack:

    • Leans toward enterprise IT scenarios
    • Allows creation of large numbers of different content types
    • Has good support for multi-lingual and multi-channel scenarios
    • Built in “environments” allow easy separation of development, staging, and production versions, along with ability to track all the elements that made up a given release (tagged by you at release time) and with granular support for rollbacks.
    • Builds content types on a “modular block” model, which can be a powerful enabler for content creation teams

  • GatsbyConf 2021 brings new 3.0 version and new images

    Latest revision: March 4, 2021

    The online virtual GatsbyConf, which kicked off today, announced at least six significant updates, including a 3.0 release of Gatsby itself; a new component that goes beyond the already savvy Gatsby-sharp handling images used within Gatsby sites; and the addition of a CDN service (in partnership with Fastly) to the Gatsby Cloud service. Additionally, there were new, substantially changed releases of key plugins tying Gatsby to headless instances of WordPress, Shopify, and Contentful.

    Patrick Sullivan, Senior Product Manager at Gatsby Core Team, noted that the past year has seen a 40% increase in the number of Gatsby sites on the web, but conceded that there were “a number of struggles with using Gatsby.” Toward addressing issues such as build times, especially as part of the local developer experience, Gatsby Senior Software Engineer Lennart Joergens walked through two significant updates being released as part of 3.0. First, local development warm rebuilds will use a “query on demand” capability so that only altered pages are regenerated.

    Joergens showed a second change where the directory structure of content in a site can be mapped onto the source file directory tree. You might have a “products” directory, a “shirts” directory within it, and then the slug for each file will reflect a product name. This is the sort of organization good developers tend to lean toward in any case, but here the logic that’s encapsulated in the setup can be combined with the partial rebuild capability so that, as Joergens demonstrated, changing the name of a shirt product causes several pages to rebuild (because there are links on other shirt pages to this product along the lines of “you might also like”), but changing the description on the shirt page causes that page only to rebuild, because that’s the only place where that text is rendered.

    Online resources relevant to 3.0:

    The Chasm

    More than one speaker in the conference lineup—and this includes Product VP Dustin Schau —talked about website creation as a function of two presumably rather different groups: marketers (for the words on the pages in the site), and developers and designers (for the site itself).

    Nick Gernert, CEO of WordPress VIP (the high end consulting and hosting arm of Automattic), took the position that the JAMstack world has been too focused on tools to grease the skids for developers (and enhancing performance), but would need to shift the priority to enabling creators (that is, the marketers). He proposed a website version of Maslow’s Hierarchy of Needs, where the base of the pyramid is Security and Scalability, and the peak is the “meaningful content experience.” Just below the peak? Agility.

    Seize (and Discard) the Moment (Library)

    One final takeaway: more than once in presentations during the day, the moment.js library was called out as something that, when used, causes an outsize bump in the size of your JavaScript bundles. You’ve been warned.

    A second day of the conference will offered several workshops, including a 101 course to get yourself started with Gatsby.

  • The Core Web Vitals Report

    [et_pb_section fb_built=”1″ _builder_version=”4.8.1″ _module_preset=”default” custom_padding=”||7px|||”][et_pb_row column_structure=”3_5,2_5″ _builder_version=”4.8.1″ _module_preset=”default” min_height=”711px” custom_margin=”|auto|0px|auto||” custom_padding=”||0px|||”][et_pb_column type=”3_5″ _builder_version=”4.8.1″ _module_preset=”default”][et_pb_text module_id=”section1″ _builder_version=”4.8.2″ _module_preset=”default” custom_padding=”9px|||||”]

    Google’s Core Web Vitals: Executive summary

    [/et_pb_text][et_pb_text admin_label=”#section1″ _builder_version=”4.8.2″ _module_preset=”default” text_font_size=”19px” custom_padding=”5px|12px|9px|12px|false|false” border_radii=”on|1px|1px|1px|1px” border_width_all=”1px” box_shadow_style=”preset2″]

    [dropcap]G[/dropcap]oogle earlier pre-announced a May 2021 shift to using what it calls “Core Web Vitals” (CWV) metrics as part of its ranking algorithm. The pandemic has pushed this plan out to an unknown future date–Google has said it will provide six months further notice before the change is made. This report offers an initial explanation of the three metrics involved, how they relate to other Google page experience metrics, and how to strategize for what will likely be a noticeable effect on rankings when CWV enters the ranking algorithm.

    [/et_pb_text][et_pb_text admin_label=”#section2″ module_id=”section2″ _builder_version=”4.8.2″ _module_preset=”default” text_font_size=”19px” custom_padding=”||1px|||”]

    [dropcap]T[/dropcap]he fact that Google is changing its ranking algorithm is not, in itself, cause for alarm. Google changes its process—what gets measured, how it’s weighted, and so on—all the time. Generally there are several hundred (mostly trivial) changes in a year.

    CWV promises to be one of Google’s bigger deal changes. How much bigger is worth contemplating. We’ll get to that.

    One indication that this one matters to Google (besides the lengthy advance notice) is that CWV is an addition to a group of metrics that Google puts into the category of Page Experience. How does a user feel about the experience of using a particular page?

    As you can imagine, Google wants to send you to results that you are happy you were sent to. So, if you asked a question, they’d like to send you to a page that answers your question (or, better yet, they’d like to answer your question right there on the search results page). Beyond the content of the page, though, lots of things figure into how you experience the page you’ve just been sent to.

    If the page takes forever to load in your browser, odds are you won’t even stick around to see the page. But speed comes in more than one flavor, and CWV tries to get at a few elements that are important in how you perceive the speed of a page.

     

    [/et_pb_text][et_pb_text module_id=”section3″ _builder_version=”4.8.2″ _module_preset=”default”]

    The Core Web Vitals: What Are They?

    [/et_pb_text][/et_pb_column][et_pb_column type=”2_5″ _builder_version=”4.8.1″ _module_preset=”default”][et_pb_toggle title=”Toc” _builder_version=”4.8.2″ _module_preset=”default” inline_fonts=”Encode Sans Expanded”]

    Executive Summary

    Algorithm Changes

    What Are the Core Web Vitals?
    How to Get CWV Scores
    Do CWV Scores Matter?
    CWV Strategies

    [/et_pb_toggle][/et_pb_column][/et_pb_row][/et_pb_section][et_pb_section fb_built=”1″ _builder_version=”4.8.2″ _module_preset=”default” custom_padding=”0px|||||”][et_pb_row column_structure=”3_5,2_5″ _builder_version=”4.8.2″ _module_preset=”default”][et_pb_column type=”3_5″ _builder_version=”4.8.2″ _module_preset=”default”][et_pb_text _builder_version=”4.8.2″ _module_preset=”default” text_font_size=”19px”]

    [dropcap]C[/dropcap]ore Web Vitals (CWV) is a set of three measurements Google has said it will add to the group of measurements it uses when deciding which results you see first when you perform a search on Google. The decision to add these metrics was announced months in advance (something Google only very rarely does), was originally slated for May 2021, but has been pandemic postponed. Google has said it will provide six months of warning before pulling the switch and, as I write this, that hasn’t been given yet. So, perhaps late fall 2021.

    Google says there are three “core” essentials.

    The first measurement is how long it takes for the largest piece visible on the page in your browser (what’s “below” your window doesn’t matter until you scroll down to it) to appear. This is the “Largest Contentful Paint” (LCP) and it’s really just a proxy measurement. If you can get the biggest piece displayed in a hurry, probably the overall sense the user gets is that the page loaded in a hurry.

    How you can tell a page is performing in LCP measurements is something we’ll return to later—it takes some tooling.

    Measurement two is how long the user has to stare at the browser window before it will react to their input. How long before they can click on a button and something actually happens. This is First Input Delay (FID).

    Making things slightly more complicated, there are testing situations where Google uses a metric called Total Blocking Time (TBT) as a proxy for FID. For the moment, let’s not split hairs. What Google is trying to get at is how long before the page is sufficiently loaded that you can actually use it.

    The third measurement is largely targeting the mobile experience and focuses on the weird jittery effect you get when a page has started to paint, but some big piece drops into place and the page is repainted in a way that makes everything shift position all at once. You’ve started to read the page, but now everything shifts up a paragraph. It’s kind of hard to explain, but everyone with a smart phone knows what this is. Google measures it with Cumulative Layout Shift (CLS). Not just “does it jump,” but how much overall does it jump before it settles down and stays put.

    [/et_pb_text][/et_pb_column][et_pb_column type=”2_5″ _builder_version=”4.8.2″ _module_preset=”default”][et_pb_text _builder_version=”4.8.2″ _module_preset=”default” custom_margin=”167px|||0px|false|false” custom_padding=”14px|20px|14px|20px|false|false” custom_css_main_element=”padding: 10|| ” border_width_all=”3px” border_color_all=”#7CDA24″ border_style_all=”groove” box_shadow_style=”preset2″]

    THE “OTHER” WEB ESSENTIALS

    As mentioned, there are three “core” essentials. But there are four other metrics that Google considers “essential”:

    • Being “mobile friendly”
    • Being safe to browse
    • Using HTTPS
    • Avoiding Intrusive Interstitial ads and notices.

    You’ll notice that this is more a list of do’s and don’ts. You’re either using HTTPS or you’re not, for instance. 

     

    [/et_pb_text][/et_pb_column][/et_pb_row][et_pb_row column_structure=”3_5,2_5″ _builder_version=”4.8.2″ _module_preset=”default” locked=”off”][et_pb_column type=”3_5″ _builder_version=”4.8.2″ _module_preset=”default”][et_pb_text module_id=”section4″ _builder_version=”4.8.2″ _module_preset=”default”]

    How to “See” the CWV Measurements

    [/et_pb_text][et_pb_text _builder_version=”4.8.2″ _module_preset=”default” text_font_size=”19px”]

    [dropcap]G[/dropcap]oogle provides several tools that let you see specific scores for CWV, but probably the quickest way to get a general sense of how a given page is performing is to use the Pagespeed Insights tool. You paste in the URL of the page you’re interested in, it chews on things for a moment or two, and then two color wheels pop up, most likely sporting the red or orange rings that indicate a less-than-fabulous score.

    You’re generally going to want more detail than this score gives you, though. You’ll want to know what element is the one Google is counting as the largest when it times the Largest Contentful Paint, to give one example.

    Getting the info is as simple as going to the page you’re interested in using the Chrome browser, then toggling yourself into the developer tools pane (use the keystroke combination Ctrl+shift+i, which I think maybe stands for “inspection”).

    [/et_pb_text][et_pb_image src=”https://peakzebra.com/wp-content/uploads/2021/02/inspection-console.png” title_text=”inspection-console” _builder_version=”4.8.2″ _module_preset=”default”][/et_pb_image][et_pb_text _builder_version=”4.8.2″ _module_preset=”default”]

    Here’s the developer tools console in action, after recording the load of a page on PeakZebra. Following the timeline in the middle of the display is a great reminder that a lot of things are going on under the hood of a modern browser.

    [/et_pb_text][et_pb_text _builder_version=”4.8.2″ _module_preset=”default” text_font_size=”19px”]

     

    [dropcap]I[/dropcap]n the “Timings” bar in the top pane of the image above, the LCP flag marks the spot in the timeline when the Largest Contentful Paint was rendered in the viewport (in this case, at 2747.9 ms).

    Total Blocking Time (which will become important to us because it’s a proxy for First Input Delay) is recorded (as an estimate, though it’s given in hundredths of a millisecond, which I’ll concede is puzzling) just above the lower (console) pane of the tool display. In this case, it’s 654.52ms. But as for what it actually is? Google’s process looks at the timeline for tasks that took longer than  50ms. For each, the number of milliseconds that the task ran after the 50ms mark is added together. The “long tasks” (as they are called) are highlighted in the timeline by red hashmarks and a red triangle in the upper right of the offending taskbar. Google wants you under 300 milliseconds, so this page kind of sucks.

    Cumulative Layout Shift is marked in the timeline with red bars where Chrome noticed things shifting. If you click on the red bar, the part of the page that is shifting will be highlighted for you. The damage that is done to your score is a special Google concoction that looks at the number of frames in which elements are shifting and the distance in pixels that they shift.

    This is a place where things can go screwy in a hurry. And elements may be shifting in ways that you are completely unaware of. On the page I’ve been looking at here, for example, I noticed that the title of the page is rendered first in the font it’s supposed to be in, then in a default font that the theme I’m using (this is in WordPress) overwrites, then rerenders as the font it’s supposed to be. The change in font means the title is longer in the default, so that it runs over to the next line, which shifts that segment of the page, though just for the shortest blink of an eye:

    [/et_pb_text][et_pb_image src=”https://peakzebra.com/wp-content/uploads/2021/02/text-paint-example-1.png” title_text=”text-paint-example” _builder_version=”4.8.2″ _module_preset=”default”][/et_pb_image][et_pb_text _builder_version=”4.8.2″ _module_preset=”default” text_font_size=”19px”]

    Everything returns to normal a millisecond later and, at least on a reasonably peppy system, this repaint is completely undetectable. The metric that matters to Google here is really more how it performs on a mobile device, but the change is undetectable there as well.

    At present, the CLS metric is less weighted in Google’s algorithms and the fact that they’re still sorting out how to detect what actually impacts the experience is presumably the reason why. They’ll get better at measuring this as the year progresses and it seems pretty likely that at some point the weighting will shift to make CLS equally important.

    [/et_pb_text][/et_pb_column][et_pb_column type=”2_5″ _builder_version=”4.8.2″ _module_preset=”default”][et_pb_image src=”https://peakzebra.com/wp-content/uploads/2021/02/low-pagespeed-performance.png” title_text=”low-pagespeed-performance” _builder_version=”4.8.2″ _module_preset=”default”][/et_pb_image][et_pb_text _builder_version=”4.8.2″ _module_preset=”default”]

    Here’s a meh score for a page on the WordPress version of PeakZebra. In truth, this score isn’t actually that bad and you’ll see considerably worse scores on many perfectly normal WordPress pages. This shows the desktop score; the mobile score is (and usually is) considerably worse. 

    [/et_pb_text][/et_pb_column][/et_pb_row][et_pb_row column_structure=”3_5,2_5″ _builder_version=”4.8.2″ _module_preset=”default”][et_pb_column type=”3_5″ _builder_version=”4.8.2″ _module_preset=”default”][et_pb_text module_id=”section5″ _builder_version=”4.8.2″ _module_preset=”default”]

    Do CWV Scores Matter?

    [/et_pb_text][/et_pb_column][et_pb_column type=”2_5″ _builder_version=”4.8.2″ _module_preset=”default”][/et_pb_column][/et_pb_row][et_pb_row column_structure=”3_5,2_5″ _builder_version=”4.8.2″ _module_preset=”default”][et_pb_column type=”3_5″ _builder_version=”4.8.2″ _module_preset=”default”][et_pb_text _builder_version=”4.8.2″ _module_preset=”default” text_font_size=”19px”]

    [dropcap]I[/dropcap]f you’re running on a typical WordPress, Drupal, or similarly architected web publishing framework, your CWV scores at present are probably not all that great. You are right to wonder whether fixing the ills of your website are worth the trouble. Will your rankings really suffer all that much if you don’t bother? What if everybody just decided to ignore this stuff?

    The only true answer to this at the current moment is: nobody outside of Google has any idea whether this matters much or at all. We’ll find out when and if there are huge reorderings on search engine results pages (SERPs).

    That said, if it figures in the rankings in any modestly significant way, you can bet that organizations that actively tune for SEO will tune for CWV. In any “all things equal” situation, their page is going to do better than the organization that didn’t bother. I’m operating mostly on an experienced hunch here, but I think there will be some serious shifts as a result, particularly in the world of B2B and technical vendor pages.

    [/et_pb_text][et_pb_text module_id=”section6″ _builder_version=”4.8.2″ _module_preset=”default”]

    CWV Strategies

    [/et_pb_text][et_pb_text _builder_version=”4.8.2″ _module_preset=”default” text_font_size=”19px”]

    There are four ways a company might opt to deal with CWV (aside from just ignoring it), listed here in decreasing order of hassle:

    1. Relaunch on a more performant platform
    2. Make substantial adjustments to the existing platform (really paying attention to tuning a WordPress site, for example)
    3. Use the existing website as a headless CMS for a statically generated front end to the site
    4. Create groups of new pages on the existing domain that run in tandem to the existing site, these pages being ones that matter to the organization’s content and SEO strategy

    [/et_pb_text][/et_pb_column][et_pb_column type=”2_5″ _builder_version=”4.8.2″ _module_preset=”default”][/et_pb_column][/et_pb_row][et_pb_row _builder_version=”4.8.2″ _module_preset=”default”][et_pb_column type=”4_4″ _builder_version=”4.8.2″ _module_preset=”default”][et_pb_text module_id=”section6″ _builder_version=”4.8.2″ _module_preset=”default”]

    How to Choose

    [/et_pb_text][et_pb_text _builder_version=”4.8.2″ _module_preset=”default” text_font_size=”19px”]

    Is it worth the trouble to, say, relaunch on a new platform? Hard to say at this point, and maybe not, but if you were going to relaunch something anyway, now is the time to make sure that whatever you relaunch with has screamingly good performance when it comes to CWV.

    Otherwise, your choice will come down to the specifics of your site and what it does. We can dig into the virtues and mechanics of the various options in future articles, but it’s certainly worth taking a few moments now to run a representative sample of your website’s pages against these CWV metrics.

      [/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section][et_pb_section fb_built=”1″ fullwidth=”on” _builder_version=”4.8.2″ _module_preset=”default”][/et_pb_section]

    1. TheJam.dev Day Two: Looks at Angular+Jamstack, Github Founder’s Take

      Key among the events at the second day of the Jam.Dev online event was the concluding “fireside chat” with RedwoodJS creator and Github founder Tom Preston-Warner, in which Preston-Warner imagined a more full-stack edge architecture, something he is working on RedwoodJS to create. (Coverage of day one is here.)

      Tom Preson-Warner

      Moderator Brian Rinaldi, developer advocate at StepZen, asked Preston-Warner what he thinks of the “Jamstack” terminology. “The term jamstack was coined by the founders of netlify and I got involved with them very early in their journey when I think it was just the two of them, Preston-Warner said. “The term jamstack was something we talked about a great deal at some bars in the Dogpatch in San Francisco when they were just setting out and trying to define what Netlify was going to be and where they were going and how do you talk about the ideas behind what we now know as the jamstack, without a term. At the time, before we had the term jamstack, it was all static site generators, but When you say a static site, this does not  necessarily convey that you’re going to use javascript to pull in third-party APIs, or do dynamic things, or pull in external content and kind of mix it all together. So ‘static site generation’ did not do the job.  … . So that’s where jamstack really came from, and I thought it was great.

      “It always makes me think of Ajax when google maps first came out and it blew everyone’s mind because you could drag this map around it will just load stuff in automatically. And this concept that Ajax became, it was out there, all the pieces were there but nobody thought about it and no one could really leverage it because no one could talk about it until Ajax was coined. And now this concept this more complex concept had a name and everyone could talk about how they were going to do Ajax. And to me jamstack is the same kind of a thing.”

      He went on to note that “the industry needed a name for what the jamstack is, this collection of technologies that allows you to have better security, faster sites, all of these characteristics that jamstack has are now wrapped up in one word that you can talk to your colleagues about, talk to your boss about, that Netlify can talk to their customers about.”  

      Rinaldi asked what RedwoodJS is providing that Jamstack isn’t providing yet. “I love Jamstack in the way that most people think about it today,” Preston-Warner said. “But I think it can go even further. There’s a lot of potential in what you can do in a serverless environment now and if you mix that with some of the ideas around static site generation and third-party apis, or even just javascript on the front end and the client talking to something, some kind of api on the backend. I think that’s cool, but what I want to do is create a custom website completely from scratch and probably not even use a lot of the third-party apis. I might pick and choose a few here and there, but I want to create a custom site that is doing a lot of its own business logic. So, being involved in Netlify, when they came out with their function support where you can write the body of a lambda function in a file and they’ll pick it up and deploy it to AWS Lambda for you. That was kind of a revelation for me in what could be possible using this stack, because nobody wants to use AWS’s ways to get your code into AWS Lambda. It’s just not pleasant.

      “You can push all of these things out as far to the edge as you can, and you can get a level of architectural simplicity and scalability for a tremendously small amount of effort. Thinking about that made me want to find a framework that was going to let me do that.”  

      Jamgular

      Another session concerned with somewhat alternative frameworks walked through a mix of Jamstack and Angular. The presenter, Netlify Developer Experience Engineer Tara Manicsic called the combination “Jamgular.” What was nice about the session was that it featured Tara on a highwire of live demonstration and viewers got a good view into what had to happen, complete with lots of detail, in the actual work of building and configuring an Angular project. The flip-side was that, as tends to happen with live coding, various things didn’t go as expected and, well, it was like real programming.

      A less-known detail that came forward was that Angular has built-in support for generating a folder containing the static output for a project, so even though Angular doesn’t come up as frequently in jamstack conversation, it’s definitely in the hunt.

      Manicsic was asked by an attendee why she’d mentioned in passing that redirects were important. The point here was that a user can request something using a URL that is redirected at the CDN edge and sent to an edge handler (a function running serverlessly at the CDN). The callback is made so that it includes data about the edge node where the call originated, so that geographically specific actions can be taken.

      Other Talks

      Gatsby Software Engineer Obinna Ekwuno gave a more philosophical talk about when it’s good to simplify architectures and when too much gets lost in the simplification. While he pointed to some interesting tensions between having to learn lots of frameworks and libraries to find one’s way through the jamstack world (and even more as the line between front-end and back-end blurs), it seemed like we are doomed to live with those complexities for the foreseeable future.

      Agility CMS President Joel Varty tackled what is surely one of the major questions that pops up around Jamstack front ends: where “everything else” goes – things like user registration, authentication, restricted access, user-generated-content, commerce and search. His talk met with lots of approval in the conference chat stream, insofar as it created a lot of clarity around the big picture of jamstack’s many architectural elements.

      Jamstack, Varty said, plays mind games with us to make it hard to know, especially when first getting acquainted, to know where a given snippet of code will actually be executed.

      Tessa Mero’s walkthrough of the Cloudinary (where she is a developer advocate) options for media accessibility was interesting, in that Cloudinary does indeed do some interesting tricks like using AI to automatically generate ALT tag text for images, checking photos for potential problems when viewed by color-blind users, and providing machine-generated captioning for videos. She also pointed to several open resources for testing accessibility issues.

      Ohad Eder-Pressman

      Ohad Eder-Pressman, cofounder and ceo of Stackbit, presented two open tools that Stackbit has created for spinning up various flavors of jamstack site. A site called Jamstack.new let’s you pick a theme, a static-site generator, and a headless store for content, then creates an instance nearly instantaneously. The company also maintains jamstackthemes.dev, which is a repository for, you guessed it, themes that can be used with various frameworks.

    2. TheJam.dev 2021 kicks off with azure and ecommerce

      Today was the first day of a two-day Jam.Dev event online. The event had a lot to offer people who are presently trying to sort out the lay of the land in the static site generator ecosystem.

      The Azure Take on Static

      Shmuela Jacobs, cloud developer advocate at Microsoft, walked through the Static Web App service that is currently in developer preview on the Azure platform. The introduction of the service makes perfect sense, of course, given the success of companies like Netlify and Vercel in providing production build and hosting services. The basic structure of the new service looks a lot like Netlify in terms of what it does, but doesn’t have nearly as friendly a UI, at least not at this point. Part of this no doubt lies in the higher degree of complexity that large sites on Azure tend to bring to their cloud game.

      Like other options in the space, Azure basis the static service on repositories stored in github, such that when a new commit is made to the application’s repository, Azure runs the build and, assuming a successful build, deploys the application to the Azure CDN. You set up a config file that sets up things like environment variables that your app needs in the production environment.

      Shmuela Jacobs, cloud developer advocate at Microsoft

      By and large, this look at Azure’s entry into the jamstack ecosystem (beyond the already existent capability to host Docker images of jamstack servers) was perhaps the most interesting part of the day.

      Stephanie Eckles, a software engineer at Microsoft, gave a full-throated and interesting walkthrough of the 11ty static site generator. She built a basic site as a demo that ran in 3 minutes, complete with a timer running in the screen. It definitely underscored the simplicity and direct approach of 11ty compared to static sites built with React or Vue frameworks running on client pages. A panel that followed brought together Sara Drasner, vp of developer experience at Netlify, Phil Hawksworth, developer experience engineer at Netlify, and Gift Egwuenu, frontend developer at Passionate People. These are all heavy hitters in the jamstack world, but the panel never quite gelled and thus wandered a bit.

      Quicktime

      A series of quick, ten-minute talks covered a lot of ground, including an overview of Google’s Lightspeed metrics given by freelance developer Henri Helvetica. There’s no doubt that Helvetica knows whereof he speaks—he’s a frequent speaker at events and turns up involved in lots of projects—but the lightning format didn’t serve him well when it comes to Google metrics, which get deep and detailed in a hurry.

      Tamas Piros, developer advocate at Cloudinary, talked about image management (and, in particular, distributing tailored images from the edges of the net. The takeaway here was a link to a site he put together for comparing various approaches in real time. It’s at know-your-media.dev. Miriam Schwab, CEO and cofounder of Strattic, talked through the basic scenarios for making WordPress a backend for various kinds of static site, as well as making a compelling argument for why this is important in a world that has become very accustomed to WordPress and capable of using it to turn out tailored sites very quickly.

      Miriam Schwab, CEO and cofounder of Strattic

      The final two talks of the day focused on jamstack approaches to ecommerce, though largely it was a matter of showing that it was indeed possible to do. Flor Antara of Zipwhip worked through four approaches to selling on static-based sites.

      Option one, Antara said, was the non-jamstack Shopify-like third-party service. This part of the talk had me looking for the option to turn the playback speed to 1.5x. This can be a problem with live events. Option two was integration with an API, which she pointed out could be fairly time consuming to set up. Option 3 was what Antara called “Add-on” ecommerce.

      Snipcart, etc

      In a quick demo, she demonstrated the Square “Buy Link”, the second the PayPal equivalent, the third was Shopify buy button, and the final was SnipCart, which is, not to split hairs, actually an API approach, just one that happens to use GraphQL. These are all good ways to handle basic sales capabilities, but somewhat glossed over in the presentation was the fact that if you go with, say, a PayPal buy button, then you have to handle anything that would typically fall into tasks that collectively we call a shopping cart. In other words, you have to have static pages that describe the products. You don’t get any integration with inventory data unless you code it yourself. If you want to offer, say, three for the price of two bundling, you’ve got to track how many things have been ordered and whether the relevant items quality for the discount.

      It _is_ possible to support some shopping cart options into a PayPal scenario, but basically you are handing off to PayPal, just like you might hand off to any other third-party ecommerce store, as per Antara’s Option One. But SnipCart is a different animal in that it supports GraphQL. As a technicality, this is an API interface, too, but it’s particularly well geared to jamstack frameworks that use GraphQL. Antara gave a walkthrough of how this could be added to her flat HTML product pages, but arguably what’s valuable here is the ability to use templated product pages that query SnipCart for data elements that are dropped into the page.

      The conclusion of the talk, that SnipCart is the clean, jam-savvy way to do this, is spot on. Since this was a demo-based talk, SnipCart was the only vendor discussed as a headless eCommerce vendor, but needless to say, there are others, such as commercetools, and even a headless variant of Shopify.

      We’ll cover day two of Jam.Dev in a separate article.

    3. It’s Raining Headless CMS Systems

      There are two competing dynamics in the world of JAMstack. First, there’s the idea that JAMstack is the approach of choice for creating lots of different applications, beginning with marketing sites that are essentially just five pages (about, contact, products, solutions, resources) and continuing on to blogs, and from there to sites that are interactive, consult data through APIs, and so on. In other words, static is the best current choice for making websites. The second dynamic is that, even for those basic marketing sites, decoupling the content management is a good thing.

      Building a static site draws most of what ends up live on the website from source code files and, in the simplest approaches, in markdown files. You can build a perfectly snazzy blog just by writing all your entries in the markdown format and storing them in the right directory.

      If all you do is put your content into markdown files, you’ve still effectively decoupled the content from the presentation, because you could copy that directory full of blog entries to some other system and present it using some completely different application.

      The CMS-as-a-Service Upside

      It’s clear why this would be attractive compared to, say, WordPress (the defacto competitor to JAMstack as a whole). In WordPress, you use the site itself (albeit in an administrator console interface) to create and edit your content. Normally, you then serve it up using the WordPress application and, should you decide you don’t like WordPress anymore, you are more or less stuck. (As an aside I’m obligated to say that it’s now easily possible to just use the back end of WordPress and then use something else—Gatsbyjs, for example—to serve up the files to website visitors.)

      With a headless CMS, you can theoretically change horses midstream by changing which horses are presenting your web pages. In practice, there just aren’t a lot of sites around that have actually done this—changing from one static site generator (SSG) to another and running the new setup without interruption using data from a third-party headless CMS tool. As long as we’re basically talking about blogs, there’s no reason to think this isn’t readily done, but in some ways it fixes a problem that site builders may not be entirely aware that they have.

      It may be increasingly valuable to change presentation (and delivery channel—let’s not forget that this CMS may additionally serve up tweets and Instagram posts) and keep the existing CMS, but one thing that’s immediately attractive is that headless CMSs can offer high-quality user experiences for content creators using the system, plus it’s possible in most of the current platforms to customize things like approval workflows. There’s plenty of room now for anyone who can provide a fantastic content creation and workflow experience. For whatever reason, traditional CMS UX has been something of a backwater. WordPress is probably as good as it ever gets in the old school, and while it’s capable of getting the job done these days, it’s certainly not flawless. If you doubt this, just ask a typical WordPress user how to set a paragraph within a post with a hanging indent. (Hint: there’s not actually an option for this, though you can do it if you tweak the CSS).

      Headless CMS has into its own and you can get every flavor you can imagine, except the one where you run WordPress on the front and a different headless CMS on the back (probably someone’s working on this, though it’s not clear to me what the gain from it would be).

      There are lots—probably too many—variants on the headless CMS idea, most of them recent startups but a handful of them dating back a half dozen years or so. The list assembled for this article was at 71 companies when this was prepared. The current list is over in our New World Map.

      PeakZebra will take a look at all the options that seem to have some measure of traction, but not in this article. We’ll tackle of them in turn, beginning with those that have early market share and influence.

      In this article, we’ll look at the concept and capabilities that most or all of the contendors provide, with details and screenshots coming from Contentful, which is the most widely deployed of the headless CMSs. It’s not an endorsement of Contentful in particular, just a reflection of how this service is representative.

      JAMstack and GraphQL

      To be clear, when people talk about a “modern web stack” in current parlance, they are usually referring to a site written in a JavaScript framework like Gatsbyjs or Nextjs, with content retrieved by way of a GraphQL interface. This setup is appealing for lots of reasons, but it’s not the only way to get things done and plenty of options out there support RESTful APIs.

      An early draft of this report tried to sort between offerings that support GraphQL, but it became apparent that practically every one of the services we were looking at were adding support for GraphQL so fast that it was pointless to make the distinction. The problem for organizations looking to adopt a headless CMS strategy is going to be having too many choices. Most of them seem likely to use GraphQL, which will still leave them having to choose between dozens of CMS services.

      Contentful is one of the founding companies in this space, having released it’s first beta in 2013. The focus then was on delivering content from one source to multiple targets and frameworks. Obviously, that remains part of the headless CMS value proposition, but the emphasis has shifted over the years towards fitting into the JAMstack ecosystem. According to a TechCrunch article back in June (when Contentful raised $80 million in Series E venture funding), 28% of the Fortune 500 use Contentful. This kind of penetration makes them a heavy hitter in this space.

      In terms of how the service works: once you’ve established an account (and they have a free account option for dabblers and zebras), you create one or more “spaces,” within which you create content types. From a developer point of view, this is the equivalent of defining a “struct” variable type in C or, roughly, of creating a class in JavaScript. From the database point of view, it’s the equivalent of defining the fields in a table (and, of course, that’s what’s going on behind the scenes in Contentful).

      For the straight-up, no-frills blog application, you’ll create a content type that spells out the data that’s stored in a post. You’ll want a title, might want to be able to store a user-specified slug name, no doubt will want a publishing date, and will need a bunch of text for the body of the entry.

      An important difference between defining a database table and creating content types in Contentful is that content types may wind up defining something that you’d do with multiple tables in a SQL database. In the example workspace that Contentful gins up for you when you create an account, you have a set of content types for a learning site, with lessons and courses that include lessons, and so on. In this scheme, there’s a content type for Categories, containing two fields, as shown in Contentful’s interface here:

      The JSON preview tab here shows you what you’ll get if you do a meta query to get a description of what I think of as the table definition (though content types don’t talk about it that way). The sidebar tab is interesting: it lets you configure what widgets will populate the right rail when your users are editing this type of content. The entry editors tab lets you replace the editor itself.

      So the page where users will enter and edit your content has a main window for the editing and a right sidebar, like this:

      It looks, in fact, rather like the back end of WordPress. I’m not sure whether that’s because this is the way this sort of editor page tends to look, or whether it’s because Contentful made a conscious choice to make something WordPress refugees would be familiar with (which would have been, honestly, a smart product design choice).

      Two things to note here:

      1. Remember that you can define lots of different content types and arbitrarily change out the tools available as well as the editor used for those types. There’s enormous underlying flexibility, in other words.
      2. Funnily, this actually looks like what’s now called the “Classic” WordPress interface. The new Gutenberg UI in WordPress is based on the idea of serially adding blocks of various types. Gutenberg, in turn, is arguably running a bit behind the design principles of the popular add-on theme/editing tools in the WordPress ecosystem, like Divi and Elementor. They have both the concept of blocks and support for (within limits) dragging and dropping them. Furthermore, they are WYSIWYG. My point here is that Contentful, along with lots of other headless CMSs, has a fairly blog-centric notion of how to build content.

      To summarize, a headless CMS lets developers set up specific types of content (the rough equivalent, in WordPress, of creating new page template types) and provides a non-developer, end-user interface for creating and editing instances of those content types. Differentiation among the services revolves mostly around support for things like role-based access and editorial workflows.

      Following along on this “blog-centric” idea, note that non-CMS online services like Coda, which offer a sort of document-meets-spreadsheet authoring environment, may provide a model for what the CMS will become. Here’s a sample page I edited by dragging objects like the embedded table around the page:

      Coda seems to understand the possibility here—they allow you to present Coda documents as web pages. And yes, there’s an API if you want developer access to those pages (RESTful, not GraphQL). You can see how the headless CMS and the “document+formulas” will begin to overlap in interesting ways.

      Pricing for headless CMS varies widely, but seems to tend toward $500/month for business-level use. Most have free options for getting your feet wet or supporting personal blogs and the like.

      The Down Side?

      Based on numerous reviews on services like G2, discussions on Discord channels, and tweets, there certainly are some potential pitfalls in the headless CMS model:

      1. Some see the learning curve as steep. I suspect that’s not true if you’re coming from immersion in React, but is probably absolutely on the mark if you’re coming into the JAMstack world cold. Even if developers have to pick up some new skills in, say, GraphQL, once they’ve got the basics sorted out, the approach is no harder (and is arguably easier) than using RESTful approaches or old-school SDKs.
      2. Speaking of SDKs, some headless CMSs offer them and they sometimes don’t match the functionality of the GraphQL interface (or the interface of other SDKs for other channels within the same service). This may be the sticking point for adoption of CMSs that can’t get this problem sorted.
      3. Some services make it awkward to use one content type within another as content is created. In other words, this isn’t an issue where it’s hard to have a content type defined as containing or referring to another content type as developers create the type. Rather, it’s reportedly hard or involves too many steps to embed a video type (to take one example) inside a text blog post. This is actually one area where the block approach of the WordPress Gutenberg editor works with a satisfying simplicity.
      4. The CMS service becomes separate cost. Whether this ultimately matters is a function of whether you could previously get by with a no-frills WordPress site running on a third-party hosting service. In that scenario, you get a lot accomplished with one monthly fee. Once you get fancier than that, though, the costs may be allocated differently, but are likely to be the same or lower overall.

      If you are a JAMstack purist, your approach is not just to have a headless CMS, but to have all manner of capabilities delivered by way API connections to third-party services. The difference between headless CMS and all the other possibilities (such as search functions, comment providers, authorization services and so on) is that the other services are invoked from the live, running site. The headless CMS, though, is a sort of integrated development environment (IDE) for content, used to create what is essentially the content source code for a site. My view is that the “pre-compile” nature of the headless CMS means that some interesting potential capabilities that could be provided, but I’ll save these for a subsequent post.

      You can’t swing a JavaScript developer without hitting a headless CMS. It’s heartening how the churn of creativity has presented so many takes on almost all the pieces of the JAMstack ecosystem. But probably some kind of rough consensus about actual JAMstack stacks will need to emerge before more complex systems can be routine achievements. What’s interesting about the CMS, though, is that it has a fairly large interface component and, as such, might serve as a center point for building future web presences. That is, it may not be so much about choosing your SSG wisely, but choosing your content system wisely and then hanging other capabilities around it. In any case, businesses should almost certainly spend more time choosing the CMS service than they currently do, because what your CMS will do will, more than ever, determine what your website can do.

    4. CMS Market Share

      To hear some people talk, you’d think WordPress was in some danger of being rapidly overtaken by JAMstack alternatives (though it’s not entirely clear that JAMstack is the right thing to call them). It’s good self-discipline to periodically take a look at the relative CMS market share among current competitors, where it’s true that WordPress is losing market share over the past six months, and furthermore true that Gatsbyjs (the leader among the more recognized JAMstack frameworks) has gained market share in that same time period. But, to paraphrase an old saying, WordPress has lost more sites in a month than Gatsbyjs has ever had.

      According to whatcms.org, WordPress has 335 of the top 1000 Alexa-ranked sites. That’s down 6.37 percent from mid July 2020. Overall, WordPress has 30% of the CMS market share on the web.

      Gatsbyjs, in contrast, has .146 percent market share. Less than two-tenths of a percent. It runs on 49 of the top 1000 Alexa-ranked sites, which is up 33% over six months. The trend is definitely up, but to my earlier point, a bad run for WordPress may drop them 7% overall, but that relatively small loss for WordPress is 16 times more sites than Gatsbyjs has at all.

      Top CMS market share holders at whatCMS

      Jekyll comes in at a quarter of the penetration of Gatsby. Other JAMstack frameworks don’t turn up at all in WhatCMS’s tracking.

      It’s all kind of humbling, from a “modern web stack” point of view.

      On the other hand, things change quickly, stunningly quickly, in the internet world. It was only twelve years ago that CompuServe, the predominant “online service” prior to widespread public internet adoption, was shuttered. I suspect that the current generation of JavaScript developers mostly have no idea what CompuServe was (whatever it was, being online cost seven bucks an hour back then, at 28k baud).

      Things change quickly, and it certainly feels like the underlying assumptions of web applications have shifted. Websites are coded using CSS-enhancing template tools, clients are React while back-ends tend toward Node.js, data is represented in JSON, services are decoupled and delivered by way of APIs.

      You can tackle a JavaScript and APIs approach in a number of ways, but the cleanest and fastest really does seem to be JAMstack. I don’t think JAMstack fully meets the marketplace that WordPress serves yet, but in time it will. As more developers and agencies come up to speed on JAMstack, the world’s new projects will be JAMstack projects, or whatever JAMstack morphs into as it moves forward. This is good for website and content developers (and their roles will move closer together, at least in the technology space), but is probably going to be tumultuous for the companies that live in the JAMstack ecosystem. But that’s OK, it’ll be interesting.