ES Native Mode proposal

Michaël Rouges michael.rouges at gmail.com
Wed Sep 25 14:16:28 PDT 2013


Hum...the closures doesn't prenvent from foreign prototyping... and all
actual sorts of sandboxes are really heavy, much more than a possibly
native solution, mainly about performances, like my
Sandbox.js<https://github.com/Lcfvs/Sandbox.js>
.

Michaël Rouges - https://github.com/Lcfvs - @Lcfvs


2013/9/25 Andrea Giammarchi <andrea.giammarchi at gmail.com>

> in line ...
>
>
> On Wed, Sep 25, 2013 at 11:27 AM, Michaël Rouges <michael.rouges at gmail.com
> > wrote:
>
>> I personally don't use libraries, I create tools and advice every day
>> developers ... and it must be realistic, most don't even know what they
>> include.
>>
>
> which is why you don't want to promote a pattern that will be inevitable
> abusing so that developers will have messy code and unpredictable behaviors
> around because of these sort of native sandboxes in the wild.
>
>
>
>
>> I remember, visiting the site of a web agency where, in the middle of the
>> page, a dialog box is displayed to indicate that the webmaster had not
>> paid for a license to use a jQuery plugin.
>>
>
>
> This proposal of you will never solve that problem and actually should
> not/never solve that problem.
>
>
>
>
>>
>> So yes, I agree, it's the developer responsibility, but it would be nice that
>> there is a way to do so to ensure that the tools we propose behaves
>> exactly as desired, whatever the practices of the developer who uses
>> them.
>>
>>
> There are several old projects/libraries/snippets that created "extendible
> natives for everyone" and that increased the mess across developers. I
> wrote "Elsewhere" code, @jdalton worked on `fusejs`, many others had their
> own sandbox with their extends to natives cooler than everyone else (of
> course) and nobody used this stuff anyway.
>
> If you don't know what kind of environment you are running into you don't
> use method you don't know/expect to be there while if it's about securing
> your own piece of code/library there are already possible ways to guard it
> inside a closure and do whatever you want in there.
>
> I hoe you have enough examples and background to realize this is a bad
> idea that modules solved more elegantly and still you should not extend
> natives if not absolutely necessary ... not even ECMAScript guys in here do
> that ;-)
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130925/f3e9aa50/attachment-0001.html>


More information about the es-discuss mailing list