"Waterfall" usually means a sequential, linear process. Which could describe a process of wireframing -> style guide -> moodboard -> implementation. By designing in the browser, you are able to cut out the middlemen in that process with fewer excess artifacts (such as mood boards or a stack of wireframes) that represent work that isn't going to be in a production product.

Here is a solid article from 37signals on how they think their methods help them increase design agility and reduce wasted time within their small team:

37signals.com/svn/posts/3073-the-documentation-dilemma

fair points, and waterfall wasn't the correct terminology. I still feel that designing in browser is like jumping to the most costly environment too early. There's a misconception about conceptualisation, that materials like mood boards and wireframes are an 'extra' deliverable. The thinking processes and research done within those phases is done anyway, it's just a matter of who its done by, what phase of the cycle its done and what medium you're using.

Some mediums are more expensive than others, and take longer to iterate / introduce feedback. Designing in browser produces expensive leftovers as evidenced in this video. That's not to say preliminary research is perfect, but it certainly cuts down on waste later on and can produce a more cohesive product (sometimes it's hard to justify design refactoring across multiple products for example).