6 ms·

What do you mean by reuse of web apis? I’m curious to read up on this feature.

tehbeard 6y ago
Things like ArrayBuffer/view, fetch(...) and worker threads being the same spec/interfaces as the browser implementations rather than homegrown stuff like Buffer, child_process and any number of npm wrappers around the http module in node.
- TechBro8615 6y ago
  Hopefully the story is the same in five years after Deno and browsers have both had time to evolve. Are there plans in place for tracking future updates to Web APIs in Deno?
  - mark_and_sweep 6y ago
    I believe so. Recently Deno started running a subset of the Web Platform Tests to test compatibility. See: https://deno.land/manual/contributing/web_platform_tests https://deno.land/manual/contributing/web_platform_tests
monocasa 6y ago
Defaulting to browser based APIs when they exist (like a global 'window' element to access the DOM), rather than reinventing the wheel the way Node did. Although to be fair a lot of Node APIs predate their browser equivalents, and in a lot of ways the browser contains a 2.0 version of a lot of Node APIs.
- paxys 6y ago
  I can't think of a single case of Node reinventing the wheel with their APIs. Like you said, they were all created to fill gaps in browser JS implementations. It's obviously going to be hard to reconcile the two as browsers themselves increase their API surface, but then Deno is going to run into the same problem eventually.
  - IggleSniggle 6y ago
    I think that depends on how much deno commits to following the web APIs with each release. Actually, nodejs has really done a lot of catching up with deno in this regard. It just has to support both the “legacy” way and the “forward looking” way where deno does not.
  - jonny_eh 6y ago
    Node introduced the "global" object instead of using the existing "window" object the pre-existed in all browsers.
    - sdfin 6y ago
      At least whe have "globalThis" now.
  - rektide 6y ago
    node actually invented a lot of wheels. node was first with promises (a couple major iterations!), streams, uhh I dunno what else. file access (we're just getting that now in the browser after some old ill supported early attempts). modules. the web reinvented many of these wheels.
    - eyelidlessness 6y ago
      Node didn’t introduce the Promise API. Although it definitely instigated it. Node, with its async IO model, was just littered with callbacks. There were a zillion different approaches to async APIs that could ease that. Promises were, well, the most promising. But years of iteration and competing standards came and went before Node adopted them as the preferred API. And they did so right along with browser vendors and web standardization bodies.
      - rektide 6y ago
        I was referring to node <0.1.30[1] which did have promises for a while. largely from jQuery deferred, which were ungood in a couple ways I don't remember. but also remarkably similar. I still largely think kris kowal building the "Q" promise library is what made promises interesting, what surfaced the idea that we might want to first-class our completeablea/futures. I know kris had some specific inspirations but I forget what. pains me somewhat to this day that promises ultimately became somewhat un-value like, that handlers don't get to see what it was resolving. all the chain/spawn discussion, the functional promise folk: they got rolled by those insisting we had to target only the lowest rings of the developership, and that allowing more potent systems was unacceptable. wish I could find those es-discusa threads, for the powerful sorrow of the afteath, what we are stuck with, in it's so lites form, haunts me. especially as we double back a decade latter & invent controllers & signals toanage our promises. which we would have had for free. way off topic now. forgive me my late night ramblings. [1] https://github.com/nodejs/node-v0.x-archive/blob/v0.1.30/ChangeLog#L5 https://github.com/nodejs/node-v0.x-archive/blob/v0.1.30/Cha...
- maga 6y ago
  This. I started tinkering with node shortly after I heard Ryan introduce it at JSConf EU, and it was a very different world, not much for Node to draw from on the browser side, no modules, no promises, not even TypedArrays IIRC.
tengbretson 6y ago
Things like using UInt8Arrays instead of Node's homemade Buffer class, fetch, using WHATWG's implementation of Streams, Blob, WebWorker, etc.
- austincheney 6y ago
  Node's homemade Buffer class uses UInt8Arrays. https://nodejs.org/dist/latest-v15.x/docs/api/buffer.html#buffer_buffer https://nodejs.org/dist/latest-v15.x/docs/api/buffer.html#bu...
  - bavell 6y ago
    Not originally though: https://nodejs.org/dist/latest-v10.x/docs/api/buffer.html#buffer_buffer https://nodejs.org/dist/latest-v10.x/docs/api/buffer.html#bu...
deleted 6y ago
[deleted]

Things like ArrayBuffer/view, fetch(...) and worker threads being the same spec/interfaces as the browser implementations rather than homegrown stuff like Buffer, child_process and any number of npm wrappers around the http module in node.

TechBro8615 6y ago
Hopefully the story is the same in five years after Deno and browsers have both had time to evolve. Are there plans in place for tracking future updates to Web APIs in Deno?
- mark_and_sweep 6y ago
  I believe so. Recently Deno started running a subset of the Web Platform Tests to test compatibility. See: https://deno.land/manual/contributing/web_platform_tests https://deno.land/manual/contributing/web_platform_tests

monocasa 6y ago

Defaulting to browser based APIs when they exist (like a global 'window' element to access the DOM), rather than reinventing the wheel the way Node did. Although to be fair a lot of Node APIs predate their browser equivalents, and in a lot of ways the browser contains a 2.0 version of a lot of Node APIs.

paxys 6y ago
I can't think of a single case of Node reinventing the wheel with their APIs. Like you said, they were all created to fill gaps in browser JS implementations. It's obviously going to be hard to reconcile the two as browsers themselves increase their API surface, but then Deno is going to run into the same problem eventually.
- IggleSniggle 6y ago
  I think that depends on how much deno commits to following the web APIs with each release. Actually, nodejs has really done a lot of catching up with deno in this regard. It just has to support both the “legacy” way and the “forward looking” way where deno does not.
- jonny_eh 6y ago
  Node introduced the "global" object instead of using the existing "window" object the pre-existed in all browsers.
  - sdfin 6y ago
    At least whe have "globalThis" now.
- rektide 6y ago
  node actually invented a lot of wheels. node was first with promises (a couple major iterations!), streams, uhh I dunno what else. file access (we're just getting that now in the browser after some old ill supported early attempts). modules. the web reinvented many of these wheels.
  - eyelidlessness 6y ago
    Node didn’t introduce the Promise API. Although it definitely instigated it. Node, with its async IO model, was just littered with callbacks. There were a zillion different approaches to async APIs that could ease that. Promises were, well, the most promising. But years of iteration and competing standards came and went before Node adopted them as the preferred API. And they did so right along with browser vendors and web standardization bodies.
    - rektide 6y ago
      I was referring to node <0.1.30[1] which did have promises for a while. largely from jQuery deferred, which were ungood in a couple ways I don't remember. but also remarkably similar. I still largely think kris kowal building the "Q" promise library is what made promises interesting, what surfaced the idea that we might want to first-class our completeablea/futures. I know kris had some specific inspirations but I forget what. pains me somewhat to this day that promises ultimately became somewhat un-value like, that handlers don't get to see what it was resolving. all the chain/spawn discussion, the functional promise folk: they got rolled by those insisting we had to target only the lowest rings of the developership, and that allowing more potent systems was unacceptable. wish I could find those es-discusa threads, for the powerful sorrow of the afteath, what we are stuck with, in it's so lites form, haunts me. especially as we double back a decade latter & invent controllers & signals toanage our promises. which we would have had for free. way off topic now. forgive me my late night ramblings. [1] https://github.com/nodejs/node-v0.x-archive/blob/v0.1.30/ChangeLog#L5 https://github.com/nodejs/node-v0.x-archive/blob/v0.1.30/Cha...
maga 6y ago
This. I started tinkering with node shortly after I heard Ryan introduce it at JSConf EU, and it was a very different world, not much for Node to draw from on the browser side, no modules, no promises, not even TypedArrays IIRC.

tengbretson 6y ago

Things like using UInt8Arrays instead of Node's homemade Buffer class, fetch, using WHATWG's implementation of Streams, Blob, WebWorker, etc.

austincheney 6y ago
Node's homemade Buffer class uses UInt8Arrays. https://nodejs.org/dist/latest-v15.x/docs/api/buffer.html#buffer_buffer https://nodejs.org/dist/latest-v15.x/docs/api/buffer.html#bu...
- bavell 6y ago
  Not originally though: https://nodejs.org/dist/latest-v10.x/docs/api/buffer.html#buffer_buffer https://nodejs.org/dist/latest-v10.x/docs/api/buffer.html#bu...

deleted 6y ago

[deleted]