

SocketStream: a real-time web framework for Node.js - philipDS
https://github.com/socketstream/socketstream

======
silentbicycle
Do people not realize that "real-time" actually _means something specific_ ,
you can't just claim something is "real-time" because it's fairly fast?

Nothing against this project, specifically, but I've seen this a lot lately (
_especially_ among Javascript programmers).

~~~
robertfw
If it's fast enough to make the user feel like they are interacting with the
system in real time, I think it's a fair label.

At the end of the day, what is real time anyway? The sounds I hear and the
light I see have taken time to get to me... all of experience is touched by
some form of latency ;)

~~~
Homunculiheaded
But the term has a very specific technical meaning [1], not just 'very fast'.
This is analogous to when people say that 'NP-complete' is synonymous with
'very hard'. If I posted a problem to HN that I solved and that I found very
difficult, but was not np-complete, and said "look at my solution to this np-
complete problem" people would certainly (hopefully) complain.

1\. <http://en.wikipedia.org/wiki/Real-time_computing>

~~~
bascule
I don't think all software needs to meet that specific definition to be
considered "realtime" in some aspect of the word. Google agrees:

<http://www.google.com/realtime>

Does that meet the criteria of realtime computing? If not, is Google wrong?

------
fdiotalevi
Just seen the live presentation in London and it really looked interesting,
even if really in its early stage.

Two demos available so far: <https://www.socketracer.com> and
<http://ssdashboard.com>.

Also interesting that AOL is officially putting money in the project, and with
the intention to keep it under the MIT license.

~~~
TrevorBurnham
I can't connect to those domains. DNS propagation, perhaps? Are they working
for anyone else?

~~~
gambler
Nope. It's not DNS either, I can ping them.

------
TrevorBurnham
Really cool to see another Node framework that uses CoffeeScript. SocketStream
joins the likes of:

* Brunch: <http://brunchwithcoffee.com/>

* Zappa: <https://github.com/mauricemach/zappa>

* Coffeemate: <https://github.com/coffeemate/coffeemate>

Of course, SocketStream's use of websockets to deliver _all_ content (after an
initial payload) is a very different, very opinionated approach. I also like
the look of API namespacing, which allows client and server code to be
structured analogously without having to use `requires` at the top of every
file (one of Node's weaker points, as Ryan Dahl would be the first to tell
you). It all sounds very well thought-out, and I can't wait to see where this
framework goes from here.

------
aashay
> So how secure is SocketStream? Well, to be honest - we just don't know. The
> entire stack, from Node.js right up to the SocketStream client is brand new
> and no part of it is claiming to be production-ready just yet. So for now we
> recommend using SocketStream internally, behind a firewall.

I must say, I'm excited for this to become more robust, but I appreciate their
candor in telling me why I shouldn't use it in production yet. Back to old
fashioned socket.io I guess (or maybe NowJS).

------
revorad
Just seen this demoed at the HN London meetup and it looks really cool. I'd
read about how having the same language on the client and server is nice. But
seeing someone live debugging the same code on the client and server was
really eye opening. Kudos to AOL for funding this.

------
philipDS
"Note: SocketStream will be announced at the Hacker News meetup group in
London on Thursday 23rd June. We'd appreciate it if you don't tweet/blog/post
about it until after the announcement. Thank you."

I read about it on Twitter from a socket.io contributor, so I guess it's safe
to publish this.

[edit] here's a racing game demo, powered by SocketStream:
<https://www.socketracer.com>. Impressive

~~~
dualogy
Looks like this has now been HN'ed...

~~~
paulbjensen
Hi, this is Paul. Like Hugh Hefner, I will keep it up. Bear with me, I'm in
the pub right now.

------
gokhan
_"SocketStream is kindly sponsored by AOL."_

Interesting.

------
danbmil99
I think the reason 'real-time' is used in this context is primarily because
user interaction is mostly dealt with on the client side, where response times
are at least somewhat predictable. Server updates are handled asynchronously
in the background wherever possible. The end result from a user's point of
view is to remove (to the degree possible) the server lag time from their
experience.

------
mythz
Looks like a fantastic framework! with the best handpicked choice of
technologies in one basket, really looking forward to using this!

------
robertfw
Really excited to start playing with this. I've been hoping for a more socket
focused framework that meshes well with the node style

------
invisiblefunnel
Well done README. I certainly appreciate that.

------
bascule
"Effortless, scalable, pub/sub baked right in"

I was curious how this system scaled beyond one node and thus a single point
of failure. I then saw it used Redis. Hooray, they relocated the single point
of failure.

But hey, Redis is really really fast, right? That's definitely within the
spirit of node.

------
MatthewPhillips
> SocketStream automatically compresses and minifies all the static HTML, CSS
> and client-side code your app will ever need

Even while I'm developing?

~~~
BasDirks
There are plenty of modules that do this for you, so I wouldn't be surprised.

------
mgl
How is SocketStream different from nowjs? (<http://nowjs.com/>)

------
wildmXranat
Very interesting.

------
antrover
Coffee Script. Geez. This is interesting, but too bad for the use of Coffee
Script. Yes, I realize I could convert all the files to .js and be a happy
camper.

~~~
Cushman
Too bad why? I mean, aside from the fact that it's in a language you don't
already know?

~~~
mikey_p
It just totally fragments the node developer community.

Imagine the confusion when you're working with or contributing to two
different libraries that have different indentation or documentation
standards. Now make the language different, and mix and match different
syntaxes for different languages. Should modules in JS accept patches in
coffee? What about vice versa?

Not to mention that coffeescript then becomes an additional dependency, and
while in itself that's not bad, I still consider less unnecessary dependencies
a positive aspect to a library/framework.

Edit: Why downvoted? Is this not a valid concern?

~~~
jbwyme
I agree, I would personally prefer it to be pure Javascript.

~~~
paulbjensen
Hi, this is Paul, I liken the JS/Coffee debate to those wanting to figure out
whether to learn Swedish or Danish, the languages are similar, and in fact
swedes and danes speak to each other in each other's language, because they're
similar.

Disclaimer - I'm still in the pub, What I'm trying to say is, I understand JS,
I'm still happy to code in js, but I like teh coffeescript. Let's learn to
speak to each other

~~~
mikey_p
That's why I bring up the fragmentation issue. I actually found coffee to be
very pleasant to use, and if it was more standard I would jump head first and
never look back at JS, but as it is, I got very frustrated jumping back and
forth, and decided to convert all my coffee back to JS (not that it's hard).

To reiterate, I actually love coffeescript, but I see the fragmentation as
overall hurting the JS developer community.

