Nice writeup...but why is this on the front page? Socket.io apps w/a node backend are run-of-the-mill for any CS course dealing with web dev in javascript.
Asking "why is this on the front page?" and "...are run-of-the-mill for any CS course..." after you say "Nice writeup" isn't a compliment. It's a back-handed compliment.
Sorry, I didn't mean for it to come off that way. I genuinely meant that it was a good writeup; however, tutorials that make it to the front page (I have noticed) usually have some content that's new/uses some newer or relatively unknown technology. The author definitely has a lot of other more interesting and in-depth writeups e.g. a 3 pt fullstack series on using svelt w/a node backend (https://tahazsh.com/fullstack-app-with-svelte-and-node-part-...) that barely got attention upon HN submission.
It's just surprising that out of that content, this makes it to the frontpage. I'm not faulting the author, I'm just curious as to what insight HN readers got out of this article.
I don't think it's condescending - I clicked the link thinking it was something other than some run of the mill socket.io demo... and then that's exactly what it was. Oh well! :)
I generally agree with the commenter here, its really rare to see a tutorial article on the front page of HN (I work in NodeJS fullstack web development)
I am not certain but I think it might be social voting, where you get all your friends and neighbor to upvote on a thread. But then again HN crowd there are lot of beginning programmers.
When I saw the title, I saw this misery before me where recruiters serve up people like the author to companies looking for ‘realtime system engineers’ just because people put keywords on their linked in and have blog posts which look insightful etc. We all have our skills, but realtime system engineering is not an easy one. Replacing that with something websockets would be better imho.
What I've learned from years of working with product managers is that anything that is both faster than a day and faster than we've conditioned users to expect can be called "real time." If you switch from generating reports nightly to doing it every four hours, that's "real time reporting."
Maybe it means "not with the usual latancy of a REST app" in this context. In a prevoius life I did systems that ran on microcontrollers. Back then even having an OS would disqualify you from getting to claim "real time". Everything ran on the interrupts.
Wanted to say the same thing, in my case thinking of Sun's ChorusOS and Solaris schedulers and definitions of realtime wrt bounded dispatch latency. I can't believe, even having been a v8 committer ten years ago, that node can make guarantees about response time to events, i.e., bounds on dispatch latency, that are super enthusiastic. I hope I learn there's more to be enthused about.
In all fairness, I've heard the use of "real time" applications with respect to chat (websockets) or video (WrbRTC). This is the first time I've been introduced to this definition of real-time computing.
I'd be interested to see how many people are aware of this definition and why there appears to be such a divide in the first place.
Funny anecdote from using Socket.io for the first time several years ago. Some friends and I were building a fairly standard CRUD webapp, and we misunderstood some Socket.io documentation, thinking it handled the session separation under the covers. Instead, when we tried it on a shared server instead of locally, we discovered that any UI action was sent to all users of the site. There was effectively one session that all users shared. We pivoted to a 'Lightweight Collaborative Web Browsing Experience', but couldn't get it working reliably.
The term “real-time” generally has a different meaning in the context of web development than in the context of systems programming. A lot of people in these comments seem to be making fun of the author for using the term in a different context than they’re used to.
I think it's worth pointing it out to the author so in the future they can use different terminology that doesn't conflict with existing usage in software development. Some collision in terminology is inevitable, but it's nice to avoid if possible.
I mean, even though I've never done real-time programming and probably never will, I don't treat the term as up for grabs. I like that I know what "real-time" means when I hear it, so I (e.g.) gently steer coworkers towards different terminology every time they try to label something we do "real time."
So what is the recommended alternative terminology? For example, how would you characterize the type of collaboration that happens in Google Docs, or the type of communication that happens in a chat?
I'm not a web developer, so I wouldn't be the best person to ask, but the key aspect is that the server pushes data to the browser as soon as it gets it rather than waiting for it to be requested, right? You could call it "low-latency push" or "low-latency remote interaction" or something like that.
Or you could cut to the chase and call it "websockets." socket.io supports other technologies for ancient browsers, but that's a detail that could be addressed in the post.
I think it would be fine to contextualize it as "collaboration". E.g., "real-time collaboration app". You might also say immediate, instant, simultaneous, or live collaboration. Or you could be more specific about the context. Etherpad, for example describes itself as "Etherpad allows you to edit documents collaboratively in real-time, much like a live multi-player editor that runs in your browser."
I know. I was being a little snarky, but I'm also trying to make a point.
The problem is that one of the (most commonly accepted, if not official) meanings of "real-time" is a system that guarantees response within a specific time period. Usually this is a pretty small time period. So also using the term to refer to systems where there is actually no limit on the response time creates a problem.
If we allow "real-time" to be used to represent anything interactive, then how can we make clear when we're actually talking about a real-time system? Really real-time? Legit real-time?
Real time as you define it isn't even a single concept since we have hard vs soft real time. Maybe this can be called super-soft real time? I jest but the definition is already muddied.
I'm on the fence, having done embedded work, I understand the importance of hard-/soft-realtime distinctions.
Our technical terms to some extent do need to be gate-kept against having their meanings watered down, but I've seen so many "realtime" browser projects, that I'm afraid we have to accept it has entered into the common vernacular like "serverless" has, in spite of the inaccuracies.
I think the context is supposed to be "web application for interacting in real-time [as opposed to more-significantly-delayed time]" versus "real-time computing" in spite of the term "real-time application"
For those interested in creating something similar with NodeJS, but not having to write or manage any of the socket or socketio logic yourself, check out this 5min interactive tutorial of ours: https://gun.eco/docs/Todo-Dapp !
Poor cross-browser compatibility. You don't need flexbox and new CSS units to display a page with a single button. Javascript code doesn't handle connection errors and disconnects. The app by itself is completely useless and doesn't use a database or something to persist state, and cannot be used as a base for writing a real app. Node is a poor choice because it forces you to write asynchronous code and it is very inconvenient. Also, it is easy to leak memory in Node and I am not sure whether there are memory profilers for Node with GUI.
Also the article doesn't give any explanations, so the only thing it teaches is how to copy the code into the editor.
Flexbox has been supported pretty much everywhere for many many years. Same goes for the CSS units I could see. Which browsers were you thinking of?
Async of Node is a feature, and you can write it like it is sync with async / await these days so there is nothing inconvenient about it (anymore - I used to hate callback hell back in the day).
