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.

[nicolashery]

I am so excited about this. :)

This is exactly what I've been looking for: a non-trivial web app to serve as inspiration and a best-practices guide for my own projects.

As a likely-to-be "user" of TasteApp, allow me to jump in with a few thoughts?

Goal of TasteApp

I just want to make sure, is the goal of this project more:

• to illustrate the differences between client-side frameworks (like TodoMVC)

or

• to illustrate web app development best practices, and show how to implement them in different frameworks

Or both?

Persona of TasteApp user

@stephenplusplus made a good point by raising the question: who will be using and benefiting most from TasteApp?

Me! :)

More seriously, I believe (I might be wrong) that they will be people like me: we've learned JS and feel confident with it, dabbled on small projects with Backbone, templates, Grunt, Node.js, MongoDB, etc., and are at a point where we have more "serious" projects we'd like to tackle, but don't have a lot of examples on what are all the best-practices to follow, all the things to think of, how to organize the code, etc.

Concerning the "super-easy", "interactive demo/explore the code" idea you suggested @stephenplusplus: while it does sound appealing I believe that 1) it would be a lot of work, and might be better to focus the effort in keeping the TasteApps up-to-date 2) if my hypothesis above is correct, TasteApp users would actually be developers with a little bit of experience already, that have no problem reading (well-commented) code, and that wouldn't benefit as much from such "easy presentation". Personally, I'd rather have a comprehensive README that explains the different components, what they do, and where to start reading the code. To explore the app, I'd just clone it and add some console.log :)

On what TasteApp should demonstrate

I think you already have a lot of elements down already, but here are some things I had noted down for myself as "learn to do this" for my next project, there could be some things of interest for TasteApp:

• Modular architecture: organize code into modules I can easily work on separately
• Deploy as static site: I want to try some of the things from Alex Sexton's post, self-contained folders with minified files and "cache-buster" build numbers, etc.
• Mobile and offline support: with localStorage, appcache, inspired by FT Labs and Forecast.io
• Search

On managing the combinatory effect

@trek made a good point that with all the different frameworks, build tools, package managers, module systems, etc., there would be a bazillion TasteApps if we had to illustrate each.

I'd say we should have a couple TasteApps, each with a combination that makes sense, and that the sum of these TasteApps more or less covers all the options out there. Again, if my earlier hypothesis is right, i.e. that the average TasteApp user is "slightly experienced", he or she would have little problem taking one of the TasteApps and switching out, for instance, AMD for Browserify, don't you think?

On the app itself and its data

I know @addyosmani said that discussions on what the final app would be should be left for later. But with the discussion around using GitHub's API for the data part, I saw a direction being taken, and I know you're far from having settled on using GitHub data, but I did want to comment on it.

I believe that your average TasteApp user probably wants to build an app that is not "developer-focused", something useful for her non-geek friends, or at least something she can show them.

The reason I'm saying this is because about a year ago, I had asked myself the exact same question: "I want to learn JavaScript web-development, I need a non-trivial project I can work on for that, and it should cover enough aspects to be a good learning experience".

What I came up with was Outfolio (I'm not trying to advertise it haha, it was a "dummy" project, and the code is really outdated), which is just a simple app that allows the user to keep a list of places he likes, and share them via a link.

I've been wanting to rewrite Outfolio to illustrate all of the things I've learned since then, so I'll probably use TasteApp as a guideline to do so! :)

Also, concerning the question of "3rd party data or own data", maybe it could be a mix of both? I think that's a typical "real-world" use-case no? A lot of apps have their own data, and can also leverage 3rd party data. If I take my example above, I could imagine using the foursquare API for lists of venues, maybe allow the user to checkin, and then the app adds its own data to it (using its own backend or something like Parse), like notes and adding the venue to a list...

Fin

That was my two cents! Sorry for the long read, but I guess you get the point: I'm excited about this! :)

Cheers

[jonrimmer]

I'm gonna give a big +1 for animations: Transition between views; Panels sliding in and out; List items animating as they are created and removed.

Some might see them as fluff, but, when they're done right, they enhance usability and provide a level of polish that can compete with even the best native apps.

[eranation]

I hope it's ok I'm barging in but perhaps you'll be considering my recent "wish list" from a JS / MV* solution

• as said, transitions and animations between views, view states (easy in jQuery, hard in BB, experimental in Angular)
• drag and drop
• support for controls / widgets
• binding
• nested complex models and "noSQL" friendliness
• modal dialogs based views (and handling opening closing them with route changes)
• bootstraping models (not easy without pushstate)
• build system
• packaging system
• dependency management system

If your plan is to teach / showcase all the above, I can't wait to see what you have in mind

if I'm no where near and plain rude posting comments without being asked, please kindly ignore :)

(p.s. I haven't read all other comments, just scanned them, I should have, but no time, lot's of work fighting with the list above!)

On Tue, Apr 16, 2013 at 6:28 PM, Jon Rimmer notifications@github.comwrote:

I'm gonna give a big +1 for animations: Transition between views; Panels sliding in and out; List items animating as they are created and removed.

Some might see them as fluff, but, when they're done right, they enhance usability and provide a level of polish that can compete with even the best native apps.

— Reply to this email directly or view it on GitHubhttps://github.com/tastejs/TasteApp/issues/1#issuecomment-16475876 .

[peol]

Another thing would be memory footprint. How do you make sure to plug memory leaks? Gotchas in the frameworks? A framework might be easy to build with, but terrible at cleaning up itself. There's manual overhead when it comes to this area and something that most frameworks doesn't really highlight/mention any best-practices of.

[trek]

@peol +1 on that. Object cleanup should either be the framework's job or standard how-to the framework provides to developers. I've never been a fan of the official view/event teardown story taught on http://backbonejs.org/

There's a topic in TodoMVC Issues that touches on this idea. I was strongly against it because the sample app for metrics gathering was so below the level of complexity of typical browser applications the results were going to skew towards tiny frameworks and (I feared) spur people to reject larger frameworks like Angular or Ember.

I'd love to revisit the idea now that we'll have two examples at opposite ends of the spectrum. This would be an invaluable aid for people to "right size" their tool choice on a particular project: "Angular is bigger than Backbone, but for a medium sized app results in small total gziped code, but leaks memory when you do the following things."

[thanpolas]

I'd like to see plurality of data structures. A single magic object will not cut it. Any medium+ scale web app requires all sorts of data structures (maps, lists, sets, queues, buffers) to solve the various problems and challenges.

https://github.com/montagejs/collections#readme

http://docs.closure-library.googlecode.com/git/namespace_goog_structs.html

[dylang]

Frameworks are going to find ways to differentiate themselves and a demo of common features is going to miss what makes some new frameworks that don't exist today special. Like an "MVC" game engine that uses WebGL for the view, or a music generator that uses generated audio as the view.

To support this, it would be nice if there was always at least one show-off page that each framework could use to show off features, plugins, abilities, games, or anything else that that could be unique or special to that framework.

This could be a simple infinite scrolling demo, or a working NES emulator built on the framework. Sometimes you don't need a Roseta stone, you just want to see what makes a framework stand out.

[gryzzly]

What about things like "config" storage, something that many people use some kind of a global for. Current user, client IDs, API/CDN hosts &c, things that are reused by different components of the app. We have an observable Storage type that also allows to “watch” the changes in these configurations.

[jayvansantos]

There should be examples combining different build tools, package mangagers, client and server side frameworks. For example: angularjs (with yeoman [uses bower]) + hoodie, or angularjs (with yeoman) + meteor or angularjs (with yeoman) + vanilla nodejs + express. Then the same app explained but with grunt.

The point is so that beginners like me can go and see an example or examples of their preferred build tools, package manager, client, and server side frameworks all working in harmony. Correct me if I'm wrong but that's what I see in TasteJS...

[addyosmani]

@dylang

To support this, it would be nice if there was always at least one show-off page that each framework could use to show off features, plugins, abilities, games, or anything else that that could be unique or special to that framework.

We can support this. It wouldn't (of course) be the primary focus of the project, but after implementing a TasteJS application based on specs a framework would like to show off a variation demonstrating more custom behaviour we wouldn't say no to showcasing this in a more info type section.

[addyosmani]

@jayvansantos

There should be examples combining different build tools, package mangagers, client and server side frameworks. For example: angularjs (with yeoman [uses bower]) + hoodie, or angularjs (with yeoman) + meteor or angularjs (with yeoman) + vanilla nodejs + express. Then the same app explained but with grunt.

Not a bad idea, but the major problem with doing this is that there is an unquantifiable number of combinations of each of the tools and frameworks you mention that could be made and in our experience, this just doesn't scale. You can't easily compare a setup using Express + Ember + Jam to something using PHP + Backbone + Bower.

You can however more easily compare Express + Bower + Backbone (or Ember) purely down to there being fewer pieces to compare. Not doing this becomes a maintenance headache because ultimately each variation has it's own repo/branch and updates need to propagate across them all.

The way we want to tackle this problem is:

• TasteJS implements complex apps with a client-side focus. It will demonstrate hooking up to an API, package management, build tools etc.
• TasteStack will try to be the one that compares frameworks using a variety of different backends. This is closer to what you're after.
• TodoMVC will continue to enable simpler MV* framework comparison

[addyosmani]

@trek

I'd love to revisit the idea now that we'll have two examples at opposite ends of the spectrum. This would be an invaluable aid for people to "right size" their tool choice on a particular project: "Angular is bigger than Backbone, but for a medium sized app results in small total gziped code, but leaks memory when you do the following things."

Big +1.

[addyosmani]

I would also be interested to hear what @igorminar and @mhevery make of the direction being taken.

[passy]

I'd like to get some opinions on whether i18n and l10n would be a topic that should be covered. For translation, my personal approach has been a server-side pre-compilation process of the templates, but parts of it like pluralization and formatting of dates, currencies etc. can often leverage support from the frameworks.

[paulmillr]

pluralization is usually done in template layer so I highly doubt we need any examples of that included

[IgorMinar]

@addyosmani I would add these to the list:

• animations/transitions
• touch/mobile
• use of 3rd party reusable components (framework specific AND framework agnostic components)
• i18n / l10n (including pluralization)
• lazy code AND template loading
• stretch goal: code/template obfuscation support

@paulmillr I don't understand your comment about pluralization. I think it's a hard problem especially in the context of i18n which should be part of the example

[thanpolas]

@IgorMinar @paulmillr @addyosmani following up on the facilities of a library, i think the plurality of libraries should be key part in evaluating them in close relation to the libraries ability to be modular, meaning to have the ability to neat-peak only the required packages in the final bundle vs a monolithic runtime.

An argument re UI can be done as a library's main purpose is to serve the application part of an engine rather the UI. Separation of the same is actually already done by defining the View pattern.

Personally i find less value in a library enabling me to do UI stuff (transitions / touc / etc) vs enabling me to do what i need in my app by providing all the neccessary facilities like i18n, logging, structs etc in a modular take-away style.

This separation is important so we can distinct if a library is closer to jQuery-mobile or Closure-Library / YUI etc.

I do not state that UI is not an important factor, i am saying that i find the UI part less important than the application part, when it comes to selecting a library / framework.

[IgorMinar]

I'm not saying that touch should be part of the framework core. But instead the framework should be sufficiently extensible as to allow for touch capability to be pulled in as an additional module or the framework should make it trivial to integrate with a 3rd party solution. In practice there is a lot of friction in such integration so the TasteJS app should be touch enabled. On Apr 27, 2013 3:30 AM, "Thanasis Polychronakis" notifications@github.com wrote:

@IgorMinar https://github.com/IgorMinar @paulmillrhttps://github.com/paulmillr @addyosmani https://github.com/addyosmani following up on the facilities\ of a library, i think the plurality of libraries should be key part in evaluating them in close relation to the libraries ability to be modular, meaning to have the ability to neat-peak only the required packages in the final bundle vs a monolithic runtime.

An argument re UI can be done as a library's main purpose is to serve the application part of an engine rather the UI. Separation of the same is actually already done by defining the View pattern.

Personally i find less value in a library enabling me to do UI stuff (transitions / touc / etc) vs enabling me to do what i need in my app by providing all the neccessary facilities like i18n, logging, structs etc in a modular take-away style.

This separation is important so we can distinct if a library is closer to jQuery-mobile or Closure-Library / YUI etc.

I do not state that UI is not an important factor, i am saying that i find the UI part less important than the application part, when it comes to selecting a library / framework.

— Reply to this email directly or view it on GitHubhttps://github.com/tastejs/TasteApp/issues/1#issuecomment-17113981 .

[trek]

A good article about transitional animation in UIs: https://medium.com/design-ux/926eb80d64e3. The kind of thing I suspect @IgorMinar, @eranation, @JonRimmer, et al are likely getting when they say "include animation"

[pablodenadai]

I'd suggest to track the user's behaviour throughout the app. It could give us valuable info that we could use to improve the app.

Also; it would be nice to see some realtime implementation using WebSocket (ie. socket.io)