Show HN: Sparktype – a CMS and SSG that runs entirely in the browser

app.sparktype.org

45 points by mattkevan 6 days ago

Hi HN,

After trying to teach a non-technical friend how to manage a Jekyll site I decided there must be a way to make building a site with a SSG easier. Options like Decap, Contentful etc. do make it a bit easier but still take lots of tech knowledge to set up.

So I built Sparktype, a browser-based CMS that outputs statically-generated HTML and CSS. My goal is for it to be as easy to use as Substack or Medium, while providing all the benefits of a static site generator including openness, simplicity, speed, security and ownership.

It handles most things that you'd need from a CMS, including creating pages, image resizing, menu management, tags, collections, listings etc. I've only made two themes so far, but I'm working on a theme store and the ability to import custom themes.

Content is saved as plain Markdown + YAML frontmatter and JSON config files, so there's no lock-in and content is easily portable to other platforms. Generated sites can be exported as a zip file to upload via FTP, committed to Github or published via Netlify API.

I'm working on cross-platform client apps using Tauri which will enable more publishing options as its not limited by what can be done in a client-only environment.

The way the system works means that the Web doesn't need to be the only interface to the content - here's a simple Go-based CLI client that bypasses the HTML altogether https://github.com/sparktype-project/sparktype/tree/main/st-...

It's very early days and there are still plenty of bugs, but I'm posting now to hopefully get feedback and see what people think. Please do let me know!

lenova - a day ago

I love this idea. There are so many use-cases where friends or clients need a simple interface for building a quick wiki-style documentation site. I've often suggested static site generators desktop apps like Publii to them before, but even that can be a bit on the heavy-side in terms of their requirements.

First feature request: auto light/dark theme adjustment.

First bug report: when I tried adding authentication to a test site, I received this error:

  Failed to enable protection: Failed to execute 'atob' on 'Window': The string to be decoded is not correctly encoded.

Keep up the good work!

mattkevan - a day ago

Thanks for the bug report! Will take a look at that.

dmje - a day ago

This could be cool but it’s hard to tell - mobile just doesn’t seem to work and I’m going to guess that’s most people’s first touchpoint with it?

Will try on laptop later…

mattkevan - a day ago

Thanks, will take a look at why it’s not working. There’s no reason why it shouldn’t!

ngc6677 - a day ago

Excellent idea!

Really cool that it respects the SSG conventions and separation of content, collections, templates, themes etc.

fleahunter - a day ago

Interesting point about the separation of content and templates. I’ve noticed that’s a common pain point with a lot of CMSs—people get so tangled in the setup that they forget what they were really trying to create in the first place. Your approach sounds refreshing, especially for non-tech folks. Reminds me of when I was trying to get my parents to start a blog, and it just became a mess because the tools were too complicated—like, all they wanted to do was share their recipes!
I wonder if you've thought about how to handle scalability? Like, as people start using Sparktype more, handling larger sites or more complex content structures could get tricky. Also, exporting directly to platforms like Github or Netlify is a nice touch; it’s great that you’re thinking about portability too. That feels really important in today's landscape where lock-in can be a real risk.
And I'm curious, how do you envision the theme store evolving? I think that could play a big role in adoption—if users can easily find or customize themes, it might really lower the barrier to entry. Exciting stuff, looking forward to seeing how it develops!
- mattkevan - a day ago
  
  Thanks for your comments, I appreciate it!
  Yes a core part of what I’ve tried to do is separate content from presentation. This all started by trying to build an alt-protocol like Gemini or Gopher as a minimal writing and publishing experience. I realised that for it to be useful it needed to be accessible by browsers, so I added the SSG layer. But it still publishes the source content and config alongside the HTML. This means sites can be accessed by more than just browsers - as an experiment I made a CLI client that parses the source directly.
  Themes can be imported via a URL or as a zip file and are pretty similar to Jekyll or 11ty themes. My next task is to port a bunch of them over. I’m also planning to create ready-configured template sites that users can copy and configure. Maybe take an Astro or Ghost approach, with a mix of free and paid themes.

opengrass - a day ago

I like it. How are netlify and Github credentials stored across re-visit? Also no ftp in publishing.

mattkevan - a day ago

Hey thanks! Secrets are stored in the browser cache but not exported, so they’ll persist until the cache is cleared. If you open the site in a new browser you’ll need to re-enter the credentials.
I found I wasn’t able to add FTP support without some sort of proxy service. However I am working on wrapping it into a native Tauri app. This will have more publishing options as it’s not so constrained by what you can do in a browser.