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 > [email protected] > https://mail.mozilla.org/listinfo/es4-discuss > > _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
