mob at mbedthis.com
Tue Oct 30 11:15:20 PDT 2007
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.
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
More information about the Es4-discuss