Yesterday, I wrote what became a rather controversial post. I did want to address a few a things that have come up between Twitter and the comment stream. So, here we go.
Firstly, I do want to note, that the post was not meant to be even near a thorough review of Javascript frameworks. I'm not exactly sure how the post came to be seen as this, but alas: it was meant to be solely based on my experience with frameworks over time. While I am a bit of an active community member in various communities I am at the end of the day a contract developer and startup founder. I don't have the time to thoroughly vet every framework out there and often have to make quick decisions of whether a technology will work for me. When a technology seems to vary to far from my needs or practices, as much as it pains me, I do not have the time to go and decipher what is going on under the hood or change my own coding practices. While I try not to keep too entrenched in a single technology stack, there eventually becomes a point where work has to be done and "a jack of all trades, is a master of none."
Next, I want to address a few reactions of "You clearly have spent no time in anything other than Ember JS". Between Ember, Angular, Backbone (raw), and Marionette: Ember is actually the framwork that I have spent the least time with. Two of my personal products rely on Backbone, as did one of the companies that I worked for. Another contract project that I originally built in Backbone and then attempted in Angular and Ember before refactoring to Marionette JS due to some of the more awkward API constraints. On top of this, I a member of the Wardrobe CMS core team which is a Laravel package blog which uses Marionette for its entire administrative panel.
Also, I was very pleased at first to see that Rob Conery commented on the post. If you aren't aware of Rob's work, he has some great tutorials on his site Tekpub. In fact on the topic, if you want to learn Backbone, one of the best resources I found was his series Playing with Backbone. So, needless to say, I highly value his opinion and his comments did push me to edit the original post for some corrections. However amicable our back and forth was in the comments of the post and on Twitter, I was a bit offended to see him post "I’ll never understand why people write these comparisons." - in regards to quoting me saying that Knockout seemed coupled to .NET. I find that this assumption has more to do with the surrounding community than with the framework itself (which is a shame because I know many developers who are crazy happy to use Knockout)
My comment of Knockout being coupled to .NET was more experiential than technical. I will say that my experience with Knockout was rather limited as I didn't find the fit in my coding style. I realize that Knockout is not in anyway limited to .NET server implementations and is used across all sorts of technology stacks. However, the coupling to .NET was more of a community feeling than anything else. The first few tutorials (especially in screencasts which is how I often introduce myself to new technologies) that I found regarding server-side persistence were using .NET implementations.
While I am quite good at deciphering other languages other than my day to day code, I usually try to stay away from tutorials which heavily rely on server-side magic as it often covers up corner-cases which are rarely addressed. This actually was one of my biggest gripes with Ember-Data until the recent documentation change as all the examples just used Rails Serializer and every explained what API hooks and structure the API wanted other than a root element that followed the JSON API protocol. However, .NET also is a hard hit for me as a UNIX user as I cannot follow along to the same tooling and interfaces which then adds extra hurdles to the learning curve.
I completely realize that my assessment of Knockout was faster than the framework warranted and I hope to have the time one weekend to really give it a shot (maybe Rob can suggest a good tutorial that doesn't rely too much on server-side magic?) I really do appreciate other frameworks and the need they fill, the article was not meant to be a volley into enemy territory. Instead it was a response to a lot of people repeatedly asking why I had chosen Ember as they were looking to possibly switch from raw Backbone or were looking to choose their first framework.
I would love to continue discussing where a framework you use may suit this need or that, so feel free to leave it in the comments or hit me up on Twitter @ryantablada. Let's keep it friendly though.