One of my long term goals is generating tauri builds on the web. E.g. click "build" and wasm cross compiles a .exe, a .app, and a .appimage which start downloading. Theres a long way to go before that's possible, but theres been pretty steady progress. Especially now that clang was compiled to wasm theres a real avenue to bootstrap everything.
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.
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!
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.
> This all started by trying to build an alt-protocol like Gemini or Gopher as a minimal writing and publishing experience.
I took the briefest of looks at the Gopher/Gemini/alt-publishing scene and found it interesting (though I went no further than surface level research). I'd be interested in hearing more about where this experimentation took you!
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.
One of my long term goals is generating tauri builds on the web. E.g. click "build" and wasm cross compiles a .exe, a .app, and a .appimage which start downloading. Theres a long way to go before that's possible, but theres been pretty steady progress. Especially now that clang was compiled to wasm theres a real avenue to bootstrap everything.
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:
Keep up the good work!Thanks for the bug report! Will take a look at that.
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…
Thanks, will take a look at why it’s not working. There’s no reason why it shouldn’t!
Excellent idea!
Really cool that it respects the SSG conventions and separation of content, collections, templates, themes etc.
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!
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.
> This all started by trying to build an alt-protocol like Gemini or Gopher as a minimal writing and publishing experience.
I took the briefest of looks at the Gopher/Gemini/alt-publishing scene and found it interesting (though I went no further than surface level research). I'd be interested in hearing more about where this experimentation took you!
I like it. How are netlify and Github credentials stored across re-visit? Also no ftp in publishing.
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.
env import would be useful or some auth server that gets it.