Skip to content

Latest commit

 

History

History
107 lines (64 loc) · 13.5 KB

Introduction.asciidoc

File metadata and controls

107 lines (64 loc) · 13.5 KB

Introduction

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 second chapter of this book will offer 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, re-designing, developing, and re-developing a sample Web site 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.

Warning
It’s not possible to provide the detailed coverage of all programming languages, frameworks and tools used in this rather short book. You’ll need to do some additional reading with more in-depth coverage of certain topics. This book is for practitioner who need to learn while developing a project.

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 introduced 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% at the time, and 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 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 is being made from smart phones or tablets. Apple Inc. started their war against all browser’s plugins 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 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 may not be pixel-perfect on any particular device, but it’ll be made somewhat simpler (comparing 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 specific to device features, the functional specification will include requirements to test 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. You’ll have to be ready to solve problems like a dropdown not showing any data in one browser while working fine in the 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 QA phases. 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 the ability to create mashups. The integration with other technologies will also become easier with HTML/JavaScript. If all these advantages are important to your application 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 a well tested and reliable HTML5 takes time.

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

Dividing all frameworks into only two category is an oversimplification, of course. Frameworks like Backbone, Angular and Ember 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 and some more. But our goal is not compare and contrast all HTML5 frameworks, but rather show you some selected ones.

We’ll use both JQuery and Ext JS and will show you how to develop Web applications with each of them. JQuery is good for improving an existing JavaScript site. JQuery can be used to program about 80% of a Web site functionality, but for the UI components you’ll need to use another framework, e.g. 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 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. Besides, ExtJS comes with a library of the rich UI components.

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 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 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. 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 5 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 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 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 introducing their version of 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, sliding effects. 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 enterprise Web applications, the aging Internet Explorer 8 is still being widely used and they 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 IE8 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 you intend to support to ensure it functions as intended. 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. 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 of them are open source.

If you are planning to write pure JavaScript, add a tiny framework Modernizr (see Chapter 1) to your code base, 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.

Challenges of the Enterprise Developer

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

  • 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 rarely 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?

  • 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 expose 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 tag video and canvas to a Web page. It’s about serious JavaScript programming. In this book we’ll discuss all of the listed above challenges.

Summary

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