At last night's monthly meeting of Sydney JavaScript developers, the organizers tried a different format: the panel. I will admit I was a little wary of the format choice, as I've heard a lot of commentary about panels not being so great (and I've attended SXSW, which seemed to re-inforce that) -- but I think it turned out quite well. The panel had a range of JS developers that represented different libraries, and articulated their differences in opinion in constructive ways.
The panelists were:
- James McGill, Google, Maps API
- Dan Nadasi, Google, Closure (@DanielNadasi)
- Matthew Sain, Yahoo!7, YUI 2
- Tom Hughes Croucher, Yahoo!, YUI 3 (@sh1mmer)
- Dmitry Baranovskiy, Sencha, Raphael (@DmitryBaranovsk)
- Evan Trimboli, Sencha, Sencha
- Julio Ody Cesar, Awesome By Design, jQuery (@julio_ody)
- Jared Wyles, Atlassian, AUI (@rioter)
(Photo courtesy of halans - Check out his other SydJS pics.)
I typed up notes during the panel on the questions and answers, and am sharing a paraphrased version of those notes here. I didn't type anything word-for-word, and I missed some of the answers, so don't consider this to be 100% faithful. But perhaps it's useful for folks who want to remember what was discussed last night, or see the kind of questions that were asked at the panel.
Q: Can your libraries be loaded asynchronously, and if not, how do you sleep at night?
Tom: YUI was designed with that in mind from the beginning. It's the only way of loading it.
James: The Maps API does it automatically - developer only includes the bootstrap and the API pulls the full library in after. All APIs should do it automatically, otherwise developers won't usually bother.
Q: How do you test the Maps API offline?
James: You must mock, and trust that we've designed our API in a way that makes for reliable mocks (we have). Check out the Closure mocking framework, based on EasyMock.
Q: Why doesn't Google use Raphael for SVG?
James: The Maps API only uses paths, and it isn't that hard to get paths working cross-browser. When you use a library, you're putting performance in someone else's hands, and the Maps API can't afford to do that.
Q: What do you think of CoffeeScript?
Julio: CoffeeScript is not equal to JavaScript. Different languages appeal to different people.
Tom: I talked with Douglas Crockford, and he actually likes CoffeeScript, and thinks that maybe we should have done JS that way (if we could have). But now, even if we could reinvent JS, even if we could make it better, it would be a separate language. JS is winning right now, not because it's the best language ever, but because it's the language of the web. So we should stick with JS.
Dmitry: There is real life, and there is play. I like to play- I like canvas- but I don't use canvas in real projects because it doesn't work in IE. It's not real life. It'd be sad if there was a CoffeeScript programmer that did not also know JavaScript.
Q: What's the purpose of the Closure inspector?
Daniel: It is easier to debug your Closure code before it has been obfuscated, and that's what you normally do. Some bugs, however, only occur after obfuscation, and the Closure inspector is useful for debugging the post-obfuscation bugs. Sometimes those happen when using the advanced compiler options with symbol exporting.
Q: How will we develope JS in the future?
Julio: We will see more modularization, where every page has its own miniframework, its own collection of modules used by the page.
Jared: We will see JS in the server more.
Evan: We will also see JS in the desktop.
Dmitry: We will have better IDEs for developing JS.
Tom: We will have better code, and new features of the language (like strict mode) that encourage developers to write better code.
Q: Do you support touch events in your frameworks?
All: Yes.
James: Currently, it's not too difficult to support touch events since the mobile browsers all followed Apple's lead in implementing them and the API is the same. But, in 8 days, Microsoft is going to release Windows Phone 7, which bundles a ported version of the IE7 browser, and we don't have any idea what touch events will look like. Mobile development is going to get significantly more interesting; we're going from a 1 browser field to a 2 browser field.
Q: What place do UI frameworks like Yuki and ExtJS have - should we be using them, and are they accessible?
Tom: ( Re accessibility) Frameworks should use ARIA for accessibility, which marks up the page to give screen readers additional info. The fact that most screen readers don't support JS is a technology failure. There's nothing inherent about JS which means it can't be supported. Current accessibility guidelines put the onus on the screen readers. Modern readers like Jaws 7 do support JS. Pick a framework that supports ARIA.
Tom: (Re frameworks) Rebecca Murphy has written recently about the problems with using jQuery for enterprise sites. With libraries lik jQuery and Prototype, people tend to write DOM-focused code. With libraries YUI and Closure, people write component-based code. jQuery has done a good job of getting people started with JS and making it easy to get your site going, but when you're building full apps, the component-based architecture with its inheritance and modules works better. DOM-style architecture gets ugly fast.
Nadasi: Part of the reason we use component-based approach in Closure is because it works better at scale. In base.js, goog.inherits lets classes inherit from other classes easier. The ability to inherit is better for distributed development, for having many developers working off the same codebase.
Q: I come from a Java/C++ background, where tooling support is important. In moving to JS, I'm missing the tools. A lot of the times, I feel like I'm guessing-and-checking. Are you guys keeping secrets from us, or is that the way it is?
Julio: I work with Ruby as much as JS, and it has really nice testing tools - the best of any language I've seen. I hope JS will have similar tools somedays.
James: Maybe you should check out Closure compiler. It lets you enforce static typing, which is like testing for a dynamic language - it will catch half the errors. But, in defense of JS, what other development environment lets you inspect your UI, change your UI on the fly, and reflect the changes back?
Dan: Keep in mind that the cost of implementing static typing is that you lose dynamic typing. Static typing can be great for development at scale, but it deprives you of some flexibility.
Tom: I recommend SpeedTracer from Google for performance checking, Firebug for Firefox, and Visual Studio Debugger for IE.
Buchanan (audience): We would love more tools for JS, but on the other hand, I've never lost a day of development due to my IDE refusing to work.
Q: Do we need libraries now? Browsers are better, JS is easier cross-browser.
Julio: We're not at the stage yet where cross-browser isn't an issue.
James: When you're getting started with building an app, you can use libraries to take care of the hard parts for you. But once you start getting significant users, like we did with the Maps API, you'll understand their specific usage patterns, and you will find it better to write your own code that optimizes for their use case.
Q: What was the design problem you were trying to fix when building your library?
Matthew: We designed YUI for the frontpage of yahoo.com, and then decided to open-source it for others to use.
Dmitry: IE has a problem with speed, it's very slow, and it has a problem with DOM, it's just fucked up.
Q: Should we use jslint?
All: Yes.
Q: What would you do better if you were starting over?
Dan: With Closure, we would design API from the start instead of adding bits and pieces. The API is surprisingly consistent, likely due to having the same 2 code reviewers throughout, but it could be better. The documentation is shit. Michael Bolin's book fills in the gaps, but you shouldn't need to read a book to understand how to use it.
James: I would design the code to make it testable first, because it's hard to go back and make something testable. If I really wanted to hate my life, I would code everything in IE6 and get it working reasonable there, and *then* see how awesome it performed in other browsers.
Evan: Augmenting the prototype of basic objects (Array, String, etc) was not a good idea.
No comments:
Post a Comment