The web is in the midst of a seismic shift, again. Seemingly overnight, we’ve gone from a framework of all-in-one suites to a decentralized network of functionalities that give customers and users more freedom, agility, and value. The days of companies needing to hire teams of multiple full-stack developers seem to be coming to an end, while the days of no-code/low-code solutions are just beginning.
Wait, what?
Along with the move to a new digital landscape, we in the tech world find ourselves needing to adopt new language and terms to describe the scenery. By now you’ve probably heard of “Headless.” But are you familiar with “Composable DXP?” What about “JAMStack?” What does it mean for something to be “no-code/low-code?” And what the heck is a “PBC?”
At TechGuilds we pride ourselves on keeping abreast of the cutting edge of web and marketing technology. From web-based VR/AR experiences to our AI-powered wireframe-to-code tool Kajoo, we’re always adapting. Perhaps more important, we also enjoy helping people understand these developments and what it may mean for their business.
To that end, in this post we’re presenting a glossary of new terms that you’re going to see more and more in the digital space. In other posts we’ll elaborate on some of these concepts, but we wanted to give you an overview to act as a sort of map.
Headless
“Headless” is one of the older terms in this new movement, so we’ll start there. When we in the web development world talk about “headless,” we’re usually referring to Headless CMSs. A Headless CMS is a content management system that does not have a presentation layer. Traditional CMSs DO have a presentation layer, such as Wordpress, Drupal, and Sitecore. This presentation layer renders the HTML that the end-user sees in their browser, and is provided through a server response when the user visits the website in question.
In contrast, a Headless CMS, having no presentation layer, instead provides a Content API. This API provides structured data, often in the format of a highly complex JSON object, which a Single Page Application can consume in order to display websites. However, web apps aren’t the only things that can consume content APIs - mobile apps and other kinds of apps can as well. This flexibility is one of the benefits of headless architecture.
Single Page Application
A Single Page Application, or SPA, is a type of Web App that is almost wholly written in Javascript. These days when we refer to SPAs, we tend to refer to sites created using JavaScript Frameworks, such as React, Angular, Vue, or any number of newer competitors.
SPAs dramatically change the architecture of websites. On the traditional web, websites are made up of a collection of individual pages, organized in a file structure which can be navigated through hyperlinks and URLs that reflect that file structure. However, as the name implies, single-page applications only need to load a single page, through which the SPA is loaded onto the browser. Instead of loading different pages, the SPA reconfigures the page that is presented to the user using routing logic.
This Medium article about Routing provides a succinct explanation of what a router in an SPA does: “The router will be in charge of simulating transitions between documents by watching changes on the URL. When the document is reloaded or the URL is modified somehow, it will detect that change and render the view that is associated with the new URL.”
One of the advantages of an SPA is that most can be run locally on one’s machine using Node.js, which provides the kind of javascript runtime that is used to power most modern browsers. Using Node.JS, one can rapidly develop and test SPAs.
JAMStack
JAMStack is an architectural concept for the new web that puts together Headless CMSs, SPAs, and many other services. The acronym stands for “Javascript, API, Markup.” The “Javascript” part tends to refer to Javascript Frameworks such as those mentioned in the previous section. The “API” part refers not just to the Content APIs from the “Headless” section of this article, but any number of APIs from different microservices, such as Ecommerce providers. And of course, the “Markup” part refers to front-end code, which is increasingly componentized through the use of Javascript frameworks, but is also increasingly pre-rendered on the server side through Static Site Generation.
JAMStack architecture is relatively new, but rapidly gaining in popularity. One of the key advantages of JAMStack is the lack of need for a server-heavy solution. With JAMStack, companies need only to upload their SPAs onto Content Delivery Networks (CDN), rather than server farms that they need to maintain themselves.When a user visits a traditional website, a request is sent to a server, the server thinks for a bit, then provides a response to the user with the complete page requested. In a JAMStack website, the user visits a URL, downloads the SPA into their browser from a CDN, then the SPA makes various API calls to different microservices to download the appropriate data and populate the page. Whenever the user navigates to a different part of the site, the SPA and its router make the necessary API calls to update the page with needed data.
This framework means that there isn’t one source that the user has to get everything from, nor does any source have to do page rendering and send a complete page to the user. When a user downloads an SPA to their browser, it can come with all, most, or some of the necessary page logic, depending on how much the developer wants to leave to API calls.
One technique that is becoming more popular is Static Site Generation, in which every permutation of an SPA’s routing logic is saved as fully-rendered markup. This technique splits the difference between server-side rendering and client-side rendering - instead of rendering a page each time a user makes a request to the server, or the user’s browser having to process every state change in an SPA, Static Site Generation renders all of the pages once, then provides fast-loading, mostly-to-fully-rendered “static” pages to the user.
The Edge
The Edge is a networking term that refers to the part of a networked application that is farthest from the primary hub of the network. Put another way: “Edge computing is a networking philosophy focused on bringing computing as close to the source of data as possible in order to reduce latency and bandwidth use.” This quote could be confusing. “Source of data” here means not the database that the data lives on, but where the data is when it’s being processed by an application. In traditional cloud architecture, the data is processed by an application on the server that accesses the database directly. But in JAMStack applications, the data is first retrieved from an API, brought to the user’s computer, and then is processed by an SPA. So if you have a JAMStack-architected website, “the edge” could be the user’s browser.
However, when we talk about “the edge” in regards to JAMStack these days, we’re referring to static HTML sites (meaning: pre-rendered) being served over a content delivery network. The advantage to this approach is that the user doesn’t have to wait for a server response - they’re quickly given the data they asked for from a CDN. This shift in architecture increases performance and cuts down on costs for businesses.
Composable DXP
If JAMStack brings everything together for the developer, Composable DXPs bring everything together for the business leaders and marketers.
You already may know that DXP stands for “Digital Experience Platform,” which refers to a platform such as Sitecore XP or Adobe Experience Manager. These platforms provide a host of features, including not just content management and page building/rendering, but also ecommerce, personalization, e-mail campaigns, and integration with CRMs.
For a DXP to be “composable” means that these features are not as concentrated in one place as they used to be. Due to architectural revolutions such as Headless CMSs, SPAs using Javascript Frameworks, and JAMStack, there are many more options to achieve the functionality of a DXP without the need to go to one vendor for all needed features. Each feature in a Composable DXP is called a Packaged Business Capability, or PBC.
Market research firm Gartner probably has the best definition for Composable DXP, including the context in which these technologies have arisen, as well as a marketer’s frame for understanding their usefulness.
Low Code / No Code
Low Code / No Code is a fairly self-descriptive term - it refers to solutions that can be built and deployed without the need for much programming, or any at all. This philosophy is especially relevant to Composable DXPs, which have an advantage over traditional DXPs in that they don’t necessarily require a team of in-house programmers to integrate and customize features/PBCs. If you’re looking for solutions that are configurable rather than customizable, you’re looking for something low code/no code.
Kajoo
Kajoo is a product in development by TechGuilds that utilizes Low Code / No Code principles to help marketers, designers, and developers create high-quality Javascript Framework code for deployment in Single-Page Applications. Using AI, Kajoo can take a hand-drawn sketch of a web component and turn it into functional, ready-to-deploy React code. This code can then be published by Kajoo to a GitHub repo, or directly to a Sitecore instance for use in a JSS application. Kajoo also automates integration with the body of the headless CMS to create a deployment workflow that even non-developers can master.
We believe Kajoo will fill a missing piece in the developing picture of the new web - namely, as an easy-to-use builder for a website’s presentation layer. Right now the biggest drawback to Headless CMSs, JAMStack, and Composable DXPs is that you still need to have a team of developers who know how to create a Javascript Framework SPA more or less from scratch. Kajoo offers maximum configurability for creating components, mapping data, and styling.