Additional language features

Erik Corry erik.corry at
Mon Mar 7 01:46:04 PST 2011

2011/3/5 Christian Mayer <mail at>:
> Hash: SHA256
> Hello together!
> Currently I'm writing a (for me) large project that is heavily using
> JavaScript / ECMAScript. During that project I found a few features
> missing in the language that could easily be added and where I think
> that many programmers could profit from:
> 1) A printf compatible format string
> ====================================
> For example the String object could be extended by a sprintf type of
> function / method that takes a printf compatible format sting and the
> additional values. Currently there are lots of libraries that provide
> that functionality - but all cover only a small subset and it's not know
> which are in good shape or not...

This seems like a library and not a language issue.  Why not just pick
one, add the stuff you need, open source the result?  Unless you are
willing to wait several years for browsers to support your project you
will have to do this anyway.

> 2) A binary type conversion including float
> ===========================================
> My project is using AJAX technology to transmit measurement data over
> the net in JSON notation. This data contains IEEE float values, encoding
> their bit and byte representation in hex values.

That seems like a poor decision for an interchange format.  ASCII fp
values work rather well.  What is the space penalty for decimal vs hex
of gzipped data once you have already taken the hit for the JSON

> In the browser I need to convert that hex string back into a float value
> - - which is quite complicated as I have to implement an IEEE 754 "parser".

> Especially for the use with WebSockets it would be a great help to have
> a functionality that allows to pack and unpack binary data into
> ECMAScript objects.
> A possible syntax (and much better description of what I need) give the
> "pack" and "unpack" commands in the Perl language.
> 3) A fast library for small, fixed size vectors (numerical arrays)

How fast does this need to be.  Did you already do benchmarks on
modern browsers for the stuff you need.

> ==================================================================
> For 2D and 3D purposes it would be great to have a data type / object
> that is specialized for 2D, 3D and 4D values. It might even internally
> map to a SIMD datatype if the CPU running the interpreter is supporting
> it (e.g. a SSE type value for x86 processors; other CPU architectures
> have similar extensions).
> Especially for the Canvas and WebGL it would be great to have such a
> data type.
> For this data type it would be great to have a library supporting it and
> provide linear algebra functionality (matrix multiplication, etc.)
> The C++ library Eigen2 provides everything that is necessary (and even
> more...)
> So I hope I didn't write my ideas to the wrong list (if it is so, please
> correct me!). And I hope you can tell me if those additions could make
> it on the next spec of ECMAScript.

In general I am of the opinion that if the language already offers the
building bricks that you need to do your task then it requires some
special reason why you can't just make a JS level library that fits
your needs.  Basically, you need to have tried it and found that it
doesn't work for you for some fundamental reason.  Speed is not
necessarily an argument, since performance is improving all the time
and improvements to the optimization of JS code is the rising tide
that lifts all boats.  Adding the library you need to the platform has
several disadvantages:

* It makes the platform large and unwieldy.  This worsens download
times, security surface, learning curve.
* It takes years before you can rely on support.
* It locks down the API prematurely, where JS based libraries are free
to evolve.

The role of a language standards body is to say no most of the time.
Anything else leads to a monster of a standard.

Erik Corry

More information about the es-discuss mailing list