Before building this site, I had tried a few common ways to make a website.
WordPress can do many things, but for a personal site it feels too heavy. Plugins, themes, backend maintenance, security, commercial restrictions, advertisements, and extra costs slowly pull attention away from the site itself.
Hexo can also build a static blog, but long-term maintenance brings a different kind of trouble. Themes are not always pleasant to change, and when content and page structure need to be adjusted together, it becomes one round of tinkering after another.
ByteForge Studio is not a site that wants to make money from ads.
It is closer to a place where I talk with AI at night, organize thoughts, and keep a certain order of life. The website itself is a display of belief: not noisy, not rushed, and not turning every corner into a traffic entrance.
Why Astro
What attracts me most about Astro is that it is simple enough while still leaving freedom.
It can write Markdown, and it can also write components. When I want to write an article, the content can stay quiet. When I want to build a page, I can put it together slowly with components.
For ByteForge Studio, this matters.
Because this site is not only a blog.
It has journals, technical records, project archives, and an asset library. Each kind of content needs a slightly different structure, but the system should not become so complex that it can only be maintained while coding.
Astro sits in a comfortable position:
- Pages can be statically generated, so they load quickly.
- Content can stay in Markdown, so it is easy to move later.
- Components can be controlled directly, without being locked into a theme.
- There is no heavy backend that has to keep running all the time.
It is not the flashiest option, and that is exactly why it fits ByteForge Studio.
Why Decap CMS
Markdown alone is certainly possible.
But when writing for a long time, if every article requires opening the editor, finding the file, and remembering the fields by hand, writing itself becomes less smooth.
Decap CMS does not turn the site into a complicated backend. It simply gives Markdown a form that is easier to fill in.
For example, an article needs:
- title
- date
- cover
- intro
- tags
- series
- recommendation level
If all of these fields depend on hand-written frontmatter, something will eventually be missed. With the CMS, each new piece of content has a stable entrance.
The backend here is not for managing other people.
It is for spending less of my own attention.
Why the Sections Are Split This Way
ByteForge Studio now has four core content areas.
Journal is the entrance for life and observation. It does not have to be technical, but it keeps the state of a moment.
Tech is the part that other people may also be able to reference. It records the site, tools, workflows, and the actual paths taken.
Projects is more like a display case. It keeps the status, change log, and technical route of each project.
Assets is not a hidden image folder inside the code. It brings the images, covers, and resources used by the site into the open, with source notes. If someone sees an image, they should not have to inspect the page code to understand where it came from.
These sections are not here to make the site look rich.
They exist so each kind of content has a proper place.
In the word 位矩, what matters most to me is order.
Content has a place. Assets have sources. Projects have records. Thoughts have somewhere to settle.
Why Images Need Their Own Workflow
This site will probably contain many screenshots later.
Screenshots have several problems: files can become large, formats are inconsistent, and copyright/source notes still need to be clear. If every original image is placed directly into the repository, the site will become heavier over time.
So future images should preferably use WebP, together with object storage such as R2.
The ideal state is:
- Home and list pages load only thumbnails.
- Article bodies load display-size images.
- Original images open only when someone wants to inspect details.
- Asset pages explain source and license.
This protects loading speed, copyright clarity, and long-term maintenance at the same time.
What worries me is not whether images can be uploaded.
The real worries are traffic, copyright, and slow loading. These three problems tend to appear together once the site has more content.
What This Site Wants to Become
ByteForge Studio is closer to a personal technical information site.
It can show technical work and also record life. It can keep projects and assets. Later, it may even organize subscribed videos and viewing notes inside the site.
But it should not become an advertising wall.
It should not chase trends by writing things I do not truly care about.
It should keep a night-like state: quiet, ordered, and lit by a small amount of light.
Technology is only the skeleton.
What should remain is how one person organizes information, projects, and life.
