Less than a few hours after Airtable released its long-awaited integrated scripting block, I was asked by more than one community member what I thought about this new shiny toy. By looking only at one example by @JonathanBowen, I am able to say –
This toy has teeth!
I needn’t write a single line of code to recognize a game-changer for Airtable users, and specifically, consultants, power-users, and anyone interested in taking their solutions to a higher level.
Certainly, there are bound to be a lot of missing elements of this integral tool to manipulate data in tables. And there will be significant complaints about the tight guard rails imposed to prevent “coders” from doing dumb things on a platform that is ostensibly hosted for joint tenants-in-common.
Teeth?
Yes, teeth. This early implementation can put a huge dent in many of the common deficiencies of the beloved Airtable that this community has railed about for almost a half-decade.
This new block will ultimately demonstrate that dozens, perhaps hundreds of new and innovative concepts involving the science of data – yes, data-science – can be created in a sustainable and reliable fashion.
For example, one of the biggest challenges that users encounter when ingesting data into a new (or existing) base is data transformation. This is the task of aligning externally-created data with your pristinely-designed data model.
I have often made comments about shaping external data before ingesting it into your solution using the Airtable API. And largely, I believe this is the right approach if you care deeply about data normalization and consistency. But the new Script Block allows us to move this aspect of the business logic of cleaning, transforming, etc closer to the base and tables where it actually needs to run. And more importantly, script blocks can interact with data in-place; no need to create two new formula fields to create a good version of a badly-formatted field.
The impact of in-place field updates is absolutely HUGE. It will stem the forever-expanding widths of tables that are blindingly mesmerizing and very inefficient uses of CPUs, storage, and ultimately degrade performance and create management nightmares.
This single capability may eventually cut a third of all resources expended to perform data transformation workarounds. But to realize this benefit, users must have the capacity to – wait for it – write code?
That’s not gonna’ happen. This is where the aftermarket community of developers, power-users, and consultants need to step up their game. We need a vast array of code-blocks that are easily discovered, installed, and configured to meet specific data transformations.
Takeaway…
The teeth are there; where and what these teeth will chew into remains to be seen and is largely gated by the community.
One thing is clear though, the next time you reach for the track-pad to add a new formula field to render data in a more useful format from another field, consider this shiny new toy to avoid the debilitating data model disease known as Airsperfieldiasis - the never-ending band-aiding of fields to effectuate a data model that works. :winking_face:
