Do people not realize that "real-time" actually <i>means something specific</i>, you can't just claim something is "real-time" because it's fairly fast?<p>Nothing against this project, specifically, but I've seen this a lot lately (<i>especially</i> among Javascript programmers).
Just seen the live presentation in London and it really looked interesting, even if really in its early stage.<p>Two demos available so far: <a href="https://www.socketracer.com" rel="nofollow">https://www.socketracer.com</a> and <a href="http://ssdashboard.com" rel="nofollow">http://ssdashboard.com</a>.<p>Also interesting that AOL is officially putting money in the project, and with the intention to keep it under the MIT license.
Really cool to see another Node framework that uses CoffeeScript. SocketStream joins the likes of:<p>* Brunch: <a href="http://brunchwithcoffee.com/" rel="nofollow">http://brunchwithcoffee.com/</a><p>* Zappa: <a href="https://github.com/mauricemach/zappa" rel="nofollow">https://github.com/mauricemach/zappa</a><p>* Coffeemate: <a href="https://github.com/coffeemate/coffeemate" rel="nofollow">https://github.com/coffeemate/coffeemate</a><p>Of course, SocketStream's use of websockets to deliver <i>all</i> 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.<p>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."<p>I read about it on Twitter from a socket.io contributor, so I guess it's safe to publish this.<p>[edit] here's a racing game demo, powered by SocketStream: <a href="https://www.socketracer.com" rel="nofollow">https://www.socketracer.com</a>. Impressive
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.
"Effortless, scalable, pub/sub baked right in"<p>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.<p>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<p>Even while I'm developing?
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.