Yes, this is a good example of something that works quite well in a dynamically typed language and something that doesn’t in a statically typed language.
A different distinction I sometimes notice is the amount of meta-programming you need to do. Dynamically typed languages often make this painless enough that you don’t even realise you’re meta-programming. A while back I wrote a blog post about this.
I think this is roughly why writing a generic forms library in Elm is difficult.
So for example, imagine you want to write an admin interface for a web application, where you mostly want to allow the admin to change any of the data, in any way they want. So you’re going to end up with a form to edit a particular database record. If you want to do this for a single web application it’s quite doable, but if you wish to write a generic admin interface, that takes in the database-schema (or some description of the data) and presents the user with a reasonable form for that kind of data, that’s quite hard in a statically typed language. You end up partially writing a dynamically typed language interpreter, an application of greenspuns tenth rule.
So are SPAs more likely or less likely to require the kind of generic programming that would be easier/best done in a dynamically typed language? I don’t know either way, but my feeling, for what it’s worth is that SPAs aren’t especially likely or unlikely to require that kind of generic/meta-programming.