nodejs / NG

Next Generation JavaScript IO Platform
103 stars 12 forks source link

Isomorphism #17

Open yosuke-furukawa opened 9 years ago

yosuke-furukawa commented 9 years ago

As discussed on https://github.com/nodejs/io.js/issues/1716 and https://github.com/nodejs/io.js/pull/1727 the discussion has some aspects like.

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: https://github.com/nodejs/NG/issues/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.

Next Generation Node should consider the isomorphic API :)

domenic commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

bmeck commented 9 years ago

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

Fishrock123 commented 9 years ago

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

Jxck commented 9 years ago

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 commented 7 years ago

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.