Because most apps are being built in the conditions of uncertainty and the development team doesn't know if the edge case will become a business requirement.
>Feature bloat/mission creep sucks.
Unqualified, this statement is nothing more than a thought terminating cliche. Whatever constitutes "bloat" depends on the context and preferences of a decision maker.
Same goes for whatever constitutes a necessity. I seriously challenge the idea that "websockets" are a must have.
Case in point, their lack haven't prevented tons of PHP, Ruby, Python, etc frameworks (all the tons of them that are not async/event based and can't handle websockets well if at all), from succeeding.
Heck, 1/4 of the web is based on Wordpress (including players like CNN, Forbes, Sony, and NYT blogs) and that doesn't even touch websockets, not to mention not being a proper CMS/framework in lots of other ways.
Django is adding websockets support using the $150K grant from Mozilla. Rails is adding websockets support in the next version with ActionCable. Phoenix and Play frameworks have great support for websockets. Websockets are an integral part of node ecosystem.
Your websockets "challenge" is not based on facts.
Note the future tense. By which time Rapidoid might or might not have them as well.
>Your websockets "challenge" is not based on facts.
No challenge at all. Just plain old reality. Most successful frameworks don't support websockets at the moment, and are still widely used.
The fact that Node and some Java frameworks do (as does Python with Tornado and co) doesn't change that fact. Note also how I never said there don't exist frameworks that DO support websockets, so I don't get why you mention these to me.