create/publish pusher-node-client

[tracker1]

It would be nice to see a node-compatible client able to be used.

This would also more readily support being able to use the existing push-js via browserify on the client, and on the server.

It's a tangent to #84 which suggests publishing as-is, which I also support. I've stopped using bower myself and have started using a build task which will copy as appropriate from node_modules/foo/dist/foo.min.js to lib/foo/foo.min.js because bower seemed like an extra step.

In addition, there's now jspm which builds on npm to look into.

[leggetter]

Thanks for your feedback and thoughts.

I think this is in reference to this StackOverflow issue and we've all been a bit confused by the ambiguous question (which I've not edited to try to clarify).

pusher-js is a browser-focused library and has lots of browser-specific functionality e.g. referencing window and supporting Flash fallback for really old browsers.

As per #84 we will likely look at adding a UMD wrapper so that those that want to use NPM and things like Browserify can more easily use pusher-js.

But adding support for pusher-js running in the Node.js runtime isn't on any roadmap right now.

It would be nice to see a node-compatible client able to be used.

There is one available: as per the SO issue referenced above, @dirkbonhomme has created https://github.com/dirkbonhomme/pusher-client-node which does offer client functionality and runs within the Node.js runtime.

It's installable using:

npm install pusher-client

Does this clarify things?

[tracker1]

@leggetter - Yes, it was in reference to the StackOverflow question... The comment as to the client was added as a notation...

Though, I think it may well be worthwhile to kind of invert things, and bring the pusher JS client library closer to the one in the pusher-client-node, then use that as the bases for a browser client (via browserify). Just my $0.02

[pl]

Hi Michael,

As Phil mentioned, pusher-js was written with browsers in mind and because there are lots of edge cases triggered by specific browsers or network configurations, the library is quite complex. Unless you are running in an environment that does not support encrypted WebSockets, there is no need for all the fallbacks and sophisticated connection strategy.

My intuition is that abstracting differences between Node and browsers would complicate pusher-js even more, which would make the codebase bigger and less reliable (at least shortly after refactoring), but I might be wrong.

I think it might be easier to provide a layer above pusher-js/pusher-node-client that could use different libraries depending on the environment, but once again I am not really sure because I don't know much about running this kind of apps.

[leggetter]

Thanks, @tracker1 for your feedback. We'll close this one for now. I'm sure similar discussions will pop up in the future. Maybe we'll get to do a biggish refactor in the future and be able to unify the browser and node libraries via some kind of shared core library - or something.

A discussion for another day :)