Repository navigation
Isomorphism #17
Description
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 :)
Activity
domenic commentedon May 19, 2015
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 commentedon May 19, 2015
Huge +1 too.
And
ArrayBuffer,BufferSource,Blobshould also be considered to replace currentBufferAPI.@domenic About
TextDecoder, I think in many cases what I really wanted is a USVIterator for the buffer/stream/USVString .trevnorris commentedon May 19, 2015
@hax Because of changes in V8,
Uint8ArraybackedBuffers are being forced upon us.bmeck commentedon May 19, 2015
+1 for primitives (typed array usage / Blobs, console, url); not sold on file api, fetch, or whatwg streams.
Fishrock123 commentedon May 20, 2015
+1 @bmeck; it may be prudent to be at least somewhat selective with great discussion on this.
Jxck commentedon May 21, 2015
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.
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 commentedon Apr 2, 2017
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.