Ryan Stewart of Adobe joined us for episode 5 of the Open Web Podcast. We really want to be pragmatic Open Web citizens, so thought it would be good to hear from Ryan and get his point of view on what Adobe, and he, are thinking with respect to the Web as a-whole.
AIR: Ryan talked about how he sees AIR fitting into the landscape, and how he personally would love to see Geolocation APIs added
Open Source: Ryan shares his insight on the experience Adobe has gotten from their Open Source projects (Tamarin, Flex, …)
It was a real pleasure to have Ryan come into the lions den. He is very honest with what he does and doesn’t know from within, and doesn’t hold back on his own thoughts.
Steve Souders posted on Runtime Page Optimizer a tool that you can think of as a performance proxy. It sits on the server side, and cleans up content before it is sent back to the browser.
What can it do? Steve let us know:
RPO automatically implements many of the best practices from my book and YSlow, so the guys from Aptimize contacted me and showed me an early version. Here are the performance improvements RPO delivers:
minifies, combines and compresses JavaScript files
minifies, combines and compresses stylesheets
combines images into CSS sprites
inlines images inside the stylesheet
turns on gzip compression
sets far future Expires headers
loads scripts asynchronously
RPO reduces the number of HTTP requests as well as reducing the amount of data that is transmitted, resulting in a page that loads faster. In doing this the big question is, how much overhead does this add at runtime? RPO caches the resources it generates (combined scripts, combined stylesheets, sprites). The primary realtime cost is changing the HTML markup. Static pages, after they are massaged, are also cached. Dynamic HTML can be optimized without a significant slowdown, much less than what’s gained by adding these performance benefits.
Steve had another couple of interesting posts recently:
Say no to IE6 discusses how we need to do something to help upgrade IE6 users (to IE7 is fine!)
Raising the bar talks about results from Steve’s UA Profiler tests and how new browsers are pushing forward
As always with Dav, the utility comes with a full API and documentation, features useful methods like fryBacon() and stopFryBacon() and there are several clever custom events (baconReady, baconDone, baconStart) to subscribe to.
If you dive deeper into the workings of bacon you also find hidden messages of what the future might hold: void cook() An override method for extending this class to maybe fry eggs too.
I am now waiting for jQuery cocktail sausage and protoype T-Bone.
With Dojo 1.2, the build system can generate a 5.5KB gzipped (13KB ungzipped) dojo.js file, via the customBase layer option. Useful for iPhone development if you want to get under the 25KB uncompressed size limits for the Mobile Safari cache. That small dojo.js is basically just the loader and some bootstrap functions, but it allows you then to tune your build layers to meet the 25KB and dynamically load what you need as you go.
Also, the djConfig options afterOnLoad/require/addOnLoad allows loading Dojo after the page is loaded. Great for making progressively enhanced pages render even faster.
The event object contains two properties: .clientRects and .boundingClientRect, both of which refer to the result of the associated DOM methods.
In a nutshell, boundingClientRect gives you a single rectangle encompassing the entire area in which a paint operation could've taken place whereas clientRects gives you a number of rectangles, each encompassing an individual area that was drawn.
I have seen some of the great applications that SitePen produces, but unfortunately too many of them are for companies behind the firewalls.
It is great to see Sensei a really compelling Dojo application that SitePen wrote for their training class. This isn't one of those simple training examples that you normally get though. This says quality.
Revin Guillen explains:
When conducting Dojo training courses, we’ve found it to be very valuable to go beyond simple code snippets to demonstrate APIs, patterns, and other key concepts. Snippets and demos are useful, but they often lack a very important quality: context. Nothing beats having a full application in front of you—with code available to read and modify as you learn the ropes—so we built the Dojo Sensei Reader, a rich, powerful RSS reader realized as a single-page web application.
We designed Sensei specifically for training sessions. We wanted something that demonstrates the major areas of functionality Dojo offers, but as a single cohesive application rather than a collection of unrelated demos. We wanted something small enough that training groups could easily grasp the entire codebase, yet large enough to be worth using as a real-world application. We wanted something that shows the development process from start to finish, to demonstrate the level of polish you can achieve in a Dojo-based application. Beautiful as well as functional, it does all of this while providing a great, fast user experience.
One of the beautiful things about Sensei is that it proves that you don’t have to sacrifice maintainability to build a fast application. One key goal in our development process was to create an easy way for training groups to introspect the code, follow the app as it works, and even modify or augment its behavior at run-time by swapping code in and out. To deliver on this, we designed and integrated what we call Blox, a small JavaScript package with the power to make it all possible (it’s Sensei’s flux capacitor; we’ll cover it later). The result is a codebase that is very easy to work with but incurs negligible performance impact for its trouble.
Today, we are really excited to be able to announce a big personal change. Ben and I are joining forces, full time, for the first time. What are we doing? We are joining Mozilla to create a new group with the charter to create developer tools for the Open Web.
Mozilla is placing a big bet, not only on us, but in the developer tools space.
Why are we doing this? Ben and I are passionate about a couple of things: compelling software and developers. In various roles in the past, we have built tools that attempt to make developers productive. We are huge advocates for the Open Web, yet we feel that tools are lacking on our collective platform. We want to help make a difference.
As we ramp up this new group, we will be looking at the problem and seeing where it makes sense to step in. We are going to be experimenting, and thinking about how to make developers lives better in different ways, so we aren't expecting to see traditional tools come out of this group. Also, we don't want to do this alone. We want to involve the entire community which is one reason that we are so excited to kick off this work at Mozilla. We believe that we have a unique opportunity to put developers first. We can build these tools in the open, with total transparency; the Mozilla way.
We respect the work being done by other vendors, and very much want to work together. We can't wait to reach out early-on in the process, involving companies that believe in the Open Web like we do. Together we can drastically improve productivity, allowing developers to build compelling user experiences.
We are just getting started. As soon as we come up with some ideas, we will be sharing then with you and asking for community participation in various forms. You, the Ajaxian community, have been phenomenal over the years, and we can't wait to do more together.
Working with different API’s can present hurdles as we attempt to massage the same data in two different data structures - one for a grid and another for a pie chart. To address this specific challenge, I developed a short user extension Ext.ux.GVisualizationPanel enabling users to integrate visualizations into Ext JS applications without concern for these issues. The GVisualizationPanel adapts any Ext data Store into the google’s format and enables you to embed any type of visualization into a panel.
He then shows some examples, such as this intensity map:
TinyMCE: There’s a modified version of this included in Wordpress these days, and it’s extremely well supported by its developers. You get all the formatting options you’d expect, plus the ability to easily remove excess formatting tools with just a little code. As an added bonus, there’s a collection of plugins which enable even more advanced formatting options.
YUI Editor: Sadly, this one is quite often ignored, perhaps due to that fact it’s the product of a large corporation. Nonetheless, I know a kick-ass set of tools and utilities when I see one, and this editor is fit for any such best-of list!
You have 2 main configurations for this - Editor and simpleEditor. You’re not limited to these however, as once you get to grips with the API you can bespoke it with relative ease.
FCKEditor: FCKEditor is one of the longest standing web-based editors out there, and used in a great many open-source apps. It’s also available in a number of server-side languages
FreeRichTextEditor: FreeRichTextEditor is gaining more momentum these days, and comes available with 2 modes available straight out the box: design, code and preview.
WidgEditor: This is the work of client-side coding guru Cameron Adams, whose personal project has become an extremely viable, standards-based rich text editor for web applications. The JavaScript behind is also lean yet easy to read (should you want or need to understand it further), and the code output is smooth.
Are there others out there that you like? Any experiences that you would like to share? A friend recently jumped from a paid widget to TinyMCE saying that it was finally ready for prime time.
Sam Ruby has that way about him that sees things very clearly. He just took a peak at jQuery for the first time and was able to really put into words what I think jQuery enthusiasts like about the library:
The notable thing about this is that despite all of the asynchronous events taking place, the code is sequential (nested, but sequential), and that the JSON results of the AJAX call is immediately available to the function that is invoked when the selection changes.
This is based on the following code that he wrote:
Andy Lyttle wants to standardize one particular feature of <input type="search"> (which is already supported by Safari, but not standardized): placeholder text for input fields. The text would initially display in the input field (possibly in a stylized form, smaller font, or lighter color), then disappear when the field receives focus. Lots of sites use Javascript to achieve this effect, but it is surprisingly difficult to get right, in part because no one can quite agree on exactly how it should work. Mozilla Firefox displays the name of your current search engine in its dedicated search box until you focus the search box, at which point it blanks out and allows you to type. Safari's search box is initially blank (at least on Windows), and only displays the name of your default search engine after it has received focus and lost it again. Google Chrome's "omnibox" displays "Type to search", right-justified, even when the omnibox has focus, then removes it after you've typed a single character. Adding an <input placeholder> attribute would allow each browser on each platform to match their users' expectations (and possibly even allow end-user customization) of how placeholder text should work for web forms. Discussion threads: 1, 2, 3. So far, there is no consensus on whether this should be added to HTML 5, or what the markup would look like.
Matt Ryall has a good article on HTML 5, headings and sections, which documents the differences between HTML 4 and 5's header elements. My personal opinion: I once wrote a 500 page book in Docbook, a non-HTML markup language for technical writers. Docbook 3 had separate elements for <sect1>, <sect2>, <sect3>, &c, and it was a massive pain in the ass to cut-and-paste sections, or try to reuse them in different documents. Docbook 4 added a generic <section> element which can be nested indefinitely, and all those problems went away. Lots of web authors copy-and-paste HTML markup; anything that helps that "just work" is a good thing.
Kevin Dangoor of SitePen has introduced Reinhardt a dispatch engine on the client side:
A typical server-side web framework today includes three main components: a URL dispatching to some controller object scheme, a template engine, and a data mapping facility. Currently in Dojo, you’ll find that the latter two items already exist. dojox.dtl provides the first one, and dojo.data provides the second.
Given that Dojo already offers an implementation of the Django template engine, and that regular expression-based URL dispatch was a good fit for our problem at hand, I decided to base our URL dispatch on the model provided by Django.
, OpenWebPodcast
