Adding Websocket support to core

[MylesBorins]

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

[OllieJones]

As a (very happy) user of ws, I respectfully suggest that it makes sense to keep it in userland for a while longer. Why?

1. It's still undergoing active, and excellent, work by lpinca and others. If it gets put in core then it ties together release cycles that are now independent. As things stand it's possible to use a LTS release of node, but upgrade to a recent ws version if need be. That is good (for my stuff anyway).
2. (philosophical argument) Avoiding turning node into a monolith has a lot of merit.

[3rd-Eden]

I was kindly notified of this topic by the Node.js Weekly Mailing list. We probably want to loop in everyone that ever maintained or written a WebSocket implementation in the past to give their opinions on this matter. cc @brycekahle, @josephg, @darrachequesne, @alexhultman might have opinions on this as well.

I maintain various of WebSocket (and real-time) related projects, given advice to companies to tune their WebSocket implementation as well as maintain a web service that processes millions of WebSocket messages a day.

We see that WebSocket projects are still heavily used on Node.js, just by looking at the downloads on npm we see that that there millions of downloads each day to install WebSocket libraries. So we since the completion of the specification, introduction of WebRTC and HTTP2 it's still a technology that people choose to adopt in their projects. Or is used by the technologies, for example WebSockets can be used for handshaking in WebRTC and work is done to include WebSockets in HTTP2 again. It's not a dying breed and if you ask me, it should be have been in core since the specification was completed. It's also not an technology that can be easily implemented on top of HTTP like EventSource/Server Send Events to a real-time stream of data. So to me, it's quite clear that WebSockets is not going away any time soon and has been adopted by many already as core part of the web.

There are various of userland modules that add WebSocket support to Node.js, faye-websocket, websocket, ws, uws. They all have different approaches to solving this issue. Some are written in native code, others in JavaScript or a combination of both. In addition to these, we also have modules that bind to other existing WebSocket libraries such as libwebsocket. So the question is, is this good enough? When I look at ws I feel like have reached the end of what is possible performance wise in JavaScript. It's fast, pretty damn fast, but also uses a lot memory. And in order to go faster we had to use native addons. Projects like uws has shown that it's much more efficient to do it all in C++ as Node.js can get on the heavy side when dealing millions of connections and buffers. But what the project and the ws binary addons also showed is that user land based binary add-ons are a massive pain.

As pointed out by @eugeneo Node.js already ships with a WebSocket client, a bare minimal implementation just to interact with the WebSocket API of the WebInspector, but it's already there. It needs to be binary to work outside of the event loop to work during debugger statements/breakpoints. That means if we want to have a WebSocket implementation in core, it needs to be C++ in order to share code, that also makes things like UTF-8 validation, buffer handling, masking of frames a lot easier.

So technically, we already have WebSockets in Node core, the question is, should we expand/improve this and expose this? HELL YEAH

[dcodeIO]

So technically, we already have WebSockets in Node core, the question is, should we expand/improve this and expose this?

A feeling tells me that node.js should have a WebSocket global because it already has WebAssembly, while a WebSocket server is fine to be provided by userland. That is, unless there are code sharing advantages between the two.

[lpinca]

@3rd-Eden sorry for not tagging you in the conversation didn't want to bother. uws bindings disappeared from GitHub yesterday but afaik most of the performance and lower memory usage was obtained by not using net.Socket, similarly to what is done in https://github.com/mafintosh/turbo-net.

I'm perfectly fine with that if it can be done in a compatible way with the existing http module.

[watson]

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

[markozxuu]

@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 😸

[devsnek]

@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)

[markozxuu]

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

[josephg]

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:
  • [x] is it hard to be done right?
  • [x] is it widely used?
  • [x] does it have a clear spec?
  • [x] 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.

[mikeal]

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?

[josephg]

@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?

[MylesBorins]

@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

[bnoordhuis]

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.

[mcollina]

@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.

[bnoordhuis]

@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]

@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]

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.

[bnoordhuis]

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?

[mcollina]

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.

[bnoordhuis]

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)

[jasnell]

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.

[watson]

@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).

[bnoordhuis]

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.

[jasnell]

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.

[bnoordhuis]

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.

[ofrobots]

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.

[lpinca]

@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.

[bnoordhuis]

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.

[rauchg]

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:

1. we can get demonstrably higher performance than userland implementations that don't build native addons
2. 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!

[shellscape]

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.

[kapouer]

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.

[joshwiens]

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.

[talamaska]

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++.

[bnoordhuis]

@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.

[ThisIsMissEm]

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.

[nicolasnoble]

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

[bertolo1988]

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

[josephg]

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.

[arxpoetica]

[@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.

[galvez]

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.

[GrosSacASac]

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.

[dipser]

A lot of IT-student in germany have to write websocket-applications. From this standpoint alone, it should be native. nodejs feels incomplete, if it isnt. You just use it natively in a browser, but in node.js you first have to find out, its not supported, then you have to decide which userland implementation is ok and future proof? At this point, i would be annoyed. Because you will feel like nodejs is not the wonderland of server-communication you thought. The next thing as student is, you have to deal with a callback hell. How many give up at this point? Let alone, that javascript wasnt very loved in the past, but is developing (ES6) very fast and has the big advantage of learning only one language in front- and backend. If that wouldnt be the case, nodejs would have died long ago - but thats just my impression.

[damianobarbati]

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

Definitely.

[bradisbell]

I have strong opposition to this. Node.js is used for far more than web applications. Adding bloat to the core hurts these other types of applications and their portability, while providing no significant benefit to those who want it. Keep Node.js light and keep WebSockets in solid modules like ws.

[galvez]

@bradisbell you have a valid point -- I just think WebSockets can be considered a core protocol of the web, very much like http2.

[arxpoetica]

@bradisbell this is probably the most valid point I've heard on this.

I would favor, alternately, some sort of tree-shaking methodology native to Node in that case. I.e., only import what's actually imported. Obviously waaaaaay beyond the scope of this ticket (how would such a thing even be possible), but that would be my 2 cents. Best of both worlds, actually. Significantly lighten Node core, but still have core/official requires available on demand.

[josephg]

What is the actual decision making process for a big change like this?

It'll be controversial no matter what the decision is. But it would be nice to have a clear official resolution on which way node will move forward with this. Can we bump this to the TC or something?

[devsnek]

there's nothing stopping someone from making a pr. if that pr was blocked for a non-technical reason (like "ws shouldn't be in core") it could be elevated to the TSC

[gengjiawen]

@lpinca Mind create a PR ?

Just found go has websocket too https://godoc.org/golang.org/x/net/websocket.

In js ecosystem，new api System like Graphql subscription rely on this: https://github.com/apollographql/apollo-server/blob/678714293337be19163e7ae0f973c6d873cf3656/packages/apollo-server-core/package.json#L46.

[feross]

FYI everyone: There's a new spec WebSocketStream that is intended to supersede WebSocket in the same way that fetch superseded xhr. The new spec supports backpressure.

If the decision is to add ws to Node.js, then perhaps we should skip the current API and just implement this new one, since backpressure is quite important. https://groups.google.com/a/chromium.org/forum/m/#!msg/blink-dev/X7rWpAkMCyg/j6K7mEEwAgAJ

(We should also wait until this API stabilizes and there is buy-in from other browsers besides Chrome)