I usually do an annual post on what’s been going on in the world of Apps Script, like this one but since we’re coming up to the platform’s 10th anniversary in August this year (here’s a story back from 2009 when it got the green light), I thought I should do something a little different.
What is Apps Script
It’s a scripting language for G Suite, primarily to automate manipulation of documents. In its simplest form, it provides a convenient way to get access to the document’s object model and data without having to use REST APIS directly. In the early days there was, for example, no external API for the Document service, so Apps Script was the only way to programatically access it. There are generally 3 ways to access a G Suite service, although not all are available for every service, and not all capabilities are available to each method.
- As an Apps Script regular service – the object model is built into Apps Script and no special settings are needed
- As an Apps Script advanced service – this is essentially an Apps Script wrapper for the underlying API and needs to be enabled both in Apps Script and in its associated Google Cloud Platform project. There is no specific Apps Script documentation for advanced services. You need to read the REST API docs for how to interpret the object model
- Accessing the underlying REST API via an external fetch, and untangling the JSON response manually.
The Microsoft Office ‘equivalent’, VBA, is 26 years old, and although it serves a similar purpose the capabilities, design and execution are very far apart, but more of that later.
A brief history of apps script capabilities
There’s been much coming and going over the past 10 years. Here’s a non-exhaustive list of some of the winners, and losers.
|2009||Apps script debut with support for the basic document APIs and other connectivity aids to access external APIs. Finance (now deprecated)|
|2010||The script gallery – now deprecated Google sites (now only supports the old Google sites) UIApp – now deprecated.|
|2011||Groups Domain (now part of Admin SDK) Adsense (advanced service) Lock Cache Charts Prediction (now deprecated) Tasks (advanced service) UrlShortener (now deprecated) Gmail Document GUI builder (now deprecrated) Debugger.|
|2012||Many enhancements and bug fixes mainly related to all the new 2011 services, and in particular to UiApp (now deprecated) HtmlService ScriptDb (now, sadly, deprecated) ContentService Web app deployment Script service and triggers script.google.com and the ability to create standalone scripts in addition to container bound scripts and script libraries|
|2013||Admin SDK (advanced service) directory and reports Fusion tables (now deprecated) Google+ domains (advanced service) Mirror (advanced service) YouTube (advanced services) and analytics Forms Drive (replacing Docslist)|
|2014||Native mode in HtmlService (the removal of the caja sandbox was a great step forward for enabling flexibility of what you could do with Apps Script client side) Support for custom Oauth flows via the Script service Add-ons developer preview Cache, Lock and Properties service enhancement with separation of user, script and document mode LinearOptimization|
|2015||Add-ons in GA Almost all the enhancements in 2015 were in support of Add-ons node-google-apps-script (now deprecated in favour of clasp)|
|2016||Android Add-ons Early access program for App maker|
|2017||Slides advanced service Sheets advanced service Execution API Stackdriver logging Reviews introduced for OAuth scopes, in addition to the Add-on review processes Gmail Add-ons Card Services|
|2018||Apps Script API Clasp was enabled by the Apps Script API, and is a way to allow developers to use their own tool chain preference to develop Apps Script projects Macros for Google Sheets This was also a big year for enhancements to the Slides and Sheets services|
|2019||DataStudio integration enhancements BigQuery data connector|
EvolutionSo is there a clear evoloutionary theme developing? For insight, let’s look at Microsoft VBA over its long lifetime. It started as a way of automating repetetive tasks (the Macro), but soon developed a life of its own. What it had going for it was its tight integration into the object model of the document hosting it, but that is also its problem. Being container bound means that document sprawl also means script sprawl, and sprawl it does. Into every Office application, and across many copies of the same documents across many instances of local PC storage. Although cloud based, Apps Script’s early container bound heritage could have led to the same issue, but soon it became clear that libraries and standalone scripts could be much more reusable when properly controlled.
This makes it seem like Apps Script has gone through several cycles of an identity crisis.
In the early days it was clear that a way of creating an effective front end was required, so UiApp came along – a way of building apps from predefined widgets. Along with ScriptDb as a database a decent front end came within reach of a sophisticated end user. GuiBuilder was introduced to try to make this capability even more widely available.
These ‘generated’ apps were of relatively low capability and something more flexible was required. At that time, it seems that Apps Script gained many more capabilities such as an ‘unsandboxed’ HtmlService, Webapps, libraries, the execution API, the Script service, OAuth2 enablement and Add-ons to leverage this new found flexibility. All of this, and latterly, Clasp and the API service to professionalize the developer experience, made Apps Script a more appealing and serious platform for developers, was probably the ‘golden age’ of community participation, and a great demonstration of what Apps Script could be made to do. The previous generation of ‘end user design tools’ were largely deprecated.
The potential for an Apps Script ‘wild west’ has given rise to a more sandboxed, user orientated environment again, with tools such as App Maker, Card Add-ons, scope refinements and restrictions and reviews on what can be published through Add-on and OAuth reviews to the extent that many of those that have produced free add-ons in the past have either withdrawn them or have stopped developing new ones.More recently, the creators of those Add-ons that require an external security reviews find themselves faced with a cost that most will not be able to bear – as below
All this means that quality and security will be enhanced, but at the cost of many useful community contributions and developer resistance.The assessment fee is paid directly to the assessor and not to Google. A certified third party will complete the security assessment to ensure the confidentiality of your application. Depending on the scope and complexity of your app, the cost for the third-party assessment may vary from $15,000 to $75,000. Smaller apps will be on the lower end, while more complex apps will require more review and expense.Existing assessments that meet the security assessment program standards might reduce the scope and cost of your review. The assessors will consider existing assessments in their review.
VBA never solved this problem – it continues to cater for both the developer and the end user, but it doesn’t have the same flexibility as Apps Script, and its platform means that most of the decision points around Apps Script direction simply don’t apply. So what next for Apps Script ? For the many, or for the few ? What do you think ?