Talk:Ember.js

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

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

Proposed restructure[edit]

I would like to suggest that this article be refactored to be less sales-y and more like the React [article], which is easier to follow.

  1. Intro (aligned with modern messaging)
  2. History (roots, 6 week releases, semver, versions & editions)
  3. Governance (Core Teams, RFC process)
  4. Philosophy/Mental model (everything under one roof)
  5. Notable features (zero config, components, routes, data, testing, build, deployment)
  6. Extended ecosystem (CLI, Inspector, Data, Addons)
  7. Future development (Octane, status board)
  8. Learning resources — Preceding unsigned comment added by Handlebears (talkcontribs) 00:08, 16 December 2018 (UTC)[reply]

Reason for removing the See Also section[edit]

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]

Although the links may have been added from a developer's intuitive point of view, the criteria can probably be quantified by popularity and history of libraries in the same family, i.e. client-side JavaScript frameworks. For example, the top three client-side JavaScript frameworks, measured by stars on GitHub are Angular, Backbone, and Ember. I would not include Meteor or Firebase, as they are server-side (not fully client-side) frameworks. There's nothing wrong with including Knockout, but then you're dipping into a level of popularity where you might include others like Facebook's new React too. (See todomvc.com for a good roundup of MV* JS frameworks.) It seems like See Also sections generally include alternatives to the topic in question most often seen in literature, which I think correlates well to the GitHub popularity metric plus historical lineage. So you could, for instance, take the top four plus Ember's ancestor to arrive at: Backbone, Angular, React, Knockout, and SproutCore. I agree with your point about a decent JavaScript framework comparison article though; Comparison of JavaScript frameworks is poor quality in that it includes irrelevant and non-notable projects and misses many popular frameworks. --Vine77 (talk) 01:09, 16 February 2014 (UTC)[reply]

Not encyclopedic content[edit]

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

ORM?[edit]

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]

Pro's and Con's[edit]

Can we get a pro and con summary? — Preceding unsigned comment added by 192.91.171.42 (talk) 13:32, 18 September 2014 (UTC)[reply]

Model-View-Controller Pattern[edit]

Ember doesn't state on their website to be a MVC framework. I think if this page mentions the architecture pattern then it should say Model View ViewModel pattern. Ember passes data to the so called Controller where a property acts as a proxy for the Model.[1] This pattern fits the approach of the MVVM pattern as described on MSDN.[2] In the MVC pattern described by Martin Fowler the View would retrieve the data directly from the Model.[3] This is also supported by Rob Conery on his blog.[4] --Zeb27 (talk) 19:59, 21 May 2016 (UTC)[reply]

References[edit]

  1. ^ Controller "Ember Guide". Retrieved 21 may 2016
  2. ^ The ViewModel Pattern "Microsoft Developer Network Blog". Retrieved 21 may 2016
  3. ^ GUI Architectures Martin Fowler. Retrieved 21 may 2016
  4. ^ The Frustratingly Lovable Crazy-making Huggable Ball of Whack That Is Ember.js "Blog of Rob Conery". Retrieved 21 may 2016

Maintenance and rating of JavaScript articles[edit]

Concerning editing and maintaining JavaScript-related articles...

Collaboration...[edit]

If you are interested in collaborating on JavaScript articles or would like to see where you could help, stop by Wikipedia:WikiProject JavaScript and feel free to add your name to the participants list. Both editors and programmers are welcome.

Where to list JavaScript articles[edit]

We've found over 300 JavaScript-related articles so far. If you come across any others, please add them to that list.

User scripts[edit]

The WikiProject is also taking on the organization of the Wikipedia community's user script support pages. If you are interested in helping to organize information on the user scripts (or are curious about what we are up to), let us know!

If you have need for a user script that does not yet exist, or you have a cool idea for a user script or gadget, you can post it at Wikipedia:User scripts/Requests. And if you are a JavaScript programmer, that's a great place to find tasks if you are bored.

How to report JavaScript articles in need of attention[edit]

If you come across a JavaScript article desperately in need of editor attention, and it's beyond your ability to handle, you can add it to our list of JavaScript-related articles that need attention.

Rating JavaScript articles[edit]

At the top of the talk page of most every JavaScript-related article is a WikiProject JavaScript template where you can record the quality class and importance of the article. Doing so will help the community track the stage of completion and watch the highest priority articles more closely.

Thank you. The Transhumanist 01:08, 12 April 2017 (UTC)[reply]

Possible confusion with similarly titled framework[edit]

From 2005-2007 a javascript utility library of the same name existed. It was written by developers at Highground Technologies and later renamed to quiverjs. — Preceding unsigned comment added by 204.13.59.70 (talk) 16:47, 15 November 2018 (UTC)[reply]