How robust in the [iol] or ""image on load"" technique?

You could always just add console.log("It loaded") at the start of your script and use that to check if its being loaded each time.

As far as future updates causing it to break well anything is possible. I honestly don't know but personally I think it would just be adapting the code a bit as oppose to breaking it completely.

Well if for some reason the script injected via IOL didn't load you would not loose any data because nothing would happen. But I have never encountered this situation.

Any SaaS (Software as a Service) platform could "break" overnight weather it was due to the vendor pushing out a broken version or a user implementing a custom script solution that interacted badly with a new version of the platform.

The more likely problem using any scripting solution with QuickBase is accidentally overwriting or possibly deleting (much less likely) during development. The best advice here is to do your development in a separate application with duplicate or dummy data.

In my experience, yes, a new release did cause the IOL technique to break, resulting in significant rework. Thanks to recent features released by Quick Base, particularly Quick Base Actions, I've found that with careful design, it is often possible to avoid using IOL. Javascript within a custom button, however, seems pretty safe, and in my experience is often helpful. (For an example, see my post on the topic of collapsing and expanding all sections in a form.)

>a new release did cause the IOL technique to break

This isn't true. The IOL technique injects JavaScript into your page and to my knowledge it has never broken. A more likely explanation of what Alex is saying is that some particular script someone wrote that was injected with IOL may have stopped working because of a change QuickBase made and the script made some assumption about the structure of the QuickBase page. But this would be the fault of that particular script not the IOL injection mechanism itself.

Moreover, the Service Worker technology is god mode for QuickBase. You gain complete control over QuickBase because the Service Worker can intercept any network request before the page is even delivered to the browser for processing.

Of course the IOL technique itself is not to blame. That's not the point. The question is whether it's prudent to use scripts and IOL to design an app, or to stick to native Quick Base. Really it's a matter of relative risk. What's the risk that a new release of Quick Base will result in your app being broken if ...

• You rely entirely on native Quick Base? Low. Not zero, but low relative to other design options.
• You have some Javascript within custom buttons? A bit higher. Quick Base sanctions using JavaScript in custom buttons. However, if the button makes assumptions about, for example, the document model, and those assumptions no longer apply because of a Quick Base release, then your buttons stop working. But the impact is limited to what your buttons do.
• You rely on scripts injected with IOL? Higher still, if only because your script has a wider scope of potential impact than a button would have. Quick Base Actions are, in many ways, a good alternative to what previously one might have been tempted to do via IOL scripts.

Ok we are on the same wavelength ..

But counterpoints:

(1) In any risk assessment you have to look at risk and reward. The rewards of using JavaScript are unending with QuickBase. There has been a literal explosion of features and affordances JavaScript brings to the browser to the point where senior developers can't keep up and the pace of innovation shows no signs of slowing down. Products such as QuickBase can't keep up with the pace of innovation and quite frankly most software companies can't find enough developers versed in the latest technologies and their products to some degree or another are laden with lots of technical debt. Using script with QuickBase allows you to workaround almost any conceivable limitation or problem and can utilize the benefits of new technology immediately without waiting for hardcoded features to be prioritized and implemented. If you don't use script you are simply locking yourself out of the enormous benefits that it can provide.

(2) The computational (ie formulas) and workflow model of QuickBase has to evolve and it needs to embrace script. The idea of stringing together URLs that redirect with 302 response status codes using redirection parameters is outdated. The existing QuickBase user base may be comfortable with the idea that the URL action represents the "state" of the application but this model has been abandoned by the development community in favor of single page application (and other architectures) that perform computation, workflow and state management through background AJAX calls - not by constantly reloading the full page and displaying a new URL.

(3) When I write custom scripts I go out of my way to not interfere with QuickBase's native features. One technique I encourage is to prevent namespace collisions by always placing your code in a closure and prefixing any element id, variable or class with a "QBU" prefix if they will be exposed at global scope. Another technique is to emulate user input rather than directly modify the DOM. Or to mutation observe changes in QuickBase's modification of the DOM. Some of these topics I mention may be over many peoples heads but I put a lot of thought into how to safely use script with QuickBase. Quite frankly if over 15 years I have never had a problem that could not be fixed often in several different ways.

(4) Webhooks and Actions can only respond to a limited set of events (add, edit delete a record) and they do so server-side. In contrast all events are initiated client side and include 1000s of different events. Script gives you the ability to respond to any of these client side events immediately and without latency. Webhooks are best at responding to events generated from a foreign domain.