Startup Team Working

Which Website Builder Should I Use? (Part 1)

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.

It will help to understand this post if you have already read last week’s post “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 each website.


Websites get structure from HTML files

Underneath everything else, every website is composed of HTML

The first category isn’t strictly what you might think of as a website builder, but I’m starting here because this is the baseline. Underneath the beautiful facade of any website design, websites are constructed with HTML documents, styled using CSS stylesheets (delineating fonts, colors, backgrounds, margins, and other styles that make everything look nice), and given dynamic features through JavaScript. If you know how to write HTML and CSS, this may be what you start off doing to build a website. It certainly has some advantages, chief among them the speed at which such a website can be built and with which it will perform if you follow good design practices. But it also has some disadvantages. In particular, using raw HTML/CSS means that your structure (or theme) is deeply enmeshed with your content. To use the house analogy we’ve referenced before, it’s a bit like having a home in which all of the furniture is built-in: instead of a couch, you have a built-in bench, instead of a kitchen table, a built-in island, etc. Such a design could be beautiful and if you are a craftsman reasonably maintainable. But if you are not a craftsman or if your tastes ever dramatically change, it may be difficult to re-arrange this house. Likewise, a raw HTML/CSS website can only be updated by rewriting the HTML/CSS. If you know how, that may be fine, but if you don’t any change, regardless of how small, will be a challenge. A final consideration when thinking about a raw HTML/CSS website is about the size of the project. Though there are some “templating” and import/include options now available for HTML, often involving using JavaScript libraries, basic HTML/CSS doesn’t allow you to easily re-use elements, whether they be “content” elements or “structural/design” ones, across pages. As a result, each page needs to be “complete” from top to bottom, meaning that common elements such as headers or footers have to be manually kept up-to-date with one another across every page on your website. For a small site, this may not be a problem, but for a large/rapidly growing one it could be a huge amount of extra work.


  • Can be fast to build if you know HTML/CSS
  • Very fast performance because no application needs to run on the server to generate files
  • Maximum control over every detail of design


  • Requires knowing HTML/CSS well
  • Requires access to server to upload files and knowledge of how to use tools like FTP to do so
  • Content and Theme tightly melded together, meaning any changes to either often requires adjusting both
  • Templating is often limited and each page must be created separately and updated to stay in sync with other pages
  • Content blocks cannot be re-used across multiple pages
  • All functionality has to be coded in
  • All future updates require knowledge of HTML/CSS

Desktop Website Builder Programs

Screenshot of Google Web Designer, a desktop website builder. Credit: Linux Screenshots

Screenshot of Google Web Designer, a desktop website builder. Credit: Linux Screenshots

Raw HTML/CSS websites are generally built “locally,” meaning that the designer/developer writes the code for the site in a text-editor on their laptop and then uploads the completed files to the server. This is generally faster than working directly on the server itself (even a fast server experiences some delay time in responding), safer (you can test your changes before they are live), and allows you to work in a more familiar environment. So the natural next step from writing raw HTML/CSS is to use a program installed on your local computer that lets you visually design a website and exports the HTML/CSS for you to upload to the server. The most famous example of such a website builder is Adobe Dreamweaver, but plenty of other options exist (including this free option from Google, still in beta, but worth checking out). This type of website builder can give you some of the same advantages that a raw HTML/CSS site would, such as website performance, if used properly, without requiring any code editing. But that “used properly” caveat is important. Though easier to use than writing code these programs often do have a significant learning curve and can easily be used to create a heavy, bloated site that will perform poorly. They may also produce “code bloat,” or extraneous code output in the files either carrying lots of references to the builder itself or creating a structural shell that’s more complicated than it needs to be. It’s also worth noting that though this type of website builder makes it easier to edit content for non-coders than a raw HTML/CSS site would, it still tightly enmeshes your content with the overall design, or theme, of your site. This means that should you ever decide to do a significant overhaul of the design theme, you’ll have a much more difficult time transporting your content (such as the text and images on your pages or blog posts) over to your new design than you would if they were truly separated. This results in some similar issues to what we noted in a raw HTML/CSS site: you may not be able to re-use or share components across pages easily and may need to keep all your pages in sync with one another manually (though some apps, such as Dreamweaver, do offer templating features that mitigate much of these concerns). Finally, though many of these desktop design apps have lots of basic functionality, like blogging or contact forms, built into what they can generate, they are often “feature-limited.” This isn’t to say that you can’t do things they don’t have built in: since they are generating code output files for you, you could always add more features into those output files directly. But it does mean that if you need features they don’t have available, you’ll have to know how to code them in yourself.


  • Doesn’t require knowledge of HTML/CSS
  • If used properly, can generate a very fast performing website
  • Visual tools make it easy to see what you are designing


  • Can carry a significant learning curve, making them cumbersome to work with for beginners
  • Most of the major options are proprietary, so there will generally be a cost to purchase the software and may be ongoing subscription/upgrade costs
  • Requires access to server to upload files and knowledge of how to use tools like FTP to do so
  • Content and Theme tightly melded together, meaning bringing over content into a significant redesign can be challenging
  • Sometimes output contains extraneous code, resulting in bloat that could slow down your website
  • Templating may be limited, meaning each page may need to be created separately and updated manually to stay in sync with other pages
  • Often cannot re-use content blocks across multiple pages
  • Often limited in functionality and/or require ability to code in extra features you want in your website, such as animations or dynamic elements

Traditional Content Management Systems

WordPress Dashboard Screenshot

A screenshot of the WordPress post editing dashboard. WordPress is the most popular traditional Content Management System

Both types of website builders we’ve discussed so far involve designing, building, and editing your website on your local laptop or desktop and uploading the code files for the site to your server. Traditional Content Management Systems (or CMSs) do things a little differently: they let you work right on the server without having to edit code. A CMS takes a very different approach to website building by creating a full separation between content and design/theme. Usually, this means that your content is stored in a database of some kind while the design or theme is coded using a templating language that lets the website drop the proper content into the right spaces. This works kind-of like running a mail-merge to produce a form letter. If you’ve ever done this, you know that to run a mail-merge you use a spreadsheet to store all the information being “merged,” like the recipients names, addresses, and perhaps some personal notes to be included. Then in your master document, you create merge tags representing the places where that information is going to be inserted. When you run the merge, the data from the spreadsheet gets dropped into the proper places in the template, generated customized letters for each person on your list. In our house analogy, this is more like having your furniture be actually separate items from the architecture of your house. You can move your furniture pieces from room to room, take them to another house, or replace them with new pieces all without touching the floor plan. Likewise, you could move to a new house and bring your same furniture in without needing to replace all the pieces. In a traditional CMS, this sort of separation is accomplished by storing your content in a database and inserting the content into templates to generate each individual page. You login into an administrative control panel where you can update your content, such as text and images, in a format that looks much like typing into a word document. You can also choose a “theme” from within this control panel, and often can preview how your content will fit into multiple themes before deciding which to install. Then the CMS does the work of generating each page, fitting the content into the proper spaces within the theme or template. This has serious advantages for sites that contain a lot of information, especially if any of that information takes the form of a “archive,” such as a blog. Most CMS solutions also offer a large network of “plugins” or “add-ons” that let you easily extend their functionality without needing to code in the extra features you want. These may let you add new “content types,” such as calendar events, or do new things with your content, such as displaying it in multiple places or multiple ways. These features all build on that same basic concept of separating content from design, using the flexibility this allows to add a lot of functionality with relatively little developer work. Of course, the ease of movement this separation between content and theme affords does come with a trade-off: your server now needs to run the CMS application and use it to generate each page on your site, which can slow down its performance (though with a well-tuned CMS, it shouldn’t be very noticeable). You may also now need to manage software/plugin updates and, because an active application is running on the server, may need to take some extra security considerations that a “static” HTML/CSS site would not need. But these extra considerations may be worth the trade: most of the time the update process is very easy and many hosting companies will assist you with both updates and security. This may have something to do with the incredible popularity of CMS platforms. The most famous option in this space is WordPress, which on its own powers over 26% of the web at last count. Plenty of other options exist, both open source and proprietary. Some notable ones are: Joomla, Drupal, ExpressionEngine, and CraftCMS, with new options emerging all the time.


  • Separation of Content and Theme using database makes it easy to change both independently of one another
  • Templating allows multiple pages to use the same design/layout easily or share specific components (such as header/footer)
  • Friendly, easy-to-use website dashboard lets you easily edit content and manage your site without editing code
  • After initial install, doesn’t require any direct access to server configuration or file system
  • Functionality can usually be extended through plugins without needing to know code


  • Can suffer a performance lag because of application processing time (but often are very fast and/or can take advantage of caching)
  • May require some additional maintenance, for example: staying on top of software/plugin updates and adding new users to the administrative dashboard
  • Because application is running on server, may require additional security measures

Conclusion (for now)

Next week we are going to consider three newer additions to the world of website builders: drag-and-drop CMS platforms, static site generators, and headless CMSs. These new options extend the concepts of the three we’ve considered here. With that said, it’s worth acknowledging a clear bias that we have in our analysis: we strongly prefer systems that separate content from design. We believe that the “portability” that this separation allows is a huge advantage over other offerings, especially for sites that contain a lot of content or are likely to stay active and be actively updated for a long time. So of the three types of website builders we’ve considered this week, our winner every time will be a traditional Content Management System, such as WordPress or CraftCMS. More to come soon…

Posted in Church Technology, NonProfit Technology, Product Reviews and Recommendations, Tech For Good, Technology for Public Service and tagged , , , .

There is one comment

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