Semi-colons, semi-colons everywhere!
At the end of most lines of code that are run, the developer needs to put a semi-colon unlike in Ruby. Exceptions can be made, however, when defining a function (what a rubyist would call a method) or even some simpler logic.
This is less extreme and consistent than languages such as C++ which outright ignore whitespace and only move to the next line after a semi-colon, but it appears to nonetheless be possible to use a semi-colon in place of a linebreak (as evidenced by some rather unsightly source files... looking at you, JQuery!).
..Don't forget empty brackets!
If I've learnt anything from struggling with some particularly nerve-wracking bugs, it's that you need parentheses in front of any method call more complex than to return a stored value. Your method doesn't take arguments? Empty parentheses it is!
C'est ne pas 'puts'
Firstly, as a Rubyist you may be familiar both with puts (or sometimes print) for outputting text and with p for displaying the value of a variable during specs.
The actual 'puts' of JS
If you really, really want to say something to the user, you want to use either document.GetElementById(element_id).innerHTML = desiredText, (swap out for GetElementsByClassName or GetElementsByTagName as desired) to manipulate the content inside a HTML element.
Function? Class? Was this ever meant to be?
It is for this reason I think it is felicitous to touch on two main approaches that can be taken:
Front end single page web app:
Usually the fact that pure JS can only really perform actions within the scope of the rendered page can come across as quite daunting; how on earth do you carry data entered or produced within one part of your app across the app as a whole? But what if we don't move between pages at all, and do all our logic manipulations right there and then? Well then, reader, this curse can be made into a blessing.
The great thing about not moving between different pages in a web app is that you don't have to go to all the trouble of constantly sending out requests to the server.
This can be a lifesaver for an app's users (in figurative terms, but sometimes literal depending on what your app does) if it just so happens that their internet is pretty terrible or their provider charges a lot for that precious extra traffic.
While Node.js is a technology I must still delve further into and learn, its main appeal is that it allows both the frontend and the backend logic to be unified under a single language. From the outset, this makes it far easier to take calculations made by interactive elements on the frontend and update records held on the server-side accordingly, and in turn carry these between pages.
It is by understanding its history and the way its scope has grown profoundly from its original intended purpose that we can understand the quirks and conventions that distinguish it from other languages. There are many more I could list, but I wanted to cover what was most striking to me about JS coming from a Ruby background.