Code comparison tool

[addyosmani]

Since day 1, we've wanted to have a way to easily compare different implementations of the TodoMVC apps but it's been hard for a number of reasons. Apps have different file structures and it's not always as easy as saying 'lets compare view:view'. A code comparison tool that solves this problem, letting folks more easily see how one framework might structure a piece of an app vs another could be quite useful.

[paulmillr]

Not sure about tool, how can it feel?

Maybe make a list of features and a list of implementations (codes) under each feature?

[stephenplusplus]

In my opinion, I think being shown the code that say, creates a View, and how it looks ( App.View.extend({}) ) compared to another framework isn't super useful. Since we're all builders and already curious about frameworks to the point that we're using Taste, we've almost certainly already downloaded the source code and have it in our editors. We will count on well-written comments and good companion documentation to help us see what's happening. I'll call that "after the hook," where the user has downloaded the source, and then talk about the "before the hook" experience we can offer.

I had a suggestion for TodoMVC the other day, that's only an inch or two short of impossible to implement now that TodoMVC has grown so large. However, since Taste is just a young little monster, would anything like this idea help the "before the hook" experience?

In general, it helps me to imagine these applications (TodoMVC & Taste) as a guided tour through the growing number of choices a developer has. Code/helpful messages and Application side by side is very appealing to me, as that offers an immediate benefit to the newcomer, like nowhere else provides.

What if we had a sidebar that showed the hierarchy of the app's source files. When a particular action triggers a line of code to execute, say "Transition to Contact Us view," the folder with the file responsible for the action "opens" and displays in bold the file that caused the action. This would likely require a conscious effort of the developer of the example application to call some type of global "base" function, at the noteworthy action. In the sidebar, there can be a permanent "Download the source code" link, and as a Taste user sees the files lighting up as they navigate the app would increase their interest in downloading the source. Once they have the code in their editor, or even the dev tools, they know right where to look.

I'll just throw out some keywords in case it sparks up any ideas from others... dev tools, chrome extension, breakpoints, console.log()/warn()

If anything needs further explanation, let me know, and I'll be happy to clarify!

[ColinEberhardt]

I thought you might like to know how we approach this with PropertyCross.

One of the key metrics of interest when considering cross-platform mobile frameworks is just how much code is actually shared. With some it is 100%, you do not have to write a single line of platform specific code, whereas other frameworks give you a common 'runtime', and you have to write the 'views' for each target platform (iOS, Android, WP).

With PropertyCross we publish the code sharing metrics on the website:

http://propertycross.com/xamarin/

Each implementation has a 'stats' JSON file:

https://github.com/ColinEberhardt/PropertyCross/blob/master/xamarin/stats-config.json

We then generate statistics using a simple script that is run using node:

https://github.com/ColinEberhardt/PropertyCross/tree/master/build

We are also working on improving the README.md file for each framework:

https://github.com/ColinEberhardt/PropertyCross/issues/62

My aim is that the folder structure for each framework should be detailed, to make it easier for the developers to locate the 'interesting' code, like the controller or view-model logic.