Introduction.asciidoc

Introduction

During the last decade, the authors of this book worked on many enterprise web applications using a 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 by using what’s known as the HTML5 stack. But only the second chapter of this book offers you an overview of the selected HTML5 tags and APIs. The first chapter is an advanced introduction to JavaScript. The rest of the chapters are about designing, redesigning, developing, and redeveloping a sample website for Save The Child. You’ll be learning whatever is required for building this web application on the go.

You’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.

Moving from DHTML to HTML5

DHTML stands for Dynamic HTML. Back in 1999, Microsoft introduced the XMLHttpRequest object to allow the web version of its mail client, Outlook, to update the browser’s window without the need to refresh the entire web page. Several years later, it was substituted with a more popular acronym, AJAX (which stood for Asynchronous JavaScript and XML); today we refer to it simply as a name, "Ajax." The market share of Internet Explorer 5 was about 90 percent at the time, and in enterprises it was literally the only approved browser.

Many years passed by, and today’s Internet ecosystems have changed quite a bit. Web browsers are a lot smarter, and the performance of JavaScript has improved substantially. The browsers support multiple simultaneous 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 are being made from smartphones or tablets. Apple started its war against all browser plug-ins; hence using embedded Java VM or Flash Player is not an option there. The growing need to support a huge variety of mobile devices gave another boost for the 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. The UI might not be pixel-perfect on any particular device, but it will be made somewhat simpler (compared to developing for one specific VM, device, or OS) and will have the ability to adapt to different screen sizes and densities. Instead of implementing features that are specific to a particular device, the functional specification will include requirements to test under several web browsers, in many screen sizes and resolutions. HTML5 developers spend a lot more time in the debugger than people who develop for a known VM. You’ll have to be ready to solve problems such as a drop-down not showing any data in one browser while working fine in 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 HTML5 application.

You’ll save some time because there is no need to compile JavaScript, but you’ll spend more time testing the running application during development and Quality Assurance (QA) phases. The final deliverable of an HTML5 project might have as low as half of the functionality compared to the same project developed for a VM. But you’ll gain a little better web adaptability, easier implementation of full-text search, and the ability to create mashups. Integration with other technologies will also become easier with HTML/JavaScript. If all these advantages are important to your applications, choose HTML5.

JavaScript will enforce its language and tooling limitations on any serious and complex enterprise project. You can develop a number of fairly independent windows, but creating well-tested and reliable HTML5 applications takes time. It can be significantly easier with the use of libraries or a framework.

In this book, we use some JavaScript frameworks; there are dozens on the market. Several of them promise to cover all the needs of your web application. Overall, there are two main categories of frameworks:

• Those that allow you to take an existing HTML5 website 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, or trees, which are pretty typical for any UI of the corporate tasks. JQuery is probably the best representative of this group; it’s light (30 Kb), extendable, and easy to learn.

• 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 (or an offshoot of that), have a proprietary way of laying out elements on the web page, organize navigation, and more. Ext JS from Sencha belongs to this group.

Dividing all frameworks into only two categories is an oversimplification, of course. Frameworks such as Backbone.js, AngularJS, and Ember.js have no "components" in terms of the UI sense, and some don’t even quite dictate how you build your application (as in, they are not full-stack like Sencha). Some of the frameworks are less intrusive, whereas others are more so. But our goal is not to compare and contrast all HTML5 frameworks, but rather to show you some selected ones.

We’ll use both jQuery and Ext JS and show you how to develop web applications with each of them. jQuery is good for improving an existing JavaScript site and can be used to program about 80 percent of a website’s functionality. However, for the UI components, you’ll need to use another framework (for example, jQuery UI). You should use jQuery 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 becomes a fabric of the website, which includes an application piece rather than just being a set of web pages. Besides, Ext JS comes with a library of the UI components.

Note	JavaScript frameworks are hiding from software developers 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 workflow support are needed for a typical enterprise application in which the user needs to perform several steps to complete the business process. And 20 percent of an application’s code will require 80 percent of the project time of complex development. So choosing a framework 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. A 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 discuss this subject in [productivity_tools], which is dedicated to 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 the data types of the method’s parameters. In JavaScript, you can only guess if the parameter names are self-descriptive. Take the Google framework, GWT, which allows developers to write code in Java by auto-generating the JavaScript code. Writing code in one language with further conversion and deployment in another one is a controversial idea unless the source and generated languages are very similar. We’re not big fans of GWT, 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, using TypeScript or CoffeeScript to produce JavaScript code can be a time-saver.

The Ext JS framework creators decided to extend JavaScript by introducing their version of classes and a more familiar syntax for object-oriented languages. Technically, they are extending or replacing the constructs of JavaScript itself by extending the alphabet. Ext JS recommends creating objects by using ext.create instead of the operator new. But Ext JS is still a JavaScript framework.

The jQuery framework substantially simplifies working with a browser’s Document Object Model (DOM) elements, and there are millions of small components that know how to do one thing well; for example, sliding effects. But it’s still JavaScript and requires developers to understand the power of JavaScript functions, callbacks, and closures.

Developing in HTML5

Should we develop in HTML5, given that this standard has not been 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, so if you run into issues there, they won’t be caused by a lack of HTML5 support. In the market of enterprise web applications, the aging Internet Explorer 8 is still being widely used, and it doesn’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 it takes care of Internet Explorer 8 issues.

Remember that, even if you rely on a framework that claims to offer cross-browser compatibility, you will still need to test your application in the browsers that you expect to support to ensure that it functions as intended. The chances are that you may need to fix 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. Spend some time working with the framework, and then work on your application code. If you can, submit your fixes back to the framework’s code base—​most frameworks are open source.

If you are planning to write pure JavaScript, add the tiny framework Modernizr (see [mocking_up_the_app]) to your code base, which will detect whether a certain feature is supported by the user’s web browser, and if not, provide an alternative solution. We like the analogy of TV sets. People with the latest 3D HDTV 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.

Challenges of the Enterprise Developer

If you are an enterprise developer starting work on your first HTML5 enterprise project, get ready to solve the same tasks that all UI software developers face, regardless of what programming language they use:

• Reliability of network communications. What if the data never arrives from/to the server? Is it possible to recover the lost data? Where did it get lost? Can we resend the lost data? What to do with duplicates?

• Modularization of your application. If your application has certain rarely used menus, don’t even load the code that handles them.

• Perceived performance. How quickly is the main window of your application loaded into 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 will you need to use several frameworks?

• Is well-written documentation available?

• Does the framework of your choice lock 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?

• What is the right set of tools to increase your productivity (debugging, code generation, build automation, dependency management)?

• What are the security risks that need to be addressed to prevent exposing sensitive information to malicious attackers?

We could continue adding items to this list. But our main message is that developing HTML5 applications is not just about adding <video> and <canvas> tags to a web page. It’s about serious JavaScript programming. In this book, we discuss all of these challenges.

Summary

HTML5 is ready for prime time. There is no need to wait for the official release of its final standard. All modern web browsers have supported most HTML5 features and APIs for a couple of years now. To be productive, you’ll need to use not just HTML, JavaScript, and CSS, but third-party libraries, frameworks, and tools. In this book, we introduce you to a number of them, which will help you make the final choice of the right set of productivity tools that work best for your project.