Here’s a taste of what he works on:
Scripteka (http://scripteka.com) was one of the first app-like websites that we have built. Then there was a Wehike (http://wehike.net), but that wasn’t an application – just a plain, very minimal, website. I recently worked for Aptana (http://aptana.com) together with Ryan Johnson (http://livepipe.net/), implementing front end of some of their redesigned sections. Other than that, my full time job involves intranet-based apps, and none of them are publicly available : (
His most visible work is prototype’s changlog.
Question 1: What programming paradigms do you use – Class / Prototype based inheritance, AOP, Functional Programming, etc?
I’m a bit of a performance freak and this, of course, reflects on the way I design applications. I try to stay away from patterns that provide real private members, since memory consumption is usually more important. Pseudo private members (i.e. those that begin with underscore and are documented as being private) work pretty well for us even in large applications.
Functional programming is definitely handy and often makes for quite elegant solutions. I absolutely enjoy it once in a while.
Other than that, proper class?/object hierarchy and overall architecture definitely needs to be thought through. In my experience, any kind of inheritance emulation usually makes application simpler to understand and maintain.
I asked him to elaborate where functional programming has been useful:
Prototype extends `Function.prototype` with plethora of useful additions – `bind`, `curry` and `wrap` are one of the most helpful. Both `bind` and `curry` allow for a partial application – when different functions can be made out of one – by currying? original with different arguments. Bind, of course, allows to specify within which context? function should be called. `wrap`, on the other hand, allows to program in AOP style – wrapping? functions with before? and after? behavior. `wrap` is also useful for monkey-patching core methods without ever touching library source. I’m always cautious when using these helpers – additional level of abstraction is useful but deceiving, and can easily kill performance pretty badly.
Question 2:What architectural patterns do you employ – MVC, SOA, Layers, Components / Widgets?
Service oriented architecture works out quite nicely for us. I wouldn’t say it affects client-side design much, though. I haven’t tried MVC approach on client-side either. Perhaps our systems are not large enough to fully take advantage of all aspects of MVC. Widgets, on the other hand, are a great way to encapsulate distinct pieces of functionality. I think DOM would be a great foundation for widget-based systems if it wasn’t designed and implemented so poorly; Instead of taking advantage of it, DOM usually needs to be thought of as a quite hostile and unpredictable environment – all for achieving maximum compatibility.
I asked him to follow up on what is implemented poorly in the DOM and how he would improve it:
- Careless resolution of named? elements via document or global objects (i.e. when `form` with name=getElementsByTagName? shadows native `document.getElementsByTagName` method, etc. I’m still not sure how they managed to f*ck-up like this. )
- Verbose API, lack of relatively basic functionality (which HTML5 is trying to fulfill now), methods are not chainable?
- Gaps in specification (and vague explanations here and there)
Question 3: How to you manage event handlers and responding to them?
I use event delegation where appropriate, of course. Also, having some kind of way of simulating mouseenter/mouseleave is a must.
Question 4: Dom Building – how do you build HTML?
I use templates often – chunks of markup presented as strings – which are then interpolated with proper values at runtime. I find this to be the most maintainable way to deal with DOM creation/modification.
Question 6: Testing – what level of testing do you do? What tools do you use?
I should definitely be doing more testing : ) I find it hard to test applications that change often and usually resort to just unit-testing separate widgets/scripts.
Question 7:Compression & Build – Do you compress your JS files, what do you use?
All assets are pretty much always gziped; I don’t see a reason not to do so. Everything else depends on a project. Rails, for example, concatenates all .js files when set up properly so we take advantage of that. Minification, on the other hand, is usually not much of a high priority.
Question 8: What development methods do you use – Waterfall, Agile, V, Story based, Requirement based?
I work in a very small team where we have a very transparent and flexible communication process. We try to stay more on a side of agile? than that of a waterfall.
Question 9: Documentation – Do you document your code? What tools do you use?
I try to document as much as I can. jsdoc is a perfect tool for that. I’m looking forward to using PDoc in the future (developed by one of Prototype.js members – Tobie Langel)
Question 10: File Structure – Do you have a standard file structure? What does it look like?
No standards really. Usually depends on the server-side framework in use.
Question 11:Performance – How do you tackle performance issues?