And indeed, we have seen an explosion of Ajax applications in the last year or so. Startups established to create Ajax versions of existing applications already have been bought by companies such as Google. Existing Web sites are scrambling to include Ajax functionality. Book publishers are printing Ajax-related books like they're going out of style. I probably know of at least six toolkits for adding Ajax to applications, and new ones are being released all the time.
Much of the excitement behind Ajax is the freedom it gives designers and developers. Before Ajax, Web applications could be beautiful to look at, but their page-based interfaces were reminiscent of old mainframes, whose applications ran on a page model. What, you want to create an application that is updated incrementally? Sorry, the HTTP/HTML combo means that you either got a new page, and got to enjoy the functionality that it offered, or you stayed on the current one. Every page update had to be accompanied by an HTTP request, and vice versa.
There is no doubt that Ajax applications have a cleaner look and feel to them than old-style Web applications. They feel more natural and responsive, and it's easy to imagine all Web applications looking like this within a few years. This is probably a good thing overall, and I'm looking forward to what the future will bring. In fact, I would guess that within a few years, saying you're an “Ajax developer” will sound as funny as saying you're a “cookie developer”, or a “DOM developer” or even a “database developer”. Just as understanding each of these technologies is now an expected part of being a Web developer, the same is true for Ajax. Yes, this means that Web developers have yet another set of technologies to learn if they want to keep up.
After several years in which Web developers dealt with incompatible versions, Netscape had the language standardized by the European organization ECMA. Officially, the language is now known as ECMAScript, but no one really calls it that. The versions in Internet Explorer and Mozilla are now largely compatible with the standard, although there are still differences and issues to work around.
Perhaps the simplest way is to create a button—an <input> type meant for exactly this task—and have that button then execute our code. For example:
There is a variety of handlers, all of which begin with the letters “on”, so you can execute a function when someone clicks (onclick), when something is changed (onchange), when an element gets the mouse focus (onfocus) or loses it (onblur), and a number of other possibilities. (Because we're using XHTML, all attributes must be in lowercase. So although it might be tempting to make the event handler more legible by writing onClick, that will invalidate the page.)
We can make this a bit more interesting by personalizing the message:
Win an iPhone 6
Enter to Win
|Microsoft and Linux: True Romance or Toxic Love?||Nov 25, 2015|
|Non-Linux FOSS: Install Windows? Yeah, Open Source Can Do That.||Nov 24, 2015|
|Cipher Security: How to harden TLS and SSH||Nov 23, 2015|
|Web Stores Held Hostage||Nov 19, 2015|
|diff -u: What's New in Kernel Development||Nov 17, 2015|
|Recipy for Science||Nov 16, 2015|
- Microsoft and Linux: True Romance or Toxic Love?
- Non-Linux FOSS: Install Windows? Yeah, Open Source Can Do That.
- Cipher Security: How to harden TLS and SSH
- Web Stores Held Hostage
- PuppetLabs Introduces Application Orchestration
- Simple Photo Editing, Linux Edition!
- Firefox's New Feature for Tighter Security
- diff -u: What's New in Kernel Development
- November 2015 Issue of Linux Journal: System Administration
- It's a Bird. It's Another Bird!