Wednesday, April 1, 2015

HP Software Targets Mobile App Developers

 HP has announced the launch of its new software Mobile App Developers The company is targeting mobile app developers with the launch of several pieces of software aimed at improving the quality of software.

HP, Mobile App Developers, Mobile App Developers,  mobile app , testing mobile programs. , software releases , HP Haven analytics, HP security software and elegant SaaS-based interfaces. ,  Network Virtualization and Service Virtualization software

App Pulse Mobile monitors the performance of apps, an update of the project manager Agile and an overhaul of the Mobile Center, a suite for testing mobile programs.

The latest software releases are designed to address the challenges of mobile application development across the development lifecycle by combining its tools for application development testing, monitoring and systems management with HP Haven analytics, HP security software and elegant SaaS-based interfaces.

Together, these capabilities result in solutions that help make designing, delivering and managing mobile applications an intuitive, collaborative process. Businesses can use HP's solutions to accelerate application delivery and to test and monitor apps across multiple devices and operating systems.

The service also features the Fundex, which is a score related to how enjoyable the application is to use. The score starts at 100, and an app loses points for various transgressions, such as crashes and sluggish performance.

The company has also released updates to its Network Virtualization and Service Virtualization software, which will help driving the development on the mobile. It has also integrated its Application Lifecycle Management tool with the software security program Fortify, allowing customers to test the security of their mobile apps, which remains a big concern in the cybersecurity industry.

Sushma rani, EFYTIMES News Network 

Dismantling invokedynamic

Many Java developers regarded the JDK’s version seven release as somewhat a disappointment. On the surface, merely a few language and library extensions made it into the release, namely Project Coin and NIO2. But under the covers, the seventh version of the platform shipped the single biggest extension to the JVM’s type system ever introduced after its initial release. Adding the invokedynamic instruction did not only lay the foundation for implementing lambda expressions in Java 8, it also was a game changer for translating dynamic languages into the Java byte code format.

While the invokedynamic instruction is an implementation detail for executing a language on the Java virtual machine, understanding the functioning of this instruction gives true insights into the inner workings of executing a Java program. This article gives a beginner’s view on what problem the invokedynamic instruction solves and how it solves it.

Method handles

Method handles are often described as a retrofitted version of Java’s reflection API, but this is not what they are meant to represent. While method handles can represent a method, constructor or field, they are not intended to describe properties of these class members. It is for example not possible to directly extract metadata from a method handle such as modifiers or annotation values of the represented method. And while method handles allow for the invocation of a referenced method, their main purpose is to be used together with an invokedynamic call site. For gaining a better understanding of method handles, looking at them as an imperfect replacement for the reflection API is however a reasonable starting point.
Method handles cannot be instantiated. Instead, method handles are created by using a designated lookup object. These objects are themselves created by using a factory method that is provided by the MethodHandles class. Whenever this factory is invoked, it first creates a security context which ensures that the resulting lookup object can only locate methods that are also visible to the class from which the factory method was invoked. A lookup object can then be created as follows:
class Example {
  void doSomething() {
    MethodHandles.Lookup lookup = MethodHandles.lookup();
  private void foo() { /* ... */ }
As argued before, the above lookup object could only be used to locate methods that are also visible to the Example class such as foo. It would for example be impossible to look up a private method of another class. This is a first major difference to using the reflection API where private methods of outside classes can be located just as any other method and where these methods can even be invoked after marking such a method as accessible. Method handles are therefore sensible of their creation context which is a first major difference to the reflection API.
Apart from that, a method handle is more specific than the reflection API by describing a specific type of method rather than representing just any method. In a Java program, a method’s type is a composite of both the method’s return type and the types of its parameters. For example, the only method of the following Counter class returns an int representing the number of characters of the only String-typed argument:
class Counter {
  static int count(String name) {
    return name.length();
A representation of this method’s type can be created by using another factory. This factory is found in the MethodType class which also represents instances of created method types. Using this factory, the method type for Counter::count can be created by handing over the method’s return type and its parameter types bundled as an array:
MethodType methodType = MethodType.methodType(int.class, new Class<?>[] {String.class});
By using the lookup object that was created before and the above method type, it is now possible to locate a method handle that represents the Counter::count method as depicted in the following code:
MethodType methodType = MethodType.methodType(int.class, new Class<?>[] {String.class});
MethodHandles.Lookup lookup = MethodHandles.lookup();
MethodHandle methodHandle = lookup.findStatic(Counter.class, "count", methodType);
int count = methodHandle.invokeExact("foo");
assertThat(count, is(3));
At first glance, using a method handle might seem like an overly complex version of using the reflection API. However, keep in mind that the direct invocation of a method using a handle is not the main intent of its use.
The main difference of the above example code and of invoking a method via the reflection API is only revealed when looking into the differences of how the Java compiler translates both invocations into Java byte code. When a Java program invokes a method, this method is uniquely identified by its name and by its (non-generic) parameter types and even by its return type. It is for this reason that it is possible to overload methods in Java. And even though the Java programming language does not allow it, the JVM does in theory allow to overload a method by its return type.
Following this principle, a reflective method call is executed as a common method call of the Method::invoke method. This method is identified by its two parameters which are of the types Object and Object[]. In addition to this, the method is identified by its Object return type. Because of this signature, all arguments to this method need to always be boxed and enclosed in an array. Similarly, the return value needs to be boxed if it was primitive or null is returned if the method was void.
Method handles are the exception to this rule. Instead of invoking a method handle by referring to the signature ofMethodHandle::invokeExact signature which takes an Object[] as its single argument and returns Object, method handles are invoked by using a so-called polymorphic signature. A polymorphic signature is created by the Java compiler dependant on the types of the actual arguments and the expected return type at a call site. For example, when invoking the method handle as above with
int count = methodHandle.invokeExact("foo");
the Java compiler translates this invocation as if the invokeExact method was defined to accept a single single argument of typeString and returning an int type. Obviously, such a method does not exist and for (almost) any other method, this would result in a linkage error at runtime. For method handles, the Java Virtual Machine does however recognize this signature to be polymorphic and treats the invocation of the method handle as if the Counter::count method that the handle refers to was inset directly into the call site. Thus, the method can be invoked without the overhead of boxing primitive values or the return type and without placing the argument values inside an array.
At the same time, when using the invokeExact invocation, it is guaranteed to the Java virtual machine that the method handle always references a method at runtime that is compatible to the polymorphic signature. For the example, the JVM expected that the referenced method actually accepts a String as its only argument and that it returns a primitive int. If this constraint was not fulfilled, the execution would instead result in a runtime error. However, any other method that accepts a single String and that returns a primitive int could be successfully filled into the method handle’s call site to replace Counter::count.
In contrast, using the Counter::count method handle at the following three invocations would result in runtime errors, even though the code compiles successfully:
int count1 = methodHandle.invokeExact((Object) "foo");
int count2 = (Integer) methodHandle.invokeExact("foo");
The first statement results in an error because the argument that is handed to the handle is too general. While the JVM expected aString as an argument to the method, the Java compiler suggested that the argument would be an Object type. It is important to understand that the Java compiler took the casting as a hint for creating a different polymorphic signature with an Object type as a single parameter type while the JVM expected a String at runtime. Note that this restriction also holds for handing too specific arguments, for example when casting an argument to an Integer where the method handle required a Number type as its argument. In the second statement, the Java compiler suggested to the runtime that the handle’s method would return an Integer wrapper type instead of the primitive int. And without suggesting a return type at all in the third statement, the Java compiler implicitly translated the invocation into a void method call. Hence, invokeExact really does mean exact.
This restriction can sometimes be too harsh. For this reason, instead of requiring an exact invocation, the method handle also allows for a more forgiving invocation where conversions such as type castings and boxings are applied. This sort of invocation can be applied by using the MethodHandle::invoke method. Using this method, the Java compiler still creates a polymorphic signature. This time, the Java virtual machine does however test the actual arguments and the return type for compatibility at run time and converts them by applying boxings or castings, if appropriate. Obviously, these transformations can sometimes add a runtime overhead.

Fields, methods and constructors: handles as a unified interface

Other than Method instances of the reflection API, method handles can equally reference fields or constructors. The name of theMethodHandle type could therefore be seen as too narrow. Effectively, it does not matter what class member is referenced via a method handle at runtime as long as its MethodType, another type with a misleading name, matches the arguments that are passed at the associated call site.
Using the appropriate factories of a MethodHandles.Lookup object, a field can be looked up to represent a getter or a setter. Using getters or setters in this context does not refer to invoking an actual method that follows the Java bean specification. Instead, the field-based method handle directly reads from or writes to the field but in shape of a method call via invoking the method handle. By representing such field access via method handles, field access or method invocations can be used interchangeably.
As an example for such interchange, take the following class:
class Bean {
  String value;
  void print(String x) {
For the above Bean class, the following method handles can be used for either writing a string to the value field or for invoking the print method with the same string as an argument:
MethodHandle fieldHandle = lookup.findSetter(Bean.class, "value", String.class);
MethodType methodType = MethodType.methodType(void.class, new Class<?>[] {String.class});
MethodHandle methodHandle = lookup.findVirtual(Bean.class, "print", methodType);
As long as the method handle call site is handed an instance of Bean together with a String while returning void, both method handles could be used interchangeably as shown here:
anyHandle.invokeExact((Bean) mybean, (String) myString);
Note that the polymorphic signature of the above call site does not match the method type of the above handle. However, within Java byte code, non-static methods are invoked as if they were static methods with where the this reference is handed as a first, implicit argument. A non-static method’s nominal type does therefore diverge from its actual runtime type. Similarly, access to a non-static field requires an instance to be access.
Similarly to fields and methods, it is possible to locate and invoke constructors which are considered as methods with a void return value for their nominal type. Furthermore, one can not only invoke a method directly but even invoke a super method as long as this super method is reachable for the class from which the lookup factory was created. In contrast, invoking a super method is not possible at all when relying on the reflection API. If required, it is even possible to return a constant value from a handle.

Performance metrics

Method handles are often described as being a more performant as the Java reflection API. At least for recent releases of the HotSpot virtual machine, this is not true. The simplest way of proving this is writing an appropriate benchmark. Then again, is not all too simple to write a benchmark for a Java program which is optimized while it is executed. The de facto standard for writing a benchmark has become using JMH, a harness that ships under the OpenJDK umbrella. The full benchmark can be found as a gist in my GitHub profile. In this article, only the most important aspects of this benchmark are covered.
From the benchmark, it becomes obvious that reflection is already implemented quite efficiently. Modern JVMs know a concept named inflation where a frequently invoked reflective method call is replaced with runtime generated Java byte code. What remains is the overhead of applying the boxing for passing arguments and receiving a return values. These boxings can sometimes be eliminated by the JVM’s Just-in-time compiler but this is not always possible. For this reason, using method handles can be more performant than using the reflection API if method calls involve a significant amount of primitive values. This does however require that the exact method signatures are already known at compile time such that the appropriate polymorphic signature can be created. For most use cases of the reflection API, this guarantee can however not be given because the invoked method’s types are not known at compile time. In this case, using method handles does not offer any performance benefits and should not be used to replace it.

Creating an invokedynamic call site

Normally, invokedynamic call sites are created by the Java compiler only when it needs to translate a lambda expression into byte code. It is worthwhile to note that lambda expressions could have been implemented without invokedynamic call sites altogether, for example by converting them into anonymous inner classes. As a main difference to the suggested approach, using invokedynamic delays the creation of a similar class to runtime. We are looking into class creation in the next section. For now, bear however in mind that invokedynamic does not have anything to do with class creation, it only allows to delay the decision of how to dispatch a method until runtime.
For a better understanding of invokedynamic call sites, it helps to create such call sites explicitly in order to look at the mechanic in isolation. To do so, the following example makes use of my code generation framework Byte Buddy which provides explicit byte code generation of invokedynamic call sites without requiring a any knowledge of the byte code format.
Any invokedynamic call site eventually yields a MethodHandle that references the method to be invoked. Instead of invoking this method handle manually, it is however up to the Java runtime to do so. Because method handles have become a known concept to the Java virtual machine, these invocations are then optimized similarly to a common method call. Any such method handle is received from a so-called bootstrap method which is nothing more than a plain Java method that fulfills a specific signature. For a trivial example of a bootstrap method, look at the following code:
class Bootstrapper {
  public static CallSite bootstrap(Object... args) throws Throwable {
    MethodType methodType = MethodType.methodType(int.class, new Class<?>[] {String.class})
    MethodHandles.Lookup lookup = MethodHandles.lookup();
    MethodHandle methodHandle = lookup.findStatic(Counter.class, "count", methodType);
    return new ConstantCallSite(methodHandle);
For now, we do not care much about the arguments of the method. Instead, notice that the method is static what is as a matter of fact a requirement. Within Java byte code, an invokedynamic call site references the full signature of a bootstrap method but not a specific object which could have a state and a life cycle. Once the invokedynamic call site is invoked, control flow is handed to the referenced bootstrap method which is now responsible for identifying a method handle. Once this method handle is returned from the bootstrap method, it is invoked by the Java runtime.
As obvious from the above example, a MethodHandle is not returned directly from a bootstrap method. Instead, the handle is wrapped inside of a CallSite object. Whenever a bootstrap method is invoked, the invokedynamic call site is later permanently bound to theCallSite object that is returned from this method. Consequently, a bootstrap method is only invoked a single time for any call site. Thanks to this intermediate CallSite object, it is however possible to exchange the referenced MethodHandle at a later point. For this purpose, the Java class library already offers different implementations of CallSite. We have already seen a ConstantCallSite in the example code above. As the name suggests, a ConstantCallSite always references the same method handle without a possibility of a later exchange. Alternatively, it is however also possible to for example use a MutableCallSite which allows to change the referencedMethodHandle at a later point in time or it is even possible to implement a custom CallSite class.
With the above bootstrap method and Byte Buddy, we can now implement a custom invokedynamic instruction. For this, Byte Buddy offers the InvokeDynamic instrumentation that accepts a bootstrap method as its only mandatory argument. Such instrumentations are then fed to Byte Buddy. Assuming the following class:
abstract class Example {
  abstract int method();
we can use Byte Buddy to subclass Example in order to override method. We are then going to implement this method to contain a single invokedynamic call site. Without any further configuration, Byte Buddy creates a polymorphic signature that resembles the method type of the overridden method. However, for non-static methods, the this reference is set as a first, implicit argument. Assuming that we want to bind the Counter::count method which expects a String as a single argument, we could not bind this handle toExample::method because of this type mismatch. Therefore, we need to create a different call site without the implicit argument but with an String in its place. This can be achieved by using Byte Buddy’s domain specific language:
Instrumentation invokeDynamic = InvokeDynamic
 .bootstrap(Bootstrapper.class.getDeclaredMethod(“bootstrap”, Object[].class))
With this instrumentation in place, we can finally extend the Example class and override method to implement the invokedynamic call site as in the following code snippet:
Example example = new ByteBuddy()
int result = example.method();
assertThat(result, is(3));
As obvious from the above assertion, the characters of the "foo" string were counted correctly. By setting appropriate break points in the code, it is further possible to validate that the bootstrap method is called and that control flow further reaches the Counter::countmethod.
So far, we did not gain much from using an invokedynamic call site. The above bootstrap method would always bind Counter::countand can therefore only produce a valid result if the invokedynamic call site really wanted to transform a String into an int. Obviously, bootstrap methods can however be more flexible thanks to the arguments they receive from the invokedynamic call site. Any bootstrap method receives at least three arguments:
As a first argument, the bootstrap method receives a MethodHandles.Lookup object. The security context of this object is that of the class that contains the invokedynamic call site that triggered the bootstrapping. As discussed before, this implies that private methods of the defining class could be bound to the invokedynamic call site using this lookup instance.
The second argument is a String representing a method name. This string serves as a hint to indicate from the call site which method should be bound to it. Strictly speaking, this argument is not required as it is perfectly legal to bind a method with another name. Byte Buddy simply serves the the name of the overridden method as this argument, if not specified differently.
Finally, the MethodType of the method handle that is expected to be returned is served as a third argument. For the example above, we specified explicitly that we expect a String as a single parameter. At the same time, Byte Buddy derived that we require an int as a return value from looking at the overridden method, as we again did not specify any explicit return type.
It is up to the implementor of a bootstrap method what exact signature this method should portray as long as it can at least accept these three arguments. If the last parameter of a bootstrap method represents an Object array, this last parameter is treated as a varargs and can therefore accept any excess arguments. This is also the reason why the above example bootstrap method is valid.
Additionally, a bootstrap method can receive several arguments from an invokedynamic call site as long as these arguments can be stored in a class’s constant pool. For any Java class, a constant pool stores values that are used inside of a class, largely numbers or string values. As of today, such constants can be primitive values of at least 32 bit size, Strings, Classes, MethodHandles andMethodTypes. This allows bootstrap methods to be used more flexible, if locating a suitable method handle requires additional information in form of such arguments.

Lambda expressions

Whenever the Java compiler translates a lambda expression into byte code, it copies the lambda’s body into a private method inside of the class in which the expression is defined. These methods are named lambda$X$Y with X being the name of the method that contains the lambda expression and with Y being a zero-based sequence number. The parameters of such a method are those of the functional interface that the lambda expression implements. Given that the lambda expression makes no use of non-static fields or methods of the enclosing class, the method is also defined to be static.
For compensation, the lambda expression is itself substituted by an invokedynamic call site. On its invocation, this call site requests the binding of a factory for an instance of the functional interface. As arguments to this factory, the call site supplies any values of the lambda expression’s enclosing method which are used inside of the expression and a reference to the enclosing instance, if required. As a return type, the factory is required to provide an instance of the functional interface.
For bootstrapping a call site, any invokedynamic instruction currently delegates to the LambdaMetafactory class which is included in the Java class library. This factory is then responsible for creating a class that implements the functional interface and which invokes the appropriate method that contains the lambda’s body which, as described before, is stored in the original class. In the future, this bootstrapping process might however change which is one of the major advantages of using invokedynamic for implementing lambda expressions. If one day, a better suited language feature was available for implementing lambda expressions, the current implementation could simply be swapped out.
In order to being able to create a class that implements the functional interface, any call site representing a lambda expression provides additional arguments to the bootstrap method. For the obligatory arguments, it already provides the name of the functional interface’s method. Also, it provides a MethodType of the factory method that the bootstrapping is supposed to yield as a result. Additionally, the bootstrap method is supplied another MethodType that describes the signature of the functional interface’s method. To that, it receives aMethodHandle referencing the method that contains the lambda’s method body. Finally, the call site provides a MethodType of the generic signature of the functional interface’s method, i.e. the signature of the method at the call site before type-erasure was applied.
When invoked, the bootstrap method looks at these arguments and creates an appropriate implementation of a class that implements the functional interface. This class is created using the ASM library, a low-level byte code parser and writer that has become the de facto standard for direct Java byte code manipulation. Besides implementing the functional interface’s method, the bootstrap method also adds an appropriate constructor and a static factory method for creating instances of the class. It is this factory method that is later bound to the invokedyanmic call site. As arguments, the factory receives an instance to the lambda method’s enclosing instance, in case it is accessed and also any values that are read from the enclosing method.
As an example, consider the following lambda expression:
class Foo {
  int i;
  void bar(int j) {
    Consumer consumer = k -> System.out.println(i + j + k);
In order to be executed, the lambda expression requires access to both the enclosing instance of Foo and to the value j of its enclosing method. Therefore, the desugared version of the above class looks something like the following where the invokedynamic instruction is represented by some pseudo-code:
class Foo {
  int i;
  void bar(int j) {
    Consumer consumer = <invokedynamic(this, j)>;
  private /* non-static */ void lambda$foo$0(int j, int k) {
    System.out.println(this.i + j + k);
In order to being able to invoke lambda$foo$0, both the enclosing Foo instance and the j variable are handed to the factory that is bound by the invokedyanmic instruction. This factory then receives the variables it requires in order to create an instance of the generated class. This generated class would then look something like the following:
class Foo$$Lambda$0 implements Consumer {
  private final Foo _this;
  private final int j;
  private Foo$$Lambda$0(Foo _this, int j) {
    this._this = _this;
    this.j = j;
  private static Consumer get$Lambda(Foo _this, int j) {
    return new Foo$$Lambda$0(_this, j);
  public void accept(Object value) { // type erasure
    _this.lambda$foo$0(_this, j, (Integer) value);
Eventually, the factory method of the generated class is bound to the invokedynamic call site via a method handle that is contained by aConstantCallSite. However, if the lambda expression is fully stateless, i.e. it does not require access to the instance or method in which it is enclosed, the LambdaMetafactory returns a so-called constant method handle that references an eagerly created instance of the generated class. Hence, this instance serves as a singleton to be used for every time that the lambda expression’s call site is reached. Obviously, this optimization decision affects your application’s memory footprint and is something to keep in mind when writing lambda expressions. Also, no factory method is added to a class of a stateless lambda expression.
You might have noticed that the lambda expression’s method body is contained in a private method which is now invoked from another class. Normally, this would result in an illegal access error. To overcome this limitation, the generated classes are loaded using so-called anonymous class loading. Anonymous class loading can only be applied when a class is loaded explicitly by handing a byte array. Also, it is not normally possible to apply anonymous class loading in user code as it is hidden away in the internal classes of the Java class library. When a class is loaded using anonymous class loading, it receives a host class of which it inherits its full security context. This involves both method and field access rights and the protection domain such that a lambda expression can also be generated for signed jar files. Using this approch, lambda expression can be considered more secure than anonymous inner classes because private methods are never reachable from outside of a class.

Under the covers: lambda forms

Lambda forms are an implementation detail of how MethodHandles are executed by the virtual machine. Because of their name, lambda forms are however often confused with lambda expressions. Instead, lambda forms are inspired by lambda calculus and received their name for that reason, not for their actual usage to implement lambda expressions in the OpenJDK.
In earlier versions of the OpenJDK 7, method handles could be executed in one of two modes. Method handles were either directly rendered as byte code or they were dispatched using explicit assembly code that was supplied by the Java runtime. The byte code rendering was applied to any method handle that was considered to be fully constant throughout the lifetime of a Java class. If the JVM could however not prove this property, the method handle was instead executed by dispatching it to the supplied assembly code. Unfortunately, because assembly code cannot be optimized by Java’s JIT-compiler, this lead to non-constant method handle invocations to “fall off the performance cliff”. As this also affected the lazily bound lambda expressions, this was obviously not a satisfactory solution.
LambdaForms were introduced to solve this problem. Roughly speaking, lambda forms represent byte code instructions which, as stated before, can be optimized by a JIT-compiler. In the OpenJDK, a MethodHandle‘s invocation semantics are today represented by aLambdaForm to which the handle carries a reference. With this optimizable intermediate representation, the use of non-constantMethodHandles has become significantly more performant. As a matter of fact, it is even possible to see a byte-code compiledLambdaForm in action. Simply place a break point inside of a bootstrap method or inside of a method that is invoked via a MethodHandle. Once the break point kicks it, the byte code-translated LambdaForms can be found on the call stack.

Why this matters for dynamic languages

Any language that should be executed on the Java virtual machine needs to be translated to Java byte code. And as the name suggests, Java byte code aligns rather close to the Java programming language. This includes the requirement to define a strict type for any value and before invokedynamic was introduced, a method call required to specify an explicit target class for dispatching a method. Looking at the following JavaScript code, specifying either information is however not possible when translating the method into byte code:
function (foo) {;
Using an invokedynamic call site, it has become possible to delay the identification of the method’s dispatcher until runtime and furthermore, to rebind the invocation target, in case that a previous decision needs to be corrected. Before, using the reflection API with all of its performance drawbacks was the only real alternative to implementing a dynamic language.
The real profiteer of the invokedynamic instruction are therefore dynamic programming languages. Adding the instruction was a first step away from aligning the byte code format to the Java programming language, making the JVM a powerful runtime even for dynamic languages. And as lambda expressions proved, this stronger focus on hosting dynamic languages on the JVM does neither interfere with evolving the Java language. In contrast, the Java programming languages gained from these efforts.


10 Amazing Libraries for Your Web-based JavaScript Applications

Of all the languages you can use to create Web applications, JavaScript seems to have the most robust selection of truly useful libraries to choose from. In fact, there are so many JavaScript libraries out there that sometimes it’s hard to figure out which one to use, especially when you’re just getting started with Web application design. So we’ve called out 10 of the best, most-useful JavaScript Libraries available.

Some of these libraries are practically must haves, employed by just about every site on the Web. Others are more specialized—you need them only when you have specific functionality on your site. But all of them have managed to distinguish themselves from the rest of the crowd in one way or another (in alphabetical order):

1. AngularJS

Go ahead; admit that you’ve found HTML5 a little less comprehensive than you wanted it to be. AngularJS is here to remedy that situation. Many developers rely on the Model-View-Controller (MVC) approach to creating large-scale applications, and the AngularJS framework makes it possible to extend HTML by acting as the controller portion of MVC. Controllers are the behavior behind Document Object Model (DOM) components. AngularJS makes it possible to create new behaviors in a manner that is both natural and straightforward. The extensions end up looking like additions to HTML, rather than something bolted in place.
However, the coding can become complex and this framework may be more suited to enterprises than small startups. Even the simple examples on the AngularJS site rely on multiple files that quickly create complexity.

2. Backbone.js

Backbone.js provides the model portion of MVC. The model is the representation of an underlying data source. For example, you might need a model of a corporate employee list or data from the company’s catalog as part of your application. Whatever the data source, the model describes the data, its format, and the means for dealing with the data. It creates an abstraction that makes it possible to deal with the data without tying it to the DOM. As a result, Backbone.js deals with events, such as whether the object is on or off, and model methods, such as getting or setting an attribute. In fact, it has a long list of features that make working with the model easier, but requires a relatively steep developer learning curve. Fortunately, the vendor also provides a relatively large list of examples so you can see how to perform key tasks.

3. D3.js

Many websites are data or content driven. For example, if you go to a news site, the news changes nearly every time you visit. The information is definitely dynamic and trying to reconfigure the site’s setup every few seconds to support changes becomes impossible. The D3.js library is unique in that it puts the data and content first.
The main advantage of the D3.js library is its extremely flexible handling of content, sometimes at the cost of a bit of pizzazz. For sites devoted to selling products rather than presenting information, D3.js may not be the best choice. In addition to extreme flexibility, D3.js also tends to be fast because it eschews a lot of the baggage other libraries use to create slick presentations.

4. jQuery

Few websites get by without using jQuery and jQuery UI. Yes, there are other libraries that perform the same tasks, but jQuery and jQuery UI are so good at the job they do and they receive so many quality updates that most developers rely heavily upon them. Many sites use jQuery for basic DOM manipulation for three essential reasons:
  • First, jQuery is incredibly easy to learn. The site provides not just one or two examples like most libraries, but enough of them so there is a good chance you’ll find an example that demonstrates how to accomplish your specific task.
  • Second, jQuery is incredibly fast. Because it focuses on performing specific tasks well, jQuery makes it possible to perform those tasks quickly.
  • Third, there is a huge installed base of community support and add-on creators for jQuery.
Of course, there are costs associated with anything. For example, jQuery doesn’t always work exactly the same way across browsers. The vendor is actually up front about these concerns and you can find information about browser support on the JQuery site.
Also, unlike other libraries listed here, jQuery isn’t a complete solution. You need another product, such as jQuery UI, to build a complete application. Your site will be more modular and dependent on more libraries when working with jQuery (which isn’t necessarily a bad thing).

5. jQuery UI

You use jQuery UI to add basic graphic elements to your application after you incorporate jQuery. The jQuery UI library comes with all sorts of interesting widgets to configure your application to provide great services to the end user, along with a little visual spark to keep them interested.
Most importantly, jQuery UI works with just about any browser available: You won’t have a lot of people complaining that your application doesn’t work as expected. jQuery UI also boasts a vast number of available add-ons. For example, jQuery UI lacks a time picker, but you can easily get an add-on to perform that task from places such as

6. jQuery Mobile

Many JavaScript libraries are primarily designed for desktop systems. They may work just fine with mobile devices, but one essential element of the mobile experience is missing—touch. jQuery Mobile works with other members of the jQuery family to produce applications that work well on mobile devices, an increasingly popular way to interact with the Web. If you already use jQuery and jQuery UI, adding this library to your application makes it relatively easy to update it for mobile.

7. PDF.js

Many documents are easy to present on the Web using common programming techniques. However, the Portable Document Format (PDF) file is a desktop document that defies easy presentation using standard Web techniques. Given the amount of information found in PDFs, you really do need PDF.js in your programmer’s toolkit to ensure you can properly display this kind of document on screen.

8. QUnit

Anyone who has created more than a few JavaScript applications quickly realizes most libraries provide testing functionality that is hard to use if it exists at all. Testing by hand is problematic, even if you use a script, because manual testing of an application of any complexity is bound to be cumbersome and time consuming (assuming that the manual testing actually finds all the errors in the first place). One of a number of unit testing libraries available for JavaScript, QUnit stands out with great community support, a short learning curve, and relatively comprehensive approach. You can even use QUnit to test QUnit (assuming you’d ever want to do so).

9. React

React provides the view portion of the MVC. It doesn’t assume anything about the underlying technology stack that you’re using to model or control the data. All React is interested in is displaying the data on screen. With this in mind, it doesn’t rely on the browser DOM, but instead relies on a light virtual DOM that makes displaying the information quite fast. The price you pay for the speed and ability to use MVC is complexity. Even a small component requires quite a bit of code (as demonstrated by the examples on the vendor site). What you gain is flexibility and speed when working with really large projects. (As far as I know, React doesn’t support the newer Models-Operations-Views-Events, MOVE, approach.)
React is still in beta, but some developers are already using it for production work. It’s a good idea to be extra careful when relying on beta products, but React provides cutting edge features that you may not be willing to wait for, especially if you’re maintaining a really large site and MVC is essential to getting the job done.

10. SWFObject

Many websites still present multi-media effects using Shockwave Flash (SWF) files. Of course, you could just embed the SWF files as an object, but then you couldn’t provide a specific version of the SWF file to go with the version of Shockwave Flash installed on the client system. And your site would just sit there, apparently broken, if the client doesn’t have Shockwave Flash installed. The SWFObject library helps you overcome these problems by helping your site provide the sort of content the client actually requires. Even though using this library adds to the complexity of your application, it can help ensure most users see Flash effects as you intended, no matter what setup they might have.

Bottom Line

It’s important to realize that every website and Web application is unique. When considering any library, there are a few key things you need to take into account:
  • Ensure your library is flexible enough to meet your needs so that you don’t have to worry about odd kludges or workarounds to get the job done.
  • Check on how often the library is updated to meet new application requirements and to ensure compatibility with new standards.
  • Verify that the library is secure before you use it for a critical application. Trying to fix security problems later can be nearly impossible.
  • Ideally, choose a library with strong community support—you might be surprised how often you’ll need it.
  • Check out some simple example applications to discover how well the library is written and whether the documentation is actually usable.