The search for the most ideal scripting language for Airtable.
I purposefully included the word “debate” in the title because I know where this is heading.
As the number of scripting languages approaches the number of religions we can choose from, deciding which scripting language is best is not unlike deciding which God to worship - if any.
And the irony of this debate in a community of people who cherish and thrive in the no-code movement does not escape me. Airtable users are vastly the equivalent of spiritual atheists; they would rather not spend ANY time or energy writing code let alone deciding which script language to write it in.
And so, with trepidation, this missive presses on to do its best to stir up (or dispel) yet another controversy -
… the search for the most ideal scripting language for Airtable.
This is one of those topics where I typically warn people to not get me started, but a few Airtable experts - people who I regard as both clever and masters of the Airtable platform - entered my launch codes over in
If historical data can be our guide, I'm hoping for exactly the opposite. More as to why [exactly] a little later.
’s response to the suggestion of yet another language has a lot of good points, but it’s not the complete picture. I’m sure she was buried with more pressing programming tasks when she composed this.
Setting aside the origins of early development languages such as Visual Basic, SQL (itself), and a few others - no vendor-created language has ever done well - and by “well” I mean swayed developers enough to fully master and base their work on a singular focus using only that vendor’s script model. The vast majority have failed and fallen into obscurity. There are a few exceptions but for the most part, it’s very rare to see any level of deep adoption of a vendor-based language unless and of course, the vendor has also locked out all other languages by failing to provide an API. That’s a red flag for another conversation.
So much for vendor-based languages. This sentiment is not uncommon and across many vendor-built scripting environments. Visual Basic is apparently dreaded by 79.5% of developers while WordPress is close behind with 74%. Matlab, Sharepoint, and CoffeeScript weren’t that far behind. All three were still in the 70s. Each of these platforms requires specific scripting environments driven by platform vendors.
Only those languages that are based on open-standards have thrived or at least have had the opportunity to thrive. And even the early languages that were initially proprietary have trended toward openness with deference given to their respective communities, rather than the marketing and salespeople who love to own the value chain.
Database Scripting Requirements
Scripting language choice typically falls into one of two categories; client-side (like in a web browser), or server-side (script that actually runs on the server but met be created and launched via a client).
Airtable scripting must embrace both client and server-side processing because there are things that you shouldn’t burden the web browser and the user’s machine with. Failing to accept this distinction will result in really poor performance for certain operations.
and the freedom to run the same code on the server and the client.
Custom Script Blocks
is gaining momentum and possibly on its way to overtaking AngularJS. Thanks to its simplicity (and its Facebook origins), React more than tripled the number of upvotes on its questions.
The Responsibility of Building a Script Language
With all of the features that Airtable has planned, and the vast array of things that aren’t planned but need to be addressed, imagine if Airtable had to think about a new scripting language that works across three fundamental touch points - client, server, and integrated plugins. Enough said.
Want to print your doc? This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (