Week 7: Front-end

NOTE: I’m a few weeks late publishing this because I got busy and forgot to finish this post. So I’ll be summarizing week 9 soon.

Even though I’m in the Iron Yard’s Ruby on Rails backend course, we’ve taken the past week or so to explore JavaScript, jQuery, and the basics of front-end design. We did so by taking a note-posting API that we’d created previously in Rails(pretty similar to a blog writing platform, really) and writing a front-end for it outside of Rails. As always, you can check it out at my github I really appreciate that we’ve gotten this chance, since many of the junior developer positions that seem to exist prefer a familiarity both both sides of the stack. Here are some thoughts from my week spent in the front-end:

  • I have a new appreciation for Ruby’s syntax. Javascript, in many ways is like Ruby. It’s object oriented. They share a ton of basic features like hashes, arrays, classes, functions/methods. And it seems that they generally deal with data and information in the same sort of ways. Our instructor literally showed six slides comparing JavaScript and Ruby and then announced we knew the language. It was half-tongue-in-cheek, of course, but there’s a kernel of truth there. In actual spoken-language terms, Ruby and JavaScript are like Spanish and Portuguese. Knowing how to speak/write one isn’t enough to know how to communicate in the other, but when you start to look at the other language, you can read and understand what’s generally happening. One way that they are dissimilar, however, is in their syntax. Ruby’s syntax is very forgiving, relying on simple statements like “end” (if you want to end a loop or method), lots of implicit assumptions, and a few punctuation symbols to establish meaning. It’s really easy to look at Ruby and know exactly how far down you are nested, for example. Javascript, on the other hand, is much more punctuation heavy, and requires more explicit statements. Take, for example a commonly cited code comparison between the two languages:
Ruby: arr.map(&:strip)
Javascript: arr.map(function(x) { return x.trim() })

As you can see, the Ruby bit is about twice as short, and doesn’t require explicit calling of functions inside iterator methods, doesn’t require methods/functions to be marked with parentheses, and doesn’t require an explicit “return”. Maybe it’s first-language bias, but I find Ruby much more pleasant to read. I do hear that JavaScript is moving more towards a Ruby style syntax. For example, there’s no longer a need to put semi-colons everywhere — I believe previously two would have been needed in the JS code above. And I think that you can now write the above JS something like this, which isn’t that bad at all.

arr.map((x) => return x.trim())

Most of the JS one reads on the internet, however, isn’t nearly so pretty.

  • That said, I really enjoyed my time learning JS. In particular, the way that JS is able to access and manipulate the entire html document (the DOM) that gets rendered by browsers. It really does make a website more more seamless and user-friendly when the page doesn’t reload every time that an action is taken by a user. Instead, just the part of the page that is affected by the action is altered. It’s kind of brilliant how this is done. You attach event handlers to objects to listen for specific events. For example, you could attach a handler to listen for a “click” on a button. When that happens, a script that you have attached to that event fires. Usually, you prevent that button from doing whatever it was going to do, and instead fire off an ajax request to an endpoint on some API. Then you take whatever data you get back and shove whatever pieces of it you want into the html document wherever you want it. This makes the whole experience appear more seamless from a UX perspective, and also reduces the amount of data that your individual API calls are asking for, speeding up your website.
  • On another note, I think I could be happy if ended up as a front-end OR back-end engineer in the long term. I’m still figuring out what I’m most interested in, obviously, but I really enjoyed thinking about and designing the visual aesthetics and user experience of my application. I was a bit surprised by this, since I wasn’t one to enjoy art class in high school (I think the peak of my art experience was finger painting in kindergarten). But freed from the physical constraints of studio art — drawing straight lines, globbing the right amount of paint, etc — I found myself much more capable of producing decent looking stuff. Not beautiful, groundbreaking stuff, mind you, but websites that are, nevertheless, a far sight better that I would have thought possible given my lack of artistic inclinations in school. Good enough, I think to suggest that with enough practice and training, I could probably be good at the design portion. If there’s anything that I’ve learned over the past seven weeks, it’s that what matters more than anything is persistence and hard work — even though I may not be the most naturally talented artist, I can make myself a good front-end programmer.
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.