Isomorphism

[yosuke-furukawa]

As discussed on nodejs/node#1716 and nodejs/node#1727
the discussion has some aspects like.

• Should we implement the same API on browser?
• Should we put the API on core?

My opinion is core API gets closer to the browser API. (But as a first step, we should discuss what API is core / non-core. Ref: #10 )
isomorphism is so important for us. isomorphic libraries can be easier to learn API and test easily and improve reusability (we can use the library on both browser and server).

Node/io.js is not only server-side, we can use Node/io.js on client application(Electron, NW.js), AWS Lambda, IoT. The usage is increasing. isomorphism is so important.

So, we should get close to the browser API as possible. Of course we should give our opinions to browser API for feedback. I would like to remove the frictions between the browser and Node API.

IMO, The following API should get closer to browser.

• console (https://github.com/DeveloperToolsWG/console-object/blob/master/api.md)
• url (https://url.spec.whatwg.org/)
• stream (https://streams.spec.whatwg.org/)
• fetch (https://fetch.spec.whatwg.org/)

Next Generation Node should consider the isomorphic API :)

[domenic]

Huge +1. (Although IMO "isomorphic" is misused here throughout the community as a pretentious way of saying "portable".)

I also think TextEncoder/TextDecoder should be candidates, not because they're great APIs, but just for purposes of portability.

My work with V8 extras should help, here. With luck enabling some of these will be a simple matter grabbing a few files from Blink and adding a line to the gypfile. (Not Fetch obviously, or console, but the others are potentially doable.)

[hax]

Huge +1 too.

And ArrayBuffer, BufferSource, Blob should also be considered to replace current Buffer API.

@domenic About TextDecoder, I think in many cases what I really wanted is a USVIterator for the buffer/stream/USVString .

[trevnorris]

@hax Because of changes in V8, Uint8Array backed Buffers are being forced upon us.

[bmeck]

+1 for primitives (typed array usage / Blobs, console, url); not sold on file api, fetch, or whatwg streams.

[Fishrock123]

+1 @bmeck; it may be prudent to be at least somewhat selective with great discussion on this.

[Jxck]

I'm huge +1 for node-code to support API's like this.
FYI, exactly I'm working for this.
these are quite huge specs for my spare time, so currently work in progress actualy.

• https://github.com/Jxck/obtain-unicode
• https://github.com/Jxck/utf8-encoding (utf8 only in encoding standard)
• https://github.com/jxck/url
• https://github.com/Jxck/URLSearchParams
• https://github.com/Jxck/fetch

I'm using TypeScript for them, because I wanna respect WebIDL interface in whatwg spec, also I can check spec consistency.
after I finished writing I'll remove typescript staff and rewriting with es6 or so.

[watilde]

Since we've already started working on WHATWG URL impl in Node.js, it really makes sense to try to have some of the other standard APIs. I'd +1 on @bmeck's scope.