Fwd: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

[Yehuda Katz]

Sent from my iPhone

Begin forwarded message:

> From: Yehuda Katz <wycats at gmail.com>
> Date: October 30, 2007 11:26:58 AM PDT
> To: Michael O'Brien <mob at mbedthis.com>
> Cc: es4-discuss <es4-discuss at mozilla.org>
> Subject: Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM
>

> I spent all of yesterday writing code in ES4 but the current state  
> of the RI is so crippling as to make it a fairly useless tool for  
> exploring how one would really write ES4 code.
>
> Pretty much every time I tried to use a neat feature to simplify, it  
> was unimplemented or broken.
>
> Additionally, the way numbers work is extremely unintuitive and  
> inconsistent. That said, I'm really looking forward to a more stable  
> RI because ES4, when fully implemented, will be glorious.
>
> Sent from my iPhone
>
> On Oct 30, 2007, at 11:15 AM, Michael O'Brien <mob at mbedthis.com>  
> wrote:
>
>> Totally agree that ES4 can be implemented without undue bloat. ES4  
>> VMs
>> should remain small with modest growth despite the features being
>> considered for ES4.
>>
>> We too are creating a compliant ES4 implementation to serve embedded
>> devices. So our target is not so much browsers, but small embedded
>> devices including mobile. Typical uses are mobile widget engines and
>> embedded web servers. Our implementation (EJScript to add yet another
>> name) is dual license: open source and commercial as are our previous
>> embedded projects. You won't see much on our web about this yet --
>> working too hard to complete our Alpha ;-), but we have both a Java  
>> and
>> C VM running the majority of the ES4 language already including  
>> most of
>> the big items: classes, packages, units, type annotations and have  
>> been
>> using it in some commercial products already. So we are field testing
>> ES4 features as we go.
>>
>> Our all up target memory footprint is < 250K for a minimal script. We
>> are currently on target although we are missing some of the runtime
>> library. We have a split compile / VM design so this does not include
>> the compiler footprint. We have found that some of the ES4 features  
>> are
>> essential for us to get such a small base footprint. The improved  
>> typing
>> greatly enhances early binding and helps allows byte code sizes to be
>> reduced. Now if you have large programs and large object counts --
>> memory will go up of course.
>>
>> I would STRONGLY urge that those who have concerns about the ES4  
>> spec,
>> engage and try writing some code with ES4.  The features blend well  
>> and
>> the end result is a nice expressive language that keeps the old ES3
>> dynamism but adds powerful constructs for safer, more scalable  
>> programs.
>> It seems to wear well the more you use it. It also works well
>> incrementally where you can start with ES3 and selectively employ ES4
>> features as you wish.
>>
>> Michael O'Brien
>>
>>
>> Steven Johnson wrote:
>>> The suggestions of bloat and instability from some corners are  
>>> rather
>>> disingenuous when you consider that
>>>
>>> (1) at least one high-quality ES4 engine (Tamarin) will be  
>>> available with a
>>> source license compatible with both open-source and commercial  
>>> vendors, so
>>> the claim that it will be hard for browser vendors to implement can
>>> theoretically be reduced to a claim that it will be hard for  
>>> browser vendors
>>> to integrate. (Sure, there may be technical or political obstacles  
>>> to using
>>> a particular engine, but assuming that the ES4 spec will require  
>>> every
>>> browser vendor to write their own implementation is clearly false.)
>>>
>>> (2) at least two active contributors to Tamarin (Adobe and  
>>> Mozilla) have a
>>> very high vested interest in keeping code size small, as the  
>>> success of both
>>> Flash Player and Firefox are predicated on acceptable download  
>>> sizes.
>>>
>>> As Tom pointed out, the compiler for ES4 will definitely get more  
>>> complex,
>>> but the VM is unlikely to grow significantly in size or complexity.
>>>
>>> _______________________________________________
>>> Es4-discuss mailing list
>>> Es4-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es4-discuss
>>>
>>>
>> _______________________________________________
>> Es4-discuss mailing list
>> Es4-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es4-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20071030/5f565a96/attachment-0002.html