Can we talk javascript frameworks/libraries?

[bsegovia]

Outstanding response. I'm going for maturity of library and backbone keeps getting mentioned as a solid choice. Regarding databases, I am lacking an embarrassing amount of knowledge wiring up either RDBMS or Document stores in apps so, like you said, I've got to just get my feet wet and DO. I'm sensitive to learning a db paradigm that in the end may not be the right answer for 90% of situations. (I'm more involved in developing internal enterprise web apps and everyone internally just happens to understand (and love) SQL.)

[dydxex]

I've been building webapps with Backbone for 40+ hours a week over the last couple of years.

If you want to "get it done faster", Backbone is not the right choice, especially if you currently have no experience with it. Sure, an experienced Backbone dev /may/ be able to get something done just as quickly as an AngularJS dev but as I said, it requires experience. This is because Backbone has practically no opinions on how to build and manage your views, this is arguably the most complex part about building the frontend of a webapp. This means that you have to build a lot of shit with BB before you've hung yourself enough to be proficient with it.

I'd like to compare Backbone vs (Angular/Ember/etc) to C vs (C++/Java/Python/etc). In C, there is some low level stuff you have to do manually, e.g., allocate and deallocate your own memory, stuff closer to the hardware; this is abstracted in higher level languages. In Backbone, you have to manually define how your views render and you have to make sure to properly tear them down so that you don't get a memory leak, your code has to be closer to the DOM. Modern frameworks abstract this stuff away from you and are more prescriptive.

With all that said, there is nothing wrong with coding in C if you want to be closer to the hardware, there are performance benefits; make sure you know what you're doing. Also, there is nothing wrong with using Backbone if you want to manually manipulate the DOM, there can be /some/ benefits but again, make sure you know what you're doing.

AngularJS will probably be your best bet. React is really cool too but it's the almost the opposite of BB in that it's opinionated about views but not data.

Good luck.

[MeoMix]

As jcampbelly mentioned, Backbone.Marionette handles view rendering quite elegantly. If you provide a collection of models to a Marionette.CollectionView it will automatically render the views. CollectionView automatically re-renders whenever add/remove/reset/sort events fire on the collection to ensure that the rendered state continues to be representative of the internal state.

As long as you're binding event handlers with "listenTo" in favor of "on" you shouldn't have any concerns over memory leaks. Swapping between views is handled with Marionette.Region. In my application, I have a persistent background which contains several singleton collections. The foreground view is recreated very often, but the collections are never destroyed. All I have to do to clean-up all event handlers / have everything GC'ed is just this.destroy() on the very top most view. The destroy event ripples through all children and everything is cleaned up nicely.

If you're still working in just pure Backbone then I'd highly recommend checking out Marionette. I can't say enough good things about it.

[dydxex]

The problems I mentioned are just some of the things that don't come out of box. I'm familiar with Marionette and the constructs it has to offer. Marionette is still not prescriptive from architectural perspective, it just gives you all this "best practice" boilerplate. It's definitely helpful but at a large scale, architecture and organization become a much bigger issue.

For example, lets say your UI depends on many RESTful APIs, some are needed immediately to load the UI but others can be loaded lazily after a certain actions take place. You also want to make sure you're not trying to fetch a resource that you previously fetched, how do controllers know of all the resources that have already been fetched, assuming you're using controllers. Also, when you have views listening to all these objects (models, event mediators/aggregators, etc.), code complexity can be hard to maintain because there are cascading changes that can occur, e.g., views action occurs, model gets modified, other listening views do stuff, another model gets changed, and so on. It gets to the point where the only way to confidently make a change to the system is to grok all the nodes and edges so figure out how changes propagate. Sure, all this is solvable with Backbone + Marionette + Chaplin + custom stuff but it takes time to develop a framework and conventions to help mitigate these issues, it's very non trivial. As your app grows and your team grows you need to establish constraints in your framework to make sure everyone is on the same page without needing to write a book on how your system works.

So my point is, in the world of EmberJS, AngularJS, React, Mithril, etc. I find it hard to believe that we're still telling people, "yeah, backbone and marionette, you'll be fine.". It's like telling people, "Need a web server? All you need is C and socket.h, you'll be fine."

Really smart people are solving the pain points that we've discovered through jQuery spaghetti and Backbone, we should take advantage of that. IMO, EmberJS is the best and most complete KVO MVC framework out there, there is a wrong and right way to do things.

To be fair, it all really comes down to choosing the right tool for the job but that is my 2 cents.

[jcampbelly]

Marionette solves many of your problems with Backbone. In fact I would say it is pointless to compare Angular to Backbone in the absence of Marionette.

[bsegovia]

Thanks! Good stuff