Maybe platypub should be a desktop app

Biff
1

I’ve been thinking a lot about the right architecture for platypub, and I’m starting to think that having it be a regular web app is more trouble than it’s worth. What if it were instead a babashka program/graalvm binary that:

  • starts an http server and serves a gui interface over localhost
  • includes a rich text editor/cms in the gui, as platypub does now
  • saves posts, images, and site config to your local filesystem, similar to how people typically use static site generators
  • includes a gui for managing mailgun newsletters, as platypub does now
  • for previewing, just uses the netlify dev command, which would also serve your site over localhost, but on a different port than the platypub gui.
  • similarly, deploying can just be netlify deploy
  • has import “plugins”/scripts that fetch data from wherever and write it to the filesystem in some form (like markdown with front matter)
  • themes are just scripts that read in markdown files and config from the filesystem and spit out a rendered site in the public directory, like any static site generator. if needed, platypub can include some wrappers that make it compatible with existing static site gen themes, like Hugo themes.

in other words, platypub would be more of a thin-ish wrapper around the already common (at least among programmers) workflow of using a static site generator and deploying it to e.g. netlify. platypub would add a gui interface (including a rich text editor), newsletter tools, and perhaps some helper code/conventions around themes and import plugins e.g. to facilitate reuse. and it would be packaged up so that it’s hopefully accessible for non-programmers.

Benefits over doing platypub as a web app:

  • no need to deal with sandboxing themes and import plugins.
  • easier to develop themes and import plugins. they don’t even have to go through platypub at all.
  • storing data on the filesystem (E.g. as markdown with front matter) makes it much easier for the user to have direct access to their data. easy to migrate to/from platypub, back up to git/Dropbox, use git as a source of truth, use other programs to edit your posts…
  • very easy to “self-host” (that’s how everyone does it)
  • easy to use the netlify cli for previewing and deploying, which simplifies platypub’s code and makes it so netlify functions work during preview.

Disadvantages:

  • slightly less convenient to get started (have to install a program instead of just signing into a web app)
  • collaboration is harder if you want multiple writers on the same site (have to use git/Dropbox/etc)
  • platypub could no longer be an example app for Biff

I think the pros here quite heavily outweigh the cons. it would be good to zoom out a bit and discuss who platypub is targeted at though:

  • myself. I love vim, but not for writing blog posts. I especially want inserting images to be convenient. I also want it to be convenient to set up a newsletter to go with the site. I have multiple sites and want it to be quick to spin up a new site + newsletter. I want complete control over the structure and design for both sites and emails. I don’t want to pay a monthly fee for a site with little traffic (again, multiple sites) or deal with other unnecessary restrictions (like custom domains being a paid feature).

  • other programmers/technical people who are mostly happy with static site stuff but also want the same conveniences that I want around rich text editing/newsletters.

  • nontechnical people/people who don’t want to deal with managing static site stuff from a CLI, but still want complete control over their site/newsletter (in terms of both design and platform dependence)

People platypub probably shouldn’t be targeted towards:

  • the mainstream consumer market. The reality is that having complete control over the design doesn’t matter for most people. social media profiles all look the same for example, and it’s a non-issue. platypub is probably best as a publishing tool for power users. that also works out well since I don’t think there’s any feasible way to provide email without making users provide their own mailgun keys since I don’t have the time or energy to deal with spammers.

  • people for whom publishing is a business. there are plenty of platforms/tools for this already. better imo to focus my/our open source efforts on use cases that are underserved by the commercial market.

  • people/businesses who want a general purpose site builder/less crufty version of WordPress. pretty much the same reasons as the previous bullet point. apps that are built for businesses should generally be businesses themselves imo.

1 Like
2

I’m planning to be writing essays/howtos through the end of next month, then in November I’d like to put some time into platypub.

1 Like
3

All of this sounds Good - I hate to lose the Biff dependency since I want to use it as a tool for working with Biff also this change puts it in there with 1,000 other site generators. Maybe position it as a Biff frontend tool where you can develop themes UI etc and deploy them as a static site but also have the hooks/ability to deploy as a Biff UI/frontend if you wanted to have a CMS or maybe wanted to add other elements that required a backend – Would also be nice to allow the ability to use it as a frontend for Juxt/Site

4

Sounds a little complicated :wink:. For a website that needs a backend you can always just deploy a regular Biff app. Rather than making Platypub still work with Biff somehow, maybe what you need is a CMS plugin for Biff–something you could stick in a regular Biff app that would provide a CMS admin UI for blog posts/whatever, then in the rest of the Biff app you can pull content from XT and render it like usual.

If you’re interested in something like that, what I would do first is set up WordPress or something for use as a headless CMS and then write a Biff app that syncs data from WordPress into XT. Then if that setup feels good and you want something more integrated, you could look at writing a Biff plugin to replace WordPress.