Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Discussion about the role of TodoMVC #83

Closed
addyosmani opened this Issue · 7 comments

4 participants

@addyosmani
Owner

Both Yehuda (Ember) and Jeremy (Backbone) were in #documentcloud today discussing their frameworks, misconceptions and options on modular solutions like AMD. TodoMVC came up briefly and I wanted to discuss some of the comments that come out of that portion of the talk.

Jeremy commented that he thought this project was somewhat silly as Todo apps shouldn't be the way people decide on a framework. In his opinion this should be done by browsing the source and looking at serious applications built with it .Yehuda felt the project was at least better than how people were going about comparing frameworks in the past so that's at least something.

I agree with J's assertions to a degree, but imo the Todo app presents a gateway solution for easily comparing syntax and structure. It was also mentioned that none of the apps cover routing, something both developers felt was necessary for a true comparison (Yehuda mentioned a proper routing solution for ember.js was probably a month off).

I'm wondering based on this feedback if we should be revisiting a ticket that came in a while back to add routing to all of the Todo examples. This could be as simple as providing a way to link to individual Todo entries (with a routed view), however it would represent a change to our template and slightly more work to changing the apps.

I also think that we should revise our project readme/site when we get a chance to more strongly point out that we don't consider TodoMVC apps the end-all of how people should be choosing frameworks. I thought this was relatively clear before, but if it can be improved perhaps we should.

Open to thoughts on the above and other ways we can improve the project that we may not have considered. I think it's better to look at these now as we're still in a phase of rewriting existing apps.

//cc @boushley @sindresorhus

@boushley

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.

@sindresorhus
Owner

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
@webpro

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.

@boushley

@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.

@addyosmani
Owner

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!

@webpro

@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.

@addyosmani
Owner

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.

@addyosmani addyosmani closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.