In this reading, we focus on literals and constructors. Again, this continues the exploration into the fundamentals of how JavaScript works — with the goal of being able to grok design patterns — ways of formatting bits of code in the language when structuring systems, all designed to handle the most common cases. Put another way to be prepare to carefully design and architect code, it’s important to understand a bit more of the building blocks we’re working with. A departure from my usual accepting the idiosyncracies of the language because that’s just the way it is.
Anyway, this chapter is all about different types of information in JavaScript (lists, objects, etc) and how to create them. It was interesting to learn that everything is very object-based. I always thought a list was distinct from an object, but in fact, a list or array in JS (I’ll shorten JavaScript to JS from here on out) is a type of object. This explains why checking the type of an array tells me an object — I always just thought that was a symptom of my broken code. Intriguing that the other way I’ve checked, testing for length which works for an array, but not for an object, isn’t reliable. You could always add a length function to an object, since you can customize how these building blocks work. I found the book’s suggestion to be a bit less readable than my instincts tell me is okay, so I don’t really have a great solution for testing an object’s type in JS right now. But I’m thinking a lot more about this than I did before.
There is also a big difference b/w creating a new instance of an array (new Array()) and just creating an empty one (myArray = []). The latter is preferable. I didn’t know the former was an option before, and that helps me better understand how JS works, but sounds like I should stick to what I’ve been doing.
Jumping back and forth between reading and writing code for Ruby and JS is both confusing, but also raises an interesting thought process. I am intrigued to learn about how related to objects JS as, and how that might play into what I’ve learned about object-oriented program during my recent foray into Ruby. Could I think of JS objects more not just as a place to collect methods (and that was a reach beyond just jumping functions everywhere), but attaching information of a certain type, to better organize code. And is the state of those values I could attach a way to keep track of application state, what a certain piece of the app is doing at a given time? As I’m writing, I think I’m finally starting to understand that may be what Backbone helps support. (Don’t quote me on that last bit, this is a space to think out loud, and it’s very likely I could be off on this; just working through the learning as I go.)
Of course, I also see the difference in languages, like how end is used at the end of a Ruby block, but causes a syntax error in JS. And the naming convention in JS is camelCase, Ruby has snake_case (see the capitals vs. underscores?). I don’t know that I’ll ever get over accidentally typing the wrong syntax in different programming files, although maybe it will get better with time.
Oh, and I’ll close with another interesting thing in terms of vocab that I learned last week, related to all this — the difference between a method and a function. A function is more generic, a block of code that does some task. A method is a function attached to an object or class. I guess kind of like a square is a specific type of rectangle. I’ve been trying to be more precise in this language in the past week or so. Always something new to learn!
