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
- 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.
A brief history of apps script capabilities
|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.
Domain (now part of Admin SDK)
Adsense (advanced service)
Prediction (now deprecated)
Tasks (advanced service)
UrlShortener (now deprecated)
GUI builder (now deprecrated)
|2012||Many enhancements and bug fixes mainly related to all the new 2011 services, and in particular to UiApp (now deprecated)|
ScriptDb (now, sadly, deprecated)
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
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
|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)
Early access program for App maker
|2017||Slides advanced service|
Sheets advanced service
Reviews introduced for OAuth scopes, in addition to the Add-on review processes
|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
So 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.
For the developer, or for the office professional ?
This is the same dilemma as VBA. Whether to make it super comprehensive and powerful, but with it, dangerous and elite, or whether to make it simple to create apps but with more limited capability. Creating front-ends is always the most complex problem to solve for both developers and end users, and in the case of Apps Script, it’s doubly complex because the front end runs in the browser with no direct integration to the underlying object model which is detached and on the server.
Controlling server side Apps Script with an HTMLService generated app is extremely powerful and flexible (essentially this is how an Add-on and a webapp work), but leads to security concerns. Locking down what can be done client side leads to unappealling, unimaginative solutions with limited utility.
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
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.
All this means that quality and security will be enhanced, but at the cost of many useful community contributions and developer resistance.
So what next for Apps Script ? For the many, or for the few ? What do you think ?