> This is kinda funny to me because I know it's untrue. The product I work on in my day job is based on JMVC 3.2 and we can't upgrade to 3.3 because of the size of our app and the amount of refactoring work that would need to be done to make it work with the new concepts.
While it may be a large undertaking for your organization, I wouldn't consider any of these to be irrational changes in API from 3.2 to 3.3: http://www.javascriptmvc.com/docs/done.html
Yes, and I think we do a decent job of highlighting why.
Backbone/Knockout may be well maintained but their scope is fixed. CanJS has gone from the times of $.widget() to <app-component> while maintaining backward compatibility.
Just the fact that this is a blatant advertorial makes it hard for anyone to take your article seriously. Your arguments are valid and I admire your research but your presentation discounted all the value you provided with your article. If I were you I would have left out your attempt to "sell" your project and just mention it briefly at the end. If people actually agree with you, they would have been interested anyway. But as soon as you started talking about CanJS the credibility fell to 0
Thank you, I get the sense that you're not trying to be overly negative. But I'm also slightly confused. If you can't gain credibility with valid arguments and research, how else can you?
The article as is right now, won't be shared as much as could have been if it had objective tone. What I've seen a lot of people do is make a useful and objective argument about what the message they're trying to convey and then maybe at the end mention their message briefly. That's how people build credibility. Check out all "Crunch Network" posts on TechCrunch. Even though most of the writers behind those articles do have agenda (they all have some stakes in the subject matter), a lot of those articles are useful. Since the content is useful, a lot of people share them and there's no lost credibility.
The article comes across as very biased. Also; the article was posted by Matthew, a pretty significant contributor to CanJS, but this was not disclosed in the submission.
It wasn't until I was 3/4ths of the way through the article that I even caught on that Bitovi is the company that created CanJS since it is not a framework I have personally used or am all that familiar with.
From your own article you highlight these 3 points as describing "longevity"
1) Trust. (The framework shouldn’t break backwards compatibility.)
2) Consistent innovation
3) Proven Track Record
Both Knockout & Backbone have clearly demonstrated both points 1 & 3. Point 2 is dubious at best since depending on your definition of consistent innovation you may well break Point 1 - Trust.
Consistent innovation is also, IMHO, not a necessity of longevity. If I need to turn a screw I need a screwdriver. Tomorrow a screwdriver will still work; maybe it's a faster battery charged screwdriver, but it is essentially the same tool solving the same problem. KnockoutJS is a tool that still solves the same problem.
It's fair to have compromised your expectations of frameworks - since there aren't many that have been around for long - but Bitovi and its clients have not. Our libraries are both backward compatible and constantly innovating.
The goal was to illustrate how unique dependencies could be packaged separately for progressive loading while navigating single page javascript applications.
I had to write the scripts to implement this concept myself and it wasn't a quick and easy task. It would had gone along a lot easier if I was able to abstract away some of those queries with a tool like this.
We use index mappings at TaskRabbit, and it does make things a lot easier. It helps with 0-downtime mapping changes (as you point out), and it also lets us combine large indexes. We segment large data collections by time (ie: events_year_month) which we roll up in an alias. This allows us to delete/add large collections without downtime as well.
What's cool about the elsasticsearch api (and therefore the elasticdump tool) is that with aliases, you can read/write to and from an index just like you can an alias.
My instinct tried to steer me away from doing that, but my urgency to get something out there overcame it. I had anxiety about every damn word I wrote so I ended up settling with copy I felt "flowed".
I'll look into the type thinness. Thanks for the feedback.
While it may be a large undertaking for your organization, I wouldn't consider any of these to be irrational changes in API from 3.2 to 3.3: http://www.javascriptmvc.com/docs/done.html