This past weekend I had the pleasure of attending and presenting at the annual SXSW conference, down in Austin, TX. I participated in a panel discussion called ‘More Secrets of JavaScript Libraries’ (a follow-up panel to last year’s talk). The synopsis was as follows:
In a reprise from last year’s popular panel – the JavaScript libraries authors are getting together again to impart their what they’ve learned from their experience in developing solid, world-class, JavaScript libraries. Covering everything from advanced aspects of the JavaScript language, to handling cross-browser issues, all the way up to packaging and distribution. A complete set of knowledge for a JavaScript developer.
The talks went really well – we each gave a quick 10 minute presentation on a topic that interested us and finished up with some Q&A. The individual talks were as follows:
- Getting Loaded (All about network performance and file loading) – by Nate Koechley of YUI.
- Meta-Language Frameworks (Talking about the abstractions provided by frameworks) – by Andrew Dupont of Prototype.
- Real World Accessibility (A quick examination of the upcoming ARIA specification) – by Becky Gibson of IBM and Dojo.
- Performance and Testing (Looking at various performance analysis and testing techniques) – by John Resig of jQuery.
The full presentation and audio can be found online.
More information about my talk can be found in my follow-up post: JavaScript Testing Does Not Scale.
Joel Gascoigne (March 20, 2009 at 11:22 am)
Thanks John, I’ve only quickly flicked through the slides but all those presentations seem so relevant to my thought processes with the web applications I’m developing right now!
There comes a point when you work with adding enhancements so much that performance really becomes an issue. You end up with 15 external JavaScript files and the page really seems to take a while to load, with a noticeable pause between the DOM loading and the JavaScript kicking in. I’m looking to address all these things very soon and this is just what I needed! I’ll be checking out the audio.
Me Again (March 21, 2009 at 2:24 pm)
Direct link to the PDF please? :(
Adam Schwartz (March 22, 2009 at 12:54 am)
Wow, John. This presentation is fantastic. Keep them coming!
Lewro (March 23, 2009 at 3:46 am)
Very useful information. Thanks for that.
iPad (March 26, 2009 at 12:09 am)
Great post John, This is amazing, too many information but a good resource. Thank you
Richard Fink (March 26, 2009 at 1:03 pm)
John,
This is a little OT, but I’d like your take on something. It’s about an interoperability issue and it impacts JavaScript’s effectiveness – especially in the areas of design and accessibility.
I’ve done a lot of work relating to font-rendering and adaptive sizing/resizing of elements and I’ve got a question begging for an answer.
You’re the oracle, here’s the problem, hoping you can shed some light:
As a group, browser-makers now seem to have settled on “Adaptive Zoom” as the main approach to provide users with an all-purpose way of adjusting the size of text and images within the browser window.
(See pdf:
http://code.msdn.microsoft.com/ie8whitepapers/Release/ProjectReleases.aspx?ReleaseId=563
for a description of it in IE8.)
First Opera, and then FF3, and more recently IE8 and now Webkit (with Chrome 2 Beta and Safari 4 Beta) – all have adopted this approach.
However – particularly in FF – there seem to be no properties available with which to detect the user’s current Zoom level in script. Developers are forced to work in the dark.
Early on in the development of IE8, with Beta 1, I pointed out to the IE team that, as it was then implemented, IE8’s Zoom made it impossible to distinguish between a browser window sized to say, 80% the width of the screen at 100% Zoom, and a browser window sized full-screen set to 125% Zoom.
(An informal whitepaper on the issue here:
http://www.readableweb.com/forIEteam/IE8zoomanalysis.htm
)
The problem was addressed, thankfully, by having IE’s screen.logicalX/YDPI properties report the recalculated dots-per-inch or “logical” pixel screen resolution currently being used by IE to calculate sizes.
Now, going back to Webkit (Chrome 2B and Safari 4B) – in those browsers, as a conscious decision I’m sure, there IS a way to detect Zoom level but the values returned by the properties are at odds with the values of the same properties in FF.
Here is the discrepancy:
Chrome and Safari allow for the detection of Zoom by comparing the value of:
document.defaultView.getComputedStyle(document.documentElement, null).width;
which always returns the width of the window (documentElement) in device pixels (that is, the “unzoomed” pixels) with
document.documentElement.clientWidth
which returns the size of the window in logical pixels.
However, in FF, both properties return the same value (that is, the size of the documentElement in logical pixels) which makes them useless for comparison and thus determining Zoom level.
What’s your take on this. Is there anything “incorrect” W3C spec-wise with what WebKit has done? It doesn’t seem so to me and it’s an issue of interoperability, certainly. Do you think it would be wise for FF to follow suit in the next 3.x version?
There are all kinds of scenarios where knowing the Zoom level of the page is important. Even critical.
I filed a bug report ages ago, but it fell by the wayside.
But hey, your opinion counts way more than mine, what’s your take?
noodler (April 3, 2009 at 9:47 am)
i’ve never understood why this keeps being a question, why YUI does what it does the way it does.
1. parse & build a function call tree
2. build a partially ordered function set to cover dependencies
3. IF we want to build a single js file,
3.T map function poset back to source files to make a source file poset
4.T build and cache the mega-source file
ELSE
3.F write and cache a script which loads necessary scripts in order
all of this and more can be automated.
a more extreme (as in deviation-from-mean) set of techniques along these lines can be seen at: http://www.razorspeed.com/index.php/what-is-razor-optimizer
implement as little or as much as you wish.
carlos (April 7, 2009 at 8:35 am)
“more-secrets-of-javascript-libraries”, what a stupid title, you guys are really selling it , aint you? your libraries suck.plain javascript is the only one. it just looks like you are trying to attract a bunch of kids who wants to do drag & drops, there is no secret , and it is for sure not find in a js librarie but in javascript itself.
Jason Grant (April 7, 2009 at 3:54 pm)
Excellent overview.
Still today so few people implement proper accessible JavaScript enabled interfaces and what you are proposing here is total wizdom for long time to come in terms of accessibility and general best practices.