Backbone has made me a better programmer

indexOf returns -1 if the query isn't found in the string; -1 is usually represented as all bits 1, so a bitwise not on -1 is 0, which when converted to a Boolean is false. So ~x is more-or-less equivalent to x != -1; but its a bit obscure, and seems like bad style to me (indeed, I'm not even sure if the ECMAScript standard guarantees that -1 is stored as all bits 1, so it may not even by correct).

`indexOf` returns -1 if there's no match.

Bitwise NOT on -1 will give you 0 -- for any other number, it'll return a truthy value.

It's the same as:

`return item.toLowerCase().indexOf(this.query.toLowerCase()) !== -1`

If you're really dead set on doing things this way, it's safer to prefix with !! to coerce a real boolean:

`return !!~item.toLowerCase().indexOf(this.query.toLowerCase())`

Yeah, but -1 isn't represented in IEEE 754 floating point as all bits one, is it? The ECMAScript standard specifies that the bitwise operators work by first converting their arguments to 32-bit signed integers, but at least how I read it, it doesn't actually say anything about how these 32-bit signed integers are represented (which implies that they continue to be represented as IEEE 754, which isn't how browsers behave, and wouldn't be very useful).

I will be waiting for the day when you will be introduced to angularjs.

TL;DR - This was originally a reply to another commenter. There seems to be a lot of people accusing Backbone of failing to provide things that it has never claimed to provide. This is a bit of a rant so apologies in advance! Obviously YMMV but I've been batting these criticisms of Backbone away left, right, and center recently.

To summarise: If you need a framework, then Backbone is not what you're looking for. Use something else, because in all likelihood Backbone will not give you the tools you're looking for. Backbone solves a different problem.

====

The only real 'major' problem with Backbone.js is that people for some reason think it's a framework. It is not, and as far as I'm aware it has never claimed, or attempted, to be one.

The real, underlying problems that Backbone attempts to solve are the following:

1: Unstructured, spaghetti JS code.

2: Complicated DOM traversal / outrageously convoluted jQuery selectors.

3: Total lack of templating.

4: Generally crap organisation of your application.

Customers / users are constantly requesting more dynamic pages. You know that form which adds a new item to the Foo list? Why does it have to refresh the entire page? Why can't I drag and drop stuff like I can with every other application I use on my computer?

Customers are realising that they CAN do cool stuff in their browser now, and you better believe you're going to get a call asking you to turn a previously read-only site into a fully dynamic web app. So you do what every other dev does and rewrite the whole thing from scratch using a proper framework and it's all nicely designed and fully specced out. Or not. What actually happens is your customer doesn't have enough money for a re-write. They want all the existing features, but they want the development phased. Your boss / colleague / dog wouldn't let you re-write the damn thing anyway because they assume that it's just a case of cut + paste from another application somebody who no longer works there wrote 10 years ago. So you do it step by step. You do it page by page / feature by feature. That page which displayed a list of items now displays new items automatically, you don't need to refresh the page! Adding a new item is a simple AJAX call back to the server. Notifications? Done!

And then a bug is found. Suddenly you realise you have no real way of isolating your model from the DOM. You're hiding data in hidden input fields so you can retrieve it via jQuery later and do something with it - maybe some AJAX request to the server. It takes you a day to fix a bug that should only take 5 minutes. It takes you a month to add a new feature that should only take a few days.

It seems like only in web development do developers have this (when you think about it) really, truly, WEIRD approach to building applications. We let the data provider build our user interface. We don't bother with models - just hide data in the DOM and get it back when a user clicks a button. Need to represent the same data in two different ways? Build a new View in your rails app and add a ton of logic to change how it looks based on the model's data. Why do we have an MVC framework server side and then forget all about it on the client-side?

When you think about a web application PROPERLY, the insanity becomes obvious. In what other development domain do we allow the data provider (the server) to render the user interface? Why do we discard models and proper encapsulation? Why do we weave logic into views which should really live in a model / controller? What the hell have we been doing to ourselves?

A lot of web app developers think they're building the following:

  Server (Model / Controllers) - GIMME DEM HTMLZ -> Browser(View)

What they SHOULD be thinking about building is:

  Server (Data Provider / API)  Client (Model / View / Controller)

The fact that you're using HTML and JS to develop an application is merely incidental. Your server provides you with some data - it's insanity to also let it define what that data should look like when it arrives client-side.

Backbone.js aims to solve THESE problems. It is not an application framework. It gives you a few basic objects and hopes a light bulb flickers on above your head. Suddenly you realise that hey - you CAN isolate your models from your views. You CAN have multiple views per model. You CAN have proper event handling, just like you can in every other non-web application you've ever written. Hurrah! Need to extend your model? Easy! How about displaying the same model - once as a full page, once as a widget in a sidebar? Simple! Need to update the view when your model gets updated? Piece of cake!

Backbone is a solution to a lack of structure. It is not a framework. There is no convention, no 'right way' to do things. Backbone is exactly what the name suggests: a spine for your application. Everything else - your framework, your error handling system, your security mechanisms - these are all left for you to figure out yourself. You can pick a framework built on top of Backbone, or you can figure one out for yourself. Backbone doesn't magically turn your web app into a modular, extensible system - but try to build one WITHOUT Backbone or something similar and see how far you get before you realise you've got serious problems.

  > Nested views and automatic view updates.

Not Backbone's problem. It doesn't even attempt to solve this issue as far as I'm aware. Solve it yourself, or use something which does.

  > How would you display a list of items in backbone? What do you do when an element is removed/added?

How is this Backbone's problem? How would you do it in any other programming language aside from JS? Port it to JS, and your problem's solved.

  > How do you update a view when an element changes?

It SHOULD just be as simple as calling your render() method? If your rendering code is incapable of not fucking this up, then it's your own fault.

At the end of the day - Backbone is not there to hold your hand. If you can't figure the above problems out on your own, then Backbone is probably not for you. Backbone is even agnostic about how exactly you draw your views onto the page. Want to stick a shit-ton of logic in your template? Fine - but leave Backbone out of it - that's between you and your templating engine!

Backbone gives you a solid foundation. Everything else is just arms and legs.