Compare JS MVC frameworks implementing the same site: TodoMVC(addyosmani.github.com)
addyosmani.github.com
Compare JS MVC frameworks implementing the same site: TodoMVC
http://addyosmani.github.com/todomvc/
9 comments
(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.
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.
The thing is, not everyone got the time to wade through the mass of JS frameworks available today. The intention of TodoMVC is to give you a taste of each framework, which can help you narrow it down. You can think of it as speeddating JS frameworks. It's by no means perfect and I agree that it should not be your only source, but it's a lot better than just trying out the most popular one and using that.
Disclaimer: I'm one of the devs (Sindre).
Disclaimer: I'm one of the devs (Sindre).
Yeah, it's worth noting that picking a common baseline for comparing frameworks is like trying to pick common benchmarks for programming languages.
Sure you can write comparable code... but writing benchmarks in multiple languages in an idiomatic style that plays to each language's strengths while still remaining comparable is challenging.
Sure you can write comparable code... but writing benchmarks in multiple languages in an idiomatic style that plays to each language's strengths while still remaining comparable is challenging.
where can we find information on what the different libraries choose to do differently
I'm genuinely sick of seeing todo apps being implemented, and in this case, compared, in various languages.
It's simply not a complex enough app (ie: no authentication/login system) and serves only to give the highest level of an overview about a framework.
Actually getting down into the nitty gritty side of things (which includes everything from authentication, validation, and templating, to routing, persistence (both sql and no-sql), and XHR/we sockets) is crucial, in my eyes, for us to really see how a system can grow from an intro-to-framework-X into the next-big-thing.
Obviously, there's a requirement to actually learn the language/framework that you end up choosing, and therefore there's no real benefit to having a copy/paste sample app that includes the kitchen sink, but damn, I'm sick of recreating the wheel.
Actually getting down into the nitty gritty side of things (which includes everything from authentication, validation, and templating, to routing, persistence (both sql and no-sql), and XHR/we sockets) is crucial, in my eyes, for us to really see how a system can grow from an intro-to-framework-X into the next-big-thing.
Obviously, there's a requirement to actually learn the language/framework that you end up choosing, and therefore there's no real benefit to having a copy/paste sample app that includes the kitchen sink, but damn, I'm sick of recreating the wheel.
This is great. I've been considering moving to a client side MVC as opposed to relying on GAE. I started messing around with Backbone.js and I really like it. What are the downsides of client side MVC as opposed to server? Is it easy to bog down the client with the extra processing?
Is it easy to bog down the client with the extra processing?
Sure, if you're not careful; but that's the case w/any language or layer of an application stack. I'd consider becoming familiar w/JavaScript a greater concern though. Learn to avoid JavaScript's foot guns, and use tools like Speed Tracer to help profile your JavaScript.
If it matters, my time tracking and invoicing product uses heavy client side processing, to the point where some of its reports never touch the server. We're seeing response times in the low ten's of milliseconds when relying on JS-only generated reports.
Sure, if you're not careful; but that's the case w/any language or layer of an application stack. I'd consider becoming familiar w/JavaScript a greater concern though. Learn to avoid JavaScript's foot guns, and use tools like Speed Tracer to help profile your JavaScript.
If it matters, my time tracking and invoicing product uses heavy client side processing, to the point where some of its reports never touch the server. We're seeing response times in the low ten's of milliseconds when relying on JS-only generated reports.
Makes sense, there's no one answer to my question, because there are so many variables involved. So, it will take trying them out and of course it will depend on my needs. It may even make sense to do server side on some parts of the site and client side on others. I like the idea of being less constrained to my backend technology, which is what attracts me to JS MVC. I also like how concise Backbone.js is, it doesn't seem to try to do too much.
SEO can be a nightmare if you're going totally single-page (you really have to go with a solution where you can render your javascript templates server-side if someone directly requests a page); though we've found that bounce rates go down considerably when navigating between pages is near-instantaneous.
This is a fantastic idea. I love the breadth of frameworks covered. Are you having to solicit developers to create their own example? Nicely done.
Slightly related, I'm looking for a MVC Node.js framework, that is, one that runs on the server. Does anyobody know one?
Edit: Just got this one from another post on the front-page https://github.com/mde/geddy.
Edit: Just got this one from another post on the front-page https://github.com/mde/geddy.
Express is pretty great, very bare-bones though.
Why limit it to Javascript? This would be a fantastic way to learn any framework or language.
Leaving the browser makes the "problem to be solved" into something so unspecified the comparisons would stop having value..
A todo list encompasses many basic entry points a piece of software must accommodate:
1) interface 2) database 3) adding/removing from said store 4) sorting 5) class structures ...
I could go on. Essentially, the best way into any language is to know how something is supposed to work and compare it to how it appears to be working, making those more difficult leaps by actually practicing.
1) interface 2) database 3) adding/removing from said store 4) sorting 5) class structures ...
I could go on. Essentially, the best way into any language is to know how something is supposed to work and compare it to how it appears to be working, making those more difficult leaps by actually practicing.
Love this idea! I need to get more familiar with a lot of these frameworks
todomvc is a good way to make people aware of the different frameworks and gives a quick guideline to their "style". If anyone is doing anything more complex then they should be spending the time on each framework's page to evaluate which one has the features they need and if the framework's own documentation and website hasn't got documentation that you need then you probably shouldn't be using it anyway.
I like this idea. One request: I wish there were more convenient links to unminified source for each of the examples.
To that extent, I have to apologize for publishing the original Todo example app ;)
While TodoMVC is a fine resource, I think it's still important to look at what the different libraries and frameworks choose to do differently ... and most importantly, what sort of real apps have been built with each.