Preface

(To Whom and About What I Am Talking)

efore I started to create Web applications, I read some books and articles on the topic. Some good, some bad and some really ugly. There are countless publications for beginners detailing how to color the page or make a sentence bold. A systematic study of the basics is useful but one should not spend too much time on learning those few HTML tags. What I needed was the tricks and tips of the trade, which make a Web site fast, usable, maintainable and aesthetic. I am offering the reader a fast track. Once you have a basic knowledge of HTML, CSS and JavaScript, you can jump on my wagon. Following the examples of Creating Fast Web Applications you will become an advanced Web developer much faster than if you keep reading those beginner's books.

The alphabet soup

ave you heard about RAD, as Rapid Application Development? Yes? Good. How about DRA, as Development of Rapid Applications? Yes? I doubt it. I just made up this term. Creating fast applications is out of scope of the IT industry. If your application runs slow, they say that it's not their fault; you should buy a faster, more powerful computer. They can convince you to buy their software, which will quickly do the developing job for you. If you fail, you won't complain. But if someone promises that the resulting app will be fast and in fact, it is not, you may have the right to ask your money back. That's why there is no such thing as DRA.

The title and the content

hat a lame book title! my son said. At least, why don't you change the adjective to slick? My son's remark made me think. Creating fast Web applications is very important but speed is not the only characteristic of a computer program. These lectures are focusing on speed but they concern about aesthetics, maintainability and usability of browser based applications as well. In short, slick covers the topics better than fast, but it sounds too populist to me and it connotates with superficial, not just with fast, smooth, compact, nice and smart. As so many times, my son was right but after considering all aspects I neglected his advice. I did not want to imply that my collection was one of those "How to Become a Pro with No Brain" books. That's why the second part of the book has been included. It deals with the second most important aspect of slickness after speed; with usability. The third part is about both: How to make an application fast and usable with some ideas of AJAX.

A title must be captivating, as short as possible, still distinctive, descriptive and precise. My first choice was one of my articles' titles: Info On the Fly. It is catchy and short but does not give a clue about the topic. A title like that can hide anything from a book on gossiping to airplane flying instructions. I knew exactly what I wanted to write about but I could hardly select the first word. Should it be building or creating? I relate the word building to the persistent diligence and effort of the construction worker and the word creating to the vision and inventiveness of the engineer. The job of Web design and development requires both brain and buttocks. What is more important? I chose the word creating because I thought that developing applications require more brain than endurance. Actually, several What-You-See-Is-What-You-Get Web site building software take the most part of burden. If one has imagination, one can build nice looking static Web pages in no time, with no sweat. The trouble starts when one visits these sites. First, one does not get what you have seen. Second, these pages open much slower than those created without using the page editor's WYSIWYG feature. And new problems rise when you want to create some dynamism on the pages. When I say dynamism, I don't mean dancing signs and flashing pictures. A dynamic page has to do something useful; to calculate, to select, to give context-sensitive choices. The WYSIWYG mode is not efficient for creating dynamic sites and applications.

I struggled with the last word of the title, too. Should it be site or application? People associate the Web with Web sites and they are almost completely right. However, a Web application is not necessarily a site on a network. Web application is a term for programs that use a browser as their graphical user interface. It should have been called something like browser-based application. It includes but is not limited to Web sites. A Web site can be a set of static pages full of pictures of a pet. It is just a Web site, not a real Web application even if it shakes and barks. We can expect from an application to be dynamic. Well-written Web apps run in any modern browsers, in almost any computers with almost any monitors. As opposed to most software applications, they are platform independent because their codes are in text format, readable by any operating systems. They don't have to reside on a network. A so-called Web application does not necessarily need a Web server, either. I can't change an industry-wide established terminology and I will interchangeably use the terms Web application and Web site as others. However, I always mean a set of interconnected pages which opens in a browser. Nothing more and nothing less.

Let me explain the subtitle, especially the reference to the target audience I described as not-so-dummies. In the last decade the average computer literacy shifted from beginners' toward intermediate level. A generation grew up on the "For Dummies" series. Amateurs learned how to handle various computers, software tools and build Web sites by moving the mouse around. Most people took advantage of the convenient approach. They grabbed one of the Web site building software with the corresponding "For Dummies" book, turned on the WYSIWYG mode, and formed their pages without knowing, what is going on behind the scene. They can create nice pages with limited functionality now. I want to reach those who already learned the basics and feel the urge to move further, leaving the children's play of pointing-and-clicking behind.

Web pages written in a What-You-See-Is-What-You-Get development environment may become dysfunctional or even unusable sometimes. Most of all, they are always slower compared to the ones edited in source code view. A crucial review of the automatically created source codes is necessary to speed up these pages. It's not a developer but a senseless software that writes the code. A program, which does not care about superfluous repetitions or file size. Names and id's, like x139 and Table07, automatically given by the software, don't mean anything and there is no person to ask how and why a code segment was created. The generated code becomes more and more difficult to decode as it grows. You can start a project in WYSIWYG mode, show off with the fast progress but you cannot finish it. At a critical point you must stop pointing and clicking and must write and rewrite substantial portions from scratch. The last 5% of the project will need more time then the first 95%. Why can't we hand code from the beginning then?

An example

et's say you have a restaurant at a ski resort and you want to display an accurate menu and wine list next to the entrance. Every time you change the special of the day, run out of an item or a new wine delivery arrives, you need to update the list. Would you retype the new list, go out to the freezing street and replace the sheet of paper three times a day while the snow blows in the open window of the menu box? Or get an old, stand-alone computer for a $100, place its monitor in the menu window, and as soon as you reedited a simple text file inside the building, the new menu is shown in a fancy format outside. The program can automatically update the price list according to the part of the day, before breakfast, lunch and dinner time. This is a simple application, but the periodical updating function would be hard to write with a WYSIWYG tool. Using the samples of this book, you can hand-code a dynamic price list application in Notepad and run it in a browser, without having a Web site or a network. Do you want to put the price list on your Web site? You can do it, too, without extra reformatting efforts. The online and offline versions will be the same.

Inspiration, perspiration

riting the first application from scratch is time consuming. During my programming career I had to switch systems and languages several times. At these times my mentor used to say: "Never write your first program in a new system. Start with the second." He meant that we should pick a source code, any working code in the particular language, and rewrite it. This book presents enough sample code to rewrite.

Working with source code always delivers great intellectual satisfaction to me. The challenges make me excited and sometimes sweat. These selected lectures are for Computer Science/IT teachers and students, for professional and amateur developers who want to develop themselves, too, for small business owners who can't afford to buy expensive development environments and office suites. For those who already see the limitations of the code generating tools but don't have the time to cope with picky languages and disagreeing browsers. I hope that the ideas make the readers as excited as myself and the given solutions help to spare their sweat. However, if you do have time to sweat, you can find related practice questions and problems at the end of each lecture.