Thanks Rich for that insightful post! As the tech lead of the AMP project for Google the things you are describing are actually very much on my radar and JavaScript journalism is a use case that absolutely want to support well!

We are currently working on 2 strategies to make interactive content feel at home in AMP:

1. Interim solution: iframes

By using iframes. Now, this comes with problems that I am aware of, but the fact is that they are already widely used in publishing for the same purpose, so they really do help. Since AMP’s launch amp-iframe has gained resizing (without disrupting page load!) and the ability to be near the top of the page (actually that was added yesterday) if they have have a meaningful placeholder.
The interactives you mention in the article could be implemented using this. I totally applaud you that the Guardian doesn’t use iframes by default for this, but for the time being it is needed for AMP support.

2. Long term solution: Preemptive multitasking on the web

I recently spoke at JSConf how to reconcile the reasons why AMP chose not to support author written JS with, well, author written JS. Doing this will involve solving what we call the coordination problem. The web platform is great at composing things together, but it has no way to coordinate them. Every item on a page can decide: “I’m going to mess up the user experience and you can’t do anything about it”.

We have an idea how to fix this. But it’ll be a long process and be pretty invasive to the overall programming model. Similar to the transition from cooperative multitasking (which slowed down MacOS and Windows 3.11 in the 90s) to preemptive multitasking. We think we can do this within the current web platform without new primitives, but it’ll be a a long road to getting it to really work well. As always our GitHub project will be the best place to follow along and to influence how this will end up looking.