Beginning Web Application Development

Don't get me wrong, web applications have a compelling story versus native applications. Notably, the "distribution problem" of how do you get updates to users is pretty much gone. And, while the incompatibilities between browsers can be infuriating, still, there are at most a dozen that matter.

But, the number of technologies involved can be staggering. A good web developer will have a working knowledge of HTTP; an intimate knowledge of HTML, including "HTML5"; will be able to work with CSS; will have a working knowledge of JavaScript, and probably better knowledge of some JavaScript libraries; will be able to work with persistence engines, either directly or using some sort of adapter library; will probably need to know at least one server framework well; and will need to know whatever languages the server framework uses. In addition, some domain specific languages, such as templating languages will probably need to be learned. And the developer will have to be able to fluently switch between all of these artifacts, as they will typically all be in use simultaneously.

This is a long list of requirements for a beginner. Hell, it is a long list of requirements for a practitioner.

Fortunately, it can be broken up into a bunch of easy stages. Unfortunately, it will take time and energy.

First, learn "12 element HTML" -- <html>, <head>, <body> <p>, <ul>, <li>, <a>, <div>, <span>, <table>, <tr>, and <td>. Write something, using nothing but these elements, and using all of these elements. Do not use an HTML editor. Use a text editor, vi, emacs, notepad, whatever. These will be the bread and butter tags you use every day, and you will be expected to be able to fix the, usually hideously broken, HTML generated by HTML editors. Read what you have written with a critical eye towards appearance.

Now, work on appearance. Find out what CSS is. Make sure you understand CSS selector syntax. Find out what the box model is. Understand where styles can be located. Try all three, figure out what the advantages and disadvantages of each location are. Apply this to the stuff you wrote. Make it look better. Go overboard, make it look even uglier. This is will take a few days. There is a lot here, and unless you have the luxury of an on-site designer, you will have to know enough to change color, font, and location.

You may find yourself being fascinated with CSS. I am not, I just want to know enough to make it easier for the people who have to deal with the applications I write to find information. However, CSS is surprisingly broadly needed, at least in the small. Many menu systems use <li> and CSS to make the items visible, distinct, and positioned, for example.

A couple of websites have a lot of good advice on them about CSS, has a lot of good information. shows what can be done by an artist of CSS. CSS3 opens up new possibilities.

If you have gotten even this far, you now need to think about "continuing education". You need to start being exposed to what other people are doing. One of the best sources of the is Hacker News. You want to read it at least daily. Visit the "Show HN" items, and demos. Unless it is your interest, you can safely ignore most of the financial and general interest stories. But, it is the only place I know where in-depth stories and cutting-edge demos are routinely announced. Be sure to look at comments, as well. There are some very bright people on HN, and the signal-to-noise ratio is unusually high.

Now turn your attention for a day or two to HTTP. HTTP is "stateless". What does that mean? How does that affect application development? What kinds of interactions with a server do browsers use? What is the difference between a GET and a POST method? When can servers respond to browsers? Read the standard, the actual standard, not some simplified version.

Now back to HTML. What is a <form>? What are all of the input types available? When is it good to use each? When is form submission triggered? Design some forms. Don't forget that forms can be styled. Have someone else try to use the form, watch them to see what appear to be problems, have them tell you what the problems are. What you think are problems and what others think are problems will often be different. Both matter!

Up to now, everything could be done with just a browser using file:/// URLs. Now you need a web server, and preferably a web application server. Install one, pyramid, rails, flask, django, whatever looks reasonable to you. Why? Well, forms aren't very interesting unless you can somehow save and retrieve the information in them. Install your web application server. Get a basic "Hello, Web" application running. Read the documentation.

Wire in a basic persistence engine. At this point, it doesn't matter much which one you use. A lot of people like sqlite at this stage. I have reservations, because it stores everything as character, and doesn't fail properly. If you like SQL databases, PostgreSQL is very good. Figure out how you are going to use the persistence engine from your application server. In particular, are you going to use direct function calls, or are you going to use some kind of an adapter (an ORM, like SqlAlchemy, for example). If you already know the database language, you are probably better off using direct calls, especially at this stage. Constructing the mental models required to work effectively is difficult and the more "moving parts" you have, the more complicated the mental model has to be.

You wrote a form. Catch it using the application server. Persist the data. Write another form so that you can retrieve the item and display all associated data. Look at your form. Does it have date fields, or numeric fields, or times? Are some fields required for the data to make sense or to be stored? OK, implement server-side logic to check the input. (You will always have to do this on all forms -- client-side logic helps the user immensely, the form will be more responsive -- but client-side logic can always be subverted.) OK, now comes a big question. What do you do in the presence of errors? How do you communicate them back to the user? How do you prevent data from being lost?

Congratulations. You can now make any 1990's style web application. But, "modern" web applications are a bit different. In order to make the application more responsive to user actions, more and more of the action is being moved to the client side, that is, more and more is happening in the browser itself.

Oh, happy, happy, joy, joy! Now there is another set of techniques to learn. The foundational language of all modern browsers is JavaScript. There are some very good resources available. JavaScript: the Good Parts is supposed to be very good (I haven't read it). Eloquent JavaScript looks good. You need to be able to read simple JavaScript and know the event model that browsers support.

An aside: and this goes for all web development. Avoid It is full of inaccurate information. See, and in particular, for better resources.

But, the DOM (Document Object Model) is a killer for web development. It is hard to use, incredibly verbose and generally "the worst wrong way" to get anything done. Find a JavaScript library you are happy with. I use jQuery. Remember CSS selectors. jQuery uses them to associate JavaScript functions and form elements. It is quite useful.

If you do go with jQuery, read Rebecca Murphey's jQuery Fundamentals book. (This is supposed to be extended and developed into, but that site is not ready at yet). In particular, all of the examples at use an approach that requires heavy use of anonymous functions, often deeply nested. This is much harder to read than necessary, and anything that is harder to read is also harder to write.

Whatever library you use, remember to always think about whether what you are doing is easier in raw JavaScript or in your library.

Now, having JavaScript or a helper library available opens up a lot of new options. The form can become responsive to user input, for example disabling or enabling controls based on a checkbox. Client side validation can be done, so the the user knows about most errors immediately.

And, most importantly, smaller units of information than entire pages can be transferred. This is done via the XMLHttpRequest, but is mostly abstracted up into three slightly different terms. The first is AJAX, (Asynchronous JavaScript and XML). Frankly, this hardly matters any more, there is less and less XML in the current web. The second technique is called AJAH, where the H is from HTML. Here, a request (via JavaScript) is sent, and a HTML fragment is given back. JavaScript is then used to replace some element of page with the fragment. Finally, the last common technique is sometimes called AJAJ, where the J is for JSON (JavaScript Object Notation). This allows you to submit a request (again via JavaScript) and receive an object back, which may be used to update several elements of the form at once. AJAJ is probably the preferred method now.

Finally, you will want to explore the plug-ins available for your JavaScript library.

You can now write most modern web applications. There is lots more to learn, and this includes lots that I haven't learned yet. The HTML5 technologies promise a lot of new options, and will definitely allow us to push even more to the client side. Note that HTML5 form inputs have a lot of new options. Read about them, think about using them.

One thing that is often underestimated is the amount of reading required. There is a lot. And, as fast as most software development practices change, web software changes even faster. Do not expect your hard-won knowledge to have a long working life. Change is constant, pervasive, and rapid. Keep reading, keep thinking, keep trying to improve, and keep practicing!

One final thought: remember that you are working with web applications. These are not usually art forms, in and of themselves, they are more like industrial design. Especially if you have international users, you have to think about the effects of bandwidth and latency. Things that can be immediate to an on-site user can be painfully slow to someone overseas. So, be sure to keep your transfers as small and as infrequent as possible. Most of your users will never have heard of bandwidth or latency. Be prepared with analogies (in a telephone conversation, high bandwidth is a guy who talks real fast, high latency is a guy who pauses between sentences, for a real long time). Bandwidth and latency constraints mean that you always optimize images, and that you never rescale them on the client, they mean that you minify any large JavaScripts, and they mean that you never load anything that is not needed on the form being presented. Think about minimalism, and "small is better". But, balance, balance, balance. You still have to make your forms attractive and usable.