tastejs / meta Goto Github PK

As discussed with @addyosmani, @ColinEberhardt and @godds the name TasteJS gives the impression that we would limit submissions only to JavaScript. Can we find a name that is more welcoming to non-JS solutions, preferably with an available TLD? :)

/cc @sindresorhus

Now that we've decided to start using the blog more actively we should try to do a more long-term brainstorming on content so we're able to publish something at least bi-weekly.

It could be an article, project update, interesting things happening in the JS framework ecosystem (like an actual innovative framework being released), experience working with a framework, what we're working on, possible new TasteJS projects, etc. Anyone (also non-contributors) comment on what you would like to see.

I was just looking through the ToDoMVC list (learning about Dojo!) and it struck me that it isn't terribly obvious why some implementation are not spec compliant.

Firstly, a minor point ... take Kendo UI for example, I think the colouring of the various implementations on the todomvc.com website is a little unclear. I find maroon to be quite an ambiguous colour! Is Kendo spec compliant or not?!

Now that I have determined that it is not spec compliant, I'd really like to have an easy way to find out why, so that I can consider fixing the outstanding issues and contributing my changes.

I looked through the issues, but must admit, I am not 100% sure where it falls short!

A method we use in PropertyCross, which I quite like, is to provide a direct link to the known issues for each framework, for example ...

http://propertycross.com/enyo/

We still need to do a bit more work on tightening-up the specification, but at least this does give would-be contributors an easy way to see how they might help.

$ yo taste
# ascii taste monster
What framework are you interested in? angular

# fetches angular demonstration

# ascii popsicle
All set!

It could pop it in /demonstrations/angular to enable using a sub-generator to include other demonstrations alongside.

As a framework owner, I have a taste.json file in my root directory that can be used by tastejs to provide content for the site.

Hypothetical taste.json example:

{
   "homepage": "http://angularjs.org/",
   "documentation": "http://docs.angularjs.org",
   "tutorials": {  
      "hello_world": "http://docs.angularjs.org/tutorial"
   },
   "api": "http://docs.angularjs.org/api/",
   "examples":  "http://angularjs.org/examples.json",
}

Other top-level values could include:

• IRC room
• Email list/Google Group
• StackExchange tag
• Plugin sites
• Twitter/AppNet ids
• Links to docs like changelog, goals, important blog posts
• Feature enums for generating comparison checklists
• Screenshots
• Demos
• Issues

Values are always urls. If the url ends in .json then it is assumed that is a file or api endpoint for additional data, such as a dynamically generated list of examples.

All the cool kids are doing it.

http://tastejs.com/blog

Example: http://blog.getbootstrap.com

Could be a nice place to share announcements, a curation of the absolute best blog posts (not to much though), summary of discussions, etc.

I really like the medium.com article design. We should have something similar: https://medium.com/i-m-h-o/125a8658682c

Run on Jekyll.

@passy said: 18px base font-size

We all work on an increasing number of projects, most of which benefit from regular release cycles.

I wonder if it would be useful to put together a calendar (in milestone form) planning out major releases for the next 6 months.

e.g .next versions for..

TodoMVC
Yeoman
TasteApp (alpha)
Basket
etc.

I was reading the history around tastejs/TasteApp#1, tastejs/TasteApp#2 and tastejs/TasteApp#4. It seems to me that not only would it be good to create a multiple-implementation front end app such as is being discussed there, but what about a multiple-implementation back-end as well? If we had a spec for an API that the front end app was going to use, we could implement that for multiple languages, such as .NET, Java+various libraries, node, Scala, etc - using Heroku/GAE/Azure for deployment.

I'm happy to invest some time in doing this, but it may influence the decision about what spec to use for TasteApp (from the suggestions put by @paulmillr and @jeremychone), which is still undecided.

What do people think?

Since day 1, we've wanted to have a way to easily compare different implementations of the TodoMVC apps but it's been hard for a number of reasons. Apps have different file structures and it's not always as easy as saying 'lets compare view:view'. A code comparison tool that solves this problem, letting folks more easily see how one framework might structure a piece of an app vs another could be quite useful.

After a little bit of inactivity (my bad, too many projects on the go), we have pushed out a v1.3 release:

• Delphi implementation added.
• Emy implementation added.
• Intel App Framework, Sencha Touch 2, Enyo and PhoneJS implementations updated.
• PhoneGap implementations now using common Cordova 3.1 configuration

A big thank you to @mrpotes who did all the hard work on this one.