Free Front-End Books and Courses

With the pace of change in our field, keeping up to date as a developer is always an ongoing challenge, especially given you likely have a job to do and also want to maintain some semblance of a personal life. Myself, I tend to do a lot of reading on the bus to and from work–to the point I won’t now work any place where the commute will involve driving–as well as working on personal projects or courses after the kids go to the bed in the evening. As such, I’m always on the look out for new reading material, especially regarding advanced JavaScript, CSS, and modern design patterns and methodologies. Following are a number of resources I’ve found that contain relevant and timely front-end material, are of high quality, and are free.

Syncfusion is currently offering over 40 technical books of 100+/- pages each, in PDF and MOBI formats, via a “Succinctly” series, here: And don’t kid yourself, these are quality books. For example, the JavaScript Succinctly book is written by Cody Lindley, and contains much the same material you will find in his highly rated JavaScript Enlightenment book. Beyond the JavaScript book, other relevant topics include, jQuery, KnockoutJS, AngularJS, Bootstrap, and Node. I personally found the Knockout.JS Succinctly book quite useful, and if you combine that with Ivaylo Gerchev’s series on Knockout, then you will have a very solid foundation from which to work from. One word of warning: you are asked to provide some contact information in order to download the books, and you may receive a marketing call. There are no obligations, however.

Moving on… Marijn Haverbeke’s Eloquent JavaScript is one of the very best introductions to the language you can find. And very recently the second edition of this book has been made available for free! Find it here:

I have taken a number of paid online courses, some of them well done (such as the some of the courses you will find at ed2go) and some of them taught me a different lesson than I expected. Aquent Gymnasium offers free online courses, focused on UI/UX, that are as well done, or better, than any of the paid courses I’ve done: The course on responsive web design goes into a lot of detail, and is extremely well done. They also have offerings on jQuery, Bootstrap’s grid layout, and Node.js, amongst others. If you do well in one of their courses, you may be encouraged to consider working for them. No obligations, of course.

And finally, while more Computer Science oriented than focused on front-end development, you can find a number of free university courses online, as well: Amongst these you will find courses on Android programming and Python.

And that’s what I have in my list, thus far, for material that meets the following threshold: either a book or course related to front-end development, is of high quality, and is free. If you know of additional material out there that you believe meets these bars, please do share in the comments section.


Simple Implementation of a Protected ObservableArray in KnockoutJS

Recently I worked on an exercise building the UI for a table grid-based app,  where you can click on a row to reveal an edit view that presents the record in more detail.  For the bindings, I utilized knockout.js (note this article assumes some basic understanding of how two-way bindings are implemented using knockout).

table grid
The Table Grid
edit record view
The Edit Record View

As part of the exercise I was aiming for usability. And in line with that, it struck me that if you happen to be in the edit view, edit a number of attributes, and then realize you made mistakes, that you should be able to revert back to the original data. Problem is in knockout.js, the bindings done with Observables and ObservableArrays update your viewmodel immediately, leaving you with no way to revert short of another request to the server.

Google to the rescue.  I found this exemplary Knock Me Out blog post by Ryan Niemeyer on how to handle committing or resetting edits on Observables.  I’m hardly one to be above borrowing code from those more talented than myself, so I incorporated it and found his protectedObservable to work fantastic … at least for attributes that would normally be observables.

But I also had a number of observableArrays, and these are where the rollback functionality is especially needed, as relying on a form reset wouldn’t help us with deleted array elements.  Some more googling and I found this jsFiddle, also by Ryan, and I thought I was golden.  Turned out my joy was premature as it didn’t work for me, though this was through no one’s fault but my own.  If I had read his comments more closely I would have seen it was designed to work only with observableArrays of primitive types.  My observableArrays contained objects which themselves contained observables and observable arrays (which, in turn, contained objects).  So I had, at hand, what I thought was a more complex issue.

But the solution turned out to be quite simple!

Basically, I just made a shallow copy of the initial array that we would keep around for the case we want to rollback, and attached “reset” and “commit” functions to an observableArray to create our “protectedObservableArray,” keeping the same interface that Ryan implemented.  Reset basically works by clearing our observableArray, then iterating through our copy of the array, calling .reset() on any elements that have such a function, and pushing those elements onto the observableArray.  Commit is similar in that you iterate through the elements in the observableArray and call .commit() on the element if the function exists, and then resetting our rollback array to a shallow copy of the array underlying our observableArray.  Easy stuff!

//allow commit/reset functionality on an observableArray
ko.protectedObservableArray = function protectedObservableArray(initialArray) {
  var m_rollbackValue = initialArray.slice(),
      result = ko.observableArray(initialArray);

  //commit result values
  result.commit = function () {
    var x,

    for (x = 0, len = result().length; x < len; x += 1) {
      el = result()[x];
      if (el._destroy) {
        el._destroyCommitted = true;
      } else if (typeof el.commit === 'function') {
    m_rollbackValue = result().slice();

  //reset to rollback values
  result.reset = function () {
    var x,

    //clear out underlying array in observable
    result().length = 0;

    for (x = 0, len = m_rollbackValue.length; x < len; x += 1) {
      el = m_rollbackValue[x];
      if (typeof el.reset === 'function') {
      if (el._destroy && !el_destroyCommitted) {
        el._destroy = false;

  return result;

But there’s always a “but.”  In this case, this protectedObservableArray works fine if all its members are either protectedObservables or protectedObservableArrays. But what if we want our arrays to contain more complex objects whose members, in turn, could be protectedObservables, protectedObservableArrays, or additional objects?  These objects do not have any reset/commit functionality, and in turn, these objects’ members will not have their reset/commit functionality triggered.  Allowing our arrays to contain members that are not primitives was the whole point of coming up with this protectedObservableArray implementation, in the first place.

One approach would be to iterate through all the members of any object, and if said object has an own property “commit” (or “reset”) that is of type “function”, then call the function.  The issue with this approach is we’re going to end up having to handle nested objects, not to mention having to handle objects we don’t want to check (such as functions), and this code is going to become ugly pretty fast.  (But feel free to take it on, if you so desire).

I took what I think is a more elegant, and easier, approach that involved making available the ability to extend our objects with reset/commit functionality.  .reset() would iterate though the members of the object and call their .reset() functions (if they have one), and like-wise for .commit().  Any nesting of objects becomes irrelevant as our “protected” objects share the reset/commit interface the other protected members have.

The code, encapsulated in a constructor function I added to the ko namespace, ended up like this:

ko.ProtectedObjectExtend = function ProtectedObjectExtend() {
  if (!(this instanceof ko.ProtectedObjectExtend)) {
    return new ko.ProtectedObjectExtend();

  this.commit = function () {
    var prop;
    for (prop in this) {
      if (this.hasOwnProperty(prop) && typeof this[prop].commit === 'function') {

  this.reset = function () {
    var prop;
    for (prop in this) {
      if (this.hasOwnProperty(prop) && typeof this[prop].reset === 'function') {

Now, for any object type we want to have this functionality we can either set or extend its prototype with an instance of ko.ProtectedObjectExtend, or in the case of an object instance we can extend that instance:

//set prototype of object type
MyClass.prototype = new ko.ProtectedObjectExtend();

//extend prototype of object type
MyClass.prototype = $.extend(MyClass.prototype, new ko.ProtectedObjectExtend());

//extend object instance
myObject = $.extend(myObject, new ko.ProtectedObjectExtend());

The only issue with this approach is our objects cannot have members called reset or commit, else only one version of the member will survive the extend call.  So design your objects with that in mind.

And that will do it. If you go back to the demo I built––you can see it in action on the edit view. Try clicking “Cancel” to undo any changes, and clicking “Save” to commit changes. (Re-click “edit” to return to the edit view and see if it reset or committed as expected).

I’ll be checking this code into my GitHub in the coming days, but in the meanwhile I would appreciate any feedback or questions.