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:
- Readers' Choice Awards 2013
- Linux Kernel News - November 2013
- December 2013 Issue of Linux Journal: Readers' Choice
- Mars Needs Women
- Sublime Text: One Editor to Rule Them All?
- Raspberry Pi: the Perfect Home Server
- RSS Feeds
- Advanced Hard Drive Caching Techniques
- Web Administration Scripts
- New Products
- thanks for share, great
11 hours 50 min ago
- There are factors which are
16 hours 50 min ago
- Gnome 3 ?
17 hours 35 min ago
- Reply to comment | Linux Journal
21 hours 42 min ago
- "Redis RethinkDB 4.5%" on Best NoSQL Databases
1 day 7 hours ago
- on the ground
1 day 14 hours ago
- I was able to read the whole
1 day 15 hours ago
- since i have read the title i
1 day 18 hours ago
- Belanja Online Cari Voucher Diskon
1 day 19 hours ago
- The kernel doesn't really
2 days 7 hours ago