Got this concern several times today 
so I’m going to reply it here.
I don’t think that the functionality I’m tapping into will significantly change any time soon, and here’s why:
-
First of all, I’m only hooking up into places that look like stable API.
I.e., I’m not triggering anyF.x(e, n, c)that would randomize on every weekly build — I’m triggering what looks like fairly mature and well-designed public interface:— i.e. I don’t think
getCanvasGrids()oraddColumn, or function parameters, or object fields will get changed in the coming few years. -
And one of the reasons why I think they won’t get changed: Coda just recently rewrote their editor code when they introduced page columns. So I don’t see why they should still be unhappy with this part of the code and want to touch it any time soon.
-
Lastly, observing Coda for the last 4 years, I can’t see them putting time into changing any of it now. There have to be massive reasons to do that, on the brink of inability to make new features unless this code is rewritten. Which is very very unlikely. What I see Coda doing is doubling down on making new features, incorporating smaller fixes. The big topics will be AI and a better permission system (page-level sharing and stuff). But none of these will conceptually affect what, functions like addColumn? Pfft
So the only way how I see this breaking is that Coda engineers decide to break it just in spite But I haven’t been bad to them, so why would they do that? Remember we’re all still using the hidden formulas even in our production docs. Sure, Coda doesn’t endorse these, but they don’t deliberately break them either, and they only removed a few hidden formulas (mostly unused control-related ones like Slider() and Scale()) because they wouldn’t fit with some of the updates. And on the contrary, they made efforts to keep Button() alive, even though they could’ve just removed it. They broke it several times, yet still made efforts to restore their functionality.
There are several likes on this topic from Codans. Not sure if this comes along as approval though but I just don’t see why they should oppose this. Not encourage, of course, because a 3rd party extension is out of their control (unlike packs where they can vouch for their security model; here they cannot make any claims and would rather not take any responsibility). It is up to you to take the responsibility and install an extension from a person you can or cannot trust (i.e. me.) This is basically a q-tip situation: on the package it says don’t clean your ears with it, but everyone is still doing it at their own risk.
I agree about the ‘the whole team needs an extension’ sentiment. That’s why I foremostly thought of this as a developer tools kind of thing — something with macros for the builder but not necessarily for the whole team. But if a certain team extensively uses Coda internally (which is, IMO, still the best way to use Coda — for the internal tooling), and the extension makes it possible to build some must-have workflow, then what is the problem if everyone just installs it?