The Great Language Debate
The Great Language Debate

The search for the most ideal scripting language for Airtable.

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

this thread⁠

I’m even hoping that they introduce a simple “Airtable scripting language” that doesn’t require learning JavaScript, which is daunting to many. -
@scott_world⁠
⁠

If historical data can be our guide, I'm hoping for exactly the opposite. More as to why [exactly] a little later.

I think that sticking with an existing computer language, such as JavaScript is a smart thing to do. There are tons of free resources for learning JavaScript. There are also tons of resources for coding in JavaScript, such as editors that already know the JavaScript grammar. Plus lots of people already know JavaScript. -
@kuovonne⁠
⁠

⁠

@kuovonne⁠

’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.

Vendor-based Languages

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.

The recent

Stack Overflow scripting languages survey⁠

revealed that …

Visual Basic is the most dreaded language.

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.

Standards-based Languages

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.

Typically, certain languages are better for each of these operating climates, but one has excelled; javascript.

According to

Tech Beacon⁠

…

It’s now been more than 20 years since javascript was first introduced and everything has changed.
Web applications⁠
are the dominant way that people interact with the computing universe, and JavaScript is the foundation. Even server applications are
increasingly written in JavaScript⁠
as programmers turn to Node.js for
increased speed ⁠
and the freedom to run the same code on the server and the client.

Custom Script Blocks

This is a new capability in Airtable that requires a more robust development realm. Custom Script Blocks enjoy access to Airtable internals with far greater openness than Script Blocks and the public API. To get this more integrated access to the Airtable platform, you must program in a specific flavor of javascript -

React⁠

. This is how Airtable developers build client-side Airtable features itself including Blocks and the entire UI.

Once again, StackOverflow provides a glimpse concerning React Javascript adoption -

If you follow the JavaScript community at all, you know that
React⁠
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.

So, I think Airtable has probably picked a solid strategy - JavaScript universally across all scripting points - from server, to client, to integrated components.

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.