Hello from Rome! Lovely this time of year.

I have no comment on Steve Souders, YUI or Dojo at this time. I’ll just leave it at that. :)

The bit about loading scripts without blocking is a major red flag though.

Read Steve Souders articles. You’re absolutely right if your application/page is JS dependant, but thats the whole point, making your pages work without JS and cutting down on useless load times. Offering content sooner in an opted or forced low tech environment.

And (contrary to popular opinion) in browser scripting, the context-specific solution will always trump generalizations in terms of size, speed and maintainability.

Hmm, yes and no. YUI3 and Dojo for example allows context-specific script loading solutions and is more maintainable and pluggable. Libs like OP offer partial solutions, pretty much like $LAB for libraries that either pollute the global scope or are namespaced nightmares. Size and Speed are relative to conditions and environments, maintainability depends on how you architecture your code and is thus a strawman argument.
.
There are many ways that lead to Rome.

Personally, I’m feeling lazy and I want a prefab integration ;-)

UA testing also means updating that whitelist every time a capable browser comes out, and assumes you know about every browser out there that should be getting enhancements.

@V1: There’s pretty simple way to prevent a FOUC with EnhanceJS. Check out this docs page if you’re interested: http://code.google.com/p/enhancejs/wiki/IntegrationTips

There is another option for companies that don’t want to make client-side changes or have a framework that would make it difficult to manage. You can conditionally exclude JS/CSS server-side based on UA. Following Yahoo graded browser support as a model you create whitelists and blacklists for who gets what.

We choose to always deliver a full set of CSS or JS if the UA wasn’t on the blacklist. This allows feature detection and conditional comments in the browser, but allows us to skip markup and external assets for browsers we know it won’t work for.

@PeteB:
A while back, I thought the same thing, but the more we built sites with progressive enhancement, the more we saw that including unqualified, advanced CSS and JS on a page can be disastrous for users on older browsers and mobile devices (both old and new). Unfortunately, the norm these days is to test for the latest browsers (IE6-8,FF2+,Safari 2+, etc) and then turn a blind eye to the rest, assuming the page will probably “just work” in other browsers, even if it’s not quite perfect. Unfortunately, browser support for CSS and JS is not as clean as support/doesn’t support split, and when certain properties are improperly or incompletely supported, we often see a perfectly usable page get *enhanced* into a non-functional, unusable mess, and this is happening in browsers that are widely used today (particularly in developing nations). These days, the enhanced version of a site usually requires a tight synchronization of CSS and JS. If either isn’t supported well, the experience often breaks. For example, imagine creating a slider control, a dialog overlay, or client-side tabs without great CSS and JS support. This isn’t limited to highly functional apps either – the problem exists in ordinary website layouts too, and plenty of popular sites offer up a broken experience to users who don’t have the latest browsers.

The goal of EnhanceJS is universal accessibility, and applying progressive enhancement *only* when we know it’ll work seems to be effective in achieving that that goal. As @Ben mentioned, there are other benefits to using EnhanceJS such as page load speed, since mobile devices won’t have to download the JS and CSS they won’t use. The “low-fi toggle link” even lets you cookie yourself for a low-fi experience if you have a browser that would normally pass, which is nice for iPhone users who just want a quick load, for instance. I know I’d much prefer a perfectly functional, but less designed, page over a broken one. So our goal is trying to deliver the appropriate experience to the right browser. Sorry for the plug… you can read much more about all this in our new book :P http://filamentgroup.com/dwpe/

It may be more convenient to load assets dynamically like this, but it isn’t a very good service to users with JavaScript disabled; a better, although less slick, alternative is the conditional comments that most people are already using.