Use JS MVC Framework such as Backbone.js

[khatiba]

There are many JS MVC frameworks available now, it would be nice to have Magento's javascript enriched features using Backbone and possibly in tandem with a compatible JS App framework such as Marionette.js (I use these two and there combination is fantastic). I'll spare the details as these are popular frameworks. I would be interested in contributing to the effort if this is a viable milestone.

[magento-team]

Thanks for the suggestion, we will consider it.Right now the primary effort is to move all the code to jQuery.

[vanessametonini]

I think that a library such as require.js is more useful(to developers) than backbone for now (after move all to jquery)

[kevva]

require.js is not a library though. I don't like the idea of Magento forcing people to use Backbone either since there will be others using frameworks like Angular with their themes. Stay with jquery since it's very lightweight and will most likely not conflict with other frameworks.

[ScreamingDev]

A ticket like "Make it possible to use different JS MVC Frameworks" would be better instead of lock everything down to one solution.
Like the discussion about Twig in #370 I see this thread as a non-starter. Going on a meta level has more chances of success and will satisfy more than then one particular group of people who like "Backbone.js" e.g.

[paales]

Make it possible to use different JS MVC Frameworks
This is practically impossible to implement. This would make the overarching framework the lowest common denominator of all the frameworks (or I don't understand what we are trying to do).

I do like a bad framework better than no framework at all. The current state is that the javascript section of Magento is one big mess, other developers do not know how to extend the current functionality and build their own ways of doing things, copy whole sections to their own module etc.

Use something like RequireJS so you are allowed to set dependencies on modules, automatic/async script loading. Encapsulates every module etc.

Include the most common interface elements (even if they are not used in the core), think http://getbootstrap.com/javascript/, besides those mentioned on the Bootstrap page, include a price slider, date picker etc. This way an extension developer can add an interface element to a page without adding extra libraries (and having 5 developers use different solutions).

I'd like it if there is a way to do AJAX intelligently on the frontend in an AngularJS / EmberJS method (think about animation etc.), AJAX is the way forward, push-state, PJAX, etc.

I like the model representation that is available in practically all the frontend frameworks, having to only edit models and the rest is handles automatic would be perfect (checkout.paymentmethod = 'cc' and everything works).

[jonathanselander]

+1 for RequireJS or similar, it has grown to be a prerequisite for our Magento 1.x development

[khatiba]

I agree, Backbone and Marionette were examples, locking down to that particular solution isn't ideal, could be rephrased. The move to jQuery already reduces some of the pain of integrating these frameworks. But, as paales said, and I feel the same, a framework is better than none at all, and its of growing importance in this area.

Perhaps to avoid conflicts, the dev team would provide a homegrown "common denominator", a set of base models/events that can be mixed-into a framework of choice.

The effort of moving to jQuery I'm sure is a terrible ordeal, not intending to put more pressure on the team, just brainstorm.

[Flyingmana]

The most important point here is to design the API between js and webserver consistent and good documented.
This allows other developers to build on their js framework/mvc/singlepageApp/(and so on) of choice.

Besides this I would at first suggest backbone.js, as it has the(in my filter bubble) longest and widest usage yet. angular.js seems also very promising thanks to the influence Google haves there now.

But only rely on jQuery is ok too. keep it simple for the default and let developers provide specialization.

[ghost]

+1 for backbone

Magento should really be just an API/REST interface with a backbone frontend and Twig templates... then it would at least be up to date with modern practices...... (oh yea and rewrite the server part it in node.js :-)

[alankent]

Magento is investigating improving the service layer separation between UI and business logic which should make it easier for someone to build a completely custom UI if they chose to, but the Magento model of "layering" modules and merging the UIs is pretty core to its model (and module developer ecosystem).

Looked at from another perspective, Magento may struggle to use some technologies around until they "catch up" and support a more modular way to build UIs... ;-) (Sorry, I could not resist! I do understand what you are saying.)

Very interesting thread.

[kandy]

@alankent but how are magento team can verify that service layer/API enough covers functionality without building big client side mvc application?

[alankent]

Utopia is declaring service layer API automatically makes it available to UI components (blocks, templates, etc) and as a web service with near zero additional effort. That way the service API is guaranteed to behave the same as what the Magento UI sees. The team is still experimenting here - trying to find the nicest solution.

After working out how to do it, there is still the BIG job of pulling out business logic where it has snuck into UI code to have nice service API definitions on top of all business logic. This rework would be needed to be completed to get all business logic exposed via web services. There is a lot of code to go through - this will take time to complete.

(The other reason to do it is to make it easier for customers to customize the HTML Magento produces for their own site without having to mimic/copy business logic. Less "magic" code in PHTML files is a good thing all round. It should also make it easier to put a different UI layer on top if that is what someone wanted to do in the future.)

[verklov]

@khatiba , we do not consider adding support of Backbone.js so far. However, we are looking at the various JS libraries. We might consider using one of the libraries and if so, it might make its way into the product backlog.