Plugin Architecture

[akbsteam]

First of all, really interesting project; something I've been thinking about for a while - the notion of using a mac app to simplify the generation of deployment of static sites, so 👍👍👍

2 questions:

• the app is open source? but also available as a purchase-able download? is there a difference between the 2?

• thinking about the other generators I've used (most often Hexo), there is a plugin architecture that allows for extending in arbitrary ways; this is vital really, because use cases can vary wildly.

---

Perhaps thinking about these in tandem, the app development might be (instead or as well as) supported by a plugin/theme shop?

Some thoughts anyway, and I'm happy to look at areas where I might be able to lend some support.

[njdehoog]

Thanks! Any help would be appreciated.

The framework and command line tool are open source, but the Mac app, which is built around the framework, is not. That is the difference.

I've thought about creating a plugin architecture, and I would love to do so, but I haven't figured out a good way to do that in Swift yet, since it's a compiled language. A solution could be to have plugins be implemented in another language, like Javascript, but I don't like this kind of fragmentation. Any ideas on this?

[akbsteam]

slightly OT; have you seen this:- https://github.com/sorbetto/sorbetto

their approach is that almost everything is a plugin.

My inclination would be similar - modularise as much as possible, with frameworks containing most of the functionality which is then called by wrapper app / cli. Then for plugins, they could then access the same frameworks, and be CLI apps themselves; in the *nix way of doing things - lots of small components strung/piped together. The order of processing could be controlled by a simple draggable tableview or similar.

[njdehoog]

I hadn't seen Sorbetto before. It's interesting, because originally I went the same direction with Spelt, but at some point I realized that this abstraction where everything is a plugin only complicates the design of the static site generator, and provides few advantages in return. That's why I decided to abandon that approach and opt for a more straightforward implementation. The current design is loosely based on Jekyll's implementation, which means there are still points where plugins can easily be hooked into the generation process, but the problem lies in finding a low barrier solution to creating those plugins. Creating separate binaries for each plugin might be a solution, but then we'd have to make it really simple to create one. I think this is an interesting direction to explore, so if you want to give it a go, I'm definitely interested.

[akbsteam]

the nice thing about them being binaries, is that if they don't rely on something internal to the project (a framework for instance), they could be written in any language, not just swift.

[njdehoog]

sure, that's a nice feature. on the other hand, if the simplicity of creating a plugin is the main concern, exposing a framework for plugins would be a good idea. the two approaches are not necessarily mutually exclusive, but I would want to focus on Swift first