6 ms·

SocketStream: a real-time web framework for Node.js

128 points by philipDS 15y ago

philipDS 15y ago
"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 https://www.socketracer.com. Impressive
- deleted 15y ago
  [deleted]
- dualogy 15y ago
  Looks like this has now been HN'ed...
  - paulbjensen 15y ago
    Hi, this is Paul. Like Hugh Hefner, I will keep it up. Bear with me, I'm in the pub right now.
MatthewPhillips 15y ago
> 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 15y ago
  There are plenty of modules that do this for you, so I wouldn't be surprised.
gokhan 15y ago
"SocketStream is kindly sponsored by AOL." Interesting.
antrover 15y ago
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 15y ago
  Too bad why? I mean, aside from the fact that it's in a language you don't already know?
  - mikey_p 15y ago
    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 15y ago
      I agree, I would personally prefer it to be pure Javascript.
      - paulbjensen 15y ago
        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 15y ago
invisiblefunnel 15y ago
Well done README. I certainly appreciate that.
mythz 15y ago
Looks like a fantastic framework! with the best handpicked choice of technologies in one basket, really looking forward to using this!
fdiotalevi 15y ago
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 https://www.socketracer.com and http://ssdashboard.com 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.
- deleted 15y ago
  [deleted]
- TrevorBurnham 15y ago
  I can't connect to those domains. DNS propagation, perhaps? Are they working for anyone else?
  - gambler 15y ago
    Nope. It's not DNS either, I can ping them.
silentbicycle 15y ago
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 15y ago
  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 ;)
  - silentbicycle 15y ago
    Not really. The term actually refers to a specific (and in some cases crucial) characteristic, at least until a bunch of people dilute an important distinction to the point of meaninglessness. "Event-driven" or "non-blocking" is probably a better fit, here. Or "web scale", because then people know you're just making up crap about the new hotness.
    - mechanical_fish 15y ago
      Didn't you lose this battle back when the original Warcraft came out, seventeen years ago or so? Real time is not a technical term anymore in most of the conversations where it appears; it's popular jargon and it means "the opposite of turn-based". However, I wish you and L'Académie Française the best of luck. ;)
  - Homunculiheaded 15y ago
    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 http://en.wikipedia.org/wiki/Real-time_computing
robertfw 15y ago
Really excited to start playing with this. I've been hoping for a more socket focused framework that meshes well with the node style
TrevorBurnham 15y ago
Really cool to see another Node framework that uses CoffeeScript. SocketStream joins the likes of: * Brunch: http://brunchwithcoffee.com/ http://brunchwithcoffee.com/ * Zappa: https://github.com/mauricemach/zappa https://github.com/mauricemach/zappa * Coffeemate: https://github.com/coffeemate/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.
wildmXranat 15y ago
Very interesting.
revorad 15y ago
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.
deleted 15y ago
[deleted]
aashay 15y ago
> 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).
bascule 15y ago
"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.
danbmil99 15y ago
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.
mgl 15y ago
How is SocketStream different from nowjs? (http://nowjs.com/ http://nowjs.com/)
hacktheplanet 15y ago
Here's the team's first tutorial on writing apps with SocketStream in case anyone is interested: http://addyosmani.com/blog/building-real-time-coffeescript-web-applications-with-socketstream/ http://addyosmani.com/blog/building-real-time-coffeescript-w...

128 points by philipDS 15y ago

"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 https://www.socketracer.com. Impressive

deleted 15y ago
[deleted]
dualogy 15y ago
Looks like this has now been HN'ed...
- paulbjensen 15y ago
  Hi, this is Paul. Like Hugh Hefner, I will keep it up. Bear with me, I'm in the pub right now.

MatthewPhillips 15y ago

> 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 15y ago
There are plenty of modules that do this for you, so I wouldn't be surprised.

gokhan 15y ago

"SocketStream is kindly sponsored by AOL." Interesting.

antrover 15y ago

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 15y ago
Too bad why? I mean, aside from the fact that it's in a language you don't already know?
- mikey_p 15y ago
  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 15y ago
    I agree, I would personally prefer it to be pure Javascript.
    - paulbjensen 15y ago
      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 15y ago

invisiblefunnel 15y ago

Well done README. I certainly appreciate that.

mythz 15y ago

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

fdiotalevi 15y ago

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 https://www.socketracer.com and http://ssdashboard.com 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.

deleted 15y ago
[deleted]
TrevorBurnham 15y ago
I can't connect to those domains. DNS propagation, perhaps? Are they working for anyone else?
- gambler 15y ago
  Nope. It's not DNS either, I can ping them.

silentbicycle 15y ago

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 15y ago
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 ;)
- silentbicycle 15y ago
  Not really. The term actually refers to a specific (and in some cases crucial) characteristic, at least until a bunch of people dilute an important distinction to the point of meaninglessness. "Event-driven" or "non-blocking" is probably a better fit, here. Or "web scale", because then people know you're just making up crap about the new hotness.
  - mechanical_fish 15y ago
    Didn't you lose this battle back when the original Warcraft came out, seventeen years ago or so? Real time is not a technical term anymore in most of the conversations where it appears; it's popular jargon and it means "the opposite of turn-based". However, I wish you and L'Académie Française the best of luck. ;)
- Homunculiheaded 15y ago
  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 http://en.wikipedia.org/wiki/Real-time_computing

robertfw 15y ago

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

TrevorBurnham 15y ago

Really cool to see another Node framework that uses CoffeeScript. SocketStream joins the likes of: * Brunch: http://brunchwithcoffee.com/ http://brunchwithcoffee.com/ * Zappa: https://github.com/mauricemach/zappa https://github.com/mauricemach/zappa * Coffeemate: https://github.com/coffeemate/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.

wildmXranat 15y ago

Very interesting.

revorad 15y ago

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.

deleted 15y ago

[deleted]

aashay 15y ago

> 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).

bascule 15y ago

"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.

danbmil99 15y ago

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.

mgl 15y ago

How is SocketStream different from nowjs? (http://nowjs.com/ http://nowjs.com/)

hacktheplanet 15y ago

Here's the team's first tutorial on writing apps with SocketStream in case anyone is interested: http://addyosmani.com/blog/building-real-time-coffeescript-web-applications-with-socketstream/ http://addyosmani.com/blog/building-real-time-coffeescript-w...