Spare a thought for the humble page builder. These CMS plugins allow users to easily drag and drop elements (buttons, grids, images, headers, text blocks, videos, etcetera) onto the page. Although the #webdevelopment hype machine would have us believe that headless CMSs (Strapi, Contentful, Ghost) and Static Site Generator projects or hosting platforms (Gatsby, Netlify, Vercel) comprise the marketplace’s most enticing offerings, frontend practitioners continue to find the CMS + page builder combo a valuable stack within the SDLC. Popular page builders include WordPress’s WPBakery and elementor; Shopify’s Shogun and PageFly; and Drupal’s DXPR and Stacks. Shogun also offers page builders for Magento and BigCommerce. Although they sometimes present difficulties for engineering teams, especially those taxed with modifying these plugins or theme components, page builders remain a practical, flexible, and user-friendly solution for smoothing client handoffs.
The Page Builder’s Promise & Reality
Page builders contribute to the move towards non-developer-as-user centered GUIs by treating the entire webpage as a canvas. Using a page builder I can drag a section onto my page, divide it into three side-by-side containers, and then place what amounts to a WYSIWYG in one, an image into the second, and an iframe for a YouTube video into the third. These sections are responsive, meaning that the user can elect to have containers stack vertically on smaller viewscreens (tablets and smartphones)–all without writing a line of CSS or JS. Don’t like this layout? Delete it, drag over a new layout, and start over.
Oftentimes web developers tasked with building and maintaining CMSs find page builders to be indispensable, not necessarily because they enable frontend engineers to create responsive, professional-looking websites–these could be built using vanilla JS and CSS–, but instead because they lessen post-handoff client confusion as well as the amount of requisite documentation. Web developers, especially those saddled with legacy code and older CMSs, use page builders as the best means of creating excellent digital experiences despite the sometimes older or convoluted backends upon which they are constructed.
Page building technologies fit into the larger ecosystem of no-code and low-code products which take up an increasingly large share of the webpage building market. Like more all-inclusive webpage building experiences such as Webflow (which positions itself as a “visual CMS”), Squarespace, and Wix, which also rely upon a drag-and-drop UI, what these products invariably promise is speed; or, as elementor phrases it: “Rapid development with minimum effort.” Unbound from the tyranny of interactive teams, page builders permit businesses to bypass the costly and tedious step of employing designers, UX/UI, and frontend engineers. Instead, the page builder’s prepackaged library of elements can be pulled onto the page as-is and published. Speed is certainly achieved when clients use page builder themes out of the box. However, modifying these themes is usually even more tedious than coding a design from scratch because frontend developers must reverse engineer the code to identify existing JS, CSS, Sass, Bootstrap, etcetera, and then overwrite this functionality.
If the process of modifying page builder themes is so time consuming then why use them at all? Because once it’s set up page builders allow non-engineer users to create and modify not only a website’s content (a feat achievable using WYSIWYGs in the CMS), but also its design and appearance. This makes page builders a boon to interactive teams tasked with building unique digital experiences, and then handing them off to non-technical clients. Once the frontend engineers modify these prepackaged elements to fit a design nontechnical users can mix and match these bespoke elements throughout the site.
What’s Next for Page Builders
Here at RedMonk we have been following frontend trends and website building markets for years. Although the page building market is in some respects less flashy than the Jamstack and SSGs these products are not wholly different. Gatsby offers a Starter (roughly analogous to a theme), which incorporates prebuilt templates that frontend engineers can modify. Yet the more limited page builder continues to occupy a significant portion of the market for good reason. Page builders provide a viable and affordable option for organizations unwilling or unable to update their entire stack.
Page builders have been a thriving product offering in the CMS marketplace for years. Shogun has been particularly successful in this space, raising $67.5M in its series C of funding last year, and $114.6M total after over six rounds of investments, for a total valuation of $575M. Elementor has raised a more modest $15M over two rounds of funding. Although page builders continue to play an important role in the domain of low-code frontend products, investors are betting that SSGs and hosting platforms will eventually usurp this market. In fact, it is likely Shogun’s headless commerce platform product, and not its page builder, that tempted venture capital firms like Insight Partners and Accel to support its most recent funding round.
While it might be tempting to view page builders as a transitional product positioned unhappily between a WYSIWYG and template dependent past and a fully no-code future, this is not likely to be the case. Remember that over a third of websites use WordPress–a longstanding dominance suggesting that page builders will continue to demand a place at the frontend table for years to come.
No Comments