We've all be there. You're trying to get a certain block of code to execute after everything else is done. If it executes too soon, you won't get it to do the thing you want it to. Lodash.defer() to the rescue! Just wrap the code that you want to execute last in an _.defer() method and it will wait until everything on the current call stack has completed and then execute your desired code. Problem solved. Or was it?

One thing I've been doing over the past few months that has both made my object traversal more readable and less lengthy is using Object.keys() to get an array of the keys on my object and then looping with the array.

The new year is always a great time to start fresh. All the failures of the previous year are forgotten and you can refocus all your efforts on what you want to achieve in the coming year. I've made several big goals this year, but I wanted to specifically address the resolutions that affect this site. I hope that by sharing them here, I can get a little more accountability from the community and that will force me into action. Without further ado, here are my 2016 goals for this site.

There are many reasons to not expose certain methods to the outside world in your JavaScript code. Your APIs will be cleaner and easier to reason about when there are fewer options available and you aren't exposing your internals. Sometimes it is important to hide implementation details for the sake of privacy. Whatever your reason, there will be times when you want to use private methods in your JavaScript code. Here are a few ways to accomplish that.

I have recently been thinking through the best way to unit test React components. The interesting thing about React components is that they are a container for a combination of state and rendering logic. This should make them easier to test than most view layers in other frameworks because we can easily change the state of a component and make assertions based on what we expect the state changes to do to modify the rendered output.

Sometimes you find yourself solving the same problem over and over again. Usually when that happens, it's a good time to step back and think about a way to have a single reusable solution.

That was exactly what was happening when we were building out a library of custom components in React. For good usability, many of our components needed to have an action occur when a user clicked outside the component. This was the case for many components such as modals, comboboxes, etc...

To use a single space between variable names or to line them up, that is the question. This is something I've never had a strong opinion on either way, but I have recently formed a strong opinion as a reaction to the error of my ways.

Over the years, I have experimented with putting my JavaScript unit tests in several different locations in my applications. A few years ago, I was very into trying to make an MVC paradigm work in my client-side code, so I would have a top-level directory called tests that would mimic the folder structure of the non-test code, so it would have a folder called models and a folder called controllers, etc...

Like nothing else out there, React has gotten me thinking of my code as a series of modules that are glued together to make a larger application. This has always been an ideal to reach for, but their focus on unidirectional data-flow has forced me to rethink the way I structure my code in a really positive way. It's no wonder that even Angular 2.0 is using a similar component-based architecture for rendering UI. It just makes sense! Today, I'm going to walk through how I have been organizing my components. This approach makes each module easy to find when I need it.

One interesting new feature that ES6 brings us is something called "destructuring." Destructuring can be used to pull certain parts of an object out of an object and assign those parts to a new variable or multiple variables. Lest you think that this is a useless part of the ES6 spec, let me show you some examples of how destructuring can be used in a JavaScript application.

One of my favorite parts of ES6 is arrow functions. In fact, at this point I encourage my team to always default to using them unless there is a clear reason not to. So, you you may be wondering what arrow functions are and why they are worth using. In this article, I will show some examples of arrow functions and how they can be used to make your JavaScript code cleaner and more readable.

With v0.13 of React, we got native support for using ES6 classes. This may not seem like a huge deal since ES6 classes are basically just syntactical sugar over the more laborious inheritance of yesteryears JavaScript. However, it is clear that there was a problem since practically every framework or helper library added their own kind of classical inheritance, often with a different implementation. The unified class syntax for ES6 gives us an easy way to do inheritance that will one day be native to every browser and JavaScript engine. Looking forward to the future, React now gives us the ability to call React.Component as a native class.

Well, it is officially a new year! I feel like every year that I've been a JavaScript developer, there have been huge things that have happened on the library front. When it comes to a community largely driven by open-source developers, it's hard to predict what the JavaScript landscape will look like in 2015. There could be a new library or framework that gets released tomorrow that literally changes everything. However, judging by the 2014 landscape, I have put together a few predictions for 2015.

Writing complex behaviors in an asynchronous language like JavaScript can be a bit of a challenge. If you aren't careful, you can make some pretty ugly nested code in order to get things to work like you expect. To solve the problem of illegible nested callbacks, we have promises. If you are writing applications in Angular, you are in luck because Angular ships with a great promise library called "Q". Today, we're going to look at a few approaches to making more readable and maintainable Angular applications with the help of the built in Q promise library.

At the ng-europe conference in Paris this year, the Angular team made several revelations about what Angular 2.0 will look like once it is complete. Several of the current features of Angular will be put to rest, but one of the more notable ones is the controller $scope. As developers prepare to eventually migrate their applications to Angular 2.0, it is important to do what we can currently in order to prepare for the easiest migration. One thing we already know we can do is to stop using the angular $scope entirely in our controllers. This is how you can do exactly that.

In my opinion, one of the coolest things about Angular as a JavaScript framework is its rich testing story. With Angular, you can easily create rich and complex interfaces that separate the concerns of DOM interaction and actual code to the point where you can write tests against everything.

I am excited to announce that next Monday, I will be starting a new job as a Senior JavaScript Developer at Aloompa!

I had been meaning to start playing around with React for quite a while now. There is a lot of buzz around React and I really wanted to see what it was all about. I had looked at a little code written with React and JSX and I was frankly a little taken aback by the syntax. But last week, I was at devLink and I saw a presentation by Jim Cowart on the React framework and several things clicked for me. I've started playing around with it this week and I thought I'd write an introductory post to cover what I've learned so far.

When I first started writing client-side applications, the process was terrible. I had to save my file and then flip over to my browser to check my results. As a result, I was clicking two buttons every time I wanted to save a file. To make matters worse, I had to repeat the process to test my application in multiple browsers. To test a minimum of Chrome, Firefox and a single version of Internet Explorer, I was clicking 4 buttons. To repeat that flow over and over again to test incremental changes was soul killing.

I have been burning the midnight oil working on a Sails application. I'll be giving a more formal announcement when I launch it, but the basic idea is that you can surf the internet and add recipes for any meals using a handy bookmarklet. Once the recipe is in the database, you can generate a meal plan with any recipes you have added. You can then print off a shopping list based on the contents of your weekly meal plan.

In Angular, there are times when you will want one controller to be able to communicate with other controllers. For example, if you want your user to be able to click a button and for a different controller to be aware of the UI change.

JavaScript has seen a ton of development even in the past 5 years. The changes haven't been so much in the language itself, but in how the language is being used. This has been a product of the host of libraries and frameworks that have been created that allow developers to consume them and do just about anything. Need a library to build robots to assist you in your evil plot to take over the world? It probably already exists.

In my previous blog post, I talked about how you can use Knockout to enhance forms that are rendered from the server. This led to my next challenge - creating lists that are rendered from the server and then managed with Knockout on the client-side in instances where JavaScript is enabled.

One of the great things about all of the best MV* frameworks is that they allow you to hardly render any templates on the server-side. That means that you only need to hit the server for data. Of course, that is great if your users have JavaScript enabled, but what if they don't?

When I was a kid, we had a family desktop computer that we kept in the living room. Since I had a brother and two sisters in addition to my parents, we had to ration our computer time to allow everyone to get on our amazing dailup connection and do whatever we liked to do. Because of that, we were limited to two hours of computer time a day.

Now that we've gotten our server-side API set up, we can us it to get data into the Angular portion of our application. We'll be using the $http service that Angular gives us out of the box. The point of this is to quickly get the application running and not necessarily best practice, so please be forgiving.

In the last few posts, we have been building an application using Sails, Angular and RequireJS. We've got a basic UI in place now, so we should be able to get it to a point where we can actually send and receive data from the server.

In the past few posts, I've been laying the groundwork for building an Angular application on top of Sails. Now that everything is in place, we can jump right in to adding Angular views.

As I promised at the beginning of this series, we are going to be using RequireJS to manage our client-side modules. If you haven't used RequireJS or a similar AMD loader before, let me just say that you are really missing out. RequireJS lets you write your code in small modules that only expose the parts of the API that you want to show and as an added bonus, it uses JavaScript to load your JavaScript modules.

Today, we are going to look at how Sails.js handles server-side templating. Sails lets you use whatever type of templating you want want, but out of the box, it uses EJS, which is based off of Ruby's ERB.

Sails JS is a really cool framework for building realtime web applications. Today I am going to show you how easy it is to create a new Sails project. In many ways, Sails is similar to Ruby On Rails. It allows you to create a new application and sets enough defaults that you can run it right away.

Since I tend to be a glutton for punishment, I have decided to devote the next several blog post to a series on making a scalable application using Sails.js on the back-end and Angular on the front-end.

Setting up multiple types of authentication on an application can be a daunting task. There are a ton of moving pieces and you want to make sure that your user model is up to the task of consuming any type of authentication you throw at it. To that end, I recently set up Facebook authentication on a Sails.js app I'm working on and I thought it might be worth sharing how easy it actually turned out to be.

In my opinion, Sails is one of the best Node MVC frameworks out there. It provides a really clean architecture and is completely customizable. The Socket.io integration also gives it an edge over many of the competitors.

I only recently started playing around with Sails, and I wanted to add a unit testing suite to the application I was working on. I searched for other people who were doing test driven development in Sails, but I wasn't satisfied with the results. As it turns out, getting tests in place for Sails was one of the easier things I've done in my life and I was able to get a few unit tests running withing 30 minutes of sitting down to do it.

About a month ago, I switched from running my blog using Poet.js on Nodejitsu to using Harp.js to compile it as a static site. There are several benefits to taking this approach. First of all, I can host the site using any server environment. When I build it, all that I have are HTML, CSS and JavaScript files and they can be hosted with Node, Apache, IIS or any other server. Another benefit is that there are several places where I can host my blog for free.

I ended up choosing to go with Github pages because this is a web development blog and I thought it was well-suited for their platform. This is how I got it working.

One of the best parts of CSS3 is the ability to do keyframe animation. Once upon a time, if you wanted to animate DOM elements in the browser, you had to do it with JavaScript. CSS3 animations are generally smoother and perform better than moving elements around with JavaScript. They also do really well on mobile devices.

With a little bit of working knowledge, it's really not hard to make some nice looking CSS3 animations, and that is what we are going to do today. If you have ever studied animation, you probably know that one of the first things you need to learn is how to do squash, stretch and bounce, which are the cornerstones of exaggerated animation physics. Today, I'm going to walk you through how you can handle those basics just using CSS3.

If you have worked on a large scalable web application, I probably don't have to tell you how important it is to keep your modules from directly referencing each other. There are several Pub/Sub libraries that have emerged to solve that problem. Some of the main contenders are PubSubJS, Postal and Amplify.

With several options to chose from, there is certainly value in abstracting away whichever choice you make so that you could easily switch the Pub/Sub library out without impacting the application. There are various reasons for switching libraries. Your library of choice might become unmaintained, or perhaps it will evolve in a way that doesn't suite your needs, or perhaps a better solution will emerge. Whatever the case, you certainly don't want to be locked in and have to change every file of your application if you do make the choice to switch at some point. Additionally, if you are using an AMD loader, you get the added benefit of not needing to require the pub/sub library in every module that uses it. This is how I have gone about abstracting my pub/sub libraries in applications in the past.

I have been a huge animation enthusiast since high-school. I even went to college hoping to become a professional computer animator before I got sucked into the wild world of computer programming. I have recently been dabbling with Three JS, which is a JavaScript engine for creating 3D models and animations for the browser.

Of course, my interests go beyond just making games and website animations. I like that the engine is written in JavaScript and that it uses web technologies like the canvas and WebGL to render the models. To that end, I have been exploring ways to export animations I make with Three JS to an external video file that I could use to stitch together actual films just like any application-based 3D animation software like Maya, Blender or Lightwave. I know it's crazy, but I think this might actually work.

If you haven't used ko.ninja yet, it is a great little framework for building awesome Knockout applications.

I've built a sample app to show how easy it is to build something with Ninja. The application is based off of Conway's Game of Life, which was devised by the British mathematician John Horton Conway in 1970.

There has been a lot of buzz around whether or not jQuery is needed for building web applications anymore. Many blog posts have sprung up about how to do common things that are typically done with jQuery just using vanilla JavaScript. While it is important to know where jQuery is needed and where a leaner solution could provide a quicker load time and less complexity, for most large-scale projects, the last thing you want to be worrying about is optimizing against various browser types and nuances.

Reactive frameworks such as Knockout may seem on the surface to work pretty well without needing jQuery at all, but as you get deeper into complex interfaces, you might find yourself needing something such as a jQuery UI component. So where should jQuery and DOM interaction go in a well-structured Knockout application?

For the past year and a half, I have been working for a completely remote company called appendTo. We literally have employees working from their houses, coffee shops and Buffalo Wildwings across the globe. One of the main draws to the company for me was the ability to work from anywhere.

There are obviously numerous benefits to remote working for the employee, but I've also come to the conclusion that if I were ever to start a company of my own, I would absolutely build it as a 100% remote company because there are a lot of benefits for the employer as well. Here are a few reasons why.

Meteor is a really nice framework for building real-time applications. The example application shows off how easy it is to share code between the server and client by putting the code inside a single JavaScript file at the root of the project. Running the example app from a single file definitely shows off how awesome sharing code is, but it also made me scratch my head trying to figure out how to organize a larger application. After reading through the documentation and a lot of trail and error, here is the organization that I have landed on.

When I first started writing JavaScript, most of the libraries that are around today weren't available, which meant that there were basically a few low-level ways to loop over an array of content. Now that there are many more options, I wanted to take a moment to examine what they are and how each option might affect readability of code as well as performance.

Unit testing in JavaScript can be difficult sometimes. Typically, you only want to test the behavior of a single module, but if you are using an AMD loader like RequireJS, you may be pulling in several other libraries and modules just to test a single module. The point of the unit test is to test an individual unit, not to test how it works with other dependencies.

If only there was a way to trick the test runner into thinking that the other modules were loaded by providing simplified stubs of the methods they actually performed! Good news, that is totally possible using Squire. Don't run away when you see the creepy looking mascot on the GitHub page, Squire is totally worth your time.

I remember when I first started playing with JavaScript in high-school. The first thing I loved about it was that I could change things without the browser even refreshing. It was like I was a magician moving elements around, hiding and showing things, totally in control of what the user could see. All I had to do was directly modify elements in the DOM and they would instantly react. But that was in the late 90s and early 2000s, now I have found reasons for abstracting away DOM interaction. That's not to say that DOM manipulation shouldn't happen, it just shouldn't be the glue that holds your application together.

Previous Post In This Series

This is a part of a larger series about the ko.ninja framework that I helped to create to make Knockout development more awesome. Previously, we looked at how we can automatically save ko.ninja data with ajax, but today we're going to look at how to use Socket.io with ko.ninja. Since I love socket.io so much, I had to include it as one of our model options in ko.ninja. This is not a primer on how to use socket.io, so if you haven't used it before, I suggest checking out my blog post on getting started with socket.io.

Previous Post In This Series

This is a part of a larger series about the ko.ninja framework that I helped to create to make Knockout development more awesome. Previously, I showed how you can create a model to save data to localStorage. Today we are going to look at how you can save data to a server using Ajax using the ko.ninja model abstraction layer.

Previous Post In This Series

This is a part of a larger series about the ko.ninja framework that I helped to create to make Knockout development more awesome. With ko.ninja, you can add a model to your viewModel to automatically save your data as soon as it changes and validates. Ko.ninja comes with several model types including localStorage, ajax and socket.io, but we also plan to add the ability to let you define a custom model type if you have other needs that are not covered by our model types.

Previous Post In This Series

This is a part of a larger series about the ko.ninja framework that I helped to create to make Knockout development more awesome. In my last post, I introduced ko.ninja, a framework that I helped create for making awesome Knockout apps. Today, we're going to continue looking at ko.ninja, but we are going to focus on doing validation on the ko.ViewModel.

Over the past year, I have been doing a ton of work on Knockout applications. There is a lot to love about Knockout. The declarative bindings allow you to keep your UI data-driven and synced at all times, which is a huge win when you are working on large scalable applications. However, one place where the Knockout core is lacking is that it is not prescriptive about how code should be written for it. That was the beginning of the idea behind ko.ninja. If we could put some structure around our viewModels, we could do some really cool things.

There are plenty of reasons to want to browse the Internet privately. Search engines and social media sites have been collecting our browsing for years in order to target marketing and advertisements to us. There are plenty of hackers out there who would love to get their hands on your data. But perhaps the most disturbing recent revelation about data collection has been the extent to which the NSA is actively gathering our personal information.

Authentication can be something of a road-blocker in application development. I can't tell you how many times I've had a great idea for an app, but instead of jumping in and writing the core functionality, I try to tackle the authentication layer first. The problem is that once I've gotten authentication in place, my excitement for the project has faded because I wasn't working on the project itself, just trying to set up a login system. Meteor takes the work out of setting up authentication so that you can focus on more important things, like writing the core functionality for your app.

Our kids are still really young, but as soon as they are old enough to read and do some basic math, I’m planning to teach them how to write JavaScript. We will probably have a better setup than most people because I work remotely and we are planning to homeschool our kids. That will give me ample opportunity to work with them on a regular basis.

If you have ever wanted to listen for user events like pasting, copying and cutting on the clipboard, you will be glad to know that it's not that hard. As fate would have it, there is already an event for each of the clipboard operations.

In the old days, if you wanted to get up-to-date data from the sever, you would need to set an interval on the client-side and continuously make Ajax calls to see if new data was available. The problem is that the data was never exactly real time. It was just what had been fetched every fifteen seconds or so. If you pinged the server too often, you would create needless overhead and there may or may not even be new data for the client to consume. The problems with this sort of approach are obvious.

I previously introduced the Meteor framework and showed how to create a simple application. Today we are going to look a little deeper and explore how data works in Meteor. If that isn't enough to get you excited, let me give you a teaser - Meteor literally lets you save data on the client-side without having to deal with the internals of server-side code. Have I got your attention yet?

Test driven development (or TDD for short) is the practice of writing your unit tests prior to writing the code for your application. Already having your tests in place informs your software design decisions and serves as a way to determine whether your code is accomplishing what it is supposed to. The benefits of TDD are obvious, so why is it so hard to approach writing software this way?

When it comes to building applications quickly that share a ton of code between the client-side and server-side and that excel at real-time communication, there is nothing more awesome than Meteor. Meteor aims to remove all of the busywork from creating single-page applications, and it does a heck of a job at it.

One way to reduce the loading time of your website or application is to merge multiple images together into one large sprite. The benefit is that only one http request has to be made instead of multiple requests. Of course, managing a sprite image and the CSS that uses it can be a pain in the neck. That is where Compass comes in. Compass has a really cool helper that lets you import an entire folder of images and that it will automatically sprite for you.

Sublime Text is a really great editor for writing code. It is actually my editor of choice at the moment. One nice feature that comes with Sublime is the ability to specify a custom build type. Sublime comes with several built-in build systems, but I've recently discovered that rolling my own build system is really simple. Here is how I got Sublime to build my JavaScript and Node scripts using Grunt.

When I received a copy of Secrets of a JavaScript Ninja for my birthday, I was understandably excited. As a long-time user of the jQuery, I have a great deal of respect for John Resig, who is the lead developer and creator of the useful and popular library. It should be noted that this is not a book about jQuery. This is a book about advanced JavaScript fundamentals.

If you haven't been using Grunt to run your JavaScript tasks, you have definitely been missing out. Grunt is really great about automating tasks that would have been very tedious otherwise. One great thing about Grunt is the ability to run grunt watch to monitor your files and run tasks when they are changed. We can use grunt watch in tandem with compass to automatically compile css files on the fly as we change our SASS files.

When I first started moving my blog over to Poet, one of the most frustrating things for me was the fact that all of the blog posts are cached, meaning that every time you edit a file, you literally have to restart the server to see the changes. Luckily, I have implemented a neat little trick to refresh the blog posts any time they are updated.

If you haven't used Sencha Architect to build your Sencha applications, you are totally missing out. Sencha Architect is essentially a WYSIWYG editor that allows you to construct applications by dragging and dropping components into the stage area. Sencha Architect App Development from Packt publishing is a really helpful book that shows you how to construct an application in Sencha Architect from start to finish.

I have recently moved this entire blog over from using the Wordpress CMS to running on completely on Node. The library I eventually ended up choosing is called Poet.

If you've been creating applications using Node, you've probably fallen in love with the built-in package management framework "NPM". Using NPM makes life a ton easier because instead of needing to go out and download all of the third-party packages your project will need, you can just type a line or two in the terminal and everything is good to go. What if there was a tool like NPM for managing client-side JavaScript libraries? There is one. It is called Bower."

Sometimes when you are developing applications, it can be handy to know how long it takes for an operation to complete. For example, you might want to know how long an element takes to render or how long it takes for an Ajax call to resolve. Luckily, most of the modern web browsers have a console.time function that makes that easier.

Knowing what parts of your code to test can sometimes be tricky. If you have a large application, it can be challenging to know what has already been tested and what still needs testing. That is why the world needs JSCover.

Amplify is JavaScript component library from appendTo. It has a ton of useful features and one of them is the storage piece. If you have ever worked with storage in the browser, you probably know that there are various APIs and storage types with varying degrees of browser support.

When I first started writing Node applications, my main question was how I could keep the server running on a live server.

The answer I finally discovered was Forever. Forever is a CLI tool that keeps a node process running indefinitely. That means that you can ssh into the place where your code is hosted, start the server with Forever and then close your ssh connection and the server will still be running. It is a thing of beauty.

This year, I started a vegetable garden in my front yard. There are several reasons I started it. We are trying to get out of debt, but I still want my family to have nutritious food that isn't full of deadly chemicals. I also think that skills like being able to grow your own food could become really valuable in the coming years of inflation that the Federal Reserve has set us up for in the United States.

Internationalizing an application can be a tedious process if you are translating your app into different languages manually. Every time you add a new value to be translated, you have to add that value for all of your translation files. It can become a real pain.

Testing is really important when you write software. That is a fact. But the real question is what you should test. The simple answer is "everything possible."

This is entirely experimental, but I've created a purely JSON-based templating system called jQuery.jsonTemplate.

The idea is to have a completely JSON-based nested markup language that compiles to HTML and back again.

Software development is a really exciting field to be in. Technology is constantly changing and improving. The demand for people who can read and write code is constantly expanding. The laws of supply and demand work in the developer's favor since all of the companies are forced to compete for the limited number of people who can write code well.

If you're going to be in Nashville on May 21 at 6:00, stop by the Interactive Developers meetup at Vaco to hear me speak about the Compound MVC framework for Node. There is always free food and drink. You can RSVP here.

I have recently been diving into Creating Mobile Apps With Sencha Touch 2 and I have really been enjoying it.

As someone who worked with Sencha Touch when it first came out, it has been fun to watch the steady improvements that have been added over time to make Sencha Touch 2, so I was doubly excited to have the chance to review this book.

The Sencha Touch data model makes working with data really easy. One of the coolest things that the data model provides is an abstraction layer for HTML5 local storage. There are several types of local storage out there right now and they enjoy varying degrees of browser support. Sencha Touch opts for the simple key-value storage because it is supported in basically every relevant browser today.

Knockout JS is a fairly simple MVVM framework that aims to make data binding easier.

The cool thing about Knockout is that you can essentially subscribe an element to a piece of data. When that data is updated, the DOM magically updates as well. To be more precise, its not really magic that's happening... it's JavaScript.

One of the most useful CompoundJS plugins is Compound-Passport. If you aren't familiar with Passport, it is an authentication library for Node that provides a common API to authenticate with Facebook, Twitter, Google, Github and over a hundred other OpenId and OAuth login sources.

Functional testing the DOM can be a daunting task. Tools like Qunit and Mocha make it easier, but the real trick is automating the testing process from the Terminal so that it can run continuous integration in the background and throw errors when a test fails.

If you aren't familiar with it, the NodeJS version of the Selenium WebDriver is a great way to write functional tests in JavaScript and automatically run them in your browsers.

Previously, I introduced you to Compound, an awesome MVC framework for NodeJS. Today, I am going to expound on how the routing works in Compound.

If you are not familiar with how MVC work, I suggest you take a look at some of my older articles about JavaScript Architecture and Code Separation. From here on, I will assume that you have a basic understanding of the place of controllers in the MVC paradigm so that the routing will make sense. Let's begin.

I've been a huge fan of Apple since college. What's not to love? The user interface is clean and intuitive, the shell is based on Linux, which makes it easy to use and Macs hold up really well to both wear and tear and malicious software.

NodeJS may still be young, but there are already several MVC frameworks popping up to run exclusively on Node. My favorite is CompoundJS.

Anvil.js is a powerful "Convention over configuration" build tool that was built by Alex Robson and sponsored by appendTo, which is incidentally where I work now.

JQuery comes loaded with various utility methods that make manipulating elements and data easier. One really useful method is jQuery.map().

A few years ago, I was working for a small startup in the financial industry. We were working against time to get an application finished before the dwindling money supply was depleted. In the end, we were not able to meet our mark. However, during my time there, I became known as "the Machine" because of my intent focus on our work.

I have several Wordpress websites that I've designed and developed. Perhaps a little known secret is that I have all of the sites hosted inside a single Wordpress installation instead of hosting a completely unique installation for each site. Sharing a common code-base for the heavy lifting has some great benefits.

BackboneJS is a great framework for building large scalable JavaScript applications. One of the best things about Backbone is that the community has built countless amazing plugins that extend the Backbone namespace. I've compiled a list with just a few of my very favorite Backbone plugins.

The release of Node.js in 2009 ushered in discussions about the endless possibilities for sharing code between the client-side and the server side. While there are several good examples of entire libraries working very well on both ends, most of the projects that are written in Node tend to shy away from sharing the meat of the application with the browser. I think that the real issue is developers being stuck in our ways. We are trying to write traditional web apps in a language that can actually go beyond what traditional scripting languages were even capable of.

JavaScript is different from other programming languages because it is asynchronous. That means that there is a possibility that several things can be happening at the same time. In other words, JavaScript doesn't wait for one thing to execute before going to the next. If you are waiting for a timeout to fire, or a response from an Ajax call or a database transaction, while the process completes, JavaScript silently moves on.

Another year has come and gone and it is now officially 2013. I guess the Mayan Apocalypse didn't happen after all.

I've always been a big advocate of making goals and this year is no different. Goals help you plan out your future and enable you to break down big things into smaller pieces that are more easily finished.

Before I left Moontoast last month, they worked with me to open-source a HTML5 canvas jQuery charting library I created for their internal analytics tool. I wrote a blog entry for their developer blog introducing jQuery ToastChart. I thought you might be interested to see it.

I've been using a standup desk for nearly a year now. It all started when I discovered this infographic.

Up until last week, I was working at Moontoast where I had set my Ikea desk on top of four cinder blocks to make it standing level. This week, I started working at appendTo, which means that I'm finally able to work from home.

I've recently been working on a JavaScript API that interfaces with a REST-based server-side API and handles cross-domain issues while still allowing GET, POST, PUT and DELETE methods to be fired from anywhere on the web. Due to cross-domain security issues at the browser level, making POST, PUT and DELETE requests can be a lot harder than you might think.

I've been working on several projects in the past year or so that have required me to write some jQuery plugins and custom JavaScript widgets and I feel like several of them could definitely be useful for other developers. I've set a goal this year to release at least two projects to the community, but it's tough to know which ones people will find most useful. Since it takes a little work to get a library to a place where it works under multiple scenarios and that's even before the lengthy process of writing documentation, I thought I'd put it up to a vote to see what people would like to see and use. Whatever seems to have the most positive attention is what I'll probably end up open-sourcing first.

A few days ago I realized that I read a lot of books and articles about JavaScript and web development and that this would be a good place to share my thoughts about them both for my own reference and maybe even for helping other people out. In the interest of that revelation, I present to you a quick review of HTML5 for Web Designers by Jeremy Keith of A Book Apart.

As a JavaScript developer, I tend to spend a lot of time getting and setting data using a server-side API. Over the past few years, I've encountered all sorts of APIs and I've formed some opinions on what makes a good API for JavaScript interaction. Here are some of my thoughts.

Most of us can agree that spawning popups with JavaScript is usually a user experience FAIL. We've all been to websites that opened several popup ads. That is always something to avoid. Malicious and ad-happy sites have made it necessary for browser plugins and some browsers to block JavaScript popups altogether.

This is something that I have been trying to make up my mind on over the past year and a half at least. The question? Do JavaScript libraries need an abstraction layer?

Just to clear the air a little before we jump into the discussion, if you are making a small website, this doesn't apply. I'm talking about large, scalable JavaScript applications.

I tend to fall in with Coldfusion programmers from time to time and while I actually really like the language and the community, the one thing that can make working with Coldfusion and JavaScript harder is how the language returns JSON.

I've recently been thinking about what it would mean to emulate the MVC best practice of skinny controllers that started in the confines of server-side development within the much more glamorous language and beautiful JavaScript. For those of you who haven't read some of my previous posts, I am a huge advocate of using Model View Controller architecture in client-side code as well as on the server-side. I've written in depth about what MVC looks like on the client-side, so I won't bother to delve into that explanation here.

A few weeks ago, I started using SASS. What is SASS? It's an acrostic that stands for "Syntactically Awesome Style Sheets." SASS is run from the command line and essentially lets you write stylesheets with things like variables, nesting and mixins (which are pretty much the equivalent of the functions in a real programming language).

Has anyone ever told you that your application is too slow? What can you do about it? You can always point the finger at the server-side people and mumble something about the database being the problem, but is there anything you can do to speed up the loading time? Can you speed up the browser's reaction to user-activated events?

Several months ago I wrote about event binding using ExtJS or Sencha touch. Something that you may or may not know is that you can achieve the same thing with jQuery using custom even binding.

We now have HTML5 and CSS3. Browsers are still racing to actually implement them, but the specs are here, whether they are fully realized in the wonderful world of browsers or not. So the real question becomes, what should we do with the knowledge we have of things to come?

Having worked on several large scalable JavaScript and Ajax application over the past couple of years, I've started to form a definite opinion about what an application needs in order to be truly scalable and ultimately successful. So what does your application need?

It's no secret that web developers don't lead a very active lifestyle. In fact, from the day I entered college until a couple of weeks ago, I had gained almost 25 pounds thanks to my lack of activity and disregard for the effects of food on my body.

I recently had the need to override all of my links on a Sencha Touch app with an onClick event. I needed to be able to open the links using the ChildBrowser plugin for PhoneGap. The problem was that I needed to grab the links before I rendered the content to the page and apply the onClick event instead of the href.

For some reason, I keep watching episodes of a television show called "Hoarders." If you haven't seen it, it's about people who collect stuff. Collecting stuff is one thing, but these people have no organizational system for the items that they collect. They literally have piles of so much useless junk that their houses become essentially unlivable. Many of them don't even have a single walkway to navigate through their homes. They could lead better lives, but they are unwilling to let go of their material possessions.

Last night, I finished re-doing the mobile version of this site using jQuery Mobile. The only other mobile JavaScript library I have worked with so far is Sencha Touch and I must say, they are vastly different. My prognosis? If I am going to make a mobile version of a website, I am going to use jQuery Mobile. If I am going to make a "native" mobile application, I will be more likely use Sencha Touch.

JavaScript is a loosely-typed case sensitive language. Technically everything in the language is a variable. Yes, it may be a string, a function, an array or an object, but everything is a variable at its core. Because you can make your variables all lowercase or all uppercase or anywhere in between, it’s important for the sake of code readability to have a pattern for how the variables will be cased.

There has been much discussion in the JavaScript community about JavaScript loaders, whether they are needed, what they do and whether it should be a function of the browser. I figured while there is so much buzz around the topic, it's a good time to put in my own thoughts.

I'm thinking about putting my series on application architecture in EXT and Sencha on hold for now because the Sencha team has announced their plans for EXT 4.0 which looks like it will include a very nice MVC framework built in.

This post is directly related to my previous post on MVC and EXTJS. If you haven't read it yet, I'd suggest that you take a look at it before diving into this one.

If you haven't seen any of the rich interfaces that have been built with EXT JS and Sencha Touch on web applications, Adobe Air applications or native smart phone apps, you will. The Sencha family gives us everything we need to build large applications, but it doesn't limit us on how we can write them.

So, I recently was working on a project using Sencha Touch and Phonegap to create an iPhone App and everything worked perfectly when I was using the emulator for the iPhone 3, but when I emulated it for the iPhone 4, it wouldn't load anything at all. The solution? Apparently, the DOM was still rendering when the Ext.onReady block was firing because the iPhone 4 was not properly using the Ext.onReady block.

When I started writing JavaScript (and code in general, for that matter), one of toughest things for me to wrap my head around was what variables and functions I could access from where.

If you're like me, you are constantly looking for better ways to architect your JavaScript applications to be scalable and modular. One of the keys to writing an application that fits the bill is to use reusable components that, instead of calling other functions or components directly, broadcast events that multiple components may be listening for. I've been on a hunt to figure out how to do this correctly for a while now and I've finally come upon a few good solutions.

There are literally tons of JavaScript frameworks out there to ease the pain of website and application development. Obviously, the most popular one out there right now is jQuery, but that is not to say that there are not other libraries out there. So the question becomes, should developers use libraries or is it just a crutch that keeps them from learning real JavaScript? Here are some thoughts on the subject.

Ajax is awesome for things like rich internet applications that don't require SEO because of their internal nature, or for on-page events like form validation and submitting, but from an SEO standpoint, adding content to the DOM is illegible. But you still want the increased usability of not having to reload the page every time an element or two is changed, right? The fact is that users don't like waiting on your page to load, and the more you can do to keep from reloading the whole thing, the better. But still, there's the problem of JavaScript DOM manipulation not jiving with Search Engine Optimization. What's a person to do?

Nearly a year ago I was working for a company in the financial services industry that had need for a scalable, secure, AJAX application. It was extremely large in scale and scope and it quickly became clear that I was going to have to have some sort of organizational structure to build the application upon. My server-side experience at this point was primarily in writing C#, and I had fallen in love with the organization of the .NET MVC design pattern. From there, I had been doing some contract work using CakePHP, which is also an MVC framework. While I had written JavaScript for my websites, an entire application is completely different. I looked around at frameworks and eventually settled on JavaScript MVC for its basis in the MVC framework as well as its rich feature set. So what does JavascriptMVC come with "out of the box?"

As the web has grown, the Javascript programming language has grown with it to become rich and robust. Whereas websites used to have only a couple of lines of Javascript code used in them, Javascript has evolved to a point where it often does a large part of the heavy lifting in Internet Application development. With the evolution of Javascript, the code typically used on a site can often grow to a point where it is bulky hard to maintain if it is not properly constructed. That's why the topic for today is on how to architect Javascript in such a way to make it easy to maintain. Javascript is a programming language, after all, so we should treat it with the same care and respect we would treat server-side code.

If I haven't said this before, I am seriously planning on showing more code in some of my post in the near future. This one is slightly related to my previous blog entry, What is UI / UX? but I will be more focused because I'm just going to be talking about how links relate to user experience on websites. First, we'll take a history lesson.

When I tell people that I'm a User Experience / User Interface Developer, I tend to get a mixture of people who say "you make website, I can't event check my e-mail" and people who aren't exactly sure what it means to be a user experience designer. My goal through this blog is to tackle some of the relevant issues pertaining to web usability, and user experience as well as sharing some client-side and possibly a little bit of server-side code that can help other people who are trying to create user friendly websites. Since that is my ultimate purpose here, I feel like I need to lay some groundwork by explaining what User Experience Design and what User Interface Development actually entail. This is just laying down the tracks for some more in-depth discussion down the road, but we've got to start somewhere, right? Let's jump into it.

SEO has been a hot topic especially in the last few years as the number of websites on the Internet has increased and being easily found on most search engines has been increasingly difficult. Everyone who has a website is looking for ways to make their site more accessible to Google and other modern search tools, so what are the basics? How can you take your website and bump it up in search engine rankings? Here are some clues.

A couple of years ago, if you had asked me what my take on design patterns for internet applications was, I would have probably given you a blank, questioning stare. You see, as sad as it is, proper design and architectural patterns aren't exactly the norm in the web development world. Today, I'm going to give you a quick overview on what architectural design patterns are and why they're important and then focus in on MVC.

Microsoft released Internet Explorer 6 nearly eight years ago in August of 2001. Since then, they have released two new versions of their web browser, IE7 and IE8 and have officially stopped supporting the outdated cousin, IE6. So why is it that most web developers are still supporting a browser that even Microsoft itself has turned its back on?