Show HN: Sparktype – a CMS and SSG that runs entirely in the browser(app.sparktype.org)

43 pointsby mattkevan6 days ago4 comments

lenova18 hours 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!
- mattkevan14 hours ago
  Thanks for the bug report! Will take a look at that.
dmjea 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…
- mattkevan14 hours ago
  Thanks, will take a look at why it’s not working. There’s no reason why it shouldn’t!
ngc6677a day ago
Excellent idea!
Really cool that it respects the SSG conventions and separation of content, collections, templates, themes etc.
- fleahunter19 hours 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!
  - mattkevan14 hours 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.
opengrassa day ago
I like it. How are netlify and Github credentials stored across re-visit? Also no ftp in publishing.
- mattkevan14 hours 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.