Thanks, @Michelle_Valentine, @Kasra, and the rest of the Custom Blocks team!
Being a pretty new developer, I have found that React.js has a substantial learning curve. Despite that, Airtable’s excellently crafted SDK for Custom Blocks eased much of the learning process. All of the hooks that Airtable made available were absolutely indispensable for someone who is still trying to understand exactly how a “hook” works! The fact that I do not have to worry about figuring out how to trigger re-renders made developing on the SDK so much simpler.
The UI Components provided by the SDK were also a wonderful blessing! Having these pre-packaged, easily-configurable UI elements reduces the time to develop an excellent looking Block by a huge amount – probably upwards of 70%.
Overall, I am absolutely delighted that I have been able, as a novice, to develop some solid, useful, and beautiful blocks to augment Airtable’s functionality in a reasonable amount of time.
The Custom Blocks platform unlocks so much functionality in Airtable that wasn’t there before that it’s difficult even to focus my brain towards a single avenue for answering this question! In general, the Custom Blocks platform has unlocked the ability for me to meet the needs of consulting clients, without having to turn to other web tools, in a lot more cases. And to my mind, the biggest benefit realized from this fact is stability of the system as a whole. Web API’s are improving and expanding rapidly, but it remains true that the more separate services you introduce and the more connections you try to maintain in a software system, the more fragile it becomes and the more places for failure it assumes.
Custom Blocks provide the opportunity for immense amounts of flexibility in complex data processing, without requiring the cost of additional services, and eliminating the fragility creating and maintaining those connections. The existence of Custom Blocks will, for most cases, remove that slight hesitation I feel at suggesting Airtable as a platform for a client that I know will need more complex workflows or any degree at all of automation!
There is an argument to be made that Custom Blocks should be just that… “custom”. If I build a Custom Block for Client A to meet their specific needs, it should be built and tailored exactly to those needs and to the shape of their base. It’s unlikely that a Block built with this mindset will exactly fit the use-case and data-structure of Client B, and so Client B will get their own Custom Block. But I can’t help but get the sense, from these contests, from the open-source nature of the Blocks, from the way Airtable addresses the use of these Blocks, and from Airtable’s own Blocks, that Airtable hopes for many of the Blocks built by the community to be widely available and usable by their user base, much of which is non-technical and will not be able to modify/customize source-code. It’s difficult to reconcile “Github Repos as a distribution method” with this democratic ideal of easy-to-use, community-built blocks that are well kept and maintained.
I guess the “thorn” for me is seeing a potential future where I end up with a mess of Custom Blocks and forks of Custom Blocks and emails and GitHub issues requesting updates and features from people I don’t even know making me wish I had never ventured in to developing something nice and sharing it with the world. Of course, this can never be fully eliminated, but with a good system, the pain of maintaining and distributing Custom Blocks could be mitigated to at least some degree.
Genuinely – the Custom Blocks platform (in addition with the Scripting Block) elevated the value of Airtable to me personally, and as a consultant by 1000%. It’s hard to over-state just how big a deal this is for the platform.