Currently twitter-bootstrap-rails-confirm is loading after the DOM, despite the fact that it doesn't interact with the DOM until someone triggers a jquery_ujs confirmation. We can get an impossibly tiny performance boost and clean up the setting of user defaults if we load ASAP.
Note that this is a breaking change if anyone has (foolishly) required twitter-bootstrap-rails-confirm in their application.js before jquery_ujs.
(ps, unrelated: Any reason the js needs to be in twitter/bootstrap/rails/confirm.js? Seems like twitter-bootstrap-rails-confirm.js would be just as good, and wouldn't require drilling through three directories when developing.)
Currently twitter-bootstrap-rails-confirm is loading after the DOM, despite the fact that it doesn't interact with the DOM until someone triggers a jquery_ujs confirmation. We can get an impossibly tiny performance boost and clean up the setting of user defaults if we load ASAP.
Note that this is a breaking change if anyone has (foolishly) required twitter-bootstrap-rails-confirm in their application.js before jquery_ujs.
(ps, unrelated: Any reason the js needs to be in twitter/bootstrap/rails/confirm.js? Seems like twitter-bootstrap-rails-confirm.js would be just as good, and wouldn't require drilling through three directories when developing.)