-
Notifications
You must be signed in to change notification settings - Fork 3
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
Practical implementation #3
Comments
Inspired by @nicolashery comment in #1 (comment) what if we develop a tiny app demonstrating each single feature for every framework? Maybe here I have been distinguishing between the initial feature set of the target applications (defined in #1) and the feature set of the frameworks (two-way data binding, templating (conditionals, lists, partials, etc.), nested properties, computed properties, partials, AMD support, etc.) If we have a matrix, frameworks / features, the development would be atomic, feature per framework. With a Divide et impera approach, the effort of the startup should be more easy. For instance, for the two-way data binding, we can develop the classic temperature converter; for the computed properties the classic list of the grocery, quantity times price, and so on. My two cents. |
There's going to be a non-trivial amount of work involved in implementing TasteApp for a given framework once #1 and #2 are resolved and the spec is written.
I suggest that we begin by implementing the app using a single framework end-to-end just to help us refine the spec and evaluate how well it can be used.
Thoughts? Perhaps we could ask a member of the community to help with this or use a service like BountySource to kickstart a first implementation.
The text was updated successfully, but these errors were encountered: