Summary
In a recent Yahoo YUI video, Yahoo's Douglas Crockford gives an overview of the state of Ajax application development on the Web, and points to ways in which the Web can improve.
Advertisement
Douglas Crockford, inventor of the JSON data exchange format, and Yahoo's chief DHTML evangelist, presents an overview of the State of Ajax and client-side Web development. Among the topics he discusses are Java, the flaws and benefits of JavaScript, why CSS should be replaced, why mashups are significant, and what can be done about Web technologies, such as HTML and JavaScript, that saw their last major updates in 1999.
On Java's failure to capture the client-side Web, Crockford notes that:
Java had all the right stuff, but it failed... at least in this space [in the client]... There were three main reasons for this. First, because it didn't keep the write once, run anywhere promise. It turns that write once, run anywhere is really hard. Even though most of the VMs were written by one company, it was not stable enough to keep [that] promise. Any software technology that can keep that promise is doing something extremely right, and Java wasn't doing it, at least not then.
He also notes Java's security model and client-side user experience as the other two reasons.
Crockford considers mashups to be an important innovation:
One of the things Ajax enabled are mashups. And mashups are the most interesting innovation in software development in at least 20 years. Mashups are the fulfillment of the promise of component architecture and highly reusable modules. Mashups are great, providing a whole new class of interactivity and value. Unfortunately, mashups are insecure, so when we’re designing mashups now we have to be careful that the mashups not have access to any confidential information. And it turns out every page contains confidential information, so mashups, as currently practiced in the browser, are inherently insecure.
Security is a big problem in the web. I think it’s our number one big problem. The web is an exploit waiting to happen. I think we need to fix the browsers before we can take the next step... What does this mean for mashups? If you have scripts from two or more sources, the application is not secure. Period. That's intolerable. The whole thing about the way the Web works now, is [that] we need to be able to do that, have multiple things coming together from anywhere and be able to create value by their interaction for the user without compromising anybody.
Crockford comments on JavaScript as:
JavaScript has a deeply flawed, unpopular model, but it works in an environment where Java failed really, really hard. That's evidence that despite its flaws, JavaScript is doing something seriously right. The Web requires an especially high level of compatibility, the run everywhere problem, and JavaScript is succeeding there. We have four major browsers, each with a completely different JavaScript engine, and we have high levels of interoperability. That's an amazing achievement...
The worst feature in JavaScript is its insecurity, it was not designed for a context in which you have different interests coming together, requiring to defend against each other... collaboration under mutual suspicion. It's really urgent that we fixed that.
Crockford also notes that the Web user interface model is still very far from the state of the art in graphics technology, and that new Web technologies should to take advantage of graphics hardware that's standard on most computers today.
Another interesting part of the presentation is Crockford's skepticism about the different Web standards committees in moving the art forward. On HTML, for example, he notes that the current widely deployed standard dates from 1999, partly because new efforts at HTML standardization have not succeeded:
HTML was scheduled for termination. The W3C scheduled to kill it in favor of an HTML-based format, XHTML, which has failed. Despite the fact the HTML has all these inherent problems with it, it works, and it has benefits that are significantly more interesting than the thing that was supposed to replace it. We see a lot of standards activity, and I would sum that up as confusion. I'm not confident that the HTML 5 committee is going to converge on anything that we would want.
What do you think of Crockford's comments on the state of Ajax?
Java had all the right stuff, but it failed... at least in this space [in the client]... There were three main reasons for this. First, because it didn't keep the write once, run anywhere promise. It turns that write once, run anywhere is really hard. Even though most of the VMs were written by one company, it was not stable enough to keep [that] promise. Any software technology that can keep that promise is doing something extremely right, and Java wasn't doing it, at least not then.
Java failed in the client because applets took too long to be downloaded, installed and run, whereas web pages appear with very little delay.
The failure to keep the promise of 'write once, run everywhere' is not the reason that Java failed, because html/scripting has the same problem from browser to browser, but it was successful.
One of the things Ajax enabled are mashups. And mashups are the most interesting innovation in software development in at least 20 years. Mashups are the fulfillment of the promise of component architecture and highly reusable modules. Mashups are great, providing a whole new class of interactivity and value. Unfortunately, mashups are insecure, so when we’re designing mashups now we have to be careful that the mashups not have access to any confidential information. And it turns out every page contains confidential information, so mashups, as currently practiced in the browser, are inherently insecure.
Information is the real value from the dawn of civilization. Any system which promotes the management of information is bound to be a success. That's why operating systems should not have file systems but databases. It's information that counts, and the web is about information being available in forms that can be combined to produce new information.
Security is a big problem in the web. I think it’s our number one big problem. The web is an exploit waiting to happen. I think we need to fix the browsers before we can take the next step... What does this mean for mashups? If you have scripts from two or more sources, the application is not secure. Period. That's intolerable. The whole thing about the way the Web works now, is [that] we need to be able to do that, have multiple things coming together from anywhere and be able to create value by their interaction for the user without compromising anybody.
Easy to fix: make a new programming language which is distributed, scripted, secure, safe, and declarative; release it in two forms: a client form which has a browser and a server form which allows applications to just run, without any visual output. There are projects like this which prove my proposal's feasibility: the DARPA Browser, capability-based security, the E programming language, the EROS operating system etc.
Crockford also notes that the Web user interface model is still very far from the state of the art in graphics technology, and that new Web technologies should to take advantage of graphics hardware that's standard on most computers today.
That's because HTML is a hardcoded implementation of a graphical output. If HTML was a domain-specific-language of a real programming language, extending it with new visuale elements would be very easy.
HTML was scheduled for termination. The W3C scheduled to kill it in favor of an HTML-based format, XHTML, which has failed. Despite the fact the HTML has all these inherent problems with it, it works, and it has benefits that are significantly more interesting than the thing that was supposed to replace it. We see a lot of standards activity, and I would sum that up as confusion. I'm not confident that the HTML 5 committee is going to converge on anything that we would want.
No committee has ever designed something useful for everyone. It's impossible...the solution is to make HTML (or whatever language is required) Turing-complete, and let people design systems for their needs.
> Crockford also notes that the Web user interface model > is still very far from the state of the art in graphics > technology, and that new Web technologies should to take > advantage of graphics hardware that's standard on most > computers today. > > That's because HTML is a hardcoded implementation of a > graphical output. If HTML was a domain-specific-language > of a real programming language, extending it with new > visuale elements would be very easy. >
He also mentions that HTML's page-oriented data transfer was a throwback to an old IBM terminal type. By contrast, other terminals worked based on character transfer, which is somewhat similar to Ajax. In effect, he was suggesting that HTML as medium for Web application programming is a big problem. But it also works well enough to have emerged as the most successful programming paradigm on the Web, partly because alternative solutions were more complex.
I have to disagree with Douglas on one point. Java did not have the right stuff and browser compatibility was not the main problem either (JavaScript incompatibility can be a pain too); it was just one of the many problems. Here are some others: 1.) Applets were initially not supported on all browsers and platforms. It got worse when Microsoft removed Java from IE during the legal battles with Sun. 2.) To write an Applet you have to find and download an extra SDK for your platform to compile your program. 3.) Java was slow to start up and used a lot of memory. 4.) Many applets ended up being big and took to much time to download on a phone modem. 5.) Applets do not integrate with the html of the page but usually are separate boxes that do their own thing. JavaScript allows you to write small functions that build on top of the already existing html. 6.) Applets have no graceful fallback mechanism for backward compatibility. If you do not have Java installed you get an empty white box. With JavaScript you still get some static document and possibly additional information from the NOSCRIPT section.
Also JavaScript is a scripting language which has the following benefits: 1.) Open source: the user has access to the source of the script he is running and can learn from it, reuse it or improve it. 2.) Ease of building: you don’t have to go through the write, compile and link cycle. A simple text editor is all you need. 3.) Short startup time. There is no checking or optimization done upfront. Checks and optimizations happen as the program runs. 4.) Embedding: a small enough core that you can integrate the language as part of the product and hook it to existing functionality.
Java and JavaScript came out in 1995. In retrospect I wonder why nobody thought of integrating an open source scripting language into a browser before that time. Perl was publicly released in 1987, Python in 1991 and Lua in 1993. All of these were available with source code under liberal BSD style licenses with all of the groundwork already done. We could have leveraged existing tools and documentation and everybody could have reused the same implementation to improve compatibility.
Crockford is a an entertaining presenter but he clearly misses the point:
1. The internet was not created as an application platform and it has been successful because of this fact. 2. Reliable internet applications can be built on top of the existing Internet infrastructure (which is insecure and difficult for application programing). Reliable network protocols are built on unreliable. The same applies to Internet applications.
Previous Topic
