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!

[trek]

What’s “selection handling”?

For a given collection, what item(s) are "selected"

I'd also add to the list above, collection filtering, sorting, adding, and removing objects.

[searls]

Thanks for the shout-out, @trek -- as it turns out I do have lots of ideas on how to make UI unit testing valuable and I also agree that the Internet is severely lacking in good examples and documentation.

If anyone on the project is interested in pairing with me or discussing it, let me know. Otherwise I'll just leave this screencast demoing a bit of my style here: http://searls.testdouble.com/posts/2013-03-21-jasmine-tactics-screencast.html

[kouphax]

WRT the server question - I think having a hosted reference implementation filled with real data etc. would go a long way to helping people create apps with various client frameworks and tools (isolated from backend concerns).

My one concern is that this is perfectly fine for work that aims to demonstrate the client side framework features but this "heavy opinion" does little for integration examples (do we want to show use of WebSockets, JSONP, CORS, XMLRPC or all of them) or demonstrating back end stack options (which is why I'm here in the first place)

So yeah - I think a reference service is an essential piece of this puzzle but I do think it there needs to be the option for more tightly integrating backend stacks and client stacks especially if the tools offer this integration OOTB.

[paulmillr]

I also think we should have our own hosted example backend. This way people will be able to create their own backend stacks and taste.js will become both frontend and backend project.

[addyosmani]

I also think we should have our own hosted example backend. This way people will be able to create their own backend stacks and taste.js will become both frontend and backend project.

We'll definitely have hosted backends as a part of the TasteStack sub-project, but I think we should discuss further the idea of a hosted backend for TasteJS as a default. Were you referring to it in that context rather than using GitHub API, @paulmillr?

[paulmillr]

@addyosmani yes. Like api.ost.io which is in Rails. One guy (@mehcode) wants to make his own implementation of this API with Python + Cyclone + Armet for REST now.

I will gladly give my server resources for this project, the server is idling most of the time.

In my opinion hosted backend as default is better because we have all it open-sourced now, unlike GitHub APIs etc.

[addyosmani]

Thanks for the fantastic input @trek

I think the goal should be an app with sufficient complexity to touch the edges of the frameworks and go just beyond them.

+100% on us considering multi-level hierarchies and modals. I hadn't considered this previously.

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.

Good idea. It would be helpful to discuss and decide what interaction patterns we want to cover specifically and how they might manifest in the application we choose to implement. Infinite scrolling will be an interesting one (if we go for it) as GitHub is typically seen as multi-view rather than scroll for more data. We could do something like an infinite commit history view if needed.

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

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

sgtm. Let's discuss this more once we've nailed down the app idea.

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.

I feel like developers are ultimately going to want to unit test the client-side portion of their apps regardless, but I agree that many of the tests for UIs in the wild aren't as solid as they could be. Let's definitely chat this one out some more!

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.

This was the reasoning we had behind wanting to use something like GitHub - real data, fairly reliable and it's well documented.

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.

I would love for this to be part of the requirements but it looks like we'll need to get more consensus about whether build tools/bower should be prescribed as a must or are optional. Would love to hear more from other framework authors here.

[stephenplusplus]

Just thinking out loud here... I'm trying to create a persona for the average Taste user, and I'm not sure we have identified him or her correctly. The site we're talking about above sounds flippin' amazing for all of us, since we all get giddy with new MV* frameworks, and are relative experts in the field (maybe not me so much :)). But, maybe we should be trying to brainstorm the most helpful application for someone with limited experience with these frameworks; maybe not even any pattern or architecture experience. These are probably the most common visitors to a site like Taste, and probably the ones we should be thinking about, since they're the ones who need and want the help, and stand to gain the most.

To go into a little more detail, I would love to see this project let a user unfold any given framework as your curiosity or experience increases. I would like to see TasteJS be super easy, that presents each framework something like this (rough idea):

On the left half of the screen, the application itself will run.

On the right half will be the code that runs the application, and any special messages about interactions that just happened, or highlight parts of the code as they are used in the app. We could have a global todomvc-common function, almost like debugger, say codeDebugger that is called on chosen events. In the case of TodoMVC's current Todo app, think...

on click of delete Todo, call codeDebugger(blockOfCode, message)

...which will put that code block into focus. We could even treat it like a real debugger, and let them step through what's happening, explaining the particulars of the framework being used as they go.

Then, if they like what they've seen, and want to learn more, or "unfold" a framework, they can either clone the application code only, or use Yeoman generators to pull down the app, and add on pieces as they need (grunt, bower, etc.).

That's just my high level take on this. I'm just worried about scaring people away by throwing too much code at them at once. People might appreciate learning a little slower, and not going from "What's an Angular? Where does the Backbone go?" to "I just made the most scalable, optimized user experience ever" in one clone.

[paulmillr]

build tools/bower should be prescribed as a must or are optional

I think they should be optional. We have stuff like component(1) which does Bower’s job in absolutely different way, with hundreds of very small components. We want to show this way too.

[passy]

@stephenplusplus I don't see your images. Did something go wrong with the upload?

[stephenplusplus]

Did I do some bad markdown? I didn't mean to include any inages in my response. I use my words to paint pretty mental images :-)

[passy]

@stephenplusplus I think I misread that part. Sorry for that. :)

[stephenplusplus]

I can mock something up if that was unclear!

[trek]

I think they should be optional. We have stuff like component(1) which does Bower’s job in absolutely different way, with hundreds of very small components. We want to show this way too.

The problem with showing other methodologies for build tools (or anything else) is the combinatory effect this will have. 12 frameworks x 3 build tools x 5 testing frameworks x 15 server frameworks x N compiled/transpiled languages.

Then we need to keep them all up to date and accurate. In my mind an excellent browser application framework can be developed

• in isolation from its data source
• in any browser "language"
• against any testing framework
• using any package manager
• using any build process in any language

If TasteApp is for demoing these frameworks, I think we should just pick a set of support tools and run with it. I'm fairly indifferent to the specific choices. Possibly we allow people the option of a combining these tools a la the dependency-examples directory of TodoMVC.

When it's time to do a dependency management shootout, I'd rather see a single implementation of Taste (probably Backbone) used as test case for comparing along this single metric.

[addyosmani]

If TasteApp is for demoing these frameworks, I think we should just pick a set of support tools and run with it.

From a scalability and comparison perspective, this makes a great deal of sense.

When it's time to do a dependency management shootout, I'd rather see a single implementation of Taste (probably Backbone) used as test case for comparing along this single metric.

Hmm. Interesting idea! At some point we may try addressing this in the future.