Let me bump this topic with some new insight and challenges.
As you may know, I’ve primarily been working on Space Lua recently. The deeper I go with it, the more I convinced that this is The Way. I believe that deeply leveraging Lua will give us more elegant and powerful alternatives to a few things we currently have in SilverBullet.
Specifically, I think it can replace the following things:
- Query blocks and query language
- Template blocks and template language
- Expression language
- Templates (such as to create snippets, live template widgets, perhaps new page templates)
- Space Script
- Some use cases for Plugs
So pretty much all the power user features that SB offers.
If I would have known or realized what I could do with Lua, I would not have built any of these features as they are, and would have built Lua equivalents instead. But, here we are.
This has happened before.
Old timers may remember that in earlier SilverBullet versions had a whole lot more things built in. All the snippets like /h1 etc were all hard coded before. I then invented the whole templates with hooks mechanism and was able to delete a whole lot of builtin functionality and moved them into libraries.
That was pretty great, but also meant people had to do some migration work to move from one system to the next.
With a move to fully leverage Lua, we may face a similar if not bigger migration challenge.
What would be the nicest for me, would be to simply rip the bandaid:
- Finish up the missing pieces of all the “new ways”
- Simply delete the old mechanisms
- Live happily ever after
But this would be rather brutal to the community, because it would basically break everybody who used any of these SB features (like templates, queries etc.). Of course, you can pin your version and simply never upgrade, but…
A softer approach would be to deprecate the old systems, but keep them in place for some time. I’d leave the code there, but not invest much in it (as is already a little bit the case). I’d update the documentation with all the new ways, re-record the videos with the new ways, which would naturally lead to all new users simply not even realizing the old systems are still there. Then, after some amount of time, I’d release versions of SB that more and more vocally would start to warn users that they need to migrate to the New Way, and then eventually delete the old mechanisms. If people don’t want to make the effort, they could freeze their versions to an old SB release of course, but they’d never get any new stuff.
Another approach would be to attempt to automate the migration. With a lot of effort, I could write functionality that would attempt to rewrite your Query Language queries to Lua Query Language queries. That replaces query blocks with Lua expression directives. Or template blocks with Lua expression directives. A (for me) cheaper solution could be to leverage AI to do this (with some smart prompting) but that would mean that I’d have to ask everybody to pass all their content through some LLM to migrate, which many will likely not be very comfortable with.
For my sanity (code base size and maintenance) I’d really like to get to a point where eventually only one system exists and I can delete the old code, and my sense is that one system should be Lua based.
I’m bringing this up in this 1.0 thread because I think my new target for 1.0 is to make Space Lua feature complete. That means: there’s a Lua way to do all the things listed as the things to be replaced (at the top of this post). I don’t think I would immediately delete the then-legacy mechanisms, but at least “hide” them (from docs) or at least clearly mark them as deprecated.
Anyway, a bit of a train of thought update. But I’m interested in your perspectives, especially on what you think a reasonable migration path could be.
. Thanks!
Been a minute since I’ve been around, but not stopped using SB. Just a busy time in life right now… Hope everyone’s doing well.