SocketStream: a real-time web framework for Node.js | Hacker News Reader

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

github.com

128 pointsphilipDS37 comments

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

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

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.

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

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

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?

Yes, it has a specific meaning in computer science, but it also has a plain-English meaning, as well as different specific meanings in other domains. For example, in gaming "real-time" means "not turn-based", which I think is close to what web developers mean when they use it for web pages that do two-way interactive communication.

Real time, in web technology, means that the client communicates with the server through a socket instead of repeated HTTP get requests. This is exactly what this project is describing.

You probably hear this a lot lately, especially from javascript programmers, because this is one thing node.js could be really good at.

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.

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

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

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.

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

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.

"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

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

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

"SocketStream is kindly sponsored by AOL."

Interesting.

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.

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

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

Well done README. I certainly appreciate that.

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

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

Even while I'm developing?

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

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

Very interesting.

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.

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

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?

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

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

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.

well, I speak Norwegian perfectly and close to perfect Danish and Swedish and... I know issues DO happen due to translation (because my Swedish and Danish is only close to perfect ;) ) Will be the same here. Don't get why a startup want this at all.

Two bits: Not that it isn't really elegant, but the jump from js to coffeescript does not result in a big enough gain for me to want to do it (as opposed to say, the jump from c to python). It foists an extra mental space on my team, as they have to learn to think in both languages, but doesn't give them a different programming environment with different problem solving tools. If we could totally dump js it might be more appealing. As it is, I see coffeescript splitting the js dev community by making code sharing more difficult.

Ahh "Geez" the start of every great, thoughtful language debate.

I get down voted because I prefer native Javascript to Coffee Script? Wow.

Reply on news.ycombinator.com