ah… @Bill_French
i assumed you were using the itsy-bitsy server which takes the code in base64 and returns a page with your html, css & js (and you returned that as an embed).
we took the library that itsy-bitsy used and implemented on our github webserver.
but you have uncovered a deeper secret labyrinth in the coda servers…
NOW my mind is blown!
now i will lose sleep until i figure out how you did it!
max
Ok it will take me some time to fall asleep tonight thanks to @Bill_French, will definitely explore some ideas tomorrow 
Ha ha! This is exactly how I felt when I realized how simple this approach was. It’s really Codans who deserve the credit for this Itsy bitsy excursion. I was working on a full text search Pack and discovered the temporary file system - one thing led to another, and I had what could be described as the only useful Pack that is nearly as small as the Hello World Pack.
Yes, I know. And the naming of this Pack as Itsy was purely coincidental. I looked at its purpose - small, mostly simple HTML blocks of functionality and then asked the thesaurus about small things - “itsy” came right up and without hesitation chose it to be the brand for the greatest smallest functional Pack ever built. LOL
In the interest of better sleep - I shared all 80 lines of Itsy’s code to you privately.
Playing around with the pack. My first 2c:
I wouldn’t make a separate itsyPlus() formula but rather update the original itsy() one with the new behavior. It’s not that far into pack’s existence to worry about breaking existing behavior with Embed wrapping.
On reporting the data back into the Coda doc — one solution that comes to mind is webhooks. You can set up your web app to send an XHR to the hosting doc and process the payload in automations.
Yep, there it is @Bill_French & @Xyzor_Max.
Every time you press the = button on the calc, the result will be added to the table on the right:
This is actually too cool. This means one can make whatever form layouts, whatever intake fields etc and report the data into my Coda doc. No need for packs, no need for masochistic SVG tinkering, no need for Coda form trickery. This is so huge I secretly weep that I didn’t find it myself 
P.S. Holy hell, that sweet feeling when all pieces of the puzzle finally click together 
I always wanted custom widgets in Coda and I kinda knew I could just make my own web server but that didn’t feel clean enough. So the path there was:
I found the capability to render SVG in images, which was the first step to custom widgets
Then @Artem_F found the way to render HTML+CSS in those SVG, which allowed to ditch the low-level rects and leverage the powerful DOM + CSS rendering engine.
Then @Xyzor_Max made the solution with a custom web server so that interactivity could be there
Then @Bill_French found a way to ditch the 3rd party server and rock off vanilla Coda.
And finally, the recently added webhooks feature in Coda allowed to connect these widgets back into Coda.
Now literally everything is possible.
Your 2 cents is always worth many times that; appreciate it. But during inflationary times, it’s at least worth 26.5 cents. 
Thanks! I was considering that but I wondered if there were some users who still want to wrap Itsy functionality in an Embed()? No?
Bingo! Just a matter of time before this would become apparent. I think there are easily 20 more like this that have not yet dawned on us.
Indeed - this was exactly what triggered the idea. I wanted it to be ultra-simple for anyone to use. Your SVG research was also instrumental in nudging my thinking about this problem.
And that said, it’s time to suggest to Codans that the temporary file system should be able to be less temporary for certain use cases, otherwise, we be hittin’ that pack to sustain long-running refreshed web components.
There’s just one problem to explore: security.
E.g. in my example I included the API token right in the code that’s open for anyone to see. And there doesn’t seem to be a way around it. The token is set up to have write rights to the whole Coda doc, which leaves it vulnerable to bad actors. There’s no way to limit it.
Even if you somehow conceal the code in the pack, it’s still going to be served through that embed. Anyone can open developer tools and see it in plain text. The only way to not expose it is to never trigger the webhook directly but still have that separate proxy server.
BTW this didn’t have to be the webhook, it could be a direct Add Row REST API call. Could be whatever call really as long as the token is there.
P.S. This calls for a feature request: tokens that are restricted to only trigger a webhook with a certain ID.
Your example is freakin’ brilliant Paul! Simple, effective, and quite fast. Love it.
Two comments -
I’m serious about #1 - it literally took hundreds of experimental attempts and many hundreds of hours to continue to understand the pathway.
#2 I haven’t thought about much, but when Neanderthals discovered fire, they shared the discovery. Is this one of those ideas that we should all celebrate and work to improve?
I think there is away to secure apps like this. I need to noodle on it for a while. I believe the answer is a persistent file system - maybe Coda can help.
What do you mean by #2 — make the pack paid?
I could totally imagine charging some $1 or $2 / mo for it. Then, speaking of myself, I could probably re-create it, knowing the mechanism.
I would also see a thriving ecosystem of custom made widgets that would run on the itsy pack.
E.g. I would totally redo my laggy POS interface or inline calculator in HTML and return the result into my doc.
Yes. It’s tough to decide because (a) the cat’s out of the bag, and (b) would commercializing it be in the best interest of anyone, me included?
You absolutely could build this - it’s like 9 lines of code. A clever 9 lines, but still, incredibly simple. LOL I refer to it as the only Pack that is as small as Hello World! and possibly as big as the whole world.
Even so, there are many thousands of users who need this but cannot easily fabricate it, yet it is something that all Makers should have free and open access to. In case you didn’t connect the dots, this is why I asked over in Slack …
Yes, this is likely a far bigger opportunity for commerce and likely very beneficial for non-technical users. I have wondered how you would package Itsy + web components. Do you simply distribute Itsy “flavors” with bundled docs and web app code?
well done all who contributed to this journey
and yes, it is like fire, to be shared with everyone for the good of all (imho).
security:
i believe the answer is for Coda to bring this INSIDE the product, make it a native feature of CFL and thus enclose it in a safe and secure enclosure.
i hope the wise ones at Coda are listening and will do the right thing here.
respect
max
Guys this is amazing!
I’m starting to wrap my head around all the possible use cases this could unlock. The dynamic dashboards features alone has tons of potential for business application since it’s much flexible for customized reports. (Thinking about Google Data Studio visualizations here).
Also kudos for the cooperation between you all! It’s amazing to see how this all was compounding on top of each other’s discoveries and knowledge.
Thank you @Bill_French for building this platform. I’m sure it’ll be the foundation of amazing things as makers start adopting it.
PD: Thanks @Xyzor_Max for calling my attention to it. Awesome find!
My socks are on fire! Reading this thread is like watching the three musketeers perfecting their craft, it’s so inspiring!
Now, of I’ll go, trying to figure out the intricacies of Itsy and to ponder possible use cases.
@Bill_French, @Xyzor_Max and @Paul_Danyliuk, your contributions to the coda community are invaluable.
Imo you all deserve a plague on the community forum’s entrance doors - we’re all standing on your shoulders!
itsyPlus(“<h1>Hello World</h1>“)
There are no deep complexities with Itsy except the complexities of the code you decide to throw at it and your imagination.
The only [apparent] limitations of Itsy are those of HTML, CSS, and JavaScript. I say “ apparent limitations” because I’ve only cycled about 10,000 lines of web code through it. We’re in uncharted waters, but sailing conditions seem delightful.
Today’s POS apps are yesterday’s summit attempts and tomorrow’s view from the top. Never stop climbing.
First thing to seriously try: integrate the full Highcharts into Coda.
Now that could be the premium pack.
(also calling dibs on that because why the hell not? )
Ha ha! You have my blessing and support, but free markets have a well-defined vocabulary and “dibs” is not part of it.
