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.
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 ;)
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.
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. ;)
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.
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.
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.
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.
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.
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.
Nothing against this project, specifically, but I've seen this a lot lately (especially among Javascript programmers).