Which Website Builder Should I Use? Part 2: A Few More Recent Additions

A question I get asked a lot is about “website builders”, specifically, which one? There are a lot of options out there, but generally speaking they fall into a few large categories. To help you decide what you should use, we’re going to consider those categories and point out the pros and cons of each.

Just before Easter, we examined raw HTML/CSS websites, desktop website builders like Adobe Dreamweaver, and traditional Content Management Systems (CMSs) like WordPress or ExpressionEngine.

It will help to understand this post if you have already read our post from two weeks ago, “How Websites are Built: Using a House Analogy to Understand the Layers.” The analogy we used in that post will especially help you understand the different ways in which website builders approach the relationship between “theme” and “content” on a website.

Drag-And-Drop Content Management Systems

Adding a blog post to a Squarespace website. Credit: JIG Creative

Currently, the chief competition for traditional Content Management Systems in the website builder market comes from “drag-and-drop” builders like Wix, Weebly, or Squarespace. These platforms offer an easy-to-use experience, letting you create a website from scratch without needing to write any code or install any software. You can see the “blocks” you need to add to your page, where you are placing them, and edit the content “live” to see exactly how it’s going to look in relation to everything else. This makes it seem very easy for a non-coder to build a full-featured website from the ground up to their exact specifications, which is appealing, especially for a lot of small business owners. This approach has become so popular, in fact, that “drag-and-drop page builders” are beginning to crop up in the traditional CMS ecosystem, too. For example, WordPress themes such as Divi (by Elegant Themes) and plugins like Beaver Builder or SiteOrigin Page Builder are adding drag-and-drop functionality to WordPress page design.

While these solutions seem to make website building a much simpler task, there are some downsides to consider.

First and foremost, many of these options — including Wix, Weebly, and the Divi theme for WordPress — drop or blur the separation between “content” and “design” that traditional Content Management Systems enable. To reiterate our analogy from our first post, this is a bit like having a house where the furniture is built into the floor plan instead of being separate, moveable pieces. As a result, while initially building your site with a drag-and-drop website builder may be fairly simple, future updates can prove much more difficult. Since the content is “baked into” the design of the site, your content isn’t “portable,” so you either have to remodel the entire site around your content or recreate all your content in a new site. For a small or simple website, this may not be a problem, but for more complex or frequently updated sites it could prove very challenging.

Another major draw-back of some drag-and-drop builders is that they lack the ability to change styles “site-wide.” So to make your fonts consistent across every page, for example, you may need to change the font on every single element on each page manually, which can be an extremely tedious process.

Finally, some of these platforms have limited functionality. Especially with proprietary options, you can only use the “content block” types and integrations the platform makes available. To get an idea of how this might affect you, it’s worth looking at how these platforms “position” or market themselves and identifying who their target audience is. Most are clearly targeting small, local business owners. They may even get even more narrow in focus: for example, specifically targeting restaurants or hotels or local retailers. This is worth paying attention to because if you fit their target audience, the features they make available are more likely to work well for you. If you fall outside that target audience, however (or have needs outside the “norm” for that audience), you may find that the functionality they’ve built in doesn’t work for you or has to be “hacked” to make it work (kind-of). Having a clear sense of strategy before you start designing will be invaluable for evaluating whether one of these website builders will be a good fit for you.

Pros

• Visual drag-and-drop features may make design accessible to those without coding knowledge
• Proprietary platforms include hosting, so no servers to mess with or software to install
• If you fit their target audience, available functionality may be a good match

Cons

• Dropping the separation of “content” and “design” found in traditional content management systems can make revisions or redesigns difficult
• Some platforms don’t have ability to make site-wide style changes, making “consistency” in design very tedious
• Especially with paid/proprietary platforms, you may find that the functionality available is limited or doesn’t fit your use case. This is especially true if you don’t fit into their “target audience”

Static Site Generators

When we discussed raw HTML/CSS websites two weeks ago, we noted that one disadvantage had to do with “templating”: without employing some special tricks, it’s difficult to share content across multiple pages of a raw HTML website. This can make updating a website tedious. We also noted that in a raw HTML/CSS website build, the content is “baked into” the design, making significant changes to either more challenging (like it would be challenging to rearrange or swap furniture in our fictional house with all built-ins). A somewhat more recent category of website builders aims to solve both these challenges, at least for developers. These are known as “static website generators.” They allow for the separation of content from design and the easy implementation of a design “theme” or template while maintaining many of the same advantages that raw HTML/CSS sites enjoy. This is done by “generating” a raw HTML/CSS website from the combination of the chosen design template and the provided content. Often this can be done “locally” on the website designer’s laptop and uploaded to the server (though the generator may also be run on a server) . The live site on the server then acts like a raw HTML/CSS website (because it is), which means it performs very quickly and doesn’t have as many security concerns as one with a CMS application running in the background.

Content for static site generators is often written in markdown. Credit: Adityaultra

The target audience for this type of website builder is clearly developers: if you can code and feel comfortable working with a server, this type of website builder may be a dream. If the thought of either of these things scares you, static website builders on their own may not be the right fit. However, they are worth knowing about because sometimes they are what is operating in the background when working with a newer “Headless Content Management System,” which we’ll consider next. Some of the most popular examples of static site generators include Hugo and Jekyll.

Pros:

• Speed and security advantages of raw HTML/CSS
• Use of “templating” makes maintenance of an active website much easier
• Separation of “content” from “design” makes revisions to design easier and lets content be highly portable

Cons:

• Often require at least some coding and/or command-line interactions
• Content, such as page or blog-post text, may need to be written in a special format (usually “markdown”). Though this is easy to learn, it does require learning
• May require access to server to upload static files. This can often be “automated” through other services, but that may require additional technical knowledge

Headless Content Management Systems

The static site generators we just discussed are great for developers, but not as friendly to those who don’t know how to code. The most recent trend in website builders offer similar advantages to non-coders (though they may require more help from developers to set up). Headless Content Management Systems are called “headless” because they lack the visual publishing element of a traditional content management system. A traditional content management system not only manages your content, it creates the website that will display it using some sort of theme or templating system. For example, WordPress both manages your content through it’s admin dashboard and plugs that content into the appropriate places on a page using your chosen “theme.” A Headless CMS strictly manages the content, leaving the process of displaying it to some other system or application. In this case, the CMS communicates with the publishing “head” through some form of API, or Application Programing Interface, that lets another application extract the content the CMS is managing and plug it into its own templating system. This may take the form of integrating with one of the static site generators we’ve just discussed, providing the generator the content it needs to create its raw HTML/CSS output. The newly released NetlifyCMS is an example of this strategy. Increasingly, though, headless CMSs are used to talk over the web to another application or more than one application that acts as the delivery vehicle for the content. This communication often uses a language called jSON and happens through a REST API, terms you might see periodically when examining these types of website builders. If you aren’t a developer, don’t worry too much about those terms, just know that they are common mechanisms through which one application can talk to another.

Though our house analogy doesn’t perfectly work to explain this type of website builder, imagine a headless CMS as something like a moving and storage service for your furniture and belongings. It keeps everything organized in one place and lets you determine where and when it should be delivered. One advantage of this approach is that the same CMS can be used to manage the content for multiple delivery locations, such as a website, a mobile app, and a newsletter. This would be like using our storage and delivery system to move our furniture and belongings between multiple homes so that wherever we went we had it all with us.

Sounds fancy, eh?

Using a Headless CMS allows you to distribute your content to more platforms from the same application over an API, which could have huge benefits. Credit: Camwilliams96

This can be very powerful for handling web content. For example, a newspaper publisher might use this sort of system to publish articles to their website, mobile apps, and social media pages simultaneously, while letting the different platforms (app, website, social) dictate formatting, placement, and even access level (putting some content behind a paywall, while other articles may be freely available, for example). Or a museum might use this approach to manage descriptions and photo galleries about their exhibits, making short excerpts available online but longer, more detailed descriptions available in their custom mobile app available for in-person visitors.

In either of these examples, using a headless CMS means the CMS doesn’t need to be bogged down with formatting content for the different publishing locations and content authors don’t need to publish the same articles in three different apps. Instead, the headless CMS provides one place for all the content to reside and different “front-end” publishers can grab that content and fit it into their system, formatting it however they need. This takes the flexibility and portability of separating content from design to a whole new level!

Some popular headless CMSs include Contentful (proprietary), Prismic.io (proprietary), and Directus (open source). Headless, API driven approaches are also beginning to cross back over into traditional content management systems. For example, WordPress and Drupal both offer API’s to access content organized by the CMS. Even some drag-and-drop builders, like Squarespace, include API access to your content.

Though this approach offers a great deal of power and potential, it’s still early days and many of these CMSs lack some of the features available in a traditional CMS. For example, they may not have access to the wealth of plugins and add-ons available for a traditional CMS like WordPress, meaning new functionality may have to be coded into the front-end “head,” whether that be a website or mobile app. Even for those traditional CMSs that offer a “headless” mode, many of their standard functions or the functions offered by their plugins may not be accessible over the API, making them seem feature limited compared to their “standard” mode cousin. This means that often you will need a developer to get you set up, coding in the custom functions you need for your website/app, even if managing the content for each of your delivery platforms becomes easier thanks to having a single, intuitive CMS admin panel. This limitation aside, we think this approach has much to commend it and believe it may be the wave of the future.

Pros

• The portability of content separated from design is amplified by a headless, API-driven model, letting content be cross-posted across multiple apps, websites, and social platforms simultaneously
• “Front End” themes, apps, and other delivery platforms can be light weight (because they don’t have to contain all the content) but still have access to all the content at speeds rivaling raw HTML/CSS
• Easy editing interface means content creators and editors don’t need to know how to code

Cons

• Not (yet) as feature-rich as traditional CMS’s, but those features can be coded into front-end publishing locations by a developer

Conclusion

We’ve now covered six major types of website builders: raw HTML/CSS sites, desktop website builder programs, traditional content management systems, drag-and-drop website builders, static site generators, and headless content management systems. Each of these categories has unique pros and cons, and each can work in the right situation for the right user.

In general, we highly value the separation of content from design. This separation makes ongoing maintenance and future redesigns significantly easier. It also grants you a high degree of flexibility in the formatting and delivery of your content. We think the value of this separation outweighs the potential “ease of use” offered by other kinds of website builders (in fact, we think it usually renders that “ease of use” a deceptive, ultimately unfulfilled promise). So in general we strongly lean towards traditional content management systems, static site generators, and headless CMSs in our recommendations.

Of these, the right fit generally depends on your own skill set and the specific needs of your project. Projects with one primary publishing site — a public, mobile responsive website — are well suited to traditional content management systems or, if you are a coder, static site generators. Projects that may be well served by having multiple publication sites — such as a website and iOS, Android, or Desktop native applications — can take advantage of the extreme flexibility offered by a headless CMS. The size of your project may also play a role: traditional CMSs do not always scale well, but using a headless CMS with it’s publishing head delivered through multiple servers (or a static site generator configured to do the same) could significantly improver performance for large or high-traffic projects.

With any of these options, there are countless possibilities available to you. Let us know what you plan to build.