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

[Michael O'Brien]

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
>
>