Hacker News Reader

Comment by franciscop | Hacker News Reader

It is built on top of express to keep all of the good things, but it adds basic middleware and some more advanced functionality like websockets through socket.io and security through helmet by default.

It is designed to work perfectly with Promises and async/await, the new ES7 features that makes asynchronous code awesome. Also, I put a lot of work into making the documentation extensive and clear and I'll keep working on that for the future while preparing for the 1.1.

Edit, release notes: https://medium.com/server-for-node-js/server-js-1-0-released...

View on HN

Looks interesting -- will check it out. I've definitely found the batteries-not-included nature of express to be annoying at times.

I like the design of the API, but I don't understand what you mean by "built on top of express?" I see you have express in a plugin module, but I'm not sure how it's being used.

It is being used underneath to connect all of the moving parts.

In the package.json you can see its a dependency of the project. So it seems like its more of an abstraction of Express than an alternative.

Why socket.io instead of just plain websockets? Socket.io adds a lot of complexity in the client and the server. What commensurate benefit does it provide?

http://caniuse.com/#feat=websockets

Socket.io adds rooms/namespaces as a feature, automatically reconnects with effort to not have all clients reconnect at the same time, covers compatibility edgecases, heartbeat, timeouts, custom events, multiple transport methods, server side implementations in multiple languages, supports non-ws fallback for reasons that might not be browser compatibility, and a good API.

For one, it has message_id ackbacks so that you can have a request/response rpc style system. A basic feature for any websocket-heavy application.

    socket.send('login', [uname, pass], (err) => ...)

And there are socket-io clients for most languages that can interop with a socket-io server, once again supporting message_id callbacks.

Reconciling my own message_id + reconnect buffer system is not something I want to build on the client + server every time I build an application.

People talk shit about socket.io and then never recommend an alternative that implements this fundamental feature. Without message_ids, I get flashbacks to working with IMAP.

>Why socket.io instead of just plain websockets? Socket.io adds a lot of complexity in the client and the server. What commensurate benefit does it provide?

The real reasoning is browser support. Socket.io supports automatic fallback to AJAX long polling if the client doesn't support websockets. It also standardizes the interface across clients. It's essentially to websockets what jQuery is to the DOM.

Reply on news.ycombinator.com