I really don’t want to simply respond, point by point to the announcement (you know the one). It’s ugly and foolish and I just feel like I don’t want to lower myself to that.
But I also don’t want to keep people in the dark. I’d like to shine a light on my decision to leave the the RapidWeaver platform, tell people more about what I’m working on in Stacks 5, and generally just be the open, no BS, down to earth developer nerd that you’ve all known for years.
So I’d like to do an Ask Me Anything. Normally when famous sorts of people do this, they do it live – but that can be hard since we have a good chunk of users in both Germany and California – which have a large time gap between them.
So, I’ll start this off now – but we can keep it running asynchronously for a day or two. Basically until my fingers get tired.
I’ll add this question from @albertkinng that I received on Twitter.
(from the announcement)
“In 2018 we learned that YourHead had reverse-engineered RapidWeaver to add site resources to Stacks. In 2020 YourHead they subclassed more private classes to assist backwards compatibility. These latest ones, are still used by Stacks today.”
This paragraph implies “reverse-engineered” is nefarious. And that realmac was kept in the dark from a secret and learned in a surprise discovery.
So, breaking it down:
did i do anything nefarious: No.
were Site Images kept secret: No.
was it found out in a surprise discovery: No.
Let’s talk about the RW Plug-in API
The RapidWeaver Plug-In API has never had any detailed documentation. It does have framework “header-files” and a few read-me files. There is no documentation similar to Apple’s docs for their frameworks like AppKit, Obj-C, or Swift.
Like all RW plug-in devs I read the framework header-files, then make educated guesses about their functions, and do a lot of trial and error.
To be clear, this is exactly the same stuff I’d do when using Apple’s frameworks.
Is reading header files “reverse engineering”?
No. Not at all.
Did I do something nefarious or otherwise unethical?
No. This is normal development stuff. Site Images was no different from any of dozens of difficult features in Stacks.
Was this hidden or secret?
No. Site Images was a headline feature. I talked to realmac about it a ton. There was a lengthy private and public beta – lots of people used including RealMac used it for months before release.
I think that’s probably sufficient to debunk this right?
It seems clear to me that the implied meaning was purposefully different from the literal meaning – that the author hoped to imply I was doing something surprising and unethical but was actually just normal stuff.
But I’ll add a couple more – more specific details for the nerds:
Did I “decompile” RapidWeaver
No. I didn’t decompile RW.
In 17 years I have never decompiled RW.
I will never decompile RW.
That is crossing the line.
Did I “class dump” RapidWeaver
Maybe. I’m not sure.
Class dump is specifically Obj-C – so, harder to classify. There’s not that many Obj-C devs anymore. It’s a tool in the Obj-C toolbelt. I don’t use it often, but do occasionally. Like any tool it can be used for good and bad stuff. I don’t think my occasional use is anywhere near the line.
Did I say/write “reverse engineer”?
Maybe. Not that I recall. But I may have. I definitely used it colloquially to mean “it was hard to figure out” something. As in, “with no docs i had to reverse engineer this 3D printer to get it going!”
If I did write it, I assure you it was to mean something entirely boring – and that the author is well aware of that.
If you mean “what will Isaiah be able to do as an app”:
I think there’s huge potentials for new features. I’ve often given RW lists of stuff that I thought would be low hanging fruit to work on.
I can tell you that the list is long. And that I never have any shortage of new ideas – I don’t ever have writers block when it comes to apps.
:-)
But I should probably hold off on detailing exactly what stuff I hope to add. I don’t want to give away any more ideas than I already have.
Or perhaps you mean “what will users be able to do with Stacks5 that they couldn’t do before”:
In the short term our goal is simply to ship a functional app. Often apps of this size and complexity take a year or more. I’m aiming for a much shorter schedule. But that means the first versions will be as simple as they can be.
In the longer term I hope to build some things into the app that utilize the modular power of Stacks. And I think making the framework-stacks like Foundation, Foundry, etc. – I think they can become “first class citizens” with much more access to the behavior of the entire app in a much simpler way. But again, I need to stop short of giving any details – not only because I don’t want to give away my plans – but also because that’s stuff I simply haven’t had time to build yet.
@isaiah, I just want to say, for the record, while I’ve always been a fan, I really, really reached a new level of respect and admiration for you and your work with the release of Stacks v4, and the incredible tutorial videos you made to accompany that, as found at
I think I mentioned two significant things at the time, certainly for me.
1- @isaiah is a genuinely nice guy. A really good guy. There’s no ulterior motive here. You just want to help people better use RapidWeaver and maximize that potential with Stacks.
Thank you.
2-your video explaining the RapidWeaver Add-Ons folder taught me more about how RapidWeaver works than anything I’d ever seen, and what struck me most was just how lacking RealMac had been all along in explaining this, unless I first paid them a fee to watch their tutorials???
Why didn’t they teach us all this to begin with?
Or do they not actually understand their own product?
I’m looking forward to the Stacks.app. I have every confidence in you, as does 90% of the RapidWeaver community as currently constituted.
I believe that Realmac’s website creation tool was @isaiah himself, trapped inside a shell named Rapidweaver and now is free to create what he thinks is better and useful for us. Make a dent in the universe! I’ll be here supporting you.
I’m not a marketing sort of guy. I leave that stuff to other people mostly. I’m also terrible at the slick-talking sales pitch. I just wasn’t wired up to do that sort of thing.
I just try to be myself. I know it means I’m a little rough around the edges and sometimes swear more than I should – and I ramble. Sometimes a lot. About nerdy details no one cares about except me…
But hopefully you get a sense that this really is me behind the keyboard.
@isaiah With reference to the 1st version(s) of Stacks App (speaking of the “functional-and-as-simple-as-can-be-version”) I would like to ask the following questions:
Can we rest assured that the most important frameworks (Foundation 1, Foundation 6, Foundry, UiKit and Source) will work just fine with Stacks App? Until now I only know that definitely F6 (and probably Foundry) will work, but what about the others mentioned?
Is it planned to support other 3rd party Themes at some point in the future?
I assume that Stacks App won’t support any kind of Plugins – as we currently know them – like FormLoom, Pluskit etc. in the foreseeable future, right?
For me it will be important to see the social media tab included and - most important - to keep the sftp/ftp publishing feature. Will this both be included?
Yes.
This is the first question/answer of the FAQ at https://stacks5.app . Not only will framework stacks work, I expect every stack to work. The core of Stacks5 is largely unchanged from Stacks 4.
The one caveat here is that the StyledText (RTF) → HTML conversion in RW is very very old and crusty. Obviously I don’t have access to that old and crusty code, and even if I did, I think it could do with a bit of improvement. Dan mentioned to me that he thinks RW remove that code too.
So to ensure the smoothest transition – or even if you plan to stick it out with Realmac (please don’t), I would strongly urge you to move important things to MarkDown for text wherever possible. Use StyleText only for the basics, and try to avoid custom fonts and other similar styles that don’t translate well to HTML and CSS.
Yes.
But I think that’s all I should say at this point as there’s many decisions that I’ve yet to make. I don’t want to promise something that later I find impossible to deliver.
Yes and No.
In most cases using the Stacks API allows developers (like YabDab – who makes FormLoom) to build similar add-ons inside of Stacks that are more flexible because they can be combined with many other things on the same page.
If you rely on 3rd party plug-ins today you should probably stick with RW8 for now. I don’t want to speak for other devs, but think it’s safe to say that YabDab is not planning any RW9 plug-ins. And Stacks 5 has not plug-ins (at least in the first version).
Of course you know that you’ll be the first to beta-test whatever solution Mike and I come up with. ;-)
As for PlusKit: Partials inside of Stacks are already infinitely more flexible and less crashy than PlusKit’s @import could ever hope to be.
As for other basic pages like HTML and Style Text: these translate easily to simple Stacks pages with a single Stack. I’m already working some on the importer and I think importing simple things like that should be smooth.
My hope is that in the near future Stacks will be able to give the 3rd party stacks “first-class” access to a much broader set of features that had previously only been available to plug-ins: like sub-pages, theme access, project configuration, etc.
I’m not against plug-ins by any means – I love plug-ins, obviously. But Apple has made it clear that they’re moving away from plug-ins – both in macOS and what they’ll allow in the App Store. It’s much harder to build a plug-in system in swift (not impossible, but not easy).
I think from that standpoint it would be wiser, in the long view of years to come, for Stacks5.app to invest in ways of building those things using the Stacks API. A stack has no binary code bundle – so in that sense it’s probably viewed as much more secure in Apple’s eyes than a plug-in.
Thanks, Jannis. I could have been more clear. In my head, I was thinking about encrypted stacks, having read that they may fall under a separate category.
What is currently communicated by big Dan: stack add-on developers must actively do “something” to make them compatible, eg. with a converter transpile them into a Elements version.
Of course this “conversion” might be able to be done by someone else, not the actual stack add-on developer, but a 3rd party.
Encrypting the stack add-on by the developers should help.
As all this is not available by now, these are only assumptions. Maybe RW9 will never be released 😝
This reads like a user or another developer may, at their option, choose to open source a stack developer’s intellectual property and release it — for internal use or other — as a separate product on a platform not supported by the author of the stack.