Overview of a full-stack javaScript site, part 2

Yesterday I detailed the code we’ll be using on our Portland Code School group project to interact with the server and the database. Today we’ll look at the libraries we’ll be using on the client side to make everything work smoothly. Client-side code is becoming more and more important as sites try to improve load times and minimize the work that the server has to do, so this is definitely great stuff to learn about.

The first library we’ll be using is probably also one of the most widely known: jQuery. jQuery (or $ to its friends) is essentially a tool for navigating around the DOM to all the different elements on the page. It’s also packed with all kinds of neat build-in features, like cool image transitions, event listeners, and utilitiy methods. It’s so widely used because it’s so useful—definitely worth having a look at.

Underscore is another library we’ll be making use of. Like jQuery, it’s pretty much a utility library, and also like jQuery, it has a nickname—in this case, _. Most of Underscore’s functions revolve around collections of data—arrays and objects. Many of the array functions remind me of Ruby, which has things like flatten, compact, and uniq built in. There are plenty of similar functions for objects, as well as some general utility functions and functions that deal with functions.

The last real client-side library we’ll make use of is Backbone. Backbone requires Underscore, so we’d have to have that around even if it wasn’t a fantastically useful library in its own right. Backbone is where the serious client-side stuff starts to come in, since Underscore and jQuery are basically utility and convenience libraries. Backbone brings in the concept of views to JavaScript, which basically allow you to easily update only particular areas of the page, meaning that the site as a whole feels much faster. The client will essentially get a big chunk of data from the server on initial connection, and only display some of it at first.

The easiest way to think about this is like a tabbed window. With plain html, it’s quite possible to make a display that looks like a tabbed window; each tab can be a link, and when you click on that link, you go to a new page that has an identical layout to the previous one, except that the active tab is highlighted and the content of the tabbed section is different.

With Backbone, you can actually make all of that happen on a single page, which means no more waiting for a request to a server to get sent off across the continent, processed, and sent back. Instead, all the information is local to the client, and gets updated there. The tabs and the external portion of the page don’t change at all—only the view inside the tabbed content changes. It’s definitely pretty cool stuff, and you can see why it’s popular.

There is one other library we’ll be using, which is almost more of a production thing than anything else: Browserify. This is a handy little thing that makes life easier for developers by letting us use node-style require statements when writing code for the client. It will then take all the stuff you’ve written and compile it into a big file called bundle.js, which you then make accessible to the client through a <script> tag as usual. This lets you keep from having dozens of lines of <script> tags, which is pretty nice. There’s also a browserify-compatible library called watchify that will keep an eye on your code as you develop it and update the bundle.js for you—better and better!

And that should take care of most of the stuff we use in this project. It’s possible that a few more libraries will get dragged into the fray as well, but those should provide a basic outline for a full-stack JavaScript site.

Leave a Reply

Your email address will not be published. Required fields are marked *