JavaScript for Line of Business Applications

Discover how to build a JavaScript application framework that scales for the challenges of today's complex web applications.

Angular JS is known for and is becoming increasingly popular due to its nature of testability. Angular’s in-the- box abstractions make any amount of code easily testable. Code written using Angular JS can be tested using any JavaScript unit testing framework out there, may it be QUnit, Jasmine, Mocha or some other library.

QUnit is a JavaScript unit testing framework developed by jQuery team. It is used in the projects like jQuery, jQuery UI, jQUery Mobile. QUnit is a very simple and generic framework that can be used to test any piece of JavaScript code. Unlike Jasmine, QUnit doesn’t have built-in support for creating spies. 

Sinon is a JavaScript library that makes the process of creating spies, mocks and stubs easier. It doesn’t depend on any other JavaScript library and easily integrates with any JavaScript unit test framework. Official site has a nice API documentation covering different features of the library. 

JavaScript’s implementation of scope and context is unique to the language because it is so flexible. Functions can be adopted for various contexts and scope can be encapsulated and preserved. These concepts lend to some of the most powerful design patterns JavaScript has to offer. However, this is also a tremendous source of confusion amongst developers, and for good reason. The following is a comprehensive explanation of scope and context, the difference between them, and how various design patterns make use of them.

Chaining Methods, also known as Cascading, is the technique of repeatedly calling different methods (or the same method) on an object in one continuous line of code. This technique is popular in jQuery and other JavaScript libraries, and it is even inherent in JavaScript’s native methods like the common String methods. It is just so lovely that we can’t resist making our own methods facilitate cascading.

We will learn that this technique is easy and effortless because it is rather straightforward to implement chainable methods in JavaScript. We only have to return this(the object we want subsequent methods to operate on) in each method. Let’s learn this baby quickly and get back to what we were doing.

In today's large Web companies, an increasing number of people are touching an increasingly large percentage of the front-end code. As a result, most organizations struggle to keep their code modular. Changes to one part of the application often inadvertently break unrelated parts downstream.

Preventing unintended consequences is not an easy problem to solve, especially since HTML, CSS, and JavaScript are, by their nature, co-dependent.

To make matters worse, traditional computer science principles like the separation of concerns, which have long been a part of server-side development, rarely get discussed when it comes to front-end code.

In this article I'll talk about how I've learned to decouple my HTML, CSS, and JavaScript. From my experience and the experience of people I know, the best ways to accomplish this are far from obvious, often counter-intuitive, and sometimes go against much of the so-called "best-practices" out there.

In this post, I’d like to show the differences between using an Angular.js factory to get local JSON data vs remote data via an AJAX call.

To make a HTTP call via an Angular.js factory, we need to pass the $http object into the factory and then make a call to the remote HTTP request using the $http.get() method.

In this example, you can see that the controller makes a request to the factory which then calls an asynchronous function ($http.get) to get the data. When this asynchronous function completes successfully, it calls back to an anonymous function in the controller and populates the view model.

We started our demonstrating the core components of the application and how to set up an AngularJS app. In the previous post, we covered the internals of directives in AngularJS.

In this section, we’ll tackle services, clean up our code, and finalize our audio player.

Throughout this tutorial series, we are building an NPR audio player that will show us the current stories on the showMorning Edition and play them in our browser. To see the fully finished demo, head over here.

Up until now, we’ve only concerned ourselves with how the view is tied to $scope and how the controller manages the data. For memory and performance purposes, controllers are instantiated only when they are needed and discarded when they are not. That means that every time we switch a route or reload a view (we’ll cover routing in the next post), the current controller gets tossed out.

Services provide a method for us to keep data around for the lifetime of the app and communicate across controllers in a consistent manner.

Ember and Backbone are both promising JavaScript frameworks but have completely different philosophies. In this post, I'll compare the two, both from a practical and philosophical perspective. I'll defer to real world experience with Backbone and SproutCore (Ember's predecessor), as well as basic experiments with Ember (full disclosure: haven't built a large Ember app yet).

So we have a roughly apples-to-apples comparison. Let me dive in and talk about some philosophical differences:..

Today we’re happy to announce the release of MacGyver, the duct tape and swiss army knife for AngularJS applications.

What is it?

MacGyver is an AngularJS module comprised of directives, filters and utilities for quickly developing your UI. It was built to meet the need for reusable components between multiple AngularJS applications.

What does it include?

MacGyver includes the following directives:

• autocomplete

• datepicker

• file upload

• menu

• modal

• spinner

• tag autocomplete

• tag input

• time input

• tooltip

- See more at: http://tech.shift.com/post/58726393361/introducing-macgyver#sthash.wdN5JTik.dpuf

JavaScript supports Object Oriented Programming but not the same way as other OOP languages(c++,php,Java,etc.). The main difference between these language and JavaScript is, there is no Classes in JavaScript where the classes are very impotent to create objects. But there is a way we can simulate the Class concept in JavaScript. 
Another important difference is data hiding. There is no access specifiers like (public,private,protected) in JavaScript. Again we will simulate the concept using variable scope in functions. 

1)Object
2)Class
3)Constructor
4)Inheritance
5)Encapsulation
6)Abstraction
7)Polymorphism

Brick is a bundle of reusable UI components created to enablerapid development of HTML5 apps. Brick adds new HTML tags- allowing developers to express the structure of an application in a clearer, more concise manner.

As developers we know that we should be keeping out code modular. That means if you’re using a library like Knockoutjs you shouldn’t put all your code in a single viewmodel.

So what if you need those modules to be able to communicate with each other? Typically you would use a PubSub type of structure to allow cross module communication but what if there was an easier way?

As I was developing in Knockout I thought, what if there was a way for me to specify a value on 2 different viewmodels that used the same observable value? So when one is updated, the other would get that message and automatically update and push changes to the view.

Well, it turns out it is easier than I thought. A few lines of code later and I had it. I’m calling the solution ko.public, and it’s available on GitHub under the MIT license. So go nuts, and enjoy!