Backbone is one of the dominant MVC JavaScript frameworks, in addition to Angular, Ember and SproutCore, among others. It has a vibrant maintainer community and a plugin development community as well. It's meant to be a small, unopinionated core of code. I think the purpose of Backbone is explained best on backbonejs.org.

Backbone.js gives structure to web applications by providing models with key-value binding and custom events, collections with a rich API of enumerable functions, views with declarative event handling, and connects it all to your existing API over a RESTful JSON interface.

Backbone has a hard dependency the Underscore library. Underscore is an extremely lightweight set of JavaScript utitlies for manipulating Arrays and Objects and dealing with functions. One of these, debounce, was already needed for a core issue #1276908: Administrative tables are too wide for smaller screens. Many jQuery functions for type-checking and custom functions to manage event firing rates could be replaced with Underscore functions. Underscore is essentially jQuery without DOM events and manipulation parts (and ~30kb smaller).

Backbone works with jQuery or Moustache or Handlebars or Twig -- any DOM manipulation library -- to create the Views. Rather than also manage Models in jQuery, which it wasn't designed for, Backbone slides into this part of the Stack and gives us more formality in what will be evermore app-like UIs in Drupal. We should encourage folks to move towards an MVC model from core out.

The Spark team has several projects on deck for Drupal 8 core inclusion that could leverage Backbone and Underscore.

I could also see Backbone being used to build an advanced block-to-region assignment UI.

The reason I'd like to see these two libraries in core (Backbone and Underscore) is the same that we have jQuery in core. It's standardizes the community on a library so that various modules aren't including their own frameworks, leading to competing frameworks in a site buildout. Having a common MVC framework will help standardize the application layer across these projects.

Additionally, in #1774312: Create.js: yay or nay *and*: when?, there was broad community support for using Create.js rather than custom code for parts of the Edit module, but that integrating Edit module with Create.js would likely only be able to happen post feature freeze if both Edit module and Create.js land into core separately before feature freeze. Create.js has a dependency on Backbone, so before spending time working on build issues (#1774312-17: Create.js: yay or nay *and*: when?) necessary to make it ready for Drupal, it would be helpful to first have Backbone approved as a core library.

Finally, as we've done when committing other major libraries to core during feature thaw, doing so is a signal that the library is approved for core and facilitates keeping reviews for the library's use case focused on the use case and not on the library. If no use case lands before feature freeze, the library can be removed.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

effulgentsia’s picture

Damien Tournoud’s picture

jQuery AHM is a command-based remote control AJAX framework, ie. exactly what we have in Drupal 7... but our version is far richer.

SammyJS is one of the numerous client-side libraries inspired by Sinatra. I remember discussions about implementing a common syntax for URL states in Drupal (in one of the issue around the Overlay), but I cannot find them anymore. Having a consistent hash syntax will already go a long way here.

Damien Tournoud’s picture

If we are talking about incorporating new external libraries, I would definitely welcome:

http://documentcloud.github.com/underscore/ : Let's please have some higher level structure in our Javascript

http://documentcloud.github.com/backbone/

sun’s picture

Frankly, I don't think this issue is going anywhere. If you follow HackerNews, Ajaxian, etc then you know that there's a new fancy library every single day.

We shouldn't talk about tools first. We need to come up with concrete ideas for improvements and figure out their requirements, and only that is going to determine the tools we need.

RobLoach’s picture

Sounds like we could adapt ajax.js to use some of the tools out there, however. This would take some of the load off our shoulders. Thanks Alex, for the issue link. Adding the NIH tag.

wmostrey’s picture

andypost’s picture

The only reason to add is comet but not sure that core able to work this way. probably WSCCI helps

zeropaper’s picture

for what my opinion worth is: Backbone is not the new shiny thing.
It's rock solid, extensible and easy to understand.
On a side note, it's used by giants I trust for the quality of their code.
So... I would +1 that.

ethanw’s picture

I think there are two questions in this discussion: whether or not a JavaScript MVC should be a part of Drupal core and whether Backbone JS would be a choice for such a library. I am one of the creators of the Backbone module, and hope it demonstrates the power of a standardized integration between Drupal and JS MVC's. I would strenuously advocate for the inclusion of some JS MVC in coming versions of Drupal Core, and would submit that Backbone is likely a very good choice.

To the first point, some of the key factors supporting the inclusion of a JS MVC in core are:

  • Efficiency and state-of-the-art/best practice: JS MVCs are a burgeoning area of development because they represent a significant improvement in the architecture of interactive client interfaces. Separating data from display on the client side allows for faster, more responsive interfaces and reduced server load and data transmission. These advantages indicate that client-side MVC is around to stay, and may well be "the future of ajax", and as such Drupal should provide an equivalent level of integration. By integrating an MVC into core Drupal will stay at pace with the emerging standards in the field.
  • Drupal is a great foundation for client-side MVC apps: Drupal is arguable the best of the mature MVCs for the creation and management of the sort of structured data that client-side MVC libraries consume. By standardizing a client-side MVC library Drupal can position itself as a solution capable of producing complex webapps without the need for extensive server-side coding know-how, continuing the tradition of providing non-programmers with considerable power.
  • JS MVC libraries allow interface innovation: many of the core administration pages, for example, might benefit considerably from use of a JS MVC (the Block admin page comes to mind), and system-wide functionality such as in-place editing might also be best achieved through such a design. By integrating a JS MVC into core, efforts towards such initiatives can be encouraged to build on each other, as opposed to risking fragmentation if this is left to various contrib modules to accomplish.
  • JS MVC's integrate with Drupal at a deep level: JS MVC apps will integrate with Drupal at the level of basic entity rendering (see #145551: Enable loading and rendering into multiple formats (html, xml, json, atom, etc.)) and may requires updates to the theme layer to be most effectively utilized. By integrating a JS MVC into core these related core design considerations might be directed to most elegantly support the creation of JS apps in Drupal by focusing on a single set of conventions (though using on framework as a case study would likely benefit other MVC solutions as well).

Now, as per the question of whether or not Backbone is the best match for Drupal, I think there are a number of features that make it an especially well suited and compelling choice. I'd point to this blog post introducing the Backbone module and the DrupalBackbone.js annotated code for more specifics, but will summarize here:

  • Almost "parallel" architecture: Backbone models map onto Drupal entities extremely intuitively, and Backbone collections allow integration with index listings and Views (in a manner that is fairly unique among similar JS libraries).
  • Lightweight design philosophy: Backbone apps are created through straightforward inheritance based on a set of lean prototypes. Like Drupal it is primarily interface based (in the sense of object interface, not user interface) and it does not force a host of design decisions on developers. This is a contrast with other JS libraries such as KnockoutJS and EmberJS.
  • Powerful integration with theme layer: Backbone's approach to templating is also very flexible, and allowing Backbone templates to be managed by the theme layer allows non-developers the ability to customize Backbone applications without the need for either advanced PHP or JS knowledge. While this might be possible with other JS MVCs as well, Backbone's almost complete agnosticism with regard to its templating system allows a very tight integration between Drupal templates and Backbone views. See the example module code for a demonstration of this.

One additional note: Backbone does have licensing issues, currently it is MIT licensed, would need to be made dual licensed like jQuery. I do not know if the developers are open to this.

ethanw’s picture

Also, should this thread be renamed to reflect the more specific request to integrate a JS MVC with Drupal core? Or should that discussion be broken out into a separate issue?

nod_’s picture

Title: [meta] How can D8 AJAX learn from and best use recent AJAX innovations? » [meta] JS MVC in core

Underscore is definitively worth it's 4k in Drupal core if we don't have to use jQuery.

I'm not sure about backbone/spine and other libs alike since core isn't even close of having a productive use of it. This might change with the block & layout initiative. It might even be part of the block & layout initiative.

Anyway, renaming for now.

alanburke’s picture

Wordpress has just included underscore and backbone in its core
Looks like Backbone has the momentum at the very least
http://core.trac.wordpress.org/ticket/21664
https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2012...

Damien Tournoud’s picture

At this point, I would rather go Knockout JS or even Angular JS then Backbone for a true MVVM architecture. Backbone is so last year.

nod_’s picture

Let's have contrib fight it out and keep core JS out of the way that's the best we can do for now.

No real chance (to do it properly) for D8 at this point that's D9 material.

kika’s picture

ethanw’s picture

Two updated considerations for this thread coming out of DrupalCon Munich, both related to the (potential) use of Backbone in the Spark projects:

  1. The Edit module's in-place editing, slated for core integration in D8, will require Backbone if CreateJS is used for architecture. @Wim Leers is currently in the process of implementing w/ CreateJS and discussed the possibility of requiring Backbone in D8 core for this.
  2. Some of Spark's panel editing interface features were initially implemented by with Backbone in mind by @jessebeach. Jesse has a patch in Backbone's issue queue for more elegantly dealing with module path routing in Backbone, but sees advantage to using Backbone if it is available in core with or without that patch applied.

These indicate to me that Backbone may need to be included in core, but as a library used for specific UIs, not a complete client-side MVW ("model-view-whatever") integration for Drupal. That could be handled by contrib, if it needed to be.

jessebeach’s picture

I put together a patch for tbranyen's backbone-boilerplate several months back. I'd need to port this to the current backbone HEAD. Essentially what it does is get a list of all the Modules in an app. The assumption is that modules are not defined as part of the signature of the main app function.

The initialization step of the app calls the namespace.mergeSubroutes method. That method merges routes defined by submodules.

https://github.com/jessebeach/backbone-boilerplate/commit/9220deb4f4c180...

And an example sub module implementation:
Discussion of the point: https://gist.github.com/1235317#gistcomment-289991
Repo: https://github.com/jessebeach/boxes

Wim Leers’s picture

#16: It's not yet certain if Edit will use Create.js, see #1774312: Create.js: yay or nay *and*: when? — feedback welcome :)

effulgentsia’s picture

One barrier that nod_ identified related to adding vendor JS libs to core is that they're then frozen for a very long time. I opened #1787222: [meta] Strategy for updating vendor JS libraries within a major stable version for discussing that.

effulgentsia’s picture

In #1774312: Create.js: yay or nay *and*: when?, there was a generally warm reception (though not unanimous) to integrating Create.js into Edit module, but doing so will be deferred until after both an initial Edit module and the Create.js library are committed to core separately. Each of those needs to happen before feature freeze (Dec. 1) but the integration can be worked on up until code freeze (Apr. 1). Given that, I suggest we start by getting underscore and Backbone into core as part of this issue, then open a follow up for VIE and Create.js.

Are there any remaining concerns or blockers to adding underscore and Backbone to core?

jessebeach’s picture

That would be marvelous. Truly marvelous.

webchick’s picture

Issue tags: +Spark

From the sound of Spark planning meeting today, having backbone.js in core would be a huge help in cleaning up the JS from various Spark issues.

Tagging.

jessebeach’s picture

Status: Active » Needs review

I have a patch for this, but the file exceeds 3mb. Anyone know how we get large commits in?

RobLoach’s picture

Jesse: If you commit it to a sandbox/github, we could make a link to the diff.

If it's mostly moves, -M25% might help. What binaries are packed? Could post those in a zip and the non-binaries in the patch. Another solution is to have the files download via Composer http://getcomposer.org/doc/05-repositories.md#package-2 .

nod_’s picture

Status: Needs review » Active

Nothing to review yet, point to a sandbox or something :)

(edit) also, 3mb for underscore+backbone?

jessebeach’s picture

Status: Active » Needs review
FileSize
127.35 KB

Ok, here's a nice little patch to get us started. Adds Backbone and Underscore -- min and dev -- to system_library_info. Underscore is a dependency of Backbone. I tested with drupal_add_library just including Backbone and things went swimmingly.

jessebeach’s picture

FileSize
32.07 KB

nod_ asked me to remove the non -min.js versions from the patch.

nod_’s picture

Status: Needs review » Needs work

Actually that'd be the minified version we'd want out of the patch. During dev it's the unminified source that we're using. Especially since It's easier to learn from while we get used to new libs.

Just before release we'd want to switch to the minified version like we do with jQuery.

jessebeach’s picture

Status: Needs work » Needs review
FileSize
96.76 KB

Updated to refer to the development versions of the patches.

I added a postponed task to do the production file swapping #1800022: Update Backbone and Underscore.

RobLoach’s picture

Status: Needs review » Reviewed & tested by the community

Looks good.

tim.plunkett’s picture

Title: [meta] JS MVC in core » Add Backbone.js and Underscore.js to core
catch’s picture

Status: Reviewed & tested by the community » Needs work

I don't see any reason to add these to core. Where's the issues that depend on them? What are they blocking? How did this go from a very generic meta issue (not to mention #14 and #19) to adding the libraries with absolutely no discussion whatsoever?

jessebeach’s picture

Backbone is one of the dominant MVC JavaScript frameworks, in addition to Angular, Ember and SproutCore, among others. It has a vibrant maintainer community and a plugin development community as well. It's meant to be a small, unopinionated core of code. I think the purpose of Backbone is explained best on backbonejs.org.

Backbone.js gives structure to web applications by providing models with key-value binding and custom events, collections with a rich API of enumerable functions, views with declarative event handling, and connects it all to your existing API over a RESTful JSON interface.

Backbone has a hard dependency the Underscore library. Underscore is an extremely lightweight set of JavaScript utitlies for manipulating Arrays and Objects and dealing with functions. One of these, debounce, was already needed for a core issue #1276908: Administrative tables are too wide for smaller screens. Many jQuery functions for type-checking and custom functions to manage event firing rates could be replaced with Underscore functions. Underscore is essentially jQuery without DOM events and manipulation parts (and ~30kb smaller).

Backbone works with jQuery or Moustache or Handlebars or Twig -- any DOM manipulation library -- to create the Views. Rather than also manage Models in jQuery, which it wasn't designed for, Backbone slides into this part of the Stack and gives us more formality in what will be evermore app-like UIs in Drupal. We should encourage folks to move towards an MVC model from core out.

The Spark team has several projects on deck that could leverage Backbone and Underscore.

I could also see Backbone being used to build an advanced block-to-region assignment UI.

The reason I'd like to see these two libraries in core (Backbone and Underscore) is the same that we have jQuery in core. It's standardizes the community on a library so that various modules aren't including their own frameworks, leading to competing frameworks in a site buildout. Having a common MVC framework will help standardize the application layer across these projects.

And as a steamvalve, If we don't get the features in that depend on Backbone into core before feature freeze, we can remove Backbone.

effulgentsia’s picture

Issue summary: View changes

Updated issue summary.

effulgentsia’s picture

Status: Needs work » Reviewed & tested by the community

I replaced the issue summary with #33 plus a few minor tweaks. Setting to RTBC for catch to respond with if there's anything else that needs work.

effulgentsia’s picture

How did this go from a very generic meta issue (not to mention #14 and #19) to adding the libraries with absolutely no discussion whatsoever?

Re-reading the comments in this issue, I see quite a few people supporting these libraries for core inclusion. If someone thinks this needs more discussion, please set to needs review, but please clarify what would qualify as sufficient discussion.

effulgentsia’s picture

Status: Reviewed & tested by the community » Needs review

Actually, setting back to needs review to give a little more time to gather broader community feedback. I posted a comment on #1774312-89: Create.js: yay or nay *and*: when? asking for it. Please link from other related issues too, or get the word out via the social media of your choice.

henribergius’s picture

Status: Needs review » Reviewed & tested by the community

+1 for using Backbone.

Since JSON-LD seems on its way to Drupal as well, having that and Backbone would make it possible to use VIE as a bit higher-level JS API to Drupal. VIE provides mappings between JSON-LD and Backbone models, as well as data bindings based on semantic mark-up and connectivity to external services like Apache Stanbol.

If you combine that with the fact that VIE already has a service for parsing Edit's data attributes, doing the Edit Create.js integration cleanly would be trivial.

sun’s picture

Status: Reviewed & tested by the community » Needs review

From my perspective, the main blocker that needs an extremely solid answer is:
#1787222: [meta] Strategy for updating vendor JS libraries within a major stable version

Overall, I can get behind adding Backbone. Underscore, however, presents quite a "conflict" with regard to jQuery (possibly 2.0), since they're doing almost the same. I do not have the impression that there's a well thought-out and solid plan yet for how to handle the ambiguous/duplicate functionality of both libraries (also in light of the remaining time to feature freeze).

jessebeach’s picture

Underscore is a hard dependency for Backbone.

catch’s picture

I'd really like to get #1787222: [meta] Strategy for updating vendor JS libraries within a major stable version resolved one way or the other before we add any more external js libraries to core and am tempted to mark this issue postponed on that one.

nod_ has been working hard to reduce our dependency on jQuery, and I'm coming 'round to the idea quite strongly that having five year old versions of libraries still kicking around on the internet is counter-productive at this point.

With the current policy we'd be stuck with a 2013 release of backbone.js in Drupal 8 until Drupal 10 is released and we drop support for it (assuming the two-release support cycle is still in place by then), which could be as late as 2018. How quick are the release cycles for backbone? What's their policy on backwards compatibility? None of these questions have been discussed in this issue at all yet.

@jessebeach, those three spark projects are all links to contrib projects, not core patches. In general we're committing external libraries to core when there's an existing patch in the queue that's using them to make those more reviewable, I'm not aware of any such issue suffering from this problem at the moment so don't feel like there's any hurry here.

webchick’s picture

Well, we did commit Twig without a core patch for the same reason—a big code clean-up effort happening on the side in preparation for a core patch. We're aiming to get those modules prepped for a core inclusion propsal in the coming weeks, but we need to know if it's feasible to rely on this library to do so or not. We'd really prefer to not create a Drupal-specific MVC framework, but rather rely on standard JavaScript community tools to do so.

The question of how to handle external JS library updates going forward in D8 is definitely a sound one. I'm not sure it's a blocker, though. We committed Symfony without resolving this question, choosing instead to resolve it after as a critical task, and this is a similar situation.

webchick’s picture

Also, as Jesse mentions, should we ultimately not get those features into core, we could always remove this library, just as we'll remove Twig if that initiative doesn't come to pass.

TD540’s picture

I'm completely against this as I prefer ember and ember-data. In contrast to Backbone, it reduces a lot more of boilerplate code. Definitely check out the Ember State of the union: http://www.infoq.com/presentations/Ember-js

I'm not saying Ember should be in core, I'm only saying Backbone definitely shouldn't be.

jcisio’s picture

Status: Needs review » Needs work

#35:

Re-reading the comments in this issue, I see quite a few people supporting these libraries for core inclusion. If someone thinks this needs more discussion, please set to needs review, but please clarify what would qualify as sufficient discussion.

I'm sorry, but supporters for Backbone & Underscore in core in this issue are effulgentsia, jessebeach, webchick, Rob Loach and nod_, all are from the company behind the contrib modules in Spark, so it does not sound well.

And once those libraries go in core, the would be some conversion, and it could happen that we use 20% of jQuery, 30% of Underscore etc. instead of 50% of jQuery actually. It's worse, as sun pointed out. And at that time we could not remove those libraries, neither.

Brief, we don't have (yet) use cases in core. And those libraries are not such revolutive things. I don't see the Twig case is similar.

catch’s picture

On Twig, that was committed when there were initial patches already in to pave the way (like Attributes). It had also had months and months of previous discussion around it by dozens of people. That's not really happened here, less than six weeks ago nod_ said "Drupal 9" for example. There was also absolutely no competitors to Twig whatsoever apart from sticking with PHPTemplate (even less than Symfony had when the first part of that went in).

Symfony we introduced over a year ago when there was plenty of time to resolve the release cycle issue. Since then there's been tonnes of work with their community, and they've gone out of their way to create a release schedule and bc policy that's kind to us (obviously we haven't seen it in action yet since it was only announced last month but it looks good at lesat). There was a critical task in the queue tracking this the entire time and various options were explored in that.

With a PHP library though, at worst we could fork our own version during the 8.x cycle (i.e. only to backport security fixes if there wasn't an equivalent branch upstream) and use that until Drupal 9. We don't have sufficient JavaScript expertise to do anything like that.

Additionally no code from PHP libraries is ever executed by browsers, so it's not such an affront to all that's good and decent if we end up shipping with a sorely out-of-date version. It'll piss off developers, but it won't spam the console log with deprecated messages for site visitors as Drupal 6 and 7 currently do.

nod_’s picture

I'm hurt by your questioning of my integrity jcisio, I'd ask that you review my work on the core queue this past months, or even what I said in this issue, and reconsider your position about me or my motives. Thank you.

As far as community support goes, Damien Tournaud was supportive of the idea back in the days (April), as far as I know he was the first to brought it up in the core queue, he even proposed that core uses it #1541860-1: Reduce dependency on jQuery.

catch’s picture

@nod_, Damien said this in April about backbone, in this issue:

At this point, I would rather go Knockout JS or even Angular JS then Backbone for a true MVVM architecture. Backbone is so last year.

jcisio’s picture

I've just had a chat with nod_, it turns out that Damien and nod_ support Underscore (not Backbone).

jcisio’s picture

And I'm sorry for having made nod_ misunderstood. I should have done a 90% quote, instead of 100%. What I meant is that most supporters are behind Spark (of course henribergius is not from Acquia).

nod_’s picture

@catch: Indeed.

That said, if you read #16 we end up basically with: no backbone in core == no createjs in core possible. It's not something I necessarily want but I'm not against it.

Personally I'm much more interested in underscore since at this point it's still my opinion that it's too tight to have all of core use backbone properly before feature freeze. I think of it as a dependency of createjs and since that could be interesting to have in core, why not. I'd like to remind that core hasn't been using jQuery UI for a few months if I'm not mistaken. There are patches out there but none close to RTBC.

(edit) thanks jcisio, I appreciate it.

catch’s picture

Thanks for the reminder about jQuery UI, I opened #1801456: Remove jQuery UI from core to discuss.

effulgentsia’s picture

Status: Needs work » Needs review

Re #49, I'd like to point out that zeropaper (#8), ethanw (#9), and alanburke (#12) are not from Acquia either.

Point well taken about this needing broader, more visible discussion, which is why I set this to needs review in #36.

Setting back to "needs review" though, because each of the use cases mentioned in the issue summary (Edit module, Layout module, Gridbuilder module) are transitioning from prototype level code to real code now and in the coming weeks left of feature thaw, and whether they get developed with Backbone or without it will depend on the outcome of this issue.

idflood’s picture

One more +1 for backbone.
- It adds some structure
- The most mature project with large community
- Doesn't do too much and is flexible
- Good documentation and you can read the annotated source code in 10 minutes.

The other frameworks are also good but I feel that the learning curve of drupal is already hard enough, so choosing a small and simple javascript framework is important.

Kiphaas7’s picture

underscore still has cruft in it which we don't need in 80% of our JavaScript.
Better to use custom build lodash. It's also faster. And compatible with backbone, because it is a drop-in replacement for underscore.
http://lodash.com/#custom-builds

Dries’s picture

Issue tags: +Favorite-of-Dries

Let's focus on the most important issue first. The most important issue is getting a framework (like Backbone.js or something else) in so we can move forward with building advanced client side functionality. Once we have the right framework in, we can worry if we want to deal with updates.

This is comparable to us getting jQuery in. It would have been a blatant mistake not to get jQuery in because we couldn't agree on how to update it. jQuery fundamentally changed Drupal, and empowered 1000s of non-expert front-end developers to incorporate sophisticated JavaScript interactions in their code. Adding jQuery was huge.

Think about that, and apply it to a client side framework, and you'll realize that what really matters is getting a framework in, not to figure out how to update it. It could be really huge, and in a way, we're late to the game.

I'd be very comfortable with Backbone.js. It seems like it is pretty much the standard, as it is widely used and loved by many developers. Having said that, I think picking the right framework warrants a good discussion. This issue has been open since May 2011, and people appear to be sharing their opinions. I'm thinking I should make a decision no later than October 15.

catch’s picture

This is comparable to us getting jQuery in. It would have been a blatant mistake not to get jQuery in because we couldn't agree on how to update it. jQuery fundamentally changed Drupal, and empowered 1000s of non-expert front-end developers to incorporate sophisticated JavaScript interactions in their code. Adding jQuery was huge.

It was at the time, but it's now a big problem shipping with outdated jQuery versions, and we still haven't figured out how to update it 6 years after the fact. I don't want us making the same mistake again. If we want mobile-friendly Drupal 8 we have to take client-side performance seriously, taking it seriously means being able to pull in upstream fixes quicker than every three years.

catch’s picture

Also what happened with jQuery wasn't that we couldn't decide how to update it and added it anyway, it's that this was never discussed at all and hasn't properly been since.

RobLoach’s picture

Also what happened with jQuery wasn't that we couldn't decide how to update it and added it anyway, it's that this was never discussed at all and hasn't properly been since.

hook_library_alter() is what jQuery Update uses. I agree version compatibilty and future-proofing it is very important.

Crell’s picture

catch: No, the general decision on jQuery was "zOMG we can't update it because we might break an API somewhere", so we don't. (jQuery minor releases did sometimes have edge case breaks, but generally not major ones.) I am not supporting or decrying that approach, but I think it's inaccurate to say that we never discussed it. (Maybe haven't discussed it recently, but it was discussed.)

webchick’s picture

Right, but I guess I don't get why the jQuery Update approach we have now isn't good enough. We use it in Spark to get the same version of jQuery as D8. Our modules just include jquery_update as a dependency. Done.

I guess these comments are all OT for this thread, though, so let's talk at #1787222: [meta] Strategy for updating vendor JS libraries within a major stable version.

rooby’s picture

I'm personally happy with backbone and underscore, although I have not done huge amounts of investigation into competitors.

I have done a D7 site with a large amount of backbone display and it would have been nice for it to have been in core, even though there were still other libraries I needed that would still not have been in core.

The main issue I had was drupal's jQuery was not new enough for backbone, which required some patches to the jqmulti module to get it all going.
It would be preferable if I didn't have to spend time doing that.

From a core point of view, if we want out of the box fanciness like edit, we have to include something.

I think if we don't shy away from updates for fear of breaking things in future things should be ok.
To do that all we really have to do is make sure we are doing things the right way when writing backbone/underscore/jquery/etc. code and when we update to a new version, if there is anything that will break we fix it.

The only thing to worry about is that contrib modules might be relying on that specific version.
I don't think that is much of a problem because it is then just the module maintainers responsibility to update accordingly, which is what they have to do with any other drupal updates anyway.

The main risk in selecting a framework is the risk of having something that ends up not being properly maintained or something that is superseeded by something cooler or better (which will probably almost always happen eventually).
Then we are tied to whatever we choose until the next release at least, however changing frameworks every major drupal release is also not something we want to be throwing all our available time at.

This same risk is apparent with any framework, and even any tech anything. Or non-tech anything for that matter.

One thing I will say about backbone is that it might be a bit steeper a learning curve for people than jquery was/is, but that is likely going to be the case with any MVC framework.

Gaelan’s picture

I think machine name would benefit from this.

jessebeach’s picture

Gaelan, do you mean this project? Machine name

Gaelan’s picture

Nope. I just mean the FAPI machine name.

frega’s picture

the effort to improve the "authoring experience" (in edit.module/spark) will introduce a new and non-negligible javascript codebase (whether in core or contrib). in order to make it easier to maintain the codebase and sustain the effort in the mid- to long-run a foundational library (like backbone) seems like a pretty good and sound idea to me.

currently edit/spark does not rely on backbone. i am not aware of an issue planning such a refactoring and the discussion/conclusion in #1774312: Create.js: yay or nay *and*: when? seemed to suggest that backbone would primarily be a consequence of (potentially) using createjs. wim just indicated to me that this could perhaps be in the "making", though - perhaps wim/spark team could outline what the plans are in this field? if Unless spark/edit.module leveraged backbone, i am actually not sure that the potential complexities incurred would outweigh the gains - and i do really, really like backbone :).

ps. refactoring edit.module on backbone would stengthen the case to use createjs but that is - although i am trying to help bergie and wim on the "edit-createjs thingy" on github - a separate and distinct discussion.

webchick’s picture

Right, the idea behind uploading a patch to this issue in the first place was to see if we would get blocked on trying to add these libraries to core. We'd certainly love to use backbone in both Edit module and Layout module as part of our JS refactoring in getting them core-worthy, but are not really going to take the risk if it's going to be shot down. Backbone seemed to have pretty close to consensus within this issue, but I guess it's still not quite there yet.

effulgentsia’s picture

Priority: Normal » Critical

Raising to critical to get more attention (given #55, this seems an appropriate priority anyway). Also posted to the core group on g.d.o.

film42’s picture

I still don't understand the need for this. Backbone and really all other frontend JS frameworks are designed for single page apps, not CMSs. I think it's a cool idea but the practicality just isn't there. I mean, if it's an admin interface then sure, but if this is being designed for full-blown public frontend then I think you're mistaken in what these frameworks do. I don't mean to flame the hate here, I'm just offering up my experience as a JS dev. It's not easy to mend for customization. With plugins and blocks the best you could do really is an ajax navigation to load content on demand. I just don't see this working. What does everyone else think?

effulgentsia’s picture

I mean, if it's an admin interface then sure

Per the issue summary, the 3 use cases identified so far are all for admin.

effulgentsia’s picture

Issue summary: View changes

Updated issue summary.

elliotttf’s picture

I'm not convinced that this is a good idea. While Backbone is a great framework it's already been pointed out that there are others out there and in my experience the one you choose to use has a lot more to do with your use case than what you're necessarily familiar with. Furthermore and as it's already been pointed out, there are new JavaScript frameworks popping up every few months. The trend has been that the new ones are more performant, smaller (download size), and innovative in their approaches. This isn't to say that backbone won't continue to evolve, but it doesn't seem like it's enough of a standard (like jQuery is) to make the decision to include it in core.

It's already been mentioned in this thread, but Underscore currently has a fork (lodash) which is a drop in replacement, improves performance, and fixes some bugs. It may be unwise to go with underscore at this point in time unless there's either an easy way to drop in lodash or an effort to bring lodash's improvements back into underscore.

In my opinion Drupal would be better served by spending time on allowing any front end framework to connect to it through REST endpoints, etc. It seems to me that if backbone were chosen as a core component the community would run the risk of making decisions that make the platform weaker as a back-end for other front-end frameworks in the interest of making things easier or more efficient with backbone.

mikey_p’s picture

I don't know much about Spark and how it is intended to be merged into core. If it follows the patterns that were established in Drupal 7 with overlay.module, contextual.module etc, then I would expect individual components of Spark to be in their own individual modules. If that's the case, why couldn't these libraries be provided by a module that contains them for the individual modules or Spark to depend upon?

While jQuery in core is one thing (and sometimes debated as being strongly opinionated) adding something like backbone to core in a non-modular way seems like an extremely opinionated move. As someone who spends most of his time overriding what core and contrib modules do, I'd rather not see Drupal core include another framework in its entirety, but rather lets include it in a way that can be easily removed or disabled. Semantically even putting it in module makes the fact that it's not required to use Drupal is a significant statement.

film42’s picture

Should probably be made better stated then as..

"I could also see Backbone being used to build an advanced block-to-region assignment UI.

The reason I'd like to see these two libraries in core (Backbone and Underscore) is the same that we have jQuery in core. It's standardizes the community on a library so that various modules aren't including their own frameworks, leading to competing frameworks in a site buildout. Having a common MVC framework will help standardize the application layer across these projects."

..is plenty ambiguous and I still feel the same.

ericduran’s picture

I'll keep this short.

So I like Javascript MVC's (AngularJS being my current favor) and I think underscore is a great addition to core.

That being said sadly I don't see how Backbone.js could be useful in core. I see the advantages of having them available but not sure it needs to be or belong in core. So the big issue is that a decent amount of the app logic is now going to be switching from php to JS not to mention I'm not even sure we have that infrastructure in core to take full advantage of these MVC framework.

From what I can tell we're trying to build mini MVC apps on top of core which I'm not sure is appropriate for Drupal core (But I'll let other people decided if that's cool or not).

Anyways just my $0.02

MFoster’s picture

Status: Needs review » Active

I would say there is certainly a need for a more formal javascript application stack/library within drupal. jQuery at it's best is a dom utility library that has many pain points when developing RIAs that are usually soothed by some extraneous 3rd party library. The benefit from this would be that it solidifies module developers onto a single stack for easier development and less requests for JS overall throughout a drupal site composed of many modules.

Backbone and really all other frontend JS frameworks are designed for single page apps, not CMSs.

This just isn't true, the Backbone model/view architecture could be incredibly beneficial. Drupal already has models such as, node, taxonomy, user...etc. Backbone could provide a smooth way to create and modify these models in the JS tier. However this will require server side support, which gets to catch's point. What value does this add to simply toss backbone/underscore into core?

I don't think it will be worthwhile until we can integrate it properly. Meaning that we build Drupal's models into Backbone.Models and work with the Backbone.sync operations to expose/leverage existing CRUD operations for these models. My vote would be not only do we incorporate them into core, but to build out an extension to the framework to serve the fundamental models of the drupal system.

corbacho’s picture

Priority: Critical » Normal

Disclaimers:

  • I've worked with Backbone.js daily for almost one year (but with a Python backend, not so much with Drupal except for demos)
  • I did a Drupalcon presentation about Backbone.js in the FrontEnd that is very related to this issue (specially my part, first 30 min, that is more conceptual and what are the benefits of Backbone). Ethan did hands-on-code part, see also his opinion at #9)
  • This is not about Acquia, this can help many other developers

Trying to focus on picking the framework (Dries #55):
Is this the correct framework ? Yes. Why?

  • Because it's focus: It's well written code and does only one thing, a MVC pattern in Javascript and that's all. In 2 years, the framework hasn't changed much, except bug fixes and couple of "naming" issues. This is the reason why is perceived as "becoming the standard": Stability.
  • Because of its minimal weight (5.6K gziped). And my guess is that it will never grow much, no bloat
  • Because it brings a dependency: underscore.js to core, one of the most useful and elegant libraries of little JavaScript helpers I've ever seen. Consider it as an extension of the JavaScript language and also as a fallback, because the library uses, when possible, ECMAScript 5 native methods. This has nothing to do with the DOM or jQuery, although they overlap in some methods like ($.each _.each, etc) (In the other hand, lodash.js is a 99% compatible alternative library to underscore.js that focus on performance at expenses of internal code readability)
  • From my point of view, the most important reason to choose Backbone is the documentation and resources. It's easy to find tutorials, articles (see Addy Osmani) and *thousands* of Stackoverflow questions. It has also growing a big ecosystem of Backbone "add-ons" around.
  • It's backend agnostic, so it could be easy to help integrate with other non-Drupal backends to fetch content (Think a central notification system with Drupal, Twitter, etc as sources for example). Even you can use non REST API backends.

So then, is Backbone.js the next "big thing" like jQuery?
No. Backbone.js is not the "next" jQuery. It solves only certain problems, and for sure it's not as easy to use as $(this).appendTo('body').animate() that even a kid can learn.
In technical words, Backbone.js is just a well-done Model View pattern implemented in JavaScript with a Events Systems and optional Router to handle paths (The router component is not used by Create.js/VIE.js for example, and probably neither in Drupal because is used as not-single-page app)
What are the benefits? It improves Separation of Concerns (decoupled code), Testability and abstraction. The awesome thing is it's only about 800 LOC and using plain JavaScript (no DOM == no cross-browser headaches), delegating everything to do with DOM (including events) to jQuery.
For the PHP guys: I would say Backbone.js could be the Symphony for the Frontend developers. Is it easy? No, but is worth it to produce beautifully structured code that you can feel proud at the end of the day? Hell yes.

Updating backbone.js
Backbone.js is about 2 years old and very soon (maybe next week?) is going to be released the 1.0 version. It has survived the "hype" very well and it's mature now. In fact, in all this time it hasn't changed much. It's the result of Jeremy's motto: "Don't add anything to Backbone.js if doesn't help to 80% of the developers"
Again Backbone.js it's not jQuery, in the sense that it doesn't has to deal with the hell of different DOM implementations across browsers, Backbone.js is about ECMAScript and this standard doesn't evolve so fast, so it wouldn't be very big deal to have an old version of Backbone.js during several years.

Thoughts against Backbone.js in Drupal core
I can think of some caveats, but they are mostly hypothetical:

  • Reusability
    underscore.js and jQuery are libraries of helpers, you don't change them
    Backbone.js is more a skeleton (even some people consider it as boilerplate) where you build your app on. So many times you will need to adapt the skeleton to your needs (override methods like .sync, model .fetch, add special handlers for events, etc, etc)
    So, I wonder if it can be difficult to build in top of 1 Backbone more than 1 suit without conflicts (a Drupal suit, a Edit-Spark suit, and other possible 3rd party-module suits).
  • I haven't played much with Angular.js, but the idea of placing data in the HTML, instead of the puristic Backbone.js perspective, where all the data is Server ---(JSON) ---> Model. Angular.js approach could be easier for jQuery developers, already familiar with data- attributes. Also it is the only library that could compete with Backbone in documentation because it has a dedicated team from Google to support it, test it and document it.
  • I'm bit (0.2%) concerned about the author of the library, meaning that he's quite opinionated, and Backbone.js is not driven by the community as much as I would like (we also have seen it when J-David forked its own underscore library, lodash). But this doesn't mean that is a bad thing neither. It gives stability and he's done great work imho.

Oops, sorry about how horrible long has become this post.

ericduran’s picture

Status: Active » Needs review

Also it should be noted this is not as simple as including jQuery into core. jQuery was/is the leading library in doing all the magic jQuery did then and still does now.

On the MVCs side is not as clear cut. There's a new MVC framework every other week.

nikkubhai’s picture

From my point of view, the most important reason to choose Backbone is the documentation and resources. It's easy to find tutorials, articles (see Addy Osmani) and *thousands* of Stackoverflow questions. It has also growing a big ecosystem of Backbone "add-ons" around.

Yes. And believe me it will also greatly help in attracting new developers. If technically, backbone and underscore can be included , I think we should not be hesitant to adopt these libraries. I mean Drupal is still good without them but why not make it better?

P.S. : This is the 1st time I have posted in drupal core issue. There was a lot that I wanted to say. But, maybe next time.

nikkubhai’s picture

Also it should be noted this is not as simple as including jQuery into core. jQuery was/is the leading library in doing all the magic jQuery did then and still does now. On the MVCs side is not as clear cut. There's a new MVC framework every other week.

Agreed that, there's a new MVC framework every other week. But, Backbone.js is still much more popular and used as compared to others. http://backbonejs.org/#examples . Maybe when jQuery was included, jQuery was not as dominant and leading as it is now.
Also, in previous comments, others have mentioned that if its not worth, these libraries can be removed same as twig.

film42’s picture

Adopting these libraries may attract new users, but it will push away a lot of current ones. The last thing I want the drupal community to do is to make quick decisions to drive in new blood. jQuery is great because it just works and it's amazingly easy to use. Backbone is fantastic and really taught me to good js standards. But a lot of developers would rather have an 'easy to develop on' system over a bloated stack software frameworks. I agree with corbacho and when I said Backbone is for single page apps, it's far to say that 90% of the time, that's what it's used for and I have a feeling he'll gladly stand by me on that. I agree that it is an amazing way to keep things organized but again, I feel that this isn't the right direction for drupal's core. As a fork of drupal? Maybe. But I would leave it as a job by job basis for developers who feel confident in these frameworks.

nod_’s picture

#75 is a really nice overview, thanks!

It's not because it's in Drupal that you have to use it. In core only the edit module and aloha-related things would be using it for now. Then it's contrib choice to use it or not. Replacing underscore with lodash sounds like a great contrib module to me :)

Crell’s picture

Historical note: jQuery wasn't the uber-library that it is today when Drupal first adopted it. It was one of a number of up and coming "make Javascript not suck" libraries, and was at the time in no way guaranteed to come out on top. I think Drupal adopting jQuery was a non-trivial factor in jQuery eventually coming out on top, but it wasn't an obvious "duh" market leader when Drupal 5 was in development.

It sounds like people need to pay attention to #80, though. The reason to add these two libraries to core is that CreateJs uses them. There's a fairly strong consensus that we want to back the Edit module with CreateJs, time and logistics permitting.

This is more akin to "we want to use jQuery UI for the Views-in-core UI. Is it OK to add jQuery to core, since we kinda need that for jQuery UI to be useful?" Unlike jQuery UI, though, there's a very clear set of tools that are in the pipeline that would make use of them. :-)

Naturally none of these would get loaded on every page, just pages where they would actually get used. At this point I would hope that goes without saying, but just to be clear, I'm saying it. :-)

cweagans’s picture

I strongly support anything necessary to get client-side code more structured and easier to manage, and this seems like an obvious win to me.

andyhawks’s picture

@film42 - I'm curious about the type of existing user that would be pushed away by inclusion of Backbone in core, because that's important to consider. I don't think it would happen though - as nod_ and Crell noted Backbone would not be mandatory, included only where needed, and can happily sit next to jQuery. If the argument is pushing away Angular/Ember/JS-framework-of-the-week users, again Backbone inclusion will definitely spur contrib modules for alternatives. And to the point re: single-page apps, this is not only a valid use case for Drupal now w/ services, it's recognized that it will be growing and expanding per WSCCI initiative.

As a Drupal developer by day (and night) I am seeing an increasing number of client projects where a JS-MVC becomes a requirement just in the past few months. That trend carries almost no relevance for core decisions, but as someone who has listened to client issues re: Drupal authoring experience on a weekly basis for years, I feel the needs of the Spark team should carry the weight in the decision here, esp. given how relatively low the impact of this is on core compared to Jquery or views-in-core. Considering Spark needs, WSCCI directions, established community of Backbone users, and even some Symfony+Backbone and Twig alignments -- +1 here.

cosmicdreams’s picture

+1 for including these libraries as it makes AMD for javascript even more important.

bmhaskar’s picture

+1 for including these libraries .

I really feel it's almost necessary to have a strong javascript framework to handle the data and representation in js, both these things are very well achieved by backbone.js.

bensnyder’s picture

+1 for this. thx @corbacho in #75

cweagans’s picture

Status: Needs review » Postponed

As much as I hate to delay this, I think #1787222 still needs to happen first, no? Based on that, I'm marking this postponed, but if you disagree, feel free to change it back.

effulgentsia’s picture

Status: Postponed » Needs review

Yes to #87, but setting to needs review anyway to encourage more feedback on +1/-1/or-x-is-better-than-backbone comments in parallel.

jpstrikesback’s picture

Yes, please.

meego’s picture

Priority: Normal » Minor

+1 for including backbone.js in core

Like wordpress
http://core.trac.wordpress.org/ticket/21664
or diaspora
http://devblog.joindiaspora.com/2012/01/10/client-side-re-write-oh-my
did for good reason in the past.

Love to use http://createjs.org/guide hand in hand with D8 in future.

nikkubhai’s picture

Priority: Minor » Critical
Ralt’s picture

I'm completely against including Backbone.js into Drupal core.

Backbone.js allows you to have modular code by providing an MVC architecture. That's cool.

Why do you need a framework to have modular code? Especially with the inclusion of AMD (#1542344: Use AMD for JS architecture, although I prefer browserify, but that's another matter), relying on a framework to organize your code is not needed.

Also, #13 seems pretty much ignored (I've seen it mentioned once), although it shows something that's been said several times: there are plenty of great javascript frameworks out there. Personally, I'd much rather have AngularJS which is backed up by Google than Backbone. Why? Well, why not. I haven't seen a single table comparing backbone with any other framework to see why it'd be better than other for Drupal as a CMS. And I'm pretty sure noone could come up with such a table (objectively made) that reeks of backbone inclusion in core compared to other frameworks.

Just my $0.02.

nod_’s picture

@Ralt: compare the size.

Ralt’s picture

@nod_: by saying this, are you comparing the complexity of the frameworks?

cweagans’s picture

Why do you need a framework to have modular code? Especially with the inclusion of AMD (#1542344: Use AMD for JS architecture, although I prefer browserify, but that's another matter), relying on a framework to organize your code is not needed.

@Ralt, That really sounds like a NIH argument, but I'll bite: there were a lot of reasons given for including it throughout the thread. We don't need to turn this into a Backbone vs $some_other_framework discussion.

Here's three good reasons:

1) Backbone is stable and the API is relatively unchanging.
2) AngularJS is something like 75kb (minified), whereas Underscore and Backbone combined totals up to ~9kb (minified). We already load a lot of Javascript. We don't need to exacerbate that problem, especially on mobile.
3) Edit module needs it.

Ralt’s picture

@Ralt, That really sounds like a NIH argument, but I'll bite: there were a lot of reasons given for including it throughout the thread. We don't need to turn this into a Backbone vs $some_other_framework discussion.

I'm not saying this should be a backbone vs someotherframework discussion, I'd much rather say it's "any js library vs just AMD", or "any js library vs how could we handle correctly any js library in core, including its updates".

1) Backbone is stable and the API is relatively unchanging.

That's a pretty good point that wouldn't be a problem without a proper system to handle updates. Because tomorrow, the library might do a very small change that may break everything. It's unlikely, sure, but it's possible.

2) AngularJS is something like 75kb (minified), whereas Underscore and Backbone combined totals up to ~9kb (minified). We already load a lot of Javascript. We don't need to exacerbate that problem, especially on mobile.

AngularJS is 80k minified, Underscore (16k) + Backbone (20k) is 36k (yes, both minified). Sure, it's twice as much, but it's still lighter than your logo. And probably cached because AngularJS is available in Google Ajax Libraries (while neither Backbone nor Underscore are).

3) Edit module needs it.

It doesn't need it, it would just be a nice addition. It's a nuance to keep in mind.

The discussion to handle JS libraries should be in another issue, but I think Backbone would just pollute Drupal. It sure would be nice as a contributed module, but definitely not in Core.

StevenWill’s picture

I am for a modular approach that allows for the addition of other JS frameworks.

killtheliterate’s picture

I haven't finished reading through all the replies yet, so forgive me if this has already been said.

I feel that, if anything, Drupal should be moving away from including js components in core, and instead towards something like making the library module core. Already, jQuery is extremely outdated in d7, and with young and rapidly developing JS libraries, this will be amplified.

Crell’s picture

I reiterate my previous point:

1) We want Edit capability. Pretty much everyone is on board with that.
2) I've not seen anyone really object to the Spark Layout Builder, which would be nice in core.
3) There's a clear consensus that, time and resources permitting, we want to back Edit with the CreateJs library, since that's an emerging standard for decoupled CMS functionality.
4) CreateJs uses Backbone and Underscore.

I don't believe CreateJs can easily not use Backbone/Underscore. (Wim and Bergie can correct me if I'm wrong, but that's my understanding.) So the options are

A) Put Backbone/Underscore in core;
B) Don't use CreateJs, which means a weaker, less code-reuse Edit module.

To everyone arguing for $other_library, please address *that* issue. Not just preferences, but *that* dependency.

To those arguing that core shouldn't "pick a winner", I overall agree... on a framework level. On a framework level we should force as few decisions as possible. But this is not a framework level question. It's an application/platform level question. Do we want to include Backbone/Underscore in the *application* level, in order to make our edit-in-place capability (which it seems almost everyone wants) stronger?

That is the question. Which library will be "winning" in 4 years is not the question. The question is do we accept the dependency chain for a CreateJs-backed Edit module: Yes/No.

adubovskoy’s picture

I feel that, if anything, Drupal should be moving away from including js components in core, and instead towards something like making the library module core. Already, jQuery is extremely outdated in d7, and with young and rapidly developing JS libraries, this will be amplified.

I agree with the opinion. Backbone expected to 1.0 release. Every version has new collections and bugfixes - it's young project and it is growing fast.

UPD:

Do we want to include Backbone/Underscore in the *application* level, in order to make our edit-in-place capability (which it seems almost everyone wants) stronger?

This is convincingly. But we still have "jquery problem". We used jquery in the core for the same reasons - support for internal (application) functional.

webchick’s picture

Please note that the "jQuery problem" is being resolved in #1787222: [meta] Strategy for updating vendor JS libraries within a major stable version and shouldn't interfere here with a technical assessment of Backbone.js and its competitors.

nod_’s picture

Component: ajax system » javascript
Status: Needs review » Postponed

Putting that in my backyard since it's where it'll end up being used.

Postponed on #1787222: [meta] Strategy for updating vendor JS libraries within a major stable version since that's the real blocker for this issue.

chx’s picture

Assigned: Unassigned » nod_
Status: Postponed » Active

The meta issue is rapidly achieving consensus.

It seems that there is no concrete, actionable "let's take X instead and we will do the Edit module on top". Short of that, given that there are people who have a dedication to add a much desired feature to core I am extremely strongly against blocking their work based on personal preferences. Even if another JS framework might be better, that's alas not helping anyone. We didn't have a community-wide debate whether Zend Framework, Lithium or whatnot is better but went with Symfony because the people who said "we will code web services" said "we want Symfony". Do-acry.

So I assign this to nod_ and ask him that short of serious technical deficiencies to approve going this forward.

msonnabaum’s picture

I did my best to read this thread, but it's rather large, so forgive me if I missed something.

From what I can tell, there is a lot of confusion around why we want to bring Backbone in and what the implications are.

I'm not really seeing the details on what we need from it, but I would assume that we aren't committing to Backbone as a framework, we're just using the parts of it we need. If we just need data bindings, that means Backbone.Events, Backbone.Model, Backbone.Collection, and maybe a few others. I dont see us building single-page apps in Drupal core, so we wouldnt be using stuff like Backbone.Router.

Talking about this in terms of MVC is misleading (ignoring the fact that backbone is NOT MVC), we're just talking about data bindings.

With that in mind, I don't see this as a huge commitment. Modern javascript MVC/MVVM/MVP frameworks are just a collection of (ideally) decoupled modules. We should be able to mix and match as needed to implement the features we need. We could even extend the backbone objects and not expose them as a public api to contrib (clearly we can't actually hide them, but we could forbid it).

So if we need a data binding framework to implement D8 features, let's just f-ing commit the pieces we need from Backbone already. There's no way we're going to be able to decide on a framework in the abstract.

Also, no one should be talking about underscore; It's implied with backbone. If we want to consider things like lodash (which I like), that can be a performance follow up.

nod_’s picture

Status: Active » Reviewed & tested by the community

What chx and msonnabaum says.

I'm all for getting this in and let the edit module use it. I postponed to avoid needless bikeshed. the Strategy thread looks good and patch in #29 still applies.

catch’s picture

I'm fine with this going in on the basis of "we aren't committing to Backbone as a framework, we're just using the parts of it we need."

If patches start showing up that go beyond that, we're going to need to review them case by case. Also great to see the other issue RTBC (although I didn't catch up with the overnight comments on it yet).

cosmicdreams’s picture

Had a great chat with a few of our JavaScript pros. They had a lot to say about the plan (mostly good things). Stay tuned, they had three main suggestions for our work:

1. Timeline drives addition of backbone now

Given the current timeline and the importance of this feature they advocated adding backbone and eventually lodash. Given that we are wanting to use Asynchronous Module Definition to allow js developers more control over the javascript that is loaded in their Drupal projects, using lodash is key as underscore has recently removed all AMD support.

2. Create a Bridge to handle backbone.js's possible instability

Backbone.js has changed rapidly in the past year and it is likely to continue to change rapidly. A developer that knows backbone well described the changes in the past years a complete rewrite. We should be wary of backwards compatibly support and guard against the headaches breaking backwards compatibility in a future release might impose on Drupal.

Also, they noted that since backbone will be in core, it's likely that module and theme developers will use it. They'll figure out a way because js devs are crazy ninjas like that. We need to protect these developers for breakages as well.

To accomplish this we should wrap backbone with our Drupal namespaced javascript library, create an API for using backbone within Drupal, and then eventually evolve the API to handle Event registration, Data binding, etc so that if Backbone breaks, we fix our API's implementation of backbone and warn the adventuring themers and module developers that chose use backbone directly that their work broke as a result.

3. AMD is super important

AMD will allow our javascript developers a good avenue for getting into Drupal as their work is now standardizing on this methodology. I'll see If I can get them to stop by to make a strong case for that but I just wanted to reiterate that they consider it extremely important.

Dries’s picture

@catch: it looks like both backbone.js and underscore.js are two relatively small JS files. I could be wrong though.

Ralt’s picture

@Dries: The problem is not about the size of the files, but rather about the way we're going to use it. Implementing them just so that we can use them for Spark is fine, but the patch shouldn't grow to integrate the framework with Drupal core. (I'm thinking about the Drupal object or the behaviors that integrate JavaScript with Drupal core behavior.) This problem will disappear with #1787222: [meta] Strategy for updating vendor JS libraries within a major stable version though.

webchick’s picture

Oh, no one is suggesting that. Just having bundled in as an option for module developers to use, like jQuery UI, when Backbone would be the Right Tool For The Job™.

RobLoach’s picture

A bit off-topic, but in regards to a few other issues, should these be in their own respective modules to help reduce bloat in System module? What I mean is:

  1. Add a Underscore module, which would declare underscore_library_info()
  2. Additionally, have a Backbone module, which would depend on Underscore module and declare its own backbone_library_info()
  3. If people want to use an upgraded version of Underscore/Backbone, they could install the Underscore contrib module. Drupal already replaces any core module with one from contrib if it finds it.

I still would much rather have a package manager handle the dependencies for us though. However, that's an entriely different discussion :-) .

webchick’s picture

Ok, I think I mis-read catch's comment in #106. I believe he's saying "We can commit the library, but not commit to using it to replace everything in /misc" and I think everyone is 100% on board with that.

While #1787222: [meta] Strategy for updating vendor JS libraries within a major stable version is not quite wrapped up (Dries has some concerns, for example), there are two solid directions proposed there, one of which has growing community consensus around it. Dries feels strongly that that issue should not hold up features in the meantime, and I'm inclined to agree. I think we got our desired effect of getting people to pay attention to the issue, and now it's a matter of wrapping things up over there.

So, barring further objections, I'd like to commit this on Monday.

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Ok, it's now Monday, no news over the weekend. I guess this is good to go.

Committed and pushed to 8.x (with CHANGELOG.txt entry). Thanks a lot everyone for the discussion here! Here's to more front-end excitement in Drupal 8! :)

Wim Leers’s picture

Interesting in this context: the JS lib poll by ppk is also indicative of how widespread Backbone.js usage is: http://www.quirksmode.org/blog/archives/2012/10/javascript_libr_1.html. jQuery is used by 91%, Modernizr by 58%, underscore.js by 33% and backbone.js by 30%.

Wim Leers’s picture

.

klonos’s picture

...I realize I'm coming late here and that what I'm about to say might seem OT (I think not), but I really think we should be focusing on getting #667058: Add a libraries folder with a README.txt in it to DRUPAL_ROOT in. Then things would become more "pluggable" and people/modules could easily use whatever they so choose. For example Spark devs could use whatever they wanted to work with and people wanting to enable in-place editing in D8 would simply have to download whatever that module had as a dependency. We would most likely not be having this conversation here and perhaps with the help of stats gathered (#1036780: Drupal.org should collect stats on enabled sub-modules and core modules) would know if something was worthy of inclusion in D9 core (so to spare 95% of users from downloading extra 3rd party requirements).

If it so happened that the requirement changed to a new better/faster/cooler library then things would perhaps be as simple as supporting both and providing a respective section with instructions in the README or in the site status report.

Just my 2c too.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Pancho’s picture

Would we want to have a change notice for this?
Certainly no API change, but it wouldn't hurt being noticed...

cweagans’s picture

Can't hurt. I say go for it.

Pancho’s picture

Title: Add Backbone.js and Underscore.js to core » Change notice: Add Backbone.js and Underscore.js to core
Priority: Critical » Major
Status: Closed (fixed) » Active
Issue tags: +Needs change record

Fine, however this preferably should be done by someone who is really into it and can describe what Backbone and Underscore buy us resp. module developers. Marking major only, because it is no API change notice.
Maybe @nod_ or @cosmicdreams?

nod_’s picture

Issue tags: -Needs change record

It's in the changelog already don't feel it's necessary but if someone is up for writing the change notice go for it.

nod_’s picture

Issue tags: +Needs change record

tags…

marcingy’s picture

Category: feature » task
xjm’s picture

Priority: Major » Critical

I also think a change notice for this would be helpful. Filing appropriately.

jessebeach’s picture

Status: Active » Closed (fixed)

Change notice posted: https://drupal.org/node/2053901

nod_’s picture

Category: task » feature
klonos’s picture

Title: Change notice: Add Backbone.js and Underscore.js to core » Add Backbone.js and Underscore.js to core

...

klonos’s picture

Issue tags: -Needs change record

...

klonos’s picture

Issue summary: View changes

Clarifying that core Spark modules are for core inclusion.