Alternative proposal to privateName.public
Mark S. Miller
erights at google.com
Mon Dec 26 11:01:56 PST 2011
On Mon, Dec 26, 2011 at 8:27 AM, Erik Corry <erik.corry at gmail.com> wrote:
> > On a side note, I have seen a talk where someone mentionned that the
> > because Node has support for some ES5 features that legacy web browsers
> > can't even emuate.
> It's also partly bullshit because most of the time you want to write
> very different code on the server and the client. For one thing the
> trust model is completely different and that has a huge effect on all
> the code.
Hi Erik, I'm wondering what you have in mind here. Could you please expand?
> For another the modules infrastructure that you have on
> node is (for good reasons, I suspect) completely different to the
> infrastructure available on the client, which makes a difference to
> the way you structure your program.
AMD (Asynchronous Module Definition) as supported on the client by
require.js and curl.js is catching on for precisely that reason. There is
no shortage of adapters between AMD and CommonJS modules, so AMD modules
are also quite usable on the server.
> Never the less, there is a subset of JS that can be used on both the
> server and a given subset of supported clients, which is about the
> most you can expect.
Which subset do you have in mind? Our ES5 emulation works on all ES3
clients on which we've tested, going back to IE6.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss