-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Code comparison tool #3
Comments
Not sure about tool, how can it feel? Maybe make a list of features and a list of implementations (codes) under each feature? |
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! |
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. |
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.
The text was updated successfully, but these errors were encountered: