2014 has been an eventful year for Google Apps Script with some great new capabilities arriving (add-ons), as well some useful ones (ScriptDB) being deprecated. In this post I’ll cover my highlights and lowlights of the Apps Script year, and would love to have your opinions on
- did I miss anything significant this year, and do you agree with my comments?
- what do you think the best thing that happened this year in Apps Script?
- .. and the worst ?
- what an ‘apps script bucket list’ should contain.
Of course the big news this year was add-ons, which went into developer preview in March. Prior to that in February there were a number of add-on enablers implemented such as the ScriptApp class with its oauth token handling and a large number of DocumentApp changes such as bookmark, cursor setting and named ranges to allow navigation back and forwards between the add-on and the active document. Other preparatory changes included removing the ability to customize the width of a sidebar in which the add-on will execute. In September additional authorization items were added to ScriptApp, and installable triggers were enabled for add-ons, and finally in October, add-ons became implementable in Forms.
My personal view of add-ons is that with a few exceptions, they’ve been a bit of disappointment, which I attribute mainly to this (others might say that difficulty of monetization should also be added to the list).
- There’s a lot of overhead and things to learn to do with publishing add-ons to the Chrome store. In the end a lot of things that start off with a plan to be an add-on end up as a custom menu item.
- The review process. It’s good that publicly available add-ons are checked for dangerous side effects and quality, but organizations who want to publish domain only add-ons should be able to do what they want, when they want. They can develop their own review processes if required.
There were a few changes in quotas throughout the year. In case you missed them
- January – Number of email recipients reduced from 500 to 100.
- March – Number of read/write in gmail increased from 10000 to 20000 a day.
- March – Maximum script execution time increased from 5 to 6 minutes.
Quotas and rate limitation continue to be a hot topic in the community, although most recognize that they are necessary to protect the consistency of the environment.
In order to prevent malicious or dangerous code running under html service, it has always been sanitized by Caja
. The side effect of this is that many popular libraries didn’t work, there have always been a lot of restrictions on what you could do, and execution was often inexplicably slow. Opening up the pandora’s box of add-ons of course led to a lot of pressure to have these limitations restricted – you couldn’t even use Angular
– two of Google’s hot web component frameworks. In December, all that changed with what I regard as the best thing that happened this year – the IFRAME
sandbox mode. There seem to be various browser compatibility issues, but in principle you can now create real web apps with the html service. Maybe I missed the point, but Caja
has always given me the impression of being little more than a fairly neglected science project (the home page was last updated nearly 3 years ago)
Changes to things we are using can be irritating, and services such as ScriptDB which were widely used and implemented led to a lot of chatter and upset. Here’s some of the things that were deprecated (and sometimes replaced) in the year
- January. Various spreadsheet functions that were duplicate to those provided by DriveApp.
- February. Replaced Script and User properties with a single PropertiesService. Although it was painful, this is a more secure model than what we had previously.
- February. Finance service. In my opinion, it should never really have been a script app service in the first place.
- May. Both the Domain Service and ScriptDB deprecation was announced. Without knowing the bigger picture, it’s hard to fathom the reasoning behind withdrawing ScriptDB without a simple official alternative, but I guess it will be revealed one day.
- June. Script Gallery was deprecated, with the intention of focusing on the add-on store.
- September. Some changes to LockService and CacheService along the lines of those made earlier in the year to the PropertiesService. These lessen the risk of leakage between user and script level and are good changes.
- December. The Docslist service (the predecessor to DriveApp) was deprecated, along with the UI service. It always takes a while to change UI code, but with the HTMLService now fairly mature, it doesn’t make a lot of sense to continue to encourage development in the UI service.
We’ve seen what happened, but what would we, as an Apps Script community, like to see in 2015 and beyond? For me, a couple of things are already under way that will allow us to create great apps – the IFRAME sandbox mode and the work that has been done to simplify authentication with the ScriptApp service. However there’s a lot more – here are my thoughts
I’m a heavy user of libraries, but they are still considered to be experimental, and actively discouraged in add-ons. The fundamental problem has been hinted at with the changes in PropertiesService, CacheService and LockService (and the deprecation of ScriptDB) , where leakage between shared libraries can cause performance or security problems, but for me it boils down to one of definition. Is a library a) just some common code that can be used in multiple scripts as if it were part of the main script or b) a script environment with its own properties that collaborates with (rather than is consumed by) the main script. For most people the answer is a, but libraries have been implemented as b.
The Apps Script IDE is basic (it only partially supports JSDOC for example), and the debugger is worse than useless. Like many, I tend to use Chrome Dev Editor
for bulk editing and it would be wonderful if Apps Script Classes were supported there, with Github integration and bower support as discussed in the previous post. HTMLservice code is transformed and is not recognizably debuggable using Chrome Dev tools, and server side Apps Script needs a revamped debugger able to support the same constructs as the language supports (try debugging inside Array.map), with the interactive capability we have had for years in other IDEs (even VBA)
There are plenty more things on my list such as an updated SITES capability, asynchronicity and promises, CORS for Apps Script webapps and the ability give them your domain address, an implementation of gapi for apps script etc.. etc.. , but I’ll limit myself to those for now. The driver really is whether Apps Script should be considered to be heading towards being something like node.js or just a client app that happens to run on a server. But what I’d really like to do is turn it over to you for your bucket list and why.
The apps script community
continues to expand – if you haven’t yet, I encourage you to join and participate to continue this discussion.
is a site mainly about Apps Script, Google APIS and how to get there from VBA, with about 1.5m pageviews by .5m users to date. Recently I created a small community for focused discussions on the content and libraries you’ll find there. I recommend you join that too