And this morning, there was a great introduction to workers.

It is exciting times again for animations in serverside JavaScript run times.

So, here I am to talk about our recent effort to bring a new set of APIs into Node Core.

This may be an opportunity for us to really think about the JavaScript API service in

the ecosystem and create a more universal developer experience across the different

platforms.

So, let's finish this that is right, I'm Joyee, I live in Hangzhou.

I worked on Gaia, and I'm a member of the Node steering committee.

On Twitter or GitHub, Joyee Cheung handle.

Some of you may be aware of this effort of bringing more web APIs into Node Core.

But maybe some folks are just curious because they hear things that are interesting.

So, in case I am using some lingoes that only a very few people understood.

So, what does it mean when we talk about bringing web APIs into Node Core? of well, we are basically

talking about adding browser APIs to the Node.js runtime as buildings.

So, you can run them on the server side without using npm install.

So, in this talk I will try to be objective and summarize how far we have come in this

journey, where we are, and where we are going.

On a teeny tiny side note, Node.js is silent.

So, like many others, I will try to use the correct pronunciation in this talk.

Here is a mental picture of how JavaScript in the wild came to be.

In the beginning before Node came along there were two kinds of APIs that came with the

runtime for JavaScript developers.

There were some JavaScript builtins like date, regular submissions, errors that were part

of the language.

It was created by system 9 and implemented by engines.

There was a host API.

And at that time hosts were basically just browsers.

These APIs were implemented by the browsers and are more or less run by organizations

like W3C.

And then Node was created a started to take off on the server side.

Initially it included some of the web APIs that were already present in the browsers.

Or like at least some APIs that look like what you'll find in browsers.

But Node also introduced several different APIs for doing certain things on the server

side like instead of even target in the browsers.

Because the semantics of the equivalent APIs on the browser side may not make sense for

servers.

Like, for example, there isn't one DOM tree in this execution context for events to bubble

through on the server side.

So, it does not really make sense to implement part of the event target specification in

Node.

So, as time goes by, browsers have developed and synthesized more APIs in the browser to

empower web developers.

While Node also developed several equivalent APIs on the server side with a didn't design.

Because of the popularity of the Node.js runtime, these home-grown APIs gradually became the

defacto factors for the server side run times.

But obviously no one likes to remember two sets of APIs for doing basically the same

thing.

So, over the past few years people have been sending feature requests to Node to bring

the two platforms closer together.

For now, it usually means making the runtime more compatible with browsers.

So, Node did evaluate and implement some of the requests and it is looking into more APIs

from the web.

So, we currently have different types of web APIs implemented in Node Core.

So, some of them are more localize the with the browsers.

And, for instance, we have methods in the browsers, and this is the living standard

of the timers in the HTML specification.

In Node we also have a set of timer APIs, that's similar, but the implementation does

not strictly follow what the browsers do.

For example, it returns an object while browsers usually return a number instead.

The other type of web APIs we have in Node Core are the ones implemented with an existing

specification in mind and behave mostly the same as the APIs that you will find in browsers.

For instance, the new URL implementation in Node Core was developed specifically according

to the URL standard.

This means we did look at the spec test when we implemented them.

And we also have tests.

So, how do we know how close our implementations are to the ones in the browser?

We run a subset of the web platform tests which are tests which are on browsers and

other implementations.

So, to see the current status of the performance in Node, you can look at the status files

under tests, the status folder of the Node project.

There are a few pretty selfexplanatory JSON files documenting the web standards implemented

in Node.

So, this one is not technically a web API addition, but I wanted to mention that there

is now another type of web standards implemented in the core.

We have collaborated with the what is the HTML specification and the first implementation

of JSON modules has landed in the master branch as part of our experimental ECMAScript module.

So, Node implemented first.

So, here we have the web APIs implemented in Node Core that can be alternatives to certain

home-grown Node build teams.

Legacy methods under the URL and the string built in module can be replaced by the new

URL and the URL search params classes.

And searching and coding and decoding methods of buffer and string decoder can be replaced

by text decoder and text decoder as well.

And there is the performance API which, for example, can be used to replace certain timing

methods in the process object.

In addition, we also have some APIs that are not exactly replacements for existing Node

APIs.

But are similar enough in many use cases that it is reasonable to consider them as alternatives.

Be sure to read the documentation if you want to rewrite your code with these APIs.

For example, cue microtask can be used to cue a microtask which will be run asynchronously

which will be used to replace the process if you do not have strict requirements about

the timing you want your task to be run.

There is also web worker which spawns threads in Node.

And it may be used to replace child processes if you are only looking for a way to upload

and you don't necessarily need processes.

So, as of Node 12, we have several web API implementations that are now stable and can

be used in production.

Those are listed on the left here.

And these are available as globals.

So, you don't have to require a builtin to get hold of them.

These are also covered by the web platform task in Node Core.

There may be some additional extensions in these APIs.

There's some minor unspecified behavior differences.

But at least those are fairly limited, and we are aware of them.

We also have a few APIs that are still experimental which means there may still be breaking changes

in the future.

These are currently placed under builtin modules and not on the global object yet.

The current experimental web APIs that we have are workers and performance time being

API.

But they also differ significantly from what you would get from the browsers.

And we do not run web platform tests for them yet.

So, watch out.

So, there is also an implementation of WebAssembly, the JavaScript API of WebAssembly that we

get for free from V8.

But the web API of it has not been implemented yet.

Other than existing APIs, there are a bunch of others that are hunting the issue tracker.

Oops.

There are still under active discussion.

They're web strings which are the foundation of web specifications.

But then we already have Node strings in Core which are also the foundation of many existing

Node Core APIs.

In case you didn't know, there are many different types of strings in Node.

There's string number one.

Which has several issues.

So, they now introduce string number two.

But then they also had some issues.

And then actually introduce string number three which still had issues.

So, there's now a new implementation of strings called Bob which is under development for

some time.

And will hopefully solve all our problems.

Anyway, this is not a string talk.

You can read the documentation if you want to learn more about them.

So, with all the strings, you can imagine how complicated it would be to bring yet another

string into Node Core.

And there is also Fetch.

Which is probably the most requested web API in Node Core.

We just had a session about it this week at the Open JS Coverage Summit in Berlin and

there is now a new work in progress pull request to bring it fresh into Node Core.

Yay!

[ Applause ] So, we have to talk about the history of these

web APIs in Node and what may be coming next.

So, why exactly are we doing this?

One obvious run is with a common API surface, there is less cognitive burden for developers.

We could their documentation, tutorials, tooling.

Instead of developing and maintaining a separate set of educational resources.

This is especially important for just beginners.

At the moment they have to choose between Web APIs and Node APIs when they are just

getting started.

With a common API service, beginners can be less distracted learning about basics.

There are still differences between the two platforms.

But it will be less intimidating when they already learned a bit more about these APIs.

So, another reason for web APIs into Node core, we have more containers compared to

more npm modules.

This is open source and it's natural that contributors come and go.

In Node, even when the existing maintainers of a specific builtin module shop less often,

we have an open governance and an effective nomination and onboarding process to bring

new contributors into the team.

Compared to regular npm modules, this kind of maintenance story fits better with the

Web APIs that are designed as builtins for the host environment.

So, if you have been paying some attention to this topic, you may be aware that it takes

an extraordinary amount of time for this API additions to be accepted into Node Core.

Here I will lay out some of the reasons why there are several requests that keep showing

up in the issue checker but have never really gone anywhere.

So, everything I'm going to talk about later are in the context of the consensusseeking

model of Node Core.

So, Node Core is operated under the consensus from over 100 core collaborators.

These are contributors who have write access to the repository.

For every technical decision, any one of these 100 more than 100 Node Core collaborators

creates an objection.

If consensus cannot be reached within the collaborators, it may come down to a vote

among the members of the tech committee who are a subset of the collaborators.

But we usually try to avoid voting.

We also take community feedback into account even if it's not from someone who has committed

into Node before.

So, here are the common arguments against adding Web APIs into Node Core.

There is still, to some extent, a small core philosophy within Node Core.

It's about providing only the basics functionalities in Core and empower users to implement user

modules instead of building our own opinionated APIs that may become a compatibility or maintenance

burden.

This philosophy has been broken several times in the past.

But at least as far as Web API goes, we are still mostly just trying to expose the existing

functionalities through a different API services.

This is not exactly an idea that's welcomed by everybody either.

Especially when the web API may also lack features that do not make sense for browsers.

Oh, yeah.

And like sometimes they may be necessary for servers.

So, one alternative to adding these APIs in Node is to release them as official modules.

Theoretically for modules that are maintained under the Node organization, it will be possible

to have a maintenance story similar to the one that Node query has.

But some may also argue that it is easier to optimize if it's done in Core because it

can use certain internal APIs.

Or sometimes it may just not be technically possible to implement something without access

to internals.

A part of the philosophical concerns, apart from those, there are concerns about the design

of the web APIs.

They're more than just a bunch of interfaces.

Behind the Design of these APIs, there is just a very different context.

For instance, the browser has a very different security model.

When you fetch an API endpoint, for example, at a script and you want to send credentials

like cookies along with the request.

Fetch as implemented according to the specifications should follow the crossorigin resource protocol

and check the access control allowed header in the HTTP response before invoking that

with the data.