Define initial feature set

[addyosmani]

Taste.js (final name TBD) is the successor to TodoMVC which hopes to offer a more complex sample application. Features we initially feel it should capture:

• Authentication, session management
• Complex routing
• State management
• Demonstrates CRUD
• Uses either a third party API or a dedicated back-end for data
• Multiple views
• Registration, login, logout
• Precompiled templates
• Sub-views
• Mobile support
• Unit testing

Other factors we could consider:

• Navigation transitions and animations
• Form validation for different views
• Nested components
• Offline caching?

@paulmillr's excellent ost.io app already captures these, but let's discuss what else we want the taste app to demonstrate (whether we go for ost.io, a GitHub client, both or something else). Ost.io initial taste spec is located on google docs.

Discussions around:

• What the final app will be
• Whether we will provide a reference template and so on are separate and can be discussed later.

cc @sindresorhus @trek @passy

[addyosmani]

Other things to consider:

• Should the app also require some form of build system (e.g grunt)?
• Should it (optionally) encourage use of a package manager?

[paulmillr]

• Yes, it should use any build system. But build systems can be different. Some stuff can be simple with makefiles. I think we need from build system ability to concat and uglify all code to 2-3 files. No 100 dynamically-loaded AMD files.
• Encourage the manager yes, require — no.

[paulmillr]

It is cool that ost.io already has backend btw, we can encourage people to make spec-compilant backends with different technology too.

[passy]

For inspiration: Building an App with Ember.js

I think the app Tom builds there is a great example for an app slightly more complex than the Todo app. We certainly want to go further with this, but some elements there could be interesting.

[addyosmani]

On the AMD note, I would say - at some point we may consider including a version that does use lazy-loading/dynamic just so that developers are able to compare how that works and performs, but otherwise I'm happy with the first releases being correctly built upfront.

On the backend side of things, lets loop in @kouphax who will be working on TasteStack (the more backend centric comparison of client/server integrations for TasteJS). I think we'll need to decide whether we want to use the GitHub API or opt for a dedicated backend as a part of our initial requirements too.

Also, why don't we cc in @tomdale in case he has any further input from the Ember learnings.

[kouphax]

• Should the app also require some form of build system (e.g grunt)?
• Should it (optionally) encourage use of a package manager?

I'm fine with encouraging the use of these tools. Requiring them, on the other hand, may be adding unnecessary constraints and have some negative impacts on server side effort (they may not I'm just thinking out loud). Also it may be fitting comparison to show the difference between a bare implementation and one with all the bells and whistles and package managers and build tools.

As to what the TasteApp should actually demonstrate - the list above is fairly comprehensive. I think it would be good (even with a dedicated backend) to show integration into 3rd Party services - either from the backend or directly from the client (or both).

I'll pop up more thoughts as and when they occur to me.

[passy]

I'm fine with encouraging the use of these tools. Requiring them, on the other hand, may be adding unnecessary constraints and have some negative impacts on server side effort (they may not I'm just thinking out loud).

+1. Some frameworks may have their own toolchain and reflecting the best practices of each framework should always be a top priority.

[addyosmani]

I agree with us softly encouraging the use of PM and a build system but not making it a hard and fast requirement.

Love to cc in @btford @sbellity and @derickbailey here too in case they have any thoughts on what else the next evolution of TodoMVC should tackle feature wise.

[paulmillr]

@addyosmani what do you think about making initial taste spec public so that folks will be able to express their concerns and ideas?

[btford]

I like what I'm seeing. I think these decisions should be on a per-stack basis.

For an AngularJS + Node.js app, I'd want to use Bower, Grunt, and Yeoman, but I don't think that would be the case for everyone.

[addyosmani]

@paulmillr I think that would be a fantastic idea. Shall we do it Monday to ensure it gets maximum reach?

[paulmillr]

@addyosmani no problem with that. I have made the document available to anyone with link, feel free to post it any time.

[trek]

features

I think the goal should be an app with sufficient complexity to touch the edges of the frameworks and go just beyond them. A side effect is that we can probably drive future improvements for common concerns:

view hierarchy management

ost.io is pretty simple (mostly it's drilling down via view replacement). This demos Backbone well, but much of the hierarchy management in Ember unexercised. I'd prefer to see deeper (3+) levels of hierarchy, nested hierarchy (e.g. master/detail stuff), selection handling, and modals. Common patterns in applications, but usually avoided in browser applications because it can lead to complex view hierarchy.

It's question I see a lot. Less about Ember because there's support for it, more for other frameworks.

interaction management (i.e. "widgets")

The app should need common interaction patterns like typeahead, modals, popovers, date pickers, progress bars, icon badging, infinite scroll and make the implementer not shop these out to 3rd party libs. I think Angular will really shine here, where in Ember/Backbone you're more likely to just want to use a jQuery plugin. That's a fine, pragmatic answer but it's glossing over areas the framework isn't offering help for a common task and I'd like to highlight it.

Also: animation. Super common, some frameworks have good support, some are getting good support (Angular), some have features that actively make this hard (Ember view removal occurs immediately, meaning there's no easy way to do animation on this event).

data management

Nobody has a great story for this beyond very basic, flat, non-relational data. And yet, most apps of any complexity have to handle data problems like association-loading, -updating, and -removing, identity mapping, expiring stale data, handling conflicts, &c and have to handle them in a way that the framework expects. This is true even for "non-opinionated" frameworks.

Let's make the data interaction needs sufficiently complex so framework developers can't continue to punt on this problem.

tests

I'm not entirely convinced unit testing for UIs is a great idea. Everything I've seen in the wild feels incredibly brittle. The best advice I've heard is to extract anything library-like into a library and test that, then cover your UI behavior with automated browser driving. Maybe @searls can jump in here to advise.

Definitely want a runnable app spec though: http://www.youtube.com/watch?v=heK78M6Ql9Q

server

This is the always the hardest question for browser app demos. Without a backing service the app doesn't reflect real world use. With a service you either write a custom service and alienate everyone who doesn't know that particular language/framework or select an existing third-party API and now have to offer instruction for issues like

• obtaining and using API keys to authenticate to the service.
• connecting to this data in development (jsonp? CORS?, proxy through middleware server if neither available?)
• acting on behalf of an authenticated user

Despite all that hoop jumping, I think using a 3rd party service is better than developing or or offering server solution. A well-written client app should only care about the API, not what happens behind it. A third party service also lets people play with real data immediately.

build Tools & dependency management

Three months ago I would have said "no way". Now, I'm pretty sure we should mandate the use of grunt and/or bower. A sufficiently complex app basically needs either build tools or server app integration. With a 3rd party service the latter isn't possible (IMO, it's an icky pattern anyway). I get the sense that Grunt has emerged as the tool and has the most traction. I also hope real examples will drive adoption of those tools.

If we don't mandate a build tool I think the applications will get unwieldy. Huge application.js file or huge index.html with many script tags and lots of templates. Either is confusing.

[paulmillr]

@trek current ost.io is just a draft for this purpose, we can always modify it based on responses.

Modals and nested hierarchy are good ideas, i’d add them. What’s “selection handling”?

[passy]

@trek +1 on everything. I really like where this is going!

view hierarchy management

This makes a lot of sense. Covering complex view hierarchies in different frameworks could offer some unique insight into parts of the frameworks, that are almost never covered in tutorials. That is exactly the part I haven't gotten to in any of my experimentations with different MV* frameworks and I would love to see how to correctly do this.

interaction management (i.e. "widgets")

Another great point. Many frameworks convey the impression that they replace the ecosystem of jQuery plugins that was build over the last years. It would be nice to show how to properly leverage them instead. Also, I agree that Angular's directives will really shine here.

data management

This could be a part where there is no One Right Answer to the problem, but I'm curious to see what solutions there will emerge.

tests

I know that Angular splits their tests into end to end and regular unit tests. That could be applicable to other frameworks as well.

server

I'm also inclined to go with an existing third-party API, preferably with CORS support.

Thanks so much for your input!