W3C Community Group: "Client & Server JavaScript APIs"

[Alexandre Morgaut]

Hi,

some times ago I added some W3C/HTML5 APIs as references to look at for the design of server-side APIs 

I tried to propose a Server-side adapted version of XMLHttpRequest and encouraged the support of "console".

We also have on the wiki a proposal to support Web Workers via the Worker module.

When ServerJS was renamed CommonJS, one of the expectations was to address not only the server but also the client.

I had a dream... To have a real ubiquitous language.... and not only the ECMAScript part of JavaScript.

Modules haves been created to be able to share components between many JavaScript environments, but what we can see is that the biggest collection of Modules runs only on Node.js, and that Node.js APIs might become a new standard...with only asynchronous APIs (excepting require)

At Wakanda we have been looking everywhere for which standards to support, and because we wanted interoperable code even with client-side scripting we often looked to what was designed on this side... We then started to support, as some of you may know from my talk at the first Wakanday conference: XMLHttpRequest, sessionStorage, console, Workers, File, FileSystem, Blob, structured clones, Blobs... And I must admit that for compatibility with existing modules, we also implemented the support of some Node.js APIs.

Some have said before that HTML5/W3C APIs were not adapted to the server-side context. It is or was partly true... 

But today:

- the client-side also have Worker which don't have graphic interface 

- the offline mode made them specify very server-side related APIs like SQL, Sockets, FileSystem, Base64

The WebCL draft already include specific section saying when part of the specification can not be exposed in Worker or Server-side context...

And what's great, is that most of those APIs have been specified for either synchronous & asynchronous usage

Wakanda is able to run some threads in asynchronous mode and I heard that RingoJS can do it too.

Even when real asynchronous is not an option, asynchronous can generally be simulated, we did it for XMLHttpRequest which take care to call the onreadystatechange handler with each adequate state value. 

I don't ask people here to drop CommonJS APIs

I just ask you, if you are interested, to participate in the community group I proposed to:

- propose enhancements of Client-side API specifications with some potential section about the server-side context

- start to implement some of them in your environments

The proposed community group is there: http://www.w3.org/community/groups/proposed/#jseverywhere

Such initiative might generate a new collection of modules that would run not only on client-side but also on our server-side implementations... And maybe in the future could also be interoperable with Node.js if they play this game with us.

Note:

If you are not comfortable with a native support of those APIs, they could still be only injected in the context with the call of global or specific modules

- require('w3c/XMLHttpRequest2')

- require('w3c/FileSystem')

- require('w3c') // inject all the available w3c APIs

 

[Alexandre Morgaut]

I forgot to say

Web Workers allows now to run synchronous code on client-side without blocking the user interface

It is then now possible to implement require() on client-side as it is running on server-side. 

The perfect example is that importScript(), available in Worker contexts, also work synchronously.

http://www.w3.org/TR/workers/#dom-workerglobalscope-importscripts

 

[Alexandre Morgaut]

Another input

The FileSystem API, even it quite complicated, includes an interesting concept of filesystem sandbox which make perfect sense in shared hosting server environments

[Alexandre Morgaut]

I'm happy to announce that this Community Group has been validated:

You can now join it from this URL: http://www.w3.org/community/jseverywhere/