Today, we’re going to cover how to turn your Node.js script into a native command-line utility, and then how to share it with the world using NPM (Node Package Manager). In the video, I’m using the trial-and-error approach to show you everything that is required and show the errors you might encounter along the way if you forget a step. It’s actually quite simple.
Last time we talked about how to use NPM and some of the command line utilities that you can install that are built using Node.js. Today, we’re actually going to build a small command line utility ourselves that can be a bit of a time saver. We’re going to use the RequireJS optimizer to automatically concatenate and minify our CSS files the moment any of them are changed.
I remember trying to get into starting with Node.js months ago and, to be frank, it wasn’t the simplest process. Installation was a hassle, and pretty much required the use of a Linux of Mac computer. Now, Node.js has evolved to the point where just about anyone can get started using Node.js (maybe not my grandparents, but they don’t even have a computer). Let’s get started!
Finally! We’ve made it to the end of the Backbone.js Application Walkthrough video tutorial series. In this final video, we make few small adjustments for the sake of organization and a bunch of other changes that convert the application to work using RequireJS. Almost every file gets touched in this video, but each only receives minor changes in order to create an overall major change in modularity and optimization.
We’ve made it to part 4 of this Backbone application walkthrough series. This time we finally get the app to do something worthwhile… like work! The application finally lives as we implement the router and hit the “GO” button. Check out the power of the router and don’t forget that just because it’s running, does not mean we’re done. The next and final video in this series converts the application to work with AMD and RequireJS.
Moving on to part 3 of the Backbone Application Walkthrough video series, we work on moving all of the templates to external files to reduce the dependency on the templates being included in the index.html file and so that they might become available if we use these views on different pages. Also, I added an extra view that wasn’t in the original application because, as you’ll see in the video, it makes things a little nicer.
We’re moving right along in our video series of tutorials walking you through the process of writing a Backbone.js application. Today we cover the views and embedded templates. There are a number of views here, all pulling from the same models and collections of wine. You’ll see each view, what it’s for, and how it works its magic. Click on through for this long look at Backbone.js views and templates.
The day everyone has long been waiting for has finally arrived. I’ve just started the first part of a series of posts walking through how to build an actual application using the Backbone.js JavaScript MVC framework. With this first piece of the puzzle I cover the structure of the application and get you started with some HTML plus the model and collection JavaScript code. Let’s take a look!
We’ve all heard time and time again that when you’re trying to determine the JavaScript capabilities of a browser you should avoid user agent string parsing like a horrible plague and instead put your trust in a little thing called feature detection. But why should we? What’s so bad about relying on user agent strings? Also, how do I even use feature detection anyway? Read on and you’ll find the answer to all of these questions.
We’ve all heard of Templating, heck I’ve written about templating. Templating is a great way to write HTML that is designed to be manipulated and inserted into a document via JavaScript, but it has a very annoying caveat: it’s a huge pain to make templates external. They pretty much have to be inline, which doesn’t allow you to maintain them separately. That’s all about to change.