Show HN: Joint, a real-time Node.js framework for single page apps | Hacker News Reader

Show HN: Joint, a real-time Node.js framework for single page apps

github.com

56 pointsrgbrgb23 comments

Hey, my name's Peter, I put this up. This was the non-language part of our project from the Programming Languages and Translators taught by Al Aho at Columbia last semester. Our team really focused on getting the client and server to talk without really talking about clients and servers too much. Hope you enjoy! We're all here and will answer any questions.

Feel free to tweet me @_0_ if you have any more questions.

Looks interesting, particularly for smaller apps that don't need the whole dnode protocol exposed. I think that's their target use case.

Also, I was kind of surprised that the project logo was a skeleton judging from the project description: "A hand-rolled real-time Node.js framework for connecting single page apps".

>A hand-rolled real-time Node.js framework >hand-rolled >joint

Not sure what you're suggesting, but thank you!

Skeletal joint.

Nice to see people using some of my libs to do nifty stuff but I must caution against depending on `latest` since this could cause your application to break in the future if I push breaking changes: https://github.com/ptrsghr/joint/blob/master/package.json#L5...

It's a better idea to do:

    "dnode" : "~0.9.11",
    "browserify" : "~1.10.17"

since that way you'll get patch fixes automatically but your library won't break when I push out an update that bumps the minor version, which could including backwards-incompatible changes.

Good point! Thanks for the tip and for all your great and inspiring modules.

Edit: I just switched it to use version numbers.

Isn't this exactly what nowjs does?

Yes, very similar but nowjs includes a lot more specialized functions and namespacing conventions.

However, with any library that you simply require in your node.js app, there is a certain amount of boilerplate code and HTTP stuff that you have to deal with before writing your remotely accessible functions and application code. With Joint, we were trying to figure out the most minimal way to whip up a single page web app that does some real-time stuff. We think that not exposing protocol/header stuff makes programming this stuff a little more fun.

Also see the responses regarding DNode.

I've been programming with NowJs and could you point me to the "Boiler plate" stuff you're talking about? I don't get it. It is very clean.

So at the top of any nowjs app you're going to have some kind of HTTP stuff to serve files and something about listening on a port. You might also have some Express stuff with routes.

If there's logic there that you need, Joint isn't going to work out. If you can get by with the limitation of just serving static files, Joint will take care of that setup and encourage you not to reach for HTTP when you add a feature, nothing personal.

In what sense in this real-time? Hard or soft real-time? What guarantees does it provide?

It uses dnode which uses socket.io which uses WebSockets whenever possible and falls back on flash or xhr polling. Joint is pretty new and I provide no guarantees but I've found those libraries to be pretty dependable when it comes to telling me when someone disconnects and keeping the connection open (socket.io checks for a heartbeat).

Well that's not real time in any sense then is it?

"a non-real-time system is one that cannot guarantee a response time in any situation, even if a fast response is the usual result"

http://en.wikipedia.org/wiki/Real-time_computing

This complaint is getting a bit tiring. It's clear from the context that the author is talking about the real-time web, not real-time computing.

http://en.wikipedia.org/wiki/Real-time_web

Do you have a better term to describe web-based systems that offer the appearance (to humans) of instant communication with the web server?

why does this require its own application to launch it? wouldnt it be fairly easy to make this connect/express middleware?

Yes, DNode (https://github.com/substack/dnode) will actually do most of this stuff and it is a pluggable library.

For Joint, we wanted to make a really clean interface just for single page apps where you're only focusing on function calls rather than HTTP headers, cookies, routes, etc. A lot of the small 1-off apps we were making and thinking of making just had a couple HTTP requests for static files then a bunch of AJAX or socket.io calls. We think that in this case, the limitations imposed by Joint will help inspire creative solutions.

Neat hack. Excellent tutorial.

What would be the benefit of using this over something like ZeroMQ?

For a single page web app? I would guess that it would be quite a bit easier to use Joint as this is what it's designed for.

Are there any nice ZeroMQ libraries that run in the browser?

You can do exactly the same thing using DNode.

Yep, and DNode is running under the covers. We wanted to get rid of all the extraneous stuff you have to do to set DNode up, get an HTTP server going, serve static files, etc. when you're making a single page web app.

Heard about Meteor.js?

Reply on news.ycombinator.com