This is a great question. The little iOS development that I've done it seems like the script and style are tied together with the markup.
I think about how painful it would be adding a custom button(new behavior) to a notification on a website: you either add an event listener to the dom and listen for it to bubble or add it to the button directly(the easier option). These new web frameworks seem to be adding it directly to the dom node -- we're back to <a onClick="function('value')"> which is faster, but traditionally harder to manage. But since everything is a structured component (all of these things implement an interface) we can build them faster and worry about it on the component level and not the markup level.
I've been playing with React and Riot and it is a very interesting approach. You can build things out a lot faster than you used to and that is what matters in the end. The user will not care if you separate concerns (as long as the page renders and is accessible, but that is another story).
Not familiar with react and barely JavaScript, but why is <a onClick="function('value')"> bad? I mean as longs as the function calls a function on another module and doesn't contain any more logic than that. The other module remains testable, and the only logic in the UI is a function call.
If the interface of the module changes, sure the UI would have to change, but I tend to think people over think things at this point (my opinion and I hope it doesn't distract from my original question).
As far as I'm concerned <a onClick="function('value')"> was bad because 'function' was a global variable reference.
I don't think that's the case for React though so I'm not sure if the GP saw some other drawbacks in it (apart from the aesthetic of separating logic from presentation.)
In React, you would do <a onClick={this.props.foo('value')}> (for example) - JSX would interpolate that and set up the appropriate click binding, and the function is local to the component.
My experience with iOS development is that you just have to hack things together in whatever way works. Frequently you'll get a screen 70% of the way there with slick but inflexible visual editor, then need to copy and paste a bunch of imperative methods to modify things further at runtime. All of this separation of concerns stuff is a bit lofty for iOS.
I think about how painful it would be adding a custom button(new behavior) to a notification on a website: you either add an event listener to the dom and listen for it to bubble or add it to the button directly(the easier option). These new web frameworks seem to be adding it directly to the dom node -- we're back to <a onClick="function('value')"> which is faster, but traditionally harder to manage. But since everything is a structured component (all of these things implement an interface) we can build them faster and worry about it on the component level and not the markup level.
I've been playing with React and Riot and it is a very interesting approach. You can build things out a lot faster than you used to and that is what matters in the end. The user will not care if you separate concerns (as long as the page renders and is accessible, but that is another story).