that was closed by discourse.org airtable’s Team automation parameters.
Reminder: before I have enough skills and time to develop my own FrontEnd UI for Airtable in the form of WebApps or Mobile-Apps, which might never happen because it’s not my main job, I serve my job in a very friendly and efficient way (compared to the time I didn’t know AT) using Airtable, Script-Block and the appropriate javascript learned little by little in the community, MDN and MEDIUM.com, among other multiple sources.
In the meantime, I considered various third parties to put a FrontEnd UI that would suit me best over my tables powered by my first scripts.
The Professionals I consulted were not surprised by my observation: unless I would spend a lot of money to rent several third parties simultaneously to cover what I think is my current specifications, creating at the same time so many dependencies that weaken my daily work, I have not found something that satisfies me enough in terms of money to spend to obtain an incomplete frontend solution imposing compromises or workarounds that are not very reliable because they are difficult to develop, sometimes weak.
Looking at what the best-known third party solutions in this community offered, I realized that I am neither NoCode nor CodeOnly, but somewhere in between.
I also realized that even though I like the constrained and simple airtable Script-Block environment rather than starting from a desert empty of APIs, tools and UI with 100% freedom before starting to write code, I don’t have time to study and practice very heavy, multi-layered and often evolving SDKs like AWS or even Gsuite.
I also realized how much the Airtable Script-Block Community had allowed me to progress quickly around my own most urgent Use-Cases to solve by adapting the scripts they offer with their documentation while learning very good coding practices, I couldn’t really find an equivalent in other environments offering a rich SDK and APIs.
The last path that I explore at this date because I need a FrontEnd UI that answers a little to what I have just criticized or regretted out of Airtable is UI Bakery but without any assurance that I will adopt this solution after TRIAL it.
It’s just what seems to me the least inappropriate to my own current wishes while offering me at least a “back-up” UI FrontEnd in the short term.
So I did not choose ADALO because I did not find the possibility to solve my most urgent requests despite many other advantages to the ADALO solution that I chose to leave for the moment.
I will follow closely the evolutions of ADALO in the future as I also do with other LOW- or NO-codes and maybe come back to it one day.
I’ll probably stay focused on Airtable Script-Block for a while and I hope soon to have access to the reading and manipulation of my Table’s Metadata with Airtable Custom Block that is pretty more complicated for me than Script-Block because REACT.js, html, CSS…
But after finally choosing a FrontEnd UI that is not written line by line by me, I will not hesitate to share reviews and experiences here.
