3 ms·

I don't know how Bitovi can bash other frameworks for breaking compatability on major versions, when they completely changed the concepts of JMVC in version 3.3

I don't know how Bitovi can bash other frameworks for breaking compatability on major versions, when they completely changed the concepts of JMVC in version 3.3. They also stagnated for 2 years between version 3.2 and 3.3. >If your project chose JavaScriptMVC in 2007, you would have made a wise decision, giving your team an upgrade path to a modern application for the past 8.5 years. 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.

evlapix 11y ago
> 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 http://www.javascriptmvc.com/docs/done.html
moschel 11y ago
Changing concepts is natural as best practices evolve. 3.3 introduced live binding, but it didn't break any of the older ways of writing apps. 3.2 to 3.3 is actually mostly syntax changes that are documented in the guide linked in the other comment. What specifically is preventing you from upgrading? If you want any help or tips, please reach out and we'll gladly help you or give some pointers.