JavaScript for Line of Business Applications

We started building Flight.js at Twitter back in 2011 as a component-based framework. Two and a half years later, with the whole of twitter.com now running on Flight, how do we feel about Flight and mixins? Are they working for us?

Rather than using the classical talking animals to describe our components, I’ll try to use real-life twitter components, though I’ll be dramatically simplifying for readability.

* Precedence

* Inheritance

* Modularity

* Attributes

* Summary

One of the reasons AngularJS is so great to work with is that it was developed around the idea that testing is so important that it should be built into the framework. Every check-in of the Angular source is tested before it’s accepted into the core.

Testing is incredibly important, especially in a dynamically typed environment like JavaScript. It gives us the opportunity to catch errors before they happen in production. Testing code allows us to be confident about the production value of our code.

As bugs in our code, or any code, are inevitable, it’s important for us to be able to determine where they are and try to eliminate them before they show up in production. Using testing, we can isolate these pieces of functionality in a test environment where we can understand our app from the inside out.

Testing is essential if we are to understand what is happening in our app.

In this article, we’re examining how to test our application using end-to-end testing. End-to-end testing is black box testing. We are testing that the system works as planned from an end user’s perspective.

An end user doesn’t care if a service works as planned; he or she cares that the functionality of our app works as expected. We can think of it as a way to automate starting the app in our browser and clicking through the workflow of the application.

It would be inefficient for us to click through the application manually, so we’ll script our tests to happen automatically.

One of the many ways in which EmberJS, AngularJS, and BackboneJS differ is in how they treat their models. AngularJS uses dirty checking on Plain Old Javascript Objects (POJSO); whereas EmberJS and BackboneJS both use accessors (getters and setters) on wrapped objects.

We will be exploring the ways in which these two approaches differ, and the implications these differences have when it comes to choosing which Javascript framework we we should write our single page apps in.

How to use Ember.js components in general and how to re-use them through inheritance to extend certain behaviour without repeating yourself.

One of the nicest things about Ember.js are components. It’s very easy to create reusable, self-contained components. But reusable doesn’t just mean to reuse the component throughout an application, it also means to extend such a component. Due to Ember’s inheritance model it’s pretty straight forward to extend an existing component to inherit behaviour and add new logic. 

Single-page web applications often turn into jQuery soup, where application logic, DOM manipulation, and server access are all mixed together. This mixing of concerns makes such applications harder to understand and test than they ought to be. Segregated DOM is a modularization tactic that separates all manipulation of the DOM into dedicated JavaScript objects.

The principal benefit of doing this is to make it easier to reason about each class by keeping it focused on a single task. When I'm working on the Filter DOM class, I concentrate on how to do the DOM manipulations on the HTML elements. When I work on the controller I can ignore the details of the HTML structure, css class names, and the like.

In more abstract pattern terms, these DOM objects act as Gateways, a passage between two BoundedContexts (the application and the HTML DOM). Like any gateway the DOM object has an interface that speaks the vocabulary of its client (the application) and an implementation that translates this into the barbaric (HTML DOM) land beyond.

The support for Accounts in the Meteor platform has left me incredibly impressed. Various accounts packages allow for the addition of account handling on the backend and on the user interface with minimal effort. Adding in support for popular authentication methods (such as Google, Facebook, Twitter, etc.) consists of adding a new accounts package.

To demonstrate, I’m going to take the simple chat application that I built in the Meteor Introduction post and extend it to use accounts instead of using a simple text input to specify the message user.

Meteor is one of a new breed of JavaScript frameworks changing the way we build web apps. Tom Coleman and Sacha Greif explain how to get started in building a simple forum.

Launched in April 2011, Meteor is a JavaScript framework that's part of a wave of tools ushering in a new way of developing web apps. You know the kind: you keep hearing about them and promise yourself you'll check them out, yet never find the time to actually dive in.

Luckily we're here to help you out. So follow along, and in less than 30 minutes you'll have Meteor up and running, will be playing around with its impressive real-time capabilities, and will finally know what all the fuss is about.

Durandal is a lightweight JavaScript framework designed to make building Single Page Applications (SPAs) simple and elegant. It has strong support for MVC, MVP and MVVM so that no matter what type of front end architecture you prefer, Durandal can handle the task.

With RequireJS as its base and a thin layer of conventions, Durandal can provide amazing productivity while helping you to maintain SOLID coding practices. Pair that with out-of-the-box support for rich UI composition, modal dialogs, eventing/messaging, widgets, transitions, routing and more....and there's no doubt you'll be able to build whatever apps you can imagine.

Unit tests can be great to verify your source code, but there are times when integration tests provide a more useful report on the stability of your application.  Yes, integration tests (most likely) require more setup than unit tests, and yes, they will (again, most likely) test things outside of the code you wrote.  But they also come with a huge upside in that they test what your customers will use — the end product stack.  And including integration tests in your continuous integration builds can track how that experience functions over time.  Successful integration tests provide you with a real sense that your application performs correctly from end to end.

Although there are many possible integrations to test within an application, I’d like to focus on testing at the UI layer.  Within the Node.js environment, there are (of course) many options available to you.  One of the more popular tools to assist in UI testing is PhantomJS.  PhantomJS is not, however, a test tool but instead a headless WebKit, and requires a testing framework which may need additional configuration.  In some cases this might be necessary, but in other cases, a simpler solution is all that’s required.  Zombie.js provides that with very minimal setup and an intuitive interface for your UI testing needs.

There are many things I like about Grunt, and many of them are still true.

I like that Grunt gives you the choice of being a Config file or just straight up JS (write your own functions using Node Modules).

I like that it had it's own API to do things and forced plugins to be written in a common way (much like jQuery) - this made it easy to A : Use plugins quickly; and B : Write plugins.

I like that it garnered a quick following and is now used by a lot of Open Source projects. This in no doubt helped spawn a metric-shitton of plugins.

But there was room for more. There's always room for more.

gulp.src takes a glob (a list of files) and then you just pipe them through plugins. This is the thing with Gulp, it's all about Streams. Just think of it like the chaining you do with jQuery.

I like Gulp a lot, it feels like discovering Grunt all over again. I like the way its code over configuration; don't get me wrong, I love the simplicity of Gruntfiles and I think it gives opportunities to those who wouldn't normally write their own scripts to assist with automation to dive in. I am also aware that with Grunt you can choose to have code over configuration.

Grunt and Gulp can co-exist to serve different groups of people, for now though, im sitting with Gulp. I can't wait to start doing more with it.

This is a series of posts about AngularJS and our experiences with it while migrating the client of a complex enterprise application from Silverlight to HTML5/CSS/JavaScript using AngularJS as a framework. 

I got some feedback from readers that they didn’t like that I never introduces how to implement a RESTful API which can then be consumed by an Angular application. I though that I should change this and have decided to publish this post where I show how a simple REST API can be implemented.