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

[Yehuda Katz]

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