EXTEND_PROTOTYPES false by default.

[jdalton]

Currently Ember extends built-in prototypes of Array, Function, & String by default. Although Ember doesn't require these extensions and they can be disabled, because they are enabled by default they tend to stay that way as evident by sites like vine, twitch, nbcnews, & discourse using the default settings.

The problem with adding methods like Array#compact, Array#without, Array#uniq, Function#on, & String#capitalize is that it increases the likelihood that they'll be used and cause problems/roadblocks for future built-in language extensions. For example, if ES7 tried to add Array#without that behaved in a different way than Ember's Array#without newer environments would get the built-in version while older would get Ember's causing an inconsistency and increased possibility of breaking thing. We've seen this recently with MooTools and Array#contains, but it's happened before with Function#bind, String#contains, and even DOM4 Element#remove.

[stefanpenner]

@jdalton as you know, internal ember does not rely on these things. So we have lots of flexibility here.

I am unsure if they should be default on or default off, that is a @wycats and @tomdale question.

But I do think if they are ON, we should always use our user land versions and never fall back to native versions. That way if something does change, our users will still get the consistent original behavior they expected.

[workmanw]

I would also add that there are a lot of blog posts, Stack Overflow answers, JSBins and even Ember guides that currently show code that assumes EXTEND_PROTOTYPES set to true. It's not that changing false to true is hard, but it would effectively invalidate 90% of the examples that exist and could ultimately be another point of confusion for newer users.

[stefanpenner]

An added confusion is we have Enumerable which allows enumeration over non array like objects but with all the array like goodies.

This leaves us with potential differences with [].contains and enumerableThing.contains. Which sucks big time.

This part of ember was inherited from the sprout core days, a time when browser world was stale, prototype extensions where used without fear (wrongfully). Going forward this is in the category of cruft I wish to see improved. As such a strategy and plan needs to be derived.

[stefanpenner]

I think Ember.A() behaving ala lodash might be the way forward. Ultimately, just using a small subset of lodash may be useful, but we are very nervous to explode our gzip'd bite size even more.

[tomdale]

I'd be willing to reconsider it once the way you consume Ember is via ES6 modules, and in a 2.x release, but this change would be way too breaking for the 1.x series.

[stefanpenner]

Also worth noting. In theory currently ember will run slower with prototypes off. And will be an involved but good refactoring to address this

[jdalton]

I think Ember.A() behaving ala lodash might be the way forward.

👍

Also worth noting. In theory currently ember will run slower with prototypes off.

Ah, good to know. Manually bolting on methods reminds me of Prototype's approach for supporting DOM extensions in older browsers (not so awesome).

There's deeper issues as it looks like even with a config of EXTEND_PROTOTYPES as false new built-ins can still leak through to Ember.A(...) which can lead to the same issue described above. Here's a simple example of that.

[stefanpenner]

@jdalton yes, we need to be consistent about this. The current state is the result of much scenario solving but we a more holistic set of solutions.

Currently ember always falls back to existing natives, but clearly we don't actually want this. As it may result in future breakages.

if it wasn't for Ember's Enumerable, I would opt immediately to drop our version of this and move to a minimal lodash.

[totaltrek]

+1

Extending native prototypes is always dangerous and usually avoidable. I haven't yet used Ember, and this is the main reason why. I want my apps to gracefully upgrade as well as they gracefully degrade.

It seems to me that the reason prototypes are extended inside Ember is for syntactic sugar, which, let's be honest, is a fantastic goal. I just worry that it's following such a bad practice that the project itself will suffer in the long term.

As an example, let's look at Function#property -- the sugar that lets us "allow you to treat a function like a property" (quoting the docs). If ECMA version 7 defines a radically different #property on the native Function prototype, all ember apps risk immediate and permanent failure without crisis-mode maintenance. Instead of attaching #property why is the sugar not defined as follows?

App.model = Ember.Object.extend{
    oneAttr: 'a string',
    anotherAttr: [ 'an', 'array' ],
    someAttr: Ember.Property( function () {
        return this.anotherAttr.reverse().concat( this.oneAttr ).reverse()
    }, this )
}
--
> model.someAttr();
'a string an array'

This solves at least three problems: one, interfering with the native prototype; two, replacing sugar with safety and consistency; three, I'm not using Ember yet. The only problem remaining is the dusty example code on stackoverflow, random blogs, codeschool, and the like; most of which is already behind if not broken since it was published.

PLEASE NOTE: I'm not suggesting Ember.Property( function ) as an implementation target here. That is pseudocode provided merely to illustrate a potential solution. Looking at ember-runtime/lib/ext/function.js it seems that Function#property might be fairly easily portable to a new Property class in the Ember namespace.

[OrKoN]

@totaltrek

I think what you suggest is already there (see Ember.computed):

var Person = Ember.Object.extend({
  firstName: 'Betty',
  lastName: 'Jones',

  fullName: Ember.computed('firstName', 'lastName', function(key, value) {
    return this.get('firstName') + ' ' + this.get('lastName');
  })
});

So one can easily avoid using prototype extensions. And projects such as ember-watson can convert your existing code if you wish: https://github.com/abuiles/ember-watson#ember-watsonconvert-prototype-extensions. Also see this emberjs/guides#110

[stefanpenner]

So we will be making an effort during the 2 -> 3x lifespan to mitigate the performance issues caused by totally disabling prototype extensions (which is one of the main blockers). There are several ergonomic things that will need to be improved as well, but nothing very hard just laborious.

I have also thrown together a first pass at updating the guides to prefer non-prototype extension modes for the 2 most common ones. emberjs/guides#110

A future effort will dig into the array extensions (which are the most gnarly, and without them the current internals will suffer performance issues, but this can be mitigated)