I’ll chime in with my opinion here too
What drew me to CanJS from the get-go was that it was not an opinionated “framework”. For me it fell more into the “library” category.
However, this means that getting going can be a daunting task. With something like Ember, that I actually worked with for 3 years, it is very much based on convention. If you want a “Blog” you have to have a “BlogController”, “BlogView”, and a “BlogRoute” and you’re off. Frameworks tend to make the easy cases super-simple but the more tricky cases tend to get pretty hectic.
CanJS does not impose any pre-defined structure which means that you need to come in with a pretty good idea of what you are after. Again, this isn’t a bad thing at all but given the general level of reluctance from developers to learn anything new it definitely doesn’t help. Many developers end up having to deal with the full stack but typically won’t want to spend much time on the front-end as that isn’t their focus. Having something that requires some proper attention is going to cause them to move to something slightly simpler to get going.
I also think that DoneJS adds somewhat to the confusion. I worked with Ember before the
ember-cli days but it seems as though
ember-cli introduced the same type of confusion although I’d posit that it may have been somewhat less of a departure from
ember than the
CanJS affair. I don’t use DoneJS at all. I tried but I couldn’t quite see the benefit… I may be missing something.
CanJS has been changing a bit too much too quickly for my liking but once it stabilises and the community hits the point where members are able to assist each other things will start picking up.
Another issue is that business that have to pick a technology stack tend to go with the “mainstream” bits and CanJS does not have enough visibility from that point of view.
I sincerely hope that it will change and I, for one, push CanJS as a viable option wherever possible.