In an ideal world, Starship would run in C.

However, compatibility is important. The current build system uses a collection of primarily Python scripts to collate static blog content.

Starship v1 is completely static. However, this won't scale well long-term, so plans are to use backend indexing to organize each entry into a nearly-completely-formatted file, which will be pulled by frontend JavaScript and inserted into the post list.

I have mixed feelings about JavaScript, though.

It would make several tasks much easier:

• clipping pages to appropriate visual length
• front-end auto-loading of older entries
• various buttons and tooltips

I'm still not sure though. I still kind of want to believe in the dream of a fully static, Web 1.0 style blog which remains fully functional even with javascript disabled. But that might not be very possible without proper backend support.

Though...

Maybe if I do some cool datastructures trick I can avoid using any server-side processing at all. I think I'll group posts in either 20s or 30s, and have individual html files with each section of posts from each time period/section.

Meaning, if I mantain some sort of linked list of post summaries or formatted sectors - I can really easily push one new page to the top of the list and sometimes propagate chunks of posts down through the list. Not entirely sure at the moment.

---

Planned substructure

• index.html
• style.css
• assets/
  • pic.png
  • demo.c
  • ...
• pages/
  • 1_hello-world.html
  • 2_starship.html
  • 3_thoughts.html
  • ...
• old/
  • 1_old.html
  • 2_old.html
  • ...
• build/
  • published/
    • 1_hello-world.html
    • ...
  • drafts/
    • an-unfinished-post.html
    • private.html
    • ideas.html
    • ...
  • publish.py

The build/ directory would store drafts (which would be flagged under gitignore) as well as "published" pages. These wouldn't be entire compiled pages with the title, styling, font, etc. but rather snippets of HTML corresponding to their summarized view which would appear in the main page. Fully compiled pages would be located instead in pages/, and statically linked to by index.

Datastructure would be very useful to ensure that each publish run causes on average (or possibly: at most?) O(log n) cascades.

(It is also possible that I am way overcomplicating this, and there is no reason to need such a structure.)

A categories feature could be very nice! I will probably implement a similar cascade system for that, except one cascade-list per category, each in its own directory:

• categories/
  • programming
    • index.html
    • 1_old.html
    • 2_old.html
    • ...
  • toki pona
    • index.html
    • 1_old.html
    • ...
  • ...

Mantaining a static index.html page for each category will be imperative as category links (on the main page, from posts in said category) must be static for efficiency.

If (when?) I end up implementing this feature, it will almost definitely be in Starship v2 or later. v1 release will primarily target the following:

• single main page, no chunking
• individual full-form post links
• build dir with drafts

Chunking will be the next big feature to add I think. Then would be support for images/assets, and categories later IF I can get chunking to work reliably for the main stream.

That's enough for now. I should probably get to work.

See ya later :P