To start this post of, I feel it fitting to put one popular misconception to rest: Javascript is not, in fact, related to Java. Mine, at least, is beginning to seem like a distant cousin of working script (and sometimes, of the kind that does things!) I've come to learn a couple of things about the language along the way, and similarities/differences to Ruby.
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.
When first learning of console.log in javascript, many will see parallels to the former but it is in fact in between the two.
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.
Because you see, reader, Javascript is a front end language intended to manipulate HTML (and sometimes CSS).
Function? Class? Was this ever meant to be?
While the most recent standard for Javascript (ES6) does have a class syntax of sorts (and has long had a syntax for 'prototypes' of functions), the distinction between classes and methods which exists for many backend languages doesn't translate as cleanly on to JavaScript for the most part as a matter of design. Functions are added to a 'class' by means of className.prototype.functionName = function(){ code here }, and instances of said class defined by var instanceName = new className.
Javascript, ultimately, is a front end tool intended to manipulate HTML and CSS on the fly.
Few could have anticipated the complexity of logic which it has evolved to be able to take on - especially of the kind that traditionally would be relegated to back end logic - but methods exist to create essentially the entirety of a web application's logic in Javascript.
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.
Using Node.js:
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.
In conclusion
JavaScript is a surprisingly versatile - and at times confusing - language which has grown from a controlling medium for dynamic frontend elements to hosting capabilities on the level of a backend language.
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.
Top comments (0)