A discussion on the next steps for Sculpin

[opdavies]

Following on from this Twitter thread, I'm looking for more hands-on experience with Symfony and its components, and Sculpin is a good suggestion as it's a project that I'm familiar with and use (I used it for my personal site for a number of years, I still use it for some client static sites, and have given talks on Sculpin before at DrupalCamps and PHP meetups).

Here are some comments from @beryllium in that thread:

Sculpin needs an internal rewrite, and also might benefit from a newer implementation (internally it's based on Symfony 2), but I don't really have the energy to move it forward in that direction at the moment.

I'm quite torn on the direction to take it. Like, should it get steered toward JAMstack stuff, or should it move closer to a simpler "render these files with markdown" approach, or should it stay as it is but just get faster ... etc

As I suggested, I've started this issue to have a discussion around the next steps for the Sculpin project, and if there's anything that I can do to contribute with moving the project forward, that would be great.

[beryllium]

It'll take me a few more days to get my thoughts in order for this (plans this weekend make it difficult to concentrate on tech :) ), but a couple of early, spur-of-the-moment thoughts:

Internals

The sculpin internals are quite complex at the moment. They feel like a combination of event-driven programming and ... something else. I think this is a result of the way Sculpin is using Symfony. As I recall, it is essentially building up a list of all the files and data source providers and using that to configure a Symfony "website", and then querying each URL as though it were a web request & saving the HTML output to disk. (Again, I might be slightly wrong in the implementation details.)

This way of handling the architecture makes it a bit difficult to interject new functionality. Adding the custom output dir/source dir flags required navigating a bunch of layers of the app and it felt like a hack, for example, rather than a purposeful implementation.

I'm not sure how to solve this to make the internal flow easier to work with. It seems like the complexity is the result of the "shortcut" of trying to wrap things up into a website and then output all the pages.

The Future

I have a few ideas that I want to move forward with, but I'm unsure how to gain a foothold and kick them off. My PR for having a live editor embedded in the project seems like a useful one, but it'll need some work on the internals so that the files get saved & regenerated in a consistent way across platforms.

I also want to find some way to solve "static site hosting" when an authentication wall is required. Particularly one that can integrate with corporate authentication solutions/single-sign-on with minimal effort. A solution to this could probably be productized in some way, but I don't know if there'd be enough demand to justify even building up the architecture for a proof of concept.

And finally, the whole JAMstack concept is getting a lot of buzz, and I think Sculpin could possibly work with it - but it would require making it possible for data source providers to be fed from APIs instead of files on disk. And I'm not sure how much interest there would be. If there is something "beyond JAMstack" on the horizon, it might be better for Sculpin to look toward that target instead.

[dragonmantank]

So, I initially started dragonmantank/pamstack as a joke, but have been looking at extending this with Sculpin, and pushing out what amounts to a JAMStack layer but backed by PHP functions to Google Cloud Run.

It worked.

So now I'm actually looking at porting my site over to it, using Sculpin to generate the static files. It's mostly working, which I think is a testament to how well Sculpin works in a way.

[WyriHaximus]

Internals

The sculpin internals are quite complex at the moment. They feel like a combination of event-driven programming and ... something else. I think this is a result of the way Sculpin is using Symfony. As I recall, it is essentially building up a list of all the files and data source providers and using that to configure a Symfony "website", and then querying each URL as though it were a web request & saving the HTML output to disk. (Again, I might be slightly wrong in the implementation details.)

This has always made me wary of contributing more on a internals level of Sculpin, so if we can also address this it should be more fun to help out.