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.
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.
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.
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.
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.
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".
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.
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).
24 comments
[ 3.0 ms ] story [ 67.2 ms ] threadFor 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.
Are there any nice ZeroMQ libraries that run in the browser?
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.
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.
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
It's a better idea to do:
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.Edit: I just switched it to use version numbers.
"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
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?