JavaScript for Line of Business Applications

Or is it? Do you have an opinion?

I selected this title because that analogy helps me as I’m learning more about TypeScript. It has “truthiness”. But in a good way. It will help you understand the motivations behind TypeScript, and how its syntax and concepts relate to JavaScript syntax and concepts. 

It’s “truthiness”, because if you take that concept too literally, it breaks down. TypeScript makes some features easier than in JavaScript, but it doesn’t feel quite as revolutionary as the jump from C to C++ (or maybe I’m just older). TypeScript isn’t changing the techniques used in JavaScript, like the shift from procedural to object oriented programming from C to C++. It is making Object Oriented constructs easier, but they aren’t impossible in JavaScript.

Most Single Page Applications (SPA) written in HTML and JavaScript interact with server side code using the familar XMLHttpRequest object. During development it can be convenient to run the application with mock data that eliminates this server dependency. This can be useful if the server side stack is complex and not easy to set up on a local machine or if a shared dev server running the server components suddenly goes offline. It’s also handy for tweaking the data returned by the services to ensure the UI behaves appropriately in specific scenarios. Naturally it’s imperative to integrate the SPA with real server code early and often but the flexibility provided by the “server mock” technique can be indispensible.

Note: while this article will illustrate how to mock services in an AngularJS application, this pattern applies to any UI technology (JavaScript or otherwise). The key is achieving Separation of Concerns (SoC) that allows real services and mock services to be easily swapped.

In the course introduction we look at what Knockout.js is, what architectural pattern it is built on, and how it can help us rapidly develop sophisticated, interactive user interfaces that don't turn into a tangled mess of event handlers. We also set up our development area ready to start coding in lesson 2.

In lesson 2 we add the wrapper for our app and see how easy it is to create a simple constructor for our application that accepts configuration options and supports chaining. We also saw how to use jQuery's extend method to merge the configuration object with the default properties of the application.

TBC

Whenever I write JavaScript I throw all software craftsmanship discipline out the window. There are no unit tests and very little structure to the code. It's just me and the browser refresh button until we get it right. If you are lucky you may have jQuery to provide a nice CSS selector based api that somewhat shields you from browser quirks. Maybe you even kept your project from devolving to the point where every page is basically its own JavaScript app with no hope of reuse between them. Even then JavaScript is still likely a second class language in your project. Surprisingly, this state of affairs is normal. I want to take my client side scripting just as seriously as any other code in my Grails web app. I want tests, structure, and less boilerplate, and I am going to use AngularJS and CoffeeScript to do that.

One of the hottest web architecture trends today is Single Page Apps or SPA. This architecture eliminates the traditional request response model the classic web was built upon. Instead it requires only a single page be retrieved from the server. Subsequent views (analogous to traditional pages) are brought in and out of view as needed. The SPA architecture relies heavily upon AJAX requests to pass JSON objects to and from the server to the client to merge with views that present data.

The benefits of a SPA include much less network activity, faster responses to user interactions, smaller server loads. It also makes it possible to use fancy view transitions, which give the appearance of a native application.

SPAs are a very new technique and often leave developers confused and looking for best practices. Traditional techniques and architectures no longer apply to web development and need to be replaced with a new way of thinking as well as learning how to use JavaScript and HTML5 features effectively.

* Client-Side Routing
* Markup Management
* Data Retrieval And Storage
* Using WebStorage To Persist Data
* Deep Linking and History Management
* Conclusion

A few tips and libraries for creating and documenting RESTful APIs with Express.js.

These days I spend more time using Express for APIs that send nothing but JSON. In this post I’ll cover a few libraries and reminders to help keep your code organized and your API friendly for developers.

I’m assuming an API backed by MongoDB, and that we’re using Mongoose. Covering the basics of Mongoose is beyond the scope of this article, but I want to highlight a few lesser-known bits.

In part 2 of Backbone.js Deconstructed, we will be examining the meat of Backbone. The meat being Backbone, views, models, and collections. Equipped with the knowledge conveyed in part 1, you should be adequately prepared to get intimate withBackbone.View, Backbone.Model and Backbone.Collection constructors and corresponding object instances. Before we begin, I am going to lay out my strategy for discussing the meat.

While it is common that most efforts to teach Backbone start with learning about models, I actually think this prohibits learning. I believe once the peripheral parts are understood, the easiest path for grokking Backbone starts with the view. I strongly suggest a mastery of views before you attempt to populate a view with data (i.e. models or collections of models) and eventing the view to stay in sync with the data. The plan is to first examine views, then models, then collections in that order. Once each of these parts are understood, we will take this knowledge and use it to examine a small and contrived contact's application. Don't be afraid to examine the application first, In fact I recommend it, as it will give some a helpful context before reading sections 2, 3, and 4.

1 - Article Overview
2 - Backbone.View
3 - Backbone.Model
4 - Backbone.Collection
5 - Building A Simple Contacts Application
6 - Conclusion

JavaScript libraries such as jQuery serve a great purpose in normalizing cross-browser behaviors in the DOM in such a way that it’s possible to use the same interface to interact with many different browsers. But they do so at a price. Part of that price, in the case of some developers, is having no idea what the heck the library is actually doing when we use it.

Heck, it works! Right? Well, no. You should know what’s happening behind the scenes, in order to better understand what you are doing. Otherwise, you would be just programming by coincidence.

In this article, I’ll explore some of the parts of the DOM API that are usually abstracted away behind a little neat interface in your library of choice, including Ajax, events and DOM querying.

* Meet: XMLHttpRequest
* Event Listeners
* Event Delegation
* Querying the DOM
* DOM Manipulation
* Conclusion

The first part of any Ember project is to get the basic up and running. Since this is a super basic example we are just going to wire up a Go server to serve our static assets.

Now that we have a basic http server we can setup our Ember environment.

I have included a script that will grab jQuery, Handlebars, and Ember for you. These are all the dependencies that you need to get the project up and running.

Now we can actually create our ember application. The canonical example name space is App, but you can use any name that you would like.

This line of code bootstraps your Ember application. It will automatically run once the page is loaded.

Let’s create our kittens endpoint. First we are going use the super excellent Gorilla web toolkit’s mux for routing. I prefer to have my api endpoint under an /api name space. This is not a requirement, but a personal preference.

Both ES6 generators and node-fibers can be used to block a coroutine while waiting on some I/O without blocking the entire process.

This means that you can wait for an I/O result within your code but still have the performance benefits of the single-threaded, non-blocking I/O model you all know and love.

Both can do this for arbitrarily deep call stacks. The main difference between the capabilities of the two is how explicit the syntax is. It's the classic battle between wanting to be safe while wanting to be flexible.

Deciding mid-stride to adopt a JavaScript application framework exposes many difficult decisions. What should be targeted first? How does one deal with untested, legacy code? It can make transitions a scary, tedious process.

At Viget, we've found Backbone to be a great tool for bolstering existing code with greater structure and functionality. With an active community and a number of superset frameworks (such as Thorax and Marionette), it gives us flexible tools to tackle current problems with an outlet for more elegant solutions down the road.

We've started to trend towards a series of steps that help to translate code over in a safer, more testable way.

* PULL HTML CONSTRUCTION INTO A TEMPLATE
* BREAK OUT DATA PROCESSING
* FINISHING THINGS UP WITH BACKBONE.VIEWS

Given this natural hacker-reflex to probe and tinker, it is odd how little I knew about Git until recently. Perhaps my daily life is so reliant on Git not failing to do its job, that I don't want to poke around lest I find a flaw. Until now I have been content with kicking the tyres and going for a spin around the block, rather than dismantling that mysterious .git directory. Nevertheless, I recently became curious and dug in. I was thrilled to discover that Git is even more beautiful internally, than it is functional externally.

At heart a Git repository is a key-value object store where all objects are indexed by their SHA-1 hash value. All commits, files, tags and filesystem tree nodes are different types of objects living in this repository.

When an object is added to the repository it is hashed, and from then on it is referred to by its SHA-1 hash value. Effectively a Git repository is a large hash table with no provision made for hash collisions. Luckily, with SHA-1 the probability of hash collisions is so vanishingly small that it is nothing to be concerned about.

To see an example of some simple objects, initialise a super-simple git repository with the following commands...