
Build Your First Real-Time App in Node - tahazsh
https://tahazsh.com/your-first-realtime-app-in-node
======
abhisuri97
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.

~~~
softfalcon
I find this comment incredibly condescending.

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.

~~~
abhisuri97
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-...](https://tahazsh.com/fullstack-app-with-svelte-and-node-part-1)) 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.

------
pickdenis
Node.js is the opposite of what some people would consider "real time."

[https://en.wikipedia.org/wiki/Real-
time_computing](https://en.wikipedia.org/wiki/Real-time_computing)

~~~
aikah
Unfortunately both "realtime" and "systems" have become buzzwords, void of
their actual meaning. "Websocket" isn't real time of even close to it.

~~~
claytongulick
Words take on different meanings in different contexts, and get adopted in
different domains all the time - this is how language works.

An example - "I'm going to ping Bob to see if he's available"

There are innumerable others.

Sure, this isn't "real-time" in the context of microcontrollers, and RTOS
stuff, but in the web app context, I think it counts.

~~~
goatlover
Right, but it would be best to stick with accurate technical definitions when
discussing technical issues.

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

------
blunte
"real-time" \- You keep using that word. I do not think it means what you
think it means.

~~~
simonbw
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.

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

~~~
tobr
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?

~~~
dkarl
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.

------
marknadal
Great resource!

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](https://gun.eco/docs/Todo-Dapp) !

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

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

