The Website Development Tools I Use to Build Static Sites

I am not a designer, per se. I enjoy art and design as a hobby, and web and graphic design give me a way to relax while still building something useful. The sites I build combine both sides of that interest. Working with different technologies keeps my development skills sharp and reinforces something I have come to believe: the best way to learn a technology is to apply it to a real project.

That combination has also taught me that a useful list of website development tools is not really about finding one application that does everything. It is about choosing a tool for each stage and making sure the output from one stage works cleanly in the next.

My static-site workflow has five parts: sketch the design, turn it into HTML and CSS, choose how the site will be generated, convert the design when that saves useful work, and keep the source in Git before publishing it.

The Short Version of My Static-Site Toolchain

Here is the stack at a glance:

Stage	Tools I consider	The decision that matters
Visual planning and assets	Inkscape or Pixelmator Pro	Do I need editable vector artwork or pixel-based image work?
HTML and CSS	Bootstrap Studio or Visual Studio Code	Do I want a visual interface or direct control over the files?
Site generation	Pelican, Hugo, Astro, Jekyll, Eleventy, or Publii	What content model, template language, and maintenance routine fit the site?
Theme conversion	Forge, when appropriate	Do I already have structured HTML that needs to become native platform templates?
Versioning and publishing	Git plus a separate host or deployment service	Can I review and recover changes before the site is deployed?

You do not need every tool in every row. In most cases, you need one clear choice per stage.

Start With the Design, Not the Generator

I usually begin by working through the visual direction before choosing templates or generator features. That could mean rough page composition, reusable shapes, a logo treatment, image crops, or a few representative layouts.

Inkscape is useful when the work is fundamentally vector-based. Its native format is SVG, which makes it a natural fit for logos, icons, diagrams, and other artwork that needs to scale cleanly.

Pixelmator Pro covers the pixel-based side of the job. That is where I would work with photographs, textures, image composition, and exported graphics with fixed dimensions.

The point is not to finish every screen in a graphics application. I want enough of the visual system settled that I am not inventing spacing, typography, colors, and component behavior while also solving the template architecture.

A useful handoff from this stage includes:

• A small set of representative page layouts
• Reusable colors, type choices, and spacing decisions
• Vector assets kept as SVG when that format makes sense
• Raster images exported at the dimensions and quality the site needs
• Notes about how layouts should adapt at smaller screen sizes

That is enough to begin coding without pretending that a static mockup answers every browser question.

Use Bootstrap Studio or VS Code for Different Kinds of Control

For the HTML and CSS stage, my choice is usually between Bootstrap Studio and Visual Studio Code.

Bootstrap Studio is built around visual editing. Its interface lets you arrange components on a stage, adjust them through visual controls, and work with the underlying HTML, CSS, JavaScript, and Sass. It can export a regular folder containing HTML, CSS, JavaScript, images, and other assets.

That works well when I want to explore a Bootstrap-based layout visually while still ending with ordinary front-end files.

VS Code is the more direct option. I use an editor when the file structure already makes sense, when I need tighter control over the markup, or when visual controls would slow down a code-heavy change. Its built-in Git support is also useful for reviewing file differences, staging changes, and committing without leaving the editor.

These tools overlap, but they are not the same decision. The practical question is whether the current job benefits more from visual composition or direct file-level control.

Whatever I choose, this stage should end with a complete static HTML version of the design. Navigation, repeated content, page layouts, asset paths, and responsive behavior should be understandable before generator syntax is introduced.

Choose a Static-Site Generator From the Maintenance Job

A static-site generator takes content and templates and produces the files that a browser receives. The hard part is rarely finding one that can produce HTML. The hard part is choosing the conventions that you will still want to maintain later.

I work with or keep an eye on several options:

• Pelican is written in Python, uses Jinja2 for themes, and supports content written in Markdown or reStructuredText.
• Hugo provides its own command-line workflow, content system, and template model.
• Astro can generate static sites and also supports server-rendered approaches when a project needs them.
• Jekyll is a Ruby-based static-site generator with layouts, includes, collections, and Liquid templates.
• Eleventy supports several template languages and turns content templates into static output.
• Publii takes a desktop CMS approach, so content editing and site generation happen through an application rather than a typical command-line project.

I would not choose among them from a feature checklist alone. I would ask:

1. Who will edit the content?
2. Which language and template syntax will the maintainer understand?
3. Does the site need a conventional blog, several content collections, or mostly fixed pages?
4. How much command-line setup is acceptable?
5. Can the generated output be previewed and deployed with the hosting setup already in use?

Pelican may feel natural in a Python-oriented workflow. Hugo is a sensible candidate when its content and template conventions fit the project. Eleventy gives a JavaScript-oriented developer several template choices. Jekyll remains relevant when Ruby and Liquid match the environment. Astro belongs in the conversation when the project may need components or a path beyond fully static output. Publii is different because its desktop interface can be the deciding factor for the person maintaining content.

I do not use one generator for every site. This Aeriform blog runs on Pelican, while the Forge and ReminderBridge product sites use Hugo. My personal sites include projects built with Astro and Publii, along with another Hugo site. I used Forge to convert the structured HTML for each of these sites into templates for the appropriate target platform. That mix reflects the different history, content workflow, and maintenance needs of each site rather than a belief that one generator should handle every project. The Forge multi-engine theme development page explains the product side of using one structured HTML approach across different targets.

The best choice is the one whose routine you can explain and repeat six months later.

Where Forge Fits in This Workflow

Forge is useful after the static HTML design exists. It does not replace the design application, code editor, generator, or Git. It handles a narrower handoff between structured HTML and native platform files.

Forge uses documented data-forge-* markers to identify partials, content blocks, repeating items, bound values, and links in the source HTML. It can then create editable output for the documented WordPress, Eleventy, Hugo, Jekyll, and Pelican workflows.

For example, a navigation element marked as a partial can become the appropriate reusable file for the selected engine. A blog list marked as a loop, with one article row or card marked as its repeating item, can be mapped to that engine's template syntax.

The limitation matters: Forge does not infer every decision from arbitrary HTML, migrate a site's content or database, or remove the need to understand the target platform. Missing markers, inconsistent paths, or an absent content slot can produce incomplete output. You still need to inspect the files, run the target generator, and test the result.

That is why I place Forge after the HTML design and before final platform testing. The Forge Getting Started guide documents the source structure, sample sites, markers, and conversion sequence.

Astro and Publii are part of the broader generator landscape. Forge has dedicated implementations for an Astro theme bundle and Publii theme files, but I would not currently choose Forge based on either target. Availability in the distributed build and current target-platform validation still need confirmation. That does not prevent you from using those tools independently.

Git Is the Safety Layer, Not the Host

Once the project contains source files, templates, configuration, and content, I keep it in Git.

Git gives the project a reviewable history. I can inspect a diff before committing, isolate an experiment on a branch, and return to a known version when a change goes wrong. That is especially helpful when generated files and hand-edited files live near each other, because I can see exactly what changed.

Git is not the same thing as publishing. A remote Git service stores and shares the repository. A hosting or deployment service builds or serves the site. Some platforms connect those steps, but they remain different responsibilities.

My practical sequence is:

1. Preview the site locally.
2. Review the changed files.
3. Commit a coherent change to Git.
4. Push it to the chosen remote repository when appropriate.
5. Let the approved deployment process build and publish the site.
6. Check the live result separately.

Keeping those stages distinct makes a failed build or bad visual change easier to diagnose.

A Smaller Toolchain Is Usually Easier to Maintain

If you are starting a new static website, use the smallest version of this workflow that satisfies the project:

• Sketch the important layouts and prepare only the assets you need.
• Build clear, responsive HTML and CSS in either a visual tool or a code editor.
• Choose one generator based on the content and the person maintaining it.
• Add Forge only when converting finished HTML into an established native theme format saves meaningful manual work.
• Put the source in Git before connecting it to a publishing process.

You can change tools later. Clean HTML, organized assets, understandable templates, and version history make that change less painful.

Frequently Asked Questions

Do I need both Bootstrap Studio and VS Code?

No. Bootstrap Studio is useful when visual construction helps you work through a Bootstrap layout. VS Code is useful when you want direct control of the project files. You can use both, but a project should have a clear source of truth so changes do not get lost between them.

Do I need a static-site generator for a small website?

Not always. A handful of stable pages can remain ordinary HTML. A generator becomes more useful when layouts repeat, content grows, or several pages need the same navigation, metadata, and components.

Is Forge a static-site generator?

No. Forge converts marked, structured HTML into editable files for documented target platforms. The selected generator or WordPress then builds or runs the resulting site.

Does Git publish a website?

Git tracks versions of files and exchanges them with repositories. Publishing requires a host or deployment process, even when a platform can deploy automatically after a Git push.

What to Do Next

Start by writing down the artifact you need at the end of each stage. That one exercise will remove many tools from consideration.

If you already have a finished HTML design and need to turn it into reusable platform templates, read the Forge overview on Aeriform and then work through Forge Getting Started with a sample site. Compare the generated files with the source before trying it on your own design.