Adding Websocket support to core #19308

MylesBorins · Mar 13, 2018

The original thread where adding this was discussed #1010 was closed with a decision by the iojs TC to rather implement lower level buffer methods, but that was abandoned.

There is an open EPS to add the feature, but we have since abandoned the process.

Some of the people who originally were -1 changed their opinions in #1010 more recently. In fact, we already ship a partial implementation of ws in the inspector.

I think it might be worth us revisiting adding WS to core.

/cc @eugeneo @rauchg

Re: Inspector.

Inspector WS implementation is not complete, e.g. there is no support for binary frames.
Inspector would still need a C++ implementation that can run on a separate thread. Both JS execution and main libuv loop are suspended when the application hits a breakpoint.

eugeneo · Mar 13, 2018

Re: Inspector.

Inspector WS implementation is not complete, e.g. there is no support for binary frames.
Inspector would still need a C++ implementation that can run on a separate thread. Both JS execution and main libuv loop are suspended when the application hits a breakpoint.

i'm not wholly against this but i would like to factor in how much stuff we put into all our release binaries. if we can come up with more creative ways for shipping stuff like this i'm totally a +1 (#19307)

devsnek · Mar 13, 2018

i'm not wholly against this but i would like to factor in how much stuff we put into all our release binaries. if we can come up with more creative ways for shipping stuff like this i'm totally a +1 (#19307)

I am still -1 on this.

mscdex · Mar 13, 2018

I am still -1 on this.

@mscdex can you be explicit in your reasoning?

devsnek · Mar 13, 2018

@mscdex can you be explicit in your reasoning?

@devsnek for the same reasons I gave in the linked issue.

mscdex · Mar 13, 2018

@devsnek for the same reasons I gave in the linked issue.

As discussed in #1010 and as a maintainer of ws I'm +1 on adding WebSocket to core.

lpinca · Mar 13, 2018

As discussed in #1010 and as a maintainer of ws I'm +1 on adding WebSocket to core.

@mscdex in #1010

-1 WebSockets is still something better suited for userland IMHO. Sure it's something that many people do use, but there are also many other widely used standardized protocols/APIs that could be argued as "core" to the "web" that are not currently included in node/io.js core. For example: multipart parsing/generation, Server-sent events, HTTP/2, ICMP, SSH/SFTP, FTP, SOCKS, VNC/RFB, SMTP/IMAP/POP3, SOAP, Web Workers (as an API), XHR/XHR2 (as an API), etc.

Since this original post we've added http2. While you listed a bunch of protocols not all of them are supported natively by the browser.

https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API

https://caniuse.com/#search=Websockets

MylesBorins · Mar 13, 2018

@mscdex in #1010

-1 WebSockets is still something better suited for userland IMHO. Sure it's something that many people do use, but there are also many other widely used standardized protocols/APIs that could be argued as "core" to the "web" that are not currently included in node/io.js core. For example: multipart parsing/generation, Server-sent events, HTTP/2, ICMP, SSH/SFTP, FTP, SOCKS, VNC/RFB, SMTP/IMAP/POP3, SOAP, Web Workers (as an API), XHR/XHR2 (as an API), etc.

Since this original post we've added http2. While you listed a bunch of protocols not all of them are supported natively by the browser.

https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API

https://caniuse.com/#search=Websockets

@MylesBorins I don't think node should aim to become a (DOM-less) browser. Anyway, my "vote" and reasoning still stands.

mscdex · Mar 13, 2018

@MylesBorins I don't think node should aim to become a (DOM-less) browser. Anyway, my "vote" and reasoning still stands.

It's more about communicating with browsers, not becoming one.

targos · Mar 13, 2018

It's more about communicating with browsers, not becoming one.

http2 is an argument against being too eager to absorb protocols into core. Neither its API nor its implementation are all that great; it would have benefited from iterating outside core for a while.

I guess you could construe that as an argument in favor of websockets: third-party modules have existed for years and their APIs and implementations have pretty much crystallized by now.

bnoordhuis · Mar 13, 2018

http2 is an argument against being too eager to absorb protocols into core. Neither its API nor its implementation are all that great; it would have benefited from iterating outside core for a while.

I guess you could construe that as an argument in favor of websockets: third-party modules have existed for years and their APIs and implementations have pretty much crystallized by now.

This is a great idea. While today Node is already an indispensable tool for web developers it does not enjoy the same full seat at the table of web browser tech advancement despite being held completely captive by it. Few agree on the controversial edicts like Promise and esmodules but we can definitely all agree these transition moments could have been handled better with Node being an a fully active participant instead of recipient of these challenges.

Node has a big opportunity to become a full fledged user agent (web browser) and first class support for web features will be a part of that. +1!

brianleroux · Mar 13, 2018

This is a great idea. While today Node is already an indispensable tool for web developers it does not enjoy the same full seat at the table of web browser tech advancement despite being held completely captive by it. Few agree on the controversial edicts like Promise and esmodules but we can definitely all agree these transition moments could have been handled better with Node being an a fully active participant instead of recipient of these challenges.

Node has a big opportunity to become a full fledged user agent (web browser) and first class support for web features will be a part of that. +1!

http2 is an argument against being too eager to absorb protocols into core. Neither its API nor its implementation are all that great;

PRs welcome.

Re: websockets

I'm still -1 for the time being. This is something that has been done quite well by userland and there are still unanswered open standards questions about http2+ws that require more thought and experimentation.

jasnell · Mar 13, 2018

http2 is an argument against being too eager to absorb protocols into core. Neither its API nor its implementation are all that great;

PRs welcome.

Re: websockets

I'm still -1 for the time being. This is something that has been done quite well by userland and there are still unanswered open standards questions about http2+ws that require more thought and experimentation.

When http2 was added, I think one of the considerations were that we could do a lot of low level stuff in C++ land that was hard or even impossible(?) to do efficiently in user-land. Is there a similar reason for wanting to bring WS into core, or is it just to have more features?

watson · Mar 13, 2018

When http2 was added, I think one of the considerations were that we could do a lot of low level stuff in C++ land that was hard or even impossible(?) to do efficiently in user-land. Is there a similar reason for wanting to bring WS into core, or is it just to have more features?

@jasnell can you point me towards the open standards discussion regarding h2 + ws?

MylesBorins · Mar 13, 2018

@jasnell can you point me towards the open standards discussion regarding h2 + ws?

The ietf httpbis working group is working on this .... https://tools.ietf.org/html/draft-ietf-httpbis-h2-websockets-00

It's still super early in the process tho there is some early implementation happening.

jasnell · Mar 13, 2018

The ietf httpbis working group is working on this .... https://tools.ietf.org/html/draft-ietf-httpbis-h2-websockets-00

It's still super early in the process tho there is some early implementation happening.

Ideally there should be a clear general framework on how to decide whether something belongs to the core or not. I would consider points like

is it hard to be done right?
is it widely used?
does it have a clear spec?
is it likely to become obsolete in the near future?
does it need optimizations from the core?
will the entire community benefit from it being part of the core?

kof · Mar 13, 2018

Ideally there should be a clear general framework on how to decide whether something belongs to the core or not. I would consider points like

is it hard to be done right?
is it widely used?
does it have a clear spec?
is it likely to become obsolete in the near future?
does it need optimizations from the core?
will the entire community benefit from it being part of the core?

is it hard to be done right?

@kof I fully agree with all your points except this one – there is no reason to believe that code in Node core is better-written or better-maintained than userland code in general.

I think a better question in its place would be “Is it hard to do effeciently without native addons?”.

addaleax · Mar 13, 2018

is it hard to be done right?

@kof I fully agree with all your points except this one – there is no reason to believe that code in Node core is better-written or better-maintained than userland code in general.

I think a better question in its place would be “Is it hard to do effeciently without native addons?”.

@addaleax The idea behind that point is: if it is in userland, it is likely there will be multiple competing implementations, which will result in attention not being fully focused on a single code base and as a result lower quality, just because less people are working on it or using it. I have no data to back it up.

Userland is good when a feature needs experimentation.

kof · Mar 13, 2018

@addaleax The idea behind that point is: if it is in userland, it is likely there will be multiple competing implementations, which will result in attention not being fully focused on a single code base and as a result lower quality, just because less people are working on it or using it. I have no data to back it up.

Userland is good when a feature needs experimentation.

@kof

is it hard to be done right?

No.

is it widely used?

Yes it is.

does it have a clear spec?

Yes.

is it likely to become obsolete in the near future?

No.

does it need optimizations from the core?

Not necessarily but optimizations in core may help. In ws we have two optional binary addons. One for the masking/unmasking of frames (bufferutil) and one for the UTF-8 validation (utf-8-validate).

will the entire community benefit from it being part of the core?

Yes I think the community will benefit from WebSocket in core.

There are a lot of userland implementations. The most popular are ws, faye-websocket, and websocket. Combining the the best parts of each one of them to create a single module in core would be great imho.

lpinca · Mar 13, 2018

@kof

is it hard to be done right?

No.

is it widely used?

Yes it is.

does it have a clear spec?

Yes.

is it likely to become obsolete in the near future?

No.

does it need optimizations from the core?

Not necessarily but optimizations in core may help. In ws we have two optional binary addons. One for the masking/unmasking of frames (bufferutil) and one for the UTF-8 validation (utf-8-validate).

will the entire community benefit from it being part of the core?

Yes I think the community will benefit from WebSocket in core.

There are a lot of userland implementations. The most popular are ws, faye-websocket, and websocket. Combining the the best parts of each one of them to create a single module in core would be great imho.

+1, mainly because @lpinca has been doing a great job in maintaining ws the last few years.

mcollina · Mar 13, 2018

+1, mainly because @lpinca has been doing a great job in maintaining ws the last few years.

pinging @jcoglan and @theturtle32

MylesBorins · Mar 13, 2018

pinging @jcoglan and @theturtle32

So far I haven't seen any concrete comments on why implementing WS in core would be better than having it in user-land. I'm sure @lpinca have done a great job maintaining ws, but that hardly qualifies as a reason to bring it into core right?

I just think there need to be concrete examples on how core can provide a better WS implementation than user land 😃

watson · Mar 13, 2018

So far I haven't seen any concrete comments on why implementing WS in core would be better than having it in user-land. I'm sure @lpinca have done a great job maintaining ws, but that hardly qualifies as a reason to bring it into core right?

I just think there need to be concrete examples on how core can provide a better WS implementation than user land 😃

i don't think there's anyone saying we would do a better job. i think the argument is better integration and since we can ship it with a native backing users will get a perf boost without having to install anything.

devsnek · Mar 13, 2018

i don't think there's anyone saying we would do a better job. i think the argument is better integration and since we can ship it with a native backing users will get a perf boost without having to install anything.

@devsnek Could you provide an example of how the integration would be better if WS was in core?

Regarding native backing then n-api and pre-compiled binaries should remove the requirement of having users compile stuff (if I understood your argument correctly).

watson · Mar 13, 2018

@devsnek Could you provide an example of how the integration would be better if WS was in core?

Regarding native backing then n-api and pre-compiled binaries should remove the requirement of having users compile stuff (if I understood your argument correctly).

It seems the main argument for adding ws to Core is to reduce binary dependencies. Since both native dependencies are buffer-based, I think they may be good candidates for adoption of WebAssembly. @lpinca has that been seen as a possibility?

TimothyGu · Mar 14, 2018

It seems the main argument for adding ws to Core is to reduce binary dependencies. Since both native dependencies are buffer-based, I think they may be good candidates for adoption of WebAssembly. @lpinca has that been seen as a possibility?

For an API, I'd like to propose the WhatWG WebSocket API, as much as we can implement the standard (I know there will be some inconsistencies around events).

If we run into any serious problems with the API design we can attempt to work with the whatwg to update the standard. It seems like @TimothyGu has participated in this document along with @domenic.

re: http/2 + ws, if we get an implementation going we can participate in trying to solve this problem!

will the entire community benefit from it being part of the core?

I think implementing standards in core, especially ones implemented in the webplatform, can help the ecosystem focus on creating better abstractions on top of a protocol like WS, and avoid having to implement the base protocol themselves. If the various ecosystem modules share a kernel it allows there to be collaboration across projects with a shared interest, and potentially brings more people to help maintain core itself.

MylesBorins · Mar 14, 2018

For an API, I'd like to propose the WhatWG WebSocket API, as much as we can implement the standard (I know there will be some inconsistencies around events).

If we run into any serious problems with the API design we can attempt to work with the whatwg to update the standard. It seems like @TimothyGu has participated in this document along with @domenic.

re: http/2 + ws, if we get an implementation going we can participate in trying to solve this problem!

will the entire community benefit from it being part of the core?

I think implementing standards in core, especially ones implemented in the webplatform, can help the ecosystem focus on creating better abstractions on top of a protocol like WS, and avoid having to implement the base protocol themselves. If the various ecosystem modules share a kernel it allows there to be collaboration across projects with a shared interest, and potentially brings more people to help maintain core itself.

@watson userland implementations work and I'm a big supporter of small core but HTTP(s) and many other modules are in core because they are so popular that it made sense to create a core module for them. The same is valid for WebSocket in my opinion. Quoting @domenic from nodejs/NG#10 (comment)

I think the conclusion of this line of thought leads us to a process wherein we say "yes, core is interested in supporting feature X." Then, someone---maybe an io.js collaborator, or maybe not!---goes off and builds a prototype of feature X as a user-land module. Along the way, they might need to ask for more low-level APIs from core, and those will get rolled in. But over time, this external implementation of feature X matures, and io.js collaborators start commenting on it, and the ecosystem starts using it, until we decide: yes, we should roll this in to core, and start shipping with it.

Is core interested in supporting WebSocket? That's an open question. I think it should.

@TimothyGu we didn't explore that possibility but that's definitely a good idea. We already have prebuilt and n-api based binaries for native addons. Removing binary dependencies is not the reason why I would like to see WebSocket in core though. The question is, why is HTTP and HTTP2 in core and WebSocket isn't? They all are in the same league and they all can live in userland if wanted. On top of that a good part of the WebSocket implementation is already in core as the upgrade mechanism is already available and supported in core.

@MylesBorins If we ever decide to experiment with WebSocket in core, API need to be discussed. I think we want to support piping data around so a websocket should be implemented as a Duplex stream like faye-websocket does. I guess we also want to support fragmented messages and permessage-deflate. In this case we should augment the standard send() to add the ability to specify if a message is the last one in a fragmented message and to specify if a message should be compressed or not.

lpinca · Mar 14, 2018

@watson userland implementations work and I'm a big supporter of small core but HTTP(s) and many other modules are in core because they are so popular that it made sense to create a core module for them. The same is valid for WebSocket in my opinion. Quoting @domenic from nodejs/NG#10 (comment)

I think the conclusion of this line of thought leads us to a process wherein we say "yes, core is interested in supporting feature X." Then, someone---maybe an io.js collaborator, or maybe not!---goes off and builds a prototype of feature X as a user-land module. Along the way, they might need to ask for more low-level APIs from core, and those will get rolled in. But over time, this external implementation of feature X matures, and io.js collaborators start commenting on it, and the ecosystem starts using it, until we decide: yes, we should roll this in to core, and start shipping with it.

Is core interested in supporting WebSocket? That's an open question. I think it should.

@TimothyGu we didn't explore that possibility but that's definitely a good idea. We already have prebuilt and n-api based binaries for native addons. Removing binary dependencies is not the reason why I would like to see WebSocket in core though. The question is, why is HTTP and HTTP2 in core and WebSocket isn't? They all are in the same league and they all can live in userland if wanted. On top of that a good part of the WebSocket implementation is already in core as the upgrade mechanism is already available and supported in core.

@MylesBorins If we ever decide to experiment with WebSocket in core, API need to be discussed. I think we want to support piping data around so a websocket should be implemented as a Duplex stream like faye-websocket does. I guess we also want to support fragmented messages and permessage-deflate. In this case we should augment the standard send() to add the ability to specify if a message is the last one in a fragmented message and to specify if a message should be compressed or not.

I can't establish a vote for this, although would be a nice to have.

I found that WebSocket implementation isn't that solid neither in the Browser.

Is high cpu consuming and so far I couldn't see any implementation in a big scale (which I would have guess they would be using it); eg: Facebook, Twitter and Gmail, they rather relay on polling.

I guess is mainly related on the cost created on the Server side due being really hard to scale it (eg. Load balancing). Not sure Node wants to make his capacity in supporting it.

M3kH · Mar 14, 2018

I can't establish a vote for this, although would be a nice to have.

I found that WebSocket implementation isn't that solid neither in the Browser.

Is high cpu consuming and so far I couldn't see any implementation in a big scale (which I would have guess they would be using it); eg: Facebook, Twitter and Gmail, they rather relay on polling.

I guess is mainly related on the cost created on the Server side due being really hard to scale it (eg. Load balancing). Not sure Node wants to make his capacity in supporting it.

I would argue that it's actually easier to scale WebSocket than HTTP polling and it's way more CPU efficient. The protocol was designed to solve the HTTP polling problems, see https://tools.ietf.org/html/rfc6455#section-1.1. With WebSocket you have a persistent TCP connection, no HTTP headers overhead, seamlessly integration with the cluster module (no need for sticky sessions).

lpinca · Mar 14, 2018

I would argue that it's actually easier to scale WebSocket than HTTP polling and it's way more CPU efficient. The protocol was designed to solve the HTTP polling problems, see https://tools.ietf.org/html/rfc6455#section-1.1. With WebSocket you have a persistent TCP connection, no HTTP headers overhead, seamlessly integration with the cluster module (no need for sticky sessions).

@lpinca what happens on frequent reconnects if you don't have sticky sessions?

kof · Mar 14, 2018

@lpinca what happens on frequent reconnects if you don't have sticky sessions?

@kof with WebSocket it doesn't matter as long as the TCP connection is established, all messages are sent over the same connection so they all hit the same server. Sticky sessions are required for HTTP polling.

lpinca · Mar 14, 2018

@kof with WebSocket it doesn't matter as long as the TCP connection is established, all messages are sent over the same connection so they all hit the same server. Sticky sessions are required for HTTP polling.

@lpinca By frequent reconnects I ment reconnects on the TCP layer (when connection is dead for real)

kof · Mar 14, 2018

@lpinca By frequent reconnects I ment reconnects on the TCP layer (when connection is dead for real)

@kof not sure I understand. The websocket is closed along with the underlying TCP connection and a new one created.

lpinca · Mar 14, 2018

@kof not sure I understand. The websocket is closed along with the underlying TCP connection and a new one created.

Isn't it similar to long polling from performance perspective on bad physical connections at scale?

kof · Mar 14, 2018

Isn't it similar to long polling from performance perspective on bad physical connections at scale?

Yes, but ideally the majority of TCP connections are stable no? And even in the worst case scenario it's still better than long polling.

lpinca · Mar 14, 2018

Yes, but ideally the majority of TCP connections are stable no? And even in the worst case scenario it's still better than long polling.

Given the discussion I'm coming around on this, but what I'd like to see is a process similar to what we followed with N-API and http2... specifically, work on the new module being done and proven out in a separate fork repo before work being committed here in the main repo. Doing so allows greater flexibility in experimentation and implementation without disrupting anything else happening in core. It also allows implementation progress to be made in advance of a full commitment to "landing" it as a feature.

jasnell · Mar 14, 2018

Given the discussion I'm coming around on this, but what I'd like to see is a process similar to what we followed with N-API and http2... specifically, work on the new module being done and proven out in a separate fork repo before work being committed here in the main repo. Doing so allows greater flexibility in experimentation and implementation without disrupting anything else happening in core. It also allows implementation progress to be made in advance of a full commitment to "landing" it as a feature.

I'm mostly indifferent to whether WebSockets should be in core at this point, but I lean toward the opinion that it should not. I don't feel it's anywhere near as widely used or fundamental as HTTP is, and it would end up just being more for the core team to have to maintain. That being said, my WebSocket implementation hasn't required much maintenance since becoming stable.

Honestly, I kinda feel like it doesn't really need to move into core. As it stands, the community benefits from multiple competing stable implementations, without there being so many that it's difficult to pick one. Each implementation has its own particular API that fits better for different coding styles or use cases. If Websocket was implemented in core, it would instantly become the One True Implementation and the One True API, and I'm not sure that's especially beneficial. Alternatively, it may try to be all things to all people by supporting multiple kinds of APIs, and that would create more surface area to maintain as well as more planning and design work up front. It may end up being less good than what we already have now, at least until enough work has been put into it to evolve it to something stable. And all that work would essentially be just re-inventing the wheel.

Core optimizations to support Websocket implementations might be nice. Or a new optimized C++ implementation that does a majority of its processing work off the main thread might be interesting (Websocket perfectly lends itself to an entirely async API anyway), but I'm not sure even that kind of project would need to live in core.

theturtle32 · Mar 14, 2018

I'm mostly indifferent to whether WebSockets should be in core at this point, but I lean toward the opinion that it should not. I don't feel it's anywhere near as widely used or fundamental as HTTP is, and it would end up just being more for the core team to have to maintain. That being said, my WebSocket implementation hasn't required much maintenance since becoming stable.

Honestly, I kinda feel like it doesn't really need to move into core. As it stands, the community benefits from multiple competing stable implementations, without there being so many that it's difficult to pick one. Each implementation has its own particular API that fits better for different coding styles or use cases. If Websocket was implemented in core, it would instantly become the One True Implementation and the One True API, and I'm not sure that's especially beneficial. Alternatively, it may try to be all things to all people by supporting multiple kinds of APIs, and that would create more surface area to maintain as well as more planning and design work up front. It may end up being less good than what we already have now, at least until enough work has been put into it to evolve it to something stable. And all that work would essentially be just re-inventing the wheel.

Core optimizations to support Websocket implementations might be nice. Or a new optimized C++ implementation that does a majority of its processing work off the main thread might be interesting (Websocket perfectly lends itself to an entirely async API anyway), but I'm not sure even that kind of project would need to live in core.

Speaking of turbo-net, there's already a turbo-ws built on top of that: https://github.com/hugmanrique/turbo-ws

watson · Mar 15, 2018

Speaking of turbo-net, there's already a turbo-ws built on top of that: https://github.com/hugmanrique/turbo-ws

@lpinca Hi 👋 any difference between using socket.io and websockt natively? I am new regarding the protocols, what difference will there be if websocket is integrated to the core of nodejs?

Thank you for taking the time to read my question 😸

MAPESO · Mar 15, 2018

@lpinca Hi 👋 any difference between using socket.io and websockt natively? I am new regarding the protocols, what difference will there be if websocket is integrated to the core of nodejs?

Thank you for taking the time to read my question 😸

@MAPESO thats a bit off topic for this. socket.io is a wrapper around a bunch of different hacks and connections (including websockets) to make sending messages between server and client possible extending back to really old browsers. beyond that it also abstracts the connections into "channels" and such. in the topic of this conversation socket.io and websockets are not at all equivalent (and as long as we're on the topic of perf, its worth noting that socket.io is pretty slow)

devsnek · Mar 15, 2018

@MAPESO thats a bit off topic for this. socket.io is a wrapper around a bunch of different hacks and connections (including websockets) to make sending messages between server and client possible extending back to really old browsers. beyond that it also abstracts the connections into "channels" and such. in the topic of this conversation socket.io and websockets are not at all equivalent (and as long as we're on the topic of perf, its worth noting that socket.io is pretty slow)

@devsnek I know, my question was off topic, but as I do not have much experience in protocols😄

MAPESO · Mar 15, 2018

@devsnek I know, my question was off topic, but as I do not have much experience in protocols😄

Thanks for the write-ups @3rd-Eden and @jcoglan. I wrote browserchannel in the node 0.4 days because there were no better options. At the time websockets didn't support cookies and would often break in unexpected ways with new browser releases. Socket.io had an incoherent story around reconnection, and could arbitrarily reorder messages on reconnect. The sharejs issue tracker had more bug reports due to socket.io's bugs than due to any of my own code. I rewrote sharejs on top of faye at one point - I can't remember why I stopped using faye, but the way faye extensions work left a lasting impression on me. Its a beautiful API, and I'm still a little bit in love with it. I used that model for the sharedb extension API.

There's an interesting set of engineering philosophy around how reconnection works that is rarely discussed - if a client disconnects and reconnects, should you think of this as a new connection (and have the client and server reestablish state), or should you migrate state from the old connection? Browserchannel does the former, and socket.io the latter. I believe reestablishing state in the application is the correct choice - in practice migrating state from the old connectionn is way more complicated than you would expect. (How do you handle multiple active tabs? Do you need server affinity? A session database? Do subscriptions need object references? , etc). But of course, if you need your own reconnection logic then its harder to use someone else's magic auto-reconnection code. Socket connections are stateful. They're useful because they aren't request-response, and pub-sub does not cover all the use cases of a socket connection either.

Personally these days I use (and recommend) pure websockets for all my projects. This seems obvious but is probably worth saying anyway: If websockets enter core, the API of ws is about the level of abstraction I think we should aim for.

Most of the points I'd like to make have been made well above, so I'm going to expand and reiterate some points from above I agree with:

I agree with @jcoglan that the streams2 API is still incoherent and confusing. I'm sad that nobody cleaned it up. To this day I still run into random issues with message framing because nobody really knows how to use streams correctly. It is very difficult to build an accurate mental model of how they work. Eg, what is the relationship between the close, finish and end events? Are _read and _write re-entrant (that is, can multiple invocations be running concurrently?) Even with reference to the documentation these questions are crazy hard to answer, which is an unfortunate mess. If it were up to me I would ask dominictarr and substack to put a replacement streaming library in core. But thats a separate rant.
We don't have a framework for deciding what should be in core and what shouldn't. It seems like some people think almost nothing should be in core and will vote down any attempt to add to the surface area of core. I respect this. And also ws is widely used, stable, well understood and a centralised implementation would benefit people. Going by @kof 's criteria above, ws is:
- is it hard to be done right?
- is it widely used?
- does it have a clear spec?
- is it unlikely to become obsolete in the near future?
- does it need optimizations from the core? (partially - it could definitely benefit from binary implementations)
- will the entire community benefit from it being part of the core? (no - websockets are used widely but still only in a minority of projects)
I don't find the argument that because we have a partial websocket implementation for the inspector we should expose it particularly compelling. If the inspector needed to generate SVG files, would we add that to core too? If we're going to expose APIs for everything in core, there's a lot more stuff we could talk about exposing. (Like the http parser.)

Is there still a node technical committee with teeth? I'd like to defer the question of "on what basis do we add stuff to core" to the TC, because thats a question that affects more than websockets. If we decide nodejs should become a monolith of good and useful code, we should add ws. If we decide node should be minimal and defer to curated lists of good npm packages, there's lots of good ws libraries to recommend.

Personally I think there's a middle-ground that I'd like even better: Have an official list of recommended solid, default modules for specific tasks in nodejs. These could be decided on however we like. The official documentation should list these modules. The list wouldn't be fixed - if the community decides that ioredis is better than redis, the recommendation should change. Its the best of both worlds - we have a large, blessed, official standard on lots of stuff. And also the standard can evolve and change as fast or as slowly as we like without breaking any existing code. (Release notes for node version 20.0.0: The official recommendation for streams is now X. It has these benefits (link), see (discussion) and (migration guide)). Then maybe npm init --extended automatically adds stuff like the recommended version of streams and http2 to your package.json. And then lots of things that are in core can be migrated out, and we get a nice tight minimal core surface area, as many delicious features as we want and users have full control over when (if ever) they upgrade those modules. The recommendations for specific tasks would change less frequently over time, at the discretion of the community. But thats probably a separate discussion.

josephg · Mar 15, 2018

Thanks for the write-ups @3rd-Eden and @jcoglan. I wrote browserchannel in the node 0.4 days because there were no better options. At the time websockets didn't support cookies and would often break in unexpected ways with new browser releases. Socket.io had an incoherent story around reconnection, and could arbitrarily reorder messages on reconnect. The sharejs issue tracker had more bug reports due to socket.io's bugs than due to any of my own code. I rewrote sharejs on top of faye at one point - I can't remember why I stopped using faye, but the way faye extensions work left a lasting impression on me. Its a beautiful API, and I'm still a little bit in love with it. I used that model for the sharedb extension API.

There's an interesting set of engineering philosophy around how reconnection works that is rarely discussed - if a client disconnects and reconnects, should you think of this as a new connection (and have the client and server reestablish state), or should you migrate state from the old connection? Browserchannel does the former, and socket.io the latter. I believe reestablishing state in the application is the correct choice - in practice migrating state from the old connectionn is way more complicated than you would expect. (How do you handle multiple active tabs? Do you need server affinity? A session database? Do subscriptions need object references? , etc). But of course, if you need your own reconnection logic then its harder to use someone else's magic auto-reconnection code. Socket connections are stateful. They're useful because they aren't request-response, and pub-sub does not cover all the use cases of a socket connection either.

Personally these days I use (and recommend) pure websockets for all my projects. This seems obvious but is probably worth saying anyway: If websockets enter core, the API of ws is about the level of abstraction I think we should aim for.

Most of the points I'd like to make have been made well above, so I'm going to expand and reiterate some points from above I agree with:

I agree with @jcoglan that the streams2 API is still incoherent and confusing. I'm sad that nobody cleaned it up. To this day I still run into random issues with message framing because nobody really knows how to use streams correctly. It is very difficult to build an accurate mental model of how they work. Eg, what is the relationship between the close, finish and end events? Are _read and _write re-entrant (that is, can multiple invocations be running concurrently?) Even with reference to the documentation these questions are crazy hard to answer, which is an unfortunate mess. If it were up to me I would ask dominictarr and substack to put a replacement streaming library in core. But thats a separate rant.
We don't have a framework for deciding what should be in core and what shouldn't. It seems like some people think almost nothing should be in core and will vote down any attempt to add to the surface area of core. I respect this. And also ws is widely used, stable, well understood and a centralised implementation would benefit people. Going by @kof 's criteria above, ws is:
- is it hard to be done right?
- is it widely used?
- does it have a clear spec?
- is it unlikely to become obsolete in the near future?
- does it need optimizations from the core? (partially - it could definitely benefit from binary implementations)
- will the entire community benefit from it being part of the core? (no - websockets are used widely but still only in a minority of projects)
I don't find the argument that because we have a partial websocket implementation for the inspector we should expose it particularly compelling. If the inspector needed to generate SVG files, would we add that to core too? If we're going to expose APIs for everything in core, there's a lot more stuff we could talk about exposing. (Like the http parser.)

Is there still a node technical committee with teeth? I'd like to defer the question of "on what basis do we add stuff to core" to the TC, because thats a question that affects more than websockets. If we decide nodejs should become a monolith of good and useful code, we should add ws. If we decide node should be minimal and defer to curated lists of good npm packages, there's lots of good ws libraries to recommend.

Personally I think there's a middle-ground that I'd like even better: Have an official list of recommended solid, default modules for specific tasks in nodejs. These could be decided on however we like. The official documentation should list these modules. The list wouldn't be fixed - if the community decides that ioredis is better than redis, the recommendation should change. Its the best of both worlds - we have a large, blessed, official standard on lots of stuff. And also the standard can evolve and change as fast or as slowly as we like without breaking any existing code. (Release notes for node version 20.0.0: The official recommendation for streams is now X. It has these benefits (link), see (discussion) and (migration guide)). Then maybe npm init --extended automatically adds stuff like the recommended version of streams and http2 to your package.json. And then lots of things that are in core can be migrated out, and we get a nice tight minimal core surface area, as many delicious features as we want and users have full control over when (if ever) they upgrade those modules. The recommendations for specific tasks would change less frequently over time, at the discretion of the community. But thats probably a separate discussion.

I don't think node should aim to become a (DOM-less) browser.

I think this is worth exploring a little bit, because it's sort of counter to the original vision of Node.js.

When Node.js was released in 2009 there was a broader movement to make new platform tools that were "of the Web" rather than the Web being an afterthought. Platforms like Perl, Python and Ruby were released initially without an HTTP API and the stdlib modules added later to fascilitate it felt a bit second class and there were often multiple HTTP abstractions in stdlib (Python had 2 or 3 at the time).

What set Node.js apart, other than being in JavaScript, was that HTTP was a first class citizen. In fact, early releases of Node.js included HTTP and did not include UDP, there was even some question at the time as to whether it should add it.

Node.js adopting new core protocols of the Web is perfectly in-line with its original vision and only a dogmatic originalism could argue otherwise. There may be perfectly good technical reasons not to include Web Sockets but the argument that it is somehow out of scope doesn't match the history or vision the project has had since day one.

http2

One thing I'm surprised I didn't see pointed out already was that when http2 was implemented by @jasnell he created an API and an implementation that specifically took advantage of being in core that out-perform anything possible in userland. Why can't the same be done for WebSockets?

mikeal · Mar 16, 2018

I don't think node should aim to become a (DOM-less) browser.

I think this is worth exploring a little bit, because it's sort of counter to the original vision of Node.js.

When Node.js was released in 2009 there was a broader movement to make new platform tools that were "of the Web" rather than the Web being an afterthought. Platforms like Perl, Python and Ruby were released initially without an HTTP API and the stdlib modules added later to fascilitate it felt a bit second class and there were often multiple HTTP abstractions in stdlib (Python had 2 or 3 at the time).

What set Node.js apart, other than being in JavaScript, was that HTTP was a first class citizen. In fact, early releases of Node.js included HTTP and did not include UDP, there was even some question at the time as to whether it should add it.

Node.js adopting new core protocols of the Web is perfectly in-line with its original vision and only a dogmatic originalism could argue otherwise. There may be perfectly good technical reasons not to include Web Sockets but the argument that it is somehow out of scope doesn't match the history or vision the project has had since day one.

http2

One thing I'm surprised I didn't see pointed out already was that when http2 was implemented by @jasnell he created an API and an implementation that specifically took advantage of being in core that out-perform anything possible in userland. Why can't the same be done for WebSockets?

@mikeal good argument, well made. I’m convinced; I think we should add it.

I’m curious though - what did @jasnell take advantage of in core that couldn’t be done easily in an external module?

josephg · Mar 16, 2018

@mikeal good argument, well made. I’m convinced; I think we should add it.

I’m curious though - what did @jasnell take advantage of in core that couldn’t be done easily in an external module?

@josephg if I recall a lot of what the HTTP/2 implementation that is unique is how we maintain data in C++ land and minimize how much it needs to be brokered between C++ -> js... if I recall this level of optimization would not really be possible in a native module as things are being handed around between node + nghttp2 + v8 + libuv

MylesBorins · Mar 16, 2018

@josephg if I recall a lot of what the HTTP/2 implementation that is unique is how we maintain data in C++ land and minimize how much it needs to be brokered between C++ -> js... if I recall this level of optimization would not really be possible in a native module as things are being handed around between node + nghttp2 + v8 + libuv

That's not true. Core has more supporting infrastructure for new code to piggyback on but there is little that you can't also do from a native module. n-api was a module before it moved into core, http2 could have been too...

...and arguably it should have been because of the much shorter feedback cycle. n-api fixed design flags within days, http2's feedback cycle is closer to 6 or 12 months.

bnoordhuis · Mar 16, 2018

That's not true. Core has more supporting infrastructure for new code to piggyback on but there is little that you can't also do from a native module. n-api was a module before it moved into core, http2 could have been too...

...and arguably it should have been because of the much shorter feedback cycle. n-api fixed design flags within days, http2's feedback cycle is closer to 6 or 12 months.

@bnoordhuis what you are saying is incorrect regarding n-api and http2. They followed the exact same path before landing in core with the majority of the work being done in a separate fork of Node.js (https://github.com/nodejs/abi-stable-node/tree/api-prototype-8.x and https://github.com/nodejs/http2) where a team iterated over the implementation.

I would also kindly ask to stop pointing out that the http2 has severe design flows without writing what they are. Open up an issue or a PR to discuss, and keep this issue relevant to WebSocket.

mcollina · Mar 16, 2018

@bnoordhuis what you are saying is incorrect regarding n-api and http2. They followed the exact same path before landing in core with the majority of the work being done in a separate fork of Node.js (https://github.com/nodejs/abi-stable-node/tree/api-prototype-8.x and https://github.com/nodejs/http2) where a team iterated over the implementation.

I would also kindly ask to stop pointing out that the http2 has severe design flows without writing what they are. Open up an issue or a PR to discuss, and keep this issue relevant to WebSocket.

@mcollina The salient point is that n-api was available as a npm module before it got built into core and that was what allowed it to collect feedback and move at a high pace.

To drive home the point why that is relevant to websockets: they shouldn't be added to core until it has evolved a stable API. I think that is effectively the case but I use http2 as an example where that didn't happen - and it's stupid of us because it's not as if it's the first time we made that mistake.

Clear now?

bnoordhuis · Mar 16, 2018

@mcollina The salient point is that n-api was available as a npm module before it got built into core and that was what allowed it to collect feedback and move at a high pace.

To drive home the point why that is relevant to websockets: they shouldn't be added to core until it has evolved a stable API. I think that is effectively the case but I use http2 as an example where that didn't happen - and it's stupid of us because it's not as if it's the first time we made that mistake.

Clear now?

@mcollina The salient point is that n-api was available as a npm module before it got built into core and that was what allowed it to collect feedback and move at a high pace.

I couldn't find a reference to that module in most of our respositories, can you please add a link?

mcollina · Mar 16, 2018

@mcollina The salient point is that n-api was available as a npm module before it got built into core and that was what allowed it to collect feedback and move at a high pace.

I couldn't find a reference to that module in most of our respositories, can you please add a link?

To drive home the point why that is relevant to websockets: they shouldn't be added to core until it has evolved a stable API. I think that is effectively the case but I use http2 as an example where that didn't happen - and it's stupid of us because it's not as if it's the first time we made that mistake.

This can be said to streams, async_hooks, trace_events and a lot of the new things that landed in core. Some of them are flagged as experimental for a reason.

If we want to have a WebSocket implementation in core, a team is spawn up and a fork nodejs/websocket is created. Then the team iterates on their implementation there, and then do a "big" PR with the new feature. This is the approach that we have followed for both n-api and http2. I agree that it enables a fast iteration on the API design.

mcollina · Mar 16, 2018

To drive home the point why that is relevant to websockets: they shouldn't be added to core until it has evolved a stable API. I think that is effectively the case but I use http2 as an example where that didn't happen - and it's stupid of us because it's not as if it's the first time we made that mistake.

This can be said to streams, async_hooks, trace_events and a lot of the new things that landed in core. Some of them are flagged as experimental for a reason.

If we want to have a WebSocket implementation in core, a team is spawn up and a fork nodejs/websocket is created. Then the team iterates on their implementation there, and then do a "big" PR with the new feature. This is the approach that we have followed for both n-api and http2. I agree that it enables a fast iteration on the API design.

I couldn't find a reference to that module in most of our respositories, can you please add a link?

Getting mildly off-topic but okay, for posterity: https://www.npmjs.com/package/node-addon-api - released some months before the first node.js release that bundled n-api.

This can be said to streams, async_hooks, trace_events and a lot of the new things that landed in core. Some of them are flagged as experimental for a reason.

True, but async_hooks and trace_events can't be done as modules, and streams... yeah, what can you say about streams?

bnoordhuis · Mar 16, 2018

I couldn't find a reference to that module in most of our respositories, can you please add a link?

Getting mildly off-topic but okay, for posterity: https://www.npmjs.com/package/node-addon-api - released some months before the first node.js release that bundled n-api.

This can be said to streams, async_hooks, trace_events and a lot of the new things that landed in core. Some of them are flagged as experimental for a reason.

True, but async_hooks and trace_events can't be done as modules, and streams... yeah, what can you say about streams?

Getting mildly off-topic but okay, for posterity: https://www.npmjs.com/package/node-addon-api - released some months before the first node.js release that bundled n-api.

~~node-addon-api never bundled n-api, it's just a C++ wrapper on top of C API of n-api. n-api itself never made to npm, and even node-addon-api was released after n-api was already landed in core.~~. You are right on this point.

Still, n-api itself landed in core 1 month before the first release of the module itself. n-api was not iterated in the ecosystem (it didn't have a significant adoption), it has always been a node core component.

what can you say about streams?

Considering how many developers are complaining in this thread, we should have iterated a bit more on them.

mcollina · Mar 16, 2018

Getting mildly off-topic but okay, for posterity: https://www.npmjs.com/package/node-addon-api - released some months before the first node.js release that bundled n-api.

~~node-addon-api never bundled n-api, it's just a C++ wrapper on top of C API of n-api. n-api itself never made to npm, and even node-addon-api was released after n-api was already landed in core.~~. You are right on this point.

Still, n-api itself landed in core 1 month before the first release of the module itself. n-api was not iterated in the ecosystem (it didn't have a significant adoption), it has always been a node core component.

what can you say about streams?

Considering how many developers are complaining in this thread, we should have iterated a bit more on them.

node-addon-api was released after n-api was already landed in core

The terminology with n-api is kinda confusing so to be clear, it was added to core in #11975 and that wasn't released until end of May. The first node-addon-api release was months before (edit: but now that I think of it, it probably depended on nodejs/node-api in some way.)

(enough derailing though)

bnoordhuis · Mar 16, 2018

node-addon-api was released after n-api was already landed in core

The terminology with n-api is kinda confusing so to be clear, it was added to core in #11975 and that wasn't released until end of May. The first node-addon-api release was months before (edit: but now that I think of it, it probably depended on nodejs/node-api in some way.)

(enough derailing though)

what did @jasnell take advantage of in core that couldn’t be done easily in an external module?

Depends on what you mean by external module :-) As with just about every core module, it could have been implemented entirely as a native module. The majority of the heavy lifting in the http2 code is handled entirely at the native level with (as @MylesBorins points out) data flow being coordinated between nodejs, libuv, and nghttp2. The JS layer really only deals with the Streams API and public facing API.

More on the point for this particular thread... the initial implementation work on a possible WebSockets module for Node.js should move forward in a separate repository -- exactly as happened with other major initiatives like http/2, n-api, and now worker support. Once that work progresses beyond the rough ideas and into the coherent implementation phase, bring it back into the main repo. Thus far this has been a very successful pattern.

This repo can be created here within the nodejs github organization. I'm happy to go create it now along with the github team that will have commit access to it. Or, as was the case with the early http2 work, that can be done in someone's personal github account. It really does not matter. Let's just stop debating irrelevant side channel things and get focused on exploring this.

Just keep in mind that exploring it doesn't mean that it automatically makes it in to core. A decision will need to be made based on the specific merits of the implementation. I think there's sufficient community interest, however, to say that this is definitely something we should be looking at.

jasnell · Mar 16, 2018

what did @jasnell take advantage of in core that couldn’t be done easily in an external module?

Depends on what you mean by external module :-) As with just about every core module, it could have been implemented entirely as a native module. The majority of the heavy lifting in the http2 code is handled entirely at the native level with (as @MylesBorins points out) data flow being coordinated between nodejs, libuv, and nghttp2. The JS layer really only deals with the Streams API and public facing API.

More on the point for this particular thread... the initial implementation work on a possible WebSockets module for Node.js should move forward in a separate repository -- exactly as happened with other major initiatives like http/2, n-api, and now worker support. Once that work progresses beyond the rough ideas and into the coherent implementation phase, bring it back into the main repo. Thus far this has been a very successful pattern.

This repo can be created here within the nodejs github organization. I'm happy to go create it now along with the github team that will have commit access to it. Or, as was the case with the early http2 work, that can be done in someone's personal github account. It really does not matter. Let's just stop debating irrelevant side channel things and get focused on exploring this.

Just keep in mind that exploring it doesn't mean that it automatically makes it in to core. A decision will need to be made based on the specific merits of the implementation. I think there's sufficient community interest, however, to say that this is definitely something we should be looking at.

@mikeal wrote:

One thing I'm surprised I didn't see pointed out already was that when http2 was implemented by @jasnell he created an API and an implementation that specifically took advantage of being in core that out-perform anything possible in userland. Why can't the same be done for WebSockets?

Earlier in this thread, I did bring up the http2 module as an example of something that to my knowledge couldn't have been done as performant outside of core. I asked if the same was true for WS. I didn't see any answer to this, which leads me to believe that this isn't the case (sorry if I missed it).

watson · Mar 16, 2018

@mikeal wrote:

One thing I'm surprised I didn't see pointed out already was that when http2 was implemented by @jasnell he created an API and an implementation that specifically took advantage of being in core that out-perform anything possible in userland. Why can't the same be done for WebSockets?

Earlier in this thread, I did bring up the http2 module as an example of something that to my knowledge couldn't have been done as performant outside of core. I asked if the same was true for WS. I didn't see any answer to this, which leads me to believe that this isn't the case (sorry if I missed it).

Thus far this has been a very successful pattern.

"Successful" is subjective. It worked out okay for n-api (the C API) because we kept making breaking changes until long after the initial release. We could because there were few users.

That won't fly for a JS module. People start writing new code for those right from the start and that limits what we can change without upheaval.

A safe approach is to start out as a module under github.com/nodejs with a roadmap for migrating into core. That gives users time to try it out and provide feedback, while setting the right expectations.

And when I say 'users' I mean real users. With http2 and n-api virtually no one but the people working on it used it or even knew it was in the works until it was released.

edit: for WS there's one good argument for working in core from the get go: tight cluster integration.

bnoordhuis · Mar 16, 2018

Thus far this has been a very successful pattern.

"Successful" is subjective. It worked out okay for n-api (the C API) because we kept making breaking changes until long after the initial release. We could because there were few users.

That won't fly for a JS module. People start writing new code for those right from the start and that limits what we can change without upheaval.

A safe approach is to start out as a module under github.com/nodejs with a roadmap for migrating into core. That gives users time to try it out and provide feedback, while setting the right expectations.

And when I say 'users' I mean real users. With http2 and n-api virtually no one but the people working on it used it or even knew it was in the works until it was released.

edit: for WS there's one good argument for working in core from the get go: tight cluster integration.

And when I say 'users' I mean real users. With http2 and n-api virtually no one but the people working on it used it or even knew it was in the works until it was released.

This is entirely incorrect.

Even so, we seem to be in agreement that starting work within a separate repo is the right approach.

@MylesBorins ... I can create the repo under the nodejs github repo if you'd like, or I can leave it to you. The folks who are most interested in moving this forward can decide on the best work mode for them -- including whether that repo is a fork off core master or implemented as a separate module at first. Once some concrete progress is made there, let's revisit the question about whether it should land in core. I have created the @nodejs/websockets team and added you (@MylesBorins) as a maintainer.

jasnell · Mar 16, 2018

And when I say 'users' I mean real users. With http2 and n-api virtually no one but the people working on it used it or even knew it was in the works until it was released.

This is entirely incorrect.

Even so, we seem to be in agreement that starting work within a separate repo is the right approach.

@MylesBorins ... I can create the repo under the nodejs github repo if you'd like, or I can leave it to you. The folks who are most interested in moving this forward can decide on the best work mode for them -- including whether that repo is a fork off core master or implemented as a separate module at first. Once some concrete progress is made there, let's revisit the question about whether it should land in core. I have created the @nodejs/websockets team and added you (@MylesBorins) as a maintainer.

Strong riposte, James. I suspect you get defensive because I brought up http2 but I'm merely using that as an example of where we (note the 'we') could have done better. Let's learn from our mistakes.

bnoordhuis · Mar 16, 2018

Strong riposte, James. I suspect you get defensive because I brought up http2 but I'm merely using that as an example of where we (note the 'we') could have done better. Let's learn from our mistakes.

Core has more supporting infrastructure for new code to piggyback on but there is little that you can't also do from a native module.

One thing I would like to point out about native modules is that they have a significantly worse user experience for end-users. Users have to provide a compilation environment in their deployment environments; or trust a binary blob – which typically is not available for all platforms. Even if a module could be built to be just as efficient as a native module, it still wouldn't have the same first class user experience.

If it is deemed that protocols like http2 and WebSockets are central to The Web, then we should not relegate them to a less than ideal user experience.

ofrobots · Mar 16, 2018

Core has more supporting infrastructure for new code to piggyback on but there is little that you can't also do from a native module.

One thing I would like to point out about native modules is that they have a significantly worse user experience for end-users. Users have to provide a compilation environment in their deployment environments; or trust a binary blob – which typically is not available for all platforms. Even if a module could be built to be just as efficient as a native module, it still wouldn't have the same first class user experience.

If it is deemed that protocols like http2 and WebSockets are central to The Web, then we should not relegate them to a less than ideal user experience.

@watson I don't know, I think a pure JS implementation that resorts to low level stuff for computational intensive operations will not be much better than a userland implementation that does the same thing. My main reason for having WebSocket in core is not performance which is always good to have but to improve ecosystem interoperability.

lpinca · Mar 16, 2018

@watson I don't know, I think a pure JS implementation that resorts to low level stuff for computational intensive operations will not be much better than a userland implementation that does the same thing. My main reason for having WebSocket in core is not performance which is always good to have but to improve ecosystem interoperability.

One thing I would like to point out about native modules is that they have a significantly worse user experience for end-users.

I agree. I advocate them as a stepping stone to built-in support, not as the eternal status quo.

That said... stuff like websockets and http2 would make interesting webassembly case studies.

bnoordhuis · Mar 16, 2018

One thing I would like to point out about native modules is that they have a significantly worse user experience for end-users.

I agree. I advocate them as a stepping stone to built-in support, not as the eternal status quo.

That said... stuff like websockets and http2 would make interesting webassembly case studies.

My opinion is that WebSocket should be in core. Node.js was designed and has thrived as a platform for writing network services.

If I were learning Node.js today, I'd expect that network protocols that are widely deployed, have formalized specifications and fit the purpose of the platform would be supported out of the box.

I've expressed similar sentiments over the last couple years with regards HTTP/2[1], so I'm thankful @jasnell and others have done such an amazing work there.

I think a websocket server and client can be specially beneficial if:

we can get demonstrably higher performance than userland implementations that don't build native addons
we can expose primitives that could aid userland modules, like a reusable parser! Userland would get even better, fostering experimentation, like transporting the websocket protocol over non-HTTP channels

All in all, I'm very positive on this. The first version of socket.io had to be distributed with a .patch file to hack Node.js core to make WebSocket (Upgrade in general) work properly. Node.js is a great platform for experimenting and prototyping new ideas like that, and having solid building blocks in place from the start is a huge win.

[1] Specially after wrangling with the numerous bugs in userland implementations. These protocols are hard to get right!

rauchg · Mar 17, 2018

My opinion is that WebSocket should be in core. Node.js was designed and has thrived as a platform for writing network services.

If I were learning Node.js today, I'd expect that network protocols that are widely deployed, have formalized specifications and fit the purpose of the platform would be supported out of the box.

I've expressed similar sentiments over the last couple years with regards HTTP/2[1], so I'm thankful @jasnell and others have done such an amazing work there.

I think a websocket server and client can be specially beneficial if:

we can get demonstrably higher performance than userland implementations that don't build native addons
we can expose primitives that could aid userland modules, like a reusable parser! Userland would get even better, fostering experimentation, like transporting the websocket protocol over non-HTTP channels

All in all, I'm very positive on this. The first version of socket.io had to be distributed with a .patch file to hack Node.js core to make WebSocket (Upgrade in general) work properly. Node.js is a great platform for experimenting and prototyping new ideas like that, and having solid building blocks in place from the start is a huge win.

[1] Specially after wrangling with the numerous bugs in userland implementations. These protocols are hard to get right!

Given the wide adoption of the client spec in the last two versions of nearly every major browser necessitates the adoption of a per-spec implementation in core. The performance benefits alone will make us rich beyond the dreams of avarice. But please for the love of all that is holy, stick to the spec and avoid anything, literally anything that diverges from the spec.

shellscape · Mar 17, 2018

Given the wide adoption of the client spec in the last two versions of nearly every major browser necessitates the adoption of a per-spec implementation in core. The performance benefits alone will make us rich beyond the dreams of avarice. But please for the love of all that is holy, stick to the spec and avoid anything, literally anything that diverges from the spec.

My opinion is that WebSocket should be in core as well, and that uws has been a game changer for many developers because it brought high performance: think about serving hundreds of thousands simultaneous clients with node+uws on a single cheap server.
I would add on top of what @mikeal said, that my vision of Node.js is that it will die and be replaced by browsers in a foreseeable future. It's not browser without DOM it's cutting-edge browser with optional optimizations for servers.

kapouer · Mar 17, 2018

My opinion is that WebSocket should be in core as well, and that uws has been a game changer for many developers because it brought high performance: think about serving hundreds of thousands simultaneous clients with node+uws on a single cheap server.
I would add on top of what @mikeal said, that my vision of Node.js is that it will die and be replaced by browsers in a foreseeable future. It's not browser without DOM it's cutting-edge browser with optional optimizations for servers.

Agree with @rauchg - WS usage is definitely on the rise which imo coincides with the push to not pull shift in delivery ( WS & Socket.io alone are pulled 20 million times a month ) & as @shellscape mentioned, the browser adoption is wide.

An on spec native implementation can only help further adoption & performance while giving user land a single way of implementing WS easily. All of these things would be extremely beneficial to NodeJS consumers particularly since as @3rd-Eden said, we really can't push the performance much further without WS becoming part of Node.

As @eugeneo & @3rd-Eden already pointed out, Node technically already as a degree of WS support, this could be expanded upon to bring this feature home.

d3viant0ne · Mar 17, 2018

Agree with @rauchg - WS usage is definitely on the rise which imo coincides with the push to not pull shift in delivery ( WS & Socket.io alone are pulled 20 million times a month ) & as @shellscape mentioned, the browser adoption is wide.

An on spec native implementation can only help further adoption & performance while giving user land a single way of implementing WS easily. All of these things would be extremely beneficial to NodeJS consumers particularly since as @3rd-Eden said, we really can't push the performance much further without WS becoming part of Node.

As @eugeneo & @3rd-Eden already pointed out, Node technically already as a degree of WS support, this could be expanded upon to bring this feature home.

I can't believe how much people are against Web Socket implementation in node, and even not happy about http2?
What the hell guys? Node was supposed to be cutting edge, now years after first WS implementations, Node still don't have it, and please don't tell me to use any of the ready made ws socket frameworks. I hate them. I used ws module way back and I was happy with it.
What about http2? This was long awaited upgrade, something that helps PWA become first citizen on mobile.
I don't get it, every one of those spec is finalized, really a straight forward implementation in the lower level of the node code on C++.

talamaska · Mar 18, 2018

I can't believe how much people are against Web Socket implementation in node, and even not happy about http2?
What the hell guys? Node was supposed to be cutting edge, now years after first WS implementations, Node still don't have it, and please don't tell me to use any of the ready made ws socket frameworks. I hate them. I used ws module way back and I was happy with it.
What about http2? This was long awaited upgrade, something that helps PWA become first citizen on mobile.
I don't get it, every one of those spec is finalized, really a straight forward implementation in the lower level of the node code on C++.

@talamaska What makes you think you'll like the built-in websockets module better?

Note that I'm personally (mildly) in favor but the argument against adding it is that design mistakes in core modules cannot be fixed easily without breaking large swaths of third-party code.

Third-party modules don't have that problem: fix flaw, bump major, move on.

bnoordhuis · Mar 19, 2018

@talamaska What makes you think you'll like the built-in websockets module better?

Note that I'm personally (mildly) in favor but the argument against adding it is that design mistakes in core modules cannot be fixed easily without breaking large swaths of third-party code.

Third-party modules don't have that problem: fix flaw, bump major, move on.

As the author of one of the earliest websocket modules (which I've since decided shouldn't be used in favour of ws, websocket, faye, etc), I would say that we've already had to make special changes to core's http module in order to support websockets: now that they are a formal specification, I see no reason that they shouldn't be entirely in core.

I agree with @3rd-Eden and @rauchg, particularly with exposing some lower level primitives that could be used to build custom websocket-based protocols. I wouldn't argue for all protocols to be build into Node.js, but web-native protocols make sense: they fit with how most people use node.js, they're expected.

I for one fully support the idea of making Websockets part of node.js core (though, let's skip the Global)

Aside: On http2, whilst I've not followed fully, it sounds like it could've benefited from being non-core for a little longer, but that's an entirely separate discussion.

ThisIsMissEm · Mar 19, 2018

As the author of one of the earliest websocket modules (which I've since decided shouldn't be used in favour of ws, websocket, faye, etc), I would say that we've already had to make special changes to core's http module in order to support websockets: now that they are a formal specification, I see no reason that they shouldn't be entirely in core.

I agree with @3rd-Eden and @rauchg, particularly with exposing some lower level primitives that could be used to build custom websocket-based protocols. I wouldn't argue for all protocols to be build into Node.js, but web-native protocols make sense: they fit with how most people use node.js, they're expected.

I for one fully support the idea of making Websockets part of node.js core (though, let's skip the Global)

Aside: On http2, whilst I've not followed fully, it sounds like it could've benefited from being non-core for a little longer, but that's an entirely separate discussion.

Cross referencing bugs here: introducing websockets into the core could potentially help with issues like socketio/socket.io#3212 in the long run, where people are relying on binary extensions to improve websocket speed - which is evidently not a good idea.

nicolasnoble · Mar 27, 2018

Cross referencing bugs here: introducing websockets into the core could potentially help with issues like socketio/socket.io#3212 in the long run, where people are relying on binary extensions to improve websocket speed - which is evidently not a good idea.

In the long run aren't users going to prefer http2 streaming capabilities over websockets?

bertolo1988 · Mar 30, 2018

In the long run aren't users going to prefer http2 streaming capabilities over websockets?

Huh? I haven't read anything to suggest that http2 will supersede websockets. http2's streaming is bidirectional but not symmetric - only the client can initiate requests. Unless something changed recently, server side push doesn't bubble responses up to JS code. Also (afaik) just like http, http2 doesn't make any guarantees about preserving the order of client->server messages.

You could implement your own message-oriented streaming protocol on top of http2 using POST messages for C->S and server-sent events for S->C. But you will have to implement your own message ordering code. And you'll have load balancer problems. Websockets are sticky-by-default. That is to say, if you have a cluster of frontend servers with a load balancer, a websocket connection will stay connected to a single frontend machine for its lifetime. Configuring load balancers to replicate that behaviour on top of normal http requests is a black art. Corner me in a bar sometime and I'll tell you all about the nightmares we had getting sticky sessions working correctly through ELB a few years ago. (I understand some libraries try to silently migrate sessions. This introduces its own concurrency problems, and it doesn't work for all use cases.)

So, no. In the long run I hope websockets are reimplemented on top of http2. Although to be honest most of http2's benefits won't make much difference for websockets anyway. Over http2 the initial WS connection & handshake will be faster (since it can reuse the TCP connection it loaded the page on), but once its established it won't really matter. When websockets are implemented in http2, it will still make sense to have websocket code inside nodejs.

josephg · Mar 30, 2018

Huh? I haven't read anything to suggest that http2 will supersede websockets. http2's streaming is bidirectional but not symmetric - only the client can initiate requests. Unless something changed recently, server side push doesn't bubble responses up to JS code. Also (afaik) just like http, http2 doesn't make any guarantees about preserving the order of client->server messages.

You could implement your own message-oriented streaming protocol on top of http2 using POST messages for C->S and server-sent events for S->C. But you will have to implement your own message ordering code. And you'll have load balancer problems. Websockets are sticky-by-default. That is to say, if you have a cluster of frontend servers with a load balancer, a websocket connection will stay connected to a single frontend machine for its lifetime. Configuring load balancers to replicate that behaviour on top of normal http requests is a black art. Corner me in a bar sometime and I'll tell you all about the nightmares we had getting sticky sessions working correctly through ELB a few years ago. (I understand some libraries try to silently migrate sessions. This introduces its own concurrency problems, and it doesn't work for all use cases.)

So, no. In the long run I hope websockets are reimplemented on top of http2. Although to be honest most of http2's benefits won't make much difference for websockets anyway. Over http2 the initial WS connection & handshake will be faster (since it can reuse the TCP connection it loaded the page on), but once its established it won't really matter. When websockets are implemented in http2, it will still make sense to have websocket code inside nodejs.

[@theturtle32 said:] I don't feel it's anywhere near as widely used or fundamental as HTTP is, and it would end up just being more for the core team to have to maintain.

As others have pointed out, adoption is actually high.

[@josephg said:] will the entire community benefit from it being part of the core? (no - websockets are used widely but still only in a minority of projects)

This is a false negative; it may be a chicken and egg scenario where adoption seems lower (it's not) because the tooling is not easy to use and natively available. I personally believe this to be true. Adoption will be much higher with the right low-level API.

[@josephg said:] Personally I think there's a middle-ground that I'd like even better: Have an official list of recommended solid, default modules for specific tasks in nodejs. These could be decided on however we like. The official documentation should list these modules.

Off topic, but it could easily solve the "should we" paradigm. Too much to say on that here. Can it be picked up elsewhere?

[@mikeal said:] Node.js adopting new core protocols of the Web is perfectly in-line with its original vision and only a dogmatic originalism could argue otherwise. There may be perfectly good technical reasons not to include Web Sockets but the argument that it is somehow out of scope doesn't match the history or vision the project has had since day one.

EXACTLY this.

[@rauchg said:] My opinion is that WebSocket should be in core. Node.js was designed and has thrived as a platform for writing network services.

As someone who has had to implement WS on a few different projects, I am certain of two things: usage will increase dramatically over the coming years by particular verticals (storytelling engineers, for one). As well, WS are never easy to use. As @mikeal said, one of the things Node.js has had going for it from the beginning was the sense that it was built to be interoperable with the browser. Java, Ruby, Python, Go, and all the other low-level languages have never been easy to work with in terms of browser interoperability, and one of the explicit reasons is the difficulty in interacting with basic protocols such as http. Userland has built up a nice ecosystem around WS, but the tooling and ease-of-use factor is still a hell-a-difficult.

Treat WS as the first-class citizen it deserves to be treated. This should have been done 5 years ago.

arxpoetica · Apr 21, 2018

[@theturtle32 said:] I don't feel it's anywhere near as widely used or fundamental as HTTP is, and it would end up just being more for the core team to have to maintain.

As others have pointed out, adoption is actually high.

[@josephg said:] will the entire community benefit from it being part of the core? (no - websockets are used widely but still only in a minority of projects)

This is a false negative; it may be a chicken and egg scenario where adoption seems lower (it's not) because the tooling is not easy to use and natively available. I personally believe this to be true. Adoption will be much higher with the right low-level API.

[@josephg said:] Personally I think there's a middle-ground that I'd like even better: Have an official list of recommended solid, default modules for specific tasks in nodejs. These could be decided on however we like. The official documentation should list these modules.

Off topic, but it could easily solve the "should we" paradigm. Too much to say on that here. Can it be picked up elsewhere?

[@mikeal said:] Node.js adopting new core protocols of the Web is perfectly in-line with its original vision and only a dogmatic originalism could argue otherwise. There may be perfectly good technical reasons not to include Web Sockets but the argument that it is somehow out of scope doesn't match the history or vision the project has had since day one.

EXACTLY this.

[@rauchg said:] My opinion is that WebSocket should be in core. Node.js was designed and has thrived as a platform for writing network services.

As someone who has had to implement WS on a few different projects, I am certain of two things: usage will increase dramatically over the coming years by particular verticals (storytelling engineers, for one). As well, WS are never easy to use. As @mikeal said, one of the things Node.js has had going for it from the beginning was the sense that it was built to be interoperable with the browser. Java, Ruby, Python, Go, and all the other low-level languages have never been easy to work with in terms of browser interoperability, and one of the explicit reasons is the difficulty in interacting with basic protocols such as http. Userland has built up a nice ecosystem around WS, but the tooling and ease-of-use factor is still a hell-a-difficult.

Treat WS as the first-class citizen it deserves to be treated. This should have been done 5 years ago.

Treat WS as the first-class citizen it deserves to be treated. This should have been done 5 years ago.

Especially with the growing popularity of WAMP-based apps.

+1 on this.

galvez · Jul 18, 2018

Treat WS as the first-class citizen it deserves to be treated. This should have been done 5 years ago.

Especially with the growing popularity of WAMP-based apps.

+1 on this.

From the about page

About Node.js®
As an asynchronous event driven JavaScript runtime, Node is designed to build scalable network applications.

Node should definitely have a WebSocket support and Server-sent Events, TPC, UDP, HTTP, HTTP2.

GrosSacASac · Jul 26, 2018

From the about page

About Node.js®
As an asynchronous event driven JavaScript runtime, Node is designed to build scalable network applications.

Node should definitely have a WebSocket support and Server-sent Events, TPC, UDP, HTTP, HTTP2.

MylesBorins added the feature request label Mar 13, 2018

MylesBorins referenced this issue Mar 13, 2018
Open
Feature Idea: Brotli support in core #18964

outaTiME referenced this issue Mar 14, 2018
Closed
Force websocket close without reconnection how? #17

thecodingdude referenced this issue Mar 19, 2018
Closed
Implement window.fetch into core #19393

styfle referenced this issue Mar 19, 2018
Closed
ep: ws in core #6

nicolasnoble referenced this issue Mar 27, 2018
Closed
Socket.io crashes loading in Electron on MacOS #3212
1 of 2 tasks complete

nodejs/node

Join GitHub today

Adding Websocket support to core #19308

Comments

MylesBorins commented Mar 13, 2018

MylesBorins added the feature request label Mar 13, 2018

MylesBorins referenced this issue Mar 13, 2018

This comment has been minimized.

eugeneo commented Mar 13, 2018

This comment has been minimized.

devsnek commented Mar 13, 2018 • edited Edited 2 times devsnek edited Mar 13, 2018 (most recent) devsnek edited Mar 13, 2018

This comment has been minimized.

mscdex commented Mar 13, 2018

This comment has been minimized.

devsnek commented Mar 13, 2018

This comment has been minimized.

mscdex commented Mar 13, 2018 • edited Edited 1 time mscdex edited Mar 13, 2018 (most recent)

This comment has been minimized.

lpinca commented Mar 13, 2018

This comment has been minimized.

MylesBorins commented Mar 13, 2018

This comment has been minimized.

mscdex commented Mar 13, 2018

This comment has been minimized.

targos commented Mar 13, 2018

This comment has been minimized.

bnoordhuis commented Mar 13, 2018

This comment has been minimized.

brianleroux commented Mar 13, 2018

This comment has been minimized.

jasnell commented Mar 13, 2018

This comment has been minimized.

watson commented Mar 13, 2018

This comment has been minimized.

MylesBorins commented Mar 13, 2018

This comment has been minimized.

jasnell commented Mar 13, 2018

This comment has been minimized.

kof commented Mar 13, 2018 • edited Edited 1 time kof edited Mar 13, 2018 (most recent)

This comment has been minimized.

addaleax commented Mar 13, 2018

This comment has been minimized.

kof commented Mar 13, 2018 • edited Edited 1 time kof edited Mar 13, 2018 (most recent)

This comment has been minimized.

lpinca commented Mar 13, 2018

This comment has been minimized.

mcollina commented Mar 13, 2018 • edited Edited 1 time mcollina edited Mar 13, 2018 (most recent)

This comment has been minimized.

MylesBorins commented Mar 13, 2018

This comment has been minimized.

watson commented Mar 13, 2018

This comment has been minimized.

devsnek commented Mar 13, 2018

This comment has been minimized.

watson commented Mar 13, 2018 • edited Edited 1 time watson edited Mar 14, 2018 (most recent)

This comment has been minimized.

TimothyGu commented Mar 14, 2018

This comment has been minimized.

MylesBorins commented Mar 14, 2018

This comment has been minimized.

lpinca commented Mar 14, 2018 • edited Edited 2 times lpinca edited Mar 14, 2018 (most recent) lpinca edited Mar 14, 2018

This comment has been minimized.

M3kH commented Mar 14, 2018 • edited Edited 1 time M3kH edited Mar 14, 2018 (most recent)

This comment has been minimized.

lpinca commented Mar 14, 2018 • edited Edited 1 time lpinca edited Mar 14, 2018 (most recent)

This comment has been minimized.

kof commented Mar 14, 2018

This comment has been minimized.

lpinca commented Mar 14, 2018

This comment has been minimized.

kof commented Mar 14, 2018 • edited Edited 1 time kof edited Mar 14, 2018 (most recent)

This comment has been minimized.

lpinca commented Mar 14, 2018

This comment has been minimized.

kof commented Mar 14, 2018

This comment has been minimized.

lpinca commented Mar 14, 2018

This comment has been minimized.

jasnell commented Mar 14, 2018

outaTiME referenced this issue Mar 14, 2018

devsnek commented Mar 13, 2018 •

edited

Edited 2 times

devsnek edited Mar 13, 2018 (most recent)

devsnek edited Mar 13, 2018

mscdex commented Mar 13, 2018 •

edited

Edited 1 time

mscdex edited Mar 13, 2018 (most recent)

kof commented Mar 13, 2018 •

edited

Edited 1 time

kof edited Mar 13, 2018 (most recent)

kof commented Mar 13, 2018 •

edited

Edited 1 time

kof edited Mar 13, 2018 (most recent)

mcollina commented Mar 13, 2018 •

edited

Edited 1 time

mcollina edited Mar 13, 2018 (most recent)

watson commented Mar 13, 2018 •

edited

Edited 1 time

watson edited Mar 14, 2018 (most recent)

lpinca commented Mar 14, 2018 •

edited

Edited 2 times

lpinca edited Mar 14, 2018 (most recent)

lpinca edited Mar 14, 2018

M3kH commented Mar 14, 2018 •

edited

Edited 1 time

M3kH edited Mar 14, 2018 (most recent)

lpinca commented Mar 14, 2018 •

edited

Edited 1 time

lpinca edited Mar 14, 2018 (most recent)

kof commented Mar 14, 2018 •

edited

Edited 1 time

kof edited Mar 14, 2018 (most recent)

theturtle32 commented Mar 14, 2018 •

edited

Edited 1 time

theturtle32 edited Mar 14, 2018 (most recent)

devsnek commented Mar 15, 2018 •

edited

Edited 2 times

devsnek edited Mar 15, 2018 (most recent)

devsnek edited Mar 15, 2018

MAPESO commented Mar 15, 2018 •

edited

Edited 1 time

MAPESO edited Mar 15, 2018 (most recent)

josephg commented Mar 15, 2018 •

edited

Edited 5 times

josephg edited Mar 15, 2018 (most recent)

josephg edited Mar 15, 2018

josephg edited Mar 15, 2018

josephg edited Mar 15, 2018

josephg edited Mar 15, 2018