Introduction

Introduction

Is this intro too long? Should we rip it apart and use in several chapters

What's an Enterprise Web Application?

This book has the word Enterprise in its title, which needs to be explained, and we'll do this by example. Creating a Web application that will process orders is not the same as creating a Web site to publish blogs. Enterprise applications include company-specific workflows, and usually they need to be integrated with number of internal systems, data sources and processes.

Google Doc is not an enterprise Web application. But Google appliance integrating search operating on company documents, databases, processes, tickets, and providing collaboration is - it integrates consumer-workforce front office with what the company does (back office).

Google Maps is not an enterprise application. But Google Maps integrated with the company site used by insurance agents to plan daily route, scheduling, doing address verification and geo-coding is.

Just using a Web application in some business doesn't make it an enterprise Web application. If you take Gmail as is, it won't be an enterprise application until you integrate it into another process of your business.

Is an online game an enterprise application? It depends on the game. A multi-player online roulette game hooked up to a payment system, and maintaining users' accounts is an enterprise Web application. But playing Sudoku online doesn't look too enterprisey.

How about a dating Web site? If the site just offers an ability to display singles - it's just a publishing site as there is not much of a business there. Can you turn a dating Web site into an enterprise application? It's possible.

Some people will argue that an enterprise application must supports multiple users, high data load, be scalable, have business and persistence layers, offer professional support et al. We don't believe that a Web application should do all this to qualify for the adjective enterprise.

Let's create a simple definition of an enterprise Web application:

"An enterprise Web application is the one that helps an organization running its business online"

In this book we are going to build a Save the Child Web application that will allow people to register, donate, find local kids that need help, match donors and recipients, upload images, videos and display statistics. Would these feature make Save the Child an enterprise Web application? Yes, our non-for-profit organization that collects donations for ill kids is our enterprise.

During the last decade the authors of this book worked on many enterprise Web applications using variety of programming languages and frameworks: HTML, JavaScript, Java, and Flex to name a few. Apache Flex and Java produce compiled code that runs in a well known and predictable virtual machine (JVM and Flash Player respectively).

This book is about developing software using what's known as HTML5 stack. But only the first chapter of this book will offer you an overview of the latest HTML5 tags and APIs. The second chapter is an advanced introduction to JavaScript. Chapers 3 and 11 are about designing the Web site Save the Child. The rest of the book is about building it learning whatever is required on the go. We’ll be using dynamic HTML (DHTML), which is HTML5, JavaScript, and Cascading Style Sheets (CSS). We'll add to the mix the XMLHttpRequest object that lives in a Web browser and communicates with the server without the need to refresh the entire Web page (a.k.a. AJAX). JSON will be our data format of choice for data exchange between the Web browser and the server.

##From DHTML to HTML5

DHTML has been introduced in Microsoft Internet Explorer (IE) 5, and several years later it was substituted with a more popular acronym AJAX. Back in 1999 Microsoft created XMLHttpRequest object to allow the Web version of their mail client Outlook to update the browser’s window without the need to refresh the entire Web page. The market share of IE5 was about 90%, but in enterprises it was literally the only approved browser.

Many years passed by and today's Internet ecosystems changed quite a bit. Web browsers are a lot smarter and performance of JavaScript improved substantially. The browsers support 6-8-12 connections per domain (as opposed to 2 five years ago), which gave a performance boost to all AJAX applications. At least one third of all Web requests is being made from smart phones or tablets. Apple Inc. started their war against browser's plugins hence using JVM or Flash Player is not an option there. The growing need to support a huge variety of mobile devices gave another boost for HTML5 stack, which is supported by all devices.

But choosing HTML5 as the least common denominator that works in various devices and browsers means lowering requirements for your enterprise project. From the very beginning parameters like reliability, ability to adapt to different the screen sizes and densities will be simplified comparing to developing for one specific VM, device or OS. Instead of implementing these features, the functional specification will include testing under several Web browsers, in many different screen sizes and resolutions. HTML5 developers spend a lot more time in the debugger that people who develop for a known VM. Get ready to solving problems like a dropdown does not show any data in one browser while working fine in all others. Can you imagine a situation when the click event is not always generated while working in Java, Flex, or Silverlight? Get ready for such surprises while testing your DHTML application.

You’ll save some time because there is no need to compile JavaScript, but you'll spend more time testing deployed code. The final deliverable of an HTML5 project may have as low as half of the functionality comparing to the same project developed for a VM. But you’ll gain a little better Web adaptability, easier implementation of full text search and mashups. The integration with other technologies will also become easier with HTML/JavaScript. You have to decide if all these advantages are important to your application. If they are – choose HTML5.

But JavaScript will enforce its limitations on any serious and complex enterprise project. You can develop a number of fairly independent windows, but creating a well debugged HTML5 won’t be easy.

In this book we'll be using some JavaScript frameworks - the are dozens of those on the market. Several of them promise to cover all the needs of your Web application. Overall, there are two main categories of frameworks:

a) Those that allow you to take an existing DHTML Web site and easily add new attributes to all or some page elements so they would start shining, blinking, or do some other fun stuff. Such frameworks don’t promote component-based development. They may not include navigation components, grids, trees, which are pretty typical for any UI of the corporate tasks. JQuery is probably the best representative of this group. It's light (30Kb) and very easy to learn.

b) Another group of frameworks offers rich libraries of high-level components and allow you to extend them. But overall, such components are supposed to be used together becoming a platform for your Web UI. These components process some events, offer support of the Model-View-Controller paradigm, have a proprietary way of laying out elements on the Web page, organize navigation et al. Ext JS from Sencha belongs to this group.

We like both JQuery and Ext JS and will show you how to develop Web applications with each of these popular frameworks. JQuery is good for improving an existing JavaScript site. JQuery can be used to program about 80% of a Web site. You should use it for the look and feel support, which is what it’s meant for. But you can’t use it for building your application component model. The component model of Ext JS is applicable in about 20% of a Web site, which includes an application piece rather than just being a set of Web pages. Typically it’s a serious view navigator or a wizard to implement a serious business process or a workflow that includes a client’s part.

JavaScript frameworks are hiding from a developer all incompatibilities and take care of the cases when a Web browser doesn't support some HTML5, CSS3, or JavaScript features yet.

High-level UI components and a workflow support are needed for a typical enterprise application where the user needs to perform several steps to complete the business process. And these 20% of an application's code will require 80% of the project time of complex development. So choosing between frameworks is not the most difficult task. The main problem with DHTML projects is not how to pick the best JavaScript framework for development, but finding the right software developers. Lack of qualified developers increases the importance of using specialized frameworks for code testing. The entire code base must be thoroughly tested over and over again. We'll discuss this subject in the chapter on test-driven development.

A JavaScript developer has to remember all unfinished pieces of code. Many things that we take for granted with compiled languages simply don't exist in JavaScript. For example, in Java or C# just by looking at the method signature you know what are the data types of the method's parameters. In JavaScript you can only guess if the parameter names are self descriptive. Take the Google's framework GWT that allows developers write code in Java with auto-generation of the JavaScript code. Writing code in one language with further conversion and deployment in another one is a controversial idea, because after writing the code you’ll need to be able to debug it. This is when a Java developer meets a foreign language JavaScript.The ideology and psychology of programming in JavaScript and Java are different. A person who writes in Java/GWT has to know how to read and interpret deployed JavaScript code.

On the other hand, Ext JS framework extends the JavaScript language introducing classes and more familiar syntax for object-oriented languages. Technically they are extending or replacing the constructs of the JavaScript itself extending the alphabet. Ext JS recommends creating objects using ext.create instead of the operator new. But Ext JS is still a JavaScript framework.

JQuery framework substantially simplifies working with browser's DOM elements and there are millions of small components that know how to do one thing well, for example, an image slider. But it's still JavaScript and requires developers to understand the power of JavaScript functions, callbacks, and closures. ##Should we develop in HTML5 if its standard is not finalized yet?

The short answer is yes. If you are planning to develop mainly for the mobile market, it's well equipped with the latest Web browsers and if you'll run into issues there. they won't be caused by the lack of HTML5 support. In the market of the emterprise Web applications, Internet Explorer 7 and 8 are still being widely used and thye don't support some of the HTML5 specific features. But it's not a show stopper either.If you are using one of the JavaScript frameworks that offers cross-browser compatibility, most likely, they take care of IE7 and 8 issues.

The more conservative approach to achieving the browser compatibility is not by relying on the framework promises, but by testing and adjusting your application in different browsers. The chances are that you may need to be fixing the framework's code here and there. Maintaining compatibility is a huge challenge for any framework's vendor, which in some cases can consist of just one developer. You shouldn't have hard feelings against the developers behind the framework of your choice. These guys simply don’t have time to fix everything. You need to form an attitude that a JavaScript framework is similar to a good Legos set that will require your creativity too. Don’t get angry. Cure the framework. Spend some time working on the framework, and then work on your application code. Ideally, submit your fixes back to the framework's code base - most of them are open source.

If you are planning to write pure JavaScript, add a tiny framework Modernizr, which will detect if a certain feature is supported by the user's Web browser, and if not - provide an alternative solution. We like the analogy with TV sets. People with latest 3D HD TV sets and those who have 50-year old black and white televisions can watch the same movie even though the quality of the picture will be drastically different.

##Summary

If you are starting working on your first HTML5 enterprise project, get ready to solve the same tasks as Java, JavaFX, Silverlight, or Flex developers face:

– Reliability of the network communications. What if the data never arrive from/to the server? Is it possible to recover the lost data? Where they got lost? Can we re-send the lost data? What to do with duplicates?

• Modularization of your application. If your application has certain seldom used menus don’t even load the code that handles this menu.

• Perceived performance. How quickly the main window of your application is loaded to the user’s computer? How heavy is the framework’s code base?

• Should you store the application state on the server or on the client?

• Does the framework offer a rich library of components?

• Does the framework support creation of loosely coupled application components? Is the event model well designed?

• Does the framework of your choice cover most of the needs of your application, or you’ll need to use several frameworks?

• Is well written documentation available?

• Does the framework of your choice locks you in? Does it restrict your choices? Can you easily replace this framework with another one if need be?

• Is there an active community to ask for help with technical questions?

We could continue adding items to this list. Our message is that developing HTML5 applications is not just about adding tag video and canvas to a Web page. It’s about serious JavaScript programming.