The conference was a a few weeks back and I never had a chance to post my review/notes on day 2 and 3 of the conference. I finally got to clean-up my notes so here they are. Better late than never!
Opening Keynote: Can we fix the Web?
Douglas Crockford was the opening keynote today. He is the creator of JSON. If you’ve never heard of him and you do AJAX development, I urge you to visit his site. In my opinion, it’s one of the best JavaScript resource on the Internet. In many ways, Douglas has made my life as a developer easier, in particular with JSON and JSMin. For these reasons, I was excited about his keynote and he did not dissapoint me.
Douglas believes that the number one problem of the web is security:
- an attacker that is able to run scripts on your page can request more scripts
- an attacker can make requests to your server
- an attacker can read the document and obtain sensitive information
- an attacker has control of the display so they can request more info from the user
- an attacker can send data anywhere in the world
Web applications are built using a set of languages such as JavaScript, HTML, CSS, etc.. This makes it more difficult to enforce security because text that is benign on one langague can be dangerous on another one.
The web standards require these vulnerabilities to be present. What are the causes of insecurity?
- Javascript
- All code run with the same authority
- JavaScript is an insecure language and the ECMAScript4 proposal is even worse.
- DOM
- All nodes are linked to all other nodes on the network.
- Cookies
- Ambient authority leads to confusion and impersonation
Quote: “If there is a script from 2 or more sources, the application is not secure. Period.” This means that mashups are insecure by nature. The big problem is that advertising, the bread and butter of the web, is a mashup.
After showing the audience why the web is broken and insecure. Douglas started answering the question set in the title of his presentation: How can we fix the web? His strategy for fixing the web revolves around three points:
- Safe JavaScript subsets
- ADSafe defines a safe HTML/JavaScript subset. From their website:
ADsafe makes it safe to put guest code (such as third party scripted advertising or widgets) on any web page. ADsafe defines a subset of JavaScript that is powerful enough to allow guest code to perform valuable interactions, while at the same time preventing malicious or accidental damage or intrusion. The ADsafe subset can be verified mechanically by tools like JSLint so that no human inspection is necessary to review guest code for safety. The ADsafe subset also enforces good coding practices, increasing the likelihood that guest code will run correctly.
The ADsafe subset blocks a script from accessing any global variables or from directly accessing the Document Object Model or any of its elements. Instead, ADsafe gives the script access to an ADSAFE object that is provided by the page’s server, giving indirect access to the guest code’s DOM elements and other page services.
- Google’s Caja is also a safe JavaScript subset, but use transformation rather than validation. Using Caja, web apps can safely allow third-party scripts on their pages.
- Small browser improvements
- JSONRequest should be built into the browsers for safe data interchange .
- HTML provides no modules
- Massive browser improvements: we need to replace JavaScript and the DOM. We could start with a subset of JavaScript such as ADSafe and add useful and secure features.
Douglas concluded by saying that if we don’t fix the web, the competition (SilverLight, Flash, JavaFX) will displace it. They are all superior technologies.
For more coverage of Crockford’s Keynote address, check out these articles: 1, 2
Session 2: Accelerate AJAX development with Appcelerator
Jeff Haynie from appcelerator started his talk with a long history of web development. In my opinion, I think he spent too long on this portion of his talk and I felt like he lost the audience after a while. We were all waiting for the punch-line but it took too long to come.
Jeff gave us a brief overview of appcelerator’s platform. Appcelerator is an open source software company that develops products and services for rapid rich Internet application (RIA) development on a service-oriented architecture (SOA). You can find out more about their product on their website at www.appcelerator.com or you can join their developer community at www.appcelerator.org.
Session 3: Introduction to YUI
Eric Miraglia from Yahoo gave us a great introduction to the YUI Library.
The main components of YUI are:
- YUI Core JavaScript
- YUI JavaScript Utilities
- YUI Controls/Widgets
- YII CSS Core
- YUI Tools
- YUI Theater
YUI Core javascript is very similar to Prototype or JQuery. It is broken down into three parts:
- The YAHOO Global Object: It provides a single global namespace within which all YUI Library code resides and must be included everywhere you use the YUI Library. It provides a set of functions that is used throughout the library.
- The Dom Collection comprises a family of convenience methods that simplify common DOM-scripting tasks, including element positioning and CSS style management, while normalizing for cross-browser inconsistencies. With the DOM Collection, you can:
- Position elements on the page
- Manipulate styles: add and remove styles
- Change viewport size
- Add and remove clasnames
- The YUI Event Utility facilitates the creation of event-driven applications in the browser by giving you a simplified interface for subscribing to DOM events and for examining properties of the browser’s Event object.
The YUI Core Javascript is only 31K Minified.
The YUI Javascript Utilities contains a set of libraries for animation (You can animate everything in the styles that have a value. That’s awesome!), browser history management (to deal with back button), connection management (for doing AJAX), cookies manipulation, JSON, etc… YUI uses a modular design. You only need to load what you need.
YUI Controls/Widgets is a set of controls or widgets that one can use on a web page. It includes controls for calendars, charts, color picker, Slider, etc… YUI contains one of the best collections of controls among JavaScript frameworks.
The YUI library also provides a set of CSS tools. It is less than 7K of CSS when you pack all of the files together. It it composed of four elements:
- Reset CSS: Neutralize differences in the browsers’ default stylesheets and provides a normalized fuoundation on which to build. Takes away all of the default presentation from the different browser implementations.
- Base CSS: provides baseline browser-neutral styling treatments for common HTML.
- Fonts CSS: foundation for typography and font-sizing.
- Grids CSS: for page layout. This is similar to the Blueprint CSS framework.
While the competition between JavaScript frameworks is intense, YUI has a lot to offer:
- Great documentation
- Yahoo will host the YUI files for you, on their CDN.
- Dedicated team working on YUI full time. Used by more than 400+ million users.
- One of the most comprehensive suite of controls/widgets
- CSS libraries to go with the JavaScrit libraries
- YUI Theater
- A great set of tools such a profiler, a Javascript Compressor, a testing framework…
Though I’ve never used the YUI library, it looks great and I would definitely consider using it on my next project.
Session 4: Enterprise Comet: Real-Time, or Real-Time Web 2.0?
Jonas Jacobi, co-founder of Kaazing, started by defining the term “real-time”. His web search brought up the following definitions of real-time:
- A system that responds to an external event within a short and predictable time frame
- …so rapidly that the interaction appears instantaneous
- An activity which occurs “while you wait”, rather than being delayd for processing at a later time.
He then proceeded to define the ‘real-time web’ and came up with the following:
- Web Clients instanteneously updated
- End-users receive updates simultaneously.
Finally, he came to the conclusion that what matters is when you notify the user.
Comet is a technique to establish a permanent connection from server to client over HTTP. Comet allows you to send messages from server to client. It’s a pushing mechanism, rather than the traditional pulling mechanism that we are used to on the web. It is client agnostic. It supports browser clients or desktop applications.
HTTP 1.1 uses 2 connections per domain. So if you tie one connection to Comet, then there is only one connection left for your application to work with. The solution is to use sub-domains to work around this limitation. This sub-domain technique is recommended by Steve Souders in “High Performance Web Sites” and Rails 2.0 makes it very easy to configure.
Some Comet use-cases:
- External Data Model Changes
- Web stock ticker
- Web chat and mail - new messages received
- Web online games - multi-player poker
- Shared Data Model Changes: issue tracker updates
- Sports - a goal is scored
Jonas then went on to discuss scability issues with Comet. In particular, how do you send all these messages at the same time? The problem is that the server must copy messages across multiple-connections, possibly thousands.
Comet seems like an interesting technology and I look forward to see what will happen in that space.
Session 5: jMaki Webtop: an AJAX Mashup Framework
Arun Gupta who presented the day before on jMaki used this session to introduce us to the jMaki Webtop. He started with a short introduction of jMaki for those who did not attend his longer presentation on the subject the day before. Then, he proceeded to explain what jMaki Webtop is and showed us a demo.
jMaki webtop is a Mashup Framework that is:
- Simple and easy to use
- Runs in browser
- Evolution
- Extensible
- Manageable
- Persistent: with Google Gears
- Shared
In a few words, it’s kinda like a configurable iGoogle page. You can play with the demo that he showed us here.
Arun posted his slides on his blog, along with great reports of day 1 and day 2 of Ajax World.
Session 6: Real-World Enterprise Rails and AJAX: Top 10 lessons learned
Rode Cope is the CTO and Founder of OpenLogic, Inc. He used Rails to build osscensus.org, a global community effort to catalog the use of open-source software.
Rode Cope went through the 10 lessons that he learned while developing an enterprise Rails application with AJAX.
1) Use AJAX, but make it seamless
Good uses:
- Table Sorting
- Ordering rows in lists
- Data filtering: checkboxes, radio-button, dropdowns…
- Dynamic data loading: populate dropdowns, templates, flash-based graph data loading
- Modal dialog: “Don’t show this again”, Load content, update cookie via AJAX
- Adding elements to the page
- Edit in place
2) Don’t use AJAX if you don’t need it.
- Don’t shock the user
- AJAX is just another tool
- No drag and drop just because it’s cool
- Use client-side javascript when it makes sense: avoid server roundtrips if they don’t add value
3) Use just enough tools
- Don’t need a giant framework
- Firebug is your best friend with YSlow
- Tail the development log
4) Use Open Source
- Prototype,scriptaculous, jQuery
- Live Validation (for client side validation)
- TinyMCE
- Watir, FireWatir, Selenium
- Netbeans, Radrails
5) Don’t be afraid of JavaScript
- View Helpers: wrap AjaxRequest fo convenience, link_to_remote
- RJS
- Don’t be afraid of writing JavaScript by hand: avoid roundtrips to server
6) Watch out for JavaScript Conflicts
- run jQuery in no-conflict mode
- Live Validation wants to take over onSubmit, making it hard to implement your own custom submission logic
- Javascript Libraries are still Wild Wild West
7) Client-side validation is hard, but worth it
- Show/hide/populate fields dynamically
- Count characters remaining
- Default values in certain fields
- Live validation works well with Rails by supporting ActiveRecord validations
8 ) Cross-browser issues: not too bad
- Tooltips: some browsers truncate tooltips, some wrap them. Use library, custom javascript, or AJAX to enforce consistency
- CSS: may need special browser checks if you really care about width details, margin and padding defined differently in IE and FF
9) Security must be implemented in all layers
- Never ever trust any input: URL’s, hidden fields, form values, cookies, POST data, etc..
- No soft, chewy center: client-side validation is only there for user convenience, not for security.
- Check all roles in your controllers
- Implement all data security in your models
- View helpers simplify things: button_display_for_downloads(user)
- Consider promoting helpers to application level
10) Testing is crucial
Session 7: Spice up User Experience with Silverlight RIA
Sue Googe is a big fan of Silverlight. She spent her 50 minutes praising the benefits of SilverLight and trying to convince the audience that we should all be using Silverlight. So much that I thought she worked for Microsoft 
Why Silverlight?
- very rich UI framework built-in
- provide AJAX++ experience with little code
- deliver super quality media on the web
- Cross-browser / cross-platform
- Rapid development
- It’s free and open-souce
- Flash learning curve is high
- Has own media streaming, up to 720p
Sue showed a cool demo of the Silverlight Deep Zoom feature. She posted her slides on her blog.
Session 8: AJAX and Social Computing for the Enterprise
I’m still trying to find out whether I attended this session or not. I must be getting old
Session 9: Seam Remoting
Shane Bryzak’s talk was about Seam Remoting, which is an AJAX framework for JBoss Seam. I wasn’t planning to attend this talk at first but the OpenAjax Gadgets & Widgets talk was full by the time I got there. Since I heard good things about Seam in the past, I figured it wouldn’t hurt to learn what it is all about.
JBoss Seam is an Enterprise Java Framework:
- Provides a rich, contextual component model
- Simplified integration with various useful technologies such as BPM, drools, security, GWT, etc…
- Runs in many different environments: JBoss, Weblogic, Websphere, Tomcat
- Standards based, submitted as JSR-299 (Web Beans)
- Supports biection (inversion of control) for wiring components
- Seam components can be session beans, entity beans or POJOs
- JBOSS Tool plugin for Eclipse
How does it work?
Seam lets you make calls in JavaScript as if the class was defined in JavaScript. In your JavaScript, you will never make explicit ajax calls, you simply make a call to a function such as getStatus, as if you were on the server. Seam Remoting takes care of the plumbing and sends the request. The messages are sent using XML.
To define the Java classes and functions that you want accessible remotely, you simply have to annotate the calss with @Name(’nameofclass’) and annotate the functions that you want accessible remotely with @WebRemote.
Communication Protocol:
- is an XML-based protocol
- Loosely inspired by XML-RPC
- Supports object graph recursion
- Allows requests to be batched so you can queue up a number of requests and send them all at once.
- Support all the usual data types
Seam makes working with JMS easy. Shane went on to demo a Chat Room application using Seam with JMS. I was quite impressed. I like Seam’s approach to Ajax and I would be curious to know if there are other frameworks doing something similar.
Shane’s slide were really good and you do not need to be at the talk to benefit from them. Shane was nice enough to email me his slides and authorized me to post them here. You can download them here.
SYS-CON.TV Power Panel: The Business Value of RIAs
The day concluded with a panel of CTOs talking about who their biggest clients are, what kind of RIA applications they are building, what they believe to be the future of RIA, and other topics related to the business value of RIAs.
Summary
In summary, the second day of the conference was very good. My favorite talks were Douglas Crockford’s opening keynote, the introduction to YUI, the real-world Rails talk, and the presentation on Seam Remoting.
Technologies that I plan to learn a bit more about after this day are: SilverLight, YUI, Seam Framework, Watir, FireWatir, and jMaki.
