incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Wasilewski <devudes...@gmail.com>
Subject Re: FalconJS has landed
Date Tue, 27 Nov 2012 22:56:24 GMT
No no, don't shout up :) keep going.

I have read the article provided by you carefully.
If you will copy and paste it, and prepare a little function to 
find/replace this sentence

"The simplest way to create a module in JavaScript is to use an *object 
literal"* with "*prototype*"
The rest of above that sentence seems to be perfect.

Anything below is just a consequence of statement.

In JS word you will find bunch of old school JScripters they will 
advocate and stands for the one thing:

Why on earth language that have a 'globals' concept needs a Singleton 
pattern? The only thing/feature that can come to mind of proper OOP 
language developer like C#, Java, AS3 is safety. We understand a concept 
of public, final, abstract, private, protected. When writing API for 
others to reuse it is even more important to use all advantage of those 
languages. How many times in AS3 we using abstract or singleton 
regardless of lack of native support? Because we do understand 
importance of strict and structured language in rapid development.

However, when comes to FalconJS the task is to use strict proper OOP 
language like AS3 to translate into JS. In my humble opinion, this is 
what is all about, to protect us and give us more robust development 
environment and target the platform we need without writing FOR the 
platform. The fact that we are using AS3, output doesn't need to 
leverage all those concepts on the target level at all. Even if the 
output code would be set of plain objects or procedural style chain of 
objects, if better for performance and the final result, better for 
everyone. Good for marketing Apache Flex JS as the robust environment, 
web RIA development environment.

P.S.
I took a break after my previous email, but I will definitely do some 
JSperf test for tomorrow with inheritance, to show a full picture.

Dan

On 11/27/2012 7:46 PM, Erik de Bruin wrote:
> One more thought (yes, I really can't help myself):
>
> Google chose to go with closures (obviously), and I'm sure they care
> about all the stuff you mention... And I'd say they have some
> experience with building and maintaining large javascript projects. As
> does Yahoo (YUI), jQuery and I'm sure others as well. They most likely
> did their due diligence before choosing this technique over the
> others, something we could benefit from.
>
> A good place - albeit a bit random - to start reading about the
> benefits of the approach I am advocating is:
>
> http://www.examplejs.com/?p=250
>
> Ok, I'll shut up now ;-)
>
> EdB
>
>
>
>
> On Tue, Nov 27, 2012 at 7:23 PM, Daniel Wasilewski <devudesign@gmail.com> wrote:
>> Erik,
>>
>> If you don't care about memory consumption, output file size, long prototype
>> chain, inheritance, slow downs on bigger structures than 1 plain objects...
>> use it.
>> Again, not saying let's prefer or favour one of the method over another,
>> those things keeps changing over the time.
>> This test just 2 years ago would be a different picture.
>>
>> All I am saying is to have ability to control he output of grammar of JS. I
>> know my English is not perfect but that's my only point i am trying to make.
>> If you feel it's endless... sorry. It wasn't my intention to make it long.
>> But rather invite to constructive discussion. It is easy to say NO to
>> solution I think doesn't suits me without giving any reason.
>>
>> I would like to hear about pros of module pattern myself. Prove me wrong, I
>> will shout up :)
>> I am not JS expert. But let's not make design decisions based on the latests
>> trends, but technical reasoning.
>>
>> Dan
>>
>>
>> On 11/27/2012 4:38 PM, Erik de Bruin wrote:
>>> Dan,
>>>
>>> This is my last comment on the subject, as I foresee another endless
>>> discussion, but:
>>>
>>> Closure (Module Pattern) outperforms any other 'style' at least 2 to 1
>>> on the test you quote, yet you recommend that we don't use it?
>>>
>>> EdB
>>>
>>>
>>>
>>> On Tue, Nov 27, 2012 at 5:22 PM, Daniel Wasilewski <devudesign@gmail.com>
>>> wrote:
>>>> I'll try to help Alex :)
>>>> But he may correct me if I am wrong.
>>>>
>>>>
>>>> I believe this little test will show full picture and all 4 common styles
>>>> of
>>>> JS programming we are talking about here.
>>>>
>>>> Notice there is nothing about inheritance, just plain objects (classes)
>>>> Once inheritance is involved things are slowing down with different
>>>> ratios.
>>>>
>>>> http://jsperf.com/closures-vs-objects-vs-object-literals-vs-prototype/2
>>>>
>>>> Current proposed style of JS output is Object Literal (red bar in that
>>>> test);
>>>> Prototype (green bar) in plain object test seems to be 2nd solution
>>>> outperformed by closure (blue bar) these days.
>>>>
>>>> But when inheritance is involved blue bar is getting shorter and
>>>> prototype
>>>> is catching up.
>>>> Prototype pattern has also less footprint, since you adding 1 shared
>>>> behaviour to your object that will be reused wherever possible instead
>>>> creating brand new object.
>>>>
>>>> There is no surprise why Closure style runs very well on web kit based
>>>> browsers since Google promoting this style and making optimisation just
>>>> for
>>>> it.
>>>> FireFox trying to catch up, but Safari seems to do well both.
>>>>
>>>>
>>>> Here is a little example of inheritance done with prototype pattern
>>>>
>>>> var Class = function(){}; //empty function to avoid invocation during
>>>>
>>>> Function.prototype.extend = function(C){
>>>>     Class.prototype = C.prototype;
>>>>     this.prototype = new Class();
>>>>     this.prototype.constructor = this;
>>>>     return this.prototype
>>>> };
>>>>
>>>> now you can easily do this:
>>>>
>>>> function EventDispatcher(){}
>>>> p = EventDispatcher.prototype;
>>>>
>>>> function DisplayObject(){
>>>>       EventDispatcher.call(this); //equivalent of super
>>>> }
>>>> p = DisplayObject.extend(EventDispatcher);
>>>>
>>>> THis is obviously simplified form of what is really needed but it is good
>>>> enough to cover lots of aspects already.
>>>> Don't want to repeat what has been already sent here as examples, but
>>>> simplicity and speed of this solution will outperform anything in
>>>> real-project-use-case-scenario.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 11/27/2012 8:06 AM, Erik de Bruin wrote:
>>>>> Alex,
>>>>>
>>>>> You keep referring to a "prototype". I might be missing something.
>>>>> Where can I find it/how do I run it?
>>>>>
>>>>> EdB
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Nov 26, 2012 at 10:32 PM, Alex Harui <aharui@adobe.com>
wrote:
>>>>>
>>>
>
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message