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.

[donaldpipowitch]

Multi-device support should definitely be a mandatory part of TasteApp. I like to talk about multi-device instead of mobile support. I think big displays need love, too. :)

Important parts can be be layout for various screen sizes, different input logic (touch, mouse, etc.), high dpi images... small footprint/battery friendly (CSS3 animations instead of JS animations, etc.) ...? Something else...?

[DjebbZ]

TasteApp is looking great, with lot of ideas and a complete scope (frameworks, tools, mobile, server, etc.). I can't wait for it to start so I can learn and contribute. Is there a start date planned somehow ?

-- edit : typos.

[addyosmani]

Thanks to everyone for their input! Later this week we'll begin work on a first draft spec based on the comments in this thread.

Having used the GitHub API extensively lately I do have some concerns about relying on its rate-limits vs a dedicated backend, but we can discuss implementation specifics later.

I'll post a link to the spec draft once ready.

[sindresorhus]

@addyosmani any specific rate-limit problems you ran into? I know it's possible to ask them nicely to up the rate-limit. Dedicated back-end comes with it's own myriad of problems too.

[addyosmani]

@sindresorhus mostly requests to different API end-points depending on where you are in a multi-view app. I'm currently looking at solving this with better local caching of requests, but am also reaching out to GitHub about some friendlier rate-limits. Agree about back-end issues.

[paulmillr]

can we list all gh problems and compare to all dedicated backend problems?

[sindresorhus]

@addyosmani yeah, I think caching is the key here.

[donaldpipowitch]

How about some statistics or a rating mechanism? I think it could be useful, if you see "Oh, App 1 has more views/user than App 2."

Nothing prominent, just as another indicator.

[addyosmani]

Status update

Today, the TasteJS team met to discuss the current status of the project. We reviewed the application ideas submitted to date, discussed the complexity of what we wanted to achieve and walked through two proposed concepts in detail.

The first was ost.io, by @paulmillr. This uses the GitHub API, is a multi-view user forum and has a feature set which captures most of what was asked for in this thread. There were concerns expressed that ost.io (as a GitHub forum) may not be complex enough. To alleviate this, we're going to work with Paul Miller to flesh out ideas for how this could be improved.

The second concept was a JIRA-like team task manager, suggested by @passy and favored by @jeremychone which similarly captured much of our desired feature-set. A sample implementation of it was https://github.com/angular-app/angular-app, which we need to review more closely. It was felt that this app may have more complex data relationships that would be good to demonstrate.

As we now have two solid ideas for applications, we will be authoring draft specifications for both which will be presented to framework authors for feedback in mid-December/January. Paul will be tracking his spec work in #4 and @jeremychone will be tracking his spec in a separate issue too. The Taste team will help them polish up the specs through to completion.

We'd like to thank everyone for their input on TasteApp and look forward to your review of our specs once they're ready :)

[donaldpipowitch]

+1 for the JIRA-like task manager.

[sethladd]

I'd like to see performance requirements. I think @paullewis might have some good ideas.

• Cold start: Initial draw to glass in under 1 second.
• Warm start (files already on device): 0.5 seconds
• User interaction in 0.5 seconds after paint to glass. (can we do faster?)
• Transition times between views must be 1/2 sec.
• 60 fps, no jank

Also, this might be captured elsewhere, but:

• works offline
• syncs data to server

[paullewis]

@sethladd has an excellent list. I would add:

• Speed Index of < 1,000
• Prioritize critical resources inside of first 14KB payload

and I would definitely reiterate the "60fps everywhere all the time" mantra.

[donaldpipowitch]

Nice requirements @sethladd and @paullewis.

Could you explain "Prioritize critical resources inside of first 14KB payload" a little bit more? Why the specific 14KB threshold?

[passy]

@donaldpipowitch That's based on the amount of data you can get into the initial TCP package you can transport within one roundtrip. Good slides about this here: https://docs.google.com/presentation/d/1IRHyU7_crIiCjl0Gvue0WY3eY_eYvFQvSfwQouW9368/present

[donaldpipowitch]

Thanks @passy!

[addyosmani]

I think it may be time for us to reconsider how we approach the problem of evolving TodoMVC. By far, the most complex challenge here isn't defining a better application or feature-set, but rather, getting together enough community engineering resource to implement these larger apps.

Unlike the original project, these aren't weekend or even one week efforts. I could easily see each framework's take on the app requiring a few weeks to a month to ship. That is to say: the core TodoMVC team wouldn't be able to implement these apps ourselves without significant help (we're equally involved in other front-end OSS projects atm).

With that in mind, there are a few options:

1. Refocus our TasteApp efforts on just publishing a concrete, well-laid out spec and template, but not implement ourselves? It would be optional for any framework to take the spec, use it as they feel fit and publish. If it gets traction, we link to said implementations accordingly.

2. Estimate the ~time cost of creating TasteApp in a framework. Attempt to actively convince a few of the more popular frameworks to commit to implementing and shipping. We take more of a direct role in seeing the implementations through, via reviews and coordination.

3. Call it a day on TasteApp. I'm completely open to us ignoring this option, but if the core team decide to stick with it, I'll support it. We're still exploring evolving TodoMVC through backend integrations, more compile-to-JS languages and better testing and CI workflows. The project is not going away any time soon, but we probably do need to decide what to do with TasteApp.

Thoughts?

[supermensa]

Who is the audience? Not people sitting around in big offices. It needs to target the small time hackers, people who are interested in building stuff, breaking stuff, learning on their own from whatever small set of tools they're given.

TodoMVC is a nice enough example app, but TasteApp could be something people could actually use in the wild. Something like a mini-website with small features like pulling feeds from open APIs.

A more open/loose spec may actually work, as you'd have several approaches to a functional mini-site.

[jedireza]

I think option one is solid. With a spec in hand anyone with the time and energy could help plug away at an implementation. It could even help foster contributions from new developers trying to get into OSS.

---

Someone really cool (Addy) says:

First do it, then do it right, then do it better.

It was May of 2013 when I first posted (above) about Drywall. That project was me just doing it. And when I saw the TasteApp project I thought it was a perfect idea. I've been watching this thread since.

More recently I've abstracted the API out into a project called Frame. Which in comparison to Drywall, was doing it right. As a learning experiment, using the Frame API hosted on Heroku, I built a client only app, implemented login/logout etc... with CORS and local storage.

And just this week I published Aqua, which IMO was doing it better.

---

TodoMVC is great. I really like the idea of TasteApp. I'd love it if the projects I've been working could be useful to this one.

[passy]

I'd like to propose an Option 4)

Find an existing open source app that ticks all or most of our boxes and adopt it to become the new TasteApp by writing a spec for it. With this option we'd also avoid the problem of problems surfacing at implementation time that weren't visible while writing the spec. Perhaps we could create a separate issue and collect some suggestions for apps that come close to see if this option is viable at all.

Who is the audience? Not people sitting around in big offices.

There's a balance to strike here. No, we don't want to build a CRM here, but it would be cool if the app is something you can show to your CTO and point out what the particular library/framework implementing this makes it the perfect choice for your next project.

[supermensa]

@passy Option 4:
Deconstructing an existing application into something which would allow all framework implementations to really shine, could be more work than coming up with a generic spec.

Audience: I'd think that a comparison chart is more relevant to developers looking for a new library / framework.

If the TasteApp consisted of several (optional) modules, it would be easier to use the app as an actual boilerplate for something larger / more distinctive. In this way, newbies could quickly get off the ground and start hacking away at it - or inspecting parts of the individual framework in a very practical way.

(This would also make it fairly easy for an experienced developer to throw something together to showcase to his CTO).

[nspaeth]

I think, for similar reasons as @nicolashery, I may be among the target audience of Taste. It looks like there is some concern that a big application like proposed here would take a lot of time for developers, but on the contrary, I think it should be as contrived and feature-full as possible.

• It shows how the framework scales with application size and complexity
• It demonstrates more features of the framework and allows for a more nuanced comparison

Additionally, I think that the TaskManager application is a good fit: the concept is more familiar to users and less of a distraction while also trying to understand the underlying frameworks. It also lends itself to many possibilities for extending the application to incorporate new features that developers may want to compare.

I think @addyosmani 's option 2 would work well. It would help to pitch it not just as a common comparison application, but as a common standard suite of things that frameworks should to do anyway. The TasteSuite spec would require implementing:

• TodoMVC
• Tutorial for implementing/Rationale for design decisions TodoMVC
• TasteApp
• Tutorial for extending TodoMVC into the TasteApp/Rationale for design decisions

Implementing the "TasteSuite" spec would inherently provide framework authors with:

• Quality documentation that covers a wide range of features and demonstrates idiomatic code
• Idiomatic boilerplate architecture and code for both a small and large projects, enabling framework users to get started quickly, or rapidly proof-out prototype concepts for pitching or comparison, that will also translate well into production
• An easy way to identify missing features (ie. for developers who may spend more time on the framework than using the framework to develop useful applications)
• Easily identify areas to improve on based on alternate implementations
• In many cases, implementation will be similar to other projects so the first implantation will help bootstrap these projects.

To make it easier to keep track, I've combined the OPs features with those in the ost.io issue, others in this thread, and included some of my own:

• Realtime
  • Websockets
  • WebRTC
  • ORTC?
  • polling
  • ...
• Auth*
  • Session Management
  • Authorization: roles and capabilities of authenticated users, permissions, ACL
  • Authentication: Registration, login, logout (w/o page reload)
  • Social Auth (G+, Oauth, Facebook Connect)
• Complex data management
  • Persistence (online & offline)
  • Model change migration
  • bootstrapping
  • Local Caching
  • Invalidation
  • Relationships between objects (user -> topic -> repo etc)
  • Complex data structures (eg. Task dependencies might require graph search, GraphQl)
  • Model administration - builtin tools to admin data models (think django admin)
• State management / routing
• Modularization
  • Lazy loading
• Multiple views, Sub views
• Precompiled templates
• Easily switch from development/production
• Common UI elements
  • Drag & Drop
  • Calendar(task due dates?)
  • Modals
  • Markdown editor
  • Charting(Milestone progress, commit graph)
  • Tooltips/Pop overs
  • Accordions/Sliders/complex widgets
  • Toasts/Notifications
  • Animations/Transitions
  • Autocomplete
  • InfiniteScroll
  • File upload/viewing
• A11y, i18n, l10n, pluralization
• Mobile support
• Build process
  • Unit testing
  • Transpiling (Typescript, ES6->7)
• Demonstrates CRUD:
  • Incorporation with outside APIs (get, eg. Profile pictures from G+/Facebook, commit history from GitHub)
  • Demonstrates use of various formats and standards: XML, JSON, JSON-LD
  • (Optional) Custom REST/HATEOAS API server with CORS and access tokens to demonstrate backend capabilities
• (Optional) Builtin analytics features
  • which buttons users click/paths are taken
  • A/B testing
  • logging features (also for debugging, eg production stack trace reporting)
  • reporting
• (Optional) Graphics
  • Something to demonstrate graphics capability? Not sure. Maybe task dependency tree graphing?
  • Canvas
  • WebGL?

This is a lot of stuff, but they are common requirements. In order to facilitate broad adoption, features could be modular and reporting on frameworks could be checkboxes for feature compliance. Additionally, features could have a mix of weak and strong specification. This would allow users to get a feel for what the framework offers naturally (weak specification), and then compares it to what the user could force it to do (strong specification).

As mentioned in a previous post, strong specification can de-emphasize novel solutions which may disadvantage quality new ideas. Authors could be free to add additional features and, once some threshold of other frameworks also implement that feature, it becomes part of the graded reporting.

[leog]

Just came across this awesome initiative and I just want to join.

IMHO, regarding implementation timing and features, it's clear that the we can all think of a lot of features to include, each of us adding what we had to deal with in the past; makes sense, but as the list of features keeps growing, the initiative keeps going down to a black hole of uncertainty.

Could we just set a key set of advanced features that the TodoMVC app lacks and then go from there? We could always keep that base advanced app growing as the time goes by and people collaborate.

BTW, perhaps we can team up with TodoBackend to benefit from their knowledge base. What do you think?

[dmitriid]

2¢: You could split desired features into stages/phases:

Perhaps something along the lines of:

Stage I

• HTTP/REST
• Calendar
• Modals
• Routing
• Mobile support

Stage II

• Auth/Login/Logout/Sessions
• Complex widgets (accordion, sliders)
• Complex data (form validation, file uploads)

Stage III

• i18n
• websockets
• basic animations
• third-party integrations

Stage IV

• a11y
• complex animations

This way you could have fully-featured applications at any stage. Authors/implementers could also have this as a showcase: here's how we actually progress when building more and more complex applications.