Hi pack makers,
I just saw this video of @Scott_Collier-Weir :
As always, very useful content in simple terms.
Just out of curiosity, what would be the pros and cons or limitations of developping Apps Script instead of packs to communicate with external APIs (sending and receiving information) ?
Thanks a lot.
There are too many possible ways to approach your questions. You’ll need to provide a little more background concerning the two approaches you want to contrast.
first off; @Scott_Collier-Weir has done a GREAT job of explaining clearly how to use google script to achieve this magic trick - well done CodaGuy!
@Omar_Mhammedi, you ask a very good question that i want to tackle, based on my experience with several different clients and approaches to this;
where to use a Pack vs Integration platforms (Make, Zapier… etc) vs Google Script (and/or VBA)?
we have found that the GREATEST benefit to accrue from using Coda to automate workflows comes from the SELF-SERVICE aspect of using no-code in general and Coda in particular.
when makers are able to create their own automations BY THEMSELVES without depending on expertise from the IT department or other developers - then they enjoy HUGE benefits. they harness their own business expertise and their previous experience with spreadsheets and create, modify and share useful automations faster, cheaper and with greater agility than any other method.
but when Coda is unable to achieve the needed functionality by itself, they must exploit external tools to overcome this problem.
if they DONT have experience with PROCEDURAL CODE (eg VBA, JavaScript, Python) then we direct them to the family of integration platforms such as Make or Zapier (and others) where they can continue to enjoy the SELF-SERVICE benefits of those ‘no-code’ tools. they can achieve a LOT with these tools without needing to write procedural code.
if they DO have some experience writing procedural code, or they have someone on their team who can do so; then they have a range of options as follows;
many Excel whizz-kids have experience writing macros in VBA (MS Visual Basic) and we provide them with our VBA pack that translates VBA code into Coda actions. so they remain self-sufficient.
many Google Sheets users have experience writing macros in Google Application Script (GAS) ,a dialect of JavaScript, and we encourage them to exploit @Eric_Koleda’s pack that lets them write integration applets in GAS, which can do external integrations.
finally, if a user has a LOT of experience with advanced JavaScript, JSON and APIs; then we show them how to develop Coda Packs to achieve the integrations they require. (We also build such Packs for our clients but that breaks the SELF-SERVICE aspect of using Coda.)
so in summary (TL;DR)…
we choose the option that maximises the SELF-SERVICE paradigm of using no-code tools, based on the level of expertise the users already have (or can readily acquire). we try to avoid creating any DEPENCENCIES on external experts as much as possible.
respect
max
Some use cases, for example, would be connecting Coda to Odoo, Wordpress, Instagram, Tiktok, etc. to read Data and analytics, or post content.
I ask this because I have found many more tutorials, tips, and code snippets for connecting Apps Script to different platforms than tutorials on Coda.
And while I wish to learn how to make a Coda pack, it’s not always simple due to lack of time or having other priorities.
Having already a lot or resources to use on the internet can be considered shortcuts. I think even AI knows better how to make Apps Script than Coda packs.
It’s a great question @Omar_Mhammedi, and having worked extensively on both platforms it’s something I think about a lot. I catalogued some of the downsides of scripts, and how Packs improves on them, in this blog post:
Apps Script still has it’s strengths, especially when it comes to the speed of development and availability of existing tutorials (as you pointed out). Hopefully something Packs can catch up to over time!
This is true, but only because Apps Script is 16 years old and used by 850m people. This should not be the data used to guide your choice of implementation approach. 
Coda Packs have many limitations; Apps Script not so many. That said, I let the limitations (and opportunities) guide me when making the decision as to which scripting environment to choose. This drives to the heart of the requirements both technical and business requirements. It’s difficult to advise without knowing a lot about the requirements.
Two aspects of code development govern AI’s ability to generate useful code. ONE of them provides a massive advantage - apps script is well represented in public repositories on Github. With vast resources to learn from, it’s no surprise that LLMs are better trained to pop out some pretty solid Apps Script code even in the face of poorly-constructed prompts.
Coda Pack code and its SDK are sparsely represented in the public domain. However, a well-designed learner prompt can generate buildable Pack code as I demonstrated recently as an update to this post.
Thanks for all the information.
What I understand from @Eric_Koleda is that App Script can become messy to manage, especially for medium or large organizations. And from @Xyzor_Max, the best tool depends on the situation and the people using it.
What I’m specially curious about is from the perspective of a user that neither has any preferences nor experience, and is looking for the easiest and fastest solution to implement for a small team.
Are there any advantages and drawbacks to what each platform can offer in terms of functions and performance?
That’s a big ask. It deserves a lengthy discussion with many predicates. Most important is the predicate known requirements. Answering this in a vacuum is not wise.
Here’s one example. A Coda Pack can call out to one endpoint. Google Apps Script has no limitations. If the requirements include three endpoints, the messiness Eric mentions falls to the Coda column, not the Apps Script column.
