Discussion about the role of TodoMVC about todomvc HOT 7 CLOSED

I agree that the todo application is a bit simplistic for comparing all of these different frameworks. However, I definitely think there is value in the project as it stands today, and think that updating the apps to meet a common template is still a very important task to make comparisons cleaner.

I'm not sure I fully understand Jeremy's opinion from your comment, I'm going to assume that his opinion is that the Todo app is too simplistic to be able to really see how the framework is used. It also sounds like he is pushing that people should view the source of the project in making their decision as well. I agree that the current Todo application is overly simplistic for what we are trying to compare, but I also believe that seeing an application built on the framework adds value beyond just viewing the source of the project. As you said we expect people to use other factors in making their decisions as well.

To address the over simplicity concern I think we should come up with a set of features we want to show in the Todo application. I think we should come up with a list of all these features and then we can think of how we can change / extend the app to show all of these features. (It might be helpful to list all of the tasks we're currently showing with all the features we have. If there are features we're adding currently that don't show something new/different it probably isn't worth the effort to add it to all of these implementations) You brought up routing as one thing that we should try to demonstrate. We could probably even take this list and make it a Wiki where we list the features we try to show from the frameworks and what parts of our application demonstrate them.

As we do the redesign of the site we should definitely consider ways that we can help people find other methods of evaluating the frameworks. We could link to good blog posts/articles, we already link to the source, maybe we can make it clearer that we think people should read through it.

from todomvc.

Jeremy commented that he thought this project was somewhat silly as Todo apps shouldn't be the way people decide on a framework.

Then why is the first example on the Backbone site a todo app? :P

IMO the todo apps are there to make it easier for devs to quickly try out multiple frameworks and get a feel of how they work. It's in no way meant to be an extensive comparison, thought devs got that. TodoMVC is more like speed dating. In a short amount of time you can get a superficial view of their inner workings. But it requires a lot more time and dedication to be able to fully understand them, and make an informed decision. I agree, we should probably point that out more strongly.

I kinda like the idea of routing, even though it might be a bit overkill on a simple todo app, it improves the quality of the comparison. We could add routing to filter: All todos, completed todos, uncompleted todos, in addition to the be able to go to a single todo.

@boushley is right. We should come up with a specification on what we want to show. Let people comment on it, especially framework creators, and then create a complete spec in the Wiki.

We could also have a wiki page with good articles we or our user found useful in deciding about a framework.

I have a few ideas on what more that could be done, though we must try not to bloat them with too much good stuff:

• Reordering of todos (the Backbone todo example got this. Shows how the collection works in different frameworks)
• Search (Nice to test out the routing and collection, though might be somewhat of an overkill)

Not important in comparison, but just to make it better:

• Print style (Some people still like to print their todos)
• Responsive: mobile/touch optimized, using Media Queries

from todomvc.

The todo implementations may seem simplistic at first, but it does show what developers want to see first. Code and syntax: how does it feel? Extending this with a lot of features is overwhelming at first.

Having that said, it would still be great of course to also provide more extensive examples. But I would really recommend not to ditch the basic todo app.

By the way, the other day I started an example application using Backbone, which I will also develop in at least Knockout. It will be a simple portal, having "widget containers" and the actual widgets. Plenty of additional features to explore then, such as nested views, and routing (e.g. linking to specific widget to highlight or maximize). Perhaps I'll include drag & drop (just native), which re-orders the collection of widget containers. Etcetera.. This might be a starting point, or inspiration to you guys.

from todomvc.

@sindresorhus I like your analogy of speed dating. I really do think there is value here, even though most of these frameworks are overkill for this simple of an application. I think we should follow up with creating a list of things that we are currently demonstrating and things we would like to demonstrate within the context of a short "speed dating" application.

It's good to hear that there are other comparisons in the work (like @webpro 's projects) that may be more in depth. At some point it may be of value to include these more in depth projects, but for now I think we should stick with the "speed dating" frameworks idea. This idea of being the "speed dating" for frameworks also continues to let us include the module frameworks for comparison. "Speed dating" also works well because as in real life, speed dating isn't for everyone, and in the same way our comparison may not be for everyone, but I think it provides significant value.

@addyosmani What do you think of using this Speed Dating idea in the redesign? Make it clear what we're targeting and could give the project a quirky / memorable look.

from todomvc.

To address the over simplicity concern I think we should come up with a set of features we want to show in the Todo application. I think we should come up with a list of all these features and then we can think of how we can change / extend the app to show all of these features.

I completely agree with this. At the moment I feel like we're covering many of the basics, but I would love for us to be doing more. In a perfect would I would imagine Todo apps that are tied back to a proper CRUD backend so we're not just demonstrating working with local data and no real routing. That may however be a step too far, but as I've mentioned I think routing would definitely be something worth covering as a part of our rewrites.

What do you think of using this Speed Dating idea in the redesign? Make it clear what we're targeting and could give the project a quirky / memorable look.

I think that's a very good idea. It really hits home the point about what we're trying to offer and a level of clarity offered through related visuals would prove useful for certain.

Perhaps I'll include drag & drop (just native), which re-orders the collection of widget containers. Etcetera..

We previously discussed the idea of reordering and I think our conclusion was that it may have been unnecessary. I'm open to us reconsidering if someone can justify a benefit in terms of helping us compare frameworks.

I kinda like the idea of routing, even though it might be a bit overkill on a simple todo app, it improves the quality of the comparison. We could add routing to filter: All todos, completed todos, uncompleted todos, in addition to the be able to go to a single todo.

I like this. It may even make more sense than just routing to individual todo items, though, we could cover this of course.

On the whole, I think that this project won't be negatively affected by J's comments, but at the very least it's prompted us to reconsider how we're aiming to improve it for the first major milestone release. I see that as a great positive and I appreciate all the input everyone has been providing so far!

from todomvc.

@addyosmani This portal example wasn't meant to provide features this Todo app should have. On the other hand, I think the (re)ordering of models/collections versus view handling is extremely helpful in both understanding MVC and comparing frameworks.

from todomvc.

We ended up revising some of the text in the readme and the way we portray the project in public based on this thread. Closing for now but if we need to re-open for further discussion we can do that in the future.

from todomvc.