Jump to content

Talk:Ember.js

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Vine77 (talk | contribs) at 06:57, 29 December 2013. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Note: There is some existing discussion on Ember's Github Issue #2374 Vine77 (talk) 19:55, 15 May 2013 (UTC)[reply]

Reason for removing the See Also section

I've just removed the See Also section from this article. It linked to AngularJS, Meteor, Backbone, and SproutCore, but as usual with such sections it didn't explain the criteria for inclusion/exclusion. I know these decisions are difficult to pin down without expressing any bias (why Backbone if not Knockout? why Meteor if not Firebase? what is a library vs a framework vs a full stack platform?) so I suggest we leave this section empty until there is a satisfactory Comparison of Javascript MV* Frameworks article to which we can link. Any objections? - Pointillist (talk) 00:22, 1 June 2013 (UTC)[reply]

Not encyclopedic content

This page reads like an ad. — Preceding unsigned comment added by 213.113.183.85 (talk) 10:48, 1 September 2013 (UTC)[reply]

ORM?

Does Ember Data provide ORM-like facilities for the web? Ember Data occupies a unique space with regard to data persistence, so I wanted to solicit opinions on how to accurately describe its scope. Ember Data was originally described in this article as being an "ORM for the web", which is consistent with how it is described by a few authors, e.g. NetTuts, EPF (Ember Data alternative), and Ember.js Training. The ORM description seems like a useful analogy to me, but was removed by 98.116.104.127 with the comment, "Ember Data does not provide ORM, but maps objects to a RESTful JSON API," so I thought I'd open a discussion of how strict the definition of ORM is and whether or not Ember Data (partially?) fits that description. Ember Data is certainly not the traditional server-side SQL ORM that we usually think of, but actually has very broad goals and seems to fit Wikipedia's more generic description of object-relational mapping: a "technique for converting data between incompatible type systems in object-oriented programming languages" that creates "a virtual object database that can be used from within the programming language." Perhaps 98.116.104.127 is technically correct, but with Ember Data's inclusion of ActiveModelAdapter for backends using the ActiveModel::Serializers interface, it also seems to have the goal of being a drop-in adapter at least for ActiveModel::Serializers as well as backends conforming to the JSON-API spec. Which also brings up another question of whether we should we include a reference to the JSON-API spec? Perhaps when the projects are more stable? --Vine77 (talk) 23:07, 15 December 2013 (UTC)[reply]

Trek says in the latest blog post that "Ember data is now less of an ORM and more of a pluggable framework for assembling your own data communication layer for Ember.js applications (with some nice defaults for people's whose APIs follow common patterns)". --Vine77 (talk) 06:57, 29 December 2013 (UTC)[reply]