Can you, JS People, please stop calling your apps "real time"? If you've ever written one true real time application, you would not be calling your web apps "rt"
(Action Stations, Action Stations - Downvoting imminent. Prepare for impact)
I wouldn't. And here is the problem JS folks are having.. Real Time does not mean "happening as fast as possible" but "deterministic". If I tell the process to turn something on and off every 1ms, the rt system will do everything in it's power to do it.
> Real Time does not mean "happening as fast as possible"
That's not the meaning that's being used here. Here it means "events are shown at the time when they occur". Which is a very common meaning of the expression "real time".
No, the meaning used here (and to the OP's defense every JavaScript/WebSockets library uses this definition) is a persistent connection where events are pushed instead of pulled.
Well, that's not a meaningful distinction, because if I tell a javascript web app to turn something on and off every 1ms, the javascript web app will do everything in it's power to do it also. It just doesn't have much power to do it. The real distinction is that a RT system is designed through and through to have a lot of power to do it.
Seriously. Generally I don't get freaked out about the dynamic nature of language, but in a technical/computing context real time means something specific & web socket libraries aren't it.
Think "stuff that controls your car" or some components of a mars rover, or some medical devices. It needs to respond within hard time limits or Bad Things can happen.
Even Google doesn't care about this level of pedantry. Analytics has a "real-time" dashboard now. Like it or not, "gay" means "homosexual" as well as "happy", "hacker" means more than just people tinkering with electronics, etc. these days.
If they cared because there is a risk of misunderstanding, I could respect that. But nobody is going to confuse the two, ever, and coming with terminology is hard. Using "real time" in this case is, in my opinion, well chosen and much better than other recent terms like "responsive design".
I for one got confused - I assumed the link is about real-time systems and not a web app (I'd be interested in reading about the former but not the latter).
You just said it. Most call themselves web devs to begin with. Not software engineers nor computer scientists.
You also alluded to a division which justifies this usage: this is a project by web devs for web devs. Web devs might use different language than software engineers or whatnot.
Bzzzt. Web "real time" isn't even soft real time, really, in the traditional sense.
It mostly just means "web sockets" so that you're not polling the web server to get updates. And honestly that's a pretty nice development in web development, and something to celebrate. Just that it's not the same thing that a lot of us think of when we think "real time software".
There are tons of meanings for "real time". Just because you like one of the definitions doesn't mean the other definitions don't exist. eg, http://en.wikipedia.org/wiki/Real-time_data
embedded systems real time is impossible over the internet. So when talking about internet technology, you have to adjust the lexicon slightly. I have no problem with this.
Are you suggesting internet applications are banned from ever using the term real time until they replace the routing architecture?? Its such a good term that I don't think the embedded engineers should get to monopolize it.
Nice clean design. However, I'm not sure about the use-case you present on the website. If you're developing websocket enabled apps, you're going to have use get a socket server at some time, so why put it off?
The main issue I see here is the use of a port other than 443 - this means traffic will likely be blocked for many users, also over 443 traffic should be encrypted to avoide bad proxies messing up the request headers
Are you on a touch device or a Windows machine perhaps? Because to me, it feels smooth but too sensitive. And since scrolling is always smooth in osx, it only feels annoying.
It has the same philosophy behind it, SimpleRT is simpler for now, has only a JS API and it's not meant to be used in production, just for development purposes. No signup needed, just use it and play around with it. We'll see how it evolves
47 comments
[ 77.7 ms ] story [ 163 ms ] thread(Action Stations, Action Stations - Downvoting imminent. Prepare for impact)
How would you implement "real" rt in JS?
That's not the meaning that's being used here. Here it means "events are shown at the time when they occur". Which is a very common meaning of the expression "real time".
Think "stuff that controls your car" or some components of a mars rover, or some medical devices. It needs to respond within hard time limits or Bad Things can happen.
along the lines of: responses are guaranteed within a certain time
Edit: Although I admit that I very much associate the "rt" suffix with the "runs in deterministic time" kind of realtime.
You also alluded to a division which justifies this usage: this is a project by web devs for web devs. Web devs might use different language than software engineers or whatnot.
Meteor.js isn't a meteor, says the cosmologist.
It mostly just means "web sockets" so that you're not polling the web server to get updates. And honestly that's a pretty nice development in web development, and something to celebrate. Just that it's not the same thing that a lot of us think of when we think "real time software".
http://en.wikipedia.org/wiki/Real-time for a list.
Are you suggesting internet applications are banned from ever using the term real time until they replace the routing architecture?? Its such a good term that I don't think the embedded engineers should get to monopolize it.
Just seconds before I was to send very clever real time message:
Such RealTime, Wow.
What did you want to show us? Where is the documented source, where is regression test, where even is the license file?