legacye

@btipling

"Burn this article in a fire" :)

Looking back through my article I agree that stating delete should outright never be used didn't make sense. It's of course used in numerous JavaScript libraries and has a purpose in the language. I've updated the text to reflect my suggestion that it should be instead, avoided where possible. This advice stands as it's more difficult for V8 to optimize objects you're changing the structure of.

For others commenting on this thread, I've also taken account of some of your suggestions and tried to update the article to be as accurate as possible. Thanks for the input!

(tl;dr I created TodoMVC and agree with many of the points @jashkenas makes above)

Whilst at present TodoMVC provides a simplified baseline for comparing JavaScript MV* frameworks, we feel that this at least gives developers an opportunity to narrow down the list of them they wish to explore further. No one should be using TodoMVC as the be all and end all of which framework they use as there's significantly more to it than that. That would be a little silly :)

With respect to the comment lower down in the page regarding the nitty gritty not being covered (auth, validation, routing etc.), it's a valid point and we currently have plans for tackling this in version 1.1 of the project. Initially Backbone.js, Spine.js, Ember and CanJS will have complete end-to-end examples offered but we hope to expand upon this as we work our way through releases.

At the end of the day, our goal is to make it as easy as possible to find the framework (or frameworks) that best fit your needs and hopefully give you some incentive to investigate one or two in more depth before making your decision on what to use.

For anyone else running into traffic/timeout issues with GitHub, you might have better luck with this tagged version of the above project https://github.com/addyosmani/backbone-fundamentals/zipball/...

They're used to construct an API that interacts with Backbone (see the practical section). The whole point of the post is to demonstrate how straight-forward it is to move from persistance using something like say, the localStorage adapter over to something with an actual datastore.

Hey guys - I wrote this. Just to point out: this project is really just a proof of concept. I haven't personally seen any figures to suggest that localStorage caching is more optimal than standard browser caching, but once these benchmarks are available (hoping to get them up on jsPerf), they'll be posted to the same page.

Hey guys - Addy (author of this mini-book here). Although the current edition is very much targeted at beginners, I'm working on a significantly more detailed version this summer which will also be released for free.

To those who have mentioned some patterns are indeed better suited to 'classical' programming languages, I completely agree with you - the reason I've included a mention of them is so that developers who may not have read the book by GoF get a little historic exposure to why those patterns were defined and where they fit in.

There will be a lot more JavaScript-centric content in the next version with a little less focus on the traditional patterns.