Hi All,
I would like to ask not very technical question here.
I don’t expect any particular answer, but interesting in others vision and maybe there is plans to change this somehow. I know that I’m making some opinionated assumption here, but still this is how it feels for me.
So my question is …
“Why CanJS is so unpopular ?”
I’ll try to explain what I mean by this:
CanJS / DoneJS (former JavascriptMVC) is around 10 years on the market, still its community way smaller than in Angular / React / Ember / Vue.
I never saw any mention of it in some statistics or guides like (you can find there Aurelia or Riot, but not CanJS):
https://www.npmjs.com/npm/state-of-javascript-frameworks-2017-part-1/
Its rare case when some company looking for developer with experience of CanJS (I personally didn’t saw any, but I assume that there is some)
It’s a bit frustrating sometimes, because it provides possibilities relative to other frameworks, still its popularity very small.
2 Likes
I think I’m not good at building community. Positioning CanJS towards longevity only made the problem worse.
Vue is sort of an exception, but many of the other tools come from large companies. That helps marketing.
We have been focused on making CanJS more appealing to new users lately. But I think we fundamentally need help spreading the word about the framework. A blog/tweet/presentation written by someone not at Bitovi means 5x more than one written by us. But, I’m not sure how best to promote this.
What are your thoughts?
1 Like
I have simple Ideas articles/tutorials for beginners I will do my best to write and publish them.
In my github there’s at least 2 plugins which can be published to npm
@justinbmeyer TBH for me even the website is not that good I think it should target the public not only tehcnical JS gurus!
I’d be happy to explore other homepage proposals.
1 Like
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 DoneJS vs 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.
3 Likes